Started to write 220x176x16 color support with directBitmap to test @VonBednar 's roguelike graphics only to find I had already done it in hardware at some stage (missing from simulator still)
This gives you an idea, however, that if you do want to waste your memory on flashy graphics, its possible
@jonne is the version of directBitmap in the simulator working now?
Can you explain something more about this “direct” mode?
Can be use to generate high resolution tileset at 16 colors for backgrounds? And then draw over some action?
Yes, my game is using direct pixels to show 16 colours at high resolution. Technically you can show as many colours as you want as there is no frame buffer to hold you back.
Although there might be speed issues as you have to draw each pixel individually (x,y,colour) rather than transferring the entire buffer in one go.
Which brings us to the optimization thing. directPixel works by going into lcd command mode, addressing and then going into data mode and sending the pixel. The GRAM pointer of the LCD is automatically incremented, meaning if you know the next pixel value, you could draw the next one without going through the command/data mode switch and the addressing.
We will get to this soon, I promise. Now that I have the loader working, I feel I could use abit of time to push this ahead a bit as well
Thanks @spinal and @jonne.
Is there any difference in calling directBitmap instead of drawBitmap ?
The same code works with drawBitmap but not with directBitmap.
Also transparent color (setInvisibleColor) seems not supported?