Wait what? You're saying that 20fps sucks, yet your automatic frameskip only does 60(42) and 20... what's going on here? Are you saying that it _hasn't_ always been that way? As in the 20fps one. Also are you saying that 30fps is ill advised now? Finally does this include the memory access stuff? Or is this just some minor stuff? I'm asking because I want to keep testing this thing since it's faster and at 30fps no crackling @240mhz is damn sweet.
Going back from the start here - I don't know how much you know about TempGBA's past. Sit back and get ready to read, but this will be a good story, don't worry.
In the beginning, there were only NDSGBA 1.21 and NDSGBA 1.30. The users did not like how version 1.30 dropped support for games that worked in 1.21 via the game_config.txt file. It also crashed often, had a GUI you couldn't touch at all despite it being 9 big buttons on the Main Menu,
its performance in Mario Tennis was about 6 FPS with lots of crackling in the sound, and its automatic frame skipper was always at 2 or more, giving games a maximum of 20 FPS. The users were generally not pleased.
Having improved upon ShadauxCat's and BassAceGold's work a lot
in CATSFC, the users started to look towards a revival of the NDSGBA project. Nebuleon did want to at least add the GUI changes from CATSFC into NDSGBA, but did not have the source code. So the community requested the source code from the Supercard team (see the first 7 pages of this thread) and finally got it. There were initially two versions of the project in parallel, one being a fresh port of gpSP Kai and one being an improvement of NDSGBA. And the GUI worked better in the fresh port, due to Normmatt's and BassAceGold's help, so Nebuleon merged NDSGBA 1.21's code into the new project, TempGBA.
TempGBA ran games exactly as well as NDSGBA 1.21, and could make 128 KiB saves, but it quickly gained some features in the GUI department (see pages 8 to 20 or so), such as the ability to remap all the buttons to new DS buttons, a hotkey system inspired by CATSFC's, and the automatic versus manual frameskippers were made to work better.
Unfortunately, frameskip 0 (60 FPS rendered) wreaked havoc when the user tried to run some heavy games on it, and crashed TempGBA. This is the infamous Issue #3 (Crashes at frame skip 0). The users were told that frame skip 0 was only for certain games that gave TempGBA absolutely no trouble, and things were mostly good... but the users kept asking about frame skip 0.
It was possible at this point to make the automatic frame skipper start at 1 (30 FPS), but many games have flashing objects that flash at 30 Hz, so if TempGBA skipped 1 frame, the objects were either always visible, or always invisible! So Nebuleon decided against, and left it at 2 (20 FPS).
Around beta 8, Nebuleon started to ask about the game-specific crashes and slowdowns, looked into the code for some optimisations, and got pieces of information from Exophase and Normmatt, who had more experience dealing with ARM code. And Nebuleon started to optimise things, little by little, not understanding any of the GBA-to-DSTwo recompiler at first. The users were happier, but some games still ran very slowly.
So Nebuleon struggled with the recompiler for a while until all of a sudden it started to make sense. Having had some experience with machine code (assembly) on Intel processors in the past, Nebuleon did not struggle with the low-level details, but rather the high-level ones. "Why doesn't this optimisation work?" "Why did Exophase code this assumption into the code?" "What is the cause of all of those crashes?" So in betas 8 to 10, TempGBA got some new features... but they were not for the mere mortal playing games. They were for developers, statistics and crash information to be gathered for easier debugging and optimisation.
Then, TempGBA got a new GBA-to-DSTwo recompiler base, coded piece by piece -- sometimes breaking the old code completely to remake it into a better foundation. Some new features were added in parallel, but the mainstay was the emulation core. Many games were made to work better; however, some games started to crash (in betas 13 and 15). The bugs were so odd in beta 15 that Nebuleon requested help, and it was provided by the Supercard Team in the form of a special Supercard with a serial line. With this, Nebuleon was able to write, in real-time, information to a computer!
After a few reversions of code and reimplementations of things that did not work well, which Nebuleon called memory-access-3,
many games that previously got very few FPS (Mario Tennis's 6, Golden Sun 2's 17-20, Doom II's 4-12) were suddenly getting way more FPS, almost 60. The users rejoiced. But Nebuleon did not:
Issue #3 still made games freeze the emulator if they were too heavy but the users selected frame skip 0 (expecting 60 FPS on the screen).
So the serial line proved itself to be useful, narrowing down the problem to the frameskip code. Surely enough, a loop in the frameskip code was waiting for the audio code to signal that the DSTwo was ready to accept more sound data. Except, that loop was never to end, because the DSTwo signalled that it had enough audio to play for years!
The bug was fixed, and both Nebuleon and the users rejoiced.
The emulator became stable enough to support 60 FPS rendered, not just 20 FPS. So automatic frameskipping was deemed to be better if it was at 0 (60 FPS) initially. It dropped down to 2 (20 FPS) if the game couldn't keep up. Because many games have flashing objects that flash at 30 Hz, Nebuleon did not want automatic frameskip to be 1 (30 FPS), making them always visible, or always invisible. So the next best thing was to alternate between 60 FPS and 20 FPS depending on the need. It would provide the users with a smooth experience, while not making the sound crackle or flashing objects disappear when the game couldn't keep up. The users were pleased, but not enthralled.
The DSTwo ran TempGBA at 60 FPS and sent its images to the DS's screen, but could not keep up with the sheer amount of data that needed to be transferred.
It needed to send 60 images of 256x192 at 16 bits per pixel, so 5.89 MB per second, but it had only 4.3 MB to spare! That gave it a limit of about 42 FPS, which the user could see the most in scrolling areas, because they were scrolling with a staircase effect.
This being a limitation of the communication link, the users wanted to know whether the communication link could be improved in some way... say, with compression. This created a debate of compression methods, among which there were Deflate, LZ4 and RLE.
And this is the story of TempGBA and its 60 or 42 or 20 FPS.
tl;dr: Important parts are in bold, go read them if you just want quick context