so the file just dissapears into nothingness or something :s... it can still be played back though.
That means the file is still there and should be recoverable. Try using this program to recover the file. Put it where the movie should be and type the movie's filename ("Gex 64: Enter The Gecko.m64", or whatever it is) when it runs.
(The emulator should be made to change those characters into dashes before recording, of course.)
seems to me that if you know the exact filename of the invisible file, you can rename it with commandline, like
move "Turok 3: Shadow of O (USA).m64" "turok3.m64"
seems to me that if you know the exact filename of the invisible file, you can rename it with commandline, like
move "Turok 3: Shadow of O (USA).m64" "turok3.m64"
That's what I thought at first, but try it and you'll see that the commandline rejects that command too. It says "The filename, directory name, or volume label syntax is incorrect."
I don't know how that would ever be possible if the Nintendo 64 only accepts one stick coordinate at a time. The control stick isn't a set of buttons. What are you imagining here? Slicing the stick in half and pulling the halves in different directions?
put yourself in my rocketpack if that poochie is one outrageous dude
It wouldn't make any difference because you can set the stick out of position before the power is switched on and then pull in the oposite dirction. It just netrulises the movement.
EDIT: When I'm recording on MM I can get something to work and run it correctly from a savestate hasn't been recorded from, but when I check it from the start it just desyncs some time after that savestate has been used. I'm gonna continue till I can get into the clock tower, but the desync rate is phenomial (27 in 17 mins), I guess its because its an expansion pack game. I can imagine DK64 and PD being a lot worse. I'm just wondering is it more to do with the rom or emulator and why has no one been able to run it correctly apart from me. I actually think Petrie managed it though, then again could it be because of the TAS 0.6 pluggin.
Quick question: is it possible to allow left-right/up-down on the Mupen Controller? If so how? If not, can it be included in the next update?
It is already possible to press left+right or up+down on the digital pad. It's not possible on the analog stick for obvious reasons.
AKA: Are you sure you're experiencing a higher rate of desync than in OoT? You could be right that the expansion pak (or ROM size?) is making it worse somehow, but if so, that's definitely not the only desync-related problem. Does it desync as much if you don't load any savestates while recording it?
Joined: 10/31/2005
Posts: 329
Location: The Netherlands
so I finally figured out why I couldn't make save states that worked.. I use the Save As.. option and then enter a filename and press save. yet, today I found out that it doesn't save it, I have to actually use the Save State option explicitly afterwards as well. I guess I didn't notice this before since I probably saved over another file, yet not for real thus. I have Mupen64 0.5.0, and I see v8 is out. is this changed in this version? I'm not sure if I should get the new version since there's a note I'm not sure if it affects anything for me.
If you have an even older version you should get that, to eliminate the possibility that any other problem you have is because of an outdated version. But for your problem, use the savestate hotkeys, not "save as" (which isn't fixed yet).
Joined: 6/13/2006
Posts: 3300
Location: Massachussetts, USA
I don't know if this has been answered before...
in the current TAS I'm making the game uses the expansion pak, which I'm not 100% sure if it's nescessary to play the game, but someone suggested that the desynchs myself and everyone is getting while I'm making it are caused by this pack... Is there any way in Mupen to disable it, when I load the ROM it says no controller pak found, insert a controller and press 'A'. Is there any way to turn the expansion pak off?press start to continue without saving.
Access Violation
While processing graphics data an exception occurred
you may need to restart the emulator
With what game and graphics plugins does that happen? It sounds like a plugin-specific problem so I would think you could find a combination of plugins that prevents it from crashing like that. There are some emulation options in the settings you could try fiddling with as well (things like recompiler mode or alternate handling of jump instructions) but I've never seen anything besides worse performance come out of changing those.
comicalflop wrote:
the expansion pak, which I'm not 100% sure if it's nescessary to play the game, but someone suggested that the desynchs myself and everyone is getting while I'm making it are caused by this pack...
The expansion pak simply extends the capabilities of the N64 by giving it more RAM. Thus there is no need to emulate it specifically, it happens automatically by simply giving the N64 enough memory, and there's no way to turn it off that I know of. It's possible that the bigger the game is and the more RAM it uses, the more likely the game is to desync, in which case there's not much you can do to keep a particular game from desyncing. (Unless you're capable of finding and fixing bugs in the emulator's savestate code.)
It seems to happen with just any game now. Here are my current plugins:
Jabo's Direct3D8 1.6
N-Rage`s Direct-Input8 V2 1.82a
Jabo's DirectSound 1.6
RSP emulation Plugin
The thing is, the game isn't really crashing. It continues on just fine after I clear the error message box. The problem is that the message keeps on reappearing at seemingly random intervals, which means I keep having to tap Enter to clear it, which is the annoying part when I want to watch a movie.
Is there a way to just deactivate the message so I don't have to see it anymore?
put yourself in my rocketpack if that poochie is one outrageous dude
What is likely happening is Mupen is getting errors from the video plugin for something that isn't being handled properly. Does your graphics card support pixel and vertex shaders 2.0? Try using v1.5.2 of the plugin and if that has no problems than the only thing to do now is get a newer card or switch to something like rice which may work correctly.
Joined: 5/1/2004
Posts: 4096
Location: Rio, Brazil
Bag of Magic Food, that happens with me too if i open mupen64 + some h264 videos on VLC and other stuff. When i close those things and then restart mupen64, it stops giving me the errors. But it's a rare problem here.
Jabo's Direct3D8 1.6
N-Rage`s Direct-Input8 V2 1.60
Jabo's DirectSound 1.6
RSP emulation Plugin
these are my plugins, and i always run the emulator in windowed mode
Experiencing problems with frame advance.. Game is for Star Fox 64, but I highly doubt the game is the reason why its faulting. Input plugin seems okay and so does the video...
Whenever I tap my frame-advance key (R) it will advance a frame for the most part, but sometimes mupen will register a tap as "hold the button down for 30 frames or so" which makes the game play at 100%< speed which is odd.
I've never had this problem before, but I'm going to attempt a fresh reinstall of mupen and see how it works.
Whenever I tap my frame-advance key (R) it will advance a frame for the most part, but sometimes mupen will register a tap as "hold the button down for 30 frames or so" which makes the game play at 100%< speed which is odd.
That sounds like intentional behavior; if the game isn't checking input for 30 frames then frame advance will zoom past those 30 frames for you because they don't matter.
If it's during something being loaded then it's just general bad emulation of that certain area of the game which shouldn't be a problem since... it's loading and not ready for input sort of like in a cd/dvd game.
Bag of Magic Food, that happens with me too if i open mupen64 + some h264 videos on VLC and other stuff. When i close those things and then restart mupen64, it stops giving me the errors. But it's a rare problem here.
Okay, the next time I watch a Nintendo 64 movie, I'll try closing all other video-related applications I have running. I'll let you know if that helps any.
put yourself in my rocketpack if that poochie is one outrageous dude
Nitsuja, this messagebox.c in main/gui_gtk, did you insert this?
Because it's deadlocking the emulator and I'm going to have to amputate to save the patient.
Short version: don't call gtk's main loop code from any thread except the one designated to be for the main loop.
This shows up sometimes when the emulation thread wants to display messages on the screen, and the emulation thread isn't the GTK thread. MessageBox() locks up at 100% CPU usage from the gtk code detecting the flaw. Break down.
Workaround: messagebox now asks questions on the console. Besides, with always-on-top mode, I can't see the message boxes anyways.
