Alright, well luckily other people had already been through the trouble of figuring out how the wave RAM tests work so I basically just had to read through some posts to get the right behaviour. That made it much easier.
With this GBHawk is nominally operational.
I integrated it into the Dev Builds for anyone who wants to test. There are still some bugs so if anyone finds anything please report it here.
I also removed BIOS support from Gambatte due to it's bugginess.
I also put a core picker into BizHawk so you can choose between GBHawk and Gambatte.
There is still a long way to go in terms of development, but as it is right now it's already passes almost all the available test roms, which means it's really solid as a baseline model to develop on.
Next steps will be working through mappers, adding link cable support, implementing nitty gritty details of the ppu, and fixing bugs.
Once all that is done I might take a look at cgb.
If you guys see nothing common between these, you're being ignorant. If you don't see any difference between these, you're being ignorant.
I'm actually in the middle of adding support for over a dozen of the controllers missing from Mesen at the moment (including keyboards, barcode readers, etc.), rewriting the movie file format and allowing every kind of input device to be recorded or used via netplay. The new format is essentially the same as bk2, it's a zip file containing text files for configuration & input log. After that, I still need to make some sort of TAS editor, but that may still take a while (I personally haven't ever used one and don't really know what features people want/need from one)
On the title screen for Kirby's Dream Land, I get around 370 in GBHawk and around 3000 from Gambatte. I know scaling isn't perfect, but I doing the math, that's around 5.6x faster for you and and 8.1x faster for me. That's a pretty significant difference in scaling.
Also, would you be able to expose more memory domains from GBHawk at some point later on? I know my use case is pretty specific but it'd suck to lose all the domains that Gambatte offers over GBHawk (especially the ROM domain as File on Disk doesn't work for my usage).
DO we want to keep Gambatte around as the "performance" core, similar to snes9x/bsnes, quicknes/neshawk ?
What kind of performance can we expect at an unlocked framerate compared to Gambatte?
Guys are you serious? You're telling me the complete collapse of the branching system due to unapproved mass renaming, as well as this whole thread, which caused all site staff members to unite their mental efforts and come up with a solid approach, happened over something completely meaningless?
Will the GBHawk core require BIOS?
Kangaroo (1983) (Atari) [!].a26 from Good2600 v3.14 (Missing 16) doesn't leave the core busy loop. CRC32: 1D961D5A MD5: 35AE38B0DCA275C89C565355CCEBD7AC SHA-1: 982B8016B393A9AA7DD110295A53C4612ECF2141
loading 2-player Game Boy tasproj file crashes the emulator. In fact. 2.2.1 might be unstable when it comes to Game Boy TASing with TAStudio.
The movie time is longer though, due to more accurate emulation
One 100% reliable way to trigger a crash is:>Enable bios in Gamebatte >Load a game and create a savestate (bios enabled) >Quit Bizhawk >Restart Bizhawk >Load the game up again >Load the state
This should result in a crash. The settings all match so it's not a setting mis-match. Another 100% reliable way is:>Load the game with bios disabled >Savestate >Enable bios >Reboot core >Load the state
This one has a setting mis-match (loading a non-bios savestate with the bios setting enabled) so it may be a different crash. Maybe one of those crashes will be able to get you a lead.
Unhandled Exception: System.AccessViolationException: Attempted to read or write protected memory. This is often an indication that other memory is corrupt.
TL;DR: I believe the so called "limited" opportunities at AGDQ 2018 are a result of my own shortcomings/life situations rather than a reflection on the site itself
I can't emphasize enough how much the "limited" aspect of AGDQ 2018 TASBot content is a result of me. This is largely because no one else really wanted to actively share in or take over leading the effort