+Random Terrain Posted August 9, 2005 Share Posted August 9, 2005 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. Quote Link to comment Share on other sites More sharing options...
potatohead Posted August 9, 2005 Share Posted August 9, 2005 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 Quote Link to comment Share on other sites More sharing options...
+Random Terrain Posted August 9, 2005 Author Share Posted August 9, 2005 (edited) 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 Quote Link to comment Share on other sites More sharing options...
SeaGtGruff Posted August 10, 2005 Share Posted August 10, 2005 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 Quote Link to comment Share on other sites More sharing options...
supercat Posted August 10, 2005 Share Posted August 10, 2005 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. Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.