-
Hey, guest user. Hope you're enjoying NeoGAF! Have you considered registering for an account? Come join us and add your take to the daily discourse.
Could have Sonic the Hedgehog been done on the SNES?
- Thread starter CurseoftheGods
- Start date
- Status
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.
Honorable mention should go to this surprisingly competent pirate Sonic on the NES
https://www.youtube.com/watch?v=ffb-Bwbl4M8
Megatron
Member
Well shoot man, the 3ds can't even run SNES games, I wouldn't hold the gba's performance against it.
While that is cool, it uses precalculated slopes, and only a few slopes reused through out the game. That's how donkey Kong country and speedy Gonzalez works, too.
Uniracers is the closest I've seen the snes get to doing sonic-like calculations.
in a technical comparison between SNES and Genesis, SNES is superior in the numbers in every way except one -- Genesis has a higher clock speed on its CPU.
That's "blast processing" -- Sega identifying the one thing in a tech comparison that doesn't lose out to SNES and making it into marketing lingo.
Very smart marketing, but there's no real substance there. SNES is better hardware from a technical standpoint.
That's "blast processing" -- Sega identifying the one thing in a tech comparison that doesn't lose out to SNES and making it into marketing lingo.
Very smart marketing, but there's no real substance there. SNES is better hardware from a technical standpoint.
If we're talking numbers, you're forgetting that the Genesis has a higher resolution (SNES has a high res mode but I can't think of any game that actually uses this for things other than menus and such), more sound channels, and there's probably other things I'm not as knowledgeable about. And I think you might also be underestimating what a huge general advantage a better CPU is due to the large amount of different applications that has, several of them brought up in the thread already like the specific math calculations for Sonic's physics and Shiny's art compression.
SNES was also locked at 32khz audio while Genesis could go up to 44.1khz.
The Sega Genesis had faster CPU.
I can't imagine the Super NES doing Sonic 2's split screen mode as fast as the Genesis. Even the Genesis slowed down then one of the players dropped a lot of rings, for example...
Didn't games like Final Fight series not even allow 2-player coop due to SNES's slow ass CPU? Streets of Rage series on Genesis had 2 player coop and FAR more enemies on screen as well.
So yeah, Sonic and Streets of Rage could not run the same on SNES.
I can't imagine the Super NES doing Sonic 2's split screen mode as fast as the Genesis. Even the Genesis slowed down then one of the players dropped a lot of rings, for example...
Didn't games like Final Fight series not even allow 2-player coop due to SNES's slow ass CPU? Streets of Rage series on Genesis had 2 player coop and FAR more enemies on screen as well.
So yeah, Sonic and Streets of Rage could not run the same on SNES.
To give an example of the cost of these math routines, this is a java implementation of mulu (multiplication between unsigned integers)
The snes would need similar code to the above to do multiplication. Meanwhile, the genesis does all of the above with the following call:
Code:
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:
Code:
MULU.W <ea>, Dn 16 x 16 -->; 32Damn the music in Bio Force Ape is pretty good.
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.
MrCunningham
Member
The GBA isn't similar at all to the SNES though. It uses a 32bit ARM CPU at 16.78MHz, while the SNES used a 16bit Ricoh CPU at 3.58 MHz. The GBA is well beyond the capabilities of either the SNES or the Genesis.
The SNES's high resolution mode was used in RPM Racing, which is the prequel to Rock 'n Roll Racing.
The background layer is using the SNES's high resolution 512x448 mode, while the foreground objects are being displayed at the systems standard resolution of 256 x 224 and is being stretched on top. The SNES's high resolution layer can only display a maximum of 16 colours, which is why it was rarely ever used.
Using Mode7 to produce much smoother and seamless rotation on the special stages would have been interesting. Though you would still have to account for the unique gameplay mechanics being able to carry over as Krejlooc mentioned. Maybe it's more feasible in the special stages since it's more of an isolated environment with less stuff to account for?
Are there any notable pinball games on the SNES? That could probably be a useful point of reference.
Are there any notable pinball games on the SNES? That could probably be a useful point of reference.
The special stages in sonic 1 can actually rotate smoothly in software, there is a flag you can set to enable it. Nobody is sure why Sega set them to rotate in steps, but the assumption is the decision was made for balance issues.
If you look around, you can find hacks that enable smooth rotation.
There's a port of pinball fantasies on the snes, but it's pretty poor.
To Far Away Times
Member
Early SNES games such as Super R-Type had a lot of issues with processor speed. Compare multiplatform games and you can usually feel a difference between the two. Sonic could have worked on the SNES, but not as a straight port, and the game would have been designed around the SNES strengths rather than the Genesis.
It would have been Sonic only in name as the SNES CPU was nowhere near as strong and the sprite limit was lower.
There is nothing to debate. The SEGA Genesis/Megadrive could process things at a far higher level than the SNES could under any circumstance.
Also, if you want to get into added functionality like the chips some SNES games would put in their cartridges to get around the system limitation, then we can just bring in the ones the Genesis used of its system addons like the SegaCD or 32X and call it a day.
There is nothing to debate. The SEGA Genesis/Megadrive could process things at a far higher level than the SNES could under any circumstance.
Also, if you want to get into added functionality like the chips some SNES games would put in their cartridges to get around the system limitation, then we can just bring in the ones the Genesis used of its system addons like the SegaCD or 32X and call it a day.
protomouse
Member
Sure. Whatever tasks the CPU can't handle could be deferred to specialized co-processing logic on the cartridge itself. That's the beauty of the SNES design.
Chittagong
Gold Member
Thank god my 14 year self didn't know I would be still reading debates of whether Blast Processing is real when I am 35, I might not have had the will to live
RAIDEN1
Member
Well without a dedicated "Super FX " chip like booster in the actual cartridge I think it is fair to say a stock SNES wouldn't have as good a conversion of Sonic 1 as the MegaDrive...
One thing is for sure though it'd look a hell of a lot more vibrant on the SNES as compared to the M.D with its limited colour palette, even the music might of been better...
On the other hand, I couldn't see Super Mario World being anywhere close to what it was on the SNES....even if it was not the most speed-inducing game there is in the 16 bit world..
One thing is for sure though it'd look a hell of a lot more vibrant on the SNES as compared to the M.D with its limited colour palette, even the music might of been better...
On the other hand, I couldn't see Super Mario World being anywhere close to what it was on the SNES....even if it was not the most speed-inducing game there is in the 16 bit world..
And thus the game would have been like $99 on the snes.
SmokedMeat
Gamer™
The SNES was a major slowdown machine. No way would the SNES have handled Sonic's faster moments without chugging.
A Black Falcon
Member
For Sonic, I'd think that it's the physics in the main game itself that would be the hardest thing to get working well on SNES... for the special stages, yeah, just redo them in Mode 7.
Jaki Crush? I don't know if it quite matches up to its predecessors Alien Crush (TG16) and Devil's Crush (TG16 & Genesis), but it's still a pretty good game...
Yeah, the GBA could also do sprite scaling and rotation which was always a weird omission in the SNES hardware. It was even surprisingly capable of 3D graphics.
Ghost_Messiah
Member
As Krejlooc so intelligently said Sonic's engine is very CPU intensive and requires a super fast processor. SNES just isn't going to pull it off with the CPU bottleneck. Whilst the SNES is a wonderfully designed machine that's superior to the Genesis hardware overall the slow processor renders it incapable of running something like Sonic and Tails bulleting down pipes in Chemical Plant Zone at high speed. Yuji Naka and Sonic Team at the time were godlike programmers for that era and pushed the Genesis and pushed it hard.
As for the blast processing debate yes it's a clever marketing term but also holds an element of genuine truth as Krejlooc also stated and proved a few replies back.
As for the blast processing debate yes it's a clever marketing term but also holds an element of genuine truth as Krejlooc also stated and proved a few replies back.
The earliest Nintendo flagship titles on the system (SMW and ALttP) were fairly conservative with utilizing the hardware, such as using 8 colors per tile instead of the supported 16 as a means to keep the art size down. So I think it stands a decent chance at surviving a 1:1 port. Common SNES GPU tricks like rotation can be done in software instead with the extra CPU to spare.
There's a brilliant guy in the retro programming scene called gasega68k who has worked on demoing SNES specific games and features on the Genesis, like mimicking mode7 rendering for a Sonic kart racer and Star Fox (which is extra impressive considering it is still using vanilla hardware while the SNES had to rely on the Super FX)
http://www.youtube.com/watch?x-yt-ts=1421914688&v=eCxu_dWOMW4&x-yt-cl=84503534
http://www.youtube.com/watch?v=YUZpF2JLF4s
Also not quite related but still deserving of mention is his port of Wolfenstein which is by far his finest piece of craftmanship, considering how it performs even under the most stresful conditions
http://www.youtube.com/watch?v=-sAZWWbY4n4
Cynn
Member
Thanks. Saved me the trouble of posting that.
Sonic the Hedgehog as it was constructed was very CPU-intensive, and not because of anything related to graphics. The physics and collision code ate up a lot of CPU time as did the object code, which was designed to handle many many active independant objects running at the same time. The original Sonic suffered from tons of lag despite the Genesis's fast CPU and it wasn't until Sonic 3 overhauled the entire engine and optimized the hell out of it that the game managed to run lag-free. By the way the Genesis CPU is roughly twice as fast as the SNES one.
So no, I don't think Sonic the Hedgehog would work on the SNES, not without some extensive reworking from the ground up.
So no, I don't think Sonic the Hedgehog would work on the SNES, not without some extensive reworking from the ground up.
KojiKnight
Member
For curiosity's sake... what exactly does the SNES DSP series of special chips do? They are math co-processors, do they have functions for hardware mul/div?
http://en.wikipedia.org/wiki/List_of_Super_NES_enhancement_chips#DSP
I can't find specific information, but it seems to be that's what it's primary purpose was. If so, $99 seems way overkill when you look at the prices of games like Pilot Wings and Mario kart.
cheststrongwell
my cake, fuck off
This thread is a blast from the past. Reminds me of junior high.
The Sprites in Streets of Rage weren't as detailed as Final Fight though and were much bigger.
Neff
Member
It could have done Sonic 1 easily, maybe even better. It would have been tough to do Sonic 2 as well, but it could probably manage.
I think it'd struggle with Treasure's stuff (Gunstar Heroes, Dynamite Headdy) or Konami's post-Treasure exodus 'look we can do it too' stuff (Contra Hard Corps, Castlevania Bloodlines), simply due to the huge number of fast sprites.
Something like Red Zone, which I still think is the Mega Drive's most impressive tech demo, would be very hard to do on SNES, if not actually impossible.
I think it'd struggle with Treasure's stuff (Gunstar Heroes, Dynamite Headdy) or Konami's post-Treasure exodus 'look we can do it too' stuff (Contra Hard Corps, Castlevania Bloodlines), simply due to the huge number of fast sprites.
Something like Red Zone, which I still think is the Mega Drive's most impressive tech demo, would be very hard to do on SNES, if not actually impossible.
That + 60fps was absolutely mind blowing in 1991, and I agree it still looks fantastic today.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.
Hero of Legend
Member
The SNES's high resolution mode was used in RPM Racing, which is the prequel to Rock 'n Roll Racing.
The background layer is using the SNES's high resolution 512x448 mode, while the foreground objects are being displayed at the systems standard resolution of 256 x 224 and is being stretched on top. The SNES's high resolution layer can only display a maximum of 16 colours, which is why it was rarely ever used.
Oooh! :O Never knew this! Wonder what games could've used this without splitting the screen and getting the most out of it.
Any other examples? Not just SNES but other platforms? A lot of tech specs I see around for consoles on Wikipedia show multiple resolutions.
Sonic 1 and 2 run on the same engine. All of them do, in fact, with small optimizations and tweaks.
This mostly comes down to cartridge size (and how clever you are with compressing assets I suppose). I think Streets of Rage 1 was a 512kb cartridge. Final Fight on the SNES of course didn't even have Guy as a playable character. I think FF on SNES was also 512kb.
Both series rectified both of these issues in their sequels. And the Sega CD port of Final Fight, having the advantage of CD storage had bigger sprites than any of them, probably nearly identical to the arcade ones (probably horizontally squashed as Capcom's arcade games had a very wide resolution).
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.
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.
Dsp-1 does matrices math - projections, transformations, rotation, identity, scaling matrix math. Its not a general purpose math coprocessor, it's only useful for specific matrix calculations.
The super fx chip is a dedicated math coprocessor.
Coolio McAwesome
Member
I maintain that the SNES was a way better console that the Genesis and that Sonic was never half the game that Super Mario World was.
That said, Sonic could NOT have been done on the SNES. The SNES wouldn't have had any trouble pushing the visuals. Any decent developer would have had the game running every bit as fast as it did on the Genesis. The issue is resolution.
The Genesis ran at a resolution of 320x224. The SNES ran at 256x224. What these means is that the Genesis had more pixels to work with. This was MUCH more important in 1991 than it is today as spites don't scale in the same way that polygons do. Resolution doesn't really matter at all today as far as fundamental gameplay is concerned. It mattered in the 2D era, but nobody cared or noticed. Go figure.
Basically, the Genesis had 25% more horizontal real-estate to work with. This is why some games (like Earthworm Jim) were so much better on the Genesis. In the SNES version, you couldn't see as far ahead and were forced to make blind jumps. A game like Sonic would have been horrible on the SNES because you wouldn't have been able to see as far ahead. They could have tweaked things to push Sonic further back on the screen in order to give the player more time to react, but there's no getting around the fact that there is 25% less pixels to work with and 25% less time to react to obstacles and enemies. The SNES would have had no problem making a game that moves as fast as Sonic. The hardware was perfectly capable, and anyone that suggests otherwise is fooling themselves. However, it wouldn't have been appropriate for a game that moved that fast given the fact that you didn't have as much screen real estate to work with.
That said, Sonic could NOT have been done on the SNES. The SNES wouldn't have had any trouble pushing the visuals. Any decent developer would have had the game running every bit as fast as it did on the Genesis. The issue is resolution.
The Genesis ran at a resolution of 320x224. The SNES ran at 256x224. What these means is that the Genesis had more pixels to work with. This was MUCH more important in 1991 than it is today as spites don't scale in the same way that polygons do. Resolution doesn't really matter at all today as far as fundamental gameplay is concerned. It mattered in the 2D era, but nobody cared or noticed. Go figure.
Basically, the Genesis had 25% more horizontal real-estate to work with. This is why some games (like Earthworm Jim) were so much better on the Genesis. In the SNES version, you couldn't see as far ahead and were forced to make blind jumps. A game like Sonic would have been horrible on the SNES because you wouldn't have been able to see as far ahead. They could have tweaked things to push Sonic further back on the screen in order to give the player more time to react, but there's no getting around the fact that there is 25% less pixels to work with and 25% less time to react to obstacles and enemies. The SNES would have had no problem making a game that moves as fast as Sonic. The hardware was perfectly capable, and anyone that suggests otherwise is fooling themselves. However, it wouldn't have been appropriate for a game that moved that fast given the fact that you didn't have as much screen real estate to work with.
I like it when people say stuff like this without making any sort of technical argument at all
You're right, but I do think it's important to note the distinction between Sonic 1/2, which are virtually identical at the engine level save for small tweaks and optimizations and game-specific additions, and Sonic 3K, in which many of the game's core subsystems were heavily rewritten to be more efficient and use less CPU cycles. Not that you don't know all this already, I'm just saying
I like it when people say stuff like this without making any sort of technical argument at all
I don't know what it is about hardware comparison threads that attracts the most reductive armchair analysis.
You're right, but I do think it's important to note the distinction between Sonic 1/2, which are virtually identical at the engine level save for small tweaks and optimizations and game-specific additions, and Sonic 3K, in which many of the game's core subsystems were heavily rewritten to be more efficient and use less CPU cycles. Not that you don't know all this already, I'm just saying
I was more pointing out that if something could run sonic 1 no problem, it would be able to run sonic 2 no problem as well
- Status