Extending use of the Pandora-Key

[WizardStan]

We could pause the currently running apps with

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

 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.

 

[diligentcircle]

We could pause the currently running apps with

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?

 

[WizardStan]

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.

 

[diligentcircle]

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).

 

[Christoph.Krn]

WizardStan -- Is someone now actually working on a polished implementation of this?

 

[diligentcircle]

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.

 

[WizardStan]

WizardStan -- Is someone now actually working on a polished implementation of this?

THIS DISCUSSION IS OVER!


*closes the curtain*

 

[Cloudef]

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.

 

[diligentcircle]

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.

 

[steveway]

We could pause the currently running apps with

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

 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.

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.