As they say, two steps forward, one step back.
After many hours of work today, I have working driving controller
rotation-handling code in Death Derby!
I guess this marks the first occasion of working driving controller code in
a public Stellalist project. I hope everyone has fun looking at the
source. Feel free to use it in your own games, although it could probably
be optimized.
The way it works is I have a two tables in ROM representing the bit
sequence for rotating right and rotating left. I then find the matching
value for the last state of the controller port in each and if the
following value in the table matches the current state of the controller
port, then that indicates either an increment (rotate right) or decrement
(rotate left) of the car. If there has been no change, or if it finds no
match against both tables, it will just exit out.
The drivng controller changes state 16 times in a full rotation, which
matches perfectly the default 16 (well 15 unique) angles that are typical
of 2600 rotation sequences. Any more and it's impossible to resolve the
shape in an 8x8 square.
What I have noticed here and in Indy 500 is if you bang on the knob hard
enough to twist it abruptly, you will unfortunately trigger a change of
more than one step in less than 1/60th of a second. When this happens it's
impossible for this routine to determine the direction of travel. It's
only possible for this routine to guess direction if it's fast enough to
detect every individual change around the wheel without gaps.
In normal play this shouldn't be a problem, but if you attempted to play
the game the way one plays Tempest, for instance, spinning the thing like a
top, forget it.
I'm assuming that the way I'm reading the controllers is similar to how
Indy500 does it, but Indy500 is probably much more optimized.
I did collapse this routine and the one that sets up the pointers for the
sprite display logic so that I can pass in a 0 or 1 to do it for P0 or P1,
so that helped eliminate most of the code duplication.
Luckily even when you do a generic "declare space" in DASM, it allocates
the RAM variables in the order you declare them, so you can align your P0
variables right next to your P1 variables which makes it really easy to
create general subroutines where all variables are X indexed by 0 or 1.
Now the bad news.
I noticed that the sprite scanout routine is broken and I never even
noticed it until now!
For one thing, it's showing one scanline too few of data for P1.
Also, when I set the starting Y positions of P0 and P1 to different values,
neither displays at all.
When I comment out either the P1Loop or P0Loop code, it makes the other
sprite not show up. I have no idea why the code for one is so dependent on
the other.
So I'm definitely stuck there in need of some assistance, please? ;)
Glenn Saunders - Producer - Cyberpunks Entertainment
Personal homepage: http://www.geocities.com/Hollywood/1698
Cyberpunks Entertainment: http://cyberpunks.uni.cc
Attachment:
dd_controllers.zip
Description: Zip archive