bB questions..

[SeaGtGruff]

   a = a + 1
  if a < 4 then goto continuewithloop
  a = 0

In an actual game, some sort of "debounce" routine would be better. Right now I won't try to explain what I mean by that, but in the meantime you can speed up the frame-counting logic by changing the if to use a smaller number.

 

Does that not make no sense?

 

1. If a = a +1 then a would equal 1.

2. If a is less than 1 then it skips the whole thing and goes to continuewithloop which redraws the screen then goes to the beginning of loop again (thus never getting to the joystick routine).

3. a will always be less than 1 because you're setting it to 0 again.

No, that original code would work like this:

 

-- a starts out as 0 (before falling into the loop the first time).

-- frame 1, a is incremented to 1, which is less than 4, so it skips the joystick routine.

-- frame 2, a is incremented to 2, which is less than 4, so it skips the joystick routine.

-- frame 3, a is incremented to 3, which is less than 4, so it skips the joystick routine.

-- frame 4, a is incremented to 4, which is not less than 4, so a is reset to 0, then the joystick is read.

-- frame 5, a is incremented to 1, which is less than 4, so it skips the joystick routine.

etc.

 

In other words, the joystick routine is skipped for 3 out of 4 frames, so the joystick is read only every fourth frame.

 

That's a quick and dirty way to try to slow down the joystick, to prevent the cursor from shooting off in a given direction when the joystick is pushed, but it isn't suitable for an actual game. (I was just using that quick and dirty technique for my demo.)

 

The problem with that quick and dirty technique is that if you move the joystick or press fire during one of the frames that the joystick routine is being skipped, and if you release it too quickly, then your joystick input may not "register." But 60 frames = 1 second, so 4 frames = 1/15th of a second, and that should be "fast" enough. It may even be too fast, because what might be happening is that when you press fire, it registers twice before you release the button. On the other hand, moving the cursor should respond okay-- it's more likely to be the fire button that seems flakey.

 

Anyway, a proper sort of "debounce" routine would have a different sort of logic-- maybe something like this (which is simplified):

 

   if a <> 0 then a = a - 1 : goto continuewithloop
  if joy0up then a = 10 : cursory = cursory - 1
  if joy0down then a = 10 : cursory = cursory + 1
  if joy0left then a = 10 : cursorx = cursorx - 1
  if joy0right then a = 10 : cursorx = cursorx + 1
  rem * etc.

With this code, a will be 0 as long as the joystick isn't being moved. But as soon as the joystick is moved, then a is set to 10, and the joystick movement is processed. Then a starts counting down, and as long as it hasn't reached 0 yet, the joystick will be skipped over during subsequent frames-- until a reaches 0 again, at which time the joystick can be read again.

 

A better, less simplified routine would remember what the last joystick action was, and would ignore the debounce counter if the new action were different than the previous action. That way, if you push the stick left and keep it pressed left, the cursor will move left, but will do so at a reasonable rate (i.e., it won't shoot off to the left and move further than you'd intended)-- but if you push in a different direction, it will react immediately to the new direction.

 

This may be a little bit difficult to grasp if you aren't somewhat familiar with the concept of "debounce," which usually refers to reading a keyboard, but also applies to other input devices. To appreciate what the issue is, take out the preceding code and just read the joystick each frame, and then try to move the cursor 1 and only 1 block in a given direction. Chances are you'll end up moving at least 2 or 3 blocks, even if you just barely tap the joystick, because the joystick is being read and processed faster than you can tap the stick and then let go. The idea is to introduce some way to slow things down, but in a manner that lets the system respond to new events right away, without responding to a single event too many times too quickly. For example, if computers didn't use a keyboard debounce, then each time you tried to type a single letter you'd probably get several copies of the letter, as if you'd kept the key held down a bit, since the computer is reading the keyboard faster than you can type a letter and then let up on the key.

 

Michael

[Gorf]

Now if only I can get Fred(batari) or Micheal(SG) to help me with my custom kernal.

It will be for a game EVERYONE will want for the 2600. An Atari classic

once attempted but failing miserably, I think I have a better approach.

 

 

Fred has already seen it and agrees, I'd love to show it to you too Micheal.

Just PM me with your e-mail address and I'll send you a build of what I have.

 

 

I would also like to RE-DO Gorf classic forthe 2600 someday.

Edited September 11, 2007 by Gorf

[yuppicide]

No, that original code would work like this:

 

-- a starts out as 0 (before falling into the loop the first time).

-- frame 1, a is incremented to 1, which is less than 4, so it skips the joystick routine.

-- frame 2, a is incremented to 2, which is less than 4, so it skips the joystick routine.

-- frame 3, a is incremented to 3, which is less than 4, so it skips the joystick routine.

-- frame 4, a is incremented to 4, which is not less than 4, so a is reset to 0, then the joystick is read.

-- frame 5, a is incremented to 1, which is less than 4, so it skips the joystick routine.

etc.

 

In other words, the joystick routine is skipped for 3 out of 4 frames, so the joystick is read only every fourth frame.

 

Now I understand. I don't know why I couldn't figure that out after reading it over the first 10 times atleast. I'll have to read the rest of this post after dinner. Sorry this week we have a big fashion show at work which is Surf Expo in Orlando, FL so I've been swamped.

[yuppicide]

Just a note that I do intend to pick this back up and give it another try. I just kind of got lost in code there because I'm kind of noob at programming.

[yuppicide]

Progress is made!! Woohoo.

 

The game actually works 100% now and should be ready for sale soon.

 

Right now the game works and has 40 puzzle levels ranging from Beginnger through Expert.

 

The only thing to do is put some "polished touches".

 

Things to add:

 

- Music

 

- Title Screen / Death Screen - I'm going to find someone here to do this for me in exchange for a free game. I figured I should enlist the help of someone else because they can do cool ASM.

 

- Some sort of password system so you can continue

 

The game will be considered a "deluxe edition" which means it'll be in a box, with some surprises.

Edited October 14, 2008 by yuppicide

[yuppicide]

Been awhile since I touched this. With the custom drawscreen routine SeaGt helped me with I am unable to use a PFRES higher. I had a nice title screen made, but can't use it.

 

What I think I'm going to do is just slap a simple title screen on it with music, put some in between level indicator so you know what level you are on, and pop it on cart.