N64 Feature request: I have no idea how difficult this is to implement, but would it be possible to get a more accurate (i.e. slower) emulation of Controller Paks? Right now saves are made nearly instantaneously (within a frame or two), when on a physical console it takes much longer to perform.
This in particular prevents save corruption techniques that work on console from working on Mupen/BizHawk (in particular, I'm thinking of the save corruption glitch in Quest 64).
I just had a conversation with FatRatKnight about lua, and he mentioned that BizHawk used to provide a global GBA memory addresses region like "system bus", that now is no more. I had some uncomfort too because of its lack, so I ask if it would be possible to implement that again in BizHawk.
Of note, I also mention my memory isn't perfect in the IRC logs. Maybe GBAHawk never had system bus reads, and I was just remembering from a different core. Regardless, handling pointers means the script maker must know where each region exists, then include a name along with the trimmed pointer if bus reads are not available. Gets worse if the pointer being read is not constant in what region it references.
There's a bit of other philosophies in the IRC log I talk about as well.
I tried it in mGBA 0.5.2 at the same place with the same NPC but it doesn't occur.
EDIT: Easier way to reproduce the bug in Bizhawk is to go to the title screen menu and press up or down and loadstate right after (during the sound effect it makes).
This isn't really a bug report/feature request, but on later versions on BizHawk, could we have mGBA set as the default core for GBA? It certainly doesn't have any major problems anymore, and most newcomers to TASing don't know that they should switch over to it and end up making movies in VBA-next, which is not preferable.
I've tried TASing Saturn games on Bizhawk, and it's not practical due to the amount of desyncs. Not to mention having clear emulation errors across most games. This is as a result of still using Yabause as it's main core. However, SSF emulator has come on leaps and bounds in recent times. So I was wondering if there was a possibility of switching to that emulator in the future?
Emulator Coder, Site Developer, Site Owner, Expert player
(3576)
Joined: 11/3/2004
Posts: 4754
Location: Tennessee
So, good things have been happening in the world of BizHawk and some big changes are coming down the pipeline.
In the near future (maybe some weeks, maybe some months), we will be releasing BizHawk 2.0!
With 2.0 comes a paradigm shift of sorts when it comes to ported cores. We have a new technique that we call "waterbox" that solves a lot of problems with savestate reliability and ease of porting cores (basically we wrap the core and savestate a snapshot of it, thereby ensuring near flawless sync stating and without any need to port exising (bad) savestate logic from the ported core)
With the 2.0 release we are looking at some big improvements:
* SegaCD and Genesis - Sync stability (mostly sega cd was unreliable but there are existing issues with Genesis as well
* SNES - bsnes Sync stability without a huge speed hit
* 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
* Saturn - yabause is out, and mednafen's saturn core is in (another example of the power of waterboxing, native mednafen saturn doesn't have savestates yet)
* NeoGeo core ported from mednafen (with reliable savestates, unlike the problems that have plauged mednafen-rr)
* Virtualboy core ported from mednafen
With these great improvements comes some cost however. With BizHawk 2.0 we will not longer be supporting Windows XP or Vista, and Bizhawk will be 64bit ONLY. Also, we've upgraded to .NET 4.6.1. Users will need to run the new prereq installer most likely. This was necessary in order to get the waterbox technique working, and performant.
I recognize there are still some users on Windows XP (Not so much Vista). In order to help ease the transition, we plan to do a dual release of BizHawk 1.13.1 and BizHawk 2.0 on the same day. 1.13.1 will NOT have all the new features outlined above but will still have some general fixes and improvements to existing cores. After that, maintenance releases of Bizhawk 1.x will continue for some time as long as it is practical. However, it is unlikely that 1.x will have any new cores in its future.
Joined: 4/17/2010
Posts: 11495
Location: Lake Chargoggagoggmanchauggagoggchaubunagungamaugg
You forgot updated GlideN64.
And there's some work on recent mame too, which will hopefully make it to 1.x branch.
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.
Joined: 10/12/2011
Posts: 6449
Location: The land down under.
As an encoder. I request just one thing.
Splitting the screens for dumping.
Or even if it's easier for you guys (which will require me to double check some things):
Disables Comments and Ratings for the YouTube account.Something better for yourself and also others.
It is already possible in the alpha - set your Three Dee mode to "Side by Side" in the Virtual Boy preferences (haven't figured out how to get anaglyph colors in side-by-side yet). It dumps based on your Three Dee mode setting (in Virtual Boy > Preferences), see the below videos.
Link to videoLink to video
Joined: 4/17/2010
Posts: 11495
Location: Lake Chargoggagoggmanchauggagoggchaubunagungamaugg
Both were removed already.
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.
libsnes: Cleanup some dead code. Apparently the codebase contained a …
…primitive attempt to implement savestates, but it contained significant bugs and had no use beyond toy projects.
Can anyone please let me know what this is about?
I know it's just common programmer behavior to hyperbolize comments about others' code, but I was genuinely surprised to hear my method disparaged to this extent.
I'm not looking to stir up any trouble, but I am interested in learning about what problems my method has, because I'm still using it.
In the ten years higan/bsnes has supported save states, I've yet to hear of them ever once failing to restore a saved state for anyone. (With the only exception being that until recently, SA-1 games using WAI weren't supported.)
Joined: 3/31/2010
Posts: 1466
Location: Not playing Puyo Tetris
Is the NeoGeo Pocket Color Emulation really that good now a days? Because, I remember Card Fighters Clash having graphical issues and timing errors (Too fast Vs. Physical Device).
But, I look forward to seeing it happen all the same.
When TAS does Quake 1, SDA will declare war.
The Prince doth arrive he doth please.
I recognize there are still some users on Windows XP (Not so much Vista). In order to help ease the transition, we plan to do a dual release of BizHawk 1.13.1 and BizHawk 2.0 on the same day. 1.13.1 will NOT have all the new features outlined above but will still have some general fixes and improvements to existing cores. After that, maintenance releases of Bizhawk 1.x will continue for some time as long as it is practical. However, it is unlikely that 1.x will have any new cores in its future.
Now I'm legit curious how many people use what OS for their daily tasks for this site. I'm thinking maybe a strawpoll to roughly check, but I'm not sure how it would work for those who uses VMs or multiple OSes.
Joined: 4/17/2010
Posts: 11495
Location: Lake Chargoggagoggmanchauggagoggchaubunagungamaugg
I was thinking about a poll as well.
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.
Is the NeoGeo Pocket Color Emulation really that good now a days? Because, I remember Card Fighters Clash having graphical issues and timing errors (Too fast Vs. Physical Device).
But, I look forward to seeing it happen all the same.
It's not an overly accurate core. The savestate determinism should be much better than before.
RunToSave has never worked correctly over the entire life of bsnes. This was well known when the first bsnes movie was accepted to this site; if you pounded the savestate button a few dozen times at the beginning, the run would desync. Byuu has been presented facts about this a number of times and has flopped between viewpoints as needed, including denying the bugs, blaming them on the installation, and downplaying them as not significant for most users.
The best example I can think of is Tales of Phantasia. It uses a uniquely difficult sound engine that crashes the emulated game and in some cases even the emulator when you savestate too many times. This is 100% repeatable on any Bizhawk build of the appropriate version: Turn on 1frame rewind, load the game, and watch the attract always crash on the exact same frame <6000 frames in (the exact number escapes me now...). I fixed the emulator crash https://github.com/TASVideos/BizHawk/commit/451f786660744835be868c7fca91ef3fc33db687 but the game still crashed; then I fixed the game crash https://github.com/TASVideos/BizHawk/commit/587270cad2ec96eaeec0ae60e4247c31a0a06a2e (note: there are two commits before it that are also relevant; see end). The exact problem was completely plain under a debugger, and once the fix was implemented it never happened again in Bizhawk, but according to Byuu that couldn't possibly have been it because the game works in Snes9x, which is much less accurate!
Some other things are heavily broken too, all with the same MO: The game will work fine with no savestates, but the moment you start savestating every frame, things break. Super Game Boy, audio on some Rare games; Sonia knows more if you're interseted http://tasvideos.org/forum/viewtopic.php?t=19031
Besides complete breakage, there's also a lot of desync potential where a game will continue to run but handle timing subtlety differently. I believe Ilari has mitigated this by a combination of ignoring savestate requests at certain times and only taking savestates at known "good" times that happen to work out better, but I'm not sure; he's not the most cooperative and his code is impenetrable. Those solutions would be more duct tape and pray anyway; you still don't have something that is taking correct savestates.
End: Here are all of the commits that I ripped out of bizhawk that were related to our coreside fixes for libco savestate problems:
a60be7d2c9818229a0dcff0dbccf15f31015ca2a
a7b6a9af4d4c049dbcd775f05f8539f86456e5e9
57b1df8487e3102b2e81c75fb96640cb1da430a4
9119e4f4ea7661b555125f8d6023efda8f6ed704
b2c0910376657208acb325953fbb2dbd4957d5e1
587270cad2ec96eaeec0ae60e4247c31a0a06a2e
74c26d9b117d3bdc78f5e5247909c9a05dee2a98
5e3d6555b02b1d6a6b61d8aeb3617e256697cd01
451f786660744835be868c7fca91ef3fc33db687
There might be more of them, and I know there are frontend commits as well, and many other issues that we just didn't solve.