[Wiki]5.Pokitto Screen Modes


#1

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


Mode 4

Name: Gamebuino Legacy (enhanced with 4 bitlayers for colors)
Useful for: Gamebuino game porting
Type: Raster, Screen Buffer
Resolution: 84x48
Bit Depth: 4
Colours: 16
RAM Usage: 2016 bytes
My_settings.h: PROJ_SCREENMODE = 4 or PROJ_GAMEBUINO = 1
Screen Mode Define: MODE_GAMEBUINO_16COLOR


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…


Pokitto Ware Factory idea
[Game]Planet Escape [wip]
Exported file from Piskel issue
Pokitto is on the way, what games should I make?
Pokitto is on the way, what games should I make?
[Tutorial][Beginner]4.Creating your own art - Piskel editor for Pokitto
Idea: Little Computer People For Pokitto
#2

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


#3

It’s a wiki by the way - you’re free to make edits


#4

Cool, I didn’t realise that :slight_smile:


#5

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


#6

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.


#7

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


#8

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


#9

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.


#10

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.


#11

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…


#12

No, that was just a hack :slight_smile:


#13

too bad, I liked the idea! :slight_smile:


#14

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


#15

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:


#16

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.


#17

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?


#18

That is very clear now!


#22

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.


#23

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.