I really must remember to look at this to update sensitive…
@Hanski: Not really. It needs a different API (compared to the buffered screen modes) so I can’t simply move the code into the PokittoLib. It also requires its tiles and sprites to be in a different format. I think the cleanest would be to keep it as a separate lib.
Also, I’m completely swamped with work-related stuff these days, so I won’t be able to do anything with this any time soon. 
i dont think we mind to swap image formating for speed, if its in the pokitto lib more likely to use it
maybe consider this to be added to poklib 2.0 where last i heurd its a big overhale so we could just get the best graphics modes and flesh them out
(note on me, im currently realy busy so i cant realy work on any pokitto stuff, good luck you all)
I don’t think anyone will care at all, just have the new format implemented in img2pok and nobody will even notice it’s different.
1 Like
Having a screen mode as a separate lib instead of as part of the core is a good thing. It makes for code that is much easier to maintain. We should be thinking of taking things out of core, leaving only hardware abstractions and things that we want to keep uniform from one game to the next (like the bootlogo and loader).
Just imagine what drawPixel will look like after a few years, when there’s about 50 modes. 
Still, the biggest problem is that everyone’s got their hands full right now. 
1 Like
This is precisely why I think different image modes should be implemented using different classes (and/or separate libraries).
There’s no such thing as one size fits all, and when image modes vary drastically (e.g. tiled vs sprite vs bitmap) it doesn’t make sense to try to squash them into a single interface.
Part of the reason I’m holding off on attempting to make a mockup of what a PokittoLib2 might look like is because I’m hoping we’ll get a cross-platform IDE that supports C++11 before then.
1 Like
Well the problem with modes right now is once a better one comes out the olds practically abandoned
So in the end you just want 2 or 3 modes
The mode15 I did was just a bruteforced screw memory aproch just cuz we can 2bit high-res is practically unused
Maybe your right with separating but can still be in the library like standard library you include separate parts of it that you need like #include <vector.h> but then “modes/highreztiled.h” or something
‘Better’ is relative. Different modes have different benefits.
Some games will prefer low-res high-colour,
some games will prefer high-res low-colour,
some will be more suited to tiles,
some will be more suited to sprites.
Having different modes is what will allow the boundaries to be pushed.
Not sure how relevant this question will be but, is the RGB565 a limitation of the screen? if so, as the above example uses an 8bit palette, wouldn’t it be best to use a fixed palette for this mode?
Assuming that the RGB565 is a limitation, this 252 colour palette should cover the whole range that the screen is capable of.
[edit] 525 instead of 252, and as @Pharap will point out, I’m completely wrong.
I was under the impression that the screen is RGB888 and RGB565 was used to save memory.
RGB565 can achieve 2**(5 + 6 +5) == 2**16 == 65536 colours.
I’m not sure where you got 525 from.
You’re right, I think I’ll blame it on the lack of sleep or something like that. I had it mixed up in my head, I was thinking number of steps, rather than bits.
I still think it should be a good enough palette for most purposes though.
Perhaps, but really whether it’s useful or not depends on the bit usage.
Hi-res mode uses 4 colours because it’s 2 bits per colour (i.e. 4 pixels per 1 byte).
Lo-res uses 16 colours because it’s 4 bits per colour (i.e. 2 pixels per 1 byte).
RGB565 is specifically used because it amounts to 16 bits, which is 2 bytes,
and converting to RGB888 is just a matter of shifting.
RGB252 wouldn’t afford anything because that’s 9 bits.
RGB242 would be more reasonable because it would fit in 1 byte.
In any practical meaning this LCD screen is RGB565. The controller chip could handle RGB888 but its hardwired to RGB565 by manufacturer
1 Like
Interesting.
24-bit colour is overrated anyway, 16-bit is perfectly adequate. :P
well even under 565 the color reproduction on the screen is not the best out there
The gamut (colorspace) of a low cost TFT is not something comparable to a laptop/phone OLED screen. Just a fact of life.
Use higher contrast colors 
hmm ok just wondering what would be the widest spectrum 256 colors selection to take for this screen as sort of a standard pallet
I think the palette I put together works quite well - Weird idea about compression
It covers a good amount of the spectrum in 252 colours.
ok seems to work well enough here i just did a little conversion to that 252 colour
incidentally you have some spare indexes for transparency or other things
1 Like