Irrlicht Engine

Here's some stuff I've added to my own 0.6 version thay may be useful in general. The main idea is to be able to specify my own malloc/free functions (I've got some with memory tracking to ensure there aren't any memory leaks). I added two arguments to the CreateDevice function, the function pointer...

Panda worked fine with max6, however there are a few settings that must be used.

In particular, the materials must be exported as "inline". Luckily panda provides enough flexibility that just clicking around its panel a few times gave a result that worked. (At least it did for me).

I've just run into the infamous non-power of 2 texture artifacts. I've only dealt with 2d textures, so I'm not sure how these 'fixes' may effect the 3d case. Anyway, here's the problems I found. 1.) Texture size: Firstly, CDirectX8Texture::getTextureSizeFromImageSize() rounds down, thus returning a ...

That is the correct procedure, so the most likely problem is the pointer is invalid somehow. Two of the most likely causes: 1.) The createDevice() may fail in which case the pointer will be null. If drop() is then called it will crash. 2.) If drop() is being called twice you'll get a double delete, ...

Its nice having xml as part of the engine, especially since its bundled over the zip reader. Actually I'll slip another feature request in here. Having int/float functions that return a bool of success would be good, as in: bool getAttributeValue(int& value, const wchar_t* name) bool getAttribut...

No sweat, Irrlicht's still the best out there - the xml, zip & gui support are great.

If text is read in using the xml reader and then rendered (via the gui), newline '\r' symbols show up as boxes at the end of each line. The xml file could strip these out, or alternatively the rendering could ignore '\r's. I'm using SciTE to edit my xml files (in widestring format), so it could be c...

I've been having some fun with the gui, but here's a few ideas that would make it easier to extend it. 1.) virtual bool IGUIElement::isBuiltinType() Would return true by default, but could be overriden by app side classes. This would allow app side handlers to safely downcast the IGUIElement* to the...

You can record what the mouse is over by listening to hover/left events, and storing the IGUIElement pointer in the app code. Then when you get the event, you will know what has been clicked. However, having IGUIEnvironment do this would be a preferable arrangement, particularly since it could then ...