-
Ever wanted an RSS feed of all your favorite gaming news sites? Go check out our new Gaming Headlines feed! Read more about it here.
-
We have made minor adjustments to how the search bar works on ResetEra. You can read about the changes here.
GBA was more powerful than SNES right? (except the sound)
- Thread starter mogster7777
- Start date
There's really no need for that
GBA has enough exclusive games to prove on its own that is far more powerful than SNES.
I would even put it above the 32X, given how well it handles textured polygons.
Yeah, that was my point. GBA is far more powerful than SNES, and seeing people argue otherwise on the basis of sub-par ports of games originally designed for the SNES is kind of embarrassing.
Yeah, i agree. I have a flashcart right now full of games that a SNES could ever dream to move (The amount of FPS available for the console should already tell us that)
And, dude, Doom GBA patched to run the original maps at improved framerate.
It's one of those things that make you go WHAT THE FUCK
It's an amazing little console that only a few studios took seriously.
imo DS was meant as a soft transition but then went gangbusters and effectively became "the new gameboy". i won't be broad as to say the third pillar talk was an outright 'lie' but it was PR speak for we're phasing out a system earlier than normal
Gunstar Super Heroes has the most impressive "super scaler" section on the hardware IMO.
The background, the terrain (which consists of small sprites), the bullets, the enemies are all scaled and rotated constantly and to top it all there is an additional half transparent background to goes on and off to simulate a "going through clouds" effect.
Treasure was a great developer.
Last edited:
What makes it even more mind blowing is that those games are all grouped in the same cartridge as if they were cheap games.
But yeah while not perfect, those ports are pretty mind blowing
Yet the GBA has the best version of SMB3 and the best two 2D Metroids.
Super Ghouls n Ghosts wasn't the only game to suffer severe slowdown though. It was pretty common with SNES, with Gradius 3 being another title to suffer very bad slowdown.
SNES has a very weak CPU from what I remember in hardware comparisons. Maybe people fixed things years later, but it was very much a hardware problem.
GBA ran more impressive looking games and ran them way better.
No no, I agree with GBA being more powerful and running more impressive games. I was just talking about SGnG specifically. I think a patch for Gradius 3 has been released too, but I'm not sure if that required overclock or not.
In the case of Super Ghouls n Ghosts there was indeed a not efficient routine slowing down the game more than it should (it was an early release and the hardware wasn't as well known as at a latter stage).
Anyway SNES was purposely designed around a weak CPU that should be aided by specialized DSP chips.
To make matter worse the CPU run at different speed depending the rom type.
With SlowRom the CPU was capped at 2.68mhz whereas with FastRom the CPU run full speed at 3.58mhz.
SlowRow was cheaper hence why many publishers chose it (especially early one).
Here a Super Ghouls n Ghosts framerate comparison between the original SlowRom and the modification with FastRom:
Another interesting video on the matter is this one in which the developer of the SNES version of Another World talks what she had to do to port the game to SNES:
EDIT:
I think the Gradius 3 patch you are referring to is based on the SA1 chip which run at thrice the original SNES CPU max speed.
SA1 is probably the SNES co-processor with the biggest potential IMO, too bad it was released so late that only a few games used it.
Impressive stuff. Makes me sad I never owned one, as my mind would have been blown had I owned one when it came out.
The guy that told me about the existence of this patch also recorded this little bit of footage using the Game Boy Player
It showcases the music playback, but he also wanders a bit through E1M1
Retro Cabeza on Twitter
āY la mĆŗsica... OMG la mĆŗsica! š± Primero la original, despuĆ©s el hack de Kiddykip. (Capturado con Game Boy Player) https://t.co/RTayKGZOAgā
twitter.com
The GBA was a fantastic device to work with (minus the overly sensitive devkits that would reboot because someone walked by it). It sadly really was hampered by the audio department the most. Since it only had the GBC audio channels and 2 8bit PCM channels, everything had to be handled by the cpu (mixing, and feeding the short 8bit buffers). So a game would loose on average 10-30% of available CPU resources to simply just dealing with audio. =(
The DS had a fixed memory pool for polygons which could fit about 2k triangles (less for quads) and only be flushed every vblank at 60hz. So if you filled it you would get 2k tris at 60fps (or 120k tris a second). The downfall is the fact there was only 1 3D unit and if you wanted 3D on both displays you could only refresh each display at 30hz. Even further the 3D renderer/layer was 565 color depth and the 2D layers were 555, so there would be a drop in color when you captured the 3D rendered layer and displayed it out as a 2D layer while rendering the 3D layer for the other screen.
They were spooked by the forthcoming PSP and rushed the DS out to compete.
Interesting, I never knew that little tidbit.
It's interesting to note that for what should have been a "portable N64", DS seemingly went for an opposite direction favoring stable performance (60 fps) over more effects and higher poly count per frame but at lower framerates.
The GBA's audio and graphics capabilities are better than, but still roughly the same as the Super Nintendo's. The GBA's processor, however, is tons better than the SNES's processor (and even more than SNES with a Super FX).
Because of the GBA's processor, a programmer could really use it to push the GBA's sound system (e.g. playing MOD music and MP3 music) and the GBA's graphics system (e.g. 3D graphics) in ways that the SNES didn't ever do.
That said, a programmer would need to be willing to give up precious CPU power to do all that cool stuff. Plus, they would need to be skilled enough to actually program it all in, too. So in practice, it was rare to see things like 3D graphics and really high quality music on the GBA.
Technically speaking, you could actually do all that on the Super Nintendo as well with a suitable coprocessor, but it would have been very expensive at that time. The best that was done was the Super FX 2, which supposedly made games very expensive and was still not as good as the GBA's processor.
Ooh, that's really cool. Thanks for the neat tidbit!
Because of the GBA's processor, a programmer could really use it to push the GBA's sound system (e.g. playing MOD music and MP3 music) and the GBA's graphics system (e.g. 3D graphics) in ways that the SNES didn't ever do.
That said, a programmer would need to be willing to give up precious CPU power to do all that cool stuff. Plus, they would need to be skilled enough to actually program it all in, too. So in practice, it was rare to see things like 3D graphics and really high quality music on the GBA.
Technically speaking, you could actually do all that on the Super Nintendo as well with a suitable coprocessor, but it would have been very expensive at that time. The best that was done was the Super FX 2, which supposedly made games very expensive and was still not as good as the GBA's processor.
Ooh, that's really cool. Thanks for the neat tidbit!
At it's core, the DS was an evolution of the GBA and in an early phase was just a single screen. It was designed to be as simple to work with as the GBA. Even in the early SDK the libraries were just wrappers to talk to the hardware the same way you would on a GBA (ie through direct register manipulation). When they added a 2nd screen they slapped in a 2nd 2D chip that runs independently for the 2nd display. So the system started to have a few quirks in it's architecture as a result.
I'm pretty sure the DS could do AA. It was either that or edge marking.
Or on the basis of specs and devs actually saying otherwise. I'm pretty sure some dev from rare said SNES is better a year or two ago even.
GBA was way better than SNES. Just the ability to have sprite scaling and rotation alone was a huge upgrade over what the SNES could do, let alone the much faster processor, the higher colour depth, the huge increase in RAM and ROM over what the SNES had, the ability to directly plot pixels (instead of using tile maps) in one of its graphics modes (which greatly improved its 3D capabilities).
The only real downsides that the GBA has over the SNES (and they're not small), is the lower screen resolution and (especially), the lack of a dedicated sound chip. These were its Achilles Heel when it came to SNES ports, though thankfully the sound disadvantage was offset in large part by its greatly expanded cartridge ROM size, allowing for much more generous sample sizes than what the SNES could afford.
GBA is more comparable to 3DO/Jaguar than SNES really (and thanks to its dedicated 2D hardware, is much more capable with 2D games than either of those machines).
The only real downsides that the GBA has over the SNES (and they're not small), is the lower screen resolution and (especially), the lack of a dedicated sound chip. These were its Achilles Heel when it came to SNES ports, though thankfully the sound disadvantage was offset in large part by its greatly expanded cartridge ROM size, allowing for much more generous sample sizes than what the SNES could afford.
GBA is more comparable to 3DO/Jaguar than SNES really (and thanks to its dedicated 2D hardware, is much more capable with 2D games than either of those machines).
As a former GBA developer:
- The bit depths are slightly deceptive (as I guess they all were back then). Bitmap mode was way too slow, and even if you did use it, suddenly you have these giant file sizes that were a huge problem on a 4MB cart. The 512 mode is for tiles, which means 256 background/256 sprites (or 16x16 for the background, if you're interested in palette animation)
- Storage was a critical problem on GBA because it had a few amazing specs but an average cart size of 4-8 megabytes. Main memory was small AND slow, so we had a lot of incentive to read directly from ROM (possible!) Only problem? You can't compress files when you do that. So good luck with your 16bit color Golden Sun-esque backgrounds if they are uncompressed, you'll hit 4MB in short order. (Of course, you could get an 8 or 16MB cart later but that made your game way more expensive...)
- We knew the backlight was absent well ahead of time. But the first kits had the screen built directly into the devkit motherboard, so it was hard to say what Nintendo would change. On the original PCB, "L" and "R" are actually "X" and "Y" on the SNES controller, for example. We hoped...and they changed nothing š
THIS. Jeezus this happened so much. Even the cart burners were awful. Eventually we just used EZFA because it was way more reliable. Only problem is they didn't do any sort of ECC pass, but you could just burn 4 carts simultaneously instead and still be cheaper than one dev cart + burner. We still had dev carts of course, but going to E3 or whatever meant EZFA only.
30% is actually quite responsible. :lol Using the F5 engine if we wanted SNES audio, 60% easy. So we ended up massively compressing samples, going to 16 or 12khz, 8bit mono....just cutting massive corners to keep the audio processing and storage in check. (You are of course right, your game isn't really going to work unless you're at ~25% or less CPU utilization for audio, but again, specs/CPU/storage on this platform was a huge mismatch)