I think what @Hanski is suggesting is to bypass the regular hi-res screen drawing which has an image buffer and clears the screen at a regular interval and use a system where individual sprite objects are used instead of a screen buffer and the sprites are drawn directly when the screen needs to update.
I remember him demonstrating this trick but can’t remember which thread.
But @jonne’s mention of dirty rects is another reasonable solution since it avoids the expensive process of clearing the screen.
(Fun fact: the well-known version of ‘Solitaire’ packaged with older versions of Windows achieves the trick with the cards by not clearing the screenbuffer.)
Oh I see! So with this “sprites” technique, I would probably want to limit the game to single screens at a time (like Legend of Zelda) and avoid side-scrolling or anything like that (hopefully the tiled mode come together soon for that kind of thing).
But… Old 8-bits had one size fits all, there was no other way. You had a tiled screen mode with a fixed tile size, colour depth and even a fixed max number of tiles. The 8-bit era had many many wonderful games that found ways to get a round or enhance this limitation.
I don’t 100% like the idea of artificial limitations on a console (e.g. pico-8) but I think it might be worth considering in this case.
That was because of hardware limitations.
Old consoles handled tiles and sprites in-hardware,
often with processors acting like the precursor to GPUs (notably the PPU of the NES/SNES).
Things like changing z-order, multiple layers and the like are fine if you need them,
but if you don’t need them and you’d rather have the extra memory/processing,
then there should be a way to make that exchange.
@Hanski: Is there any reason why Sprite mode only works in Hi Res mode? I’m finding the 4 color limit a little… limiting, so I am considering switching to Standard Res, but without Sprite Mode, performance is pretty bad.
The main reasoning for creating a sprite system was to provide more colors with good performance in standard Hi-Res mode, which have only 4 colors.
The 110x88 mode has much better performance because of 1/4 of the number of the pixels compared to HiRes mode, and also drawing functions are highly optimized. Even scrolling should be possible.
That has not been my experience. Simply drawing enough 8*8 bitmaps to cover the screen (in standard def) drops the frame rate to <30fps (closer to 20).
Seems like I’ll need to look into some of these other rendering techniques (dirty rect, tiled, etc) or stick with sprite in Hi Res and just limit myself to 4 colors.
Clarification: I mean that Standard Def does not seem to have the performance required to render an 11x14 gride of 8x8 bitmaps at 30 fps. Hi Def is much worse if not using your Sprites technique (but significantly better if you do use that technique - 50fps in my test)
In general I think 30FPS is considered the minimum accepted refresh rate before quality starts to degrade. For me personally, a response of less than 16ms/60FPS feels sub-par (I’m the kind of person who would rather play at min spec to achieve 60fps, rather than have a better looking game running at 30).
Below 30fps, the game starts to feel unresponsive and choppy for most people (in my experience).
I have over 30 fps by using two layers of scrolling tiles (background and foreground) using the normal buffered 110x88x16 color mode. Thought, you need to be prepared to do some inner loop optimization to achieve that in the buffered mode.
