NESDev and Strangulation Records messageboards
Forum Index | FAQ | New User | Login | Search

Previous ThreadView All ThreadsNext Thread*Show in Threaded Mode


SubjectNewbie question new  
Posted byRans
Posted on10/14/03 00:06 AM
From IP24.203.71.173  



Hello,

I'm having trouble displaying a single sprite correctly. It appears, but the coordinates are wrong. I've included the code that you can download to help finding what's wrong.

http://www.desy.ca/test.zip

1. First a small portion of the sprite appears on the top left corner. Why?

2. In our.spr, i've got 2 sprites. The first one is a square and the second one is a dot. In my code, i do specify that the sprite index i want to display is 0 (the square). The square appears, but the dot also appears in the middle of the square! Why is that? Isn't a tile representing a single sprite?

You can compile it with nesasm and view the tiles with Tile Layer Pro.

Thanks for any help




SubjectRe: Newbie question new  
Posted byMemblers
Posted on10/14/03 01:33 AM
From IP68.58.99.218  



It never returns from the NMI, (there's a JMP before the RTI) so the stack is overflowing. And you probably shouldn't enable IRQs with CLI yet, since your IRQ vector is pointing to 0000. :)

It would seem your graphics are in the wrong format. Using tile layer (DOS version) in 1BPP format I see 2 tiles, but in NES format there is only 1 (with both of them combined). A simple error, but those are always the annoying ones, I know. ;)

There's a potential problem with the $2003 register (SPR-RAM address) not being set. Write a zero to it shortly before doing the sprite-DMA.

Looking at the memory view with FCEUltra there is only one sprite there. All the rest are sitting at coordinate 0,0 using tile #0, which is why they're visible. You can either leave tile #0 blank, or set the tile numbers for the unused sprites to a blank one to fix that.




SubjectRe: Newbie question new  
Posted byMemblers
Posted on10/14/03 01:37 AM
From IP68.58.99.218  



Also, alternatively you could set the sprite's Y coordinate to something higher than 240 to keep the unwanted ones off the screen.




SubjectRe: Newbie question new  
Posted byRans
Posted on10/14/03 03:01 AM
From IP24.203.71.173  



You're a genius! I just opened my sprites file in TLP. In the View menu > Format, it was set to 1BPP. Never noticed the formats before. When set to NES format, it works as i expected to. One problem solved thanks!

I don't have the time tonight but tomorrow i'll try to fix the top left glitches with your suggestions.

And about the stack overflow, i thought i should go back to the infinite loop when i'm done updating the sprites. So that the next interrupt would call the vblank routine, ending the infinite loop. I should study the structure of some mini-games about this! Thanks Memblers




SubjectRe: Newbie question new  
Posted byphoenix
Posted on10/14/03 04:04 AM
From IP68.75.21.252  



When an NMI/IRQ occurs, the currently executing code will be interrupted, and resumes only when you issue an RTI instruction. In your case, the code being interrupted by the NMI already would be the infinite loop that you enter after setting up the PPU. At the end of the NMI routine, the RTI instruction ends NMI/IRQ processing, and returns to your infinite loop automatically to wait for the next NMI/IRQ.

Think of NMI/IRQ as kind of an "invisible JSR" that is executed only by the hardware, and can happen at any time. Thus, when you are done handling NMI, you'll want to return to whatever code was executing before by using an RTI instruction.

Note that the "happen at any time" part is why we and steer clear from CLI, which enables IRQs, which means we would have 2 possible interruptions to deal with, which could possibly interrupt each other, etc, ad interruptum. : ) It is also why we disable PPU NMI's whenever we are initializing; a zen that I have had to reflect on as recently as this past weekend, as Memblers knows. ; )

Phoenix




SubjectRe: Newbie question new  
Posted byRans
Posted on10/15/03 02:36 AM
From IP24.203.71.173  



Interesting the fact of the automatic return to the infinite loop. This is what i didn't get. It's not an easy task to trap such errors, because it won't crash! I've never seen a nes rom crashing.

So for my test rom, i just removed the jmp instruction, and then the rti is executed if i understand well. The top left glitches was easy to fix. I just let the first tile blank and used the second one for the sprite. Works fine now.

Now i'm learning how to display a background properly. My first experience is that the background tiles are not starting on the top. Ex: I have a tile that is a square and on the top, the first 2-3 pixels are not showing. I'm gonna try to find out by myself, but i'll ask your help if i'm really stuck.

A question i need to ask : is it possible to make a "block" of sprites? As an example, i would like to make a player that is made of 8 sprites. Do we have to move each sprite one by one, or can we specify a Y and X coordinates for the whole "block"?




SubjectRe: Newbie question new  
Posted byphoenix
Posted on10/15/03 03:27 AM
From IP68.75.21.252  



As far as I know, you need to set up one sprite for every 8x8 (or 8x16, depending on PPU setup) tile in a larger graphic. For your player you will need to use 8 sprites, or 4 if you use the PPU's 8x16 sprite mode.

You'll find that most really large bosses in NES games are actually drawn as background tiles; either the boss doesn't move, or if the boss does need to move, the level background fades, the boss is drawn as background tiles, then the background scrolls to simulate the boss moving. Or the boss will have only a small number of moving parts. All this is necessary to overcome the 64 sprite total, 8 sprite per scanline limitation of the PPU.

Phoenix




SubjectRe: Newbie question new  
Posted byMemblers
Posted on10/15/03 03:43 AM
From IP68.58.99.218  



The top and bottom aren't displayed fully on an NTSC TV. The screen size is 240 pixels, but once the it's trimmed down to NTSC TV size it's more like 224 pixels (and even less on some TVs).

And yeah, for a player made of several sprites you'll need to move them all. I've been working on some sprite animation code recently, I've figured a good way to do it is to have the engine move one sprite (the 'main' one), then the animation code draws the rest of the player sprites relative to that one. It keeps things simpler, though the code might be somewhat slower.




SubjectRe: Newbie question  
Posted byAnonymous
Posted on10/15/03 4:32 PM
From IP207.236.214.130  



It's Rans here. (i'm at work and i don't know my password)

Well, i played around with the options in FCE Ultra. When set to PAL emulation, the whole screen is displayed. In NTSC though there's an option to change the first and last line of the drawing area. By default the first line is 8 and the last is 231. This can be really problematic with emulators. Do you know the "official" NTSC first and last lines on a real NES?

I hope that this is standard on a NES (with NTSC tv). If not then what a pain.




SubjectRe: Newbie question new  
Posted byMemblers
Posted on10/15/03 5:54 PM
From IP68.58.99.218  



There doesn't seem to be an offical NTSC screen size. 8 to 231 might be like an average size, but some TVs may show more or less than that.

Playing Legacy of the Wizard on a friend's TV, I could barely see a ladder that's on the floor of the first level.




Previous ThreadView All ThreadsNext Thread*Show in Threaded Mode
Jump to

Memblers' homepage             Contact Me

Forums powered by WWWThreads Demo