Hi
Toying around with the simulator on Jonne´s latest code Pokitto/PokittoSim.
Where do I find what screen mode I am running (and therefore also where to change it)?
How many different screenmodes do I have?
Cheers
Jacoste
Screenmode is a compile-time setting. If you define PROJ_HIRES=1 in project properties->build options->#defines your screenmode is 220x176x4colors. If not, it is 110x88@16 colors.
I know this is confusing.
Screenmode setting will be replaced by a simple screenmode number. As in PROJ_SCREENMODE= number. Very soon.
For what it’s worth, I think it might be better to hide the actual number from people, for example:
#define PROJ_SCREENMODE SCREENMODE_LOWRES
(Which I think should also be possible in project properties)
This has several benefits:
- People don’t have to remember which screenmode is which number, just remember the name of the screenmode.
- Code referring to
PROJ_SCREENMODEcan be more symbolic, e.g.#if (PROJ_SCREENMODE == SCREENMODE_HIRES) - It’s easier to change the number later if it has to change for some reason (different hardware/whatever).
Actually that doesnt work. You see, at that point in time (declaring defines through project build options) keywords can not yet have a meaning. so PROJ_SCREENMODE = MODE_HIRES would actually be meaningless.
I am afraid numbers is the way to go here
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.
1 Like
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
1 Like
1 Like
Yes, BUT: 19360 byte buffer. You need to conserve RAM to make the game run. For example Squiddy does not run.
1 Like
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.
5 Likes
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.
1 Like
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.
1 Like
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.
1 Like
Is lcd refresh interrupt based or are you just refreshing the lcd synchronously whenever the app gets its drawing done and calls update()?
1 Like
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
1 Like
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.