Page 1 of 1

Controller refuses to vibrate

Posted: May 1st, 2020, 7:32 am
by Jaberwocky
Hey everyone :D

Yeees I have another question again and yeeeeeeees I have no idea why it is not behaving.
I have a DualShock controller being in the "digital mode" and I want to make actuators to well uhh vibrate? So I followed some example code I found in the PSYQ folders.

When starting my game I setup the controller something like that:

Code: Select all

u_char vibration[2] = {0};

void setup()
{
	PadInitDirect(this->portData[toPortIDX(Direct::Port0)].rawData, this->portData[toPortIDX(Direct::Port1)].rawData);
	PadSetAct((int)Direct::Port0, vibration, sizeof(vibration));

	PadStartCom();
}
For every frame I will call PadGetState on Port 0 and process what I get. At boot up the controller is already connected so I directly land in "PadStateStable" at this point I have not called any thing else, so I will execute:

Code: Select all

u_char ActuatorAlign[6] = {0x0, 0x1, 0xFF, 0xFF, 0xFF, 0xFF};
PadSetActAlign((int)Direct::Port0, ActuatorAlign);
When PadSetActAlign returns 1 I will set a flag to not call this function again and I set vibrate[0] and [1] to 0xF0. From this point two things can happen:
1.) If I go directly into an endless loop, then the controller will vibrate happily.
2.) If I don't do that - then PadGetState will tell me for the next 3 frames "PadStateReqInfo" until it goes to "PadStateStable". However, it will not vibrate then!

I made sure that PadSetActAlign returns true... If I place my endless loop in "PadStateReqInfo" then it will also not vibrate. If I always call "PadSetActAlign" when being in the stable state, then it will fail, go back to the requeststate - and well it will loop.
This is so weird oO To me it sounds like I'm not allowed to get into the "PadStateReqInfo" state.

I hope anyone can help me with that, cause I believe I do the same like in the example... And I mean.... It does vibrate with the endless loop... But that would be a boring game xD

Re: Controller refuses to vibrate

Posted: May 1st, 2020, 10:13 am
by Administrator
Put the vibration in a callback so you don't need to do it in the loop and wait for it to complete.

Re: Controller refuses to vibrate

Posted: May 2nd, 2020, 2:37 am
by Jaberwocky
Thank you for the answer - sadly I did not fully understand it...

Which callback do you mean? What do I have to check for complition?

By now I changed my code to this:

Code: Select all

bool setupVibration()
{
	u_char ActuatorAlign[] = {0x0, 0x1, 0xFF, 0xFF, 0xFF, 0xFF};

	if(PadInfoMode(this->port,InfoModeCurExID,0))
	{
		while(PadSetActAlign(this->port, ActuatorAlign) == 0)
		{
			// Failed To Load Actuator, wait a bit
			for(int ctr=0; ctr<6; ctr++)
				VSync(0);
		}
		return true;
	}
	return false;
}
Which sadly didn't changed a thing - after the call I will go into the "PadStateReqInfo" state again and I will be screwed.

However... I did the following - after calling the above code I added:

Code: Select all

for(int ctr=0; ctr<3; ctr++)
	VSync(0);
Then everything works fine! But why the fox does it?
Am I supposed to call NOTHING after I called PadSetActAlign for 3 Frames? Or only certain functions? I still don't get what the problem the controller has with me .w."

Edit: I also call now the controller code from my render routine before I execute DrawSync(0); and VSync(0);

Re: Controller refuses to vibrate

Posted: May 2nd, 2020, 6:33 am
by Administrator
You need to wait some time for the controller to stabilise so VSync's are required. Check a few Sony examples. You'll see the timing is somewhat critical on some function calls.

Re: Controller refuses to vibrate

Posted: May 2nd, 2020, 8:03 pm
by Jaberwocky
I did looked into the examples of Sony but they never have a forced wait of 3 frames...
I will try making a minimal programm now for just making the controller vibrate...

Edit: Seems like this is really a timing issue - if I add printf statements in my striped down code, it will not vibrate unless I do the 3 frame wait thingy.

However... adding the controller handling to the VBlank Callback is indeed the best way of solving this! I get it to work from there all the time...