I've recently released a new Game Boy Advance emulator that I've been working on for quite some time. One of the goals for this emulator was making it more accurate than VBA, which seems to be the de facto GBA emulator. I absolutely love watching speedruns, TASes, and other very-high level playing, so another goal was to make a comprehensive workflow for power users, such as TASers and ROM hackers.
However, I'm not sure how far along I am with the first goal, as this is only the first release. And as I'm not sure how accurate the emulator is, I postponed finishing up the re-recording tools for the second release. I figured there would probably be bugs bad enough that when I fix then, it may cause desync with older movies. I actually fixed such a bug shortly before I released the first version. Furthermore, I'm very interested in getting feedback from users as I develop the emulator so I can know what to focus on, what I'm doing right, and what I'm doing wrong. I could try to guess what people want, but given that I've never done TASes myself, I don't want to make any assumptions about what people would actually want.
There is already re-recording support in the core. It's not currently exposed, but it's almost done being written. It takes a bit of a different approach to how movies work than other emulators, though, especially with regards to re-recording: each segment of a movie, from one savestate to another savestate, is a separate file. Savestates contain information about which file contains the latest branch of the movie, and each file contains information about its predecessors. In this way, it's similar to the "git" version control system. The two biggest things that are not implemented in the core at the moment are the ability to boil down this mess of files into a single file for a whole run, for the purposes of distribution, and the ability to resume recording of a movie. Obviously both of these are imperative, and I will be implementing them as soon as I get a basic GUI working.
I've read the emulator feature page on the wiki, so I know approximately what I should implement, but I'm looking to be as involved with the community as possible during development so I can provide what people really want out of a re-recording emulator.
In the realm of accuracy, I believe my emulator is quite accurate. However, I don't have an objective measure of this. I know there are bugs that I've seen in NO$GBA that don't exist in my emulator (for example, on the world map of Golden Sun, NO$GBA gets very glitchy), and I've also been informed of bugs in VBA that have reproduced in my emulator, before I fixed them (for example, the notorious slowdown near the snowman in Croket 2). There only seem to be a handful of GBA accuracy tests out there, and I pass all of the ones I've found, but they aren't very comprehensive. In fact, one of them fails on real hardware (so I match that failure, of course), so it's a bit questionable how useful that one is. I dug through the wiki and only found GB accuracy tests, but I do not support GB/C, only GBA. I'm hoping the people on this forum can help me find ways to gauge accuracy, either to prove my claims, or to find bugs so I can fix them and get closer to my goal. At the time of writing this post, I have no known game bugs. That definitely doesn't mean I don't have any game bugs, though. There are some graphical effect combinations I haven't implemented yet, for example (mostly relating to OBJWIN in different BG modes, or MOSAIC on transformed sprites). As an aside, I know I implement MOSAIC on sprites
way better than VBA does, and I actually filed a bug on VBA-M's forums to this effect. I was promptly ignored.
The first version is available on my website:
http://endrift.com/mgba/
The source code (MPL2 licensed) is available on GitHub:
https://github.com/mgba-emu/mgba (I'm not currently taking patches, but if anyone has something they really want to contribute, I may reconsider--I just want to get a bit more established before I open it up for contributions)
Of note: there's a problem with the first version and stuttering. This is easily solved by going to Emulation and turning off Sync to video. This will be off by default in the second version.
I've been in IRC for a good chunk of the day, trying to gauge interest from people, so if you want to catch me in IRC, I'm jpfau.
A list of tasks left to complete before I call the emulator "good for TASing" can be found on my bugzilla with the keyword "
TASBlocker". I'm very much still open to feature requests at this stage, although they may be put on the back burner, as there is a huge list of open tasks at the moment.
tl;dr, tell me what you want and how to fix my emulator so I can make a great GBA emulator, especially for TASing and other power users!
Congratulations, I've had trouble finding any games that break mGBA, despite the fact that I was sure more exist. I'll get to fixing this in time for 0.1.1!
E] Good news, I fixed it. I still am not sure how to reproduce your glitch in my emulator, though. It looks like an extremely cycle-dependent thing, though, since it's save corruption. Nasty business, not likely to reproduce on hardware, especially if you're using the emulator's BIOS (as the VBM says you are). I really can't recommend using mGBA's HLE BIOS with TASes at all, and was planning to basically force you to use BIOS, as without them, cycle counting is horribly wrong for a lot of things. (Especially stage loading and switching screens, etc. Anything that loads graphics, basically, will be off, potentially by a frame or two.) Combining that with save corruption, which is what this TAS appears to do, and you have an unpredictable set of input that may get lucky. If it's Flash save corruption, instead of SRAM (this is SRAM), then you're basically just out of luck. That stuff takes a variable amount of time to write, and my emulator assumes that variable is 0.
(The sound still needs fixing, but the games run fine otherwise!)
