Jump to content
  • entries
    40
  • comments
    39
  • views
    28,052

CiE stable drawing kernel for tiles

Sign in to follow this  
brpocock

360 views

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.

Sign in to follow this  


3 Comments


Recommended Comments

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.

 

which also means redesigning some stuff for you... I'll get started on it tomorrow, no chance for me to do it tonight I'm afraid. :)

Share this comment


Link to comment

Not sure if this is for the Atari 2600? However, if you post the source code I'm sure that someone round here will suggest some optimisations and may be able to get it back to 2LK.

 

Chrs

Share this comment


Link to comment
Not sure if this is for the Atari 2600? However, if you post the source code I'm sure that someone round here will suggest some optimisations and may be able to get it back to 2LK.

 

It's the tile lookups, I'm afraid. But really, the 3lk look is growing on me because it fills the screen more nicely. 8x8 tiles of 16 clocks by 24 scanlines treated as an 8x8 pixels region... means I have 4 clocks by 3 scanlines pixels...

 

The player and decorations are still 2lk.

 

The little demo I just posted the binary for is also 3,097 lines of code (excluding comments and commented-out code sections but including less than a page of graphics used in the demo)... I'll impose the gnarled nastiness of a fully unrolled kernel on the world only after I give up on it :)

Share this comment


Link to comment
Guest
Add a comment...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...