What are the plans for Irrlicht 1.8 and further?

Kalango · Post by **Kalango** » Mon May 03, 2010 3:33 pm

Dont know about 'deafult' shaders (post processing scene node may sound good to save us time doing it but still....). But a nice pimp out of shader models and improved mesh loaders. Also way more than 4 texture maps/mesh, like...8.

PS: a nice tutorial or example about projection matrices in irrlicht, wich confuses ppl a bit (including me).

hybrid · Post by **hybrid** » Mon May 03, 2010 9:09 pm

You just have to recompile Irrlicht with a different texture number in order to support more textures.

3DModelerMan · Post by **3DModelerMan** » Tue May 04, 2010 1:18 am

What about cube map support? That would be really nice.

thespecial1 · Post by **thespecial1** » Fri May 14, 2010 12:45 pm

multi pass shader support pweeeeeeeeeeeease

sio2 · Post by **sio2** » Fri May 14, 2010 7:57 pm

thespecial1 wrote:multi pass shader support pweeeeeeeeeeeease

More than three years ago: multipass fur

Mel · Post by **Mel** » Fri May 14, 2010 11:41 pm

And what about bilinear filtered 2D drawing functions? the current implementation doesn't filter the 2D drawing routines, resulting in pretty ugly images when the textures are stretched.

hybrid · Post by **hybrid** » Sat May 15, 2010 7:28 am

Of course it is, at least it can be. Just use the 2d material setting in Irrlicht 1.7

Mel · Post by **Mel** » Mon May 17, 2010 4:04 pm

Of course it is, at least it can be. Just use the 2d material setting in Irrlicht 1.7

Is it documented anywhere how to do it? I haven't found anything on the docs :/ In any case, those are good news

hybrid · Post by **hybrid** » Mon May 17, 2010 8:10 pm

Yeah, the docs have the API, and example 5 has the code.

stefbuet · Post by **stefbuet** » Mon May 24, 2010 12:57 pm

Hey,
do you have any idea when the 1.8 will be release ? I don't ask for a precise date, but an approximation of it. In fact I'll be able to continue my game during summer vacations and I have to work on the lighting system. Currently I'm using XEffect but there is still much things to do so I would like to be able to compare XEffect to the futur Irrlicht lighting/shadow system to see which suit the best for my game. I'll do that if Irrlicht 1.8 is coming out not too late after the begining of summer vacations, otherwise I'll use XEffect.
Thanks!

ent1ty · Post by **ent1ty** » Tue May 25, 2010 2:04 pm

Try to finally make up your mind about the names of functions and data types. Sometimes there is addSceneNode, and then there is push_back. And the data types:
IMeshSceneNode is done by adding Mesh before the name of the base class and
ISceneNodeAnimatorCollisionResponse is done by adding CollisionResponse after the name of the base class.
Moreover, some public members start with Capital letter while others do not: SColor Color in S3DVertex and stringc name in quake3::IShader

slavik262 · Post by **slavik262** » Tue May 25, 2010 3:32 pm

ent1ty wrote:Try to finally make up your mind about the names of functions and data types. Sometimes there is addSceneNode, and then there is push_back. And the data types:
IMeshSceneNode is done by adding Mesh before the name of the base class and
ISceneNodeAnimatorCollisionResponse is done by adding CollisionResponse after the name of the base class.
Moreover, some public members start with Capital letter while others do not: SColor Color in S3DVertex and stringc name in quake3::IShader

People like us can do that minor of refactoring. While I agree that it's important to be consistent, I'd much rather the devs work on new features than run around the source files changing capitalization.

hybrid · Post by **hybrid** » Tue May 25, 2010 4:15 pm

We cannot change the method or class names anymore, at least not without major reasons. This would create a huge porting effort for no good reason. This is different to those changes made in the past, where wrongly written names, misleading parameter types, or missing constification was fixed and caused major incompatibilities. All those changes have had direct positive effect, while changes of those things just mentioned are not better in one or the other form. We will try to keep new structures conforming to the existing ones, though.
push_back and add* are used in container classes resp. reference counted classes, so there's a good reason to keep those different.
Capitalization has been fixed in most places, only a few minor classes of the public interfaces are not yet fixed - mostly because those members are not used by anyone from the outside.

ent1ty · Post by **ent1ty** » Tue May 25, 2010 5:09 pm

Sure, I'm not suggesting to rewrite it now - just for the future

Mel · Post by **Mel** » Thu May 27, 2010 3:37 pm

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.