The Upward Spiral - timings and map tile cursor

[RSS Bot]

Timings on the first row are perfect, and the HMP0/1 bugs are basically flushed out finally, so that's all good. There's still some crap involving line (7,2) on each row, but there should be sufficient SLEEP cycles now that I don't use WSYNC to make up for it. A new bug that crept in somewhere there, though, is that the cursor pointing into the map data seems to be drifting.

 

Here's the lowdown. There's a big macro that draws a line. Lines are grouped into triples, and odds & evens. So, the main drawing loop for one row then just calls that macro 24 times:

CODE

row_start:

DRAW_LINE(0,0,0) ; Triplet 0, first line, this line is even

DRAW_LINE(0,1,1)

DRAW_LINE(0,2,0) ; Triplet 0, third line, this line is even

DRAW_LINE(1,0,1)

DRAW_LINE(1,1,0)

...

DRAW_LINE(7,2,0)

 

OK, so far so good, right? Line (7,2) -- which currently bears the lovely debugger breakpoint convenience label of "seven2" -- is a "no draw" line which prepares for the next row. So, really, I'm drawing 23 lines.

 

Depending on which line I'm on, I precache various data like the tile pointers for the next row or the bitmaps for the next line triplet. Even and odd lines alternate updating decorative tiles (P1) or the player (P0) as appropriate. There are tile ID pointers in RAM for "this row" and "next row" (copied over in (7,2) after being decoded during the row), and the triplets precache bitmap data for the next triplet, and alternate between an "odd triplet#" and "even triplet#" bitmap buffer for drawing PF1/2 left/right. (e.g. during line triplet 1 I precache the bitmaps into the "even" buffer while drawing from the "odd," then in line 2, precache "odd" while drawing "even").

 

During this maddening mass of multiply-indirect lookups, I have to hit PF2 exactly at the middle of every scanline and HMOVE exactly at the end. (I can't spare any screen lines to use RESP1 to position decorative tiles -- other than the top row -- so I have to use HMP1 to move the P1 position if there's a decorative tile on a lower line not in the same column.)

 

The important thing I have working, now, is that the PF2 and HMOVE always hit at the right time. It's a tiny thing to have no HMOVE bars, and in fact, I'd probably be just as happy to have them all the way down, but once you're into that kind of cycle-exact timing mess to do reflected asymmetric playfield, you might as well go full monty.

 

"seven2" however is not always exiting at precisely the right cycle. Also, I advance the pointer into the map at various times in the loop, basically every time I pull a tile ID out of the map I "inc" the map cursor, and at the end of a row I have to skip over some colour and decorative tile data to start the next row. Well, somehow in all that mess, I'm getting the map cursor off by one (and I haven't looked at it closely enough to figure out just how), so it'll start pulling colour data in as though it were tile ID's, thus looking up garbage data in ROM instead of valid bitmaps, and likewise getting decorative tile bitmap pointers instead of colours, and so on. Basically the whole "wild pointers are bad" "well, no shit" story.

 

So, that's the last real hold-up on the tile-draw, although i've got an open "RFE" to try the cleaner (pixel-based rather than tile-plus-pixel-offset based) joystick code out and see if it's reliable. I expect it actually will be.

 

Combat kernel is due for some pretty significant overhauls and then the connections between them all have to be stitched back in. The next time I test on the hardware I should be seeing the pieces working together. A public alpha test is not far in the future.

 

Given the amount of time I'm actually hacking on this, though (a couple of hours a week... I spend more time in the forums here probably, at 10 minutes a spell) "not far in the future" probably means early August for a real playable demo with all the major pieces intact. Some of that depends on Mayday's equally mad schedule, though. It would help to have some map data or graphics or scripts to all this

 

And, to that end, I need to write a new map coimpiler to handle the changes I made going to the "24lk" format.

 

Kernel size has actually grown a bit from the timing fixups, but there are a lot of NOP's that I can probably compress some work from (7,2) into them now. If so, I may even be able to update some of the graphics during (7,2) as well. It does annoy me to have "dead lines" all over the screen, even if they should blend in with the background nicely in the real world, I guess.

 

http://www.atariage.com/forums/index.php?a...&showentry=1577