Page 2 of 2
Posted: Thu Mar 13, 2008 8:31 am
by switch_case
i uploaded it here:
http://rapidshare.com/files/99078698/bu ... e.exe.html
this programm was supposed to simulate kind of a bullettime, and is not even nearly finished, but i learned programming irrlicht with it.
you can move your node by mouse and W and S key for- and backward, A and D are not working right ^^ speed up with minus and slow with +...
try if it starts lagging at your system...
Posted: Mon Mar 28, 2011 8:00 am
by MolokoTheMole
I can confirm this is still happening with the latest Irrlicht.
Pressing and then releasing LEFT ALT pauses the games rendering. This needs to be fixed or at least does anyone have a temporary solution? Nobody can use ALT in my game.
Posted: Mon Mar 28, 2011 8:18 am
by hybrid
IMHO, we added support for avoiding the system key invoke through ALT in either 1.7.x or in the latest SVN/trunk code for Irrlicht 1.8. Maybe you can test this with SVN/trunk as well?
The thing is that not Irrlicht causes a lag, but Windows branches into the window menu and holds the whole app. This should be fixed, though, by simply catching this message and not telling Windows about.
Posted: Mon Mar 28, 2011 8:32 am
by CuteAlien
hybrid wrote:The thing is that not Irrlicht causes a lag, but Windows branches into the window menu and holds the whole app. This should be fixed, though, by simply catching this message and not telling Windows about.
I just run the q3 map example for testing in latest 1.7 svn and still don't notice a difference when pressing left-alt. I don't know how it's currently handled, but removing a system event completely doesn't sound so good to me as Irrlicht is also used in non-game applications where you want to have the usual application behavior.
@switch_case: Can you reproduce this with the Irrlicht examples? (I don't like running random .exe's from the net . And as it's without source even if I can reproduce that it wouldn't tell me anything except that there is some problem in your application.)
Posted: Mon Mar 28, 2011 10:49 am
by hybrid
The change to WM_SYSKEY_DOWN etc. as well as the default handling for those events has been changed pre 1.7. However, this does not seem to cause the effect of preventing the menu access - at least the SDK exe still allow for. But my 1.8 exes do not. Not sure why right now, but I also cannot test latest 1.7 compiled locally, due to wrong machine here.