nesdev.com
https://forums.nesdev.com/

8x16 and whatever else unreg wants to know
https://forums.nesdev.com/viewtopic.php?f=10&t=7451
Page 59 of 93

Author:  unregistered [ Wed Jan 09, 2013 11:14 am ]
Post subject:  Re: 8x16 sprite is really a 16x32 pixel image?

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.

Author:  unregistered [ Wed Jan 09, 2013 12:57 pm ]
Post subject:  Re: 8x16 sprite is really a 16x32 pixel image?

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


Code:
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 -

Author:  tepples [ Wed Jan 09, 2013 1:39 pm ]
Post subject:  Re: 8x16 sprite is really a 16x32 pixel image?

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.

Author:  unregistered [ Wed Jan 09, 2013 3:19 pm ]
Post subject:  Re: 8x16 sprite is really a 16x32 pixel image?

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?

Author:  tepples [ Wed Jan 09, 2013 3:36 pm ]
Post subject:  Re: 8x16 sprite is really a 16x32 pixel image?

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.

Author:  unregistered [ Wed Jan 09, 2013 4:00 pm ]
Post subject:  Re: 8x16 sprite is really a 16x32 pixel image?

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

Author:  unregistered [ Fri Jan 11, 2013 11:26 am ]
Post subject:  Re: 8x16 sprite is really a 16x32 pixel image?

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, on page 43, wrote:
Setting the scroll should ALWAYS be the very last thing in your VBlank handler.

Author:  3gengames [ Fri Jan 11, 2013 1:00 pm ]
Post subject:  Re: 8x16 sprite is really a 16x32 pixel image?

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?

Author:  unregistered [ Fri Jan 11, 2013 1:52 pm ]
Post subject:  Re: 8x16 sprite is really a 16x32 pixel image?

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.

Author:  tepples [ Fri Jan 11, 2013 2:26 pm ]
Post subject:  Re: 8x16 sprite is really a 16x32 pixel image?

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.

Author:  unregistered [ Mon Jan 14, 2013 5:40 pm ]
Post subject:  Re: 8x16 sprite is really a 16x32 pixel image?

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. :)

Author:  Kasumi [ Mon Jan 14, 2013 5:49 pm ]
Post subject:  Re: 8x16 sprite is really a 16x32 pixel image?

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.

Author:  unregistered [ Mon Jan 14, 2013 7:15 pm ]
Post subject:  Re: 8x16 sprite is really a 16x32 pixel image?

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.

Author:  3gengames [ Mon Jan 14, 2013 7:25 pm ]
Post subject:  Re: 8x16 sprite is really a 16x32 pixel image?

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! :)

Author:  Kasumi [ Mon Jan 14, 2013 7:47 pm ]
Post subject:  Re: 8x16 sprite is really a 16x32 pixel image?

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.

Page 59 of 93 All times are UTC - 7 hours
Powered by phpBB® Forum Software © phpBB Group
http://www.phpbb.com/