The Upward Spiral - tech details; reduced expectations

RSS Bot · August 17, 2007

For what it's worth, some tech notes as it stands today:

Tiles don't flicker. Sprites do -- horribly, right now -- I hope to reduce it with a sort of drawing list system if I can optimize it into the kernel.

To free up cycles, there are venetian blinds :-(

Background tile maps are 8×6 tiles, each of which is 4×8 background pixels, each of which is 2|3 scanlines tall. Two scanlines draw, the third doesn't.

Sprites are the same size as background tiles but are 8×12 px using 2 scaline height pixels.

One playfield colour per row :-( Might get it up to 2 but nowhere close to the 6 I'd once thought possible (but never thought likely)

One background colour per screen. Stats area always has black background.

Border around map area. PF0 always zeroed.

Sprites have HMOVE bars and there are HMOVE bars on rows without sprites in some of the drawing list attempts. Sometimes I just go nuts and have nothing BUT HMOVE bars during the map drawing.

Stats screen has an overview map generated automatically. If the map item is found for a level, it displays.

To fix: one level per memory bank. Should support multiples but aforementioned overview maps broke that functionality until I fix it. That's a Perl problem really, but also will need some logic in the stats/inventory subscreen.

8 keys per level. Various items, some with "ammo." No magic system, but there is a fashion system. (Yes, really.)

For now, hardcoded background tile images into mkmap compiler. Future direction, split them out and allow more flexibilitiy.

Missiles and ball totally unused. Thoughts about using ball for doors but never tried implementing yet due to madness of cycle counts.

Using sta WSYNC still but believe it unecessary once sprite code stabilises.

Math is not my friend. Data structures for artwork are interleaved and inverted, e.g.

	align 256,0

tile_bitmaps:
tile_bitmaps_odd:
;;; line 7
o7_box_left___blank:	dc.b 128
o7_box_left___box_u_left:	dc.b 143
o7_solid___solid:	dc.b 255
o7_solid___half_round_left:	dc.b 243
o7_solid___blank:	dc.b 240
o7_brick_wall___brick_wall_right:	dc.b 255
o7_half_round_left___half_round_right:	dc.b 60
o7_blank___blank:	dc.b 0
o7_box_bottom_left___box_bottom:	dc.b 255
o7_box_top___box_top:	dc.b 0
o7_box_bottom___box_bottom:	dc.b 255
o7_box_top_left___box_top:	dc.b 128
o7_brick_wall_left___brick_wall:	dc.b 255
o7_brick_wall_right___blank:	dc.b 240
;;; line 6
o6_box_left___blank:	dc.b 128
o6_box_left___box_u_left:	dc.b 136
o6_solid___solid:	dc.b 255
o6_solid___half_round_left:	dc.b 247

That's from the test kernel whose screenshot I posted earlier tonight.

Headaches: Doing what I'd like to for (mostly) flicker-free sprites costs too many kernel cycles or sucks down more RAM than available.

Absent: MemCard support (lost my demo unit in the fire, sadly) or any other continue mechanism. That's a pain in the ass given the scale of the game.

Ursa script interpreter still has braindead errors that I keep finding that cause it to do things like wild jumps sometimes. Working on that.

None of current stuff tested on real hardware. Stella only stuff right now. That will probably introduce new problems with numbers of lines but I think that's the worst to worry about.

http://www.atariage.com/forums/index.php?a...;showentry=3718