NRage Input Plugin V2.00 BETA (an overhaul)
- Thread starter rabiddeity
- Start date
OP
rabiddeity
Plugin Hacker
- Thread Starter
- #362
I am stupid and did not actually UPLOAD the debug file. Sorry, it should work now.
Evryone can forget.
OK same as last post.
Just, PJ64 crash after start if nrage selected, but if I sellect nrage later(start with no or another plugin), its works normaly, ofcourse still no loading setting.
In 1964 dont work save. I can load but, if I push save, nothing saved. In starting emualion - plugin didnt get inicialized
What about setting in file? It can solve this and maybe future problems?
Or blow up win9x
OK same as last post.
Just, PJ64 crash after start if nrage selected, but if I sellect nrage later(start with no or another plugin), its works normaly, ofcourse still no loading setting.
In 1964 dont work save. I can load but, if I push save, nothing saved. In starting emualion - plugin didnt get inicialized
What about setting in file? It can solve this and maybe future problems?
Or blow up win9x
squall_leonhart
The Great Gunblade Wielder
have you the latest version of DirectX installed. i believe the latest nrage plugin is calling for an MDX file.
OP
rabiddeity
Plugin Hacker
- Thread Starter
- #365
Hm, shouldn't be. It loads from DirectInput8Create, with version set to 8, so any version of DirectX 8 or later should work. Where is it calling for another file? When you compile it?
Evryone can forget.
OK same as last post.
Just, PJ64 crash after start if nrage selected, but if I sellect nrage later(start with no or another plugin), its works normaly, ofcourse still no loading setting.
In 1964 dont work save. I can load but, if I push save, nothing saved. In starting emualion - plugin didnt get inicialized
What about setting in file? It can solve this and maybe future problems?
Or blow up win9x
As much as I'd like to blow up win9x, it refuses to die.
lain: Yes, ini support would be the solution. But there has to be a way to fix the issue here.
To rule out one more thing, try RegClean. I dunno if it'll help at all, but try running that. MS stopped supporting it, but it still works fine for win9x:
http://www.pcworld.com/downloads/file/fid,4666-order,1-page,1-c,alldownloads/description.html
Re: 1964 problems. That error message will only come up if 1964 doesn't run InitiateControllers function on the plugin before RomOpen, or if InitDirectInput fails completely. The second one would give you an error message, so it must be the first... That's not supposed to happen. I would fix that myself, but I really need the emulator to pass me a window handle so that I can initialize DirectInput. Otherwise I have to try to guess what the emulator's handle is. I'll give it a shot.
I uploaded another version, this one should spit out a lot more info. And by a lot I mean a LOT more info in the debug file. This new version won't fix any bugs, but I'll be able to trace pretty much exactly when the code crashes. Please delete your current NRage-Debug.txt files before running.
As it turns out, there's still quite a bit of work to do around the DirectInput initialization code. It's a real mess. I'm going to try refactoring so there's not so much code duplication. Coders can take a look at InitiateControllers and DllConfig if you're not sure what I mean. I've cleaned up a few things here and there, but it's still a bit of a mess. I need to eliminate the whole "many places the plugin/directinput/controller paks could be initialized" mess, and move it into one place if possible.
Last edited by a moderator:
I have dx9c.
1964 dont give me error "plugin didnt get inicialized" anymore, in game just is written no controller.
Pj64 cant start emulation, it crash after start.
OK I find something. If I delete item HKCU\software\NRAGE I can start pj64 with nrage sellected and start emulation. If I save some setting, then I get crash again. If I save during emulation, I can play normaly, if I save setting during emulation and stop and then start new emulation I get crash.
Of course setting is not saved.
Value of nrage in registers dont change. New created after deletion is same.
And I use regcleaner but it change nothing, and I recently reinstaled windows, so it should be cleaner.
1964 dont give me error "plugin didnt get inicialized" anymore, in game just is written no controller.
Pj64 cant start emulation, it crash after start.
OK I find something. If I delete item HKCU\software\NRAGE I can start pj64 with nrage sellected and start emulation. If I save some setting, then I get crash again. If I save during emulation, I can play normaly, if I save setting during emulation and stop and then start new emulation I get crash.
Of course setting is not saved.
Value of nrage in registers dont change. New created after deletion is same.
And I use regcleaner but it change nothing, and I recently reinstaled windows, so it should be cleaner.
Last edited:
squall_leonhart
The Great Gunblade Wielder
know anything about Dinput Controllers Rabid?
was wondering if you'd be able to help make XBCD work on Wireless controls.... by the lookings of it.. its gunna need to have the system files rewritten with the xbox360 info....
i dunno lol, im still learning (slowly)
yes but have you got the latest Runtime of Dx9c?
go to microsoft.com/directx and download the webupdater and run it.
its always best to cover all bases
was wondering if you'd be able to help make XBCD work on Wireless controls.... by the lookings of it.. its gunna need to have the system files rewritten with the xbox360 info....
i dunno lol, im still learning (slowly)
yes but have you got the latest Runtime of Dx9c?
go to microsoft.com/directx and download the webupdater and run it.
its always best to cover all bases
Last edited by a moderator:
Ok, Mupen64 and Project64 crashes shortly after starting. 1964 starts normaly, but if I try to load a game, the whole computer freezes completely. Saving some controller setting is still not possible.
Yes, the time of legacy DOS-based Win OS is over, nevertheless it would be nice to see that plugin working...
squall_leonhart
The Great Gunblade Wielder
lol, while dos is part of Win98, it is not a Dos based OS.
Dos is 8bit code, while windows is a split 16/32 bit.
Dos is 8bit code, while windows is a split 16/32 bit.
OP
rabiddeity
Plugin Hacker
- Thread Starter
- #370
When it crashes, what exactly does it say? What kind of crash is it? Out of memory? Divide by zero? Couldn't read memory? Or does it just hang until you kill the process? I can't remember if Win98 gives any useful information, but right now anything would help out.
A couple things. lion10, I think you've inadvertently uncovered a threading bug with this plugin while testing under 1964. On your system, the plugin init code is hanging under 1964 while trying to read/process the registry values. However, 1964 must be multithreaded because while that part is hung it's still letting you try to open up the config area. The config area would normally read from the settings in memory, but since they haven't been initialized yet it tries to read from the registry on its own. For some screwed up reason, it doesn't hang up this time! Of course, since InitiateControllers never finished, this turns into a problem later when you actually open a ROM. Anyway, these two things shouldn't be happening at the same time, so I added a block so they can't. This means that trying to open NRage config in 1964 will now hang until InitiateControllers finishes. So if the config menu doesn't open now, that's why.
Also, 1964 didn't seem to call RomOpen. I don't know if this is because of the hang problems or not.
I've changed the code a bit. It should now fail outright instead of crashing, if there's some problem reading the registry stuff. That is, unless MS has left some more surprises for me. Try running this DEBUG binary and see if it still crashes.
A couple things. lion10, I think you've inadvertently uncovered a threading bug with this plugin while testing under 1964. On your system, the plugin init code is hanging under 1964 while trying to read/process the registry values. However, 1964 must be multithreaded because while that part is hung it's still letting you try to open up the config area. The config area would normally read from the settings in memory, but since they haven't been initialized yet it tries to read from the registry on its own. For some screwed up reason, it doesn't hang up this time! Of course, since InitiateControllers never finished, this turns into a problem later when you actually open a ROM. Anyway, these two things shouldn't be happening at the same time, so I added a block so they can't. This means that trying to open NRage config in 1964 will now hang until InitiateControllers finishes. So if the config menu doesn't open now, that's why.
Also, 1964 didn't seem to call RomOpen. I don't know if this is because of the hang problems or not.
I've changed the code a bit. It should now fail outright instead of crashing, if there's some problem reading the registry stuff. That is, unless MS has left some more surprises for me. Try running this DEBUG binary and see if it still crashes.
Ok, the screenshots are from the previos debug build. The newest one don't crashes anymore, it just creates ini files without an end. :drool: So I had to kill the process... (Due to the large size, I have shorten the ini's at the end.)
OP
rabiddeity
Plugin Hacker
- Thread Starter
- #372
OK, I think that means "invalid pointer" but I'm not sure.
Sorry, the infinite debug file was my mistake, originally I had intended it to loop once and then fail the second time, but I screwed up. D'oh!
The root of the problem is that I'm using a Windows builtin function called "RegEnumValues" which lets me walk through every registry key in a directory. I give it the sizes of my buffers and it returns ERROR_SUCCESS when it finishes. If it returns ERROR_MORE_DATA, it means that the buffers I gave it for registry values were not big enough; the function returns the sizes of the buffers it needs.
This is how things are SUPPOSED to work. However, in the case of Win98, here's what's happening. I pass values of 255 characters and 1024 bytes for the key and value buffer sizes respectively. The function fails with ERROR_MORE_DATA ("I need a bigger buffer!"), and tells me I need buffer sizes of 38 for the key and 144 for the data. :huh: This really has me scratching my head, and I think there's a bug in either the Unicode layer or the Win98 implementation of RegEnumValues. I'm guessing (and hoping) that it's returning the data anyway, so I'm going to proceed to read that data out if my original buffer was big enough.
OK, I'm going to try something rather dangerous and read the registry data regardless of whether I get ERROR_MORE_DATA or not. Theoretically this is undefined behavior, so either it will crash spectacularly or work perfectly. I've also changed some permissions behavior, and asking for full read access for the registry key. Try the latest binary and see what happens.
So pj64 crash on start or on start emulation, if Nrage exist in registry.
(this error?:RegEnumValue is returning ERROR_MORE_DATA but the buffers are big enough. Proceeding anyway.)
If registry not exist, then pj64 run, until I save setting and do run emu again or start emulation. Of course, save create new Nrage in registry.
But setting looks like saved. If I delete Nrage from registry, then run emulation(I dont save setting), then during game emulation load setting and save, then after end emulation, I can see that there is same setting like after saving - setting is there after change state. Ofcourse I cant do nothing(start pj64, start emulation), I must delete nrage to get it working.
Error during crash:
Aplikace PROJECT64 způsobila neplatnost stránky
v modulu NRAGE_DINPUT8_V2_2.00_DEBUG.DLL na adrese 018f:369c1aa1.
(little translation to english:
Aplication PJ64 causing not valid page in modul nrage on adress )
Registr:
EAX=00000037 CS=018f EIP=369c1aa1 EFLGS=00010246
EBX=00000000 SS=0197 ESP=0078af44 EBP=0078ef68
ECX=0000bb40 DS=0197 ESI=0078af44 FS=0fd7
EDX=00000000 ES=0197 EDI=0078ef68 GS=187e
Bytes in CS:EIP:
66 c7 85 f6 1f 00 00 00 00 8b f4 6a 00 6a 00 68
Stack:
0078f81c 0078ef78 cccccccc cccccccc cccccccc cccccccc cccccccc cccccccc cccccccc cccccccc cccccccc cccccccc cccccccc cccccccc cccccccc cccccccc
In 1964 is saving working except modifiers are not saved. Emulation(game) say no controler. No other error in 1964.
(this error?:RegEnumValue is returning ERROR_MORE_DATA but the buffers are big enough. Proceeding anyway.)
If registry not exist, then pj64 run, until I save setting and do run emu again or start emulation. Of course, save create new Nrage in registry.
But setting looks like saved. If I delete Nrage from registry, then run emulation(I dont save setting), then during game emulation load setting and save, then after end emulation, I can see that there is same setting like after saving - setting is there after change state. Ofcourse I cant do nothing(start pj64, start emulation), I must delete nrage to get it working.
Error during crash:
Aplikace PROJECT64 způsobila neplatnost stránky
v modulu NRAGE_DINPUT8_V2_2.00_DEBUG.DLL na adrese 018f:369c1aa1.
(little translation to english:
Aplication PJ64 causing not valid page in modul nrage on adress )
Registr:
EAX=00000037 CS=018f EIP=369c1aa1 EFLGS=00010246
EBX=00000000 SS=0197 ESP=0078af44 EBP=0078ef68
ECX=0000bb40 DS=0197 ESI=0078af44 FS=0fd7
EDX=00000000 ES=0197 EDI=0078ef68 GS=187e
Bytes in CS:EIP:
66 c7 85 f6 1f 00 00 00 00 8b f4 6a 00 6a 00 68
Stack:
0078f81c 0078ef78 cccccccc cccccccc cccccccc cccccccc cccccccc cccccccc cccccccc cccccccc cccccccc cccccccc cccccccc cccccccc cccccccc cccccccc
In 1964 is saving working except modifiers are not saved. Emulation(game) say no controler. No other error in 1964.
I don't know if if this is a well-known symptom, but if I delete the Nrage registry entry, Mupen64 and Project64 starts the first time normally. I can save, load or change configurations. But if I start without “cleaning” the registry a second time, these two emulator crashes. See the gif files for more information.
1964 is much less “delicate”, it starts every time without an error. Only If I load a game, the emulator crashes and freezes the whole system…
Another strange thing is the error entry “couldn't load language DLL, falling back to defaults”. I copied the (German) “NRage-Language-1031.dll” file in every emulator directory (folder) long ago. Why the plugin don’t load the language DLL?
OP
rabiddeity
Plugin Hacker
- Thread Starter
- #375
The last debug has told me where another problem is. Looks like swscanf is overrunning its bounds. Under 1964 it just keeps running for awhile. Under PJ64 it starts reading from memory that doesn't belong to PJ64 and crashes. I'm not sure how that is possible, since I'm telling it exactly how many characters to read, but...
Oh yeah, the code to read shortcuts and modifiers from the registry, those are functions that are similar to the one that reads the buttons. Since I want to focus on one thing at a time, I've disabled those functions in this build. So your modifiers and shortcuts won't load up from registry in this build, even if you've saved them.
I'm going to try one more thing before I completely rip this thing apart. I'm going to zero the memory before reading each time, and see if that fixes it. Also the Debugfile is going to echo the GUID line before it is scanned, so that way if there are any anomalies I'll see them. New DEBUG uploaded.
Right now I'm writing up a format draft for a simple plain ini text file so that if I can't fix this we can just all move on. The hard part is drawing the line between the ini file being human readable and also easy for the plugin to read it (some parts, like the GUIDs, simply will not be human-readable). I estimate that once I have the file format worked out it will take 2 weeks to write, debug, and test. Once it's finished I'll be able to ship out a tool to convert old 2.0 registry format data to the new .ini format. That way I can leave the old registry code out of the plugin and thus save some space, not to mention cut down on the complexity of the code a LOT. Don't worry, I haven't forgotten about ini files.
There is one small problem. Where should the .ini file be written? What should be done if the user doesn't have write permission in the emulator directory? (That was the good part about the registry; every user has access to their own HKEY_LOCAL_USER so there aren't any permissions issues.) I'm partial to the idea of trying to open NRage.ini in the emulator folder first, then if that fails read from somewhere in the user's home folders. When writing the file, first try to write to the user's home folder .ini if that was where the settings were read from; otherwise try them in the order: emulator folder, home folder. What do you guys think?
Oh yeah, the code to read shortcuts and modifiers from the registry, those are functions that are similar to the one that reads the buttons. Since I want to focus on one thing at a time, I've disabled those functions in this build. So your modifiers and shortcuts won't load up from registry in this build, even if you've saved them.
I'm going to try one more thing before I completely rip this thing apart. I'm going to zero the memory before reading each time, and see if that fixes it. Also the Debugfile is going to echo the GUID line before it is scanned, so that way if there are any anomalies I'll see them. New DEBUG uploaded.
Right now I'm writing up a format draft for a simple plain ini text file so that if I can't fix this we can just all move on. The hard part is drawing the line between the ini file being human readable and also easy for the plugin to read it (some parts, like the GUIDs, simply will not be human-readable). I estimate that once I have the file format worked out it will take 2 weeks to write, debug, and test. Once it's finished I'll be able to ship out a tool to convert old 2.0 registry format data to the new .ini format. That way I can leave the old registry code out of the plugin and thus save some space, not to mention cut down on the complexity of the code a LOT. Don't worry, I haven't forgotten about ini files.
There is one small problem. Where should the .ini file be written? What should be done if the user doesn't have write permission in the emulator directory? (That was the good part about the registry; every user has access to their own HKEY_LOCAL_USER so there aren't any permissions issues.) I'm partial to the idea of trying to open NRage.ini in the emulator folder first, then if that fails read from somewhere in the user's home folders. When writing the file, first try to write to the user's home folder .ini if that was where the settings were read from; otherwise try them in the order: emulator folder, home folder. What do you guys think?
Kruci has right, there are no big changes. Only Mupen64 crashs a little bit later... The strange "couldn't load language DLL, falling back to defaults" error message still appear in the debug file.
I think the plugin-directory would be a good place for the ini file, glide64.ini is an example for this.
I think the plugin-directory would be a good place for the ini file, glide64.ini is an example for this.
squall_leonhart
The Great Gunblade Wielder
Rabid Diety, you should have it written to the plugin dir, regardless.
i doubt there are going to be many people who don't have write access to the plugin folder
i doubt there are going to be many people who don't have write access to the plugin folder
OP
rabiddeity
Plugin Hacker
- Thread Starter
- #379
Guys, the Debug files I'm reading right now are from a couple days ago. Did you download the latest DEBUG binary? Timestamp should be 7 Feb 2007, 16:52.
Yes, I have checked it now again. The actual debug build from the first site generates the following timestamp: *** DLL Attach (2.00b-Debugbuild | built on Feb 5 2007 at 15:32:48)