[stella] DD Driving Controller Routines (works)

Subject: [stella] DD Driving Controller Routines (works)
From: Glenn Saunders <cybpunks2@xxxxxxxxxxxxx>
Date: Sun, 28 Oct 2001 22:36:48 -0800
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

Current Thread