Jump to content

Photo

Getting scanline under control


6 replies to this topic

#1 atari2600land ONLINE  

atari2600land

    Waffles:

  • 10,776 posts
  • Man's best invention. Ever.
  • Location:Salem, Oregon

Posted Wed Oct 1, 2008 9:13 PM

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

Attached Thumbnails

  • scanline.PNG


#2 SeaGtGruff OFFLINE  

SeaGtGruff

    Quadrunner

  • 5,558 posts
  • Location:Georgia, USA

Posted Thu Oct 2, 2008 12:41 PM

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

#3 Random Terrain ONLINE  

Random Terrain

    Visual batari Basic User

  • 28,187 posts
  • Controlled Randomness
    Replay Value
    Nonlinear
  • Location:North Carolina (USA)

Posted Thu Oct 2, 2008 6:42 PM

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

#4 atari2600land ONLINE  

atari2600land

    Waffles:

  • Topic Starter
  • 10,776 posts
  • Man's best invention. Ever.
  • Location:Salem, Oregon

Posted Thu Oct 2, 2008 7:31 PM

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

#5 Random Terrain ONLINE  

Random Terrain

    Visual batari Basic User

  • 28,187 posts
  • Controlled Randomness
    Replay Value
    Nonlinear
  • Location:North Carolina (USA)

Posted Thu Oct 2, 2008 7:42 PM

(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

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.



#6 Nukey Shay OFFLINE  

Nukey Shay

    Sheik Yerbouti

  • 21,670 posts
  • Location:The land of Gorch

Posted Fri Oct 3, 2008 12:50 AM

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

#7 Random Terrain ONLINE  

Random Terrain

    Visual batari Basic User

  • 28,187 posts
  • Controlled Randomness
    Replay Value
    Nonlinear
  • Location:North Carolina (USA)

Posted Fri Oct 3, 2008 4:07 AM

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




0 user(s) are browsing this forum

0 members, 0 guests, 0 anonymous users