It would, but I doubt there’s currently any serious data on what the speed is like for the different modes.
There’s probably enough to say “mode a is generally faster than mode b”,
but probably not enough to give an estimate on expected framerate.
The availability of sprites would probably be easier,
but I don’t know if anyone here knows the answer for all modes.
I expect there’s one or two people who know “sprites are available on this mode”,
so if we can get several of those people to provide an answer then we’d be part way there.
That is correct. The main motivation for me was that way adding more available colors to the Hi-Res mode, and also work around a slow copy of full 220x176 pixel buffer to LCD.
We should add a field to each screen mode indicating a game/demo/example where its used. This would be useful when deciding what should be deprecated, what should be optimized, and what a good test case is.
I suspect the Gameboy screen mode can be safely removed.
I think it’s done by not clearing the screen buffer,
and instead ‘weakening’ the screen buffer before drawing.
I.e. having a palette full of different shades of a specific colour and then decrementing every non-zero palette index in the screen buffer before drawing new ones.
I can only assume though, because there’s no source code, just a .bin file:
Does removing the [Draft] part in the title of the wikis mean that they’re now official or just that it’s no longer the policy to put [Draft] in the title and that having them in the ‘wiki drafts’ category is enough?
I agree. Copying from the framebuffer to the LCD is roughly the same speed (Mode64 being the fastest, iirc), but the speed of writing to each buffer should vary a lot. It would be useful to have a series of tests for specific functions like drawBitmapData, print, drawRect, etc.
