How would I go about programming for the driving controller?

[+atari2600land]

OK, so I have an idea. (What else is new? ): make a game for the driving controller. That's it. I don't have a game idea to go along with it, but I would at least like to make a simple test using it. So my question is, I know it's possible to do (Granny's Revenge), but my question is how? Is it just like programming for the paddle controller only since it has 360 degree movement, you, um... And, also, would I use readpaddle for the driving controller? I tried to do research for this (searched for "driving controller" in this forum), but nothing really led to how.

[CurtisP]

OK, so I have an idea. (What else is new? ): make a game for the driving controller. That's it. I don't have a game idea to go along with it, but I would at least like to make a simple test using it. So my question is, I know it's possible to do (Granny's Revenge), but my question is how? Is it just like programming for the paddle controller only since it has 360 degree movement, you, um... And, also, would I use readpaddle for the driving controller? I tried to do research for this (searched for "driving controller" in this forum), but nothing really led to how.

 

The Driving Controller does not work like a paddle at all. It actually generates a binary gray code. You would need a specialized ASM read routine to read it.

[Impaler_26]

Have a look at the source code of zombie chase (included with bB in the "samples" folder), it works with a joystick or the driving controller.

[+atari2600land]

I have a math question. (I never was any good at it.) Suppose I want to make a number from 0-40 the opposite of a number (i.e. if one number was 10, have the other be 30, etc.) What would be an equation that would do this for me? In this game I'm making, in the code, the variable would be "d".

unnamed.bas

[Omegamatrix]

I have a math question. (I never was any good at it.) Suppose I want to make a number from 0-40 the opposite of a number (i.e. if one number was 10, have the other be 30, etc.) What would be an equation that would do this for me?

 

 

What do you mean opposite? In the example in your quote you look like you are simply subtracting. So 40-10 = 30.

[+atari2600land]

Yes, but what about 11 and 29, 12 and 28, etc.?

[+Random Terrain]

Suppose I want to make a number from 0-40 the opposite of a number (i.e. if one number was 10, have the other be 30, etc.)

Maybe if you made a list of every opposite pair that you know is correct, the solution would be clearer to yourself and others.

[GroovyBee]

Yes, but what about 11 and 29, 12 and 28, etc.?

 

40-10=30

40-11=29

40-12=28

 

A pattern is forming .

[+atari2600land]

Well, what do I do? The only solution I see is to make a list of all of them in the code and then do what an opposite pair would be:

if d=40 then f=0

if d=39 then f=1

etc.

 

I know there's a better way to do this, but I just can't figure it out. Sorry if I'm stupid enough to not figure it out...

[+atari2600land]

OK, I figured it out.

[+atari2600land]

But I still haven't figured out how to control the driving controller part. I looked through the Zombie game and it (of course) made no sense at all. I guess it only makes sense if I program it (which in turn makes no sense to anyone else.) Anyway, would joy0left and joy0right control a driving game, or what? I don't know what to call to turn the driving controller left or right.

[+Random Terrain]

(which in turn makes no sense to anyone else.)

Another good reason to pack our programs full of REM statements. Then other people and our future selves will be able to figure out what is going on.

[RevEng]

But I still haven't figured out how to control the driving controller part. I looked through the Zombie game and it (of course) made no sense at all. I guess it only makes sense if I program it (which in turn makes no sense to anyone else.) Anyway, would joy0left and joy0right control a driving game, or what? I don't know what to call to turn the driving controller left or right.

The basic idea is that you read the present position of the controller, and compare it to the last remembered position, to see if the controller is being turned left or right.

 

Here's the relevant code from zombie chase, with some added comments....

 

driving 
rem ** read the position of the driving controller and scale it down to between 0-3
temp1=SWCHA & 110000
temp1=temp1/16

rem ** based on the last position of the driving controller...
on last goto d00 d01 d10 d11

rem ** ...we check to see if the controller moved left, right, or not at all.
d00
on temp1 goto nomove left right nomove
d01
on temp1 goto right nomove nomove left
d11
on temp1 goto nomove right left nomove
d10
on temp1 goto left nomove nomove right

left 
rem ** the controller turned left. Adjust the car sprite/angle. (carpos)
carpos=carpos-1:gamebits{0}=1
goto nomove

right 
rem ** the controller turned right. Adjust the car sprite/angle. (carpos)
carpos=carpos+1:gamebits{0}=1

nomove
rem ** remember the controller position for next frame
last=temp1
nodriving
rem ** if the car sprite/angle is 16, make it 0. if the car sprite/angle is -1, make it 15.
carpos=carpos & 15

Edited December 27, 2010 by RevEng

[potatohead]

You can also know, if you missed a change, and by how much!

 

The grey code output changes only one bit in the value returned to the controller at a time. Think of it as a list. There are 8 values in the list, and the current one is somewhere in the list. If it's the next value, either to the left, or right, nothing was missed. On the other hand, if it's a few values away, you can know the controller was turned really fast too, and do something with that, if you want to.

[BigO]

You can also know, if you missed a change, and by how much!

 

The grey code output changes only one bit in the value returned to the controller at a time. Think of it as a list. There are 8 values in the list, and the current one is somewhere in the list. If it's the next value, either to the left, or right, nothing was missed. On the other hand, if it's a few values away, you can know the controller was turned really fast too, and do something with that, if you want to.

(The driving controller is a 2 bit encoder, so there are four values in the list)

 

 

 00
01  10
 11

Edited December 27, 2010 by BigO

[potatohead]

Thanks! For some reason, I was confusing number of positions and the bits. It's 45 degrees per bit change right?

[BigO]

Thanks! For some reason, I was confusing number of positions and the bits. It's 45 degrees per bit change right?

 

As I recall/reason:

There are 4 rotating contacts on the driving controller which create one full Gray code cycle each as they pass through the one set of two stationary contacts.

So, for every 1/4 turn, there are 4 state changes: 16 state changes per full rotation. 360/16=22.5 degrees per bit change.

Edited December 27, 2010 by BigO

[+atari2600land]

Is "SWCHA" what is used to test the driving controller input? I've never seen that in a bB game before.

 

[potatohead]

Thanks! That's a good refresher. I plan on working with the driving ones a bit later next year.

 

Sorry OP. Hopefully, this little side discussion helps.

[RevEng]

Is "SWCHA" what is used to test the driving controller input? I've never seen that in a bB game before.

Correct.

 

You haven't seen it before because you've dealt with joystick or paddle games. Working with alternative controllers - driving controllers, keypads, 2 button controllers - in bB means you need to hit the hardware registers directly.