6 replies to this topic

[atari2600land]

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

Attached Thumbnails

• 

[SeaGtGruff]

atari2600land, on Wed Oct 1, 2008 10:13 PM, said:

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]

SeaGtGruff, on Thu Oct 2, 2008 2:41 PM, said:

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

SeaGtGruff, on Thu Oct 2, 2008 11:41 AM, said:

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

atari2600land, on Thu Oct 2, 2008 9:31 PM, said:

SeaGtGruff, on Thu Oct 2, 2008 11:41 AM, said:

(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.randomter...nds.html#vblank

Quote

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]

Random Terrain, on Thu Oct 2, 2008 4:42 PM, said:

SeaGtGruff, on Thu Oct 2, 2008 2:41 PM, said:

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

Nukey Shay, on Fri Oct 3, 2008 1:50 AM, said:

Random Terrain, on Thu Oct 2, 2008 4:42 PM, said:

SeaGtGruff, on Thu Oct 2, 2008 2:41 PM, said:

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