Just an fyi, Windows Defender is being a pain at the moment and picking the prereq installer up as malware. If it were some random AV it'd be eh but it's Defender so someone might actually want to deal with it.
I’m not seeing how that would work. Any frame can be the first one. The system doesn’t track which cheats are new and need to be applied for the first time.
Yep that's where my issue is. I'm thinking in the context of my use case where you're always applying cheats at the same time you load a state and was completely ignoring the fact that applying them on the fly would cause it to fall apart.
Well my point was for the very first frame you'd do the double poke but for any future frames you wouldn't. I'd assume you'd want post-frame poke for tool purposes, not pre-frame?
Well my point is:
Frame 0
Original value - 00
Poke - FF
Advance - 00
Poke - FF
Frame 1
Current value (since it was poked at the end of the last frame) - FF
Advance - 00
Poke - FF
Repeat.
I don't see why it's needed to poke before any frame except the very first frame. In all other cases, the poke from the end of the previous frame would still persist, would it not?
The only exception I can see is if a lua script goes and writes over the value after the previous step but before the next step and that seems like a user issue
I'm well aware cheat support in Bizhawk is shoddy at best, but I recently came across an oddness in the implementation that seemed like it was introducing overhead which I couldn't quite see a reason for. Within the main emulation step loop, Global.CheatList.Pulse() is called twice.
Before the frame advance
and
After the frame advance
This seems to me like it's introducing unnecessary overhead, but I may be missing the reasoning for it being called twice under all circumstances.
Obviously, it needs to apply before frame 0. That means you need to set the value before the first frame advance. You then need to constantly set the value before the next frame advance as well.
Applying twice solves this problem. You set the value before the first frame advance, step, then write the value back. Anything that needs to check the value after the step still gets the correct value as it was written back.
At that point though, applying pre-step seems pointless outside of the very first step.
I personally can't come up with any cases where the value would have changed between frame end and the start of the next frame (outside of a lua script overwriting the value in either the frameend or the next framestart event). Framestart is currently called after the initial cheat pulse anyways so that can already overwrite the value.
I get the reasoning for having the tools update before and after every step, but why pulse cheats twice (outside of the first step)? Am I missing something, is it done that way for consistency sake (since everything else is called before and after a step), or is it just an issue in the implementation?
Been a little while since a new release... I'm hopeful for an N64 core update :)
Are there any N64 emulators still in development, anyway? It seems like N64 gets the least amount of love v__v
mupen64plus has actually seen a lot of activity lately. Microcode emulation for some of the later N64 games was greatly improved not too long ago. This doesn't fix mupen's underlying accuracy flaws, but playability is certainly still improving. Also CEN64 still sees commits, but activity on it has waned.
Most every core in Bizhawk needs updating, both in house and external. I'm not sure there is any particular time frame to do it, and it's not tied to a release schedule. Just keep an eye out I guess.
I also saw this pop up recently. Brand new N64 emulator written in C#.
I have my doubts if it's going to go anywhere but it'd be interesting to see if it did https://github.com/Ryu64Emulator/Ryu64
On the note of updating Mupen, when I looked into porting the update before, a huge amount of the patches listed in that big document just downright didn't apply due to refactoring and rewrites.
I made a proof of concept Bizhawk integration a long time ago. It played games with working video, audio, and basic input, but there was a lot of work left to do. I chose not to pursue it further at the time because PPSSPP was under very active development and I felt it would be better to wait for them to resolve a lot of their own stuff first.
There's been no work since then. If you really want to see PPSSPPBizhawk, you'd be better off starting with a version of Bizhawk that actually had it, but there's really nothing to see; it's just PPSSPP but with a lot of stuff not working. Most notably, there was no attempt at savestates, so there is no TASabilty.
I get your point. However, BizHawk has savestate capabilities, and the sound stuff has been fixed. Where can I find PPSSPPBizhawk.dll?
That's not how Savestates work for managed cores in Bizhawk. Cores either need to implement their own savestate and then Bizhawk wraps them, or they need to be made waterbox cores.
Getting into the code, there have been a loooot of changes to Mupen that completely break many of these patches. Most of the files patched don't even exist in the same form due to massive refactoring and complete re-writes. This might be a bit much for what I was looking to do.
I'd be willing to take a stab at it if it's really just a matter of re-applying previously written code to rig it back up and then working out the quirks. I assumed there were larger underlying issues with updating it which is why it'd never been done. I already have a build environment for the core configured as I built the RSP update a few months back.
Is the list of commits posted anywhere (or could you get it), or am I going to have to dig through the git history?
Oh wow! Please ask zeromus, he said he had the list. If taken in its entirety, most of the commits were to Jabo, which is now dead, so it must be quite doable. You're comfortable with submodules?
I don't have a huge amount of experience with them, but it's not a massive hassle. I'd be doing the development on a fork anyways so if it got annoying, I could just do it in the fork directly and then turn it into a submodule once it's "working".
I'll hit up the IRC for the list and take a look. Can't guarantee results if a bunch of stuff comes up that's out of my skill level (I'm primarily a C# dev but I've done some C++ here and there), but I've been wanting N64 updated for a while now and if it really is primarily a time investment, I'll take a stab at it.
Everyone knows it needs to be done, and no one has the time.
For the reference, the proper approach is making it a submodule, and porting over our changes within a fork, so we could in future update the core on a whim. zeromus has the commits that need to be reapplied, it just takes someone with the time (and basic skills).
I'd be willing to take a stab at it if it's really just a matter of re-applying previously written code to rig it back up and then working out the quirks. I assumed there were larger underlying issues with updating it which is why it'd never been done. I already have a build environment for the core configured as I built the RSP update a few months back.
Is the list of commits posted anywhere (or could you get it), or am I going to have to dig through the git history?
2.2.2
Game Genie codes still don't work for Genesis 'cause I want to use the Tails follows Knuckles code for Sonic 3 & Knuckles for testing purposes.
If the game genie code affects the rom file within the system bus (most likely does), it wont work as that memory is read only.
See this issue:
https://github.com/TASVideos/BizHawk/issues/1188#issuecomment-388483894
You can make them work if you override the read-only on the rom domain and port the code to use that domain rather than the bus but otherwise there isn't much you can do besides use a 1.x build.
Bizhawk only officially supports Windows. If you'd like to use it on a Mac, your best bet would be to either use bootcamp or some form of VM to run it in a Windows environment.
Wow... all that work I did talking about that too. He reverted the single change that didn't make the audio sound like it was coming out of a tin can and made all the bass notes higher and...?
I officially give up on that emulator then.
I reverted that change *on that branch only* because it was needed to fix part of another commit, which tons of people complained caused popping on Game Boy audio. That single commit is only needed because of the other commit, which was reverted at the same time.
But by all means jump to conclusions about what any of this does.
Whoops. I made a mistake in my original post. I both linked to the wrong commit (I linked to the GB instead of the GBA one), and misread what was reverted. My mistake there.
This doesn't matter any more anyways since 0.6.3 stable has been posted
Despite showing up and showing the domain when in action, the code data logger doesn't appear to work with NESHawk. Is this a bug or was it just not fully implemented? Seems like it should be working with NESHawk of all cores.
It only shows the "RAM" domain and despite causing the game to lag up (it's clearly doing something) it's not populating that domain.
On another note, does C64Hawk support the T64 format? It's not part of the filter when loading roms, but the core recognizes T64 files as valid files. I can't get it to run any games so I'm guessing it doesn't work? When loading a T64 file, the C64 RAM is populated, but RUN doesn't launch the game.
Edit: Looking at the code it looks like the framework is there for T64 files but it doesn't actually know how to handle them. Any plans to support T64 in the future?
I have no plans to do it myself. Probably it would only get done if SaxxonPike returns. Feel free to give it a go if you are interested.
I have absolutely zero experience in emulator development so even if I did make it work, it probably wouldn't be pretty. I may take a look though assuming I can find some good references. I have a metric ton of C64 games in T64 format rather than TAP.
Sameboy runs the SGB at the SGB1 clock speed, whereas BSNES runs the SGB at the original clock speed. Is BSNES emulating the SGB2?
I don't think it is. SGB in BizHawk needs some work in general.
Thanks.
On another note, does C64Hawk support the T64 format? It's not part of the filter when loading roms, but the core recognizes T64 files as valid files. I can't get it to run any games so I'm guessing it doesn't work? When loading a T64 file, the C64 RAM is populated, but RUN doesn't launch the game.
Edit: Looking at the code it looks like the framework is there for T64 files but it doesn't actually know how to handle them. Any plans to support T64 in the future?
The version of Mupen64Plus in Bizhawk is fairly outdated. If this is just a casual playthrough (that's what it sounds like?), I'd suggest just grabbing the saveram file from your Bizhawk directory (bizhawk/n64/saveram) and playing in a recent version of Project64 with GlideN64 as your graphics plugin.
Might want to build PJ64 from source since it looks like there hasn't been a stable release in over a year though.
I used to do to tas tests in Mario Kart 64 in 1.11.5 and it works well, except for the slowdowns when savestates are set(fixed in 1.12.1, but the gameplay still works better in 1.11.5).
But Mario Kart 64 runs terribly slow (in 100% speed) in the 2.2.1 version. Is possible to some developer to fix ONLY this QuickSave issue in 1.11.5 but keeping the rest exactly like 1.11.5 works for default? Or maybe fix this 2.2.1 slowdown issue in next Bizhawk update?
In 1.11.5, does it run at around the same speed if you change the CPU mode to "interpreter" from "dynarec" and you swap the graphics plugin to one that's available in both (just use Rice or something maybe)?
Jabo is the fastest of the video plugins by far so you lose a good chunk of performance with the loss of that, and you also lose a good chunk of performance with the loss of the dynarec.
The audio and frame difference issues are due to gambatte using 'use equal length frames' by default.
The Gameboy can have 'frames' (time bewteen VBLanks) that are arbitrarily long since it's not locked to a video standard like normal consoles. When these types of frames happen, typically during loading, BizHawk doesn't know how much longer a frame was then a normal frame, so it just plays the audio like it was 1 normal frame, cutting off notes and speeding things up.
Typically for TASing though you want frames that always start / end on VBlank since that leads to consistent input timing.
So, it's a trade off. Right now GBHawk only has VBlank based frames for ease of testing, so those issues won't be immediately fixed. It kind of sucks, but BizHawk doesn't have a good way to deal with it that I know of.
All right well that answers that.
That just leaves the Jeopardy sound issue, the HAL Wrestling sprite corruption, and the Kirby's Dream Land title screen drawing early with corrupted graphics.
Making this a second post as there was an error and I want to make sure you realize I edited it in case you saw the original. My original testing didn't have Gambatte push start on the first possible frame which changed the timing.
Some games speed up during full screen transitions. It's very clear when audio plays through the transition
Examples:
Kirby's Dream Land: https://streamable.com/nir2t
Barbie Game Girl https://streamable.com/9v15h
It seems to be linked to lag frames. Doing a quick test shows the audio issue occurs during the lag frames
https://streamable.com/yrwfw
To add to that, there's actually a significant difference in frame count if you include the lag frames which is probably leading to this issue?
Pictures of TAStudio (Both press start on the first possible frame)
Gambatte: https://narry.land/iujteu.png
GBHawk: https://narry.land/UB3hwG.png
The movies: https://narry.land/Movies.zip
