What's new

NRage Input Plugin V2.00 BETA (an overhaul)

squall_leonhart

The Great Gunblade Wielder
rotate the thumbstick along the edge,.. this will set the max axis depth,..

release the thumbstick when you do this so it can reset to the neutral position then press a button.
 

ryne

New member
Found the problem.

Don't use third party controllers from eBay. They suck.

1st party Sony controller is the way to go ;)
 
OP
R

rabiddeity

Plugin Hacker
exactly right. there is a calibrate button on it (using a mayflash pro 5 adapter), but i'm not sure if it is working.

btw, it takes only 1/2 the way for the peg to reach all the way across.

It doesn't seem like this can be fixed by calibration. I guess I need to give a bit of explanation on how joystick values work under DirectInput.

Physical joysticks are not perfect devices. Historically, analog joysticks measured variable resistors and springs; both of these change properties with temperature. These days, most joysticks use lasers and optical sensors. But Windows still needs a way to translate the raw data coming in from the controller into a "position" value it can send to games. DirectInput does a bit of preprocessing on the values, perhaps a bit too much in some cases. Windows maintains a "center point" for each joystick axis, as well as saturation boundaries for how far it thinks you should be able to push in each direction. It also measures "jitter" at the center point (random noise when you're not moving the joystick) and sets what's called a "deadzone". This is not the same deadzone that is set in NRage. Any movement within this deadzone registers as no movement. Deadzone is set to keep your character from making erratic movements when you're not moving the joystick at all, and the saturation boundary ensures that a game will read the stick as being fully pressed when it actually is. This information is reset when you first plug in a USB controller, or press "Calibration" in the control panel. The problem you're having (and a common one) is that Windows is setting the bounds for each axis too small. This means that the axis will saturate too quickly-- in other words, pushing the stick halfway results in DirectInput reporting full tilt.

On the original N64, the controllers of course had some jitter-- but they all used the same optical sensor-- meaning all N64 controllers had almost identical range of motion, and were guaranteed to jitter less than a certain amount. This meant that a center point could be set when the console was powered up or a new controller plugged in, and no other calibration had to be done. All games used some sort of fixed deadzone (around 5% probably) and all knew exactly how far the joystick could be pushed in any direction (the saturation point).

To make this a bit more clear, here's the processing for the original N64 with controller:

N64 raw data-->ingame processing-->movement

Now here's how the emulated DirectInput version works:

PC controller/driver raw data-->DirectInput processing-->(NRage turns that into fake N64 raw data)-->ingame processing-->movement

NRage reads the processed (calibrated) DirectInput values from your joystick. There are ways to read the raw uncalibrated values, but I would have to write calibration routines (and you would have to calibrate your controller each time you ran your N64 emulator). In other words, that's not really doable. But there may be a way to set the saturation level of the DirectInput processing, if it's manually set too low. That way, it wouldn't saturate too early. I'll add some stuff in the debug version to see if I can get some useful information about what values DirectInput is setting for saturation and deadzone. Maybe your driver is setting it too low, and maybe there's a fix.

Sorry, that was a long post.

edit: I'll look for a fix anyway. You never know, maybe we can get a bit better performance out of it.
 

Kruci

New member
Just curious, but what language version of Windows are you using?
Czech lang

Microsoft Layer for Unicode
I had same unicows.dll, but I didnt have unicows.pdb(useless?)

your using the latest Dx version right?
9.0c(but not latest build)

Amazing:) I can play with debug plugin, about have not weird chars(normal version still have).
Transfer Pack and MemPack crashes, transfer pack after a while after runing pokemon stadium2, MemPack after selecting save game(in game, blast corps) from mempack.
Rumble pack seems working. Voice pack useless?
Game pad, keys and mouse work fine(I test key_mouse.cpf).
Plugin always forgot button setting(all change to unassigned after startin emulation), devices have no longer gamepad setting?, setting of Packs is not lost after starting emulation.
Loading of setting from file works fine.

NRage-Debug.zip - 5 files, one testing few games, setting, packs, others just one game, one pack(name NRage-Debug_USEDPACK_GAME_CRASHorOK).
Crash is error message like, program make something unexpecting in program pj64, in dll NRage.
 

xorxif

New member
Well I dunno about the rest of you, but me running the USA version of Win98SE, the new version WORKS!!

Many thanks to rabiddeity for fixing the problem. I didn't even need to install the new version of unicows, although I do appreciate the link to it since I know at some point or another I will need it, so I downloaded it anyway.

I'll be looking forward to when you release the non-debug build. Until then I find the nrage-debug.txt fascinating...

For your reference here's the relevant lines:

*** DLL Attach (2.00b-Debugbuild | built on Nov 15 2006 at 09:07:37)
Autoselect language: 1033
couldn't load language DLL, falling back to defaults
*** DLL Detach
---DEBUG FILE CLOSED---
*** DLL Attach (2.00b-Debugbuild | built on Nov 15 2006 at 09:07:37)
Autoselect language: 1033
couldn't load language DLL, falling back to defaults
Initiating controllers...
 
OP
R

rabiddeity

Plugin Hacker
Kruci said:
I had same unicows.dll, but I didnt have unicows.pdb(useless?)

Yes, that's right. The pdb file is only for people compiling programs. You can delete it.

Amazing:) I can play with debug plugin, about have not weird chars(normal version still have).
Transfer Pack and MemPack crashes, transfer pack after a while after runing pokemon stadium2, MemPack after selecting save game(in game, blast corps) from mempack.
Rumble pack seems working. Voice pack useless?
Game pad, keys and mouse work fine(I test key_mouse.cpf).
Plugin always forgot button setting(all change to unassigned after startin emulation), devices have no longer gamepad setting?, setting of Packs is not lost after starting emulation.
Loading of setting from file works fine.

NRage-Debug.zip - 5 files, one testing few games, setting, packs, others just one game, one pack(name NRage-Debug_USEDPACK_GAME_CRASHorOK).
Crash is error message like, program make something unexpecting in program pj64, in dll NRage.

Voice pak support has never worked.

I have a feeling the other problems are Win98 related, with the automatic Unicode to ANSI conversions. This might be the same reason your controller settings are not being saved.

You say that loading settings from file works OK. How about Save Profile?

For Mempak file, try creating two new memory pak files. For the first one, use a Czech file name. For the second one use just English letters (with no Czech letters in the directory name either). Try each one and see which ones crash. This will help me figure out whether it's a general Win98 problem or a Win98 international problem. Don't worry, I'll fix it either way!

I will ask you to try one other thing. After you click "Save" in the control panel, please run "regedit". Go to the following registry value:
HKEY_CURRENT_USER\Software\NRage\DX8InputPlugin200
There is a folder under this called "Controls". Please export this folder to a file (right click it, should be one of the options near the bottom) and then post this file to the list. This will tell me whether the problem is with saving settings or loading settings.
 

Kruci

New member
I have a feeling the other problems are Win98 related, with the automatic Unicode to ANSI conversions.
I have a feeling the all problems are Win98 related:) I wonder why win2k/XP programs are not runing on win9x(except function dependency). New .exe structure? Some "we do not support old verison" from microsoft? Something just for win2k/XP?

You say that loading settings from file works OK. How about Save Profile?
Save and load work fine(control, shortcut)

For Mempak file, try creating two new memory pak files.
Both memory pack files crash(both works until crash). If I quick enough, I can work with mem pack file, it crash for "looks like same amount of time(~2 second) after searching controler pack, dont care about work with mempack(just looking on saves, or choosing saves, or creating new saves)"

At mempack options, windows Yes/No of Format mempak, Delete note, Delete memPack are emty, have no text, buttons have no text too, but if I click, text appears(just on button).

HKEY_CURRENT_USER\Software\NRage\DX8InputPlugin200\Controls
(same error with modifiers, shortCuts)
First time was empty, but I maybe did save on emty controls. If I load my saved setting, controls contain this.
[HKEY_CURRENT_USER\Software\NRage\DX8InputPlugin200\Controls]
"{D489AE00-DEC4-11DA-8001-444553540000}"=hex:00,00,00,00,00,08,01,03,04,00,00,\
00,00,08,03,03,08,00,00,00,00,08,02,03,0c,00,00,00,00,08,00,03,10,00,00,00,\
00,08,00,01,14,00,00,00,00,09,00,01,18,00,00,00,00,00,00,01,1c,00,00,00,00,\
02,00,01,20,00,00,00,00,05,00,01,24,00,00,00,00,01,00,01,28,00,00,00,00,03,\
00,01,2c,00,00,00,00,04,00,01,30,00,00,00,00,07,00,01,34,00,00,00,00,06,00,\
01,38,00,00,00,00,00,00,02,3c,00,00,00,00,00,01,02,40,00,00,00,00,01,00,02,\
44,00,00,00,00,01,01,02

This is there if I shutdown/starting emulator, or starting emulation, but is not set in configuration of nrage plugin, change of state do empty setting, but if I dont do change - set - SAVE - look again(setting still there) - samething change - SAVE - still there - STARTING/ENDING EMULATION/NEW START OF EMULATOR/... - setting is empty

Transfer Pack crash about 2second after start emulation.
 
OP
R

rabiddeity

Plugin Hacker
Okay. Settings are loaded fresh from the registry when you start the emulator AND when you start up a ROM (because Project64 reinitializes plugins just before emulation starts). I do a string comparison to read in the GUID values (the whole {D489AE00-DEC4-11DA-8001-444553540000} thing) and so there's a glitch in the codepage or my parsing code. Since I don't have a copy of Czech Win98 handy, I have to add in some more debug code to figure out exactly which line the problem is happening. Delete your NRage-Debug.txt, download the newest DEBUG version and let's see if we can figure this out.

I also want you to post a copy of one of your saved profiles so I can make sure it's saving the directory information OK.

The issue is basically this: Win95/98/ME use 1 byte per character internally. This was okay for English versions of Windows but it got really confusing when they started releasing international versions; under this system the same representation might be used for English and Cyrillic alphabets for example, depending on the language version of Windows. Even worse, 1 character in Chinese or Japanese might use 2 or 3 bytes, so it was very difficult to determine how many characters a string had. Different versions of Windows had different "codepages", or tables that said for a specific language what bytes represent what characters. Accidentally using an English capitalization function on Cyrillic or Chinese data would corrupt that data and usually crash your program. It was a nightmare for people writing international projects.

With WinNT/2000/XP, Microsoft switched to 2-byte Unicode internally. Every character has exactly one representation with no duplication. It's really nice, because it means that assuming I have the right fonts, I can write out a string with combinations of, say, French and Russian and Korean all in the same string, without worrying about what language they're in, and the characters will show up correctly.

With 2.00 I switched all internal strings and function calls to Unicode (except debug strings which are static). The "Microsoft Layer for Unicode" is a driver that translates the Unicode calls to and from the local code page. It does an OK job most of the time... but I guess there are still problems with filenames and some other issues. The default ASCII and Czech codepages are very different. From what I can see, the default base Czech codepages don't seem to have the characters { and } because they are replaced with other characters. (These are used in WinNT and later to mark the ends of global identifiers or GUID for devices.) My guess is for filenames a critical character like \ isn't being translated properly. This would mess things up a lot.
 

Kruci

New member
All looks same(empty setting after state change).

Thanks for explaining problem.

I dont use czech chars in filenames and I use default english keyboard(czech keyboard dont have same "needed" keys)

If are troubles with czech windows too big, so don care, I can live without this nice plugin:)
 

arnon81

New member
how to move forward in goldeneye

how to move forward in goldeneye?
I can do it a little bit by moving my mouse forward bit by bit which isn't comfortable...
is there other easy way to move forward?
I'm using the key profile from this thread on the first page

thank you
 
OP
R

rabiddeity

Plugin Hacker
All looks same(empty setting after state change).

Thanks for explaining problem.

I dont use czech chars in filenames and I use default english keyboard(czech keyboard dont have same "needed" keys)

If are troubles with czech windows too big, so don care, I can live without this nice plugin:)

Erm, sorry, those text files are from an older version... I added a few things to make it easier to find out exactly what's going wrong.

I think I fixed several issues anyway. I noticed that it crashes whenever it tries to write back to the mempak or to the transfer pak ram file. This was due to a mistake on my part. I think I've fixed it; please download the newest DEBUG version and try it out.

I'm still working on the registry problem that causes it to clear your settings, though it's possible that it was caused by my previous mistake, which was overwriting config memory (!) Anyway, try it and see if it still breaks.

how to move forward in goldeneye?
I can do it a little bit by moving my mouse forward bit by bit which isn't comfortable...
is there other easy way to move forward?
I'm using the key profile from this thread on the first page

Start a mission and go into the ingame pause screen (use Enter). Use the arrow keys to move around the menus (they're bound to the control pad) and click the mouse button to set things. You could add a macro that binds the spacebar to the A button to make this easier, but it's not in the default cpf file. Set your control type to "1.2 Honey" (it's under the 3rd config area, the one that shows the picture of the N64 controller). You may also want to toggle the "Look up/down" to "Upright" unless you like reverse-mouse. Finally, go into the NRage config menu and adjust your mouse sensitivity down a bit. I play with mine about 85% for both, but the axes are individually adjustable in case you want to tweak it a bit.
 
Last edited by a moderator:
OP
R

rabiddeity

Plugin Hacker
I thought it, its looked as old version, but if I downloaded debug plugin again, I already had same dll.

No change, same troubles.

Almost there. I fixed a null pointer reference. Try it again now (build timestamp should be 8:17am, 21 November 2006).
 

arnon81

New member
rabiddeity,
my c buttons is bound to WSAD, but W makes jamesbond looking up to the sky instead of moving forward...

rabiddeity,
oh sorry I didn't setup the controller in goldeneye to 1.2 solitaire
1.2 solitaire makes WSAD works to move around
thank you

I like playing goldeneye in a small screen (not full screen), but clicking the mouse when its cursor goes out of the goldeneye window make goldeneye paused by itself, how can I keep my mouse cursor inside the goldeneye window?
thank you
 
Last edited by a moderator:
OP
R

rabiddeity

Plugin Hacker
Unfortunately this is a limitation in how Windows handles the mouse, and it's something I can't fix. Theoretically when an application locks the mouse for exclusive access the cursor should disappear, but it doesn't. Sometimes pressing TAB once or twice can "re-lock" the mouse (the lock/unlock mouse bind in the Shortcuts menu if you haven't changed it). Project 64 has an option to "Pause emulation when screen is not active", and you can toggle that... but you might find that stray clicks outside the PJ64 window will activate menus and such; if that happens press TAB once to lock the mouse. Press TAB once more to unlock it so you can access menus (to quit the game and such). You should also memorize the key for your emulator that ends emulation, in case you have trouble getting control of the mouse back. For PJ64 it's "F12".

If that doesn't work, the only other solution is to play in full screen mode.
 

Kruci

New member
Almost there. I fixed a null pointer reference.
Transfer pack and mempack works now. Setting of buttons is still lost after change.

RomID and description are always empty, are they useful or error on my side?

NRage-Debug.txt, using 7z for less size (4MB unpacked)
 
Last edited:

guille007

New member
hello, first thanks for this excellent plugin and pardon-me by English poor me :p
and second I would like to help with the development of plugin;
I was verifying the operation of the TransferPak and found the following thing.

please correct-me if I am mistaken. :p
Code:
bool WriteCartMBC5(LPGBCART Cart, WORD dwAddress, BYTE *Data) {
.............
	else if ((dwAddress >= 0x2000) && (dwAddress <= 0x2FFF)) { // ROM bank select, low bits
		Cart->iCurrentRomBankNo &= 0xF0;
		Cart->iCurrentRomBankNo |= Data[0];
		// Cart->iCurrentRomBankNo = ((int) Data[0]) | (Cart->iCurrentRomBankNo & 0x100);
		DebugWriteA("Set ROM Bank: %02X\n", Cart->iCurrentRomBankNo);
	}
	else if ((dwAddress >= 0x3000) && (dwAddress <= 0x3FFF)) { // ROM bank select, high bit
		Cart->iCurrentRomBankNo &= 0x0F;
		Cart->iCurrentRomBankNo |= (Data[0] | 0x01) << 8;
		// Cart->iCurrentRomBankNo = (Cart->iCurrentRomBankNo & 0xFF) | ((((int) Data[0]) & 1) * 0x100);
		DebugWriteA("Set ROM Bank: %02X\n", Cart->iCurrentRomBankNo);
	}
...........................
it would have to be.
Code:
bool WriteCartMBC5(LPGBCART Cart, WORD dwAddress, BYTE *Data) {
    .........
	else if ((dwAddress >= 0x2000) && (dwAddress <= 0x2FFF)) { // ROM bank select, low bits
		Cart->iCurrentRomBankNo &= [COLOR="Red"]0xFF00;     [/COLOR]
		Cart->iCurrentRomBankNo |= Data[0];
		DebugWriteA("Set ROM Bank: %02X\n", Cart->iCurrentRomBankNo);
	}
	else if ((dwAddress >= 0x3000) && (dwAddress <= 0x3FFF)) { // ROM bank select, high bit
		Cart->iCurrentRomBankNo &= [COLOR="Red"] 0x00FF; [/COLOR]
		Cart->iCurrentRomBankNo |= (Data[0] [COLOR="Red"] & [/COLOR] 0x01) << 8;
		DebugWriteA("Set ROM Bank: %02X\n", Cart->iCurrentRomBankNo);
	}
...........

this makes possible the load of the Pokemon Yellow (mbc5) in GameboyTower;
yes, I already know that it does not work in gameboyTower but I have hopes that this will work someday. In addition it seems that the problem is in the emulator and not in the plugin, since pokemon stadiun verifies the data with some type of checksum. pokemon Stadiun 1 does by each bank that it loads, and the Pokemon Stadiun 2 does with the complete ROM (max load). that seems at least

another well-known problem that found is this.
Code:
bool WriteCartMBC3(LPGBCART Cart, WORD dwAddress, BYTE *Data) {
.................
	else if ((dwAddress >= 0x2000) && (dwAddress <= 0x3FFF)) { // ROM bank select
		Cart->iCurrentRomBankNo = Data[0] & [COLOR="Red"]0x3F;[/COLOR] // HACK: should be "& 0x7F" according to spec, removed this hack for now --rabid
		[COLOR="Red"]if (Cart->iCurrentRomBankNo == 0) {
			Cart->iCurrentRomBankNo = 1;
		}[/COLOR]
		DebugWriteA("Set Rom Bank: %02X\n", Cart->iCurrentRomBankNo);
	}
.................
yes, it must be 0x7F to load the Pokemon Crystal (mbc3) in PokemonStadium2 (max load) and the “if” is not needed;

at this moment I am trying to see that it happens with mbc1,
since the Pocket Monster Green (j) does not work the SAVE, nor the ROM in
the Pocket Monster Stadiun 2 (j)

The "IF" code is necessary, I had not seen that part of the specifications of MBC :p
SORRY :plain:
 
Last edited by a moderator:

Top