When I was working on the OoT testrun a long time ago, I had the Rawdata unchecked, but it still would desync for me, so it's not entirely the rawdata's fault.
And I have a problem where Mupen keeps closing when I try to load as or save as. The screen for saving/loading in a certain place shows up, but after about a second it often closes the program, which gets really annoying for me when I want to make a save state after fast forwarding for a long time. I guess I could use F1-F9, but I like to save that for my own testing and such.
Actually, now that I think about it, I could work around it, but well, it's just a thing of convenience not having to go through the place where it stores save files and moving and copying and renaming them, but if I'm the only one with this problem, that's fine.
I didn't seem to have this problem before, though I haven't used it too often before, but the times I had used it more than a few months before, it worked fine.
if raw data is unchecked, the movie desynchs at the player name input. So that can't be it.
Andypro wrote:
But yes, aside from that we can rule out the other possibilities as we're all using the proper plugin / raw data / read only settings and the same rom version.
Bag of Magic Food wrote:
Couldn't you put RawData into the dialog box for loading movies where it compares the settings so we wouldn't have to keep asking the movie author whether to check it?
As far as I can tell, the "raw data" option inherently causes some instability in the recording. I'm not sure why, which means the behavior is undefined/unsupported when it is checked, so it never should be checked. Future versions may refuse to record or playback when that option is on, or at least will issue a warning.
Andypro wrote:
In fact so much so that I'm almost considering trying to join the development team on mupen so we can get some of this crap fixed (recordable resets, desyncs, etc).
Recordable resets and from-SRAM recording have basically been done for a while. (But not posted because of other issues.)
I believe the official development team is Hacktarux, who hasn't released any updates or news of progress in quite a while. The official Mupen64 message board is here.
As for the subscreen delay, I've looked into it several times and am giving up on it for now, again. There's not enough of a debugging framework in Mupen64 to effectively test anything or isolate the changes made by the video plugin when the "copy framebuffer to RDRAM" option is on. Nothing useful came from comparing RDRAM dumps or simulating the changes in it when bringing up the pause screen. Other emulators appear to have the same problem (subscreen delay), except when using an emulator- and ROM-version-dependent cheat code to skip the delay.
The subscreen delay, for one, is nonexistent in Proj64.
Do you know how long ago (emulator version number) they fixed it? I think I read somewhere that they simply detected the ROM and hard-coded that cheat code to always be on for it. That might be the most viable solution...
I may be talking out of my ass... but to help emulate analog control, how feasible/difficult would it be to add a toolbar where you can enter in values (1-99) for U, D, L, R so that when you press the up key, it's registered as pushing the analog stick up U% of the way... and the left key being registered as pressing the analog stick L% of the way and so on?
It would be about as difficult as modifying an input plugin to have an on-top user interface box. There is probably a more convenient scheme than simply giving each arrow key a sensitivity setting, though, like displaying a circle to click in that sets the analog position, and a way to assign keys to custom analog positions.
It would be about as difficult as modifying an input plugin to have an on-top user interface box. There is probably a more convenient scheme than simply giving each arrow key a sensitivity setting, though, like displaying a circle to click in that sets the analog position, and a way to assign keys to custom analog positions.
So, um, how difficult is that?
And I don't see how that'd be more convenient since I'd probably end up clicking it until I got the precise sensitivity values I'm looking for (I can be incredibly anal like that).
I suspect that this might be an issue on my end, but it seems that the audio lags slightly behind the video when I capture an AVI, even after encoding. This became quite noticeable with the OoT WIP AVI that I just encoded last night (child portion completed), which was about 4 seconds behind at one point, and possibly went as high as 6 or 7 seconds behind by the end of the movie. As the numbers indicate, it appears that the lag increases with the length of the movie. Does anyone know if this is an issue with the emulator?
It would be about as difficult as modifying an input plugin to have an on-top user interface box. There is probably a more convenient scheme than simply giving each arrow key a sensitivity setting, though, like displaying a circle to click in that sets the analog position, and a way to assign keys to custom analog positions.
So, um, how difficult is that?
And I don't see how that'd be more convenient since I'd probably end up clicking it until I got the precise sensitivity values I'm looking for (I can be incredibly anal like that).
How bout something where you can click OR use the arrow keys to go up/down/left/right one pixel at a time? OR input values? =P
I don't know, probably not very difficult, but I haven't tried it.
AzHP wrote:
How bout something where you can click OR use the arrow keys to go up/down/left/right one pixel at a time? OR input values? =P
That's sort of what I was getting at (a circle and some number fields that are both read and write, and way to snap to frequently-used values). Using the arrows keys to move the stick up/down/left/right a little at a time is already in some input plugins.
Dacicus wrote:
but it seems that the audio lags slightly behind the video when I capture an AVI
Does this happen with other games (like Mario 64), even at a lower resolution and with less CPU-intensive codec settings?
Bag of Magic Food wrote:
And shouldn't the values go up to 127 or 128? I still think the reduction to 99 on the input display is pretty bogus
Does this happen with other games (like Mario 64), even at a lower resolution and with less CPU-intensive codec settings?
I have the same problem, and it happens also in Mario 64. Sometimes the audio also plays too early instead of lagging behind. I capture at 320x240 with default settings on the Xvid codec.
I suspect that this might be an issue on my end, but it seems that the audio lags slightly behind the video when I capture an AVI, even after encoding. This became quite noticeable with the OoT WIP AVI that I just encoded last night (child portion completed), which was about 4 seconds behind at one point, and possibly went as high as 6 or 7 seconds behind by the end of the movie. As the numbers indicate, it appears that the lag increases with the length of the movie. Does anyone know if this is an issue with the emulator?
When you say the audio is behind, do you mean it is playing later than it should? If so I think I may be able to help. I may be be wrong here but the problem might be that the capture sets the framerate to 60.0, when in actuality, an N64 runs at 59.94006. if my math is correct, you get 1 second of lag for every 16m40s. As far as I know there are two ways to fix this.
1) slow down the video: When you record in lossless, and use avisynth for final encoding either use this command on the video: AssumeFPS(59.94006)
2) speed up the audio: rather than making an avi (which is fucking terrible to use x264 with imo) make an mkv with mkvmerge and tell it to speed up the audio by a factor of 1.001 (not exact but perfect for a movie that is under 25 hours)
Also doing everything you already do but reencoding the audio by resampling and changing the speed to that factor is an option, but I personally would probably opt for option 1.
Like I said though, I might be wrong and it might just be you experiencing that problem :)
Do you have the sync audio to video checkbox set in your audio plugin? If not, see if recording works better with.
bkDJ: Thanks for trying to help, but I see some issues with your suggestion.
I thought we had decided that the N64 runs at 20 FPS.
Capturing an AVI with H264 lossless seems prohibitive, at least for my current HD (10 GiB free space, around 30 GiB total). Last time I tried, I got a 3-GiB file when recording up to the Silver Gauntlets. Admittedly, that was at 640×480 resolution, but I think it would still be huge at 320×240.
I get the lag with and without "Sync game to Audio" checked.
After fiddling around with mupen's avi recording, I see that "*.avi" is the only choice, and we all know anything bigger than 2 GB won't work, and lossless codecs (I prefer huffyuv sice the overhead is very low and since the point is to reencode, the recording stage may as well be quick) do make prohibitively large files if you have such a small harddrive (I tend not to think about that since I have 2TB of space). Mupen seriously needs to auto-split at the 2GB mark, but I don't have enough programming experience to do anything about that other than manually make a new file every 5000 frames. for reference, huffyuv makes 7500 frames 2GB at 640x480 and 1GB at 320x240.
I've never tried using an avi with mkvmerge, but you could still try making an mkv with an audio speedup flag.
Also, you don't NEED to make the first .avi lossless to change the framerate. with avisynth. It's just that for best quality and even compressibility, reencoding something that was lossily compressed is a bad idea. :)
oh and no the N64 does not run at 20fps. it runs at 60. The games on it vary, though. Games like Super Smash Brothers and F-Zero run at full 60. Super Mario 64 runs at 30. OoT runs at 20.
I'm getting a strange error I've never gotten before. I haven't messed with mupen since the last time i used it, when it worked fine. I'll just copy the error word for word. There are 3 popups.
1st:
"Direct3D failed to initialize
Error code: 8876086A
D3DERR_NOTAVAILABLE"
2nd:
"Failed to initiate gfx plugin."
3rd:
"Initialize the dll before you try config it!"
If I am trying to load a game, the emulator crashes at this point. If I am in the settings menu, nothing happens after the 3rd popup.
I get this message every time I try to config the graphics plugin or load a game. I'm using Jabo's Direct3D8 1.6. I've always used this plugin, and never seen this message before.
Any ideas?
I'm trying to customize the Windows version. This "full source" does not seem to include the Visual C++ workspace files. Where can I get them, so that I can immediately try recompiling it?
Edit: Oh, I see. It uses Mingw and MSYS.
Edit:
bisqwit@GON ~/nes/n64/mupen64_src-rerecording-v8/winproject
$ make -fmakefile.win
gcc.exe -c ../main/win/main_win.c -o ../main/win/main_win.o -I"include" -I"zlib" -D__WIN32__ -DX86 -DVCR_SUPPORT -Wall -fno-strict-aliasing -fomit-frame-pointer -fexpensive-optimizations -O3 -march=pentium2 -mmmx
../main/win/main_win.c: In function `pauseEmu':
../main/win/main_win.c:1103: warning: implicit declaration of function `VCR_updateFrameCounter'
../main/win/main_win.c: In function `closeRom':
../main/win/main_win.c:1212: warning: implicit declaration of function `VCR_stopCapture'
../main/win/main_win.c:1287: warning: implicit declaration of function `VCR_clearAllSaveData'
../main/win/main_win.c: In function `PlayMovieProc':
../main/win/main_win.c:1461: warning: implicit declaration of function `VCR_getReadOnly'
../main/win/main_win.c:1552: error: `MOVIE_AUTHOR_DATA_SIZE' undeclared (first use in this function)
../main/win/main_win.c:1552: error: (Each undeclared identifier is reported only once
../main/win/main_win.c:1552: error: for each function it appears in.)
../main/win/main_win.c:1559: error: `MOVIE_DESCRIPTION_DATA_SIZE' undeclared (first use in this function)
Sorry, I didn't see that post before. If you're still looking for an answer... it actually uses Bloodshed Dev-C++, although that uses MinGW so both should work. The error you posted looks like it can be fixed by making sure vcr.h is included. That should contain:
Depends on the input plugin. Would it be good enough to assign a range for each axis (left/right and up/down) separately, or do you really need left and right, or up and down, to have different ranges from each other?
Rising Tempest: Take a look at this thread. If it's something you want to be changing a lot, I think it'd be easier to use the mouse to set the positions on that circle. Post there if you have any other suggestions for things that would make the control easier.
