What are the plans for Irrlicht 1.8 and further?

[B@z]

try it out with release build, it wont crash.
but yea, i agree with blocking the alt menu opening thingie.

a feature request: easy plane vs triangleSelector or box vs TriangleSelector.
would be good for basic custom colliding

[CuteAlien]

For box vs TriangleSelector you can already use ITriangleSelector::getTriangles with the box parameter (if you only want to check for the first do pass an arraysize of 1).

[hybrid]

I had an issue the other day i thought it was a bug. But happened that in fact, it is a matter of the way Irrlicht handles the windows messages.

You see, pressing F10 caused the engine to stop working in Window mode. In the begining i thought it was because i had something wrong with the keyboard callbacks, but then, i realized it was something that windows actually did with all the windows present, and was that it tried to open the menus, the same as if you pressed the key alt.

Couldn't be posible that these keys were trapped somehow so they didn't trigger this behavior anymore?, or at user's request, if the menus were needed really.

This should be fixable by replacing the syskey events handling by just a simple key event generation. Don't know what the Linux equivalent would be. Guess we'd have to deal with window manager settings then.

[CuteAlien]

If this is some default system behavior then I don't really think we should suppress that as people usually want their system-keys to work. Especially in window-mode...

I'm not on Windows right now, so not sure about the reason the rendering would stop. Maybe isWindowActive() fails then (although it probably shouldn't)? In that case you could change your main-loop.

But I will try to take a look into the F10 thing when I'm back on Windows.

[xDan]

But since there's no File,Edit menu etc on an Irrlicht window there shouldn't be a need for it, right? A problem is I can't detect this state, so cannot pause the Irrlicht timer + my logic steps build up.

[Brainsaw]

Maybe adding a switch to turn that behaviour on and off would be an idea. I do from time to time hit ALT by fault, and I would like to get rid of the freezing game.

[B@z]

For box vs TriangleSelector you can already use ITriangleSelector::getTriangles with the box parameter (if you only want to check for the first do pass an arraysize of 1).

wow thanks, didnt know about that.

lot of games use ALT key for something (e.g. jump like in old tomb raiders or alternative attack), but because this freeze, we cant use that.

[sudi]

lot of games use ALT key for something (e.g. jump like in old tomb raiders or alternative attack), but because this freeze, we cant use that.

well again just in window mode.

[Mel]

But since there's no File,Edit menu etc on an Irrlicht window there shouldn't be a need for it, right? A problem is I can't detect this state, so cannot pause the Irrlicht timer + my logic steps build up.

No, actually these keys are detected, and any code bound to them is executed correctly, the only problem comes from the fact that the key press reaches the window manager, stopping irrlicht from execution, until you press any option in that menu, or return to the program, making the menu disappear, then, the execution returns to normal.

[stefbuet]

So no release approximation date ? no "near/far" release ? Thx

[CuteAlien]

So no release approximation date ? no "near/far" release ? Thx

Sorry, not really :-) It's always hard to say how much time we will find. I also suspect we should probably release an 1.7.2 before 1.8 as in the last time we had way more bug-fixes than features. But I guess that also should wait at least until we have fixed the animation bugs (at least that's my top-priority bug right now). If you want more up-to-date versions you can certainly always try svn - we are happy on everyone helping us testing stuff before releases!

One new feature for 1.8 should be cursors. Once I stop rewriting the interface over and over again *sigh*. At least for Win32 and X11 (I still got no mac).

[BlindSide]

I can't say when Irrlicht 1.8 will be released but personally I plan to have a test shadow map system integrated around July.

[stefbuet]

ok thanks

[CuteAlien]

I just checked the ALT and F10 stuff and what did happen was that a WM_SYSCOMMAND - SC_KEYMENU message were send for those keys in windowed mode. But as xDan noticed it's probably not needed for Irrlicht (and if it is needed again users will have to send that message to Windows). So for now I disabled it in svn trunk (which means for 1.8).

But this might change again if I find time (or someone else) to rework events which is one of the things I also would like to get into 1.8:

Basically the current solution isn't really that nice as we just filter a bunch of OS-events and when this doesn't fit the user wishes then it's trouble for all such messages. So either we add wrappers for all OS-events (hm....), add a WNDPROC callback which is called additionally (before Irrlicht probably) or add an w32-event which just passes on the wparam lparam stuff on Windows (and a similar event on Linux). Haven't decided yet which is the most comfortable solution.

[slavik262]

One thing I think Irrlicht could benefit greatly from is generic LOD for all meshes. The terrain LOD system is awesome - have there been any attempts to create a generic LOD option for all meshes? I hate to say it, but I know one huge thing OGRE always boasts is great LOD as a material setting.