CiE stable drawing kernel for tiles
It's been a long time a-coming but something "clicked" in my head Friday and I managed to get the above entry (lovely grid pattern that's stable) drawing. The idiots at the cable company have somehow managed to fry my connection at the moment, so I may have to burn a CD-R and sneakernet it to a Panera to get anything uploaded.
The biggest fallout is that I've gone from a "2lk" format for the tile artwork (as shown in the yellow photo) to a "3lk" format for the playfield, with a "2lk" format on the sprite overlays (not shown). Moving around a few details, that makes fora 24-scanline-tall row. I might be able to afford one extra branch-and-test after the 12th row to reduce the ROM footprint. I'm also contemplating the evil but fun option of splitting the kernel between ROM banks: i.e. having the ROM data for different parts of the map in different banks with a bank switch occuring within the kernel itself. It'd save a lot of ROM, and is just nutty enough that it might work.
The ill-defined concept would go something like this: the tile maps (which tile art goes on which spaces on the display) and the tile bitmaps for the upper 12 scanlines (4 logical lines) are stored in bank (n), with the kernel code to draw the upper 12 scanlines. After the 12th scanline, though, the kernel does a bankswitch and continues the 13th line (line 12) in bank (n+1) where we have the bitmap data for the lower halves (4 logical lines) of each tile.
The breakthrough that made this possible? Pre-OR'ing tiles. The compiler now handles arranging every used combination of tiles in advance. More work for the PC compiling the game... less work in realtime. And, not a bad overall impact on slated ROM sizes.
Travel test kernels for your viewing pleasure coming shortly.
PS: the screenshow appears below not above on this blog format. Or just click on Saturday's date on the calendar. It's totally unimpressive.

3 Comments
Recommended Comments