Zelda Screen Transitions Are Undefined Behaviour • Hacker News Board

Re: Zelda Screen Transitions Are Undefined Behaviour

#21

Post by daniel5151 » Wed, Jul 17, 2019, 3:15 PM UTC

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 certain limitations).

Lots of games used funky scrolling mechanics, typically to create status bars, but of all the different games I tested with, TLOZ was by-far the weirdest, requiring an entire special case to get working!

I don't have any screenshots of my own, but some japanese website recently covered wideNES, posting screenshots of it working with the original Legent of Zelda.[2]

[1] http://prilik.com/blog/2018/08/24/wideNES.html

[2] https://emulog.net/fc-nes-emulator-anese-how-to-use-widenes/

Re: Zelda Screen Transitions Are Undefined Behaviour

#22

Post by coldpie » Wed, Jul 17, 2019, 3:16 PM UTC

cdumler wrote: post #18

jedberg wrote: post #12

It feels like programming used to be a much harder job in the past. You not only had to figure out the program logic, but you had to work within very tight hardware constraints. Reading articles like this, or about the Atari and how the code would double as a sprite in pac-man, or how 3D was rendered in Wolfenstein, makes me think one had to be much more clever back then.

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…

> The 6502 CPU was developed literally by creating a hand drawn design. Each transistor laid out created additional complexity that humans had to understand.

Want to understand a tiny chunk of that complexity yourself? Check out how the addition operation overflow flag is implemented in silicon on the 6502: http://www.righto.com/2013/01/a-small-part-of-6502-chip-expl...

Re: Zelda Screen Transitions Are Undefined Behaviour

#23

Post by red75prime » Wed, Jul 17, 2019, 3:16 PM UTC

jedberg wrote: post #12

It feels like programming used to be a much harder job in the past. You not only had to figure out the program logic, but you had to work within very tight hardware constraints. Reading articles like this, or about the Atari and how the code would double as a sprite in pac-man, or how 3D was rendered in Wolfenstein, makes me think one had to be much more clever back then.

On the other hand you had all the hardware under your direct control. And right now I'm trying to find why kernel stashed 17MB of RAM, I really need.

Re: Zelda Screen Transitions Are Undefined Behaviour

#24

Post by llao » Wed, Jul 17, 2019, 3:18 PM UTC

Warning, 33 megabytes of (great) GIFs.

Re: Zelda Screen Transitions Are Undefined Behaviour

#25

Post by ubermonkey » Wed, Jul 17, 2019, 3:19 PM UTC

cdumler wrote: post #18

jedberg wrote: post #12

It feels like programming used to be a much harder job in the past. You not only had to figure out the program logic, but you had to work within very tight hardware constraints. Reading articles like this, or about the Atari and how the code would double as a sprite in pac-man, or how 3D was rendered in Wolfenstein, makes me think one had to be much more clever back then.

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

Re: Zelda Screen Transitions Are Undefined Behaviour

#26

Post by klodolph » Wed, Jul 17, 2019, 3:25 PM UTC

coldpie wrote: post #17

klodolph wrote: post #8

Earlier quoted context omitted.

Paperboy draws a bunch of black sprites along the left side of the screen to cover up the glitches. Depending on the game this can be acceptable, but you only have a budget of 8 sprites per scanline and 64 total sprites, and this technique can eat up a lot of that budget. Edit: as sibling comment noted, Paperboy does have custom logic on the cartridge, a 74HC161 4-bit counter. I think this is just used to switch betw…

There's an interesting parallel in Atari 2600 development here. When the screen is being drawn, the program must update the GPU registers in real-time with the progress of the electron beam across the screen. If the program doesn't update these registers quickly enough, graphic glitches will occur. Most games will poll the game state and prep for updating registers during each HBLANK period, but often this would take…

Given that the 2600 has the same CPU core and predates the NES/Famicom by six years, it's not surprising that a lot of the same tricks apply :)

For the NES, depending on the registers in question, it can be easy or hard to update them during horizontal blank. Changing the scroll registers is easy, the PPU was designed to make that possible, and gave you a sprite zero hit test so you could get the timing correct--which is how Super Mario Bros. draws the HUD at the top of the screen.

With some extra hardware you can make this easier and get some cool effects like parallax. The NES exposes a NMI line to the 6502 on the cartridge connector, and you can wire up some logic on the cartridge to signal NMI for every scanline. Battletoads uses this effectively. Atari 2600 lacks NMI because the 6507 doesn't have a pin for it.

Certain registers are much more difficult to change during horizontal blank, but not impossible. For example, palette entries. This requires very precise timing so it was very rare to see it. Indiana Jones and the Last Crusade changes the palette entries mid-frame, but only for the title screen.

Re: Zelda Screen Transitions Are Undefined Behaviour

#27

Post by anon_cow1111 » Wed, Jul 17, 2019, 3:26 PM UTC

daniel5151 wrote: post #21

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.

Re: Zelda Screen Transitions Are Undefined Behaviour

#28

Post by shareIdeas » Wed, Jul 17, 2019, 4:06 PM UTC

jedberg wrote: post #12

It feels like programming used to be a much harder job in the past. You not only had to figure out the program logic, but you had to work within very tight hardware constraints. Reading articles like this, or about the Atari and how the code would double as a sprite in pac-man, or how 3D was rendered in Wolfenstein, makes me think one had to be much more clever back then.

Idk man. Just to make a useful app I need to understand servers, databases, backend frameworks (for security), and front end.

Maybe it's finding creative solutions, but today there is a lot to know.

Re: Zelda Screen Transitions Are Undefined Behaviour

#29

Post by justinplouffe » Wed, Jul 17, 2019, 4:07 PM UTC

jedberg wrote: post #12

It feels like programming used to be a much harder job in the past. You not only had to figure out the program logic, but you had to work within very tight hardware constraints. Reading articles like this, or about the Atari and how the code would double as a sprite in pac-man, or how 3D was rendered in Wolfenstein, makes me think one had to be much more clever back then.

I’m currently doing a bit of Gameboy Advance programming for fun and I’m actually surprised by how simple most of it is at least for the basics. While some games on the platform do incredibly clever stuff (Super Monkey Ball Jr. being especially impressive), most of the popular titles use the standard tiled sprite rendering mode which is quite easy to understand and fast by default.

Re: Zelda Screen Transitions Are Undefined Behaviour

#30

Post by stopsayingthat » Wed, Jul 17, 2019, 4:12 PM UTC

shareIdeas wrote: post #28

jedberg wrote: post #12

It feels like programming used to be a much harder job in the past. You not only had to figure out the program logic, but you had to work within very tight hardware constraints. Reading articles like this, or about the Atari and how the code would double as a sprite in pac-man, or how 3D was rendered in Wolfenstein, makes me think one had to be much more clever back then.

Idk man. Just to make a useful app I need to understand servers, databases, backend frameworks (for security), and front end. Maybe it's finding creative solutions, but today there is a lot to know.

If by "understand" you mean glue together all of the high-level abstractions of each of those domains, each of which have mountains of tutorials / blog posts / StackOveflow answers, then sure.