Games that use directBitmap?

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.

1 Like

slime is using directBitmap

1 Like

Thanks @spinal and @adekto, I’ll test these tomorrow.

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.


* Single static assignment form and jump threading.

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.

1 Like