Support NeoGAF

[Krejlooc]

Well, even in GEN 7 we dont have a Sonic game with Naka's physics, let alone SNES

So Sonic's physics aren't really that special. What made them really well coded in 1991 was how well they ran on such slow, ancient hardware like the Genesis. Naka got Sonic doing a ton of really complex math in the background while also having enough left over to do tons of crazy graphics tricks, like tile decompression, parallax shearing, etc. Unless you were crazy good at using every single cycle the Genesis could afford in both vblank and hblank, you weren't going to do that.

Today, our PCs and systems are infinitely more capable than the old m68k and Sega Genesis. You can do all this math in extremely inefficient ways and still have trillions and trillions of cycles left over. Plus our GPU hardware can do all these kinds of calculations essentially instantly. The degree of difference in hardware is staggering considering it's only been like 25 years - we're talking about going from a system where being able to multiply numbers is a luxury to one where basically any sort of math we could ever want to do is costless.

That leaves the underlaying logic behind how his system worked. Divorced from the need for crazy efficiency, the logic isn't that amazing. A person with a basic understanding of trig and algebra could figure out all the math behind Sonic, and if you can't do that, then the actual logic itself has been so thoroughly deconstructed that Sonic Retro itself now hosts a breakdown of the entire engine, variable by variable.

In short - anybody who wants to make a Sonic game that looks and plays just like the old Sonic games can do so these days provided they know enough to put pixels on the screen.

Which isn't to diminish the work of Tax or Stealth or anybody - everybody knows this much about how the engines work and the info is so freely available precisely because there's been decades of research done into it.

 

[The Spoony Hou]

Sure it could, but only with some extra chips to boost the SNES power. Wasn't there a DSP chip that doubled the SNES processing power? Also, the Super FX would help for sure.

 

[Krejlooc]

Sure it could, but only with some extra chips to boost the SNES power. Wasn't there a DSP chip that doubled the SNES processing power? Also, the Super FX would help for sure.

Those extra chips cost money. And even then it's not "the SNES" doing sonic if it has to rely on extra hardware. The stock Sega Genesis is doing Sonic. Someone earlier remarked that the ability to use external chips was the "beauty" of the SNES design - every system could do that. It's not a unique feature of the SNES. The Genesis itself could do that. The reason most systems did not use external extra microprocessors is because it made your games very expensive. Sega Genesis games could be almost $20 cheaper than SNES equivalents depending on processors included.

The DSP-1 is used for matrices math. It is a processor designed explicitly to do matrix multiplication to aid in 3D calculations. This might not make sense if you don't understand how processors actually work - as in how they direct electricity that passes through them using circuits like adders and half-adders to perform mathematical operations using logic gates - but the circuitry to do matricies math in hardware is not necessarily the circuitry to do general purpose math in hardware. The DSP-1 only does matrix projections - things to perform 3D transformations, rotation, scaling, etc. It would be useless for the kind of math Sonic needs to do.

It would needs something more like the Super FX chip, which is a general purpose math co-processor. Such chip was very expensive. And again, it's not really the SNES "doing" sonic, it's the SNES passing all the math to an entirely separate processor to do it because it couldn't do it fast enough.

EDIT: And if you are interested in learning how processors work, here's a good place to start learning: http://en.wikipedia.org/wiki/Adder_(electronics). The ability to add and subtract are essentially the basis of all computing.

 

[Ziffles]

I always wondered how much work either system could offload. Like say you went crazy and stuck a Raspberry Pi on a cartridge. What would be the ceiling as far as capabilities?

Obviously you'd be limited to the final video output resolution, and sound wise you'd have to use the chips (though the SNES could accept sound streams). But otherwise could you essentially just run the entire game off the expansion hardware and pump it back in through a video stream? Or do you hit CPU limitations somehow?

 

[Flappy]

HAHA! Even the NES could handle it!

Damn. This would have blown my mind when I was a kid. Really impressive.

 

[Krejlooc]

The Sprites in Streets of Rage weren't as detailed as Final Fight though and were much bigger.

Streets of Rage 2 is really where the SoR games got impressive. The sprites in Streets of Rage 2 are enormous, and it throws way more enemies on screen at once than any of the SNES final fight games.

SoR3 has big sprites and lots of them too, but the game wasn't as good as SoR2.

 

[Krejlooc]

I always wondered how much work either system could offload. Like say you went crazy and stuck a Raspberry Pi on a cartridge. What would be the ceiling as far as capabilities?

Obviously you'd be limited to the final video output resolution, and sound wise you'd have to use the chips (though the SNES could accept sound streams). But otherwise could you essentially just run the entire game off the expansion hardware and pump it back in through a video stream? Or do you hit CPU limitations somehow?

You can replace the entire system this way. This is how those Sega Genesis to SNES adapters work, which let you play Sega Genesis games on an SNES. Or how the Super Gameboy works. Or how the 32X or Sega CD work. There is no limit. If you want, you can use the stock system solely for the controller input.

 

[DeVeAn]

Technically yes, at the time no. Read the history of Sonic and the stars would have never aligned for the game to even be made if things were different.

 

[Krejlooc]

Technically yes

I don't think the SNES could run Sonic as it is without external hardware.

 

[SneakyStephan]

HAHA! Even the NES could handle it!

FML, even in an NES version of sonic the physics are better than in any modern console version (ps3 etc)

Why is the NES powerful enough to have sonic bounce off of enemies , but the ps3/360 aren't and sonic falls through the enemies.

 

[DeVeAn]

I don't think the SNES could run Sonic as it is without external hardware.

Why not?

 

[Krejlooc]

Why not?

A major hang up the snes would have with sonic is that the sonic engine, to determine slope angle and velocity, uses division and multiplication extensively during hblank and vblank.

The sonic engine already pushes the number of cycles available during hblank to the limit - the reason sonic 1, 2 and cd use flickering sprites of splashing water at water lines is because the routine they wrote to change the palette during hblank was very expensive and took several hblanks to do, and thus the sprites hid the change over several lines. By the time sonic 3 rolled around, yuji naka had refined his algorithm enough to do it in 1 hblank, which is why sonic 3 and sonic &.knuckles don't use those sprites.

Anywho, the games already push the limits of hblank, and that's running at 7 mhz. The game uses division and multiplication, which have actual opcodes in the m68k (divu, divs, mulu, muls) - meaning the m68k processor can do actual division and multiplication in hardware in 1 call. The snes cannot do multiplication or division in hardware, it's cpu has no opcodes for those operations. The best you can do is bitwise shifting to divide or multiply by 2, but that has limited use. Anytime the snes does division or multiplication, it's done in software calling a routine which occupies many calls in 1 hblank, with larger numbers taking a logarithmic amount of time longer.

So the individual math needed to run the engine takes longer to do on the snes, and that's on top of the snes running much slower than the genesis, giving you less numbers of cycles per hblank in the first place.

Now, using a math coprocessor, things even up. But I'd imagine a stock snes would have lots of problems running sonic.



The math sonic does, the m68k was definitely faster at.

To give an example of the cost of these math routines, this is a java implementation of mulu (multiplication between unsigned integers)

public class MULU implements InstructionHandler
{
	protected final Cpu cpu;

	public MULU(Cpu cpu)
	{
		this.cpu = cpu;
	}

	public void register(InstructionSet is)
	{
		int base = 0xc0c0;
		Instruction i = new Instruction() {
			public int execute(int opcode)
			{
				return mulu(opcode);
			}
			public DisassembledInstruction disassemble(int address, int opcode)
			{
				return disassembleOp(address, opcode, Size.Word);
			}
		};

		for(int ea_mode = 0; ea_mode < 8; ea_mode++)
		{
			if(ea_mode == 1)
				continue;

			for(int ea_reg = 0; ea_reg < 8; ea_reg++)
			{
				if(ea_mode == 7 && ea_reg > 4)
					break;

				for(int r = 0; r < 8; r++)
				{
					is.addInstruction(base + (r << 9) + (ea_mode << 3) + ea_reg, i);
				}
			}
		}
	}

	protected final int mulu(int opcode)
	{
		Operand op = cpu.resolveSrcEA((opcode >> 3) & 0x07, (opcode & 0x07), Size.Word);

		int s = op.getWord();
		int reg = (opcode >> 9) & 0x07;
		int d = cpu.getDataRegisterLong(reg);

		int r = s * d;

		if(r < 0)
		{
			cpu.setFlags(Cpu.N_FLAG);
		}
		else
		{
			cpu.clrFlags(Cpu.N_FLAG);
		}
		if(r == 0)
		{
			cpu.setFlags(Cpu.Z_FLAG);
		}
		else
		{
			cpu.clrFlags(Cpu.Z_FLAG);
		}

		cpu.clrFlags((Cpu.V_FLAG | Cpu.C_FLAG));

		cpu.setDataRegisterLong(reg, r);

		int x = s;
		x = (x & 0x5555) + ((x >> 1) & 0x5555);
		x = (x & 0x3333) + ((x >> 2) & 0x3333);
		x = (x & 0x0f0f) + ((x >> 4) & 0x0f0f);
		x = (x & 0x00ff) + ((x >> 8) & 0x00ff);

		return 38 + (x << 1);
	}

	protected final DisassembledInstruction disassembleOp(int address, int opcode, Size sz)
	{
		DisassembledOperand src = cpu.disassembleSrcEA(address + 2, (opcode >> 3) & 0x07, (opcode & 0x07), sz);
		DisassembledOperand dst = new DisassembledOperand("d" + ((opcode >> 9) & 0x07));

		return new DisassembledInstruction(address, opcode, "mulu", src, dst);
	}
}

The snes would need similar code to the above to do multiplication. Meanwhile, the genesis does all of the above with the following call:

MULU.W <ea>, Dn 16 x 16 -->; 32

The best way to think about the snes vs genesis is that the snes was a lot like a fixed function pipeline - it came stock with a number of specific hardware tricks it could do, but it's weak cpu limited what it could do beyond those tricks.

The genesis is more like a programmable pipeline - few stock tricks, but loads of cpu cycles at your disposal that you can write your own special tricks.

The latter is more difficult to use than the former, but it's more flexible as well.

The sonic engine is one that does tons and tons of things in software thanks to its cpu. Stuff like the nemesis compression of tiles and running a custom sounds driver or dynamically resizing levels.

The sonic engine pushes the genesis cpu hard.

.

 

[Tain]

Why not?

There are a lot of posts above covering why the SNES couldn't do it from a hardware standpoint.

 

[Suzushiiro]

You can replace the entire system this way. This is how those Sega Genesis to SNES adapters work, which let you play Sega Genesis games on an SNES. Or how the Super Gameboy works. Or how the 32X or Sega CD work. There is no limit. If you want, you can use the stock system solely for the controller input.

You wouldn't even be limited to that, I'd think, since I know there was a Genesis game that supported MP with more than two players by putting extra controller ports on the cartridge itself.

 

[rav]

few hardware rivalries interest me as much as snes and genesis - both were distinct, not like today where a PS3 and a 360 are pretty much the same fucking thing.

Spoiler

genesis was better

HAHAHA,
They (PS3/360) are architecturally very different. For you to make such a claim definitely shows how much programming toolchains have improved over the years across the platforms. While yes, the main CPU is similar to a degree, the thread management is insanely different. Also they had different GPU vendors as well, and it's remarkable that you'd consider them so similar. Again a testament to building comparable toolchains for both platforms. Which shows that games you think were identical / nearly had teams that had specialists for each platform.

on topic: Porting a game to a different platform successfully is best done with people who really know the ins and outs of the target platform. (Specialists) The original gameboy can pull off some crazy stuff, if you're willing to race the beam so to speak.

 

[MrCunningham]

HAHA! Even the NES could handle it!

This kind of reminds me of the two Master System/ Game Gear Sonic's combined with Sonic 1 on the Genesis.

Sonic 2 SMS Green Hill: https://www.youtube.com/watch?featu...wMH8&x-yt-cl=84503534&x-yt-ts=1421914688#t=13

 

[scitek]

Yes, and it would have been exactly the same.

The SNES version would've sounded better.

 

[7DollarHagane]

Blast processing was a method of getting 256 colors on screen at once on genesis. It had nothing to do with speed.

Marketing picked up on the "blast" and used it.

 

[Krejlooc]

The original gameboy can pull off some crazy stuff, if you're willing to race the beam so to speak.

That's sort of the point of this discussion - Sonic does a bunch of "race the beam" style tricks. Quite literally in instances like scanline palette swap.

 

[DonMigs85]

That + 60fps was absolutely mind blowing in 1991, and I agree it still looks fantastic today.

All 2D tilemapped games ran/scrolled at 60FPS - you would just get slowdown if the hardware couldn't keep up.
It's not the same as a 3D game's framerate.

 

[Krejlooc]

Blast processing was a method of getting 256 colors on screen at once on genesis.

Nope. There are a few ways to get more than the standard color palette out of the genesis, but you could never get 256 colors out of the thing. This is a commonly repeated myth and it's simply not true.

First up, people need to be aware that the Sega Genesis VDP can, officially, generate 512 colors total. From this 512 color master palette, 4 16-color subpalettes are selected leaving a theoretical 64 colors displayed at once, although that number is smaller due to colors being reserved for transparent (i.e. not drawn) pixels.

Now, the most obvious way to generate more than 64 colors at once on a Genesis is to rely on the inaccuracies of the NTSC and PAL display systems at the time, which would cause the red subchannel in pixels to bleed over into adjacent pixels. Thanks to the general blurriness of SD CRTs at the time, this would result in colors next to each other blending at a near 50-50 ratio, which graphics artists at the time would take advantage of. By alternating colors, you could reasonably expect that they should show up a blend of two colors when viewed on screen. This is called dithering or stiple shading. Genesis games use dithering all over the place. It generally looks terrible on modern displays, where the resolution is sharp enough such that you can discern the pixels independently and they look like weird meshes. But on an SD CRT (or a modern display using, say, an NTSC color filter) they will blend into half-steps:

->

Using alternating pixels of solid colors and transparent colors would also result in what appeared to be a transparency effect, which loads and loads of Sega Genesis games used back in the day to fake transparency:

The other commonly used method to display more than 64 colors on screen at once is to do scanline palette swapping. To understand how this is done, you need to understand how PAL and NTSC CRT televisions worked. Unlike modern progressive displays, these old displays had a gun inside the CRT that would draw the scan out to the screen - that is the actual color pixels in a horizontal line. It would move from the left side of the screen to the right, at which point it would turn off, then move back to the left side of the screen, drop down one pixel, then turn back on and begin drawing the next (interlaced) line.

While the gun is drawing to the screen, the console is sending it data to draw, but when the gun is turned off and moving back to the left, the machine doesn't need to send any video information. This fraction of a fraction of a seconds time it takes for the gun to move back to the left side of the screen is known as hblank, and a console's CPU can run a few cycles in this time. By planning out your cycle use, you can actually load another subpalette in place of an already loaded subpalette to switch colors being drawn midscreen.

By counting hblanks, programmers could figure out where, vertically, on the screen they were drawing to and use this method to fake transparent water, which the Sonic games used extensively:

Now, the final, definitely much-less used method to output more colors on screen at once is to abuse a very rarely discussed trick the Genesis could do. While not true transparency, the Genesis had the ability to highlight or shadow individual 8x8 tiles. When highlighting or shadowing tiles, the VDP will actually do bitwise operation on the RGB values of the pixel to dynamically change them while being outputted. This is a very awesome trick, because in doing these bitwise shifting, they actually create new values outside of the master 512 palette. Which is to say that highlighting and shadowing mode can produce new shades of red, blue, and green not normally seen in the master palette for the Genesis. Some of these colors are very useful halfsteps that create missing transitional colors in fades or blends, but their use is extremely complex because it shades the entire 8x8 tile, not individual pixels. Sonic 3 uses this mode in debug mode to show different planes of solidity by shading a tile if it resides on plane b. More practical uses include ranger X using this to display more than 512 unique colors over the course of the game (people often remark that it looks like an SNES game because it's producing shades not normally seen in other genesis games), pier solar using this to do actual transparency, or Vectorman using it extensively to display more than 64 colors per screen:

But that said - no, there is no way for the Genesis to natively display 256 colors on screen at once.

 

[MrCunningham]

The SNES version would've sounded better.

Going by some of the SNES fan remakes, that would be debatable:

https://www.youtube.com/watch?v=gb4phZ6t9-M
https://www.youtube.com/watch?v=B8bbm-igqO8

This Marble Zone cover sounds like it belongs in a french cafe: https://www.youtube.com/watch?v=41Jr7990c6c

Sonic 1 really did play on the strengths of the Genesis sound hardware.

This Sonic 3 Hydrocity cover sounds pretty jazzy though: https://www.youtube.com/watch?v=l6nTtT59OPo

 

[rav]

That's sort of the point of this discussion - Sonic does a bunch of "race the beam" style tricks. Quite literally in instances like scanline palette swap.

Even the 2600 can still pull off way cooler stuff than was originally intended: http://members.shaw.ca/jeffv/halo2600.html

The Amiga was way ahead of it's time (atari 2600 lineage)

With comparable clocks and comparable expertise, most any game should be able to run just as well on another platform. With the following caveat: any special tricks needed to get it to run originally on a target platform may suffer due to memory / architectural differences. (as long as they're generally in the same generation of course. 8bit / 16bit so forth. and not including special processors for floating point and such.)

 

[Krejlooc]

Even the 2600 can still pull off way cooler stuff than was originally intended: http://members.shaw.ca/jeffv/halo2600.html

The Amiga was way ahead of it's time (atari 2600 lineage)

With comparable clocks and comparable expertise, most any game should be able to run just as well on another platform. With the following caveat: any special tricks needed to get it to run originally on a target platform may suffer due to memory / architectural differences. (as long as they're generally in the same generation of course. 8bit / 16bit so forth. and not including special processors for floating point and such.)

That's just the thing in this instance - the clocks aren't comparable. This is an instance of asking the SNES to do more than the genesis - because of the lack of comparable opcodes - on a weaker CPU, when what the Genesis does is already pushing it's faster CPU to the max.

Getting anything resembling sonic would require significant reengineering, and at that point I'd argue it wouldn't be the same Sonic at all.

 

[entremet]

Why was the Genesis port of Earthworm Jim considered better?

I played both and I remember the Genesis having an extra level, but the SNES one was more colorful and had some nice lens flare effects too.

 

[Krejlooc]

Why was the Genesis port of Earthworm Jim considered better?

I played both and I remember the Genesis having an extra level, but the SNES one was more colorful and had some nice lens flare effects too.

The reason the Genesis version has an extra level, is that, because the Genesis uses a chunky pixel format that can be further compressed thanks to the speedy CPU, the game's art takes up less space on the cart. The SNES uses a planar pixel format which causes all the very same sprites to take up more space. Because cart size = price, and EWJ was already a large game cartridge, this meant they wound up with a ton of extra space on the Genesis version. That let them add additional sound effects and voice clips, as well as a whole extra level, and small little additions to existing levels.

It was also designed for the Sega Genesis primarily. They basically cut stuff from the SNES version.

This is something that never seems to get brought up in these retro console discussions - all these things the Genesis could do with its fast CPU, it basically could do to reduce the price of games. The same stuff on the SNES made games cost more. As an example - some games later added external processors to do image decompression... which let them add more art to games, but it also increased the cost of the game. The same functionality could be added as software to the Genesis, resulting in games that took up less cartridge space, thus being cheaper, without requiring any additional, costly processors.

 

[rav]

That's just the thing in this instance - the clocks aren't comparable. This is an instance of asking the SNES to do more than the genesis - because of the lack of comparable opcodes - on a weaker CPU, when what the Genesis does is already pushing it's faster CPU to the max.

Getting anything resembling sonic would require significant reengineering, and at that point I'd argue it wouldn't be the same Sonic at all.

Ah yeah, looking closer at the specs I tend to agree. I haven't done any dev for either Sega Genesis, or SNES. With that said: It's still possible that with the memory and sprite differences there could be significant catchup even with a slower clock.

But looking at how few registers the Ricoh 5A22 (SNES) has, I doubt it could compete 1:1 without a significantly larger pool of memory. (Looks like the z80 could possibly outperform the 5A22.)

 

[entremet]

The reason the Genesis version has an extra level, is that, because the Genesis uses a chunky pixel format that can be further compressed thanks to the speedy CPU, the game's art takes up less space on the cart. The SNES uses a planar pixel format which causes all the very same sprites to take up more space. Because cart size = price, and EWJ was already a large game cartridge, this meant they wound up with a ton of extra space on the Genesis version. That let them add additional sound effects and voice clips, as well as a whole extra level, and small little additions to existing levels.

It was also designed for the Sega Genesis primarily. They basically cut stuff from the SNES version.

This is something that never seems to get brought up in these retro console discussions - all these things the Genesis could do with its fast CPU, it basically could do to reduce the price of games. The same stuff on the SNES made games cost more. As an example - some games later added external processors to do image decompression... which let them add more art to games, but it also increased the cost of the game. The same functionality could be added as software to the Genesis, resulting in games that took up less cartridge space, thus being cheaper, without requiring any additional, costly processors.

That's interesting. I owned both systems, so I never got caught in the system war nonsense.

A lot of those Dave Perry style games seems to be designed with the Genesis in mind.

I enjoyed both immensely.

 

[Krejlooc]

Ah yeah, looking closer at the specs I tend to agree. I haven't done any dev for either Sega Genesis, or SNES. With that said: It's still possible that with the memory and sprite differences there could be significant catchup even with a slower clock.

But looking at how few registers the Ricoh 5A22 (SNES) has, I doubt it could compete 1:1 without a significantly larger pool of memory. (Looks like the z80 could possibly outperform the 5A22.)

That's the deathblow - "blast processing" (a marketing term for their specific DMA controller) refers to the much, much speedier and more flexible DMA that the Genesis capable of. Several of the SNES' native hardware tricks significantly restrict DMA, and even without those restriction, Sega DMA during vblank is much faster than SNES DMA during vblank.

Plus as you noted, there are too few registers for the SNES to really even have a chance to catch up, if it even could.

 

[MrCunningham]

The reason the Genesis version has an extra level, is that, because the Genesis uses a chunky pixel format that can be further compressed thanks to the speedy CPU, the game's art takes up less space on the cart. The SNES uses a planar pixel format which causes all the very same sprites to take up more space. Because cart size = price, and EWJ was already a large game cartridge, this meant they wound up with a ton of extra space on the Genesis version. That let them add additional sound effects and voice clips, as well as a whole extra level, and small little additions to existing levels.

It was also designed for the Sega Genesis primarily. They basically cut stuff from the SNES version.

The sound was one of the biggest problems in the SNES version of Earthworm Jim1. Not only did some of the music tracks sound horrible on the SNES sound chip but a lot of sound effects in general were missing altogether. It really made the SNES game sound incomplete. Visually, the SNES game did have a few nice additional details though and higher colour graphics. It did look better in that respect. But the lower resolution also made Jim look kinda bulky.

Earthworm Jim 2 was a much better port all around on the SNES, in many ways I prefer it over the Genesis version. I think they did use some compression techniques for the SNES cartridge that made it broken on emulators for the longest time. The Genesis version of EWJ2 was pretty solid as well though, with a few extra CPU tricks thrown in that were missing on the SNES (like the blind cave salamander stage) and I did prefer a few of the music tracks on the Genesis.

Nope. There are a few ways to get more than the standard color palette out of the genesis, but you could never get 256 colors out of the thing. This is a commonly repeated myth and it's simply not true.

The static cut scenes in Toy Story display anywhere from 90-180 colours on screen at once or so. But in game it never really goes past 64 colours on screen.

 

[Krejlooc]

The static cut scenes in Toy Story display anywhere from 90-180 colours on screen at once or so. But in game it never really goes past 64 colours on screen.

That uses an interesting quirk about the high resolution interlaced mode. Essentially it swaps colors during interlacing to produce a similar effect to the one I described with dithering, except to a much greater effect.

 

[PaulloDEC]

Nope. There are a few ways to get more than the standard color palette out of the genesis, but you could never get 256 colors out of the thing. This is a commonly repeated myth and it's simply not true.

*Snipped*

Can I just say that despite not understanding various bits of your posts, they're still some of the most interesting and informative of any I've read on GAF. It's great to have access to all this information so many years down the line.

 

[Zee-Row]

The beta version of Street Fighter 2 on Genesis had more frames of animation and had heavy damage music that the SNES lacked. But then the final released got down scaled like the SNES version. I wonder why Capcom did that?

The beta looked really great.

https://www.youtube.com/watch?v=6le17Jq-HnM

 

[PepsimanVsJoe]

Goddamn @ the knowledge being dropped in this thread.

Everything

 

[Krejlooc]

The beta version of Street Fighter 2 on Genesis had more frames of animation and had heavy damage music that the SNES lacked. But then the final released got down scaled like the SNES version. I wonder why Capcom did that?

The beta looked really great.

https://www.youtube.com/watch?v=6le17Jq-HnM

This version was made by Sega and used a proprietary sound driver. Sega's own software houses had access to in-house sound drivers that were pretty awesome - Sonic 3's sound driver, for example, got used in almost all Sega games going forward. The sound driver is basically a program that tells the Genesis how to produce sound. The Genesis could produce an enormous range of sounds because, unlike the Super NES, it actually generated the sounds it played mathematically through FM Synthesis. The Super NES, by contrast, played samples - recorded pieces of audio that were stored in various bitrates depending on compression, that the SNES hardware would then pitch bend or do things like change the playback rate. By manipulating lots of sound samples, the SNES produced its music, not unlike midi.

When Capcom came in midway through the development of Street Fighter II', they used their own sound driver instead, which evidently wasn't as great as Sega's. Sega's sound drivers could produce great bass.

 

[Herne]

Sonic still looks amazing today. It has a sheer amount of animations happening all at once.

On topic though: the speed could be done. But everything would else would have to be dumbed down in the process.

I'm not sure that it has that great a number of animations running at once, it's more typical of the games that were out at the time, really. Even on the 8-bits you had stuff like that - I remember similar things happening on the C64 even at the time. Take a look at IK+, Creatures 2 - Torture Trouble, MYTH, Mayhem in Monsterland, etc. The latter even had some of Sonic's speed, and that's on a machine with a sub-1MHz processor.

 

[Krejlooc]

I'm not sure that it has that great a number of animations running at once, it's more typical of the games that were out at the time, really. Even on the 8-bits you had stuff like that - I remember similar things happening on the C64 even at the time. Take a look at IK+, Creatures 2 - Torture Trouble, MYTH, Mayhem in Monsterland, etc. The latter even had some of Sonic's speed, and that's on a machine with a sub-1MHz processor.

It definitely has a lot going on at once, much more than the games you listed. Yes, independently, what it does can be done on other systems. It is using interrupts to do parallax scrolling in 2 layers on the clouds, 2 layers on the mountains, then multiple shears across each vertical line to do the shimmering water. Then, across all of this, it's doing palette rotation, and background animations like the flowers springing up are being done with tile decompression on the fly.

Each one of those tricks is neat, doing them all in concert is really impressive. And that's not even taking into consideration the actual collision and angle math. And I'm familiar with the games you've listed - they are impressive, especially Mayhem, but they're not doing what Sonic is doing all at once. Which makes sense - Sonic is on a much faster machine.

You are right to point out that these tricks weren't invented by Sega and Sonic Team, but that's true of virtually any graphical technique ever. They all begin in demoscene, always. Sonic's implementation is still very impressive. They essentially knocked it out of the park on their very first attempt.

 

[Herne]

It definitely has a lot going on at once, much more than the games you listed. Yes, independently, what it does can be done on other systems. It is using interrupts to do parallax scrolling in 2 layers on the clouds, 2 layers on the mountains, then multiple shears across each vertical line to do the shimmering water. Then, across all of this, it's doing palette rotation, and background animations like the flowers springing up are being done with tile decompression on the fly.

Each one of those tricks is neat, doing them all in concert is really impressive. And that's not even taking into consideration the actual collision and angle math. And I'm familiar with the games you've listed - they are impressive, especially Mayhem, but they're not doing what Sonic is doing all at once. Which makes sense - Sonic is on a much faster machine.

You are right to point out that these tricks weren't invented by Sega and Sonic Team, but that's true of virtually any graphical technique ever. They all begin in demoscene, always. Sonic's implementation is still very impressive. They essentially knocked it out of the park on their very first attempt.

Of course it has more than the games I listed, none but Mayhem have such huge open levels and obviously Mayhem can't match Sonic in that area. I just meant that it's typical of the time, other games on Mega Drive, SNES or even Amiga had that kinda stuff going on. It's impressive, sure - it's just typical, is all. In that particular image - not accounting for any other level or area in the game - the flowers are bouncing and turning, the water is shimmering and falling down the waterfall, and Sonic is tapping his foot. That last, of the avatar having these kind of animations while idle, I would definitely give Sonic Team credit for. But there's not an awful lot going on there.

 

[tkscz]

saw nothin on snes move as fast as that blasted hedgehog

So I guess you never played Super Metroid then.

Yes, with the correct programming, Sonic could have run just as well on the SNES.

 

[Krejlooc]

I just meant that it's typical of the time, other games on Mega Drive, SNES or even Amiga had that kinda stuff going on. It's impressive, sure - it's just typical, is all. In that particular image - not accounting for any other level or area in the game - the flowers are bouncing and turning, the water is shimmering and falling down the waterfall, and Sonic is tapping his foot. That last, of the avatar having these kind of animations while idle, I would definitely give Sonic Team credit for. But there's not an awful lot going on there.

And I'm saying it wasn't very typical, not in 1991. Yes, plenty of games did those things individually, but no, not many games of the time did them all at once. I mean, sure, as knowledge of how this stuff was done was spread around, other games later began doing it all in concert, but not in 1991. You'd eventually get stuff like Jim Power, but that was like 2 years after Sonic. The most comparable game of the time would have been Shadow of the Beast, which does crazy interrupt parallax tricks, but none of the complex math underneath.

Sonic's graphics were certainly not "typical." Keep in mind the time period - this was like just as Turrican 2 was releasing.

 

[KittenMaster]

# of colors on screen didn't matter as much so much as the global palette which to pool the screen colors from. I doubt there are many SNES games that actually needed to display 256 colors at once (unless it was for true transparency effects), but many that benefited more from a more versatile palette. Had there been more than 512 colors to choose from for the Genesis, they could've used the 64 colors on screen with much more effectiveness than they already were.

 

[Krejlooc]

# of colors on screen didn't matter as much so much as the global palette which to pool the screen colors from. I doubt there are many SNES games that actually needed to display 256 colors at once (unless it was for true transparency effects), but many that benefited more from a more versatile palette. Had there been more than 512 colors to choose from for the Genesis, they could've used the 64 colors on screen with much more effectiveness than they already were.

You can see this in action by comparing the Master System to the Game Gear. Identical, except for master palette. The Game Gear produces games that look so much better on the very same hardware just because it can better select which 16 colors it wants to display.

 

[deltatheta]

That's nuts that Sonic had a div in the hblank. My impression with those old processors is they would avoid divisions at all costs in a tight loop because they were so much more expensive than multiplies, which were expensive already. And you don't get much tighter than an hblank interrupt. I wonder if most of the interrupt time was dedicated to that one div.

 

[Krejlooc]

That's nuts that Sonic had a div in the hblank. My impression with those old processors is they would avoid divisions at all costs in a tight loop because they were so much more expensive than multiplies, which were expensive already. And you don't get much tighter than an hblank interrupt. I wonder if most of the interrupt time was dedicated to that one div.

it wasn't done every hblank or anything, only in specific situations to speed up calculations. They did other costly operations in hblank, though. They'd spread them out over several consecutive hblanks to do complex calculations very quickly.

But yes, they would try and avoid div as much as possible (i.e. look up tables where possible, especially instead of doing sin and cos calculations which would have been rather impossible). But the way the Sonic Engine works, doing div and multiplication is inavoidable.

 

[MrCunningham]

You can see this in action by comparing the Master System to the Game Gear. Identical, except for master palette. The Game Gear produces games that look so much better on the very same hardware just because it can better select which 16 colors it wants to display.

There are some cases where I find Game Gear games to look better than Genesis games in the colour palette department, just because the Game Gear has a wider palette of colours to chose from. Despite only being able to display about half the amount of colours on screen.

Great example of SMS vs GG:

Bottom screenshot is the Game Gear version, and the enhanced 12-bit colour palette makes a huge difference.

 

[Krejlooc]

There are some cases where I find Game Gear games to look better than Genesis games in the colour palette department, just because the Game Gear has a wider palette of colours to chose from. Despite only being able to display about half the amount of colours on screen.

This is why highlight and shadow mode is so cool - because it can generate new entries past the 512 master palette. It's just super limited in it's usefulness because of the 8x8 tile limitation. It actually winds up acting quite a bit like the old ZX Spectrum Attribute Clash, so the same sort of graphics consideration used to make ZX Spectrum games would work well with Highlight/shadow mode.

 

[KittenMaster]

You can see this in action by comparing the Master System to the Game Gear. Identical, except for master palette. The Game Gear produces games that look so much better on the very same hardware just because it can better select which 16 colors it wants to display.

Heck, the Master System palette already blows the NES out of the water, so that is quite impressive on the Game Gear's part.

 

[Krejlooc]

Heck, the Master System palette already blows the NES out of the water, so that is quite impressive on the Game Gear's part.

The game gear actually has a master palette of 4096 colors, much much larger than even the Genesis master palette (8 times bigger!). The Genesis wouldn't have had nearly as bad of a problem with perception about it's color had it a prettier master palette or a larger one like the Game Gear. The TG-16 has a master palette of 512 as well, but the colors it produces are much more appealing.

Your original post was correct - 64 colors really is enough to display whatever you want for most images. Lots of times when the Genesis uses dithering, it's because it's trying to produce a color it's master palette could not produce in the first place.

 

[Piston Hyundai]

Earthworm Jim 1 was better on genny than SNES in every way imaginable.

Although the Sega CD version is even more amazing with the Special Edition.

But iirc Shiny got the engine up to speed for EWJ2 tho on SNES; however, the sequel was inferior to the original.

I still liked part 2 tho.

The SNES port of EWJ2 is probably the best if only for that fucking drum line.

Spoiler

also Krejlooc thread MVP

 

[Krejlooc]

The SNES port of EWJ2 is probably the best if only for that fucking drum line.

Spoiler

also Krejlooc thread MVP

I like when both systems have really good remixes of the same soundtrack, because it's like having two covers of the same song. I generally prefer the Genesis EWJ soundtracks, especially the first, but I like having SNES remixes as well. All of the anything but tangerine versions are great.

It's also awesome to have official versions in the form of CD releases from the Win95/Sega CD special edition of EWJ1 and the PSX/Saturn/Win95 releases of EWJ2.

Sound hardware is fascinating to me, but I don't have a deep understanding of music or audio in general. As in, I'm not very proficient at understanding the theory behind what makes good music. That's why I like seeing Gecko Yamori post in these threads, because I trust that guy's opinion on audio. I wish TmEE would post on Neo Gaf as he's pretty much the authority on video game audio programming from around this time period.

Here's a good song from EWJ1 that I feel demonstrates the difference between the Genesis and SNES, particularly highlighting the ways the Genesis can produce deep, impactful bass:

https://www.youtube.com/watch?v=qa4Z7UpFA6o

https://www.youtube.com/watch?v=S5L7M7efN9w

and of course the official release:

https://www.youtube.com/watch?v=c_YdjYf29Ko