Live data from Hacker News

Zelda Screen Transitions Are Undefined Behaviour

gridbugs.org

51–60 of 101 posts

Re: Zelda Screen Transitions Are Undefined Behaviour

#51

I don't think I would call this undefined behavior... the behavior is defined by what happens on the hardware when it's executed! There are many, many classical effects on raster hardware which are accomplished by changing registers within the horizontal blanking period... copper bars, mode 7, certain paralax scrolling. When you're on a resource limited system it becomes an art to get the most out of the platform. Lo…

Super Mario Bros, vs Super Mario 3 (NES) Combat vs Keystone Kapers (Atari 2600)

Re: Zelda Screen Transitions Are Undefined Behaviour

#52
post #24

Warning, 33 megabytes of (great) GIFs.

It's probably about time that WebP should get promoted, especially instead of animated GIF. the libwebp library comes with a gif2webp program to make the conversion especially easy.

Just doing it now, converting all the animations to WebP makes it 1.6MB. and it works in all current browsers.

Re: Zelda Screen Transitions Are Undefined Behaviour

#53
Vertical scrolling, and emulating the weird side-effects of the registers being written to, was the hardest part of recreating the NES using 3D meshes. It took me a few weekends to get Zelda 2's intro working reliably. I wrote about it a bit myself (probably got a few details wrong or simplified them) here:

http://n3s.io/index.php?title=How_It_Works

Re: Zelda Screen Transitions Are Undefined Behaviour

#54

I actually had to wrestle with this exact effect while working on wideNES [1]. By saving a screenshot of the screen at each frame alongside with it's PPUSCROLL value, it's possible to gradually build-up a map of the level as it's explored. Moreover, on subsequent playthroughs of the same level, it's possible to sync the map with the on-screen action, effectively enabling a "widescreen" mode for old NES games (with ce…

*Note to mobile/metered internet users: first link contains 30MB+ of gif images, click at own risk.

I got flashbacks of 2000s with this comment

Re: Zelda Screen Transitions Are Undefined Behaviour

#55
post #45

The NES designers goofed and made the size of the view window (nametable) 240 pixels tall. This makes vertical scrolling awkward as it throws a non-power-of-two divisor into the math. The NES doesn't have a division instruction - only bit shifts, so having to divide by 240 is a real pain! Also, Y-scrolling wasn't completely figured out until late in the NES's life. The register writes needed to do so are very strange…

I believe that's one of the reasons that games such as Super Mario Bros 3 used additional hardware in the cartridge to do the y scrolling. The memory mapper had special support for just y scrolling and scanline counting. http://wiki.nesdev.com/w/index.php/MMC3

Oh, you don't need special hardware to do y-scrolling correctly. It's just a strange set of writes: $2006, $2005, $2005, $2006. MMC3 is for the scanline counter, which allowed SMB3 to have the score bar on the bottom of the screen.

Re: Zelda Screen Transitions Are Undefined Behaviour

#56

I actually had to wrestle with this exact effect while working on wideNES [1]. By saving a screenshot of the screen at each frame alongside with it's PPUSCROLL value, it's possible to gradually build-up a map of the level as it's explored. Moreover, on subsequent playthroughs of the same level, it's possible to sync the map with the on-screen action, effectively enabling a "widescreen" mode for old NES games (with ce…

That was a great write-up. Thanks for sharing.

You could probably run an async loop which slices up painted frames and compares hashes of the slices to find identical slices to anchor and stitch similar frames together, still maintaining separate layers in case a better match is found later on. Something like that should solve for games like SMB.

Re: Zelda Screen Transitions Are Undefined Behaviour

#57
post #45

The NES designers goofed and made the size of the view window (nametable) 240 pixels tall. This makes vertical scrolling awkward as it throws a non-power-of-two divisor into the math. The NES doesn't have a division instruction - only bit shifts, so having to divide by 240 is a real pain! Also, Y-scrolling wasn't completely figured out until late in the NES's life. The register writes needed to do so are very strange…

You can probably do it without divisions if you use the name table creatively... You can place line 720 of the input at line 192 of the name table (720 modulo 256 is 192) as long as everything above and below it is displayed correctly.

Re: Zelda Screen Transitions Are Undefined Behaviour

#58
post #49

Earlier quoted context omitted.

Given that the NES had NMI and the 2600 didn't, I think that NMI probably should have been wired to horizontal blank to begin with. I'm sure that there is some reason why this wasn't done, but I can't understand why.

That would have wasted precious cycles for games that didn’t need it. The ‘n’ in NMI stands for non-maskable.

You can always mask it (enable/disable) at the place that triggers the NMI.

Re: Zelda Screen Transitions Are Undefined Behaviour

#59
post #18

Earlier quoted context omitted.

The catch about developing things back then is that you were working with duct tape and chicken wire. The 6502 CPU was developed literally by creating a hand drawn design. Each transistor laid out created additional complexity that humans had to understand. Therefore, making it as simple as possible by reducing the gates used to a minimum was important. This also meant that not all combinations inputs were valid (or…

This reminder of undocumented behavior reminded me of The story of Mel, a Real Programmer. See http://www.pbm.com/~lindahl/mel.html

I'd never seen that photo before. Mel looks a bit like Brad Pitt from far away.

Re: Zelda Screen Transitions Are Undefined Behaviour

#60

I don't think I would call this undefined behavior... the behavior is defined by what happens on the hardware when it's executed! There are many, many classical effects on raster hardware which are accomplished by changing registers within the horizontal blanking period... copper bars, mode 7, certain paralax scrolling. When you're on a resource limited system it becomes an art to get the most out of the platform. Lo…

I'd love to compare but I don't know what Persona's giant enemy crabs look like.
Post reply on HN