Josh

The AABB is calculated for each entity, not the entity and its children.

Thanks to the C++ guys for the tips.

You could output that data to a 3D printer and a copy of it in real life.

If it has a hierarchy, you might just be getting an empty top-most pivot's aabb.

You can potentially get random crashes doing that. There are a great many ways it can mess things up. For example, if the model surfaces get initialized while the engine is in the middle of rendering something, or if the global models list gets modified while being read, etc. it will cause unpredictable behavior and nondeterminstic results.

It is stupid, it shouldn't add a value in when you're reading from it. They only did this because it has to return a pointer that can be gotten or set: a = map[2] map[2] = a So it's a result of a limitation of the C++ language, because none of this stuff was implemented when they originally designed the thing. Which is why we call C++ an octopus made by nailing extra legs to a dog.

Leadwerks3D makes extensive use of multithreading in its internal routines. Great care has been taken so that physics and pathfinding will constantly run in a background thread, only syncing up with the main thread when tasks are complete. However, you can't just call engine commands from different threads arbitrarily.

We can see from this program, that the [] operator will insert NULL into the map when the key is not present, at least on the MS compiler: #include "stdafx.h" #include <stdlib.h> #include <list> #include <sstream> #include <map> #include <iostream> class Foo { public: int i; Foo(); }; Foo::Foo() : i(37) { } int _tmain(int argc, _TCHAR* argv[]) { std::map<std::string,Foo*> map; Foo* foo = map["Hello"]; // (add breakpoint here) std::cout << (foo->i) << std::endl; return 0; }

Right but the value is a pointer, so the default value is NULL. Or it would be if STL was designed by any sane person. mymap["whatever"]=NULL; Ah well, thanks for the tips.

*************************************** IMPORTANT *************************************** It seems Roland is right. Well, sometimes. I am getting unreliable behavior when reading with the [] operator, if the key does not exist in the map. I recommend always using find() instead of the [] operator!

Nothing.

Yeah, but if it's a pointer, it shouldn't add anything, because the default value is NULL. The problem was solved with a Clean & Rebuild. Thanks anyways for the tip.

driver->loadedassets is an std::map with the following format: std::map<std::string,AssetBase*> loadedassets This leaks memory: if (driver->loadedassets[rpath]!=NULL) //if (driver->loadedassets.find(fontpath)!=driver->loadedassets.end()) { reference = (FontReference*)driver->loadedassets[string::Lower(rpath)]; if (reference!=NULL) { return (Font*)(reference->Instance()); } } This doesn't leak memory: //if (driver->loadedassets[rpath]!=NULL) if (driver->loadedassets.find(fontpath)!=driver->loadedassets.end()) { reference = (FontReference*)driver->loadedassets[string::Lower(rpath)]; if (reference!=NULL) { return (Font*)(reference->Instance()); } }

Seriously? They are iterating through a list of all allocated pointers every time they call delete? This is what a map is for. I know it's for debug-only mode, but come on: void RemoveTrack(DWORD addr) { AllocList::iterator i; if(!allocList) return; for(i = allocList->begin(); i != allocList->end(); i++) { if((*i)->address == addr) { allocList->remove((*i)); break; } } }; I posted the right way to do this, on Windows at least. It's astonishing to me that all the programmers discussions I found on Google said to use GetProcessMemoryInfo(), which is horrible advice: http://www.leadwerks...et-memory-usage

Memory leaks are based on the assumption the programmer will make errors from time to time. If I could write perfect code, I wouldn't have to test in the first place.

This will do it: http://www.leadwerks.com/werkspace/files/file/352-get-memory-usage That doesn't cover issues like if I allocate a char buffer or something in a function.

Gah, I was measuring total allocations. This is the correct code: long System::GetMemoryUsage() { #ifdef _WIN32 #ifdef _DEBUG //Exact memory usage, but only works in debug mode: _CrtMemState memstate; _CrtMemCheckpoint(&memstate); return memstate.lSizes[0]+memstate.lSizes[1]+memstate.lSizes[2]+memstate.lSizes[3]+memstate.lSizes[4]; #else //Only gives approximate results, but works in release mode: long sz=0; HANDLE proc = GetCurrentProcess(); PPROCESS_MEMORY_COUNTERS ppsmemCounters=new PROCESS_MEMORY_COUNTERS; if (GetProcessMemoryInfo(proc,ppsmemCounters,sizeof(PROCESS_MEMORY_COUNTERS))) { sz=ppsmemCounters->WorkingSetSize } delete ppsmemCounters; return sz; #endif #endif }

If I declare a list, map, or stringstream in a function, and call that function, my memory usage goes up when the function ends and the stl object goes out of scope. Does STL use a funny memory pool or something? This is all it takes: void MyFunc() { std::list<int> list; } mem1=System::GetMemoryUsage(); MyFunc(); mem2=System::GetMemoryUsage(); And my memory usage increases by 12 bytes.

Okay, I got it working. I would still really like to be able to get actual memory usage. :

I tried VLD. I added the header and lib paths in Visual Studio, included vld.h, and built the debug version, but nothing happens.

Jesus, this sucks. I don't want a "tool" to "help" me. I just want to real memory usage!

Here's what I am looking into now: http://msdn.microsoft.com/en-us/library/x98tx3cf%28v=vs.80%29.aspx

It turns out GetProcessMemoryInfo() is almost useless for debugging. The Windows heap manager allocates chunks of memory at a time, and the results of GetProcessMemoryInfo() mask memory leaks. If you purposely create a leak allocating a little bit of memory at a time in a loop, it won't show up until a certain threshold is reached, and then memory usage will increase by a lot. How can I get the actual memory usage of a C++ program, to detect memory leaks?

I am using a static lib with Leadwerks3D and BMX on OSX. It's probably possible on Windows, too.

Function reloading from script files works, even with arguments attached to connections! This means you can dynamically edit scripts, and see the result immediately when you save, even if they are in use in the flowgraph. The code behind this is pretty complex, but I don't see any way to write clean and neat code to do such a complicated task. I think the trick here is to test, test, test, and make sure there are no mem leaks. I try to keep the convoluted stuff in the editor, where no script is actually executed, and then it's easier to keep the engine code clean.