rog, do you know if there would be anymore significant timing differences in the future? Also, what do you mean by speed difference? Speed as in how fast the game runs in a computer, or ingame timing difference?
I'd have to consult my crystal ball on that one. There's no way to predict how or when changes will be made that affect timing, unless of course you are the one making those changes. Prior to 3.0-365, movies would sync going back more than a thousand revisions. Take that how you will.
I meant speed as in emulation speed, not game speed.
So, i started working on tasing zelda TP using 3.0-470 (the one i posted before), and got a desync. After moving to a new area, i pulled out my sword right away before rolling, so i could do a jumpslash later. When i played it back, link simply rolled away, without drawing his sword. So i went back, and redid that part. I then played it back, and it desynced exactly the same way.
Interestingly enough though, both movies played back perfectly in 381 tas-input. I cannot even imagine what would cause it to not playback on the revision i recorded it with, but work fine on a completely different revision. Anyone tasing with the revision i posted before, do be aware there may (or maybe not) be issues with it.
In 3.0-381 (tas input) 32bit, with the recommended settings, when I save a state in Zelda Wind Waker any game the framerate drops down to 1 FPS for the remainder of the emulation session. I suppose it only happens when cheats are enabled.
So, i started working on tasing zelda TP using 3.0-470 (the one i posted before), and got a desync. After moving to a new area, i pulled out my sword right away before rolling, so i could do a jumpslash later. When i played it back, link simply rolled away, without drawing his sword. So i went back, and redid that part. I then played it back, and it desynced exactly the same way.
Interestingly enough though, both movies played back perfectly in 381 tas-input. I cannot even imagine what would cause it to not playback on the revision i recorded it with, but work fine on a completely different revision. Anyone tasing with the revision i posted before, do be aware there may (or maybe not) be issues with it.
If anyone cares, i tried it again, and it syncs fine now on 470. No idea why it desynced before, but definitely glad, since there's a fix in it for TP that would have been extremely annoying to do without.
In official 3.0-425 32bit, it seems the 'input shift' desync bug still exists in Zelda Wind Waker. I press Y, then load a state, and Link pulls out the wind waker.
I was using the master build only due to the action replay problem I mentioned in my previous post. It's good to hear this bug is fixed in the TAS builds. I still gotta try the latest one posted in this thread..
EDIT: It might just be the official build again, but I noticed in Zelda Wind Waker, saving a state changes the pause screen background and the cam angle (when unpausing, for 1 frame) - just like the goop issues in Mario sunshine...
There's a few bug fixes here, and quick testing of performance (4 minutes of running my muramasa tas), it seems to be ~8% faster than the 470 build i posted a week ago.
I think I more prefer the 600% increase I get when running Dolphin in Debug mode.
I think I more prefer the 600% increase I get when running Dolphin in Debug mode.
Can you TAS in this mode? Or is it just for debugging purposes?
Also, the comments on the newest "master" branch revision say that the old master revisions were "broken" and they prefer this more accurate, "slower" revision. But isn't the new version rog just compiled accurate, or were those coders specifically talking about the emulation of the game it fixes?
Yes, you can tas with debug mode.
CoolKirby wrote:
Also, the comments on the newest "master" branch revision say that the old master revisions were "broken" and they prefer this more accurate, "slower" revision. But isn't the new version rog just compiled accurate, or were those coders specifically talking about the emulation of the game it fixes?
The revision is a workaround to avoid fixing the actual problem, which only affects one game. Instead of fixing the JIT, Parlane decided to just switch to interpreter, which is more accurate, but 30x slower. Accuracy is nice and all, but using an interpreter for wii/gc emulation is dumb.
Joined: 3/2/2010
Posts: 2178
Location: A little to the left of nowhere (Sweden)
rog wrote:
CoolKirby wrote:
Also, the comments on the newest "master" branch revision say that the old master revisions were "broken" and they prefer this more accurate, "slower" revision. But isn't the new version rog just compiled accurate, or were those coders specifically talking about the emulation of the game it fixes?
The revision is a workaround to avoid fixing the actual problem, which only affects one game. Instead of fixing the JIT, Parlane decided to just switch to interpreter, which is more accurate, but 30x slower. Accuracy is nice and all, but using an interpreter for wii/gc emulation is dumb.
He does not know how to fix it, so he disabled it in JIT, just that one opcode, he did not disable all of the JIT.
and all, but using an interpreter for wii/gc emulation is dumb.
He does not know how to fix it, so he disabled it in JIT, just that one opcode, he did not disable all of the JIT.[/quote]And that still seems pretty dumb :(
Joined: 3/2/2010
Posts: 2178
Location: A little to the left of nowhere (Sweden)
rog wrote:
Warepire wrote:
and all, but using an interpreter for wii/gc emulation is dumb.
He does not know how to fix it, so he disabled it in JIT, just that one opcode, he did not disable all of the JIT.
And that still seems pretty dumb :([/quote]
Better to have something work correctly albeit a tad slower than working incorrectly, just because PokePark really shows the opcode is not working it may affect other games in a way that you normally don't notice but is still a faulty behavior.
Examples of things I have seen being wrong from bad opcode implementations but didn't really break the game:
RNG values - Things got rarer / more common
Movement speed - Character moving a tad faster / slower
Hitboxes
So I do not think it's dumb at all to make sure the opcode works correctly even if it costs speed, it could fix more games than you think, even though in 99% of the cases it is not visible to the human eye. And just because he doesn't know how to fix it in JIT doesn't mean it will never be fixed.
So once we start using that revision for TASing, someone could obsolete my TAS with a movie where a different RNG removes the need for wasting frames and the character moves a little faster?
So once we start using that revision for TASing, someone could obsolete my TAS with a movie where a different RNG removes the need for wasting frames and the character moves a little faster?
He was making up examples of possible side effects that wouldn't be noticed.
Joined: 3/2/2010
Posts: 2178
Location: A little to the left of nowhere (Sweden)
CoolKirby wrote:
So once we start using that revision for TASing, someone could obsolete my TAS with a movie where a different RNG removes the need for wasting frames and the character moves a little faster?
I have no idea what exactly that opcode does, I am not a GC/Wii emulation developer nor do I know anything about the systems. Those were just examples of things broken opcodes can cause. I was mainly trying to explain to rog that the opcode that was changed may have affected more games than just PokePark.
So that build keeps the emulation speed of the pre-PokéPark fix revisions as well as the fix itself? And it still doesn't include the more-save-fixes or TAS-input changes, right?
So that build keeps the emulation speed of the pre-PokéPark fix revisions as well as the fix itself? And it still doesn't include the more-save-fixes or TAS-input changes, right?
It is about the same speed as the last build (479) i posted (slightly faster actually), and includes a few more bug fixes. It does include the tas-input branch. All revisions in master up to the one i linked, as well as the more-save-fixes/tas-input branches are included in this build (and all future builds i'll post here).
So this latest official build is the recommended revision now?
Well, with that and the encoding breakthroughs, it looks like I'll probably have to switch my movie to this revision anyway.
So this latest official build is the recommended revision now?
Unless it breaks something in your game, i'd definitely recommend it, yes. The more-save-fixes branch is just getting way too far behind.
Well, with that and the encoding breakthroughs
That should work with any revision. It only takes a few minutes to apply the patch and compile. But again, i'd highly recommend upgrading if you can easily do so. The newer revisions are not only much faster, but also less buggy.
Unless it breaks something in your game, i'd definitely recommend it, yes. The more-save-fixes branch is just getting way too far behind.
...
But again, i'd highly recommend upgrading if you can easily do so. The newer revisions are not only much faster, but also less buggy.
All right, you've convinced me to change to this revision. Thank you in advance. Every time so far you've convinced me to start using a new revision, I find I really need the new features and accurate/fast emulation of the revision you suggest.
