DD still doesn't work under Z26. I think Thomas (or maybe Eckhard) posted
the solution earlier.
Cheers
A
-
Andrew Davie, TwoHeaded Software
adavie@xxxxxxxxxxxxx
----- Original Message -----
From: "Glenn Saunders" <cybpunks2@xxxxxxxxxxxxx>
To: <stella@xxxxxxxxxxx>
Sent: Monday, October 22, 2001 5:17 PM
Subject: [stella] DD build 8
> Okay, I succeeded in implementing Thomas' sprite logic routine into Death
> Derby. (I also threw in the VDEL code from Roger's recent post).
>
> More of an achievement as far as original code goes was getting the sprite
> rotation system working. For someone new to assembly language, it's
pretty
> exciting seeing your new original code actually work, even if it's a
> trivial thing. I've got the code that determines wether or not to do the
> hardware sprite flip, and the data laid out pointing to all the different
> frames in a complete rotation, and it worked. Although in this demo the
> cars are just statically pointing towards eachother, they are both using
> the same frame of animation, with the flip turned-on on the right. So I
> could write a routine that increments a simple counter 0-15 and get the
> cars to smoothly rotate around clockwise, using only 9 frames of data.
>
> I thought about using different types of car shapes but it was so hard to
> maintain the image in the rotations that I'm sticking to one set for now.
>
> I also changed some colors around. P0 has to be a different color from
P1,
> and the missiles will share the same colors as their players. The PF can
> be white or grey on the black background. Maybe in the end I'll do a
> missile command/centipede sort of thing and remap the palette into
> psychadelic colors if the game winds up having waves. I always liked that
> style of color usage so common in the early days.
>
> The problem I have now is that the horizontal positioning routine I
> borrowed from Gunfight is not working properly. I don't know what I'm
> doing wrong with it. Manual, could you check it?? The players move in
big
> jumps when I change their start positions and if I make the players cross
> the screen flips out.
>
> I thought about using the recently posted table method, but I was too lazy
> to try to convert the code over. I also don't know what I'm up to so far
> in actual ROM usage so it might be a bad idea to use the table method if
> the game's going to only be 4K.
>
> Also, I had a question about HMOVE lines. It looks like I'm going to have
> to have HMOVE on either every line, or every other line, depending on the
Y
> position of M0 and M1. Every other if they are on the same line of the
> line-pair, and every line if they are on even/odd lines. This is going to
> wind up wiping out the leftmost part of the safezone border line. If I
set
> the ball priority above PF0 and PF1 couldn't I repaint it using the
> ball? And then I could just keep M0 to the right of the HMOVE lines
hidden
> in black, correct? The HMOVE lines are narrow enough, I hope, to keep M0
> from being affected by them.
>
>
> 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/
