[Wiki]5.Pokitto Screen Modes

A detailed list of all screen modes


Mode 1

Name: Hires 4-color mode
Useful for: High resolution with low screen buffer RAM usage
Type: Raster, Screen Buffer
Resolution: 220x176 (native)
Bit Depth: 2 bpp
Colours: 4
RAM Usage: 9680 bytes
My_settings.h: PROJ_SCREENMODE = 1 or PROJ_HIRES = 1 (deprecated)
Screen Mode Define: MODE_HI_4COLOR
Other Features: Sprites, Dirty Rects


Mode 2

Name: Lores mode / fast 16 color mode
Useful for: Fast 16 colors with low screen buffer RAM usage
Type: Raster, Screen Buffer
Resolution: 110x88
Bit Depth: 4 bpp
Colours: 16
RAM Usage: 4840 bytes
My_settings.h: PROJ_SCREENMODE = 2 or PROJ_HIRES = 0 (deprecated)
Screen Mode Define: MODE_FAST_16COLOR


Mode 13

Name: Mode 13
Useful for: 256 colors, medium ram usage, very fast
Type: Raster, Screen Buffer
Resolution: 110x88
Bit Depth: 8 bpp
Colours: 256
RAM Usage: 9680 bytes
My_settings.h: PROJ_SCREENMODE = 13 or PROJ_MODE13 = 1 (deprecated)
Screen Mode Define: MODE13


Mode 15

Name: Hi-res 16-color mode
Useful for: High resolution with 16 colors, but high RAM usage
Type: Raster, Screen Buffer
Resolution: 220x176
Bit Depth: 4 bpp
Colours: 16
RAM Usage: 19360 bytes
My_settings.h: PROJ_SCREENMODE = 15
Screen Mode Define: MODE15


2

TAS Mode

Name: Tiles-And-Sprites (TAS) Mode
Useful for: High resolution, High color, Tile-based games. See this thread.
Type: Tiled mode
Resolution: 220x176
Bit Depth: 8 bpp
Colours: 256
RAM Usage: Configurable
My_settings.h: PROJ_SCREENMODE = TASMODE
Screen Mode Define: TASMODE


Mode 64

Name: Wide Pixel Mode
Useful for: Commodore 64 look
Type: Raster, Screen Buffer
Resolution: 110x176
Bit Depth: 8 bpp
Colours: 256
RAM Usage: 19360 bytes
My_settings.h: PROJ_SCREENMODE = 64
Screen Mode Define: MODE64


To be continuedā€¦

8 Likes

Name: Mode 13 (inspired from msdos screen mode 13, half resolution, more colours)
Type: Raster, Screen Buffer
Resolution: 110x88
Bit Depth: 8 bpp
Colours: 256
LibSetting: #define PROJ_MODE13 1
RAM Usage: 9680 bytes

2 Likes

Itā€™s a wiki by the way - youā€™re free to make edits

1 Like

Cool, I didnā€™t realise that :slight_smile:

1 Like

Would it be a good idea to add more details per screen mode? Like for example achievable frame rates, availability of sprites,ā€¦

2 Likes

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.

The only mode with dirty rects and sprites is mode 1.

1 Like

For some reason I was expecting there to be more.
At the very least I was expecting lores mode to support them.

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.

That makes sense.

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.

2 Likes

There was also some kind of slow phospor mode or something like that but I canā€™t check the details for the momentā€¦

edit I was refering to this:


I do not know if this was eventually added to pokittolib as screen modeā€¦

No, that was just a hack :slight_smile:

1 Like

too bad, I liked the idea! :slight_smile:

It is only a couple of code lines, so you can do it easily.

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:

Iā€™ve removed the non-working modes and I am going to clean them out eventually. These are the modes that should actually be used.

3 Likes

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?

That is very clear now!

2 Likes

We could really do with some statistics on the speed of some of these graphics modes.

If someone wants to stress test them and document the tests used, that would be much appreciated.

3 Likes

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.

3 Likes