+atari2600land Posted October 2, 2008 Share Posted October 2, 2008 How do you get the "scanline" counter above 262 in bB, and how can you prevent this from happening? Quote Link to comment Share on other sites More sharing options...
SeaGtGruff Posted October 2, 2008 Share Posted October 2, 2008 How do you get the "scanline" counter above 262 in bB, and how can you prevent this from happening? That means your "overscan" routine/s is/are too long. The "overscan" is what most Atari programmers call the part of the screen that comes below the game screen, and it's one of two periods when you get to do your stuff between drawing one frame of the screen and drawing the next frame of the screen. The other period when you can do stuff is what most Atari programmers call the "vertical blank" (or "vblank" for short), which is above the game screen. (These usages of the terms are technically wrong, but what the hey.) It sort of looks like the following: draw a frame of the game screen do stuff during the "overscan" do the vertical sync do stuff during the "vblank" draw the next frame of the game screen do stuff during the "overscan" do the vertical sync do stuff during the "vblank" draw the next frame of the game screen do stuff during the "overscan" do the vertical sync do stuff during the "vblank" draw the next frame of the game screen etc. In bB, all of your code normally executes during the "overscan," so you need to be careful that it doesn't take too long to do the stuff you want to do, otherwise the vertical sync doesn't occur when it needs to, causing the screen to have too many lines on it, and it will roll. There are three options for fixing this: (1) Move some of your routines into the "vblank" period, instead of trying to do everything during "overscan." (2) If it's feasible, see if you can divide the routines up so they don't all get performed during the same frame-- i.e., some routines would be performed during one frame, then the remaining routines would be performed during the next frame. (3) Try to tighten up your routines so they take less time, or remove any routines that you might not need to do at all. Michael 1 Quote Link to comment Share on other sites More sharing options...
+Random Terrain Posted October 3, 2008 Share Posted October 3, 2008 (2) If it's feasible, see if you can divide the routines up so they don't all get performed during the same frame-- i.e., some routines would be performed during one frame, then the remaining routines would be performed during the next frame. That sounds like a good idea. How would you do that? Quote Link to comment Share on other sites More sharing options...
+atari2600land Posted October 3, 2008 Author Share Posted October 3, 2008 (1) Move some of your routines into the "vblank" period, instead of trying to do everything during "overscan." When is the "vblank" period in bB (or does it vary by bB program?) Quote Link to comment Share on other sites More sharing options...
+Random Terrain Posted October 3, 2008 Share Posted October 3, 2008 (1) Move some of your routines into the "vblank" period, instead of trying to do everything during "overscan." When is the "vblank" period in bB (or does it vary by bB program?) Does the info on the bB page answer that question? http://www.randomterrain.com/atari-2600-me...nds.html#vblank Normally, bB code runs in overscan. This is the portion of the television screen, roughly 2 milliseconds long, after the visible screen but before the synchronization signals are sent to the television. After this is an area called vertical blank, where the picture is blanked for a couple of milliseconds before the display kernel renders the visible screen. bB runs its kernel setup routines in vertical blank, such as horizontal positioning and setting up the score, and additionally, the multisprite kernel uses this time to determine which virtual sprites to display. With recent improvements in bB's standard kernel, there is now some time available here. How much time depends on a number of factors, but in most cases it should be at least 1000 cycles. You can now run some bB code here if you wish. . . . Note that running code here means that certain changes won't take effect until the next drawscreen. Particularly, changing x-positions of objects or the score will be delayed. Quote Link to comment Share on other sites More sharing options...
Nukey Shay Posted October 3, 2008 Share Posted October 3, 2008 (2) If it's feasible, see if you can divide the routines up so they don't all get performed during the same frame-- i.e., some routines would be performed during one frame, then the remaining routines would be performed during the next frame. That sounds like a good idea. How would you do that? bB makes this easy, since you can have it draw a screen whenever you want (automatically wasting any unused cycles). Other than that, a program could check whether a framecounter is odd or even to decide between 2 different time-consuming chores...or contain some kind of abort routine to abandon a task that is taking too long (optimally storing this result so that the program "knows" to deal with it on the next frame with a higher level of priority). The game Adventure, for example, uses 3 frames to accomplish all of it's tasks. On the first frame, the console switches are checked (and dealt with, if applicable), any game sounds needed are played, the location of the chalise is checked (to see if a game had been won), the joystick is read, 8-direction player movement is applied, any carried object is updated, and the print queue is dealt with. On the second frame, objects are allowed to be picked up or dropped, vertical-only player motion is applied, the invisible surround object (if applicable) is matched to the player, the bat is dealt with, and so are castle gates. On the third frame, the dragons and objects attracted to the magnet are dealt with, and horizontal-only player motion is applied. Then it loops back for the next 3 frames, and so on. 1 Quote Link to comment Share on other sites More sharing options...
+Random Terrain Posted October 3, 2008 Share Posted October 3, 2008 (2) If it's feasible, see if you can divide the routines up so they don't all get performed during the same frame-- i.e., some routines would be performed during one frame, then the remaining routines would be performed during the next frame. That sounds like a good idea. How would you do that? bB makes this easy, since you can have it draw a screen whenever you want (automatically wasting any unused cycles). Other than that, a program could check whether a framecounter is odd or even to decide between 2 different time-consuming chores...or contain some kind of abort routine to abandon a task that is taking too long (optimally storing this result so that the program "knows" to deal with it on the next frame with a higher level of priority). The game Adventure, for example, uses 3 frames to accomplish all of it's tasks. On the first frame, the console switches are checked (and dealt with, if applicable), any game sounds needed are played, the location of the chalise is checked (to see if a game had been won), the joystick is read, 8-direction player movement is applied, any carried object is updated, and the print queue is dealt with. On the second frame, objects are allowed to be picked up or dropped, vertical-only player motion is applied, the invisible surround object (if applicable) is matched to the player, the bat is dealt with, and so are castle gates. On the third frame, the dragons and objects attracted to the magnet are dealt with, and horizontal-only player motion is applied. Then it loops back for the next 3 frames, and so on. Thanks. I'll try that stuff and see which is best for what I'm currently working on. Quote Link to comment Share on other sites More sharing options...
satyrsfaction Posted May 1, 2020 Share Posted May 1, 2020 On 10/3/2008 at 1:50 AM, Nukey Shay said: bB makes this easy, since you can have it draw a screen whenever you want (automatically wasting any unused cycles). Other than that, a program could check whether a framecounter is odd or even to decide between 2 different time-consuming chores...or contain some kind of abort routine to abandon a task that is taking too long (optimally storing this result so that the program "knows" to deal with it on the next frame with a higher level of priority). The game Adventure, for example, uses 3 frames to accomplish all of it's tasks. On the first frame, the console switches are checked (and dealt with, if applicable), any game sounds needed are played, the location of the chalise is checked (to see if a game had been won), the joystick is read, 8-direction player movement is applied, any carried object is updated, and the print queue is dealt with. On the second frame, objects are allowed to be picked up or dropped, vertical-only player motion is applied, the invisible surround object (if applicable) is matched to the player, the bat is dealt with, and so are castle gates. On the third frame, the dragons and objects attracted to the magnet are dealt with, and horizontal-only player motion is applied. Then it loops back for the next 3 frames, and so on. so, am I understanding this correctly? the way to spread your code over two or more frames in Batari Basic is simply to use an extra drawscreen? Quote Link to comment Share on other sites More sharing options...
+KaeruYojimbo Posted May 1, 2020 Share Posted May 1, 2020 45 minutes ago, satyrsfaction said: so, am I understanding this correctly? the way to spread your code over two or more frames in Batari Basic is simply to use an extra drawscreen? That will definitely work. If your game loop takes too long, divide it up over two drawscreens. I did that for the first Galctopus game because moving the shields took up too many cycles to do that and everything else that had to happen. I don't remember exactly how I split things up without looking at the actual code, but my main loop was something like this: Game_loop (move shields) drawscreen (move Galactopus, move player, etc) drawscreen (check for collisions) goto Game_loop 1 Quote Link to comment Share on other sites More sharing options...
+Random Terrain Posted May 2, 2020 Share Posted May 2, 2020 4 hours ago, satyrsfaction said: so, am I understanding this correctly? the way to spread your code over two or more frames in Batari Basic is simply to use an extra drawscreen? I thought it was if a certain bit is on, skip this section of code. If the bit is off, skip this other section of code. There would just be one drawscreen. Quote Link to comment Share on other sites More sharing options...
+KaeruYojimbo Posted May 2, 2020 Share Posted May 2, 2020 13 hours ago, Random Terrain said: I thought it was if a certain bit is on, skip this section of code. If the bit is off, skip this other section of code. There would just be one drawscreen. Looking back, that's how I'd do it now. But when you're working on your first game and someone tells you that you need to split your loop over two drawscreens because the screen is rolling, adding a second drawscreen in the middle of the loop is the first thing you think of. 2 Quote Link to comment Share on other sites More sharing options...
+Karl G Posted May 2, 2020 Share Posted May 2, 2020 Both ways work, although if you throw in an extra drawscreen, you will probably also have to set your "inside game loop" registers again, such as player colors. Quote Link to comment Share on other sites More sharing options...
bogax Posted May 2, 2020 Share Posted May 2, 2020 18 minutes ago, Karl G said: Both ways work, although if you throw in an extra drawscreen, you will probably also have to set your "inside game loop" registers again, such as player colors. you could put it in a subroutine or a macro 1 Quote Link to comment Share on other sites More sharing options...
freshbrood Posted January 29, 2021 Share Posted January 29, 2021 Does anyone know an easy way to eliminate the starstep effect in bbasic using the 2 player kernel? 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.