Sprites.chr is not appearing in PPU viewer

[Kasumi]

Looks like it's because the code to reenable rendering (under FlagClear) is literally impossible to access. Directly above it is a jmp that skips ahead of that write to $2001, and nothing branches to FlagClear.

[thefox]

You don't have to guess how big your files might be. Right-click on the file and select Properties, and it will let you know.

[Tsutarja]

Looks like it's because the code to reenable rendering (under FlagClear) is literally impossible to access. Directly above it is a jmp that skips ahead of that write to $2001, and nothing branches to FlagClear.

Got it working. I added a ORA between the two NMI flags, and if both are off, it will branch to FlagClear. Also, my sprite is shaking a little bit even though it's not moving. What's causing this? I did add some stuff to the code to fix some stuff. It removed most of the shaking, but the sprite still shakes a little bit occasionally. I also noticed that the program draws the left half of the sprite on the second background (during PAL emulation).

New code: http://pastebin.com/mivk49CK

[tokumaru]

What's the deal with the TimeWaster routine? Did you put that in because the sprite was moving too fast? That's the wrong way to solve this problem (because it may completely throw off the alignment between game logic and VBlank handler, and your NMI doesn't look prepared to handle lag frames), and could very well be causing the stability issues you described.

The correct thing to do is only run your main loop once per frame. This is commonly achieved by polling a variable once the game logic is done, and only jumping back to repeat the main loop once that value changes, which only happens in the NMI handler, so you know that a new frame has started:

Code: Select all

MainLoop:
	JSR MoveSpr
	LDA FrameCounter
WaitFrame:
	CMP FrameCounter
	BEQ WaitFrame
	JMP MainLoop

Then, anywhere in your NMI (preferably at the end, so as to not steal any precious VBlank time), you increment that variable:

Code: Select all

	INC FrameCounter

[Tsutarja]

What's the deal with the TimeWaster routine? Did you put that in because the sprite was moving too fast? That's the wrong way to solve this problem (because it may completely throw off the alignment between game logic and VBlank handler, and your NMI doesn't look prepared to handle lag frames), and could very well be causing the stability issues you described.

That was just temporary solution to see that the sprite was moving correctly on x and y axis. It was good that I tested it, since my sprite was moving the opposite direction I pressed. I had no idea that wasting time with a loop would cause sprite shaking and other side effects (which I probably haven't seen yet). The way you suggested makes sense now that I think about it. I guess I didn't even think that wait function was possible on NES. But since NMI happens once per frame, you could increment wait counters during it to get the wait counters to a consistent timing and not having to time the main loop with loops that do nothing. I guess I've been avoiding to add too much stuff to the NMI to make sure it always finishes in time.

[tokumaru]

I guess I've been avoiding to add too much stuff to the NMI to make sure it always finishes in time.

That's why we do all the VBlank stuff first (everything related to the PPU), and then we do the rest of the periodic tasks, like updating counters, running the sound engine, reading the controllers, and so on. There's nothing wrong with your NMI taking longer than VBlank to finish, as long as the PPU stuff finishes before the VBlank does.

What you really must pay attention to is not letting your main loop take longer than a frame. That hardly happens in simpler games, but in games with a lot of action there's a big chance that the game logic will be prematurely interrupted by an NMI, and if you aren't prepared to handle such interruptions all kinds of bad things can happen.

I had no idea that wasting time with a loop would cause sprite shaking and other side effects (which I probably haven't seen yet).

I can't say for sure that this was the cause, but think about it: you are constantly updating the sprites and waiting an arbitrary amount of time, over and over, and the NMI will interrupt that process at any time. Can you guarantee that the NMI handler will always find a consistent game state for its updates? What if the NMI hits when you've updated the coordinates of one sprite but not the other? The character represented by the sprites will look distorted for a frame. Depending on the task that's interrupted when the NMI fires, all kinds of side effects can result from using an inconsistent game state for a video update, and the program could even crash.

With the method I suggested, after your game reaches a consistent game state, which is ready for a video update, the engine patiently waits for such updates to happen before messing with the game state again.

[Tsutarja]

I just added the counter for the NMI. Now I just need to find out why a duplicate of the left half of the sprite appears on the top left corner of the screen. It's not visible in the nametable viewer, so it's definitely a sprite. It's not moving along with the "real" sprite though. Like I said earlier, it's only visible during PAL emulation (I use it because I live in Finland and it's in the PAL region). The latest code I posted should work in finding the issue because all I have changed since I posted it is that I added the counter, removed the time waster loop and fixed some labels that I forgot to do before (though it doesn't affect to the execution of the code at all, I just fixed it so I won't get confused later). The issue did exist in that code too.

[Quietust]

Now I just need to find out why a duplicate of the left half of the sprite appears on the top left corner of the screen.

By any chance are you initializing your unused sprite RAM to $00?

Because if you are, then all of your "unused" sprites will appear at the top-left corner of the screen, and initializing them to $FF (or any value greater than or equal to $F7) should solve it.

[Tsutarja]

Now I just need to find out why a duplicate of the left half of the sprite appears on the top left corner of the screen.

By any chance are you initializing your unused sprite RAM to $00?

Because if you are, then all of your "unused" sprites will appear at the top-left corner of the screen, and initializing them to $FF (or any value greater than or equal to $F7) should solve it.

So you mean that I should store #$FF to $0208-$02FF which is the unused portion of the sprite memory in my code.

[Quietust]

So you mean that I should store #$FF to $0208-$02FF which is the unused portion of the sprite memory in my code.

Correct.

[tepples]

initializing them to $FF (or any value greater than or equal to $F7) should solve it.

Why $F7? I thought any value in $EF-$FF was good enough to put all sprites below the bottom of the picture.

[Quietust]

initializing them to $FF (or any value greater than or equal to $F7) should solve it.

Why $F7? I thought any value in $EF-$FF was good enough to put all sprites below the bottom of the picture.

Because I fail at math, apparently - the value I was looking for was 239, but I somehow translated that to $F7 ($F8 - 1) instead of $EF ($F0 - 1).

[3gengames]

Initializing to $FF does something bad with the sprites on the next screen AFAIK. I forget what exactly, but #$F0 is the correct value to initialize to.

[thefox]

Initializing to $FF does something bad with the sprites on the next screen AFAIK. I forget what exactly, but #$F0 is the correct value to initialize to.

No.

[3gengames]

Initializing to $FF does something bad with the sprites on the next screen AFAIK. I forget what exactly, but #$F0 is the correct value to initialize to.

No.

I forget what exactly, it had something to do with the rendering disable when sprites were found by the sprite logic, but there is a quirk with a certain off-screen value. I think $FF is right, I believe it was $EF that is bad to do.