**DEVS** Solution to double picking problem

[parlance]

Hi,

I am a game programmer and I like FoF, and have just started to get back into it recently and I noticed some problems with double strumming. I did some testing using a prototype program I wrote in Blitz to test out the exact causes of the double strumming / picking problems people have been having.

The root of the problem has been mis-stated many times but to clarify the problem : The root of the problem lies in the fact that Windows MM (the input API used by SDL used by pygame used by FoF) exposes the POV hat as a pollable state rather than an interrupt based button on / off system. What this means is that there is no way to specifically alert the software than the POV hat state has changed, but rather the current state must be requested by the software and the software is responsible for detecting changes in that state.

The FoF software polls the state of the POV hat once per loop which runs at the same frame rate as the graphics, so usually 60 fps. When FoF sees that the last polled state has changed from the previous state, it will count this as a strum (if the new state is up or down).

In fast sequences of alternate strumming it is possible to actually set and unset the POV hat in less than 1/60th of a second (click and unclick the strum bar). In this case that strum would be unregistered because the change in state would occur between 2 calls to the POV state polling function. This is the problem.

A quick software solution would be to seperate the input update routines from the main loop and run them in a seperate thread at a much higher frame rate (I'd suggest even 1000 updates per second, since all this update is doing is calling a small handful of directinput functions this should be completely fine). It would not completely eliminate the missed strum problem but it would highly mitigate it, perhaps by 2 orders of magnitude (if you had 1 strum missed out of 10 in a very fast section, it would then be 1 missed out of 1000, which really isn't bad).

A better solution would be modify SDL, pygame, or FoF to link with a newly created library wrapping DirectInput or Xinput for joystick support because they both support buffered events rather than just pollable states. This would be simple to write, probably not even in excess of 500 lines.

Hopefully this helps.

[omfgdrphl]

You have to be one of the smartest people I've ever met in my life...

[Maze2234]

alarian figured this out, but i never knew it had anything to do with fps

[parlance]

After examining the source code I've more accurately determined what needs to be changed. The pygame.event.pump function handles the bulk of the work in polling input states and detecting changes which are processed and sent to FoF as "events". This function is currently called at the same tick rate as the graphics updates and everything else.

This needs to be changed to a seperate (much much higher) tick rate for input.

This function is called on line 186 of Input.py in the "run" function which then proceeds to process the events. This is the function that needs to called at a higher number of times per second, independent of the ingame frame rate and ticks per second.

alarian figured this out, but i never knew it had anything to do with fps

It doesn't necessarily have anything to do with the in-game frame rate, it is possible to update the input and game logic a independently of the graphics frame rate.

The problem is the frame rate at which input update function is being run is too low to register extremely fast changes in polled device states.

Edit: Do you mean to say alarian has already addressed this or that alarian is aware of it? I'm using the alarian mod and the problem is still present.

Another ammendment:

The need to poll the POV hat state to avoid losing joystick input data can be avoided by using the windows native XInput library which supports buffered events between state requests. Writing a quick wrapper in C or C++ and using it in place of the pygame.event.pump call would be the easiest and most efficient solution, but would only work on windows.

[worldrave]

I'm sensing another member for the team?

[Maze2234]

this has been fixed by xpadder, which you can use to map your keys, but, still the "newbs" dont read stuff, fixing this ingame i beleive is needed, i simply wow over your knowlage, and how you turn somthing so simple into.. that? Amazing brovo, worldrave is right, you ought to start developing with mfh

[aduro]

in game function is needed because external applications shouldn't be necessary

[Maze2234]

what i was trying to get at, thanks aduro,
also you shouldnt triple / double post, just edit your old posts, you will get warned for it

[parlance]

in game function is needed because external applications shouldn't be necessary

I'm aware of the Xpadder "fix". XPadder works because it properly uses DirectInput in buffered mode alleviating the need for fast polling and completely avoiding missing important on / off events.

This is a good example of why it can be a bad idea to rely too heavily on very high level libraries (pygame) to do your dirty work for you, as they often do a lousy or inefficient job.

The other often cited example is the inability to add pitch-shifting whammy-bar effects which would be trivial with an implemention that used SDL or DirectSound natively (custom mixer callback would need to seperate the input audio stream into variable sized (very short, maybe just 32 or 64 samples @ 44100 hz) kernels and re-insert them into them into the output audio stream to cover a larger number of samples, looping the kernel where you have out of range samples. Just as an example if you had a 32 sample kernel looped twice to fill 64 samples, you would effectively half the speed of the audio without altering the frequencies too gravely. A more high quality solution would involve FFTs but considering the very low range required for whammy-bar effects the simple method ought to be sufficient. An FFT based solution (to preserve input frequencies) would be desirable for something like training speeds at 50%.

[raynebc]

If FoF became multi-threaded, I'm sure many possibilities would open. It would, for one, prevent CPU core choke on hyper-threading processors. And the OS could handle some of the code that repeats on a timed interval, reducing the workload of the application.

[iamnoob]

I think we have found alarian's father

[rednano12]

My brain just exploded from sheer awesomeness.

[Death Legion]

My brain just exploded from sheer awesomeness.

WTF? Only Jurgen plays at 4-billion-notes-per-second, this guy can't explodes your head too... Look at me, I'm gonna read his post and you'll se... *BRAAOOOM*


Seriously, I can't understand how people who come from nowhere start to post smarts things like this... You know, we had UC, then Alarian and MFH, now this guy... XD

Just read man, it's brilliant. If this work, we shouldn't have more problems of noobs who don't want to read and learn that if they only used Xpadder...

[Your Mighty Ruler guy]

oooooowwwwwwwwwwwwww! My brain hurts! Use little words!

Just Kidding... sorta.

But, I don't have problems double-strumming/picking, why fix something that ain't broken? Me no understand! Too many words!

[parlance]

oooooowwwwwwwwwwwwww! My brain hurts! Use little words!

Just Kidding... sorta.

But, I don't have problems double-strumming/picking, why fix something that ain't broken? Me no understand! Too many words!

The problem is only observable in fast sections of a song with many strummed notes in a row (think Dragonforce).

In a rhythm game making sure the input is as fluid and responsive as possible in any situation should be the number one priority as it highly affects playability.

If nobody moves on this by later tonight I'm going to move on this myself and compile a modified version of SDL 1.2.13 linked with XInput (DirectX9) which should resolve the problem without having to modify any FoF or pygame code. You should be able to just drop the new SDL.dll in the application folder (folder containing FoF.exe) and it should correct the problem.