forums.ps2dev.org

[willow :--)]

I have two questions regarding the following function call

[hibbyware]

This is taken from the pspsdk docs,

Controller Kernel Library

[Torch]

It probably lets you read values between the last sceCtrlReadBuffer and the present value if sceCtrlReadBuffer is being called less than 60 times a second. From what ive seen syscon always sends button state packets 60 times a second.

[willow :--)]

@hibbyware:

Thanks. Actually I did read the docs, and search the net, but didn't get a real answer.
Count is number of buffers to read, sure, but my question is, why is there several of them ? If I pass 2, and I get 2, what is the meaning of the second one ?

Does it depend on sceCtrlSetSamplingMode ? I mean, the analog stick probably won't give off events, it has to be polled, that makes sense. However, polling the digital controller makes little sense - it can be done, and it works, but makes for a cranky input.

Here is what I can suppose :
- Is there *exactly* a buffer to read for each sample cycle (according to the setting given by sceCtrlSetSamplingCycle(int cycle)) ?
- Is there a buffer to read each time there is something happening on the controller ?
- Is there a buffer for each cycle PLUS one buffer each time something happens on the controller ?
- Does the behaviour alternates between first and second possibility depending on sceCtrlSetSamplingMode ?

This is what I wanted to know, and haven't been able to find either in the docs or on the net. Sorry for the not very explicit question.

[Torch]

I've used the Syscon hook sample where you receive every packet sent from the Syscon. You have to check some bits to identify which kind of packet it is, such as ctrl pad data using a simple switch-case.

In my app, the ctrl pad case gets executed 60 times a second always, even if you change the sampling cycle. In fact I'm using the incoming ctrl pad packets as a timer accurate to 1/60 of a second for other things in my app!!

The sampling mode invokes a hardware change. You get a different value in the Syscon packet identifier if analog is enabled. But the remaining format is exactly the same. In digital mode, the analog x & y is zero.

I have not experimented with different values of count, but I know this, suppose sceCtrlReadBuffer is not executed for some time, then sceCtrlPeekBuffer stops working after you have called it some amount of times, until you call sceCtrlReadBuffer again.

Try this experiment. Create an EBOOT and set a slow sampling rate like 1 second or something with a long delay thread. Then press some buttons and use PeekBuffer with different count values. See what pad_data you get for each count value. Don't use read buffer.

[willow :--)]

Thanks, I'll give it a try