What's new

Rewriting N-Rage DirectInput8 Transfer Pak

Status
Not open for further replies.

Doomulation

?????????????????????????
All I did actually was a very simple hack.
In the DirectInput.cpp file, there's a function called by the emulator over and over to return the pressed keys I think (can't remember what it was called though). In here, I found where it returned the keys and added this:

Code:
static int iCallTimes = 0;
if (i == 4)
{
...
i = 0;
}
i++;

Note that the same goes for both rapid fire and toggle.
I don't have the source at hand right now, so that's all I can tell you now, sorry. There also seems to be a bug (at least for me) that makes it "forget" you've pushed a macro. It does detect it at times also, but seems to do nothing.
I haven't found the clue to that, but I'm going to hunt it down (unless you do before me) as soon as I get home and get to the source.

Hope it works out well!
 
OP
MadManMarkAu

MadManMarkAu

Transfer Pak Expert
Oh yeah, I see. I found the bit. I'm not too good at forms in C, but I'll try to put an updown control there with rapid fire values. Hehe, this is unexplored territory, here... I know nothing about most of N-Rage's section of the code, but I'll give it a go.

I'm going to add 2 variables to the CONTROLLER struct, bRapidFireEnabled and iRapidFireRate
 
Last edited:
OP
MadManMarkAu

MadManMarkAu

Transfer Pak Expert
OK, doomulation, I've added an optional and adjustable Rapid Fire to the plugin.

This is the BETA version... If all goes well, and no problems arize, it will also be the final version. Now, I just have to get N-Rage to update his site.

EDIT: Attachments removed to avoid non-release version downloads. Release version is at http://www.emutalk.net/showthread.php?p=250382#post250382
 
Last edited:

Doomulation

?????????????????????????
I can't see how it works, or how it looks since the links doesn't work.
Won't you attach them to the forum instead? I got a webspace if you want to upload them elsewhere, since your space doesn't seem to work.
Don't worry 'bout n-rage, though. He seems to be around.
 
OP
MadManMarkAu

MadManMarkAu

Transfer Pak Expert
ok, FINALLY, the plugin is downloadable, I need people to BETA test it... and I mean BETA test it! Flog the hell out of it! I need to know where all the bugs are, particulatly with the RTC.

By the way, GBA roms won't work with it. So don't try :)

Also, save state files don't work with it. *refuses to point fingers* :whistling:
 
Last edited:

ggab

Emutalk Member
I've added an optional and adjustable Rapid Fire to the plugin.
it's too fast. when i set to 0 (minimun) is fastest than setting to FULL.
can u decrease the latency? i think, the lower option should be like 1 Hz (press the botton, once a second), setting to 2, 2Hz, 3 with 3Hz... etc.


very good testing game :D Sin and Punishment - Tsumi To Batsu (J)
 
OP
MadManMarkAu

MadManMarkAu

Transfer Pak Expert
ok, about the speed, I've just extended the range on the slider control. How the autofire works is, it cuts out the A, B and Z-trigger buttons once every n reads, where n is the value of the slider from 2 to 21, counting from right to left. I won't release the plugin with this fix until some more bugs have been sorted, so I'm afraide you'll have to live with it for the moment.
 

Doomulation

?????????????????????????
Ahhh, this sounds nice. I don't really get how it works, though. Has anyonye tested if these slower requiring functions fares now? I will test later, of course.
Has anyone noticed the bug when it forgets that you pressed a macro, btw?

MadMan, I can still upload your files on my site if you NEED. Great work :)
 
OP
MadManMarkAu

MadManMarkAu

Transfer Pak Expert
ok, in what way does it "forget" ou pressed it. Give me an example and I'll know what to look out for.
 

Doomulation

?????????????????????????
Right. It detects it, but no rapid fire. This I've detected that the toggle check is checked in the input config, yet no rapid fire is applied.
That's what it's about.

EDIT: The second problem seemed to be due to my debug mode with pj.
I also found a little of the working of rapid fire. First time it detects you pressed it, it should check the axises and set an appropriate variable. Then, almost last down in the function, it will be converted to absolute axis and sent back to the emulator.

Here's code snippets:
Code:
			if( fChangeMod )
			{
				switch( pcController->pModifiers[i].bTyp )
				{
				case MDT_MOVE:
				{
					LPMODSPEC_MOVE args = (LPMODSPEC_MOVE)&pcController->pModifiers[i].dwSpecific;
					d_ModifierX *= args->XModification / 100.0f;
					d_ModifierY *= args->YModification / 100.0f;	
				}
					break;
				case MDT_MACRO:
				{
					// Executes first time. Second time it won't (pcController->pModifiers[i].fSHandling will be set. Usually to 0x02). Third time it sets fPrevFireState to 0 (I think! Don't know if it's the third time.)
					LPMODSPEC_MACRO args = (LPMODSPEC_MACRO)&pcController->pModifiers[i].dwSpecific;
					if( !args->fRapidFire || !args->fPrevFireState  || ( b_Value && !btnButton.fPrevPressed))	// Wasnt firing previous round or new command
					{
						w_Buttons |= args->aButtons;
						if( args->fAnalogRight )
							lAxisValueX += MAXAXISVALUE;
						else if( args->fAnalogLeft )
							lAxisValueX -= MAXAXISVALUE;

						if( args->fAnalogDown )
							lAxisValueY -= MAXAXISVALUE;
						else if( args->fAnalogUp ) // up
								lAxisValueY += MAXAXISVALUE;

						args->fPrevFireState = 1;
					}
					else
						args->fPrevFireState = 0;
				}
					break;

At the end:
Code:
	// Seems to forget this snippet too sometimes. Happend once, so far. But this isn't the problem.
	if( pcController->fRealN64Range && ( lAxisValueX || lAxisValueY ))
	{
		LONG lAbsoluteX = ( lAxisValueX > 0 ) ? lAxisValueX : -lAxisValueX;
		LONG lAbsoluteY = ( lAxisValueY > 0 ) ? lAxisValueY : -lAxisValueY;

		LONG lRangeX;
		LONG lRangeY;

		if(	lAbsoluteX > lAbsoluteY )
		{
			lRangeX = MAXAXISVALUE;
			lRangeY = lRangeX * lAbsoluteY / lAbsoluteX;
		}
		else
		{
			lRangeY = MAXAXISVALUE;
			lRangeX = lRangeY * lAbsoluteX / lAbsoluteY;
		}

		float fRangeDiagonal = (float)lRangeX * (float)lRangeX + (float)lRangeY * (float)lRangeY;
		__asm{
			fld fRangeDiagonal
			fsqrt
			fstp fRangeDiagonal
			fwait
		}
		float fRel = (float)MAXAXISVALUE / (float)fRangeDiagonal;

		*pdwData = MAKELONG(w_Buttons,
							MAKEWORD(	(BYTE)(min( max( MINAXISVALUE, (LONG)(lAxisValueX * d_ModifierX * fRel )), MAXAXISVALUE) / N64DIVIDER ),
										(BYTE)(min( max( MINAXISVALUE, (LONG)(lAxisValueY * d_ModifierY * fRel )), MAXAXISVALUE) / N64DIVIDER )));
	}

Also, the whole pcController struct seems connected to i. If you change a value in i, this whole struct changes (at least pcController->pModifiers). Don't know if this is a bug!

I'm far from having solved the problem, though. I still know nothing!

EDIT2: It seems there is a way to avoid this bug. Each time you start the emulator, goto controller config, modifiers tab. There you should check toggle button and uncheck it (the one beside it, which determines if it's activated or not). Then click apply and save. It will work for a while. But it might stop working after a while, and if it does, then repeat the process. Sometimes it also seems to help enabling the modifier and re-loading a state to activate it. Rapid fire alone (not toggle) doesn't seem to work either...

Still no clue why, though.
 
Last edited:
OP
MadManMarkAu

MadManMarkAu

Transfer Pak Expert
Hmm... To be honnest, this is not my bug. But, give me a couple of days, and I'll see what I can do. I'm going to have to learn all about N-Rage's code, which I was hoping to avoid. ;)
 
Status
Not open for further replies.

Top