Live data from Hacker News

Zelda Screen Transitions Are Undefined Behaviour

gridbugs.org

71–80 of 101 posts

Re: Zelda Screen Transitions Are Undefined Behaviour

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

Re: Zelda Screen Transitions Are Undefined Behaviour

#72

Earlier quoted context omitted.

Do we know that the developers didn't confirm this hack with the hardware people? It could be "defined by e-mail".

You are playing semantics to try to justify it. If it's not in the official spec, it's undefined behavior.

Does anyone actually care? This was embedded software designed to run on exactly one system, not some libc designed to run on 20 architectures ranging from 8-bit microcontrollers to VLIW supercomputers.

Re: Zelda Screen Transitions Are Undefined Behaviour

#73
post #66

Earlier quoted context omitted.

The best definition of "undefined behavior" is: "if some other company created a clone of this console by following the spec to the letter, but otherwise making all their own decisions... would this game run?" Of course, if you don't have cloners immediately nipping at your heels, you might end up releasing a smash hit that takes advantage of UB in a way that forces you to define the behavior as "it works however it…

It's not "best" enough to actually appear in a Nintendo spec somewhere, unfortunately.

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.

Re: Zelda Screen Transitions Are Undefined Behaviour

#74
post #41

It's always interesting how the NES cartridges had their own hardware that could expand the system's capability. Allowing for simple cartridges for simple games and more expensive cartridges for more advanced games.

The same idea extended to the SNES too if I recall, a quick dig up on Wikipedia: "The system was designed to accommodate the ongoing development of a variety of enhancement chips integrated in game cartridges to be competitive into the next generation."

I wonder if we'll ever get back to that sort of thing... I guess with digital downloads not so much, but i really like the idea.

Re: Zelda Screen Transitions Are Undefined Behaviour

#75
post #72

Earlier quoted context omitted.

You are playing semantics to try to justify it. If it's not in the official spec, it's undefined behavior.

Does anyone actually care? This was embedded software designed to run on exactly one system, not some libc designed to run on 20 architectures ranging from 8-bit microcontrollers to VLIW supercomputers.

What I find interesting is looking for creative ways to prioritize the game experience even when the 'official spec' didn't support it. They could have given up by accepting that the spec represented the limit of what could be done, but instead pushed to find a better way.

I hadn't put thought into how important that scroll effect is to the game, but if there was a clean wipe between scenes it would have been tremendously distracting. This technique really is essential to the feeling of immersion.

Re: Zelda Screen Transitions Are Undefined Behaviour

#76
post #73

Earlier quoted context omitted.

It's not "best" enough to actually appear in a Nintendo spec somewhere, unfortunately.

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?

Re: Zelda Screen Transitions Are Undefined Behaviour

#77
post #74

Earlier quoted context omitted.

The same idea extended to the SNES too if I recall, a quick dig up on Wikipedia: "The system was designed to accommodate the ongoing development of a variety of enhancement chips integrated in game cartridges to be competitive into the next generation."

I wonder if we'll ever get back to that sort of thing... I guess with digital downloads not so much, but i really like the idea.

Well with xCloud coming up from Microsoft, and Sony partnering with them on cloud gaming - we appear to be going in the opposite direction, for better or worse.

Re: Zelda Screen Transitions Are Undefined Behaviour

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

You still have to be clever like that today depending on what kind of problems you're working on. Which was also true back then. Not all programmers back then had to derive arcanely clever tricks to get their job done. There's also a part of it that is underappreciated, which is that sometimes the cool effect wasn't necessarily an original design goal, but instead was sometimes something that was stumbled upon one wa…

One good example of this: Space Invaders was, AFAIK, the first game to feature escalating difficulty over time (because the aliens speed up the more of them you shoot). This wasn't originally part of the design; the system just couldn't run at the same framerate while managing 30 sprites as it could at 5, and there weren't any enforced timing checks.

Re: Zelda Screen Transitions Are Undefined Behaviour

#79
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?

The argument that GP seems to be making is that only relying on defined behavior ensures that your game will work on all NES systems made by Nintendo as well as any clone systems that follow the specifications that Nintendo issued for programmers on the NES.

Re: Zelda Screen Transitions Are Undefined Behaviour

#80
post #74

Earlier quoted context omitted.

The same idea extended to the SNES too if I recall, a quick dig up on Wikipedia: "The system was designed to accommodate the ongoing development of a variety of enhancement chips integrated in game cartridges to be competitive into the next generation."

I wonder if we'll ever get back to that sort of thing... I guess with digital downloads not so much, but i really like the idea.

We have some sorts of similar things. EyeToy and Kinect were additional hardware added to the system for games; not on the same media as the games though. The difference is expansion hardware today is always going to be subordinate to the main system --- the economics and data transfer realities don't work out to put a polygon processing enhancement in a USB add-on; but the cartridge slot has immense potential and it could also be cheaper to use the base system with enhancements than to release a whole new enhanced system (although, it's not clear to me how much the base genesis/megadrive benefits the 32x)
Post reply on HN