nesdev.com

Hello again everybody,

After a long time i decided to work on my pong game again. The game is coming together nicely, But i could use some help.
Controls, sprites and collision dectection are al working fine but i got some trouble with the backgrounds/ gamemodes.

I want to switch backgrounds and gamemodes.( PUSH START on the StateTitle to go To the StatePlaying )
I'm following the Nerdy Nights tutorials so i'm using the 3 gamestates StateTitle, StatePlaying and State Gameover.
So i wrote this newbie code. When you push the start button you immediately turn off the screen and disable NMIs, draw the screen and then turn the screen on again when you are finished. it's turning the screen off in the middle of drawing. ( $2000 & $2001 ) It kinda works funny enough but this is not the way to go.

I read the NMI document from disch and it confirms i'm a newbie
To solve this problem i have to use varibles for $2000 and $2001 and use a waitframe. I kinda understand this i think. It's like using the Ram for the sprites i think.
But then the exsample shows another NMI exsample. So i read some more about NMI and another way to use it with a handle and then i see a better way to get your backgrounds in your code etc.etc.

In other words information overload !!
I just want to finish my pong game and after that i want to edit sound and experiment with multiballs and other stuff.

So could 1 of you push me on track again ?
What is the best way for a newbie to use the Vblank to switch game modes and backgrounds for simple 2 or 3 screen games ?

_________________
im a newbie,lets see how far i can get

You don't need to disable NMIs if your NMI handler is "well behaved" and doesn't do PPU stuff unless it's told to by the main program via different flags.

Anyway, the best approach will depend on how you're currently dividing the logic and the drawing. If I remember correctly, Nerdy Nights starts out with the worst possible program structure, which puts logic and drawing in the NMI handler, in that order (which only allows you to use 7.6% of the total CPU time!). I don't know if that changes later on, but if that happens to be the structure you're using, I suggest you fix that immediately, and switch to a program structure that allows you to use the full CPU time.

The most newbie-friendly program structure IMO is the one where the NMI just updates a counter:


Then you can just wait for this counter to change whenever you need to wait for vblank:


This structure is great because you can have completely independent game modes (no shared NMI handler that needs to cater to the needs of every mode), and there's no risk of conflicts between the main thread and the NMI thread because the NMI thread only does literally one thing, and never touches anything the main thread might be using.

The only disadvantage of this program structure is that it can't handle lag frames. If you take longer than a hardware frame to process a game frame, you'll completely miss one vertical blank, meaning that the music will slow down and any raster effects not triggered by IRQs (such as sprite 0 hit status bars) will glitch.

Anyway, since program modes can be completely independent from each other, you can easily code separate blocks of initialization->logic->drawing, one for each mode. Something like this:


And this is the basic idea... Just implement as many game modes as you need and jump between them.

If you want to have fade transitions, you can't immediately jump to another game mode, you have to somehow signal the intention to switch to another mode (use a NextGameMode variable or something) and initialize the fading animation, and once that finishes the next game mode is called.

If you are wondering how to get your game to not mess up if you take longer than a hardware frame to process a game frame, you should read tokumaru's post to me. If you choose method 1 be sure to bookend your vblank with: That pushes your registers to the top of the stack at the beginning of vblank and pulls them from the top of the stack at the end of vblank. When using method 1, this code works wonderfully and prevents weirdness in your game. Caution when using the stack (sometime after following this link, make sure to click on the link to another important tokumaru post).

Thanks for the replies unregistered and tokumaru !

I rewrote the Pong nerdy nights program structure. I removed all the logic from the NMI and everything works great now.

Title screen, gameplay and the game over screen work fine !
There is 1 small problem. The score on the top of the screen 000 is visible on all screens. I don't mind that it's on the play and game over screen but it does look weird on the title screen.
I think that the problem is that the ''draw scores JMP'' is in the NMI. But i have to take a closer look at this ''problem'' later.

_________________
im a newbie,lets see how far i can get

That does seem to be the "problem" to me too if your game is JSRing "draw scores" every vblank (NMI) because that drawing of the score isn't dependent on what screen it is on; rather, it just happens every frame. You can fix it!

p.s. I'm so happy you got the game to work otherwise! Good work!