Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Zelda Screen Transitions Are Undefined Behaviour

gridbugs.org

Post reply on HN
Print view View original

11–20 of 101 posts

Re: Zelda Screen Transitions Are Undefined Behaviour

#11

Post by eropple »

einr wrote: post #5
klodolph wrote: post #2

There are a few games that do diagonal scrolling. In general it's very difficult to do well on the NES, and you will likely have to live with some amount of glitching--unless you have extra name table RAM on the cartridge, which is fairly rare. See http://bootgod.dyndns.org:7777/ for a database of the hardware inside each cartridge.

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.

I read this and was shocked - surely this is incorrect!

Nope. Paperboy uses a CNROM, which is basically an MMC3. Maybe they're doing some clever edge-replacement stuff on the mirrored table, like SMB3 does with the same hardware? But you can see glitching when SMB3 does it.

(edit: my sibling post answers it. That's slick.)

Re: Zelda Screen Transitions Are Undefined Behaviour

#12

Post by jedberg »

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.

Re: Zelda Screen Transitions Are Undefined Behaviour

#13

Post by bloopernova »

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.

That "Graphics Programming Black Book" is available online here: http://www.drdobbs.com/parallel/graphics-programming-black-b...

Mode X or Q reminds me of the amazing Mode 7 SNES graphics used to great smooth effect in F-Zero and many other titles.

Re: Zelda Screen Transitions Are Undefined Behaviour

#14

Post by overcast »

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.

Harder to do tasks we take for granted now, sure. But today's games are EXTREMELY complex in comparison. Old games were intentionally made extremely difficult, to counter their simplicity in design. Else you'd be done with the whole game in 15 minutes.

Re: Zelda Screen Transitions Are Undefined Behaviour

#15

Post by im_down_w_otp »

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.

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 way or another, and then it was having that little trick in one's pocket which informed how the design would be.

Re: Zelda Screen Transitions Are Undefined Behaviour

#17

Post by coldpie »

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…

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 too long for certain scanlines and you'd end up with short black lines along the left margin. This was a very common issue, you can see it in lots of screenshots here: https://videogamecritic.com/2600tt.htm?e=85998#rev459

This wasn't a big problem, because TVs of the time often had big overscan areas (areas that were rendered, but covered by the TV's physical bezel). However, it was visible on many TVs, and today it is very visible under emulation. Activision's programmers found this unacceptable. Rather than perform the very difficult, or even impossible, task of making their code run faster than the HBLANK period, they instead chose to render the first cm or so of each scanline intentionally black! Notice the width of the screen in this screenshot compared to other nearby games: https://videogamecritic.com/2600ff.htm#rev203

More crazy tricks like this are described in the excellent "Racing the Beam" book by Nick Montfort and Ian Bogost.

Re: Zelda Screen Transitions Are Undefined Behaviour

#18

Post by cdumler »

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 event checked).

The 6502 has a few "undocumented" instructions due the fact that if you have certain on/off input pin set, you're actually crossing gates used for multiple instructions. These may crash the chip or do non-useful things, but a few do something useful in vary specific circumstances. The trick to developing on these old systems is to experiment with the chips to understand what the system does in various circumstances.

What I liked about that time was that it was possible to truly understand everything about a system because nothing is hidden from you by software drivers. The were good times.

Re: Zelda Screen Transitions Are Undefined Behaviour

#19

Post by magicalhippo »

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.

> You not only had to figure out the program logic, but you had to work within very tight hardware constraints.

Try programming microcontrollers and you can enjoy that feeling today! Get comfy with the relatively powerful ARM Cortex-M variants, which typically sports 10s of kB of RAM. Then if you feel frisky, try your hand at some 8-bit uC's with less than 64 bytes of RAM (spend your bits wisely).

https://jaycarlson.net/microcontrollers/

Re: Zelda Screen Transitions Are Undefined Behaviour

#20

Post by fred_is_fred »

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.

Not only more constraints but you had to use languages that took more work to do things, like C or Assembly.
Post reply on HN