(Also serves as an edit counter)
1. Keyboards work, but for analog input, you need another way. Is a mouse possible?
2 & 3: Dunno
4. No. You can mess with the speed all you like.
1. Keyboards work, but for analog input, you need another way. Is a mouse possible?
Mouse is possible through the NRage input plugins, although actually you can also set it to give full analog control using keyboard instead of mouse (but requiring multiple keypresses to move the stick all the way to the other end). Having an actual game controller plugged into your computer is probably the best way, if you have or are willing to get one. (I'm pretty sure that's what FODA is using.)
nfq wrote:
2. If I have a controller, is it possible to set hotkeys for it?
It's possible to use a controller to activate hotkeys by using JoyToKey or a similar program, but you can't do it directly in the emulator alone, no.
nfq wrote:
3. Why do I have to uncheck "Raw Data" in Input settings?
When it's checked, the input goes through a different path in the code. Something makes the game behave slightly differently (enough to desync) when it does so. I'm not sure why it's different, but it can't be right because it's not supposed to affect the game, so you should leave it off. (If you're asking why the emulator doesn't do it for you, it's because the emulator doesn't have control over the input plugin's internal state.)
DeHackEd: I was thinking about adding the ability to record "Reset" into M64 movies, but would that be unworkable on the Linux version? DeHackEd wrote:
1. Keyboards work, but for analog input, you need another way. Is a mouse possible?
Mouse is possible through the NRage input plugins, although actually you can also set it to give full analog control using keyboard instead of mouse (but requiring multiple keypresses to move the stick all the way to the other end). Having an actual game controller plugged into your computer is probably the best way, if you have or are willing to get one. (I'm pretty sure that's what FODA is using.)
nfq wrote:
2. If I have a controller, is it possible to set hotkeys for it?
It's possible to use a controller to activate hotkeys by using JoyToKey or a similar program, but you can't do it directly in the emulator alone, no.
nfq wrote:
3. Why do I have to uncheck "Raw Data" in Input settings?
When it's checked, the input goes through a different path in the code. Something makes the game behave slightly differently (enough to desync) when it does so. I'm not sure why it's different, but it can't be right because it's not supposed to affect the game, so you should leave it off. (If you're asking why the emulator doesn't do it for you, it's because the emulator doesn't have control over the input plugin's internal state.)
DeHackEd: I was thinking about adding the ability to record "Reset" into M64 movies, but would that be unworkable on the Linux version? (Reset should be as simple as shutting everything down and starting it up again, but it won't be that easy if everything crashes for no apparent reason instead.)
I originally had troubles with Mupen64, apparently due to the fact that the emulation runs in a different thread and GTK is a little sensetive about its threads.
But I am able to save/load savestates successfully, so some kind of reset mechanism should be possible.
Do you want access to a unix machine for debugging? I can arrange something if you want to do testing.
It's a yes when I get around to looking at Mupen64 again...
(So, maybe in a week or two. There are a lot of changes that need to be made and I'm not even sure which of them I'll be able to do or how to prioritize them.)
EDIT: Or not... I was hoping to actually have some progress to test before doing this, and so still haven't gotten around to it since it's looking like waiting for the next official release of Mupen64 is a better bet for seeing some of these problems fixed...
I don't think Nitsuja's added that yet. We were talking about putting the Reset button into a seemingly unused input bit, but I don't know if that's safe.
put yourself in my rocketpack if that poochie is one outrageous dude
Would it be possible to set up Mupen so that when recording AVI files it will automatically split them at the appropriate interval? I've had to go through a lot of trial and error to figure out where in a game I need to stop recording and then start on a new file. (Tried to record the Super Mario 64 120 Star run and I'd rather not repeat what I said when it had finished and the .AVI file was far too big for it to work. heh).
Joined: 5/1/2004
Posts: 4096
Location: Rio, Brazil
I think you can use any, but in case you're wondering, I've been using these:
Jabo's Direct3D8 1.6
N-Rage's Direct-Input8 1.60
Jabo's DirectSound 1.6
RSP emulation Plugin
Joined: 4/21/2004
Posts: 3517
Location: Stockholm, Sweden
Nitsuja, any chance you'll fix the errors in Mupen soon?
Nitrogenesis wrote:
Guys I come from the DidyKnogRacist communite, and you are all wrong, tihs is the run of the mileniun and everyone who says otherwise dosnt know any bater! I found this run vary ease to masturbate too!!!! Don't fuck with me, I know this game so that mean I'm always right!StupedfackincommunityTASVideoz!!!!!!
Arc wrote:
I enjoyed this movie in which hands firmly gripping a shaft lead to balls deep in multiple holes.
natt wrote:
I don't want to get involved in this discussion, but as a point of fact C# is literally the first goddamn thing on that fucking page you linked did you even fucking read it
Cooljay wrote:
Mayor Haggar and Cody are such nice people for the community. Metro City's hospitals reached an all time new record of incoming patients due to their great efforts :P
AVI output doesn't work well.
Using AVIzlib and CorePNG makes it to crash.
Using Techsmith and FFv1 codecs gives me an error.
Video codec failure
A call to addVideoFrame() (AVIStreamWrite) failed
Perhaps you ran out of memory.
Using uncompressed format works but that's not good.
Edit: Ok, it seems that we need to wait the ROM to be loaded before starting recording in AVI. I don't like the solution.
Joined: 3/18/2006
Posts: 971
Location: Great Britain
I've been using this emulator for a long time. But now there are problems with AVI output. I don't know why these problems arise now... =-/
Either,
I record a movie and the AVI file is unreadable (it says i dont have the right codecs, yeah right, i actually do :-))
or
I record a movie and the AVI file plays the movie but it is crazy. Weird sounds, multi coloured madness... just plain weird.
I only got this problem when I started an Extreme -G TAS... But now I cannot encode anything to AVI with this emu...
Any ideas? =-( I want to make N64 movies.
EDIT: BTW I am using uncompressed AVI. I do this and then encode later.
Feature request:
In the play movie dialog box, add a text field that accepts a frame number to start the movie on, and then have the movie start at the specified frame.
I don't know how easy this would be, but it would be immensely beneficial on long TASes.
>In the play movie dialog box, add a text field that accepts a frame number to start the movie on, and then have the movie start at the specified frame. I don't know how easy this would be, ...
It would practically mean that the movie had to be fast-forwarded to that point before starting to show anything. It's not impossible (I don't even think it would be that hard) but you would be much better off by a savestate which gets you there in no time at all.
There is a MAJOR problem with desynchronizations in the production of the OoT TAS.
I know, but I can only assume it's because he's using the "raw input" option which I said beforehand not to use because it could cause desyncs, and he for some reason didn't change when starting over. Also, there might be an actual desync in the movie file caused by loading savestates incorrectly or changing video plugins, or confusion over the ROM version or video plugin settings or other input settings.
The subscreen delay is the biggest problem right now that I'd been hoping to find a fix for, for the next version. It doesn't help that I can't get the source for the only video plugin that produces the desired behavior, and that Mupen64 has had a minor bugfix update since 0.5 without the source for that update being made available.
I can only assume it's because he's using the "raw input" option which I said beforehand not to use because it could cause desyncs
If raw data is unchecked, the movie desynchs at the player name input. So that can't be it.
Also, there might be an actual desync in the movie file caused by loading savestates incorrectly or changing video plugins, or confusion over the ROM version or video plugin settings or other input settings.
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?
mwl wrote:
Also, there might be an actual desync in the movie file caused by loading savestates incorrectly or changing video plugins, or confusion over the ROM version or video plugin settings or other input settings.
No, it's none of these.
Actually, I think people were saying that the movie was desynching when they DIDN'T use a savestate, meaning that the savestate was inaccurate somehow and led to the movie desynching when played back normally and only working when started from that savestate.
put yourself in my rocketpack if that poochie is one outrageous dude
I'm sorry, but I find it hard to believe that this is all due to our error and not faulty programming. It cannot be a coincidence that EVERYONE in that topic reported a desynch at the same location. Early on in the OoT topic, the proper plugins were posted and the ROM (v1.0 U) agreed upon.
Do a search for "desync" under subforum "N64 Games" and you'll find the desynching problem brought up in every single N64 WIP. It's not just an OoT thing.
Hmm. I suppose we should ask GuanoBowl if he's in fact recording this movie with the raw input option or not.
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.
