Emulator Coder, Site Developer, Site Owner, Expert player
(3598)
Joined: 11/3/2004
Posts: 4738
Location: Tennessee
Please don't change that, without a discussion. We will have to add support in the tasvideos submission parser if we change the systemId to "GBC".
Currently it is "GB", with CGBMode flag set to 1.
I would recommend fix the importer to do this, rather than change the systme id
Alright, it now always imports as GB. Sync settings don't respect the implied console type anyway.
At least it will work now. Might need to manually edit sync settings still but oh well.
EDIT: there now isGBC flag is properly set in movie file header and console is selected as either GB or GBC accordingly in sync settings.
Still have to do GBA mode flag manually.
Not sure where to post this, but for lua "memory.getmemorydomainlist()",
Gamebatte returns the following:
"0": "WRAM"
"1": "ROM"
"2": "VRAM"
"3": "CartRAM"
"4": "OAM"
"5": "HRAM"
"6": "System Bus"
While GBHawk returns this:
"0": "Main RAM"
"1": "Zero Page RAM"
"2": "System Bus"
"3": "ROM"
"4": "VRAM"
"5": "Cart RAM"
Can this please be made consistent (numbering + naming)? It broke my lua script for Wario Land 2 due to "Wram" missing, and "Cart Ram" having a different spacing. I have no idea which one has the right name, but making both cores use the same name and index would be really helpful.
Apparently even if you turn on the CGB in GBA option, both Gambatte and GBHawk might read the GB bios instead if you leave Mode on Auto.
I think the best way to avoid this is to merge those two options so the modes are Auto/GB/GBC/GBA.
[14:15] <feos> WinDOES what DOSn't
12:33:44 PM <Mothrayas> "I got an oof with my game!"
Mothrayas Today at 12:22: <Colin> thank you for supporting noble causes such as my feet
MemoryTAS Today at 11:55 AM: you wouldn't know beauty if it slapped you in the face with a giant fish
[Today at 4:51 PM] Mothrayas: although if you like your own tweets that's the online equivalent of sniffing your own farts and probably tells a lot about you as a person
MemoryTAS Today at 7:01 PM: But I exert big staff energy honestly lol
Samsara Today at 1:20 PM: wouldn't ACE in a real life TAS just stand for Actually Cease Existing
Can this please be made consistent (numbering + naming)? It broke my lua script for Wario Land 2 due to "Wram" missing, and "Cart Ram" having a different spacing. I have no idea which one has the right name, but making both cores use the same name and index would be really helpful.
Yeah I can do that, it makes sense.
Fortranm wrote:
Apparently even if you turn on the CGB in GBA option, both Gambatte and GBHawk might read the GB bios instead if you leave Mode on Auto.
I think the best way to avoid this is to merge those two options so the modes are Auto/GB/GBC/GBA.
I don't think this is a compelling enough reason to break movie compatibility for.
I don't think this is a compelling enough reason to break movie compatibility for.
Didn't know that would cause compatibility issues. Sorry.
Would it be okay to at least make it ignore the Console Mode option when CGB in GBA is on so that GBC bios is always read instead then?
I updated memory domains to be consistent between GBHawk and Gambatte.
Mostly this was just changing GBHawk names and ordering.
But I did make one change to Gambatte, I moved CartRAM to the end because it doesn't always exist. This is consistent with how SRAM domains are handled in other cores. So @jlun2 you'll have to update your script to reflect this.
I have started the process of converting GBHawk to C++.
It should be a lengthy but relatively easy process compared to porting the z80 core.
Nothing will change for now, and nothing will change from the user interface side regardless.
This transition will free up much needed overhead for the linked modes and lay the foundation for future work.
There is something that has been bugging me for a while, until I decided to actually look into it. I created a simple hello world ROM that is internally flagged to be a GBC game, but it doesn't set any palette color during execution. Yet, when I open it in most emulators, a bunch of seemingly random colors are initialized for the sprite palettes. However, they are initialized as all black when opening this ROM in GBHawk. I'm not sure which one is the more correct behaviour. Quoting from Gameboy Development Wiki:
Note: All sprite colors are left uninitialized by the boot ROM, and are somewhat random.
Are the sprite palettes really initialized randomly by the original hardware? If yes, then I agree to inizialize them as 0xFF bytes.
Using the latest interim build, it seems the addresses are at a different location for GBHawk than Gamebetta. For instance, in Wario Land 2 GB, Gamebetta has NPC data at 0x1000 in WRAM. In GBHawk, it's now at 0x2000. This also appeared to be the case for tile info, and thus the script won't work.
Also while attempting to open hex viewer after RAM Search/Watch I get this error:
https://pastebin.com/HVjq75Gg
Edit: The tile data is also different, despite being located in ROM. Not sure what is making it different.
Here's a screenshot of what I meant by the script isn't working:
This is the code:
https://github.com/lunjesse/BizHawk-display-scripts/blob/master/WL2Overlay.lua
I've got most of GBHawk ported to C++ (still not accessible in the Dev builds yet though.)
With basically a one-to-one port and only minor optimizations, I get only a 60 fps boost from the conversion. This is much less then I was hoping for and hardly even worth it.
I'm going to spend some time seeing what else I can do to speed things up, but probably this is the end of the road for my one cycle at a time approach.
But anyway my goal is to get a 2x boost over the current C# core, right now that goal is a very long way off.
@jlun2 I'll look into that stuff once this process is over.
I was getting ~220 for GB games, and after the port about ~280 (unthrottled, no rewind enabled)
So about a 25% increase
EDIT: it turns out that I can get most of the additional benefits just by applying optimizations I made in C++ to the original C# core. I got to 260 fps (compared to 300 I got up to in C++.)
It seems like my core design just isn't suitable to C++. I'll need to rethink things from the ground up in future cores.
I think I'll probably ditch the C++ core. (I'll remove it from the code base but keep it locally in case I need it in the future.) With a few more optimizations to the C# core I'll probably be up around where I was anyway. And the optimizations also help out the linked modes, which was my original goal anyway.
I have done quite a bit of optimizing GBHawk as a result of what I learned in trying to go to C++. GBC single and double speed modes are about 10% faster now. GB mode is 25% faster thanks to fixing a bottleneck.
This isn't much obviously but it really helped out 4 player linked modes.
I have scrapped the C++ core for now (I have it saved locally for possible future use in maybe a SGB core, but not sure yet.)
This was still a worth while experiment as I learned a great deal in a relatively short amount of time. But that's enough with optimization for now. I'll be going back to bug fixing mode and syncing console verified gambatte runs and other accuracy stuff.
I tested wario land II and save ram seems to work fine. Fortranmn did you use File->SaveRam-> Flush SaveRam?
I'll start looking into memory domains. EDIT: GBC version seems to be fine, was it only GB version you have problems with jlun2?
It's the opposite. The GB version works fine but the GBC version doesn't save on GBHawk for me. I did not use Flash SaveRam for sure.
I just fond out that the save file actually shows up properly when I use an in-game soft reset, but that's not the case when I use the Emulation->Reboot Core button. Maybe it is because the core doesn't generate the SRAM file before it resets via that button?
This is the code:
https://github.com/lunjesse/BizHawk-display-scripts/blob/master/WL2Overlay.lua
