Hardware tricks and tidbits.

[crazyjackcsa]

Does anybody know a good site that documents tricks developers used on various consoles?

For instance, the blend feature on the Genesis to get more colors, using the sound chip in the Saturn for graphics effects on Shining Force 3, and the Dreamcast not rendering polygons that couldn't be seen on screen.

I'm always interested in the little things a developer, or hardware does to eek out a little more performance.

[Clownzilla]

The sad thing is that most of the time game makers no longer have to worry about tricks like these to get their games to work. Now, most of the time they have all the juice they need. Just cram some fancy graphics and loud noises on a DVD and that is what we now call a game. The harsher system restrictions of the past is what made programmers think outside of the box and make the most of what they had. In turn they were able to become more in tune with what they were making. It's just not the same now.....

[R.Sakai]

The Dreamcast only rendering only what was on screen was a part of it's GPU, a PowerVR based chip (It was a beefy neon? I remember reading it wasn't quite Kyro 1 level).

I remember thinking it was the coolest thing in the world that my Computer and my most current video game console at the time had very similar gpus, loved the image quality on that Kyro2.

[crazyjackcsa]

The Dreamcast only rendering only what was on screen was a part of it's GPU, a PowerVR based chip (It was a beefy neon? I remember reading it wasn't quite Kyro 1 level).

I remember thinking it was the coolest thing in the world that my Computer and my most current video game console at the time had very similar gpus, loved the image quality on that Kyro2.

Right, and at the time it was a rare quality to have. In theory it doubled the power of the DC.

[NayusDante]

I know for a fact that Indiana Jones and the Infernal Machine overcame the N64's texture limitations by using multiple layers and compression.

Chrono Cross has something like 40 characters, whose script data would not have fit on the two discs given the rest of the game's content. Instead, they wrote a procedural dialog system that had each character's mannerisms and speech patterns, so there's only one script no matter which three characters are in your party.

There was something special about how Burning Rangers employed transparencies on the Saturn, considering that the hardware didn't officially support transparency.


Then, of course, there's the old "throw more hardware at the problem" solution. Capcom, Konami, and Argonaut are pretty well known for their contributions to this forgotten technique.

[tomaitheous]

Does anybody know a good site that documents tricks developers used on various consoles?

Some of these explanations requires a solid low level understanding of the hardware and format.


For instance, the blend feature on the Genesis to get more colors

That's an easy one. It's called really crappy video output. There weren't any special tricks to enable this 'feature'. And people in PAL land with SCART RGB output BITD didn't see any blend feature ;)



There was something special about how Burning Rangers employed transparencies on the Saturn, considering that the hardware didn't officially support transparency.


The hardware supports transparency just fine. It's how it doesn't correctly output multiple/combined layers of transparencies. A surface that is distorted and wrapped in a way that overlaps itself isn't rendered correctly on those transparent overlapping parts. I believe it's a color transparency calculation bug. Non overlapping transparency overlapping surfaces are fine.

[Ed Oscuro]

I know for a fact that Indiana Jones and the Infernal Machine overcame the N64's texture limitations by using multiple layers and compression.
In other words, it worked around them. Same story with Conker's BFD.


[...] the Dreamcast not rendering polygons that couldn't be seen on screen.
Ahh, to be in 2000 again...back when visibility culling algorithms were all the rage (and let's not forget occlusion trees / maps, leading to the long-popular map format named BSP). Unless something has changed, I believe that as polygon fill rates have improved this has become less of an issue than it once was - the cure (culling polygons that can't be seen) may be slower than simply rendering them in the powerful graphics hardware seen today. Probably one of the more headline-grabbing developments in 3D graphics, though, up there with normal / bump / whatever maps.

[XYXZYZ]

Flickering was kind of a neat trick on NES games, if you didn't have enough memory for, say, 4 sprites on the screen at one time, two objects would share a specific address and alternate their displayed sprites back and fourth between clock cycles. So you really only have three sprites displayed at any given time.

At least I think that's what flickering was all about, wasn't it?

[NayusDante]

Flickering was kind of a neat trick on NES games, if you didn't have enough memory for, say, 4 sprites on the screen at one time, two objects would share a specific address and alternate their displayed sprites back and fourth between clock cycles. So you really only have three sprites displayed at any given time.

At least I think that's what flickering was all about, wasn't it?

I dunno, but Mega Man 2's fortress bosses sure do flicker a lot. Standing on the floating blocks shooting a dozen Quick Boomerangs at the GIANT dragon who is shooting four rather large fireballs... every sprite on the screen is flickering, and so is half of my health bar! It's really neat to see it done there, but it makes me wonder why the other games in the series had so much slowdown with more than two enemies onscreen, particularly 3.

Speaking of NES sprites, I know I heard something about Punch Out using a special graphics mode to get large sprites onscreen.

I've also noticed some neat tricks with NES audio, concerning the limited number of audio channels. Again using Mega Man as an example, sound effects often play in the same audio channel as one of the background music instruments, muting that instrument for the duration of the SE. This allows for much more complex music than if the channels weren't shared.

[jb143]

You also used to see a lot of palette effects. Palette swapping to get more characters, lighting effects in early 3D games, and rotating through the palettes to simulate 3D motion in racing games.

[Ed Oscuro]

Flickering was kind of a neat trick on NES games, if you didn't have enough memory for, say, 4 sprites on the screen at one time, two objects would share a specific address and alternate their displayed sprites back and fourth between clock cycles. So you really only have three sprites displayed at any given time.
It wasn't exactly "memory," since the position of all the sprites would remain in the program and processed as normal.

Wikipedia has a somewhat technical explanation of hardware sprites (http://en.wikipedia.org/wiki/Sprite_%28computer_graphics%29#Hardware_sprites), to boil it down: Every time you render another line, you take the background, onto which the correct line of the sprite you want to include is pulled out and pasted on. I assume the limit of hardware sprites means that only a set amount of time is available for adding sprites to each line, meaning that if you have more than a certain number of sprites jousting for the same space, you'll need to alternate the scan cycles (frames) each is visible to keep them from clashing. The more sprites seen onscreen at any particular line, the longer number of scans you'll need before you can see any particular sprite showing up for its one frame of fame (groan).

This all leads into a point I wanted to make, which is the seldom-discussed but to my mind rather interesting topic of varying dot artifacts conjured up by video, which I guess is probably done at the same time the video is put together. See here (http://www.disgruntleddesigner.com/chrisc/gotRGB/screenshots.html) again.

[tomaitheous]

Flickering was kind of a neat trick on NES games, if you didn't have enough memory for, say, 4 sprites on the screen at one time, two objects would share a specific address and alternate their displayed sprites back and fourth between clock cycles. So you really only have three sprites displayed at any given time.

At least I think that's what flickering was all about, wasn't it?


Flickering is this: It's a work around to show more sprites on a scanline than normally possible.

The NES PPU (the video processing unit) can only show eight 8x8 (or 8x16) cells on a single scanline - even though it has a sprite table containing 64 sprites. That means it can *only* fetch up to 64 sprite pixels in a single scanline - in groups of 8 horizontal rows of pixels. So when there are 9 or more sprites on that same scanline, the PPU doesn't have enough speed to fetch them.. so they *aren't* shown. This is called sprite drop out or blank out. The remedy is to alternate between two sprites tables every other frame. Now, there is a sprite "overflow" flag from the PPU that the game code can read/detect to see if too many sprites are in a row onscreen. And if so, it can alternate between drawing the first 8 and the rest. So on one frame you have one set and the other frame you have another set shown.

The down side is that both sets of sprites on that scanline become transparent, so to speak. Because they are alternating at a really fast rate. The up side is at least you can actually see the other sprites on that line. A necessary evil. Some games/companies/coders/teams are obviously better at handling sprite management than others.



Speaking of NES sprites, I know I heard something about Punch Out using a special graphics mode to get large sprites onscreen.

No special graphics mode. It uses the background tiles for sprites. Notice the floor/mat is a solid color. This is a direct effect of doing this. In Megaman 2 with that Dragon boss. That boss is the back ground layer. Other NES games with black or solid backgrounds with bosses are usually doing this trick too. What makes Punch Out cool is that the back ground color is the floor/mat color and goes into the upper background part with the crowd. There's a split in the background where the game scrolls the BG up/down and/or left/right below the crowd section. Think of it as a multiscroll. You'll notice that only the enemy/boxer head is ever overlapping the crowd tiles. That's because the head is actually made of sprites. Clever stuff.

[crazyjackcsa]

You guys are a wealth of knowledge. Using the Background, is that the way they got the big dog to appear in Toy Story on the Genesis and Super Nintendo?

[NayusDante]

The most obvious "background boss" I can think of is Gamma in Mega Man 3. Come to think of it, Capcom used a similar technique for Fat Cat in Rescue Rangers.

[Flack]

You might find the following article (and book) interesting.

http://www.wired.com/gamelife/2009/03/racing-the-beam/

[rbudrick]

There was a trick used on the Game Gear in at least a couple of games that used a limitation of the LCD to create a transparency effect...in one game I think it was so you could see through water flowing down the screen. It took advantage of the refresh rate of that old slow LCD and when you hack a GG to work on a TV, the effect is not there at all.

-Rob

[crazyjackcsa]

You might find the following article (and book) interesting.

http://www.wired.com/gamelife/2009/03/racing-the-beam/

That was an interesting read, and If I had a VCS I'd pick up the book.

[AbnormalMapping]

One of the most basic flaws of the NES hardware is the four color limit on sprites, and one of the colors can't even be seen, reducing your crayon box to three. By comparison, the Sega Master system could throw out 16, same as a Super Nintendo. This is just one result of the limit: http://www.youtube.com/watch?v=uym-G8sJxTU

But the work around was easy: the invisible color actually turns out to be a feature designed to help stack sprites, at the potential risk of more flicker. As a result, SNK's P.O.W., Capcom's MegaMan 6, and Nintendo's Punch-Out! are the only examples I can think of where the 3 color limit was completely left behind.

[Baloo]

Don't forget the Hold and Modify technique used by Eternal Champions: Challenge from the Dark Side on Sega CD to have the system display 256 colors at once.

[ccovell]

There was a trick used on the Game Gear in at least a couple of games that used a limitation of the LCD to create a transparency effect...in one game I think it was so you could see through water flowing down the screen. It took advantage of the refresh rate of that old slow LCD and when you hack a GG to work on a TV, the effect is not there at all.

Flickering is not the only way to do it. Some games, like GG Aleste II, have sprites (eg, clouds) whose alternating horizontal lines are blank. The GG's screen resolution is so limited that these alternating lines blur with the ones above and below, making the sprites look solid, but transparent.


Don't forget the Hold and Modify technique used by Eternal Champions: Challenge from the Dark Side on Sega CD to have the system display 256 colors at once.

Haha, Tomaitheous, you wanna take this one? "Hold and Modify on the Genesis" is rich, and I don't mean in colour.

[tomaitheous]

Haha, Tomaitheous, you wanna take this one? "Hold and Modify on the Genesis" is rich, and I don't mean in colour.

'Hold and Modify'... hehe. More like "wait a sec while I blur the crap out of this poor video signal so you think you see more colors than there really are" or "WASWIBTCOOTPVSSYTYSMCTTRA" for short. But yeah, Genesis has no ham. I would love to know how that rumor of Eternal Champions got started. It just won't die. I remember some Brazilian guy arguing with me that the Genesis has true transparency because the crappy video output allowed it to blur dithering (he was referring to the waterfall in Sonic 1/2) and that any emulator that didn't do this automatically meant that it was inaccurate or broken. Like it was some sort of hardware feature. I guess that 'feature' is just broken on RGB out on the real console as well, hehe ;)

[crazyjackcsa]

'Hold and Modify'... hehe. More like "wait a sec while I blur the crap out of this poor video signal so you think you see more colors than there really are" or "WASWIBTCOOTPVSSYTYSMCTTRA" for short. But yeah, Genesis has no ham. I would love to know how that rumor of Eternal Champions got started. It just won't die. I remember some Brazilian guy arguing with me that the Genesis has true transparency because the crappy video output allowed it to blur dithering (he was referring to the waterfall in Sonic 1/2) and that any emulator that didn't do this automatically meant that it was inaccurate or broken. Like it was some sort of hardware feature. I guess that 'feature' is just broken on RGB out on the real console as well, hehe ;)

Still, kind of an interesting work around at the same time, taking a known defect and putting it to a use.

[jb143]

One of the most basic flaws of the NES hardware is the four color limit on sprites, and one of the colors can't even be seen, reducing your crayon box to three. By comparison, the Sega Master system could throw out 16, same as a Super Nintendo. This is just one result of the limit: http://www.youtube.com/watch?v=uym-G8sJxTU

But the work around was easy: the invisible color actually turns out to be a feature designed to help stack sprites, at the potential risk of more flicker. As a result, SNK's P.O.W., Capcom's MegaMan 6, and Nintendo's Punch-Out! are the only examples I can think of where the 3 color limit was completely left behind.

I don't think you could really call that a "flaw". The invisible color was so the sprites could have transparent backgounds. It was designed that way so the sprites wouldn't be in colored boxes. Your right about the trick though, stacking sprites was a common trick to increase the apparent color depth.


Here's another trick that comes to mind. Usually the screen is updated during the vertical retrace(when the electron beam is done drawing and is going from the bottom corner to the top corner to start over) This way, you could update video memory without messing up what's on the screen. If you didn't do it then, the background could "tear". The trick was that instead of doing this a programmer could update the screen at diferent times while the screen was being drawn to create cool image warping effects. A similar thing was done in gameboy games as well. I know the Zelda gameboy games for example would use it a lot to make the screen go all wavy.

[tomaitheous]

Here's another trick that comes to mind. Usually the screen is updated during the vertical retrace(when the electron beam is done drawing and is going from the bottom corner to the top corner to start over) This way, you could update video memory without messing up what's on the screen. If you didn't do it then, the background could "tear". The trick was that instead of doing this a programmer could update the screen at diferent times while the screen was being drawn to create cool image warping effects. A similar thing was done in gameboy games as well. I know the Zelda gameboy games for example would use it a lot to make the screen go all wavy.

They don't redraw the map or tiles for that wavy effect. They just update the scroll registers on a specific scanline. You can do horiztonal and/or vertical effects like this. Just as simple as changing the screen "position" on that line. Most game consoles didn't let you read/write to vram/tilemap during active display. So you couldn't get tearing that way. You had to wait until vblank. The SNES/MD/SMS/NES and other systems had this limitation. To get around it on the SNES/Genesis - they had super fast DMA channels to copy the data to vram for you. The only system that I know of that did allow you to completely read/write to VRAM during active display was the TG16/PC Engine. Of course home computers usually allowed you to as well. It should be mentioned that the NES, when using VROM and a mapper, allows you to switch out tiles mid screen - but you can't write to the tilemap sections or VRAM during active display. IIRC, there's just enough time to update 1 color (maybe 2) in palette ram during hblank. That also might require setting the clipped horizontal mode too (where it clips 8 pixels on either end if the active line).



Still, kind of an interesting work around at the same time, taking a known defect and putting it to a use.

I wouldn't call it a defect as much as just poor video signal generation, but yeah. Some games really did rely on this. More so than the norm. If you lived in Japan or EU and ran RGB setup though, this putting to good use idea was lost to you ;) Ccovell has a nice RGB comparison page that everyone should check out at least once :)

[jb143]

They don't redraw the map or tiles for that wavy effect. They just update the scroll registers on a specific scanline. You can do horiztonal and/or vertical effects like this. Just as simple as changing the screen "position" on that line. Most game consoles didn't let you read/write to vram/tilemap during active display. So you couldn't get tearing that way. You had to wait until vblank. The SNES/MD/SMS/NES and other systems had this limitation. To get around it on the SNES/Genesis - they had super fast DMA channels to copy the data to vram for you. The only system that I know of that did allow you to completely read/write to VRAM during active display was the TG16/PC Engine. Of course home computers usually allowed you to as well. It should be mentioned that the NES, when using VROM and a mapper, allows you to switch out tiles mid screen - but you can't write to the tilemap sections or VRAM during active display. IIRC, there's just enough time to update 1 color (maybe 2) in palette ram during hblank. That also might require setting the clipped horizontal mode too (where it clips 8 pixels on either end if the active line).


Doh! Your right, it is updating the scroll registers while drawing the screen to get the effect. It's been a while since I've messed with any of that. Also, I mainly worked on a PC where you could get away with such trickery.

[Baloo]

Well, I've never really gotten a straight yes or no answer for that question, so I guess it was a good question for my first Sega-16 interview.

[NayusDante]

Wasn't there a Terminator game for Genesis that required you to physically reset the game? Something was different afterwards, which let you proceed. Is there a section of RAM on the Genesis that doesn't clear when you reset?

[ccovell]

I can't think of any CPU in the world that automatically clears RAM when it is reset. The game software itself chooses to clear RAM (which almost all do the first time upon power up) or to leave some flags active between resets.