Roland

http://www.youtube.com/watch?v=h_w7fwkUI8Q My character is moved randomly as seen in the video. There is not much special about the code I load my scene which contains the door, firepit and terrain using LoadScene LoadScene( "abstract::testlevel.sbx" ); I load my character model using LoadModel TModel _model = LoadModel( "abstract::celly.gmf" ) ; I create a contoller [code] // _height is 1.7 // _modelPos is position of the character loaded // CollisionType::Prop is 1 TController _controller = CreateController( _height ); PositionEntity(_controller, modelPos ); SetBodyMass(_controller, 1); SetBodyGravityMode(_controller, 1 ); EntityType(_controller, CollisionType::Prop); In my main loop i call update on controller Note.. I do not force any movement at all in the UpdateController I do not have any code that could move the character or controller at all. // _mode is the character model loaded UpdateController( _controller ); RotateEntity( _model, EntityRotation(_controller ) ); PositionEntity( _model, EntityPosition(_controller) ); Cant find out why the model is moving around by it self. Have done this before in other test snippets without problems but now this happens. Any hints? I have done this before without any problems. It was when rewriting my code-lib which I lost (see my blog) this occurred. So I'm doing something weird dumb this time. Just cant find out what. I commented out all code that could move the character in any possible way, bit still she moves.

Yeah that one is great, but 249$... ouch @Metadron Aha. I see. It was a comment on the solution

And what has this to do with maps ???

Hmm... is really a pointer's default value NULL. Not to sure about that. However... Great that its solved

driver->loadedassets[rpath] If rpath does not match the key of any element in the container, the function inserts a new element with that key and returns a reference to its mapped value. Notice that this always increases the map size by one, even if no mapped value is assigned to the element (the element is constructed using its default constructor). driver->loadedassets.find( ....... ) Searches the container for an element with rpath as key and returns an iterator to it if found, otherwise it returns an iterator to map::end (the element past the end of the container). Use find if you don't want to add something. Seriosly

Its one thing to get information that your program actual leaks. But the big issues to know where it leaks. This info can be retrieved by using some debug-commands, the debug output window and DebugBreak. It does not matter if its C or C++, in a class or in a function. You get the info. EDIT: LATER .... Ooops. I wrote this in wrong thread. Should be in the thread about memory leakage. Sorry

Yes. Josh " for debug-only ". Thank's for explaining what a map is used for You can always make it better by using a map. The idea is the important thing. Yes... but that does not show where the leak is. Anyway I do not use any of the methods above. Just wanted to give some links with info on the subject. Personally I use the Output-window from VStudio and DebugBreak, simple as that. But everyone has their way. I could, but will not go into a debate on this Hope your leaks go away no matter which method is used. EDIT: LATER .... Ooops. I wrote this in wrong thread. Should be in the thread about memory leakage. Sorry

Maybe some help here ? Personally I would not use malloc/free in C++ if not dealing with some very special memory management code. From http://stackoverflow...and-malloc-free ============ new/delete Allocate/release memory Memory allocated from 'Free Store' Returns a fully typed pointer. new (standard version) never returns a NULL (will throw on failure) Are called with Type-ID (compiler calculates the size) Has a version explicitly to handle arrays. Reallocating (to get more space) not handled intuitively (because of copy constructor). If they call malloc/free is implementation defined. Can add a new memory allocator to deal with low memory (set_new_handler) operator new/delete can be overridden legally constructor/destructor used to initialize/destroy the object malloc/free Allocates/release memory Memory allocated from 'Heap' Returns a void* Returns NULL on failure Must specify the size required in bytes. Allocating array requires manual calculation of space. Reallocating larger chunk of memory simple (No copy constructor to worry about) They will NOT call new/delete No way to splice user code into the allocation sequence to help with low memory. malloc/free can NOT be overridden legally Technically memory allocated by new comes from the 'Free Store' while memory allocated by malloc comes from the 'Heap'. Whether these two areas are the same is an implementation details, which is another reason that malloc and new can not be mixed. ============= Another "you should use new/delete over malloc/free. See Scott Meyers' Item 3 "Prefer new and delete to malloc and free" from Effective C++." ... se http://iskren.info/r...+/EC/EI3_FR.HTM Some tips about C++ can be found here http://iskren.info/r...++/EC/INDEX.HTM Finally here is some tips on finding memory leaks http://www.flipcode....ory_Leaks.shtml However the best tip of all is "Don't leak" EDIT: LATER .... Ooops. I wrote this in wrong thread. Should be in the thread about memory leakage. Sorry

I'm really exited about this. Really interesting.

Love to see the words "works with all supported languages".

I have a short version of the story line for the Tech Demo "If it moves, shoot it. If it doesn't, shoot it anyway"

Its really just awesome with those video blogs even for group members. Everyone is working on their thing but here you get an overview on what the others have achieved. Great and thanks

Following this with great interest.

GUI.H ============ #pragma once class GUI { virtual void Draw( ) = 0; }; CHECKBOX.H ============ #pragma once #include "GUI.H" class CheckBox: public GUI { public: void Draw(); }; CHECKBOX.CPP =================== #include "CheckBox.h" void CheckBox::Draw() { // Draw here }

OK. The change is simple enough to make that happen class GUI { public: virtual void Draw() = 0; // important ... virtual must be here // = 0 means that its abstract with no code }; class CheckBox : pubic GUI { public: void Draw() { // Do you specialized drawing here } }; ///////// using ///// void example() { std::vector<GUI*> guis ; guis.push_back( new CheckBox() ); guis.push_back( new CheckBox() ); guis.push_back( new CheckBox() ); // draw them for( std::vector<GUI*>::iterator it = guis.begin(); it != guis.end(); it++ ) (*it)->Draw() // another way to draw them std::for_each( guis.begin(), guis.end(), [ ](GUI* pGui) { pGui->Draw(); }); // .... // .... // .... // ....

Of course I'm not wrong. You are only showing that you don't understand the idea with virtual Listen to Aggror He's got it.

class GUI { public: virtual void Draw() // important ... virtual must be here { // do your base things } }; class CheckBox : pubic GUI { public: void Draw() { GUI::Draw(); // base class GUI::Draw is executed // Do you specialized drawing here } }; ///////// using ///// void example() { std::vector<GUI*> guis ; guis.push_back( new CheckBox() ); guis.push_back( new CheckBox() ); guis.push_back( new CheckBox() ); // draw them for( std::vector<GUI*>::iterator it = guis.begin(); it != guis.end(); it++ ) (*it)->Draw() // another way to draw them std::for_each( guis.begin(), guis.end(), [ ](GUI* pGui) { pGui->Draw(); }); // .... // .... // .... // ....

Here is my features request for second release of LE3D. Yes. I know that first one is not released yet but so far I know that some features probably won't show up in first release. Some of those things might be in LE3D firs release already and may then be ignored. If you know that any of the mentioned items is implemented already in LE3D first release, please tell. LE2-quality rendering (HDR, SSAO, Deferred rendering, sun-shafts, real-time shadows) Much better water. Current water is not good at all Automatic conversion of fbx to gmf at least on program start. if( fbx newer than gmf ) convert .... Automatic conversion of image files to the new internal format Support for common image formats (tga,jpg,png) Snap-To function in the editor. Array-functions in the editor Groups in the the editor Image based brushes for the terrain editor Path-finding (if not already in first release) Possibility to create and share 'Prefabs' At least simple IK for 3 nodes (root, mid, target) Some kind of particle based fog-and-cloud system Trigger areas. Defining areas where a trigger even will be sent to a callback. Scaling in the editor With those things in place I think most PC- and mobile- developers will be satisfied. At least I would

Absolutely amazingly clever.

Aha... Metadron... that like "A-laget" in Swedish Hmmm time to end this thread maybe ...

Whats AAA ???

What an excellent idea Everyone will be happy

In the end this was a good discussion I think

You just happened to be the trigger of a flood of feelings. But in fact this was the first time I realized that LE3 summer version would not be LE2 upscaled. Anyway. Some hours after the chock, I have calmed down and it will probably be good in the end. I don't want to throw away my current code invenstement anyway, so I guess all is good.

I don't