The last thread:
In this thread we discuss clever techniques in games that squeezed every ounce of performance out of limited hardware. If there was ever a time you were playing a retro game and asked yourself "how did they do that?", post it and we'll figure it out.
Impressive graphical effects, sound, and implementation details all welcome. Bugs, although unintended, can be interesting to understand as well.
How did Out of this World do 3D looking graphics during the "cutscenes" on the SNES without the FX chip? I somewhat understand rotoscoping, but I don't quite get how the graphics looked 3D without just translating each frame into pixels and animating through them.
>I want to know how ranger X did what it did ar 12:20 in this vid...
That's basic line scroll. The same effect that gives the ground perspective in Street Fighter. They just change the X scroll offset per every line.
Ranger X merely applied it twice, and inverting it in the middle. Maybe it also had another bg and some windowing inbetween, I'm not sure, and too lazy to check.
Looking at that video, the effect could be pulled off on one layer if the background tiles were very simple (in this case a single 16x16 pixel tile), and if the background tiles were cyclically rotated along their horizontal axis as a function of your position while the tile map stays constant. The picture I made isn't great, but illustrates the technique.
This game looks bad ass, I've never heard of it.
Are you talking about the 3D rendering a little after 12:20? Although the Genesis has a tile based graphics chip, you can fake a low color bitmap by assigning unique tiles to the entire screen and associating them and drawing to the tiles directly.
Line algorithms can be made to be very efficient, and while it takes a little overhead to raster a line accommodating a tile based layout, 3D rendering programs overall can be very simple, and implemented in just a few hundred lines. Run at 30 or 20 fps and you have ample time to draw simple geometry even on limited hardware. Impressive stuff though.
Here's my contribution to asking a question: does anyone know how Super Metroid implemented it's power bomb? Clearly it's a constant color addition with HDMI, but the way the shape is generated must be done in software in s strange manner because the game frameskips due to the extra processing load and the fact that the edge of the power bomb explosion has different granularities. Furthermore, does anyone know if the power bomb's area of effect is rectangular or elliptical? Now that I think about it, maybe that's why the game slows down so much... Btw X-ray scope was a brilliant use of the SNES PPU.
>Run at 30 or 20 fps and you have ample time to draw simple geometry even on limited hardware. Impressive stuff though.
You have to limit either the screen size or the FPS though, since you can only upload so many new tiles (new frames) to the VDP during vblank. One of the biggest weak points of the Megadrive.
And yeah, Ranger X looks insanely good. You have levels with tons of parallax, others with highlight effects, others with crazy amount of pseudo-3d tubes and backgrounds done by linescroll, you have water splashing also done by linescroll, the forest level modifies the palette lots of times, and those are just the graphics.
The gameplay also has lots of twists: your bot is solar powered, so you need to find sources of light to recharge. On daylight levels, you get a constant charge. On night levels you have to find sources of light - either blow out an office window where the light is on, or stand on the search headlights in the city (which activates security that hunts you).
Some levels also have puzzle-like tricks, and maze elements.
It is really a great game, you should try it out.
It's like creating and uploading a gif to Tumblr. It's an art. You have 2 mb limit and should still look good. Your tools are color, resolution and compression. You have to neglect of the three of use multiple gifs (multiple discs ps1).
color of 128 of 256 and resolution of 540 or 275 and compression from 0 to 20.
> since you can only upload so many new tiles to the VDP during vblank.
That's a really good point. I'm no expert on the VDP or Genesis in general, so somebody help me out here: Was there enough VRAM to set up two full screen backgrounds with unique tiles? That way you could implement a double buffer to circumvent the low data throughput.
For the SNES using 2-bit graphics, the memory footprint would be:
(2 maps)*((32*32 names/map)*(2 bytes/name) + (32*32 tiles/map)*(8*8 pixels/tile)*(2 bits/pixel)/(8 bits/byte))
= 36864 bytes
= 56.25% of VRAM
The DMA throughput of the SNES during vblank is about:
(224-262 scanlines)*(1364 cycles/scanline)*(1/8 bytes/cycle)/(1 vblank)
= 6574 bytes/vblank
The number of vblanks needed to transfer one full frame buffer
ceil((36864 bytes)/(2 frames)/(6574 bytes/vblank))
= 3 vblanks/frame
So a game could theoretically run at:
(60 vblanks/second)/(3 vblanks/frame)
= 20 frames/second
So it's within the realm of possibility. Unfortunately 2 full screens at 4-bits is just out of reach without restricting the display area a bit.
Btw I can't believe Capcom would dump money into making the Cx4 coprocessor just to do shit like in the image. Fucking X got wireframe to work on gameboy years before X3 on the SNES.
>Btw I can't believe Capcom would dump money into making the Cx4 coprocessor just to do shit like in the image
Cx4 test screen checks exactly wireframes.
God damn it. An SNES version of Final Fantasy VII would be awesome.
What takes Genesis render polygons? What special Genesis VDP has, so polygons are generated pretty quickly?
It is all software, like playing Quake on a PC with no dedicated 3d accelerator. The processor is doing everything, which means it has to be coded to even be able to run. With a processor as weak as the Genesis', this is hard, and is why you don't see many 3d games, and most of those you do run at abominable framerates.
That explanation downplays it a little bit considering the NES could not do layers in the way that makes parallax easy. You have a layer for sprites, and another for tiles which is both background an foreground.
You can scroll tile rows at different speeds, creating backgrounds with parallax scrolling. It would be impossible to use for that Bucky O' Hare scene though, since it only works when background and foreground don't overlap.
The trick to the parallax in Bucky O'Hare looks to be animated tiles. Not hard to do since it's one repeating pattern of blocks and the screen only scrolls one direction. Basically, as the screen scrolls, the tiles animate, creating the illusion that they scroll slower than the foreground.
>But isn't Genesis VDP is tile-based?Or the processor is just quick enough to use workarounds that write pixel information into the tiles?
Correctamundo. You draw your polygons in software, then convert them to tiles, and upload them to the VDP. If you are efficient enough, it is not difficult to end up being limited by the amount of tiles you can upload, rather than the amount of polys you can draw, which is the real hardware limit. The 68k was actually fast enough to do ridiculous amounts of work in software - we have the complete shareware edition of Wolfenstein3d running on the Megadrive, for example.
It's a JRPG, nobody cares how it plays. Being graphically worse is a very serious flaw, because it wouldn't be able to tell the story properly. Do you think "Aeris dies" would be a meme without the FMV?
>Furthermore, does anyone know if the power bomb's area of effect is rectangular or elliptical?
Seeing as it affects everything on screen does it matter?
I loved the X-ray scope too. What's the PPU? Pixel Processing Unit?
How such complicated floor was performed?
Not actually that hard once you know how to do proper raytracing.
TL;DR: Raytracing basically boils down to drawing one column per width pixels (320x240 means 320 columns). Said column is separated in three parts: sky/ceiling, ground and walls. For each column ("ray of your vision"), you calculate the distance to the wall and you got your wall size in the middle of the screen, the rest can be calculated with "(half my screen height) MINUS (half my wall size)" and you start drawing from the middle.
Drawing textures on each of the three just takes some more calculations (which I don't have) with distance (which you already got)
For reference, a barebones Wolfenstein clone with black ground, red walls and blue ceiling took me about six hours to code from scratch, and I'm shit at maths. Some people from my class did portal clones in two weeks with fully-textured walls.
Here is a nice "how we got here" made from the class before mine: https://www.youtube.com/watch?v=ZOC5lYZPNUs
Ultima Underworld and Wolf 3D when they came out were utterly fucking mind blowing. If you're not old enough to remember when those games were released then it's difficult to put into words, but there's really never been anything like experiencing those games for the first time since.
>Drawing textures on each of the three just takes some more calculations (which I don't have)
You can divide your wall height by texture height - the result is the number of the same pixels you will have to draw on the wall for a pixel in texture.
The Delta Force games take place in maps that loop infinitely. It's not randomly generated, but tiled, and I'm not sure if there is a limit to how far you can go but I went through several loops of it once out of curiosity.
How was this done?
The PC-88/X1 original was already doing voodoo magic in 1988, and then it got an upgrade for the X68000. Arsys did every version of Star Cruiser; Masaya just took credit for publishing it on Mega Drive.
Yep, all hand drawn vector graphics. Required a whole lot of patience to make the data and a highly optimised vector rasteriser to get it done at a playable frame rate. The SNES one went through a few revisions. The first actually used the FX Chip but the publisher didn't want to pay for it so it was redone for the base cpu. It was also supposed to use SRAM but they didn't pay for that either.
>Here's my contribution to asking a question: does anyone know how Super Metroid implemented it's power bomb?
I don't *know* but I can guess. Drawing a solid filled ellipse is easily possible in software and the super nes gives you the choice of using the "window" which is a masking you can apply but you'd have to use a raster interrupt every line to transpose the ellipse shape to the mask.
Alternatively you can draw the ellipse to the tiles you are using for one of the backgrounds and blend that with the display. The benefit is no per line rasters, downside is that your ellipse code now has to deal with tiles and this is possibly why it slows down.
Ahh, that makes sense. My source was portscentre on youtube and he kept saying static ram. I assumed he just meant it was originally meant to have save support but they ditched it. Thanks for clearing that up.
> That’s a tough call, since I’ve done so many projects in my career so far. I think I’d have to say was the evil MOD I had to do to get Out Of This World for the SNES to copy backgrounds quickly. Since Interplay wouldn’t pay for a SuperFX chip, I found a way to do it with static RAM on the cart and DMA which got me a great frame rate. Interplay wouldn’t pay for the static RAM either, so I ended up using Fast ROM and a MVN instruction. Interplay wouldn’t pay for a 3.6 Mhz ROM either. So, frustrated, I shoved my block move code into the DMA registers and use it as RAM running at 3.6 Mhz. It worked. I got fast block moves on slow cartridges and made a game using polygons working on a 65816 with pure software rendering.