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)
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.
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.
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.
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.
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
Instead of a standard palette, why not just build one from your sprites/tiles? That’s what I did in my demo: added all the sprites/tiles into a single image in aseprite, changed from RGBA to Indexed, exported the PAL.
I guess you could use RGB332/RGB233/RGB242/etc as a general purpose palette, but that might have problems with certain colors. @spinal: Your palette has no gray?