That's really encouraging; I'm now obsessed with getting a complete game working at 50Hz and in that context I think even just two or three sprites would do it. The arbitrary 40% came from what was left over in the current demo but it strikes me it's also very close to the amount of time between line 192 and the next line 1 so setting a firm limit in that range resolves all potential concerns about sprite flicker (well, until I end up having to display a different three of the four sprites I really want each frame, or whatever).
And once I have something working along those lines I can start seeing how well the scrolling holds up with more realistic map data. I've a few more optimisation ideas either way. On 18 May 2012 09:46, Simon Owen <[email protected]> wrote: > On 18 May 2012, at 00:56, Tommo H wrote: >> If I have, say, 40% of a frame to spend on it, how many sprites, and how >> large, is it realistic to expect to be able to draw and un-draw? > > Maybe around 4-5 sprites of 16x16 pixels? IIRC my Pac-Man emulator has about > half a frame to draw 6 sprites of 12x12, plus a couple of background tiles, > including save/mask/draw/restore. For an extra boost perhaps generate the > sprite drawing code with knowledge of the data (like Chris did in SAM > Defender) — bonus points if you prepare that at runtime. > > It's nice to have some fresh on-topic content to read, so keep posting! > > Si >
