How do I slow down a game for testing?

[+Random Terrain]

We are going to be able to do some cool stuff with batari Basic because the result is fast! I tried using a bunch of for-next loops in a row to try to slow the test program down, but it's still lightning fast. How do you slow the game down for testing? Say you want to have the program wait for one or two seconds after pressing down on the joystick, how would you do that?

 

Thanks.

[potatohead]

We are going to be able to do some cool stuff with batari Basic because the result is fast! I tried using a bunch of for-next loops in a row to try to slow the test program down, but it's still lightning fast. How do you slow the game down for testing? Say you want to have the program wait for one or two seconds after pressing down on the joystick, how would you do that?

 

Thanks.

907803[/snapback]

 

I use delay counters, but not how you would think. The for-next loops you inserted really just consume inbetween frame time. Since your game still runs, you didn't consume enough to break anything. Remember the difference between this basic and an old 8bit basic is that the program runs every 60th of a second. If you take longer than that, in your gamecode, you won't get enough frames to display a stable picture.

 

One good way to see everything happen slowly is to use what I call a skip counter. The program has to loop 60 times per second, but it does not have to do everything each time. That's the key to getting a nice slowdown. You set a counter and decrement it once each frame. When it hits zero, you do everything, if it's not zero then you jump over all your game code. That way, the picture still gets drawn every 60th of a second, but your game only runs on specific frames. The end result is a slower game with a stable picture.

 

Try something like this:

 

(Set the delay where you set other things at the start of your game)

delay = 10

 

 

gameloop

 

(This is where you set your player positions, etc...)

 

drawscreen

 

(Your game code lies after the drawscreen for the most part)

 

delay = delay - 1

if delay <> 0 then goto skipaction

if delay = 0 then delay = 10

 

(your game code goes here and only gets executed every 10 frames)

(nice and slow, try smaller numbers for faster, bigger ones for slower)

 

skipaction

goto gameloop

[+Random Terrain]

Try something like this . . .

907820[/snapback]

Oh duh. Now I get it! Thanks.

 

I just tried a variation on what you posted and it worked great. Here's what I did:

 

(Set the delay where you set other things at the start of your game)

 delay = 0

 

 

gameloop

 

(This is where you set your player positions, etc...)

 

drawscreen

 

 delay = delay + 1

 if delay < 60 then gameloop

 delay = 0

 

(game code goes here)

 

 goto gameloop

 

 

 

 

It goes tick, tick, tick just like you would expect. Thanks for the help. I wouldn't have figured it out on my own.

Edited August 9, 2005 by Random Terrain

[SeaGtGruff]

We are going to be able to do some cool stuff with batari Basic because the result is fast! I tried using a bunch of for-next loops in a row to try to slow the test program down, but it's still lightning fast. How do you slow the game down for testing? Say you want to have the program wait for one or two seconds after pressing down on the joystick, how would you do that?

 

Thanks.

907803[/snapback]

 

I use delay counters, but not how you would think. The for-next loops you inserted really just consume inbetween frame time. Since your game still runs, you didn't consume enough to break anything. Remember the difference between this basic and an old 8bit basic is that the program runs every 60th of a second. If you take longer than that, in your gamecode, you won't get enough frames to display a stable picture.

 

One good way to see everything happen slowly is to use what I call a skip counter. The program has to loop 60 times per second, but it does not have to do everything each time. That's the key to getting a nice slowdown. You set a counter and decrement it once each frame. When it hits zero, you do everything, if it's not zero then you jump over all your game code. That way, the picture still gets drawn every 60th of a second, but your game only runs on specific frames. The end result is a slower game with a stable picture.

 

Try something like this:

 

(Set the delay where you set other things at the start of your game)

delay = 10

 

 

gameloop

 

(This is where you set your player positions, etc...)

 

drawscreen

 

(Your game code lies after the drawscreen for the most part)

 

delay = delay - 1

if delay <> 0 then goto skipaction

if delay = 0 then delay = 10

 

(your game code goes here and only gets executed every 10 frames)

(nice and slow, try smaller numbers for faster, bigger ones for slower)

 

skipaction

goto gameloop

907820[/snapback]

 

I just wanted to add a comment here. As most of us probably know, one of the biggest challenges in programming the Atari 2600 (besides the tiny amount of RAM and ROM) is being able to do everything we want during the vertical blank. One way to get around that is to split up the tasks so that different things get done during different vertical blank intervals. For example, if your game logic takes up about three times as long as a VBI, then you could divide it up into three or more sections, such as (1) reading and processing the controllers, (2) moving the sprites and processing the collisions, (3) updating the score and doing other remaining tasks. Then you could do the group (1) tasks during the first VBI, do the group (2) tasks during the second VBI, and do the group (3) tasks during the third VBI. After all, if you're going to be skipping VBIs anyway just so your game doesn't run too fast, then you might as well split up your tasks so you don't have to worry about exceeding the length of a single VBI!

 

Michael Rideout

[supercat]

After all, if you're going to be skipping VBIs anyway just so your game doesn't run too fast, then you might as well split up your tasks so you don't have to worry about exceeding the length of a single VBI!

908004[/snapback]

 

This comment applies double if the game is going to be using flicker. If you'll be using 30hz flicker, there's probably no reason not to split the VBI stuff in half.