After renaming debugview.dll to debugview.dll.disabled it worked fine. Then I shutdown my computer and today when I was going to play the same movie it didn't work. So I had to rename debugview.dll.disabled back to debugview.dll. Then launch the emulator. Didn't work. Then again rename the dll to disabled. Then re-launch the emulator. That time it worked.
Do I need to do this every single time?
What i think andypro is thinking of, instead of using an avi output, just load the move like you always do when you are going to watch a movie. Then use a program like fraps or camtasia to capture the screen.
The best time you have is the time you share with other people.
I'm trying to get it to play the movie at http://spezzafer.home.att.net/sm64.zip , but it seems to work completely randomly.
So far, I haven't found any logic whatsoever as to what settings I need to have with the plugins so that the movie plays.
About 30 tries ago, the movie actually started when I set the "interpreter" mode on in the RSP plugin. Excited, I turned it off to test whether it was the cause, and the movie desynced again. I turned it again on, and the movie still desynced. So that much for that theory.
**image removed for space**
This is as far as it gets. The demo will continue to run, and eventually the hand icon disappears.
To me, it seems like there's a 98% random chance that in the very beginning, the emulator will fall several frames behind the movie, causing the movie to attempt to start the game (click Mario's eye or whatever) before the game allows it.
I actually got this same problem (using windowsXP) but running the emulator for about 30 seconds before each movie playback, seems to have fixed it. I'll see if I can do more tests if I have more time (but now I'm pressed for time).
What i think andypro is thinking of, instead of using an avi output, just load the move like you always do when you are going to watch a movie. Then use a program like fraps or camtasia to capture the screen.
I found what was causing the synchronization problems. There was basically a random chance that the emulation thread would skip over the first frame of input if the ROM-restarting thread took too long. Adding in better messaging between the threads seems to have fixed the problem completely.
(I think the reason I never noticed this problem before is because I never hit Start on the very first possible frame in my tests of Mario 64, in which case it happened to stay synchronized either way.)
I also tried putting the emulation and GUI in the same thread, but then I realized that the emulator core is written in such a way that it would need to be heavily modified for this to work (especially the low-level magic the dynamic recompiler does). Oh well, so much for making the GUI more stable with a simple change.
But you will have no choice but to duplicate frames because FPS always change during emulation. So imo, you can use external software since it won't be worst.
But you will have no choice but to duplicate frames because FPS always change during emulation. So imo, you can use external software since it won't be worst.
Well, the duplicate frames are just like when a NES or SNES game lags, except most N64 games purposely lag almost all the time at a constant rate. An external recorder will also get these duplicate frames, but it might get more or less frames than are actually there for a given graphics frame. Even if you set it to record at 60 FPS, it probably won't record at exactly that rate, and the emulator doesn't always run at quite the same rate of the game it's emulating either. Only getting the frames directly from the emulator will result in completely accurate output, and it's probably faster than using an external software recorder anyway.
I found what was causing the synchronization problems. There was basically a random chance that the emulation thread would skip over the first frame of input if the ROM-restarting thread took too long. Adding in better messaging between the threads seems to have fixed the problem completely.
This is very good to hear.
Hopefully my diagnosis was helpful in getting to finding this :)
No, because the frame rate is constantly changing like you said earlier. Sometimes, the game is at 20 fps while it can be at 50 other times. So, there will be duplicate frames. Not because of lags but because N64 sucks and can't do ~60 fps like other systems. :P
Well, it's all good now since nitsuja seems to have fixed the avi output issues. I admit that even if my method of video capturing were accepted here, it would be much more of a hassle to do than using the emulator's built-in functionality.
No, because the frame rate is constantly changing like you said earlier. Sometimes, the game is at 20 fps while it can be at 50 other times. So, there will be duplicate frames. Not because of lags but because N64 sucks and can't do ~60 fps like other systems. :P
I didn't say it's constantly changing. In most games, it changes only at certain specific times (like before the game really starts) and stays locked at one speed for most of the game. The FPS number you see in the emulator might be constantly changing, but that's not the FPS of the N64, it's just the FPS the emulator is displaying (which could be lower or higher). Using an external tool will get those extra changes due to your computer speed, whereas exporting the frames from the emulator will get the constant speed it is supposed to run at. (For instance, if you try recording a movie of Legend of the Mystical Ninja with external tools, you will get terrible slowdown in the AVI, but if you get the frames from the emulator and put them together, that extra slowdown will be eliminated.)
Andypro wrote:
Well, it's all good now since nitsuja seems to have fixed the avi output issues.
Sorry, actually I'm still working on it. (Or rather, haven't been able to work on it much yet.) So far I think I've gotten it to not crash, but there are other problems...
I didn't say it's constantly changing. In most games, it changes only at certain specific times (like before the game really starts) and stays locked at one speed for most of the game. The FPS number you see in the emulator might be constantly changing, but that's not the FPS of the N64, it's just the FPS the emulator is displaying (which could be lower or higher).
I know. The problem is the fact that "it changes only at certain specific times". AVI hates that. In fact, it doesn't handle it at all.
hehe, just dump 60 frames pr second, and stuff in enough audio for one second, and the h264 encoder will remove duplicate frames... It got a 650mb raw file down to 3mb easily, with very good quality.
Successfully patched and working under Linux. Mario 64 plays successfully (until the last level where it desyncs) and stream dumping (my AVI making setup) is working about as successfully as TNSe's 'ninja mario' movie.
Alpha 4 of the Windows version is up. Playing from-snapshot movies should be fixed, playing from-start movies should no longer have a high chance of desyncing at the start, AVI output should no longer crash so much, and the music of AVI output should be better.
Successfully patched and working under Linux. Mario 64 plays successfully (until the last level where it desyncs) and stream dumping (my AVI making setup) is working about as successfully as TNSe's 'ninja mario' movie.
I tried recording from snapshot and it played fine. Then I tried changing the name of the m64 file and it failed to load the snapshot at the beginning and desynced right away. Then I changed the name back and it played fine.
I tried recording from snapshot and it played fine. Then I tried changing the name of the m64 file and it failed to load the snapshot at the beginning and desynced right away. Then I changed the name back and it played fine.
Yep, that's supposed to happen. Although maybe an error message would be nicer than a desync. If you rename the movie file you have to also rename the snapshot (.st) file accordingly.
