still working on getting my ppu to work. there was a fineX problem that i found and fixed. now i still have 2 scrolling problems.
1) the right 0~7 (depending on fine x) pixels are from the left tiles, not the tiles for the right scroll.
2) the initial screen is displays fine. but when i scroll to the next screen, i suppose that would be the next pallet, seems like every even tile is duplicated and some colors are messed up. i was messing with the mirring and changed the pointer so that both nametables point to the right (not left) table and that shows 2 right tables where the initial one is fine and the right one is messed up the same way. not sure if that info helps or is confusing... sorry if it is.
here is a screen shot where i scrolled between the 2 tables.
http://icarus.cc.uic.edu/~mhull1/screenshot.jpg
(this image will probably not be here after may 06...)
image should be here, but doesnt work and i dont know why
anyone have any suggestions to what might be wrong ?
thanks
matt[/img]
It would help if you posted the demo you were using - it's possible the demo itself has errors in it.
thanks for the reply
the screen shows up.... hmmm. it didnt when selected the preview. oh well
the blocks.nes demo is on the nesdev page,
http://nesdev.com/blocks.zip
it also works fine on several other emulators including nintenulator.
thanks
matt
Blocks is sound in terms of bugs. It looks like you might not be updating the PPU TEMP/VRAM address at the right times. Or it could be the NT at $2800 data not being fetched properly.
I bet you aren't handling the switchover to the other nametable after you render the right-most tile of the first nametable.
thanks for the replies.
blargg, i dont think i am switching over to the other nametable correctly.
right now i am just incrementing the counters as i render. i was re reading the docs the last few days and think i am missing something. could one of you explain what happens with the nametable address when switching tables ? i think i understand the mirroring. but i dont understand how to get the correct fetch address for the next name table.
thanks
matt
At a high-level, it just wraps the X coordinate around to 0 and uses the nametable mapped to $2400. Nothing tricky about it.
code snippit:
Code:
if((nPPUAddr & 0x001F) == 0x001F) nPPUAddr ^= 0x041F;
else nPPUAddr++;
In English -- when you increment the counter so that it points to the next tile, you toggle the X nametable bit (bit 10) after it wraps from 31->0.
It works in a similar way for the Y scroll -- although you toggle the Y NT bit (bit 11) after it wraps from 29->0. It will also wrap from 31->0, but the NT bit will not be toggled in that case:
Code:
if((nPPUAddr & 0x03E0) == 0x03E0) nPPUAddr ^= 0x03E0;
else if((nPPUAddr & 0x03E0) == 0x03A0) nPPUAddr ^= (0x03A0 | 0x0800);
else nPPUAddr += 0x0020;
i wasnt toggling the name table bit when crossing tables. so that is fixed. thanks
however i still have that problem with the right tile when scrolling. it is the tile from the right edge 1 pixel high.
i am trying to fix that now... any suggestions welcome
thanks
matt
Ahhh, I see that extra one-pixel-high tile on the right. It looks like the entire right edge is shifted up a pixel, suggesting that you're wrapping around on the graphics surface. Are you perhaps writing up to 8 bytes of data before the beginning of the surface pixels? That's my best guess. I doubt the problem is deep in your PPU renderer like the previous one.
i was messing with my ccode for a bit and i always get the right or left tile messed up. that got me thinking.... are there only 32 tile fetches in a scanline or is there 32 ? if the fineX scroll is in the middle of a tile such that there is part of a tile on the left and rigth edge of the screen, wouldnt there need to be 33 tiles for that? 1 for the left, 1 for the right, and 31 in the middle ?
matt
There are 34 background tile fetches and 8 sprite tile fetches in a scanline.
Tepples is correct.
During the first 256 cycles of the scanline (when pixels are being rendered), a full tile is being fetched every 8 cycles -- meaning in that time 32 tiles are fetched. The first tile fetched during this time is actually the 3rd tile to be rendered -- as the first two tiles were fetched near the end of the previous scanline (cycles 320-335) -- giving you the 34 fetches total. For details, I'd recommend you check out BT's 2C02 Technical reference doc.
From what I understand, it's important to perform all 34 fetches, even though the last tile fetched never actually appears on screen. I believe games which use mappers such as MMC2/MMC4 use that tile to trigger a CHR swap, so if you're only doing 32 or 33 BG tile fetches per scanline, those games will give you trouble later on.
I haven't actually tested the games when leaving out the last fetch so I can't say with certainty though.
fixed, i can scroll. i wasnt fetching the 2 tiles at the end of the scan line.
now to clean up the code and optimise a little.... then add sprites.
thanks
matt