For my game I'm working backwards a little, focusing on the desired look
and the design rather than the code...
Here is a mockup screenshot I did:
http://www.gamedevelopers.net/deathderby/images/screen1_color2.gif
I generated all the sprite shapes already, using PaintShop Pro. I tried to
make sure all the alignment and sizing of the pixels makes it "feasible" on
the 2600. The pedestrians are to be made from repositioned and rescaled
(single, double, or quad) missiles which is why they share the same color
as their players. You'll notice that never do you see two separated pixels
on the same horizontal with the pedestrians. Even with these limitations
you can generate some convincing shapes. I have a few different characters
I came up with.
I'll be putting a development diary page up with these images soon.
In this screenshot the tombstones are as tall as the pedestrians, which
doesn't necessarily have to be that way, but if I don't alow them to
vertically overlap (in this mockup they can) but rather "quantize" their
positions then I can cut the RAM requirements in half.
I might also be able to go with single-line height on the
missile-pedestrians, which would make them more squashed-looking but
otherwise more in scale compared to the cars and then they would be closer
in size to a single rather than a double height tombstone.
You can compare this to the only Death Race screenshot I've seen on the net
(unfortunately it's croped on the right):
http://www.gamedevelopers.net/deathderby/images/DEATHRACESCREEN.GIF
I omitted the timer in the center in favor of an invisible timer (ala
Combat) that will flash the score when time is close to running out.
I can not tell if the boundary lines are dotted or not. I think this game
is going to show up at California Extreme and I hope to attend that
convention and get some photos/video.
The idea is to follow the 1st generation Atari game conventions with the
2-digit playfield scoring system color-coded left/right and to have lots of
game variations that modify the rules of the world.
As for the code itself, I do have some very rudimentary playfield code but
it's not running perfectly right now so I want to have one more go at it
before I post it to the list for criticism.
The big question, which remains unanswered, is whether I'll have enough
time to scan out the 4 bytes of playfield and load all 4 sprite registers
(including potentially two fine control adjustments and two width
adjustments on the missiles) on the same scanline. Going with double-line
height on these objects should help, but I just don't know if it's possible.
If it can't be done without flicker then I don't want to do the game at
all, as this is primarily an exercise to utilize the missile objects to
show that they can be used as substitute player sprites--to avoid flicker.
In a worst case scenario I'm willing to resort to Starpath RAM in order to
eliminate most of the branching logic in the kernel. The entire screen,
every row, could be stored in RAM, and all the sprite shape data and
missile positioning/sizing data could be stored in separate lists of RAM as
the player missile graphics on the Atari 8-bit works. That way I'd only
have to increment the scanline counter and fetch from Starpath RAM (which
unfortunately is slower than regular RAM). Then I'd byte-move the sprite
data up and down during vblank to perform vertical motion.
Comments welcome.
Glenn Saunders - Producer - Cyberpunks Entertainment
Personal homepage: http://www.geocities.com/Hollywood/1698
Cyberpunks Entertainment: http://cyberpunks.uni.cc
-
Archives (includes files) at http://www.biglist.com/lists/stella/archives/
Unsub & more at http://www.biglist.com/lists/stella/
