At the very least, they should be separated into different classes/namespaces.
Having different libraries with different APIs would be another good alternative.
Treating display modes as ‘plugins’ or libraries in their own right rather than trying to maintain them as part of the actual library would help to reduce complexity.
It would allow people to choose what they want based on their needs (simple interface vs something for power users).
Though I also still like the suggestion I made a while back about facilitating display modes via template classes:
@spinal the different (and slightly conflicting) suggestions you mention are precisely why we should have multiple options rather than a single canonical tile mode.
If we did have a single canonical tile mode, I think it should be aimed at being the simplest or most general tile mode rather than trying to include features that only certain games will use.
Specialist options should be for specialist libraries because ‘one size fits all’ is nearly impossible in programming.
Features and speed/memory are inversely proportionate,
and are thus conflicting requirements :P
Already now, my ability to mix and match the Arduboy/Gamebuino stuff is mainly limited not by hardware but the complexity of having several libs with overlapping functionality
Abstracting the lowest layer as per your and @FManga 's suggestion makes a lot of sense
If someone wants to make a suggestion (preferably an hand drawn sketch) of how they think the core API / extended libs should be abstracted, I’d be very, very happy
@Hanski’s “dirty-rectangle” trick is an old old trick and works. In dirty rectangle, only the “changed” part of the lcd is updated. Easily 40fps in your case.
Also, I’d like to point out, that one of the things that is slowing the hires down significantly, is the indexing of the palette where each pixel value needs to me masked and bitshifted. @FManga already found a solution to that problem by unpacking the palette into unused RAM.
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)
