Of course also note for casual use, you will need a very good PC, much better than upstream or even DeSmuMe. Due to waterboxing, BizHawk melon is forced to a single thread, JIT is not available, and as discussed earlier GPU stuff is probably not possible to expose without just crashing or something. This makes melon in BizHawk much slower than upstream and DeSmuMe (around 6-7x times slower, give or take).
For reference: I get fullspeed on every DS game I've tested, this on a laptop with i7-1165G7 CPU and 16GB of RAM, as long as I use the laptop on AC mode (I have the charge threshold enabled so I can make it a desktop alternative due to COVID and shortage of desktop parts).
Another issue: Shikigami no Shiro (Taito G-NET machine which is PS1-based) suffers from input desyncs especially when there are lots of bullets on the screen. A waterbox solution would be ideal for situations like this.
Yet another issue which luckily only happens with a few games: When you go into Service mode and exit from it, the emulator closes itself. Cannot play RayStorm nor Psychic Force because of this, since it always boots into Service mode (MAME does this too but at least it reloads the game without closing).
Seems this also happens with PSX-based games that don't require a CHD (Capcom ZN1/ZN2 games for example). Had to mux the captured A/V with framerate set to 59.83fps (which is what the Mednafen PSX core uses for NTSC stuff) to 'temporarily' fix it.
More bugs found:
Savestates don't work at all on Cave CV1000 games. Load the state and it'll freeze at the frame where the savestate was made, without crashing the emulator.
And sometimes loading a state can crash. I guess someone reported this already.
How possible is to implement a Dreamcast core? Using flycast source as base: https://github.com/flyinghead/flycast
Flyinghead is okay with forking it as long as you guys use the same name for the core.
Kage, do you have a memory address for Felix's horizontal on-screen position? I think it would help whoever is judging this decide how optimized it is, as well as give insight into why the glitch happens in the first place.
Don't know at the moment, I might check it later.
But, for some reason, when you make properly timed inputs of the A+Right button combo (and B button where possible), the system thinks a single frame is the 'final' part of the level, when there is actually more to explore. When this glitch is exploited repeatedly, it can eventually place Felix very close to the border, tricking the system and consequently autofinishing the current level. This is more noticeable when jumping onto a horizontal-moving log without advancing (something that I even reproduced on real hardware via a Famiclone).
There might be other games from them (Dragon Co) with this same exploit. I might check that with 'Wait And See' since that game has some glitches accidentally left unfixed.
I can say for sure that this was fairly easy for me. With the RTA speedrun as a guide, I made a few optimizations at some levels in order to finish faster.
Next one might be Bao Qing Tian on Famicom. Current RTA record is 11:25 long so that's something to take into account.
(btw, yes I joined much earlier but I didn't have a good PC to encode back then)
