Try checking "render to main window" in the Display configuration tab.
While I do like this feature, it doesn't seem to help the hotkey issue I'm having.
I'll just mention that while I was fiddling around with Dolphin for fun, I had the exact same hotkey problem as yourself - the pause and frame advance button would stop working after a while, and then refused to work until a few minutes later.
I just thought I'd say so that you know it's not just yourself having this problem.
I used Dolphin r7588.
Thanks for sharing. It seems like this is a common problem then. I have to think we should not need to use an older version to avoid something that is likely a relatively easy fix. I'm not entirely sure who to contact or where to go to report known bugs, or if anyone cares... but I'll look around, I guess.
Thanks for sharing. It seems like this is a common problem then. I have to think we should not need to use an older version to avoid something that is likely a relatively easy fix. I'm not entirely sure who to contact or where to go to report known bugs, or if anyone cares... but I'll look around, I guess.
I had the same problem in the beginning. I use r7323
When configuring your input, make sure your directions are the numbers at the right of your keyboard, such as 8,5,4 and 6. DO NOT USE up, down, left, right.
My other input are z,x,c,v,a,s for A, B, X, Y and Z. I suggest them, because they work for me.
/////////////////////////////////////////////
I personally tried r7323, v2.0 and v3.0.
v2.0 has the issue that audio can't be dumped, therefore anything done on it has no audio.
v3.0 has sync problem. It's more stable, but at some point it will keep on desynching... weirdly enough.
r7323 has desynch issues, but will tend to be more stable "overall". If a video gets desynched at some point, you can turn back and correct the issue, unlike 3.0 who just keeps on desynch.
My personal recommandation: r7323.
Whenever I load a savestate from my movie in read-only mode (just to fast-forward through my TAS to see if a part synced), it starts recording from the savestate anyway. Is there something I don't know about how Dolphin understands "Read-only Mode"?
This may not be as annoying if I weren't working on a 3-4 hour GC TAS on a computer that runs Dolphin at 12% speed when playing back a recording.
Whenever I load a savestate from my movie in read-only mode (just to fast-forward through my TAS to see if a part synced), it starts recording from the savestate anyway. Is there something I don't know about how Dolphin understands "Read-only Mode"?
This may not be as annoying if I weren't working on a 3-4 hour GC TAS on a computer that runs Dolphin at 12% speed when playing back a recording.
Do you mean it dump frames, or you mean it records your input?
I mean it records my input. I will load a savestate in read-only mode and it will start recording input from that savestate, as if "read-only mode" was turned off!
Do you know how to fix this or have an alternative option for loading savestates in read-only mode?
Whenever I load a savestate from my movie in read-only mode (just to fast-forward through my TAS to see if a part synced), it starts recording from the savestate anyway. Is there something I don't know about how Dolphin understands "Read-only Mode"?
This may not be as annoying if I weren't working on a 3-4 hour GC TAS on a computer that runs Dolphin at 12% speed when playing back a recording.
This happens to me, too. "Read-only" essentially does nothing. Is there an open issue about this?
Yes, but it's been largely ignored. I commented on it recently in an attempt to "bump" it to a higher priority, but to no avail. This was the bane of my MM10 TAS. It would significantly reduce the amount of time it takes to TAS a complete game if I didn't have to watch the recording from the beginning every time.
http://code.google.com/p/dolphin-emu/issues/detail?id=4463&q=%22read%20only%22
I have the same "problem". Even though, dolphin has been my first attempt to TAS, and I thought it was normal, lol. I got used to play back things from the beginning, as shitty as it is.
Yea, same here. Dolphin has been my first experience with TASing as well, and I've adapted to this read-only problem by letting the replay run in another instance of Dolphin while I continue TAS'ing in the other instance. I only pay attention to the replay when it gets the part I'm at.
When I dabbled a little bit at NES TASing with FCUEX, I was amazed at the amount of features specific to improving the quality and efficiency of TASing in particular.
I started TASing with VBA, and while working on my first TAS, it was natural to just stop recording, play the movie, and skip to a savestate to check for desyncs. When I let Dolphin play the movie while I'm doing something else, I usually miss the part I'm looking for and have to start the playback all over again.
It wouldn't even be as bad if I was working on VBA or FCEUX, because those run at normal speed and you can even throttle them. Dolphin, however, runs at 12-14% speed when playing back (on my computer), so what should take 45 seconds takes over 6 minutes. And you can't even throttle it.
When I let Dolphin play the movie while I'm doing something else, I usually miss the part I'm looking for and have to start the playback all over again.
That has happened to me numerous times. When it does, I just play the movie again. It's definitely one of the drawbacks to the method I use, but with no alternatives, it's the best we got we for now.
So "DTM ignored" means they don't even care about our problem? I notice the issue says that happens for versions up to 7506. I assume that was the latest version as of the time of that post, since that still happens on r7573, the one I usually use.
So "DTM ignored" means they don't even care about our problem? I notice the issue says that happens for versions up to 7506. I assume that was the latest version as of the time of that post, since that still happens on r7573, the one I usually use.
DTM ignored is part of the title of the issue and it is explaining that the read-only option when playing .dtm's is ignored. As far as I know, it hasn't worked since it was first introduced. I'm now using r7666 and it is still inoperative.
The later stages of my MM10 run took over an hour for the emulator to get to. So I would record 10-20 seconds of input, and then have to wait for over an hour to see if it synced. This is why a read-only option would make TASing on the Dolphin much more efficient.
I can give you piece of advice, however. While recording, idle skipping must be off to make the emulator deterministic. But while playing back the recording, you can check idle skipping, and it will still sync just fine. This should speed up the playback by about 15fps.
I made another issue. Naturally, it was subsequently closed and merged with the original issue. At least I now know at least one other person now knows about this. Please star issue #4463 to highlights it's importance.
I can work on this. Didn't know about this issue because somebody else implemented the read only option.
What should the exact behavior be when a savestate is made/loaded in read-only mode?
I can work on this. Didn't know about this issue because somebody else implemented the read only option.
What should the exact behavior be when a savestate is made/loaded in read-only mode?
Awesome!
When in read-only mode, saving states should remain the same. But when loading a state, the emulator should load that state, and continue playing back the movie from that point. I'm not sure how it should handle states not part of that movie, but most other emulators have a read-only mode that should provide more information on how it's supposed to work.
I can work on this. Didn't know about this issue because somebody else implemented the read only option.
What should the exact behavior be when a savestate is made/loaded in read-only mode?
Basicly in the LoadInput function of movie.cpp it needs a if/else statement to set the mode to movie_Playing if g_bReadOnly is checked but then you also need to make it continue reading input from the input frame on the dtm...which is where i am stumped so i hope you have better luck then me. Which you probably will.
I can work on this. Didn't know about this issue because somebody else implemented the read only option.
What should the exact behavior be when a savestate is made/loaded in read-only mode?
Great! Could you maybe make a modified r7323 with the fix? I'm switching to that revision since it supposedly has fewest desyncs when recording GC TASes.
I can work on this. Didn't know about this issue because somebody else implemented the read only option.
What should the exact behavior be when a savestate is made/loaded in read-only mode?
Great! Could you maybe make a modified r7323 with the fix? I'm switching to that revision since it supposedly has fewest desyncs when recording GC TASes.
I would much rather find out what revision started causing more desyncs and fixing that than having to backport everything.
Well, the only desync issue I'm aware of is the "backshifting input" problem. You know it occurs when you press A to jump for one frame, then load a state and Mario still jumps. It exists in rev6218 or older ~ v3.0; I don't know why 3.0 is said to be less desync proof, I haven't used it very much yet. Just fix that bug and the world should be better, I think.
E: The issue I'm talking about occurs very often in Mario sunshine, rarely in SSBM, rarely in Mario Party 5 (not at all for me so far). It also occurs when using less deterministic settings.
Those backshifting problems look like polling issues with the input code. If you use the new TAS Input window, you shouldn't get any of those bugs anymore.
While recording, idle skipping must be off to make the emulator deterministic. But while playing back the recording, you can check idle skipping, and it will still sync just fine. This should speed up the playback by about 15fps.
This might work fine for Wii TASes, but I TASed the first 5 minutes of a GameCube game and, playing back the recording with Idle Skipping on, it desynced halfway through. I played it back again with Idle Skipping off and it synced perfectly. I was using r7323 (if it matters), since GC games supposedly desync the least on that revision.
You're doing a great job with this emulator so far. Just a few things that bug me (after a few hours of playing):
1, the hotkey issue is driving me nuts.
2, wish you could put a hotkey on space.
3, wish there was an option to put pause and frame advance on separate buttons.
If you rebind your keys to not use the arrow keys (specifically down and right I believe) that should fix the hotkey issue. As far as I know it's some quirk in Windows/wxwidgets for Windows that makes the game window just lose focus when certain keys are pressed, no matter what. Nobody can seem track down how to fix.
