Next frame:
Here is a short 8000 frames movie showing it happening (flickering occurs at frames 599 and 6027):
https://www.dropbox.com/s/ac1g6e6702j972g/Rushing%20Beat%20%28Japan%29.bk2?dl=0
Here is a save state (to reproduce the issue, just don't move your character at all):
https://www.dropbox.com/s/4ioa5te67pilolr/Rushing%20Beat%20%28Japan%29.Compatibility.QuickSave0.State?dl=0
ROM used: Rushing Beat (Japan) - No Intro
Emulator version: BizHawk 2.1.1
Emulator core: BSNES
Is this a normal thing with the game, or an emulation bug?
User Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:54.0) Gecko/20100101 Firefox/54.0
Vector Block Result Duration
12 3 correct 518.09ms
13 3 correct 1191.83ms
14 3 correct 1133.40ms
15 3 correct 2066.59ms
16 3 correct 6845.66ms
12 4 correct 1363.22ms
13 4 correct 1624.70ms
14 4 correct 3131.62ms
15 4 correct 3405.96ms
16 4 correct 7344.03ms
12 5 correct 1017.95ms
13 5 correct 1749.64ms
14 5 correct 3571.84ms
15 5 correct 7649.49ms
16 5 correct 17447.13ms
Status: Done.
Users using 2.0 will have the pleasant surprise of crashing when loading up a SegaCD game. Users of BizHawk 1.13.1 and older won't be having these issues.
Problem signature: Problem Event Name: APPCRASH Application Name: EmuHawk.exe Application Version: 2.0.0.12452 Application Timestamp: 594fef52 Fault Module Name: StackHash_2264 Fault Module Version: 0.0.0.0 Fault Module Timestamp: 00000000 Exception Code: c0000005 Exception Offset: 0000036f01401bb0 OS Version: 6.1.7601.2.1.0.256.1 Locale ID: 1033 Additional Information 1: 2264 Additional Information 2: 2264db07e74365624c50317d7b856ae9 Additional Information 3: 875f Additional Information 4: 875fa2ef9d2bdca96466e8af55d1ae6e
This is so absurd that it's hilarious.
Config -> Rewind & States Notice by default rewind is off on cores with larger savestates. This is because there is a performance cost. Turn it on for cores you want and fiddle with settings. Rewind works for all cores. You are just reporting what the default options are here.
* SNES - Snes9x 1.54 ported. Note that bsnes still should be used for serious TASing intended for submission at TASVideos. But snes9x is provided for its performance and decent compatibility for casual gaming, botting, and testing
There are 3 options. - Make it work only through libretro, fixing both mame core and libretro to rerecord properly. - Port mame core directly or its libretro interface like a usual bizhawk core. - Waterbox mame in its entirety. The last option can't be done without splitting mame into single driver parts, otherwise each game would have insane overhead in its savestates. The second option requires fist fixing everything and wiring it all up. The first option is supposed to fix everything and wire it up, and make it possible to port mame directly if needed, and it also helps to fix other libretro cores. So I'm working on the first option.
Never mind; resolved by our good friend DiscoHawk!
No solution. Enjoy your non-determinism.
What about their speeds?
The basic guideline is: • For hacks, use the latest version. • For other games, the preferred version is whatever makes the fastest or most interesting run (e.g. using revision-exclusive glitches to speed up the run). If there are no meaningful differences, then it doesn't matter which version you use.
I repeat the same steps except for "4)" where I pick LZO instead of GZIP. The new .avi is saved without problems.
Here's a short video showing all my steps and the error being reproduced:
https://www.youtube.com/watch?v=8_YDtdsOe5Y
I've searched for a solution online and this is the only relevant result I found:
http://camstudio.org/forum/discussion/831/gzip-problem
That person has exactly the same problem as me. But unfortunately, nobody replied to that.
Can someone help me with this? I've had this problem for years and never solved it. I'd like to encode with GZIP because the files are better compressed and become much smaller with said mode.All the determinism hack does is forces a savestate to be taken every frame, even if the frontend did not ask for one. As a result, it makes things slower. It's required because the savestate code in BSNES is worthless junk, and it breaks some things because the savestate code in BSNES is worthless junk. The same bugs do exist on lsnes; you used to be able to desync some movies by taking extra savestates. That may have changed with more recent builds; I think lsnes ignores your savestate request sometimes as a different hack around.