Irrlicht Engine

Zurzaza wrote:

robertianbelgica wrote:Yup. we were able to run it. but now a new probable occurs after the green menu an error prompt occurs where in it says. "could not open file of texture:../../data/standby.png"

simply...you must change the data's folder...you're maintaining original irrode's run-time include folder. So, the game is searching into "data" folder the standby.png image.
The solution are two:
- Change the path into the source code
- Copy the data folder into specified path

So i'll just change all the path in the source code into our specified path?

yes...you must doing that because irrlicht' device is going to search all graphics data into a folder, specified in the source code. So you can copy the irrode's data folder in your output folder.
Remember that the path is "../../data/standby.png", so the data folder is placed in the previous folder than your binaries output folder

If you want to run the IrrOde demos you have to set the execution directory of your program in your IDE. If you modify that path and load scenes from the IrrOde demos you'll have to change the paths in those scenery files, because Irrlicht uses relative paths.

Brainsaw, i've got bad news for you..it seems there are a lot of memory leaks. I've escluded leaks coming from my faults.
I make that dump by using "_CrtDumpMemoryLeaks()" by microsoft.

http://pastebin.com/BBwUVPab

Any ideas? My fault or something went wrong with my code?

Hmm ... I think I'll have to find those leaks. Your log files don't give any hints on where those leaks are, so I'll either use the VC functionality or a similar method for gcc I discovered. I'll give you a report when I find something (and I hope that the leaks come from my code and not ODE ... haven't yet tested their examples) so that I can do something against them.

Sorry, but i don't know other methods to report you a memory leak dump. Maybe you can give me more ideas to find memory leaks in my application

The way you tracked the problem seems to be good, but I haven't used it yet. From what I found after 5 minutes of google is that there must be a way to get more specific information on where the leaking memory is allocated.

Brainsaw wrote:The way you tracked the problem seems to be good, but I haven't used it yet. From what I found after 5 minutes of google is that there must be a way to get more specific information on where the leaking memory is allocated.

If you found another way to debug the memory leaks, please say it to me...this method doesn't give much information about ...

Zurzaza wrote:If you found another way to debug the memory leaks, please say it to me...this method doesn't give much information about ...

I am using Visual Leak detector for 2 - 3 years now. You need just need to include vld.h and when application stop executing you will see memory leaks in output console of MSVC.

ArakisTheKitsune wrote:

Zurzaza wrote:If you found another way to debug the memory leaks, please say it to me...this method doesn't give much information about ...

I am using Visual Leak detector for 2 - 3 years now. You need just need to include vld.h and when application stop executing you will see memory leaks in output console of MSVC.

very useful tool, i'm going to search memory leaks into my project with this great utility...thank you!

@brainsaw: I'll start debugging also all the memory leaks that i founded

Damnit ... very frustrating. I've been searching for the leaks for a couple of hours now and I'm no step further. I hope I find something or I get some input. I use gcc, and I have found something similar to the VC method, but it didn't lead me anywhere

Alright ... I have chosen to use another way to get closer to the problem: I tried a lot of the snapshots I created from the project, and I found out that the leak (or at least a leak) appeared last September. Seems to have something to do with the surface parameter additions I added back then. I am going to investigate some more in this area.

Got it. It came from the way the surface parameters of a contact were calculated. For each contact there are two sets of surface parameters, from these parameters a third set is calculated. The problem was the in the constructor of the CIrrOdeSurfaceParameters every new instance was added to a list of parameters (used for reusing the parameters), so for every step a new parameter was added to this list for every single contact (quite a lot in the IrrOdeCar demo ). The new parameters became invalid as soon as the nearCollisionCallback method ended, but the entry in the list wasen't removed. Fixed now. My testing didn't show any further leaks.

I'm debugging the project with VLD, and i noticed that there are other about 600 memory leaks. I'm trying to find them, and,If you want, I can post the solution when I finished the work..

There is one other leak I know: some of the IrrODE scene nodes seam not to be deleted. Would be nice to fix that one (of course), but the leak I fixed was worse: with the current situation the memory usage of the programs don't increase any more (at least the process explorer doesn't report any leaks during runtime).