search

Protofall / Crayon-Game-Framework

My own library for making games on the Dreamcast
BSD 3-Clause "New" or "Revised" License
5 stars 0 forks source link

Crayon/MS: Dropped inputs/vblank detection #104

Open Protofall opened 5 years ago

Protofall commented 5 years ago

This continues off from issues #17 and #32 which were about dropped inputs. The first Issue appeared to be a duplicate/not specific and the 2nd issue was closed before version 1.0.0 of Minesweeper.

Today I tested Minesweeper v1.2.0 in Intermediate mode with a fresh savefile, only options modified being sound and questions off, Controllers A and D plugged in, but only A was active and I was noticing the dropped inputs were back and were very bad. For example placing flags appeared to do nothing at all and a fair few A and X presses failed.

From my tests back in and after issue #32 I identified at least the logic of why it seemed the inputs were dropped. What would happen is sometimes my controller code would start processing the input before the new button inputs were polled. This meant if I released A and the input handling code started before input was polled, then it would start processing as if A was still held, then it would update during processing and at the very end I store the current input as the previous one. Because of this it would skip all the code related to releasing a button.

According to this thread (http://dcemulation.org/phpBB/viewtopic.php?f=29&t=104793), it would seam this is caused because my input handling code starts before the graphics are fully drawn since the input is only polled when a vblank occurs (End of rendering frame). The simplest solution I can think of is to have an extra piece of code before the input handling code and after the rendering code that waits until the vblank occurs. This could impact framerate, but I'd rather have that then dropped inputs.

KOS might already have a function that can do this, if not then I need to make the function myself. Make sure not to busy wait. Maybe sleep/signal? Probably just code the same logic from pvr_wait_ready()

Protofall commented 5 years ago

"pvr_wait_ready() waits until the PVR is ready to accept input, which is roughly a vblank wait" - BlueCrab

So my solution is to move the pvr_wait_ready() to just before the maple loop that way after a pvr_scene_finish() it will wait for the vblank before handling input.

I can't seem to make any builds with the dodgy button presses. Even for the weird_polling_issue branch and the 1.2.0 version...dunno why so for now I'll just assume this fixes it. I'll keep it open for a while now and look out for the bug.

Protofall commented 5 years ago

The above commit should have fixed the issue. I attempted to re-build some older versions with the bug and a modified version with the fix, but in all versions the unpatched cdi didn't have the bug (Tested with weird_polling_issue branch and the branch closest to 1.2.0's release (But it appears I made some changes after the closest commit :/ ). Maybe weird_polling_issue only happened in SD-builds or for some reason its compiled differently? idk.

Leaving open for a while until I'm sure enough the bug is gone.