Extending use of the Pandora-Key


We could pause the currently running apps with



Code:
kill -STOP <pid of foregroundprocess>.
That doesn't prevent most programs from processing keypresses though. The OS will continue to buffer keyboard events while the input file is still open. When you SIGCONT the program, it reads in all the buffered inputs. There is a solution that Notaz helped find.





Theoretically we could get the pid by first issuing



Code:
 xdotool getwindowfocus

which gives us the windowid of the process, that has the focus currently or
Fullscreen SDL applications don't have a window, they draw directly on the frame buffer. Getting the currently active application (and in fact all running PNDs) is a problem solved some time ago. :p
 
We could pause the currently running apps with



Code:
kill -STOP <pid of foregroundprocess>.
That doesn't prevent most programs from processing keypresses though. The OS will continue to buffer keyboard events while the input file is still open. When you SIGCONT the program, it reads in all the buffered inputs. There is a solution that Notaz helped find.
Seems to me this would also cause a massive "jump" in games that use delta timing. Am I right, or is there a solution for that, or is my guess just wrong?
 
Last edited by a moderator:
Seems to me this would also cause a massive "jump" in games that use delta timing.
Nothing that I've tested it with, but that's hardly exhaustive.
Well, PrBoom (Doom) uses delta timing, I'm pretty sure. I can't think of any others off the top of my head (other than a game I'm developing now).
 
I just whipped up a quick Python program that uses delta timing if someone wants to test the delta timing thing:


http://www.mediafire...z3lgi1zk0hmve7w


It's supposed to slowly fill in the screen with white one pixel at a time. If my thoughts are correct, then when you resume it after stopping it, it'll skip ahead and "paint" a huge section (well, maybe huge, depending on how long it was stopped) of the screen.
 
Last edited by a moderator:
I just whipped up a quick Python program that uses delta timing if someone wants to test the delta timing thing:


http://www.mediafire...z3lgi1zk0hmve7w


It's supposed to slowly fill in the screen with white one pixel at a time. If my thoughts are correct, then when you resume it after stopping it, it'll skip ahead and "paint" a huge section (well, maybe huge, depending on how long it was stopped) of the screen.

If such jump happens and you need delta time, you can either catch the SIGSTOP and SIGCONT to start calculating delta time again, or check if the delta time beetwen "frames" was highly unlikely high. I actually suggest discarding always such frames, since having minor slowdown instead of huge jump is way better. (eg. bullet hell arcade shooters anyone?)


You may also want to look into fixed time step, it's easier to manage, but can be jerky. However if you do interpolation right and priotize the logic right, it can be win.
 
Last edited by a moderator:
check if the delta time beetwen "frames" was highly unlikely high.
You know, even without this, that is a good idea. I can't believe I never thought of it. Though my version would be "limit the time reported to have passed since the last frame" (to some large value like 100 milliseconds).


In any case, my only point in bringing this up is there's no guarantee that games that use delta timing would address this problem. Maybe it should be ignored anyway (since, if I'm not mistaken, the number of games on the Pandora that use delta timing is tiny), but it's something to consider.
 
We could pause the currently running apps with



Code:
kill -STOP <pid of foregroundprocess>.
That doesn't prevent most programs from processing keypresses though. The OS will continue to buffer keyboard events while the input file is still open. When you SIGCONT the program, it reads in all the buffered inputs. There is a solution that Notaz helped find.





Theoretically we could get the pid by first issuing



Code:
 xdotool getwindowfocus

which gives us the windowid of the process, that has the focus currently or
Fullscreen SDL applications don't have a window, they draw directly on the frame buffer. Getting the currently active application (and in fact all running PNDs) is a problem solved some time ago. :p
Good to know, that you guys are on it. And that you are seemingly on the right track. I was trying this out yesterday for about half an hour and that there were my results. So, please go ahead, I'm curious to know what you'll be able to do.
 
Back
Top