Does anyone know of any games that use directBitmap
?
I decided to reorganise directBitmap
on a whim but I don’t have anything to test it with.
https://github.com/Pharap/PokittoLib/commit/aef184ece0ca6f2696a8a2e8eeba0ec4f8e71e6c
Does anyone know of any games that use directBitmap
?
I decided to reorganise directBitmap
on a whim but I don’t have anything to test it with.
https://github.com/Pharap/PokittoLib/commit/aef184ece0ca6f2696a8a2e8eeba0ec4f8e71e6c
Hi 5hink sensitive does, can’t remember now. I might have made something up, but I’m about 80% sure it does.
I already messed with my draw routines a little a few weeks back as the directbitmap seemed to have rotated 90 degrees at some point.
Will this rearrange result in a speed up of any sort?
if i recall the rotation is due to a hardware function that let you draw a screen “window” sector in portrait mode only, since in landscape you had to send out the data one line at a time
(i think it was 9.2.21Horizontal and Vertical RAM Address Position in the display documentation)
wait why is directBitmap
using so much directPixel
and not something like lcdTile
?
Until I test it, I have no idea.
I’ve moved some variables so they’re closer to their point of use and I’ve fused a pair of branches,
which are things that normally would result in a performance improvement.
But those are optimisations that compilers normally do anyway*,
so it depends whether the compiler was already doing that or not.
Sometimes it can’t do them because the rules of the language forbid it
(i.e. C++ has certain sequencing rules that a compiler can’t break)
and sometimes the compiler just can’t figure it out because the code is too complex.
I guess it might improve speed if we turn on asm like I see in the other draw modes
But for real why aren’t we using lcdtile, direct pixel is insanely slow
The problem with using assembly is that mbed online doesn’t support it and we unfortunately still have some people using that.
To be honest though, I think assembly is difficult to maintain, so I’d rather avoid it.
lcdTile
would only be an improvement for the scaled up parts because it accepts a pointer to raw colour data, not palette indices.
You could theoretically incorporate some of the contents of lcdTile
so that directBitmap
ends up using setWindow
, write_command
, write_data
etc.
If scale
wasn’t there then that might be the better option,
but the scale
parameter complicates matters.
Either way, my intent was to just clean the code up a bit, not completely overhaul it.
Scale would just mean spitting out the same value twice and putting a loop to repeat the last row
Using set window command would still benefit in speed since the display input has less load over direct pixel
I think this desperately needs an overhaul cuz it’s rather slow and therefore it’s not used much
Feel free to step in and rewrite the code to use setWindow
& co.
I don’t mind scrapping the change I was going to make, it didn’t take me that long to write.