This may not be a problem, I used your resources. 
I looked at github your post, it seems you forgot to indicate the status of the full-screen mode to reproduce the error.
However, thinking about your implementation of fall foliage, I think the possibilities of particle effects are redundant for such a simple task. I think you can do simple math to drop and rotate the sheet.
Do not forget those about the bullet
I saw that, indeed; hopefully there’s nothing in GitHub’s terms of service that cause them to lay claim to it (I doubt it). I’m willing to trust rdb, at least! So hopefully it’s okay!
Thank you for letting me know.
I presume that it happens in windowed mode, since you’re minimising the window–am I mistaken in that? (I don’t recall mention of full-screen mode, but I may have missed it!)
Perhaps, but I suspect that a particle effect will be slightly more efficient than handling it myself. Plus it provides that handy noise-force, which gives the effect of the leaves drifting a bit.
(I could do it myself–I even have a system that would do the job, currently providing blood-effects in combat. I just feel that a particle system is better-suited here.)
As to Bullet-physics, I fear that it would be overkill of a situation like this! ^^;
I changed the archive to empty png. Added a full screen. I think the link on the github needs to be replaced.
Ah, thank you for that–both the replacement of the image and the quote–I’d missed the full-screen bit, it seems!
I’ve updated the link in the GitHub issue. 
Well, it looks like rdb has found the problem: it seems that LinearFrictionForce is broken. Details in the reply linked-to here:
I think that I’m going to experiment with just applying a static initial velocity, and leaving the noise-force as the only one present. I should check whether any of my other particle effects use the friction-force, too!
Okay, I’ve just uploaded a new version that should incorporate the fix. (I’ve uploaded to itch.io as linked about, at least; the upload to IndieDB is still underway at time of writing.)
@Thaumaturge it seems you were unlucky, I chose your game as a test for the stability of Panda3d. So I found out that your game can not miss the splash screen when you press the key.
If you set the frame rate to 20 or lower.
Hahah, oh dear! XD;
Interesting! I’ve made a note to look into that–although 20 is an awfully low frame-rate, especially at the splash-screen! If the game is running that poorly on the splash-screen (without intentional setting of the frame-rate), then I would very much doubt that the game itself would run at all…
Thank you for the report!
[edit] Do you mind if I ask how you set the frame-rate so low? I’d like to investigate this problem, and do so by repeating what you did.
set in file .prc
clock-mode limited
clock-frame-rate 20
Ah, great, thanks! I’ll likely try that out, and see if I can determine what’s causing the key-press to be ineffective! Perhaps there’s some issue with KeyMapper, or Panda’s missing key-events, or… well, something!
If that I use masterpiece from Microsoft - Window.
That’s worth noting, thank you. I’ll likely try it under Linux first, since that’s where I develop, but if it doesn’t show up there then I can try it out under Windows instead.
Okay, I’ve found the problem, I believe:
In short, I have code that, when the game is considered to be transitioning between states (such as when loading a cutscene–the splash-screen included), prevents the game from becoming “active” if the average delta-t is too low. The idea being, if I recall correctly, that after loading things I wanted to the game to wait until its frame-rate had evened out and improved a bit before becoming available to the player.
Specifically, it waits until the average delta-t is less than 0.05.
I.e. 20 frames per second.
Indeed, if you set a fixed clock-rate of just one frame-per-second higher–that is, 21 frames per second–the splash-screen works perfectly. You just happened to strike on the highest frame-rate that wouldn’t work.
Is this limitation that I’ve placed a bad idea? Perhaps. But on the other hand, I don’t really want the player trying to move around in those first frames after loading a level, when the frame-rate might be a bit unstable… :/
Knows I with such frequency has passed game Crysis, but this is so to word. Actually, it is strange to have such an approach, I have not seen such innovations in games before.
I don’t know how other games handle that initial frame-rate bumpiness–if someone else does, I’m very open to suggestions! (And I do confess that it looks like the game is bugged under such conditions.)
As to playing at 20FPS… I don’t even like having the game drop below 60. I’d take 30–but 20 seems awfully low to me. That said, I am open to changing the test-value, if this approach is kept.
There should be a way to force Panda to do the frame-time affecting operations and let you know when they complete. Unfortunately, I do not have a complete list of the operations or how to force them. Starting with preparing the scene (via NodePath.prepare_scene() should be a good starting point. This should handle texture and geometry uploads. I think it also compiles shaders even though this isn’t in the docs description.
Hmm… I don’t know, however, whether it’s Panda doing such things in the background or whether it’s just a matter of letting it recover after doing heavy tasks.
Still, that might be worth looking into as an alternative–thank you!
Have you measured how many frames this problem lasts? I would just cap how long the game applies this trick to however long you have measured this problem to take to go away.
I’m not sure what Panda could be doing to “recover” after doing heavy tasks, except perhaps garbage collection, which will only take more than frame if you’ve limited the garbage collection rate.
It’s a thought–although I’m hesitant to assume that it will last the same length of time on all machines.
It may not be Panda itself; I’ve noticed for example that Ubuntu seems to take some time to recover responsiveness after taxing operations. Quite what it’s doing I don’t know–perhaps cleaning up RAM or virtual memory.
You could essentially time out your hold operation by letting the scene run if you’ve been holding it for more than some ridiculous frame count (e.g., 100 or 1000). You could change this over to seconds as well (e.g., stop waiting after 10 seconds).