Getting scanline under control

[+atari2600land]

How do you get the "scanline" counter above 262 in bB, and how can you prevent this from happening?

[SeaGtGruff]

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

[+Random Terrain]

(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?

[+atari2600land]

(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?)

[+Random Terrain]

(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.

[Nukey Shay]

(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.

[+Random Terrain]

(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.

[satyrsfaction]

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?

[+KaeruYojimbo]

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

[+Random Terrain]

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.

[+KaeruYojimbo]

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.

[+Karl G]

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.

 

[bogax]

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

[freshbrood]

Does anyone know an easy way to eliminate the starstep effect in bbasic using the 2 player kernel?