256… which means I can load the same 16-color palette 16 times into the inflated 256-color palette and not have to mask away the upper nibble to get the correct color for the lower nibble?
1 Like
2 tables of 256 each for low and high lookup
edit: actually no, 1 table of uint16_t [256][2]
first write value [hi|lo][0] then [hi|lo][1] (just increment pointer)
edit: holy cow. this might speed up the rendering alot
2 Likes
Ah, I only tried with the lower nibble because I was thinking of optimizations that would also apply to the 1- and 2-bit modes.
I was using the Mode15 demo for testing, and copying the large sprites onto the framebuffer seems to be much slower than from the framebuffer to the LCD. In that case, the more important optimization would be to provide a “copyBitmapData” function that doesn’t support transparency. It also wouldn’t hurt to invert the ifs and fors (have ifs on the outside with case-specific fors inside.)
For games that use small sprites and no background, I think this would help. I’ll give it another go.
2-bit mode? uint16_t[256][4]
I suspect the second dimension in the array isn’t going to come for free. Thumb2 doesn’t have an LDR from a pointer with a shifted register+immediate offset. I’ll do some testing.
Edit: Are there any games out there using mode15? The Mode15.bin isn’t really representative of what we should be optimizing for.
@adekto: I added the tile scrolling, see the links in my first post again.
It might be good to split this thread in two.
I get 10fps in Pok15 initially.
With a uint32_t[2][256] palette and the necessary adaptations, I get 15fps… which is still pretty slow, but 50% faster.
Pok15_paltrick.bin (163.2 KB)
2 Likes
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.