Sorry to resume an old topic, but is this fixed? Especially regards bitmap rotation and flip.
I don’t think so. It’s legacy code from gamebuino
Could try and re implement it
So actual api is missing the abilities to draw image rotate/flipped? That’s would be useful for tile engine/maps!
There’s no reason it couldn’t be added, but it would come at a cost.
Either memory or speed.
Flipping is usually relatively cheap because it usually just means flipping the order that data is read in.
Rotating on the other hand is quite costly.
its not super costly since its 90° rotation
actually i think flipping works already just rotation is not working
or its only flipping in one derection
1 Like
Fair enough, 90, 180 and 270 are cheapish.
Arbitrary rotation is difficult though.
Confirm, vertical flip work. Both in sim and hardware. 90° rotation is just enough for nice tile set maps.
1 Like
was thinking about it and you can do rotation on sprites be pre rendering them
if 90° increments work you only would need 3 or more additional sprites that are incrementally rotated and then polished up since rotating pixel art never looks good on low resolutions
doing it on hardware would just be to slow for most games
i think this would then give you smooth rotation: (if 90° is inplemented)
index = index%16;
drawBitmap(x, y, sprite[index%4], index/4, 0);
Would this “rotating” with prerendering simply be a value that changes? i.e. 1 = 90 degrees 2 = 45 degrees 3 = 0 degrees.
you would preferably use a indexed system for rotation instead of using angles or radiants
imagine it more like a clock but instead of 12 hours its 16 in this example
I’m interested only on 4(3) rotations 0°-90°-180°-270° and 2 kind of flip Vertical and Horizontal.
This kind of modification on image should be almost at zero cost on CPU. So I think at least. Also are the only kind of rotation/flip that works well also on low res sprite (8x8).
That means: 2 Bit for flip, and 2 Bit for rotation. Easy to store on memory.
Pokitto Inception:
From left: PokTiles(Tiles editor, can export to C header), Pokitto simulator, Pokitto Web (thanks @FManga) and Real Pokitto (With altered palette to make it more similar to my display)
6 Likes
Hah, I hadn’t noticed how inaccurate my colors are! 
Actually really not so bad. Maybe some photo artifact due to animation (scroll effect). Real pain is to match the HW Pokitto . It really depends on palette color choice, and the one in picture is simply too dark.
@Pharap can you split the post to another thread.
From here I suppose :
I’d like to discuss also with @jonne about his view of the API about flipped/rotated images
Right now it seems there’s some bug on drawing X flipped images near borders.
Consider it done.
(Sorry about the out-of-order comment, I missed it on the first go.)
1 Like
i mean you could be memory efficient with some sort of bit-flag to store both flip and rotation
drawBitmap(x, y, sprite], NO_FLIP | NO_ROTATE);
though you would lose a bit of ease of use (like the thing i showed before) and you need to unpack those bits as-well so im not sure if its worth it
but im not a c++ expert
So @jonne what’s your view of the api about flipping/rotating images?
Right now it seems only X flipping is implemented (with a glitch on the borders).
Its quite simple to do but needs to be implemented and tested for all different bit depths
1 Like
IF the bitmp drawing is going to be messed about with, how about having an optional flag to identify the bit depth of the bitmap, but default it to the current screen mode. That way, we could have 4bit images in 8bit mode etc.?
2 Likes