... I'm not sure if you're saying this regarding the present, or you're supposing it will never be possible to have a working frame-skip, or if you're unaware that I was talking about it regarding a future revision that has a working frame-skip for Dolphin, that could be used like the one on other emulators.
Because there are working frame-skipping on other emulators, you know that? You can press a button, and then the game goes in fast-forward mode, by skipping frames. If you let go the button, the game goes in normal speed. There is no such thing as "movie won't sync, unless it was recorded with frame skip" on other emulators.
Correct me if I'm wrong, but isn't that just turning off the frame limiter? It still "renders" each frame in memory, but it doesn't delay the output to match the correct framerate. The problem with Dolphin is that its frameskip actually skips the rendering of some frames, which can have effects on playback.
From what I can see, the only change to read-only mode is to remove the warning about recording in read-only mode and force it on if you try to start recording a movie.
I think the framestep fix might help a little with inputs from previous frames effecting the current frame. The issue with input in Dolphin is that it isn't polled at any specific time (like on frame draw), it's put on a timer that the emulated CPU polls every so often. When in recording/playback mode, that timer is forced to be once every frame, but the timing of the poll may still be off. It would be easy to fix this by forcing a poll on frame draw, but doing that would make the timing different from the current method, and possibly break movies already made/being made.
Wiimote recording is something different altogether and is just a recording of the USB stream from the Bluetooth receiver. That wasn't implemented by me and even though the USB stream is easy to decode, it does not match up frame-for-frame, because it sends its signal at 150 Hz regardless of framerate IIRC.
Can somebody here post exactly how read-only mode should work? Trying to implement it on only a vague idea of what it should do seemed to only cause problems for everyone, but when I get some free time after my finals, I would like to take a stab at fixing the behavior, but I first need to know what the "correct" behavior is.
Is lua going to be implemented in Dolphin or is it already and I'm just missing where it is?
It was removed a long time ago because nobody was actively working on it. It can pretty easily be reimplemented. All you need to do is find the revision which removed it and pull it back in into dolphin.
It won't be that easy. It was also removed because it was broken and nobody could (or wanted to) fix it.
Does anyone know why Dolphin page looks like this: http://code.google.com/p/dolphin-emu/source/list It used to list chronologically order the revisions, but now I don't understand much why it looks like that.
Looks like they upgraded the version control system to Git, which has true merges, so that indentation probably represents branches.
And I agree that it looks pretty bad. I can't even tell from where the side branch starts from as there is no revision graph. And rating being lost is probably related to the migration.
The Google Code UI for git is pretty bad. You should use Git Extensions instead.
hi, i'm on r7714 and i'm getting some minor problems. when there is focus on the TAS input window, frame advance takes 2 presses to advance a frame and you cannot save or load a state. hope this can be fixed.
also a request: a "reset stick" button to set x/y coordinates to 128/128.
Are you using render to main window? That was causing some problems with some of the hotkeys with the TAS window focused.
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.
Is it normal that I can't run Super Mario Galaxy 2 on full speed with this rig?
Core2Quad 8400 @ 2.66ghz
4 gig ram Intel Extreme edition DDR3 1333mghz
ATI Sapphire 5850 1gb
Windows 7 64bit ultimate edition
I lowed everything I can and I play 800x600 and I can't even get 80% speed, is there something wrong?
Thanks :D
Your CPU is just a tad slow. You want higher clock speeds over more cores for emulation.
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.
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.
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 remember sgrunt saying that he sometimes needed to delay the audio a second for some records. But yes, that is a bug we know about. It should be easy to manually fix.
I also forgot to mention; the window doesn't register the "click" part of the shoulder buttons. You have to do that yourself through other controls. This also means you can do some impossible things like clicking a shoulder button with no analog value, or full analog value with no click. While physically impossible on a normal controller, the controller does send separate signals for the click and analog. Might be fun seeing how some games handle that.
It works fine with OpenGL, but I usually don't use that graphics backend because it doesn't render some textures correctly. Is your version okay to use to make a TAS then? Or is the input window not done?
I'm still going to add a couple more things to the window (graphics for the joysticks, tabs for different controllers, and maybe some other things), but if it has the features you need, then it should be safe to use with a TAS.
That sounds like your graphics card doesn't support the newer shaders Dolphin now uses. Not sure why it can still run with my version and not the one on the site. You can try running it with the OpenGL graphics backend and see if that runs okay.
If you go the memory card route, make sure you specify whether it's a empty but formatted memory card or an unformatted one. The two can be handled differently in games.
Because I don't know how long until the 3.0 release will come and I can submit this, here's some binaries + a patch for what I have so far regarding TAS Input.
http://www.mediafire.com/?n5c01ercan302l9
Look under Emulation -> TAS Input. When the window is open, all analog controls are overwritten by the values in the window. It currently does it for all controllers, so you can't do multiplayer input yet.
Also, if you want to compile the patch yourself, you might need to rename OnFrame.cpp and OnFrame.h to Movie.cpp and Movie.h (both files are under Source/Core/Core/Src)
I made this small program a while back that you can use to get all the metadata from .dtm files.
http://www.toadking.com/dtminfo.zip
Just drag and drop a dtm file over it to use it.
To my chagrin, I have some knowledge of how wxwindows works. Feel free to contact me if you need help. There's also mailing lists that are pretty helpful.
Not gonna lie, if I spend a whole weekon this and end up nowhere, I just might do that. :P
What are you envisioning, anyway? I could probably mock something up in Python (which has WX bindings) which you could transfer to whatever Dolphin's written in (presumably C++) without too many changes.
For starting I was thinking of doing something like this:
When the window is open, it uses the analog inputs you set in it. Obviously it could be expanded later for digital buttons/macros, but I really want to get the analog stuff in ASAP.
To my chagrin, I have some knowledge of how wxwindows works. Feel free to contact me if you need help. There's also mailing lists that are pretty helpful.
Not gonna lie, if I spend a whole weekon this and end up nowhere, I just might do that. :P
sonicpacker wrote:
TAS Input would definitely be a big step forward. I also think that TASVideos still needs to assign a specific revision that TASers should use. IMO, newer revisions (in terms of TASing) are losing stability. I don't know what's causing this, but myself and others can attest to it. Anyway, the reason I say that is because I don't believe Dolphin 3.0 should be the "official TAS revision" even though it may seem like a good one to deem worthy. =P
If you can pinpoint which revisions cause the stability issues, that would be great. Even a range of 20 or so revisions during which the stability drops would help.
Good job on completing this!
Just one note though: The rerecord count is wrong due to a bug in earlier versions of Dolphin resetting the rerecord count. This should probably be mentioned in the submission notes somewhere.
Toad King, I'm worried due to sonicpacker's post in the Recommended settings topic.
MUGG, I wouldn't recommend updating to the newest rev. I'd stick with r7318 for now. It has the loading times more accurate than previously. In newer revs, a bit of LLE work has been done and it's causing quite a few desyncs. I tried TASing a shine in SMS and a simple sideflip + dive wouldn't sync after nearly 10 tries. Before that even occured, it had desynced at 3 places prior in the movie...I'll add that it wasn't even that many frames.
r7323 isn't far from r7318 and it has the eject/insert problem fixed. I planned to check out v3.0 once it is released - but most of all, I'm waiting for a fix for the input shifting I explained in the Dolphin development topic.
And yes, the keyboard's arrow keys seem to glitch up Dolphin, so I have my directional buttons elsewhere.
Can you ask him to see if he can find the exact revision that causes the desyncs? I looked ahead and couldn't find any big LLE changes right after 7318, and I was able to completely play back diggidoyo's MM10 WIP he uploaded in the MM10 thread with no problems. (Other than crashing twice before figuring out it was XAudio2 causing them.)
To people having hotkey issues, Try running the emulator from the main window. (Config -> Display -> Render to Main Window) That fixed the hotkeys suddenly not working for me.
And this is the first time I've heard about newer revisions having syncing problems. Can you explain this more? r7323 was a fix for memcards ejecting/reinserting on savestate, so I would think that would help sync.
When the window is open, it uses the analog inputs you set in it. Obviously it could be expanded later for digital buttons/macros, but I really want to get the analog stuff in ASAP.