Irrlicht Engine

I think I found my problem. That above redefinition a new for line number debugging of memory leaks was #defined out by another programmer on our team because it conflicted with other libraries were are now compiling into our modified version of Irrlicht.

#define CRTDBG_MAP_ALLOC
#define _CRTDBG_MAP_ALLOC
#define DEBUG_CLIENTBLOCK new( _CLIENT_BLOCK, __FILE__, __LINE__)



I see the code in the irrlicht headers anyway.

The easy way would be to run your application under the debugger. Step into main() , open up the watch window, and add a watch on the variable _crtDebugAlloc . Set the value of _crtDebugAlloc to 2254, and then run the application. The debugger will stop when the problematic allocation is being made ...

We are using the debug version of the Irrlicht.dll. We are compiling it our self. It's working fine but we have memory leaks somewhere in the irrlicht code . (Note: this is our problem and probably not an irrlicht bug)

How do I get irrlicht report the source file and line number of the leaking ...

I'm actually looking for a similar answer. I would assume node->setAnimationSpeed(0); would stop the animation. node->setAnimationSpeed(4); would start it back up.

But that seems like a hack?

rogerborg wrote:They "should" be able to do that, but they currently can't.

There's a whole slew of changes waiting on 1.5 to be released, including more flexible billboards, so if you want to see feature updates, please checkout and help test 1.5.

Thank you for the reply and tip

Billboard nodes should be able to be rotated along the axis facing the camera? To spin them clock or counterclock wise right?

sio2 wrote:The advice I have seen for IA64 is not to use floats but to use SSE. The intrinsics in Visual Studio make this really easy. IA64 has double the number of SSE registers over 32bit as well.

You mean x86-64 (AMD64), right? Not the Intel Itanium architecture, also known as IA-64.

There's no need to change datatypes to 64bit width for 64bit systems. It's just the pointers which are automatically changed to fit native sizes. With double precision you'll still have far more complex and hence slower operations, moreover, 64bit systems may have some 32bit operations which can ...

Is anyone supporting builds using native 64-bit Irrlicht?

Are there considerations beyond using f32 verses f64 (s32 and s64, etc). I know in our application, we always use f32 to do our calculations and I wonder if there is a performance hit using 32-bit sized data verses 64-bit.

Are there any ...

The info posted here is great. Thank you.

Does anyone have some experiences to how much this configuration (Fast FPU) improve an Irrlicht graphics intensive application?

hybrid wrote:The sky dome uses a rectangle texture as if you'd use a panorama picture. This image could be used for sphere mapping environment onto a mesh, but not for skydomes as used in Irrlicht.

Ok got it, thanks. Rectangular or square? What ratio if not square?

In photshop(or the gimp) you can use the polar coordinates filter wich distorts your sky to work on a skydome, for the problem with your texture
I think that on sky domes it works best with 1024 X 1024, so define your picture as a patern and just tile it inside the image so it looks how you want it ...

In photshop(or the gimp) you can use the polar coordinates filter wich distorts your sky to work on a skydome, for the problem with your texture
I think that on sky domes it works best with 1024 X 1024, so define your picture as a patern and just tile it inside the image so it looks how you want it ...

I meant to do it in something like photoshop, but thinking about it, if you've got a texture for a skydome it might not work well.. what is your texture, is it just a load of white dots, like this:

http://www.graniteland.com/stonespics/stargalaxy.jpg


(might not need warping if it's just stars ...