8x16 and whatever else unreg wants to know

Are you new to 6502, NES, or even programming in general? Post any of your questions here. Remember - the only dumb question is the question that remains unasked.

Moderator: Moderators

unregistered
Posts: 1070
Joined: Thu Apr 23, 2009 11:21 pm
Location: cypress, texas

Re: 8x16 sprite is really a 16x32 pixel image?

Post by unregistered » Wed Jan 09, 2013 11:14 am

3gengames wrote:Yep, basically think of it as "Add 256 to the scroll"and that's how it works. :) So when you get to scroll=256, you have to put X to zero, then set the bit. That moves it to the next nametable as the default that you then scroll within. :)
^thank you 3gengames, when I didn't care anymore and just followed your advice it resulted in being able to keep scrolling between nametable 1 and 2. :D
---

Now my meandering remindes me of that gif that tepples posted that shows the game safely adding the next nametable collum by collum. Is that how I should be coding now? My goal is to safely scroll into the next new nametable.

unregistered
Posts: 1070
Joined: Thu Apr 23, 2009 11:21 pm
Location: cypress, texas

Re: 8x16 sprite is really a 16x32 pixel image?

Post by unregistered » Wed Jan 09, 2013 12:57 pm

...I guess the answer is yes. Does this sound correct:

Code: Select all

set PPU so that it draws in a collum

  - while p1 is pressing right on dpad

        while there is no place to scroll to and our collum is incomplete
            draw next pair of metatiles

    scroll a pair of metatiles over
    branch to -

tepples
Posts: 21936
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Re: 8x16 sprite is really a 16x32 pixel image?

Post by tepples » Wed Jan 09, 2013 1:39 pm

Sort of. The "p1 is pressing right on dpad" controls the location of a character in the game world, and a camera data structure follows the location of this character. When the camera moves, you draw the metatiles onto which the camera is moving.

unregistered
Posts: 1070
Joined: Thu Apr 23, 2009 11:21 pm
Location: cypress, texas

Re: 8x16 sprite is really a 16x32 pixel image?

Post by unregistered » Wed Jan 09, 2013 3:19 pm

tepples wrote:Sort of. The "p1 is pressing right on dpad" controls the location of a character in the game world, and a camera data structure follows the location of this character. When the camera moves, you draw the metatiles onto which the camera is moving.
:D Can you draw metatiles at anytime? I am worrying about the screen changing to black when I try to write nametable data. I should try to write during vblank, right?

tepples
Posts: 21936
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Re: 8x16 sprite is really a 16x32 pixel image?

Post by tepples » Wed Jan 09, 2013 3:36 pm

Correct. Because the NES PPU lacks the write FIFO of the SMS VDP and TG16 VDC, writes to the nametables must happen during vertical blanking or forced blanking. Prepare the writes in a RAM buffer during draw time and then copy them to VRAM during vblank.

unregistered
Posts: 1070
Joined: Thu Apr 23, 2009 11:21 pm
Location: cypress, texas

Re: 8x16 sprite is really a 16x32 pixel image?

Post by unregistered » Wed Jan 09, 2013 4:00 pm

tepples wrote:Correct. Because the NES PPU lacks the write FIFO of the SMS VDP and TG16 VDC, writes to the nametables must happen during vertical blanking or forced blanking. Prepare the writes in a RAM buffer during draw time and then copy them to VRAM during vblank.
Alright! Thank you tepples! :D

unregistered
Posts: 1070
Joined: Thu Apr 23, 2009 11:21 pm
Location: cypress, texas

Re: 8x16 sprite is really a 16x32 pixel image?

Post by unregistered » Fri Jan 11, 2013 11:26 am

unregistered wrote:
tepples wrote:Sort of. The "p1 is pressing right on dpad" controls the location of a character in the game world, and a camera data structure follows the location of this character. When the camera moves, you draw the metatiles onto which the camera is moving.
:D Can you draw metatiles at anytime? I am worrying about the screen changing to black when I try to write nametable data. I should try to write during vblank, right?
Yesterday I learned that my attempts at writing nametable data are being done during vblank. I wasn't aware of the fact that my scrolling code appears at the end of my vblank code. So, why does the screen turn black? Do you have any ideas? :?

edit: Ok... I remember this :oops: ...
tokumaru[color=#00BFFF], on page 43,[/color] wrote:Setting the scroll should ALWAYS be the very last thing in your VBlank handler.
Last edited by unregistered on Fri Jan 11, 2013 1:20 pm, edited 1 time in total.

3gengames
Formerly 65024U
Posts: 2275
Joined: Sat Mar 27, 2010 12:57 pm

Re: 8x16 sprite is really a 16x32 pixel image?

Post by 3gengames » Fri Jan 11, 2013 1:00 pm

Well move it to the beginning of vblank? And are you updating your scroll after you do all nametable/$2006+$2007 writes? Is the scroll right? Are you catching when you have to write attributes to the new nametable?

unregistered
Posts: 1070
Joined: Thu Apr 23, 2009 11:21 pm
Location: cypress, texas

Re: 8x16 sprite is really a 16x32 pixel image?

Post by unregistered » Fri Jan 11, 2013 1:52 pm

3gengames wrote:are you updating your scroll after you do all nametable/$2006+$2007 writes? Is the scroll right? Are you catching when you have to write attributes to the new nametable?
I have set the PPU to increment by 32, after each write, and it messed up my screen and attribute tables. So I changed it back. ...Is it possible to set $2000 twice in the same vblank? :shock: That scares me.

tepples
Posts: 21936
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Re: 8x16 sprite is really a 16x32 pixel image?

Post by tepples » Fri Jan 11, 2013 2:26 pm

unregistered wrote:I have set the PPU to increment by 32, after each write, and it messed up my screen and attribute tables. So I changed it back. ...Is it possible to set $2000 twice in the same vblank?
Yes. Only the last write takes effect. Because the scroll position ($2000 and $2005) and the VRAM writing address ($2006) use the same variable inside the PPU, you need to rewrite that variable after you finish uploading nametable changes. Write the scroll position to $2005, write the upper bits of X and Y scroll, pattern table addresses, and sprite size to $2000, and turn rendering on in $2001.

unregistered
Posts: 1070
Joined: Thu Apr 23, 2009 11:21 pm
Location: cypress, texas

Re: 8x16 sprite is really a 16x32 pixel image?

Post by unregistered » Mon Jan 14, 2013 5:40 pm

Is PPUCTRL ($2000) register's bit 7 always susposed to be a one? Why would I ever need to not want an NMI to occur at the start of vblank? I'm just trying to understand $2000 better right now. :)

User avatar
Kasumi
Posts: 1292
Joined: Wed Apr 02, 2008 2:09 pm

Re: 8x16 sprite is really a 16x32 pixel image?

Post by Kasumi » Mon Jan 14, 2013 5:49 pm

If I were writing a bunch of tiles to $2007 (for say... drawing the initial screen after loading a level), and had rendering disabled I'd turn off NMIs. They would make the operation take slightly longer, because the NMI would have to run every frame while I'm writing the tiles instead of never. You could write the NMI routine to detect when you're doing this and immediately return in that case, but even then it's slower than not running at all and you have to code more.

unregistered
Posts: 1070
Joined: Thu Apr 23, 2009 11:21 pm
Location: cypress, texas

Re: 8x16 sprite is really a 16x32 pixel image?

Post by unregistered » Mon Jan 14, 2013 7:15 pm

Do my yellow additions below make sense? Or am I missing something? :oops:
Kasumi wrote:If I were writing a bunch of tiles to $2007 (for say... drawing the initial screen after loading a level), and had rendering disabled I'd turn off NMIs. They would make the operation take slightly longer,... because then the NMI would have to run every frame, while I'm writing the tiles, instead of it never running at all. You could write the NMI routine to detect when you're doing this and immediately return in that case, but even then it's slower than not running at all and you have to code more.

3gengames
Formerly 65024U
Posts: 2275
Joined: Sat Mar 27, 2010 12:57 pm

Re: 8x16 sprite is really a 16x32 pixel image?

Post by 3gengames » Mon Jan 14, 2013 7:25 pm

When the $2000 register has bit 7 set, it fires a NMI at VBlank. If it is not, it does not fire an IRQ, so your program will do whatever it does 100% uninterrupted. :)

Keep in mind, if you disable it, do something, and you come back and want to wait a frame, BIT $2002 to be safe to enable the screen in VBlank again. If an NMI happened when they're disabled, and you enable them, it'll automatically fire an NMI regardless of if it's in VBlank or not, which would mean your vblank would then writes to Palette, VRam, PPUCtrl, PPUMask, etc all during rendering, and that's bad! :)
Last edited by 3gengames on Mon Jan 14, 2013 7:54 pm, edited 1 time in total.

User avatar
Kasumi
Posts: 1292
Joined: Wed Apr 02, 2008 2:09 pm

Re: 8x16 sprite is really a 16x32 pixel image?

Post by Kasumi » Mon Jan 14, 2013 7:47 pm

unregistered: Seems about right. If I already have rendering disabled and am updating the PPU outside the NMI, having the NMI interrupt this task is kind of useless. Is that more clear? Well... maybe not totally useless. If you have a total playtime counter and use the NMI to time it, you'd still want them enabled.
3gengames wrote:it's automatically fire an NMI regardless of if it's in VBlank or not, which would mean your vblank would then writes to Palette, VRam, PPUCtrl, PPUMask, etc all during rendering, and that's bad! :)
Wow. I didn't know that. Good to know.

Post Reply