Button Behavior

[Brian's Man Cave]

Hey!

 

I am working on a side scroll racing game where I have the side button as the accelerator and the disc to move up or down.

 

But I have noticed that when I hold down the side action button, then I can no longer steer using the disc until I let go of the action button.

 

Is this normal? or am I missing something?

 

if cont = $A0 then  'speed up 
  if hit_car = 0 then
  if #car_speed < 19 then speed = speed + 1
 
  if speed >= 11 then 
   if #car_speed < 19 then #car_speed = #car_speed + 1
   speed = 0
  end if
 end if
end if

 

if cont = $04 then if y > 32 then y = y - 1 'up
if cont = $01 then if y < 72 then y = y + 1 'down

 

[+DZ-Jay]

36 minutes ago, Brian's Man Cave said:

Hey!

 

I am working on a side scroll racing game where I have the side button as the accelerator and the disc to move up or down.

 

But I have noticed that when I hold down the side action button, then I can no longer steer using the disc until I let go of the action button.

 

Is this normal? or am I missing something?

 

if cont = $A0 then  'speed up 
  if hit_car = 0 then
  if #car_speed < 19 then speed = speed + 1
 
  if speed >= 11 then 
   if #car_speed < 19 then #car_speed = #car_speed + 1
   speed = 0
  end if
 end if
end if

 

if cont = $04 then if y > 32 then y = y - 1 'up
if cont = $01 then if y < 72 then y = y + 1 'down

 

You are checking for very specific input values in "cont," which means that either a side button or the disc is allowed at any one time.  The side buttons and the disc could be pressed at the same time, and when that happens the value of "cont" will include both signals.

 

To address this, you will have to mask the bits you want before comparing.  The action buttons each use two of the top three bits of the 8-bit value returned by the controller.  So you can mask them with $E0, which will clear all bits but the top three.

 

The disc uses the lowest four bits, so you can use $0F to mask those bits.

 

This way, when both sets of bits are set, you are isolating each set before comparing them to the values of interest.

 

You can do something like:

if ((cont And $E0) = $A0) then
   ' side button pressed
end if

if ((cont And $0F) = $04) then
   ' disc up
elseif ((cont And $0F) = $01) then
   ' disc down
end if

 

The above is completely untested.  Also, there are quite a few nuances to consider that are not captured here.  For instance, the disc has no notches or ridges or markers, so it's sort of hard for a player to hit precisely on a specific spot out of 16 unmarked ones on the disc.  You may want to consider a wider target area.

 

    dZ.

Edited August 31, 2022 by DZ-Jay

[Brian's Man Cave]

13 hours ago, DZ-Jay said:

You are checking for very specific input values in "cont," which means that either a side button or the disc is allowed at any one time.  The side buttons and the disc could be pressed at the same time, and when that happens the value of "cont" will include both signals.

 

To address this, you will have to mask the bits you want before comparing.  The action buttons each use two of the top three bits of the 8-bit value returned by the controller.  So you can mask them with $E0, which will clear all bits but the top three.

 

The disc uses the lowest four bits, so you can use $0F to mask those bits.

 

This way, when both sets of bits are set, you are isolating each set before comparing them to the values of interest.

 

You can do something like:

if ((cont And $E0) = $A0) then
   ' side button pressed
end if

if ((cont And $0F) = $04) then
   ' disc up
elseif ((cont And $0F) = $01) then
   ' disc down
end if

 

The above is completely untested.  Also, there are quite a few nuances to consider that are not captured here.  For instance, the disc has no notches or ridges or markers, so it's sort of hard for a player to hit precisely on a specific spot out of 16 unmarked ones on the disc.  You may want to consider a wider target area.

 

    dZ.

That works!! I will just need to work on the disc target. Thanks

 

[+DZ-Jay]

I also wanted to say that, unlike what a lot of programmers assume, a good hand-controller decoding scheme is a little more complex than it seems on the surface — especially when you want to account for the real, analog controllers on an original console.

 

For example, masking the upper three bits to test for the action buttons may not be sufficient, because the hand-controller hardware (nor the console’s) does not account for electronics noise, glitches, and even player errors or misuses.

 

If, say, a player presses two keypad keys at the same time, there is no way to disambiguate them — but worse, they may set two of the upper three bits making them look like an action button press when inspected in isolation.

 

There are plenty of other similar cases in which a corrupt or glitchy signal looks like a valid input of interest when isolating certain bits.

 

Unfortunately these are a lot more common (especially on real hardware) than anybody would like.

 

I always invite all programmers that, as they get greater insight into how the hardware works, that they start considering these real world scenarios to make sure their games are as good as they possibly can.

 

Some games have proven definitively that very responsive, intuitive, fluid, and accurate control schemes are possible on an Intellivision disc controller, and it makes playing those games a joy.  It just takes a bit more work.

 

In my own personal opinion, there are very few things worse than glitchy, unresponsive, or sluggish control in a game.  It’s one of the reasons people say they hate the hand controllers (well, apart from the awkward ergonomics).  But that’s like the Indian blaming his arrows for missing the target.

 

My philosophy holds that the distinction between a good game and a great one that lasts through the ages, is just in the little details put into it.

 

(OK, rant’s over.)

 

   dZ.

 

Edited September 1, 2022 by DZ-Jay