Since there is a limited amount of RAM available for the display, I thought it might be a good idea to develop a special display mode based on tiles and sprites like the old 8-bit and 16-bit consoles. To avoid having to store a framebuffer in RAM, a background layer could be stored as a character array and then a list of sprites. When pushing an update to the LCD, each scanline would be generated on the fly based on which tiles and sprites appear on that line.
There are lots of interesting possibilities with a mode like this and the full display resolution and colour depth could be used. Potentially there could be palettes allocated for tiles / sprites for special palette effects like recolouring sprites or tiles.
A good API might also make it easier for beginners who want to make retro style games to emulate the look of old 8-bit / 16-bit hardware.
neat idea but generally has its own limitation in how many sprites can be on the same scanline
also you have to check every sprites bounds every scanline slowing down the process.
we are looking at some hardware solutions like using the screens DRAM as a double buffer
I didn’t see that thread before I posted but having all that extra available display RAM sounds like a big win. It could still be beneficial to write out scan lines on the fly to avoid overdraw if writing out to the display RAM is relatively slow.
I haven’t got a Pokitto yet so all of this is just speculation
@jhhoward Lets collaborate on this. I am very familiar with tilemodes. You seem to know how they work.
Basically its a combination of tiles and a array, that specifies a palette index for those tiles. Thats exactly how it is organized in Gameboy roms etc.
I had a quick look through the display spec sheet and the current Pokitto display code. I didn’t realise before that the display was originally designed to be used in portrait ratio instead of landscape. I see that the display code simply swaps the X and Y when it sends commands to the display hardware. However it looks like there is are commands to specify orientation, so it should still be possible to supply horizontal scan lines.
It should be fairly straightforward to extend the current LCD code to draw a single line on the display, and then write a separate bit of code for rendering each line based on a set of tiles / sprites
Before you do that: naturally, I tried to change the LCD to horizontal operation myself, when I started. However, in horizontal mode, a weird glitch appeared: when drawing horizontally, the DRAM was not always updating correctly on some displays. What happened is the last 2-4 bytes of DRAM were appearing at logical coordinates 0,0 (top left corner) instead of right bottom. The DRAM was offset.
What was the reason for this, I do not know.
Before you use a lot of effort to turn the display, it really makes no difference which way around you draw the screen. That part of the operation is and should remain away from normal use.
That’s a shame. It almost sounds like the DRAM address pointer was wrapping itself round to zero or something.
Nothing to stop us making a tiled mode with vertical scan line updates instead. I was hoping to have horizontal scan lines to allow the ‘genie’ effect that you see in some old games where the scroll register was changed on the HBLANK interrupt to shear the screen.
This is why I wanted you to know about it before you began coding. We are now using a different manufacturer (same IC though), perhaps horizontal mode works in them. You can try.
