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.
Zelda Screen Transitions Are Undefined Behaviour
41–50 of 101 posts
Re: Zelda Screen Transitions Are Undefined Behaviour
#42I 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.
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 also makes it so that it’s possible to do so. I find it fascinating. But I suppose the market would have just found different stabilizing points were this not the case.
Re: Zelda Screen Transitions Are Undefined Behaviour
#43Earlier quoted context omitted.
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.
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.
Re: Zelda Screen Transitions Are Undefined Behaviour
#44There 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.
> See http://bootgod.dyndns.org:7777/ for a database of the hardware inside each cartridge.
Wow, this is chock-full of content. I wish there was one for the Sega Master System too
Off-topic, but thought I'd link to this very fun comparison of various games across the two platforms: https://huguesjohnson.com/features/nes-vs-sms/
Re: Zelda Screen Transitions Are Undefined Behaviour
#45The NES designers goofed and made the size of the view window (nametable) 240 pixels tall. This makes vertical scrolling awkward as it throws a non-power-of-two divisor into the math. The NES doesn't have a division instruction - only bit shifts, so having to divide by 240 is a real pain!
Also, Y-scrolling wasn't completely figured out until late in the NES's life. The register writes needed to do so are very strange, and Zelda certainly doesn't do it correctly!
Re: Zelda Screen Transitions Are Undefined Behaviour
#46I 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.
Do we know that the developers didn't confirm this hack with the hardware people?
It could be "defined by e-mail".
Re: Zelda Screen Transitions Are Undefined Behaviour
#47The NES designers goofed and made the size of the view window (nametable) 240 pixels tall. This makes vertical scrolling awkward as it throws a non-power-of-two divisor into the math. The NES doesn't have a division instruction - only bit shifts, so having to divide by 240 is a real pain! Also, Y-scrolling wasn't completely figured out until late in the NES's life. The register writes needed to do so are very strange…
I believe that's one of the reasons that games such as Super Mario Bros 3 used additional hardware in the cartridge to do the y scrolling. The memory mapper had special support for just y scrolling and scanline counting.
Re: Zelda Screen Transitions Are Undefined Behaviour
#48It 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…
There were quite a few “professional” software packages written in BASIC at the time. Of course most software needed assembly in the early days.
Re: Zelda Screen Transitions Are Undefined Behaviour
#49Earlier quoted context omitted.
> 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.
That would have wasted precious cycles for games that didn’t need it. The ‘n’ in NMI stands for non-maskable.
Re: Zelda Screen Transitions Are Undefined Behaviour
#50It'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."