Rewriting N-Rage DirectInput8 Transfer Pak

[Knuckles]

it worked each and every times here (except the first one) (links)

[gandalf]

Well, i download it...i post the file attached(zipped it)

[MadManMarkAu]

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* :

[ggab]

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 Sin and Punishment - Tsumi To Batsu (J)

[retroK]

Thanks, the downloads work now.

[MadManMarkAu]

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

[MadManMarkAu]

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:

			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:

	// 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.

[MadManMarkAu]

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.