For a full game, isn't vblank useless?

[+Random Terrain]

I haven't tried vblank in a full game with a title screen, main loop, and game over screen, but if I'm understanding vblank correctly, it will run during all parts of the game (whenever a drawscreen is called), so whatever you use would have to work in at least three sections of your game. What would be shared between those parts of the game? Seems like each section might use different colors and have different uses for the same variables.

[RevEng]

Not useless, just niche.

 

It's a great place to store your sound fx or music routines, as they will be called every 60th of a second, no matter how many drawscreen commands you've scattered throughout your code.

 

There are other similar uses - if you're cycling a color, doing an animation to a sprite that should happen every 60th, etc.

 

That said, if the routines should only happen in certain phases of the game then you'll need a variable to track that and skip the routines if the game is in a phase they shouldn't run in.

Edited September 16, 2010 by RevEng

[+Random Terrain]

That said, if the routines should only happen in certain phases of the game then you'll need a variable to track that and skip the routines if the game is in a phase they shouldn't run in.

Thanks. I'll probably have a spare bit or two lying around for that.

[yuppicide]

Great idea to use music in a vblank. I'll have to remember that.

[+Gemintronic]

I use vblank in Uppa Creek!

 

rem vblank Section

vblank
if in_game = true then pfscroll down
return

 

I could see it being used as kind of a "hypervisor" running in conjunction with the main loop.

[SeaGtGruff]

I haven't tried vblank in a full game with a title screen, main loop, and game over screen, but if I'm understanding vblank correctly, it will run during all parts of the game (whenever a drawscreen is called), so whatever you use would have to work in at least three sections of your game. What would be shared between those parts of the game? Seems like each section might use different colors and have different uses for the same variables.

Although you can have only one vblank routine, and it always gets called, you can use a flag to determine whether to run the routine-- i.e., if the flag is set one way, just go ahead and return without performing the routine, otherwise perform the routine and then return. Or you can have multiple routines and use a variable to decide which one you want to perform. In other words, just because vblank will always get called if you've defined it, and can have only one entrance point, that doesn't mean you can't put an if-then at the beginning of it to decide between multiple paths.

 

Michael

[+Random Terrain]

I'm working on a 32 x 24 Pac-Man-ish example program and since the need for pfread has almost doubled. I was reminded by jrok that I could use vblank to help keep the scanline count from going over 262.

 

I remembered that vblank goes in the last bank, but after reading the vblank section on the bB page again, I was still kind of fuzzy about what is allowed inside of vblank (between vblank and return). I figured it wouldn't hurt to try, so I threw all of the code for player movement in there. It worked, but the animation didn't. I tossed the animation subroutines into vblank, but they didn't work there either. Finally, I took the animation subroutines out of vblank and just put them in the last bank and now the player movement code and animation is working.

 

So I guess goto can be used within vblank and on gosub can be used to jump out of vblank if the subroutines are in the last bank.

[jrok]

For a full game, isn't vblank useless?

 

No!

 

I mean, it depends on what you put in there, how you structure your code, etc. But I've never had trouble with it, including in games that have multiple screens/segments or whatever you want to call them. For instance, I used it to crunch almost 1000 machine cycles in Circus Galacticus, and that had several screens with unique functions (including making use of RevEng's brilliant title screen kernel).

 

I guess everyone codes differently, but I try to use it exclusively for longer math, bounding box detection and multiple-case trees (such as AI decision trees), and keep those operations separate from the "daily grind" of animation routines, sprite positioning, sound effects, etc. In other words, I shove the boring stuff in there that is helpful during the program's highest activity (the main game loop, usually) but that doesn't *directly* affect screen updates. Sure, you could spend RAM on avoiding certain routines within the statement, but if the stuff going on in there isn't A/V related, then who cares if it's running in the background of a "Character Selection" screen or something?

Edited August 2, 2011 by jrok