Zelda Screen Transitions Are Undefined Behaviour • Hacker News Board

Re: Zelda Screen Transitions Are Undefined Behaviour

#81

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

papln wrote: post #36

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.

This definitely does not appear to be an “unsupported use-case”. This technique is used in many first-party launch titles. As far as I can tell, this is the reason that sprite zero tests exist in the first place.

If you want an example of something that’s really an unsupported use case, consider mid-frame palette changes—in order to do this, you actually have to disable and re-enable rasterization during the horizontal blanking interval. It works, but it is difficult to get right and the PPU is clearly not designed with this in mind.

Short of having an actual spec in hand, it would appear that mid-frame scroll register updates were entirely normal and an intended way to use the device, based on the evidence (no other reason for sprite zero check, lots of first-party titles using this feature, other mid-frame updates are much more difficult).

Re: Zelda Screen Transitions Are Undefined Behaviour

#82

Post by derefr » Wed, Jul 17, 2019, 10:45 PM UTC

kazinator wrote: post #76

derefr wrote: post #73

Earlier quoted context omitted.

I meant "best" as in "most practical for a third-party dev when deciding what behaviors to take advantage of." Defined behaviors are guaranteed to work in both 1. clone consoles that conform to the spec, and 2. future revisions of the official hardware. Undefined behaviors aren't.

Future revisions of the hardware can throw everything out the window regardless of what is documented for the current hardware. What NES cartridge from 1986 can you plug into current Nintendo boxes?

I think you're confusing "revision" with "generation." Revisions are the difference between e.g. the original SNES, and the 1CHIP (SoC) SNES console, not between the original SNES and the SNES Classic.

Even though the 1CHIP SNES is a complete ground-up re-layout (has to be, turning a bunch of individual chips into one SoC), every (officially licensed) cartridge made for "the SNES" works on a 1CHIP SNES.

A hardware revision like this, requires retaining bug-for-bug UB compatibility with officially-sanctioned released game titles, because to do otherwise is to doom the console's support line to endless complaints from people whose games don't work. But hardware revisions are not concerned with keeping UB working the same where no officially-sanctioned released title took advantage of said UB. For everything not constrained by bug-for-bug compat with an existing title, all that's required of the new revision is that it keeps to the spec.

If you were a third-party in the middle of developing a new title, and were relying on some new UB you found, when suddenly your console mfgr released a new revision, it could turn out that your clever UB hack won't work the same on the new revision. (And this happened; it was why unlicensed titles—your Game Genies, your Aladdin Deck Enhancers, etc.—frequently wouldn't work with later console revisions.)

Re: Zelda Screen Transitions Are Undefined Behaviour

#83

Post by OJFord » Wed, Jul 17, 2019, 10:55 PM UTC

anon_cow1111 wrote: post #27

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.

Why isn't there an HTTP request header like 'Accept-Content-Length' to limit maximum response size?

Re: Zelda Screen Transitions Are Undefined Behaviour

#84

Post by sgrove » Wed, Jul 17, 2019, 11:04 PM UTC

derefr wrote: post #82

kazinator wrote: post #76

Earlier quoted context omitted.

Future revisions of the hardware can throw everything out the window regardless of what is documented for the current hardware. What NES cartridge from 1986 can you plug into current Nintendo boxes?

I think you're confusing "revision" with "generation." Revisions are the difference between e.g. the original SNES, and the 1CHIP (SoC) SNES console, not between the original SNES and the SNES Classic. Even though the 1CHIP SNES is a complete ground-up re-layout (has to be, turning a bunch of individual chips into one SoC), every (officially licensed) cartridge made for "the SNES" works on a 1CHIP SNES. A hardware re…

There's a fascinating story of Pilotwings being (very gently) bitten by a very slightly different hardware revisions that causes the idle animation plane to just barely crash rather than land safely: http://www.nintendolife.com/news/2019/05/random_the_captivat...

Re: Zelda Screen Transitions Are Undefined Behaviour

#85

Post by cableshaft » Wed, Jul 17, 2019, 11:05 PM UTC

Bluecobra wrote: post #3

Thanks for posting this... as a non-programmer, I really enjoy reading how the games I grew up with worked. If you enjoyed reading this, there's a great Youtube channel called Retro Game Mechanics Explained: https://www.youtube.com/channel/UCwRqWnW5ZkVaP_lZF7caZ-g/vid...

I didn't know this channel existed and it's very interesting. Thanks for sharing it.

Re: Zelda Screen Transitions Are Undefined Behaviour

#86

Post by inlined » Wed, Jul 17, 2019, 11:48 PM UTC

wutbrodo wrote: post #70

nkohari wrote: post #43

Earlier quoted context omitted.

I think the real reason for this might be that clever hacks using current technology are looked on with disdain, whereas yesterday's hacks are seen as impressive ways of making the most of limited hardware and tooling.

To me, that's a sign of the engineering discipline having matured (as well as average computational needs not keeping pace with computational power). My first job out of college was at Google, and I remember being somewhat disappointed the first time I was told to replace some elegant, dense logic with something more readable. After years of having to read other people's prematurely optimized or unnecessarily compact…

That can be the difference in how the software is deployed. At Google, most things are horizontally scaled and machines are cheaper than engineers. When I worked on Windows, it was the opposite: I was told to refactor clean multithreaded code to reduce the thread count by one. The rationale was that Windows scales vertically and every developer wasting a thread is how Windows gets slower over time.

Re: Zelda Screen Transitions Are Undefined Behaviour

#87

Post by inlined » Wed, Jul 17, 2019, 11:51 PM UTC

syn0byte wrote: post #71

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.

Survivor bias. Plenty of shite code got written for the 6508 but only clever crap gets blog posts 30+ years after the fact.

Zelda survived partially because it was so revolutionary. It was the first game so complex that it invented game saves.

https://www.vice.com/amp/en_us/article/9a3b8y/why-zelda-was-...

Re: Zelda Screen Transitions Are Undefined Behaviour

#88

Post by zeta0134 » Wed, Jul 17, 2019, 11:59 PM UTC

klodolph wrote: post #8

einr wrote: post #5

Earlier quoted context omitted.

There are a few games that do diagonal scrolling. Paperboy comes to mind. It's smooth and looks good without any noticable glitching, and without using custom chips, too. Not sure how they did it.

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…

Lots of other games have custom logic in the cartridge. Super Mario 3 and Kirby's Adventure both have a scanline counter in the cartridge that works by snooping the graphics chip while it reads the sprite and background tiles. Because the access patterns were consistent and well understood, it could keep track of where the console was mid-frame and trigger an interrupt, making it much easier to do scroll splits and fancy raster effects. Go check out the final boss from Kirby's Adventure, or the crazy rotating stage in Butter Building, and remember that the NES is doing that with a single background.

Some of this may have been undefined behavior, but the MMC3 chipset involved was produced and manufactured by Nintendo. Whatever the original design was, Nintendo appears to have stuck with that same set of capabilities throughout the console's lifetime, and encouraged their developers to take advantage of all the tricks.

Re: Zelda Screen Transitions Are Undefined Behaviour

#89

Post by makomk » Thu, Jul 18, 2019, 12:09 AM UTC

klodolph wrote: post #81

papln wrote: post #36

Earlier quoted context omitted.

"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.

This definitely does not appear to be an “unsupported use-case”. This technique is used in many first-party launch titles. As far as I can tell, this is the reason that sprite zero tests exist in the first place. If you want an example of something that’s really an unsupported use case, consider mid-frame palette changes—in order to do this, you actually have to disable and re-enable rasterization during the horizont…

The sprite zero check is useful for changing the horizontal scroll position mid-frame, which is something the hardware seems to be designed to support - it helpfully copies the value written to the scroll register to the internal horizontal scroll position at the end of each scanline. It does not seem to be designed to make the same thing possible for vertical scrolling. The programmed register value for vertical scroll is read once at the start of each frame.

Re: Zelda Screen Transitions Are Undefined Behaviour

#90

Post by dllthomas » Thu, Jul 18, 2019, 12:23 AM UTC

furyofantares wrote: post #42

dllthomas wrote: post #34

Earlier quoted context omitted.

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

That’s another part of it, to be sure, but yet another dynamic is that it being a mostly fixed system, rather than a wide array of target hardware, is what makes it feasible to implement these tricks and accumulate knowledge in the first place. It all kind of goes hand-in-hand — the fixed nature of the hardware makes it so you have to find these tricks in order to compete with games that play on newer hardware, and a…

Agreed.