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).
I understand if you still want to stick to bare numbers, but it’s definitely possible to do it this way.
It works both ways actually at the moment
You can do
PROJ_HIRES=1
or
PROJ_SCREENMODE=1
and the end result is the same
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
Yes, BUT: 19360 byte buffer. You need to conserve RAM to make the game run. For example Squiddy does not run.
Constraint stimulate creativity!
But you spoke about more screenmodes… you throw the rock now: some leaks?
I will open up the process of how to make more screenmodes, so that the community can make them.
220x176@16 is already working (tested on both sim and hardware)
220x176 tiled mode is WIP
Tinyarcade mode 96x64x256 also coming, but needs more work
Pico8 mode also coming
EDIT: uneven bit modes (3 bits, 5 bits per pixel) are also already in test.
What does a “tiled mode” mean in this case?
“Tiled mode” is a classic from the era of early computers and game arcade machines, when systems had little RAM.
It is an unbuffered mode based on a map of tiles and the idea of a “scanline” as it was in CRT screens.
I wonder would a C64 multicolour style mode be worth doing?
@spinal
110x176?
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.
Is lcd refresh interrupt based or are you just refreshing the lcd synchronously whenever the app gets its drawing done and calls update()?
display.update is called when game.update() returns true.
It is not the best possible solution, for several reasons. In the future, we might add other ways of driving the refresh
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.
@jonne wikipedia article speak about 3d rendering engine. Not sure if it’s the tile mode you want to implement in pokitto.
Oooops!!!
Hmm. Can’t find decent articles
Goes sumthing like this:
http://cs.umw.edu/~finlayson/class/spring16/cpsc305/notes/13-tiles.html
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.
