Might only be me (so if anyone else is TASing lemme know if it happens to you guys).
Have Frame Counter Set to ON.
Make a input recording, play it back with pause at the end of movie and read-only off, start frame advance from there.
It seems the frame counter OSD resets from the end of movie. if you continue TASing it seems to all play through but even after replaying the video, the frame counter will only start from the point where you previously started TASing.
Another issue is there is a cutscene in the game I am trying to tas and as soon as the it triggers, you can no longer frame advance through it. it just continues on playing (making you miss several frames to input), as well as the frame counter not including those frames from the cutscene in its counter
edit: Here's a video from OBS to capture the OSD, DTM file states 2570 frames, dolphin shows 1202. Doesn't start frame counter until about 550ish. Lots of skipped frames on the counter from the cutscene you hear but don't see.
Link to video
I got a strange bug. I make a movie file. At my last input, when I play and recording, the game work well I want. But when I playback my movie file from begin, it haven't same result I want. Tried remake my last input with same frame alot time, still get this bug
Here, my last input
Here's result what I want
Here's result when I playback movie file from begin
well well I think I found the reason
At the end of movie file, it'll make game get a little laggy, change a little timer in game. With any game have RNG depend timer then it'll affect to result
For temp fix for this problem, I just need make the end of movie a bit longer
lua in dolphin would be good! we still have ce tho!
Current:
Rayman 3 maybe? idk xD
Paused:
N64 Rayman 2 (with Funnyhair)
GBA SMA 4 : E Reader (With TehSeven)
TASVideos is like a quicksand, you get in, but you cannot quit the sand
lua in dolphin would be good! we still have ce tho!
yeah but CE leaves us with extra address that are not from the game but from the application (if I'm not mistaken). Plus having something internal may make it easier to find values and therefore LUA would be an even better feature.
OT: why are you never on IRC anymore lol
The memory leak fix that's mentioned in the previous post has been merged and is included in 4.0-8735 and newer. Unfortunately, using 4.0-5400 or older is still necessary for avoiding the bug that makes frame advance unpause randomly.
The memory leak fix that's mentioned in the previous post has been merged and is included in 4.0-8735 and newer. Unfortunately, using 4.0-5400 or older is still necessary for avoiding the bug that makes frame advance unpause randomly.
I found that the weird frame advance behavior does have a temporary solution. If you pause and then load a savestate, press the frame advance 3 or 4 times very slowly, like once every second, and then after hold the button down for a few seconds. After that, it should behave normally. Kind of a pain yeah, but the unpausing thing doesn't come back for quite a while, at least for me.
The memory leak fix that's mentioned in the previous post has been merged and is included in 4.0-8735 and newer. Unfortunately, using 4.0-5400 or older is still necessary for avoiding the bug that makes frame advance unpause randomly.
I found that the weird frame advance behavior does have a temporary solution. If you pause and then load a savestate, press the frame advance 3 or 4 times very slowly, like once every second, and then after hold the button down for a few seconds. After that, it should behave normally. Kind of a pain yeah, but the unpausing thing doesn't come back for quite a while, at least for me.
I usually just refresh the last savestate and it usually fixes after a few tries.
Figured I should briefly mention my Zelda Edition fork (https://github.com/dragonbane0/dolphin) here since a few people referred to it and it became the de-facto build to TAS Wind Waker, Twilight Princess and FSA and is used for all WiP TASes of those games afaik. It mainly adds a few comfort functions for TASing with the intention of making stuff more straightforward, fixes a few annoying issues and generally tries to keep up with useful improvements to the core that don't impede TASing stability (e.g. the memory leak fix).
The newest official releases sadly seem to be broken for TASing of a few games. Namely Wind Waker consistently desyncs within mere minutes of recording even if you use optimal settings. So I wasnt able to merge my build with a recent master yet and its still based of 5371, which is relatively old now. But at least its very stable for TASing and already includes the near console accurate loading emulation.
I'm hoping to polish up some of the things I added (it would need a lot of polish) to eventually bring them into the master or help with existing implementations. Some of the stuff I added:
-Display Memory Values directly on the OSD
-Basic emulation of a fake tuner to help with TWW TASing (so it can do the most optimal any% route)
-Helper UI that allows to splice DTMs together
-Use DTMs to create a video comparison inside Dolphin (including a timer) without having to own expensive video editing software
-Some comfort functions entirely exclusive to TP and TWW
-Basic LUA support for every game including auto starting scripts and launching scripts on command. The feature set isnt too great yet, but you can do the basic stuff (manipulate memory, save/load states, make inputs, do maths etc.)
A compiled version to play around with can be found here: http://www.mediafire.com/download/51lh1xefu3rg3q2/Dolphin_ZeldaEdition6.0.zip
I haven't checked it out much yet, but it seems like an interesting fork. Contributing the improvements to master would be appreciated if you want to do it, though there are a few ones like the fake Tingle Tuner that I don't think would fit.
I haven't checked it out much yet, but it seems like an interesting fork. Contributing the improvements to master would be appreciated if you want to do it, though there are a few ones like the fake Tingle Tuner that I don't think would fit.
Adding on to this, if you're interested, feel free to hang out in #dolphin-dev on freenode.
The newest official releases sadly seem to be broken for TASing of a few games. Namely Wind Waker consistently desyncs within mere minutes of recording even if you use optimal settings. So I wasnt able to merge my build with a recent master yet and its still based of 5371, which is relatively old now. But at least its very stable for TASing and already includes the near console accurate loading emulation.
Huh. Wonder what happened to cause that?
dragonbane wrote:
I'm hoping to polish up some of the things I added (it would need a lot of polish) to eventually bring them into the master or help with existing implementations. Some of the stuff I added:
-Display Memory Values directly on the OSD
-Basic emulation of a fake tuner to help with TWW TASing (so it can do the most optimal any% route)
-Helper UI that allows to splice DTMs together
-Use DTMs to create a video comparison inside Dolphin (including a timer) without having to own expensive video editing software
-Some comfort functions entirely exclusive to TP and TWW
-Basic LUA support for every game including auto starting scripts and launching scripts on command. The feature set isnt too great yet, but you can do the basic stuff (manipulate memory, save/load states, make inputs, do maths etc.)
A compiled version to play around with can be found here: http://www.mediafire.com/download/51lh1xefu3rg3q2/Dolphin_ZeldaEdition6.0.zip
The memory watch, dtm splicing UI, dtm compare, and lua functions sound amazing to have on the main branch. I hope at least those can be implemented so, since it's helpful for other games as well. :o
The newest official releases sadly seem to be broken for TASing of a few games. Namely Wind Waker consistently desyncs within mere minutes of recording even if you use optimal settings. So I wasnt able to merge my build with a recent master yet and its still based of 5371, which is relatively old now. But at least its very stable for TASing and already includes the near console accurate loading emulation.
Huh. Wonder what happened to cause that?
It's likely because some data isn't being saved to savestates. If that's the case, tracking down which version the desyncs started in should make finding the issue in the code relatively easy. There's always the possibility it's something else, though...
If you guys are having problems with savestates having desyncs, we're relying on you to report it so it can be fixed! If it only takes minutes (which, isn't TOO bad, but still kind of rough) a bisect shouldn't take more than an hour.
The memory leak fix that's mentioned in the previous post has been merged and is included in 4.0-8735 and newer. Unfortunately, using 4.0-5400 or older is still necessary for avoiding the bug that makes frame advance unpause randomly.
I found that the weird frame advance behavior does have a temporary solution. If you pause and then load a savestate, press the frame advance 3 or 4 times very slowly, like once every second, and then after hold the button down for a few seconds. After that, it should behave normally. Kind of a pain yeah, but the unpausing thing doesn't come back for quite a while, at least for me.
Thank you, Fog! I look forward to fixed frame advance in the Dolphin 5.0 Release.
PR 3712 is not a proper fix, it just exchanges the frame advance problem with an older problem that's less noticeable. Whether it will be in 5.0 remains to be seen.
Thank you, Fog! I look forward to fixed frame advance in the Dolphin 5.0 Release.
PR 3712 is not a proper fix, it just exchanges the frame advance problem with an older problem that's less noticeable. Whether it will be in 5.0 remains to be seen.
Didn't Fog update it about 3 weeks ago to say the original was not a race fix? And then it was added to the 5.0 release milestone? I could be misunderstanding the PR 3712 page, or what the milestone means.
Didn't Fog update it about 3 weeks ago to say the original was not a race fix?
It was a race fix – it's just that it made another issue show up too. In that sense, I suppose it's a bit like the change this PR makes. Maybe that's enough to not consider the original change to be better than reverting it, or maybe not.
CoolKirby wrote:
And then it was added to the 5.0 release milestone? I could be misunderstanding the PR 3712 page, or what the milestone means.
Something being marked with the 5.0 milestone means that it needs to get taken care of before 5.0. While most PRs that are marked with it do get merged before 5.0, it's not guaranteed. As far as I know, the main point of milestone tags is to keep track of important issues, not to approve a specific PR. If the PR already had been approved, it could've gotten merged already.
Is it possible to do TASes with the gamecube bios? (i.e. games like Pokemon Channel)
I don't see any reason why running the BIOS in a TAS wouldn't work. Just make sure that everyone who plays the input file has the same BIOS as the one that was used for recording. For accuracy when running the BIOS, you should use DSP LLE and Virtual XFB, but that isn't specific to TASing.
As far as I know, making Pokémon Channel work correctly doesn't actually require you to run the BIOS. If you're using Dolphin 4.0-8488 or newer, loading the proper font only requires the BIOS to be present. It's possible that the requirements on having the same BIOS version when playing the input file are more lenient for this, but I'm not sure at all.
Here's result what I want
Here's result when I playback movie file from begin
