performance cost of sceCtrlReadBufferPositive() ?

[whizz]

Hi guys,

possibly a newbie question - but is there a severe performance cost to
a call to sceCtrlReadBufferPositive(&pad, 1); or to repeat calls to it?

I had an app going easily 60 fps but an extra call to this function slowed it down to 30 fps - even if I disabled a lot of other stuff. It's almost if it forced a wait of a full frame. Any ideas?

Thanks in advance. :)

[rinco]

I found things started to freeze if I polled quicker than 1000usec.
Try to limit polling to 1/60th of a second (~16666usec).

[whizz]

Thanks for confirming this. Still wondering why, as it does seem that there's a delay comparable to forcing an extra 1/60th of a second wait (or waiting for next retrace).

Also slightly paranoid now that even the single call could take half a frame... but don't have profiling code in place to test this in any way.

[chp]

Thanks for confirming this. Still wondering why, as it does seem that there's a delay comparable to forcing an extra 1/60th of a second wait (or waiting for next retrace).

Also slightly paranoid now that even the single call could take half a frame... but don't have profiling code in place to test this in any way.

The problem is probably that the controls cannot be sampled quicker than 1/60th of a second, and if the function detects that it has been called with a shorter interval than this, it stalls until such time has passed.

[jpadams]

try the peek version of the read ?

sceCtrlPeekBufferPositive

worked for me ( i never tested the analog stick with this though )

- j