Action 52 is broken as of a few versions ago it appears. Still broken in the latest dev build. It launches into one of the minigames and you can't make it to the main menu. This is in NESHawk and QuickNES doesn't support it.
So I've run into a bit of an issue with capturing the Bizhawk window with XSplit.
I brought up an issue in the past and we learned that it was an issue with Jabo and XSplit's game capture not playing nicely. Now that Jabo is dead, I went to start using game capture again and came across a new issue.
In DirectX mode, XSplit doesn't detect Bizhawk as a directx program so I can't capture it. In OpenGL mode, game capture just gives me a solid white screen in the viewport.
I've noticed other programs which hook directx applications (such as Rivatuner and OBS) fail to detect Bizhawk in DirectX mode as well.
The OpenGL issue is most likely on XSplit's side (as OBS can capture fine in OpenGL mode) but the DirectX issue affects everything I have which hooks DirectX. Nothing can detect Bizhawk when in DirectX mode.
This wasn't an issue in 1.X (I just recently started using 2.X). Things could hook it fine in DirectX mode
I've run into a problem with BizHawk that has persisted since I ran the prereq installer. I keep getting these errors:
System.Exception: Initialization of Direct3d 9 Display Method failed; falling back to GDI+ ---> System.BadImageFormatException: Could not load file or assembly 'SlimDX, Version=4.0.13.43, Culture=neutral, PublicKeyToken=null' or one of its dependencies. An attempt was made to load a program with an incorrect format. ---> System.BadImageFormatException: Could not load file or assembly 'SlimDX, Version=4.0.13.43, Culture=neutral, PublicKeyToken=null'. This assembly was compiled for a different processor.
at System.Reflection.RuntimeAssembly.nLoadFile(String path, Evidence evidence)
at System.Reflection.Assembly.LoadFile(String path)
at BizHawk.Client.EmuHawk.Program.CurrentDomain_AssemblyResolve(Object sender, ResolveEventArgs args)
at System.AppDomain.OnAssemblyResolveEvent(RuntimeAssembly assembly, String assemblyFullName)
--- End of inner exception stack trace ---
at BizHawk.Bizware.BizwareGL.Drivers.SlimDX.IGL_SlimDX9..ctor()
at BizHawk.Client.EmuHawk.Program.SubMain(String[] args)
--- End of inner exception stack trace ---
and
System.BadImageFormatException: Could not load file or assembly 'SlimDX, Version=4.0.13.43, Culture=neutral, PublicKeyToken=null'. This assembly was compiled for a different processor.
at BizHawk.Client.EmuHawk.KeyInput.Initialize()
at BizHawk.Client.EmuHawk.Input.Initialize()
at BizHawk.Client.EmuHawk.MainForm..ctor(String[] args)
at BizHawk.Client.EmuHawk.Program.SubMain(String[] args)
Any ideas?
something installed a slimdx.dll to your windows system32 or syswow64 directory. It should not have done that. Remove it. If you find out what did it, put that dll in that application's directory and you'll probably fix it (after having broken it by removing it from the windows system directory)
Putting in Gameboy Game Genie codes in the Cheat Code Converter erroneously displays All GameShark Codes must be Eight characters in length. Also, it compares a 2-byte value in System Bus when it supposed to compare a 1-byte value in the ROM.
Game Gear Game Genie codes don't work as it says All Master System Action Replay Codes need to be nine characters in length.
Genesis Game Genie codes probably don't work. I tried Sonic the Hedgehog 2, tried both versions of the 99 lives code, but they don't do anything.
For SNES Game Genie codes, they're not supported yet and I may discuss it in another topic.
I opened an issue on this on Github but thought I'd post it here as well.
If Glide64Mk2 is your graphics plugin then you swap cores, a few seconds after the new core has loaded and the game has started, Bizhawk will hang then proceed to crash with no exception.
Steps to reproduce:
Set your N64 video plugin to Glide64MK2
Load an N64 rom
Swap to any other core
Wait around 5-10 seconds
A crash should occur.
cheats are all broken right now. don't discuss it in another topic. use 1.x if you need cheats.
Is this just the cheat converter that's broken for some cores? It seems as if I'm able to manually apply cheats with no issues. I used the cheat converter the other day and it worked fine (at least on PSX with the game I was using)
Any cheat code that you can manually apply, but yet the converter deosn't work, you can post a bug about on the bug tracker. "doesnt even work when i manually apply cheats" or "doesnt work at all" we already know about.
I was TASing an N64 game and noticed an annoying bug that can happen with the GLide64 plugin (I never saw the bug with one of the others). What happens is that when loading a savestate, the picture either freezes on the frame of the savestate or glitches into a black and white mess. The emulator itself doesn't freeze or anything, you can still advance frames or load savestates, only the picture is broken. The only way to fix it is by closing the emulator and hope it won't happen the next time. It also seems that the bug can only happen the first time you load a savestate.
I was playing on a 1.xx version when I got the bug and finally updated to 2.2 because I read that the 2.0 release had improved the GLide64 plugin, but it seems the bug is still present.
Is GLide64 even considered stable for TASing?
Current project: Gex 3 any%
Paused: Gex 64 any%
There are no N64 emulators. Just SM64 emulators with hacky support for all the other games.
Any cheat code that you can manually apply, but yet the converter deosn't work, you can post a bug about on the bug tracker. "doesnt even work when i manually apply cheats" or "doesnt work at all" we already know about.
I think you misunderstood what I said. If I manually add a cheat through the cheat interface, it works perfectly despite you saying cheats don't work at all.
Now one thing I have noticed is that the hex editor wont properly display smaller cheats on systems where the memory size is larger than one byte, but if you swap into 1-byte display mode it displays properly. Did this improper display lead to the assumption that cheats were completely broken?
The only things that appear to be broken are the cheat converter, the display of smaller cheats in the hex editor on multi-byte systems, and the endianess of cheats.
I'm questioning this as you're saying that cheats are completely broken when it seems like cheats aren't broken, just parts of the cheat system
Cheats are so broken that I say they're completely broken. If they work, then you get lucky.
Your screenshot is a problem with the hex editor, not the cheats. I don't see any problem with endianness.
If you are able to manually enter any cheats which work, but yet you cannot use the cheat converter to achieve the same results as that manual cheat, then submit that as a bug in the cheat converter.
If a manual cheat works, then great. I'm surprised.
if a manual cheat does not work, then I'm not surprised.
I investigated even more and it turns out it's another hex editor bug. The hex editor always displays the cheat the same way despite what the values really are. I was checking data against the hex editor which led to it appearing broken.
https://narry.land/KbqcNV.gif
Either way, I still stand behind the statement cheats work fine. You can even see in the gif that they're being applied fine and are properly replicated in game. This applies to every single core I've tested.
Edited by feos: Don't embed huge images.
Edit: Apologies for the large image. I forget at times when I take a screenshot on a 4k monitor the actual resolution is way larger than it seems. Most of the forums I post on have a [thumb] tag to thumbnail image embeds.
Edit 2: Well this debate was pointless now that zeromus has cleared up what he meant by broken.
Not too long ago I installed the supposedly 64bit version of the Camstudio codec, but it's still not showing in my Bizhawk 2.0's list of compressors. Only Lagarith is listed.
Out of the 2.0 users here, does anyone have Camstudio in their list of compressors at all?
Joined: 4/17/2010
Posts: 11478
Location: Lake Chargoggagoggmanchauggagoggchaubunagungamaugg
Absent for me too, regardless of Camstudio codec bitness.
Warning: When making decisions, I try to collect as much data as possible before actually deciding. I try to abstract away and see the principles behind real world events and people's opinions. I try to generalize them and turn into something clear and reusable. I hate depending on unpredictable and having to make lottery guesses. Any problem can be solved by systems thinking and acting.
I encountered a crash bug when rebooting core or closing emulator when running Gameboy games.
It looks like the crash happens when going from 'enable BIOS = true' to 'enable BIOS = false'. I'll look into it.
EDIT: It looks like the core is not able to properly dispose of the state pointer for some reason. I don't know why yet.
EDIT2: I don't know, now it just seems to happen randomly. I rebuilt the emulator several times, sometimes it happens, sometimes it doesn't. What does this imply? Compiler bug? Memory management issue?
I encountered a crash bug when rebooting core or closing emulator when running Gameboy games.
It looks like the crash happens when going from 'enable BIOS = true' to 'enable BIOS = false'. I'll look into it.
EDIT: It looks like the core is not able to properly dispose of the state pointer for some reason. I don't know why yet.
EDIT2: I don't know, now it just seems to happen randomly. I rebuilt the emulator several times, sometimes it happens, sometimes it doesn't. What does this imply? Compiler bug? Memory management issue?
This might be able to get you some leads.
Here are two ways to guarantee a crash with that bios setting.
Both of these crashes have been tested across five versions. All tests were done with Kirby's Dreamland and a 100% valid bios file.
2.0 stock (first release with the bios setting)
2.20 stock
2.21 stock
The latest dev build as of writing
My current build of the RTC mod (based on 2.20 with some changes merged in, built with VS 2017. Gamebatte is based on the 2.20 release. We didn't merge in any of the gameboy changes)
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.
>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.
Thanks for the repro steps. I suspect these errors are different from the original one though. Still an error none the less.
Unhandled Exception: System.AccessViolationException: Attempted to read or write protected memory. This is often an indication that other memory is corrupt.
Hmmm, that sounds bad. I'm surprised this wasn't reported earlier. I'll try to sort it out, or maybe I'll just buckle down on GBHawk so we can deprecate Gambatte, at this point it's quite outdated anyway. Either way I'll put this on the issue tracker since it seems pretty serious.
Hmmm, that sounds bad. I'm surprised this wasn't reported earlier. I'll try to sort it out, or maybe I'll just buckle down on GBHawk so we can deprecate Gambatte, at this point it's quite outdated anyway. Either way I'll put this on the issue tracker since it seems pretty serious.
While the Bios is supposed to be enabled for TASing based on the note, deterministic mode doesn't force the setting on like it does with some other cores.
For example, mGBA. Lets you use the core without the bios but deterministic mode requires the bios.
The fact that the setting was added relatively recently combined with the fact that the setting isn't forced on in deterministic mode is probably why it slipped by.
I actually caught the second version a few weeks ago, but I assumed it was because I was trying to load a savestate made with a mismatching setting so I didn't want to waste your time with a bug report.
I only just caught the fact that a crash can occur with the settings matching when getting the exact steps for the mismatching setting crash.
The emulator crashes when trying to loading SNES games with the Super Scope or the Justifier. So games like Super Scope 6 and Lethal Enforces can't be played, but the games still load.
This is not a problem in the 1.x version, but in the 2.x version it is. I hope this gets fixed before 2.3 comes out.
In the latest dev builds, if you use GBHawk, swap to Gambatte, then reboot the core a few times, Bizhawk will occasionally crash (no visible exception thrown).
I haven't found reliable steps to reproduce the crash, but it's happened more than once. If I can get more reliable steps, I'll post them here.
Dang still crashes? That's annoying.
I think I'll have to burn down all my Gambatte changes (they aren't relevent at this point anyway.)
That will teach me to try to modify code that I only vaguely understand.
The only things that appear to be broken are the cheat converter, the display of smaller cheats in the hex editor on multi-byte systems, and the endianess of cheats.
I'm questioning this as you're saying that cheats are completely broken when it seems like cheats aren't broken, just parts of the cheat system
