The file you posted says there's been 0 rerecords. I'm guessing you just opened the game and exported what you had so far, so it reset the count once again.
The latest revision has my new rerecording code in it, so that should keep track of the number of rerecords in the future. I would like you to be careful when using it because I can't be too sure that it still syncs everything correctly. My tests says it does, but I don't do the level of rerecording people here do.
Well, the good news is I have most of the rewrite working and it should be ready to commit later tonight or tomorrow.
The bad news is I discovered a bug that reset the rerecord count for movies for each recording "session". That means all movies you made up to this point will only have the number of rerecords since the last time you started recording, not total overall. While not a huge bug, it's still upsetting that it effects basically all movies made so far.
I'm using this unfortunate turn of events to go in and try to rewrite major parts of the movie code in Dolphin. The way it's done now is by swapping around multiple temporary and final movie files and can lead to file corruption, as you've discovered.
I'm currently rewriting to no longer use temporary files, but ran into a couple weird bugs. Hopefully I can commit this change in the next couple of days.
Just a Pentium? Not even a Core or Core 2? There is no way any games are gonna run at reasonable speeds on that. Also, the Intel HD Graphics mean you have an integrated graphics card, and a dedicated graphics card is a basic requirement.
I don't know what to do. I could re-do stuff since I'm not extremely far in and already have frame numbers to go off of. But is it worth it? What if the Dolphin devs update that again to lag differently before I finish the TAS?
Dolphin is constantly being updated. What I would do is just pick a revision and stick with it if it works for your game, since i can promise you this won't be the last change that breaks movies.
After looking though the revisions, it looks like 7318 might be the one causing the problems. It fixed a bug with disk read speed emulation not working correctly. If you can, try to see if 7317 works with your old movies and if 7318 is the one breaking them.
You are correct. Seems to be 7318. Was this change beneficial overall, and should I attempt to hex edit my input to sync on newer revs? Or continue using 7317 and below?
Since it's an accuracy fix, I would say it's beneficial. It looks like the change fixed a bug where the emulation of the disk drive seek speed was wrong, and instead was able to seek to data immediately, instead of having a small delay like the actual hardware. It would be very difficult to manually edit movie files to get them to sync correctly, which would involve adding the appropriate amount of blank frames to account for the new longer load times.
I feel like I should point out that newer revs messed up playback of older recordings. I downloaded 7321 to test netplay with someone else and my SA2:B .dtm desyncs at the intro of the game. My last "working" rev that I downloaded was 7306.
Revision 7272 had some changes that messed up old movies.
That was only Wii movies. I'm talking about Gamecube. I use 7227 on my laptop and 7306 on my desktop, and the movies I've made so far sync on both. But when I updated to 7321, they broke.
After looking though the revisions, it looks like 7318 might be the one causing the problems. It fixed a bug with disk read speed emulation not working correctly. If you can, try to see if 7317 works with your old movies and if 7318 is the one breaking them.
I feel like I should point out that newer revs messed up playback of older recordings. I downloaded 7321 to test netplay with someone else and my SA2:B .dtm desyncs at the intro of the game. My last "working" rev that I downloaded was 7306.
Revision 7272 had some changes that messed up old movies.
A small heads up to the TASers working on Wii games:
Revision 7272 changed the timing method for polling the wiimote for input. I'm not sure if this change fixes the desync problems many users were reporting, but it will break any movies you made pre-r7272.
It seems that syncing with Wiimotes is still causing some problems on my end, even without using savestates. Since I never got to test Wiimote recording fully, I wasn't sure if they played back right, but now it seems it's not the case.
Do you still have sync issues on Gamecube games?
but when i tried it out recording a video and play back in media player classic, there's no sound at all. What's up with that ? is there another specific option somewhere im supposed to click on that i have no clue about ??
I've always used the Xvid codec option to record videos with other emulators perfectly, but this is the first time ever that i get no sound whatsoever.
There's a separate option to dump audio to a .wav file. This is a leftover from back when the emulator was plugin-based, and both will probably be combined together in the future.
At the moment, TASes for GameCube games seem completely doable in my opinion, if difficult with the lack of some features such as a specific TAS input method, and memory watch (although debug mode has something similar). However, Wii TASes still need a little more work. Wiimotes aren't saved in an easily readable format in movie files, some users are reporting that savestates are messing up Wiimote playback, and Wiimotes are polled at a faster rate than FPS, which can cause some problems.
I'm pretty sure Dolphin has a RAM watch, but you have to start the emulator in debugger mode (with the -d flag on startup) and I'm not exactly sure how the debugger works.
Well, that means that it's playing the half presses for the shoulder triggers correctly. Not sure why it's not working for movies you make. (Also, are you sure you didn't see the crosshair? It's supposed to show up if R is pushed in all the way, which I do when looking down, but not up. It should look like this.)
The header for .dtm files are detailed here in the DTMHeader structure, but not all the fields are used or even set yet. (gameID is ignored for playback at the moment, uniqueID isn't set, and all the fields after numRerecords are not set yet.) The format for the Gamecube controller is the ControllerState structure. I'm not sure how Wiimotes are stored. I think we just store the raw emulated USB packets for it.
EDIT: The comment for numControllers is outdated. It now is a bitmask of the controllers used. (First 4 are GC controllers 1 to 4, last 4 are Wiimotes 1 to 4.)
petrie: Can you test this movie for me? I'm trying to figure out why only full presses for shoulder buttons are working for you, since everything works fine on my end.
http://www.mediafire.com/?y83xxef9bf18njd
This movie was made with r7177 in Metroid Prime and uses the memory card you uploaded in the other thread. In it, after loading the first save file, Samus should look up, then look down, and a crosshair should appear in the center of the screen when looking down. Make sure Dual Core and Idle Skipping is off, and the audio engine is set to HLE. (Although I'm still unsure if the HLE engine is deterministic enough to used for a full TAS. I got a huge desync when trying to dump the raw frames to make a sample video for this demo, which I don't get if I rerecording it with the LLE engine.)
Yeah, I sometimes had a particular desync when playing that one back where Samus would push against the wall to the left of the door and thus not make it through. It usually happened if I messed with the framerate too much. Is that the same one you were having?
I think it's the HLE audio that causes that desync, but I'm not positive. I've encountered it a while ago when testing rerecording with SSBM.
oh, yeah, I used HLE. LLE keeps giving me horrible errors. Apparently I need some sort of dsp file that I can't legally obtain.
If you have a Wii that can run homebrew (or know of a friend that has one) you can get it that way. LLE is less likely to desync than HLE according to many of the other devs.
OK, another test
http://www.mediafire.com/?ps3aa87yd2pdtib
The above contains a memory card and a dtm for Metroid Prime v1.0. The movie should work if the memory card is in slot A. It depicts Space Jump First.
I can't test it right now (on my laptop) but you should post the sha1/md5 hash of your ISO, because Metroid Prime has three different versions, which all have differences, specifically regarding space jump early.
Thank you Toad King. New question, would you happen to know why FRAPS doesn't record Dolphin (in fact...it crashes it). This was never a problem before r62xx hit (around when input after loading a state was broken).
No idea. If you want to save a movie to video, you can set the dump frames option in the graphics settings and the new dump audio settings and just combine the two files those options spit out. Just know that sgrunt is saying that they don't always line up correctly and you may need to delay/cut the sound a little bit to get it synced.
When I try to use the LLE recompiler for audio, I get these 2 error messages:
http://img607.imageshack.us/img607/875/dolphin.png
The first one disappears when press OK twice. The second one disappears if you press No twice, but the screen just stays black. If you press Yes, Dolphin closes itself.
Anyone know a fix for this?
You need the DSP ROM files to run the LLE audio engine. The only ways to get this legally is manually dumping it from a Gamecube/Wii. However, if your Wii can run homebrew, you can dump it easily with a program: http://forums.dolphin-emulator.com/showthread.php?tid=3823
Place the dsp_coef.bin and dsp_rom.bin files it generates inside the /Sys/GC folder of your Dolphin folder.
However, I'm still having a problem with savestates and Dolphin not taking input after loading one. This is kind of important to making rerecording work, so I'd like to know what can be done about this.
Also, hotkeys stop working for me if I don't switch over to the main Dolphin window. Any ideas why?
i noticed these problems in virtually any revision i try. :(
** Loading savestates dont even work half the time, like i'll open the emulator, i can load a state once, i try to do some stuff, i screw up, load again and it's become literally corrupted or screwed up, just frozen unless i completely close down the whole emu and reopen. And F1-F8 keys also only seem to work "once, then reopen whole emu"
** And it wont ever do anything unless i specifically click on disconnect wiimote 1, then reconnect... every single dang freaking time.
** and the frame advance is weird. In megaman 10, when im frame advancing...it literally skips over a frame once in awhile. When im watching the time attack counter it'll go like 1, 3, ..6, 8, ...1
That's not supposed to happen, it like completely skips over a frame cause the counter only goes up by 0.01 and 0.02 ... NOT 0.03
All these problems dont happen in dolphin 2.0 ..which is what i currently use. The only problem 2.0 has is loading and saving states sometimes crashes the whole emu, and the crash might cause the state to become permenately corrupted (saying 60 FPS, and frozen forever) heh
I've tried several different recent revisions and nothing seems to work better compared to the old 2.0 at least for me unfortanetely. So i always stay with that.
Make sure that the following settings are correct:
Dual core mode is off
Idle skipping is off
Audio engine is LLE (either recompiler or interpreter work okay)
Also, what OS are you using? And are you using 32 or 64-bit versions of Dolphin?
It happens to me with Gamecube games. So far I've tried with Mario Sunshine and SSBM.
Is it the controller stops completely, or does it start working again after a couple seconds ingame? If it's the second thing, I think I've got a way to fix it which I'll commit later today.
For example, what I do is enter Event Match 1 at normal speed. Then during the countdown (around 2 or 1), I pause and enter frame advance. I go until there is about .13 or less on the timer, then I make a savestate. If I hold left, Mario turns and walks like you would expect him too. Then, if you load the state back and hold left, Mario will not move for quite a long time. If you go out of frame advance and wait like 1 - 1.5 seconds, control of Mario will resume and you can play normally. I hope this helps.
Edit: If it helps, I believe this problem started around r62xx.
Yeah, I found the cause of that. It's a bug in the rerecording code and should be fixed in a bit. (Just have to finish testing it.)
It happens to me with Gamecube games. So far I've tried with Mario Sunshine and SSBM.
Is it the controller stops completely, or does it start working again after a couple seconds ingame? If it's the second thing, I think I've got a way to fix it which I'll commit later today.
