Irrlicht Engine

Yeah, it's still on my TODO list. Not sure if they make it into 1.8 or 1.9, though. It's not much code, but requires certain adaptions to the basic texture handling.
Maybe someone can have a look at the projection bug in the stencil shadow patch (->patch tracker), once this is fixed I can start with cube maps.

I'm sure the bug is simple and obvious! I'm telling this because the most annoying bugs in my stuff were always small ones... That's why they were hard to find.

Edit:
Anyway, dev guys, take your time! You're doing a wonderful job with this engine, which is already capable to do anything what people want. If something cannot be done with it, there are always solutions: use a workaround or downscale. I personally like a new feature much more when it works out-of-the-box rather than in the next next next patch.

I would take a look to the stencil shadows because now appear small silouettes out of nowhere, when it is applied. It didn't happen before.

Yeah, all that's already solved in the patch found on the tracker. There's now only the problem that the shadows move wrongly when the camera moves.

Could you add an int "MaterialTypeParam3" in SMaterial so as to be able to send multiple boolean with binary operator to the Material ? Because we can't with a float. I need boolean for exemple to know if I have to draw the mesh with normal mapping or not, metal specular model or not, use specular map or not.... That would be really usefull. Thx

Just use the two exisiting params as 32 booleans stored as binaries.

Using memcpy and bit masking to shove integer or boolean data into floats isn't all that elegant. A third MaterialTypeParam would be nice. Granted, it's really easy to add in yourself, but it would be nice to have official support.

On the note of shaders and integer/boolean values, could the SetPixelShaderConstant/SetVertexShaderConstant functions be overloaded to also accept integer and boolean values?

Yeah, I already did such an extension once. Guess I have to find the machine where I did that...
Anyway, having an additional member in SMaterial is quite expensive. You can have hundreds of SMaterial members per scene node. We won't add arbitrary new members just because it's inelegant to access bits of a member somewhere.

It's just an int, but like I said, easy to add in yourself.

What about the shader constant set functions supporting integer or boolean types without casting?

Well if we added a material type param 3, then we might as well add number 4 too. What if we replaced the material type param, with a core::array of s32's? And the materialTypeParam1 and materialTypeParam2
could be kept as members, but they would be references to the first two indexes of the materialTypeParams array?

Like Hybrid said though, increasing the number of params would incur some memory overhead since each mesh can have many SMaterials. I just think the addition of one for boolean and integer data would be useful.

Uhh.. maybe the IParticleSystemSceneNode could get a clone method?
Right now it doesn't have it, and frankly, it's rather disgusting

@devs... You don't even care, do you.

I'm sure the devs care. But they're probably busy with more important things right now. Besides if you want really good particles, you should really look into SPARK.

I know, it's just.. They could at least drop by and say something like 'We know about it, we will fix it in the future.'.