Zelda Screen Transitions Are Undefined Behaviour • Hacker News Board

Re: Zelda Screen Transitions Are Undefined Behaviour

#31

Post by yc-kraln » Wed, Jul 17, 2019, 4:13 PM UTC

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. Look at the difference between Mario 64 and Conker's Bad Fur Day... or Genji: Days of the Blade (PS3) vs Persona 5 (PS3) Even with modern consoles, there is a marked improvement in the apparent visual quality over the lifetime of the device, as developers learn how to squeeze more and more out of the platform.

Re: Zelda Screen Transitions Are Undefined Behaviour

#32

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

stopsayingthat wrote: post #30

shareIdeas wrote: post #28

Earlier quoted context omitted.

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.

Gluing them is only 1 step.

You still need to write the logic that each layer needs to be useful.

Re: Zelda Screen Transitions Are Undefined Behaviour

#33

Post by toast0 » Wed, Jul 17, 2019, 4:19 PM UTC

klodolph wrote: post #26

coldpie wrote: post #17

Earlier quoted context omitted.

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--whic…

> gave you a sprite zero hit test so you could get the timing correct

This was a workaround to avoid Atari patents. On the 2600 you could write to a register to halt the CPU until horizontal blanking (commonly written as sta WSYNC), to get perfectly synchronized to the next scanline. Sprite zero is more flexible, but the timing isn't as precise.

Re: Zelda Screen Transitions Are Undefined Behaviour

#34

Post by dllthomas » Wed, Jul 17, 2019, 4:22 PM UTC

yc-kraln wrote: post #31

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…

> developers learn how to squeeze more and more out of the platform

That's a part of it, to be sure, but another dynamic is that developers have to squeeze more out of the system. Dropping old techniques on new hardware will probably give you a game that looks "better" than what's already out. Once everyone has done that, to look "better" you need something new other than hardware.

Re: Zelda Screen Transitions Are Undefined Behaviour

#35

Post by EGreg » Wed, Jul 17, 2019, 4:27 PM UTC

meta-irony: "in a manor likely that was unintended by its designers"

Re: Zelda Screen Transitions Are Undefined Behaviour

#36

Post by papln » Wed, Jul 17, 2019, 4:30 PM UTC

yc-kraln wrote: post #31

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…

"Unefined" refers to the spec, not the hardware.

https://en.wikipedia.org/wiki/Undefined_behavior

This case appears to be "undocumented scenario" or "unsupported use-case", though.

Re: Zelda Screen Transitions Are Undefined Behaviour

#37

Post by papln » Wed, Jul 17, 2019, 4:32 PM UTC

coldpie wrote: post #9

einr wrote: post #6

Earlier quoted context omitted.

Nitpicking, but SMB3 uses the MMC3 chip which "adds an IRQ timer to allow split screen scrolling without the sacrifice of sprite 0" (Wikipedia) so it does not use this technique. SMB1 actually also does not use the sprite zero split technique because it never scrolls vertically. Its status bar is just a bunch of fixed background tiles.

Ah, didn't know that about the MMC3! Regarding SMB1, I'm quite sure it uses the sprite 0 thing to keep the status bar stationary while the level scrolls smoothly beneath it by setting the scroll register only after when the status bar is done drawing. See more thorough description here: https://retrocomputing.stackexchange.com/questions/1898/how-...

The article is confusing. The headline/lede claim is about partial vertical scrolling. The middle is a long detour to partial horizontal scrolling (well documented, including SMB1), and then the end goes back to talk about partial vertical scrolling (Zelda).

Re: Zelda Screen Transitions Are Undefined Behaviour

#38

Post by klodolph » Wed, Jul 17, 2019, 4:32 PM UTC

toast0 wrote: post #33

klodolph wrote: post #26

Earlier quoted context omitted.

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--whic…

> gave you a sprite zero hit test so you could get the timing correct This was a workaround to avoid Atari patents. On the 2600 you could write to a register to halt the CPU until horizontal blanking (commonly written as sta WSYNC), to get perfectly synchronized to the next scanline. Sprite zero is more flexible, but the timing isn't as precise.

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.

Re: Zelda Screen Transitions Are Undefined Behaviour

#39

Post by raverbashing » Wed, Jul 17, 2019, 4:33 PM UTC

baruchthescribe wrote: post #10

This reminds me a lot of Mode X which, although a funky 320x240 mode with square pixels built in to standard VGA, only became popular after Michael Abrash popularized it in Dr Dobbs. And then there was the utterly gorgeous mode Q - 256x256 with 256 colors. No muls or shifts - high byte is Y and low byte is X.

It's funny, you get Mode X by not picking a mode "the easy way" (like mode 0x13 for 320x200x256) but by setting the lower level registries in the VGA controller, it's an unofficial mode

Re: Zelda Screen Transitions Are Undefined Behaviour

#40

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

shareIdeas wrote: post #32

stopsayingthat wrote: post #30

Earlier quoted context omitted.

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.

Gluing them is only 1 step. You still need to write the logic that each layer needs to be useful.

This is true, and I don't mean to trivialize the work of today's programmer.

However, I suppose somewhat subjectively in reviewing or writing any of this glue or logic layer code using modern web frameworks I've never had the sort of WOW response that I do when I see what the programmers of yore were coming up with.