I'm talking about Prizm C here. I'm just curious how fast can prizm load the picture that is as big as its screen. Depends on how fast the prizm can handle it, I might come up with something.

Well, the LCD can refresh at around 20-30fps (I forget the exact number). Do you mean blit as well?

What are you planning to do?

What it blit?
Also, 20~30 fps sounds reasonable.
Also, when I include picture in C, does it have to stay in OS or the program itself?

Exactly this (however, I was actually able to get Raptor to run at 32FPS, with very minimal screen flickering, so it's at least that)



Blit == the actual drawing of the picture to Video RAM (VRAM)

The picture, when included is part of the program itself, and is included in the .data/.rodata section of it.

Ah. So that gives me few more questions.

1. So I have to convert the picture to binary/hex data or something?
2. How big/fast will program be if I were to include like 40 pictures?
3. Does fps increase much if I overclock the Prizm?

1. You can use SourceCoder to convert your pictures. And then just paste what it gives you into your program and make sure it has a unique variable name.
2. The amount of data in your program doesn't affect the speed, once you start referencing them all, it will get a little slower, but that's just because you're doing more calculations. And, it's just as fast to get the first picture as the last one.
3. I'm not certain, but I'm pretty sure it will not speed up the FPS, because the bottleneck is the LCD, not the CPU.

It would speed up the frame rate to an extent (see Gravity Duck), but once you reach the maximum possible frame rate you can't go above that by overclocking AFAIK.

The LCD bottleneck really isn't a problem, from all the tests I've been conducting. Gravity duck has to blit many different things onto the screen, which is actually its bottleneck. A game like Raptor, which blits very little onto the screen at a time, can go much faster; the bottleneck isn't the LCD refresh rate, it's the actual time it takes to blit something into Video RAM, it seems. Writing data to the LCD driver is actually pretty quick once you set the X and Y position to start drawing to for that round of transfer. Once yo uhave that setup, transfer of data to VRAM -> GRAM is as fast as writing the color_t chunks of VRAM into the LCDC.

Overclocking indeed speeds up frame rate significantly, since it makes memory access much faster, and therefore blitting faster (since blitting is just copying things over from data to VRAM, for the mot part).

As for how fast it'll be with 40 pictures, it'll depend on how you blit them, whether they're compressed or not, their size, etc. Not enough info to answer that question.