Hacking Emulation Question

[user64]

So I recently got a Supercard DSTWO, and before I did I was under the impression that GBA was harder to emulate than SNES. However, games in CATSFC are slower than in tempGBA (ex. SNES games and their remakes). I was wondering why... is it because of the resolution of the SNES, or a hardware thing, the quality of the emulator, or something else?

 

[Rydian]

So I recently got a Supercard DSTWO, and before I did I was under the impression that GBA was harder to emulate than SNES. However, games in CATSFC are slower than in tempGBA (ex. SNES games and their remakes). I was wondering why... is it because of the resolution of the SNES, or a hardware thing, the quality of the emulator, or something else?

The resolution plays a part, but it's also the layering (SNES has more layers) and other graphical things that differ.

The DS, even with the DSTwo, is limited in a lot of ways. One of those being the transfer speed, the DSTwo can only send so much data to the DS at once.

 

[user64]

So you're saying that the problem is a mix of the layering speed in SNES games, along with the DSTwo's transfer speed due to resolution? It just seemed odd that the GBA emulation was so much faster (fps), considering that the GBA could (attempt to) emulate the SNES.

 

[Deleted member 319809]

There are three main causes.

* CPU emulation. In Snes9x (CATSFC), the CPU emulation loop goes over each instruction, parses it, then determines what to do in C code. That's slow. In gpSP (TempGBA), the CPU emulation loop goes over instructions it has not seen before, parses them, then transforms them into raw machine code that it runs when it is asked to run the game.

* Sound. On the SNES, the audio processing unit (APU) is separate from the CPU and very processor-intensive to emulate, due to having so many things: 8 channels, each with pan, frequency modulation, samples or noise, and an echo buffer. The GBA has 2 direct PCM channels fed directly from memory, 2 beeper channels and noise, and the audio is controlled by the same CPU as the game. Those are much easier to emulate.

* Graphics. The SNES has many graphical modes, with 3 backgrounds, color subtraction/addition effects, or rotation, or transparency/translucency, or fading, and sprites. The GBA has two backgrounds with possible fading, alpha blending and transparency, and sprites.

 

[user64]

Thanks Nebuleon! So for CPU, is it that the SNES instructions are all weird and hard to emulate, but GBA instructions are simpler for the DSTWO to emulate... or is it the nature of the base emulators (Snes9x and gpSP) which cause the two emulators to process the instructions in different ways?

I understand why the audio and video are slower with the SNES, but why does the SNES have a much more complicated audio-visual system? I would imagine that the GBA would have power to display things such as 3 or more backgrounds, so if the GBA isn't processing that much audio or visual content... what exactly is it doing?

Also, does that mean certain video/audio things had to be simplified in games ported from the SNES to the GBA? Such as games with 3 backgrounds displayed at once, did they have to cut one out or something?

 

[Rydian]

I can't speak much for graphics, but when it comes to sound, yes ports form the SNES to the GBA were often gimped. In fact people made ROM hacks to replace the sound data on GBA games to make them sound better than the original porting team cared to do when they had to change everything over.
http://gbatemp.net/threads/final-fantasy-vi-sound-restoration.251239/

 

[user64]

Interesting... I already knew about color restoration hacks, but not about sound replacement hacks.