It won’t work through using #define because PROJ_SCREENMODE is defined in the project build options, but if you also declare SCREENMODE_HIRES in the build options before you define PROJ_SCREENMODE then it does work (I tested to make sure).
But the thing is, there will be many more screenmodes. I already have 220x176@16 colors working and more to come. In that case a simple numeric system (rather than a combination of different settings) is IMHO clearer.
This is how it is done in UZEBOX and I think its OK
It’s probably doable, but I can only imagine it being useful for displaying art considering the drawing modes are chosen at compile time. I guess it depends how fast the drawing code ends up being.
Doesn’t tiled rendering cause visible tearing in the screen where the upper part is from the new frame and the lower part of the screen is from the old frame? Or is there some sort of “vblank” period in LCD where you do tiled mode blitting?
Why would it be a problem for tiled mode and not a problem for buffer mode?
Theoretically it would be possible for the upper part of the buffer to contain new pixels and the lower part to contain old pixels if there wasn’t some sort of system in place to prevent tearing.
You’re actually bang on the money there. I actually haven’t solved the problem of tearing. I just brute force around the issue. Theoretical maximum of the screen blit is ~200 frames per second. I just spend as little time as possible drawing the individual frame.
Not just half x resolution, but using a 1bpp buffer for the pixels and a second tiled (ish) buffer to add different colours to different regions of the screen.
Yeah, I read the docs. As far as I can tell it was mostly used for art and only occaisionally used for proper games. That and the C64 could (as far as I can tell) change screen mode while running so it could e.g. do the titlescreen using the multicolour mode and run the game itself in a different mode.
I could be wrong though, I only skimmed the docs because I’ve been busy today.