Zelda Screen Transitions Are Undefined Behaviour • Hacker News Board

Re: Zelda Screen Transitions Are Undefined Behaviour

#91

Post by lgg » Thu, Jul 18, 2019, 12:34 AM UTC

kazinator wrote: post #46

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.

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

We have no idea if it was even undefined in the first place, since the PPU documentation is not public.

You are correct thought, often guarantees about behavior can be made after the fact. Generally what happens these days is someone determines they need or want to use a certain undefined behavior. The hardware people then go, look at the RTL for the chip and confirm it behaves in a certain way, and then they UPDATE the documentation to explicitly document the newly guaranteed behavior.

Conversely, often something that is documented to work just doesn't. Especially in the case of console developers who tend to be using early steppings of custom silicon. In that case sometimes when you go to the HW team they fix it in the next stepping, sometimes they document it as errata and move on.

Re: Zelda Screen Transitions Are Undefined Behaviour

#92

Post by tenebrisalietum » Thu, Jul 18, 2019, 1:36 AM UTC

OJFord wrote: post #83

anon_cow1111 wrote: post #27

Earlier quoted context omitted.

*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?

Sometimes is really expensive for the server to determine the size of the response before actually responding, e.g. some database lookups where it may not be known how many rows are returnable until the lookup is actually done.

Then there are situations where response content length is not known, such as streaming over HTTP.

Last, if a certain "Accept-Content-Length" became standard, like 8MB, developers (such as those for the ad industry) would just create javascript libraries that would download large files in 8MB chunks and sidestep it.

Re: Zelda Screen Transitions Are Undefined Behaviour

#93

Post by tenebrisalietum » Thu, Jul 18, 2019, 1:39 AM 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…

The NES PPU has a bit that when set will blank the first 8 pixels of each scanline.

I think there are games out there that do use sprites to do the same on the other side.

Re: Zelda Screen Transitions Are Undefined Behaviour

#94

Post by jdsully » Thu, Jul 18, 2019, 2:10 AM UTC

bonzini wrote: post #58

jdsully wrote: post #49

Earlier quoted context omitted.

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.

Adding a a gate with jellybean logic was a noticeable expense in the 80s and would still be today.

Re: Zelda Screen Transitions Are Undefined Behaviour

#95

Post by 0xcde4c3db » Thu, Jul 18, 2019, 3:32 AM 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…

Also, the specific phrase "undefined behavior" is typically invoked in a context related to the C programming language. In the C standard and some standards related to it, undefined behavior is just one point on a spectrum of (un)definedness:

- implementation-defined: Not defined by the standard, but implementations must choose a consistent behavior and document it (e.g. what's shifted in when right-shifting signed integer types)

- unspecified: Not defined by the standard; implementations must choose some way of addressing the situation, but need not document it (e.g. the order in which function arguments are evaluated)

- undefined: Entirely outside the scope of the standard; implementations may assume that such situations never occur, and need not have any sensible or consistent behavior (e.g. dereferencing NULL)

In that taxonomy, I think this is much closer to "unspecified" than "undefined". The latter is usually used in scarier contexts like random memory corruption or crashes, not consistent behaviors that rely on deliberate implementation choices as we see here.

Re: Zelda Screen Transitions Are Undefined Behaviour

#96

Post by codebje » Thu, Jul 18, 2019, 4:51 AM UTC

MobiusHorizons wrote: post #68

Undefined behavior in C or C++ is possible because the language specification is built to deal with different hardware architectures, so it's not possible to build portable code. In the case of something like NES game development, there is only one hardware target, so the actual observed hardware behavior can be relied upon when doing things that aren't explicitly documented. In this case it is possible to know befor…

I'm not sure it's really true that the NES represents a single hardware target. There's two families of CPUs (2A03, 2A07) with different clock speeds depending on whether the device is NTSC or PAL, within each family there's a half dozen or more revisions, DRAM controller chips changed frequently causing many interesting variations in how and when the object attribute memory could be read (or not read, as the case may be).

And that's just the NES devices! The Famicoms were different again, there were at least two licensed clones, and dozens of unlicensed clones (if you, eg, wanted your game to sell in Russia, you'd care about being compatible with the Dendy as well as the genuine NES).

Re: Zelda Screen Transitions Are Undefined Behaviour

#97

Post by shultays » Thu, Jul 18, 2019, 8:36 AM UTC

It is not really undefined behavior when you have single hardware that will behave in a very well defined way. Old console games have all sort of hacks that allows them to do stuff that the system is not designed for. Having such a basic hardware with no security checks allows a lot of potential!

Also isn't vertical split quite common? I would assume this is something the hardware designera thought of, not a game company figuring it out. They even put stuff like sprite 0 hit bit for this kind of tricks

Re: Zelda Screen Transitions Are Undefined Behaviour

#98

Post by whermans » Thu, Jul 18, 2019, 9:40 AM UTC

jordanmorgan10 wrote: post #50

duxup wrote: 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."

Going as far as co-processors for 3D rendering[0] - image buying a game today that comes with its own GPU!

[0] https://en.wikipedia.org/wiki/Super_FX

Re: Zelda Screen Transitions Are Undefined Behaviour

#99

Post by Antonio123123 » Thu, Jul 18, 2019, 2:02 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.

It was much easier then to become experienced in programming because it was way less to learn.

Re: Zelda Screen Transitions Are Undefined Behaviour

#100

Post by sgrove » Thu, Jul 18, 2019, 8:39 PM UTC

justinplouffe wrote: post #29

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.

Wow, I just googled for a youtube video of gameplay [0] and I'm genuinely at a loss at how they pulled off that 3d engine. The sound fidelity is still pretty high given the lack of dedicated sound hardware on the GBA, and somehow they still have time left over for texture-mapped polygons.

I love reading about how programmers pulled off these tricks on such limited hardware, hopefully there are some notes about it somewhere on the internet.

[0] https://www.youtube.com/watch?v=K-AZQKTlUMs