What's new

Bugs in 1.6 (input plugin specs)

rabiddeity

Plugin Hacker
Not sure if this has been fixed in the 1.7 chain or not, but these are things that are broken in 1.6.

I'm hacking around, overhauling NRage's input plugin, and I've noticed a few things that REALLY need to be fixed in PJ64. (And if you say "Use another emulator" you're completely missing my point.)

1. Controller spec 1.1 support is broken. If I return PluginInfo->Version = 0x0101 to GetDllInfo, the plugin doesn't show up at all in the plugin selection dropdown. I'm running traces in the debugger so I know it's attaching and returning the right value, and of course it works if I run under 1.0 spec with the older InitiateControllers format. C'mon, guys, it's a pretty good spec, but if you release a spec with your emulator (in the docs folder) I expect it to work in your emulator!

2. CloseDLL is called when it shouldn't be. According to the spec, "This function is called when the emulator is closing down allowing the dll to de-initialise." Here's the normal chain of calls:
(DLL loaded)
InitiateControllers
:ROM list shows up,
:I double-click a ROM to load it
CloseDLL
(DLL unloaded)
(DLL loaded)
InitiateControllers
:ROM finishes loading
RomOpen
...
RomClosed
CloseDLL
(DLL unloaded)

So that works fine. Now if I start with a different plugin loaded up, say Jabo's Directinput 7...
:ROM list shows up,
:go to Options->Settings...
(DLL loaded)
(DLL unloaded) // this is for enumeration, obviously
:select my plugin from the list
(DLL loaded)
:click OK
InitiateControllers
:Rom list shows up,
:double click a ROM to load it
CloseDLL
InitiateControllers // crashes here because I dealloc'd everything in CloseDLL

Notice something wrong? According to the spec, CloseDLL isn't supposed to be called here, because the DLL is never closed and unloaded.

Sure, it's an easy fix, just move all my dealloc stuff to DLL_PROCESS_DETACH... but obviously the CloseDLL func isn't called when Zilmar said it should be.

Are both these fixed in 1.7?
 

ScottJC

At your service, dood!
Well for the first one, I'd say is there any benefit from using 1.1 spec over 1.0?

Seems possible to me that CloseDll after a rom loads is because it wants to reinitialize it first, I see no other reason why it would do that and if thats not the case why do the other plugins work? or is it possible that your Dll crashes midpoint after the rom loads and is asked to do something?
 
Last edited:

Smiff

Emutalk Member
all the plugins specs have been bumped for 1.7
not sure about these issues though, i'll point zilmar to this
thanks
 

zilmar

Emulator Developer
Moderator
I remember fixing a couple of bugs recently with the input plugin, I know the version number is one .. where plugins get allocated and deleted has been totaly re-done as the code of how this worked was a mess, so I like to believe most/all this bugs have already been fixed in 1.7. I am guessing what happened with the plugin spec I wrote up how to do it and put in the functions, but left out one of the checks for the version to see if it should be listed in the dll list. Thanks for pointing that out. Cause if I had not fixed it would have been something I would want to fix. What are you doing with nrages plugin at the moment ?
 
OP
R

rabiddeity

Plugin Hacker
Alright, it's straightened out, thanks guys.

Mostly just cleaning out the old code. Bugfixes, spelling fixes. Added support for more controllers and controller types, independent mouse X/Y sensitivity, and I'm adding a framework for internationalization (language plugins for the plugin). Fixed the code so it writes back mempaks to disk immediately instead of on RomClose (most people don't realize that in case of a power failure or emulator crash, their savegame would have reverted to when they last opened the ROM). Oh and I cleaned up the interface too, made tabbing around the config window work properly, that sort of thing.

I've been talking with NRage about the spec, and I figure as long as you're bumping all the spec versions, here are some things which would be really handy in a Zilmar Input Plugin Spec 1.2:

I really don't like using the "CONTROLS/CONTROL_INFO" struct passed in InitiateControllers as shared memory. We need a callback function for when the non-buttons data is changed by the plugin; for instance, after the plugin has changed the "Present" state by hot-plugging a controller, or changes "RawMode", it would call this callback function to notify the emulator. Right now, it's not possible to hot-plug controllers without writing directly into emulator memory using the original "CONTROLS" passed data. On your end, this function would enter a critical section if necessary, change the values of the "Present" and "RawMode" states for the given controller, exit the critical section, and return. Any code that reads from these values in a non-atomic fashion would also enter a critical section. This would be thread-safe and also memory-safe.

NRage also mentioned adding a callback to the spec to allow input plugins to write messages to the emulator. Right now we use CreateWindowEx with a timer to draw on top of the emu window for things like mouse lock/unlock, shortcuts emulation, or "visual rumble", which is ugly and might conflict with some graphics plugins.
 

squall_leonhart

The Great Gunblade Wielder
hey rabiddeity,

since your working on this, is there anyway that you could allow -pak switching to be controlled by a controller.

currently you can only assign pak switching to the keyboard
 
OP
R

rabiddeity

Plugin Hacker
squall_leonhart said:
hey rabiddeity,

since your working on this, is there anyway that you could allow -pak switching to be controlled by a controller.

currently you can only assign pak switching to the keyboard

Good idea, I'll look into it.

Beta version with source should be up in "Plugins", hopefully this week. I'll post a link to that thread here when it goes live.
 

zilmar

Emulator Developer
Moderator
hi rabiddeity

your suggestions have a lot of merit, the main reason that I do not recommend doing them is that, it is unlikely 1964 will get updated to use them. Only pj64 1.7 would be able to use it and that will not be out publicly for quite a while. It is one of the hard things about changing specs, it breaks backward compatibility. I do not mind that as much for the 1.7 plugins, because they are designed for the new version.

With regards to the shared memory, I use my own copy, and copy the plugins one when I want to make use/read things. If I have call backs, they can be just as bad, cause then there is possible multi thread issues.

Thanks
Zilmar
 
OP
R

rabiddeity

Plugin Hacker
I understand. I figure I'll have to release two versions of the plugin anyway, one for spec 1.0 and one for spec 1.1. On this end it's not too bad; I set a compiler define and I can spit out any version (NRage did a great job with this).

Thanks anyway. Looks like I arrived on the scene a bit late.
 

Top