Roland

Pixel ... My hat of and great applauses What a great thing. When can I buy Edit: Suggestion (if not planned already) Now the path seems to be made as straight lines between the points and thats great in a building. Outdoors it can look a bit strange, specially when the NPC changes direction. It looks a little bit robotic. Could this maybe be solved with some kind of splines or other smoothing mechanism so that the NPC don't makes a bit smoother change of direction.

Sounds interesting. I'm a big fan of that kind of games.

Thanks Lumooja. Yes. They write the answer in your link

Is there any reason why normal-maps seems to be preferred (or are they?) compared to displacement-maps. If I got it right, displacement-maps gives better results. Are the slower, consumes more GPU memory or whats the reason why normal-maps are used instead?

Awesome and shared on Facebook

From a drawing by a friend of mine. She will have a bit cartoon style when done

It seems that ZioRed has taken over Facebook ... Just joking but check what happens when I try to publish my blog entry to facebook Images show where I click on Facebook symbol in my blog and what the result is. Quite surprising

Thats not an error. Its just the linker giving some information on what its doing.

Great and thanks

for_each is a normal STL function. No BOOST needed Works in VS2008 and VS2010 Example: #include <iostream> #include <algorithm> #include <vector> using namespace std; class myTest { public: void operator() (const std::string& s ) { cout << " " << s.c_str() << endl ; } } ; int main() { myTest test; vector<string> myStrings ; myStrings.push_back("For" ); myStrings.push_back("Each" ); myStrings.push_back("Works" ); for_each( myStrings.begin(), myStrings.end(), test ); return 0; }

Of course there must be a C# category

Aha.. Sorry. I misunderstood you problem then. Yes you are correct. Pointers , new and delete are your best friends in C++. They are a part of the language and there is absolutely no reason to avoid them.

Your are all missing the problem with the example. In this case the vector is destroyed when it goes out of scope. This is when we reach the end of main. The problem here is that the engine has been terminated at this moment "return engine.Free()" so what happens it that those myClass destructor's are consequentially call AFTER the engine has be closed. What then happens in the myClass destructor are freeing an object that does not exist any more as it (and all other Entity's used) has been destroyed in engine.Free already. This can be avoided in various way. Here I show some of them (I only show the interesting parts of the code) Alt 1 int WINAPI WinMain( HINSTANCE hInstance, HINSTANCE hPrevInstance, LPSTR lpCmdLine, int nShowCmd ) { Engine engine( "VectorTest", 800, 600 ) ; ........... myClass myC("abstract::gunshot.ogg"); myClass myC2("abstract::reload.ogg"); std::vector <myClass>* vec = new std::vector<myClass>() ; vec->push_back(myC); vec->push_back(myC2); // Game loop ....... // Done delete vec ; // all myClass'es are deleted BEFORE engine // as the vector is deleted : return engine.Free() ; } Alt 2 int WINAPI WinMain( HINSTANCE hInstance, HINSTANCE hPrevInstance, LPSTR lpCmdLine, int nShowCmd ) { Engine engine( "VectorTest", 800, 600 ) ; ........... myClass* myC = new myClass("abstract::gunshot.ogg"); myClass* myC2 = new myClass("abstract::reload.ogg"); std::vector <myClass*> vec ; vec.push_back( myC ); vec.push_back( myC2 ); // Game loop // Done // we delete all myClass'es (BEFORE engine is terminated ) for( std::vector<myClass*>::iterator it = vec.begin(); it ! vec.end(); it++ ) { delete *it ; } return engine.Free() ; } Alt 3 int WINAPI WinMain( HINSTANCE hInstance, HINSTANCE hPrevInstance, LPSTR lpCmdLine, int nShowCmd ) { Engine engine( "VectorTest", 800, 600 ) ; ........... { // create a new scope myClass myC("abstract::gunshot.ogg"); myClass myC2("abstract::reload.ogg"); std::vector<myClass> vec ; vec.push_back( myC ); vec.push_back( myC2 ); // Game loop // Done // vec goes out of scope and so does myC, myC2 // destructors are called BEFORE engine } return engine.Free() ; }

tex[n-1]=LoadTexture( (str)tn.c_str() );

As Shakespeare would have put it "To new or not to new. That is the question" You might be right.

Yes. Your are right. However. This discussion is now so off topic as it could be. If we should continue the "to new or not to new" discussion it must be in a separate thread. Although I don't think there is any point in doing that. You have your view and I have mine and thats perfectly OK.

My way: Mesh cube = Cube( Vec3(0,0,1) ) ; ... ... some code ... or Mesh* pcube = new Cube( Vec3(0,0,1) ) ; ... ... some code ... delete pcube ;

I was talking about LEO which is wrapping those into classes. Cube c ; c.Create(...) ; is equivalent to TEntinty c ; c = CreateCube(...) So its actually the same thing in two different approaches

A little note about that. First I copied the exe into my Leadwerks SDK folder and run it. It then fails to start as you say. Then I just copied the exe to my desktop and ran it again. Then is shows up as it should

That image looks quite amazing. I downloaded the exe and ... wow I say

Who has said anything about not using containers. Still. Using containers has absolutely nothing to do with new or Create. Its up to me, the user of a container to decide the content of the container, it can be objects, pointers, integers, booleans or whatever. Hence this is also a container std::vector<Object*> container ; container.push_back( new Object() ) ; Again. The usage of containers has nothing to do with new or Create. About having object randomly spread out through the code etc.... This statement has nothing to do with the subject either. You are then discussing design of a program and nothing else. Then about using new in constructors. Thats a common practice and is totally safe to do if you place delete in the destructor. Cant be that hard to remember. New is constructor -> delete in destructor. Edit: Lumooja... admit you are happy that I'm back

Ok. But thats has nothing to do with new or Create

There are many ways to do a GUI. But thats out of topic here. The idea was just to show the difference between using new and Create, not to discuss Gui's specifically. That belongs to another thread.

The main difference is that when creating the object using a Create method you can always have objects as members of another class and don't have to use the new command. When having the creation in the constructor (along with argument) you have to have the object as a member pointer in a class and the use new Object to create it, and of course delete object in the destructor. Personally I have no problems with this, but some folks seems to be scared about using new. The reasons for be afraid of new and pointer are to me a bit irrational, but I have noticed that this phenomena exists. I would personally go for the creation in the constructor, but I can understand that some finds the Create method to create feels better. There are though some problems with having a Create method. Here is a little code snippet from a test program of my Cells GUI that shows this. GuiImage* pgui = new GuiImage( (GraphicsWidth()-800)/2, (GraphicsHeight()-600)/2, "abstract::goback_n", GuiAll ) ; pgui->AddChild( new GuiButton( 10, 10, "abstract::a", GuiAll, "A", &click ) ) ; pgui->AddChild( new GuiButton( 266, 10, "abstract::b", GuiAll, "B", &click ) ) ; pgui->AddChild( new GuiButton( 10, 266, "abstract::c", GuiAll, "C", &click ) ) ; As you can see I use the creation by constructor as this I the way I prefer. In this example adding new childs is quite simple by adding them with new. Now if the construction of GuiButtons would have been done by using a Create methods it would now have been quite so smooth. I show this alternative here below. GuiImage gui; gui.Create( (GraphicsWidth()-800)/2, (GraphicsHeight()-600)/2, "abstract::goback_n", GuiAll ) ; GuiButton b1( ) ; b1.Create( 10, 10, "abstract::a", GuiAll, "A", &click); gui.AddChild( b1 ); GuiButton b2( ) ; b2.Create( 266, 10, "abstract::b", GuiAll, "B", &click) ; gui.AddChild( b2 ); GuiButton b3( ) ; b3.Create( 10, 266, "abstract::c", GuiAll, "C", &click ) ; gui.AddChild( b3 ); // note: b1, b2, b3 must bee stored somewhere as they will // cause null-references if they go out of scope I think the samples above shows the advantage of using new instead of Create. But as Aggror says. Its a matter of taste in the end. You get the same result both ways, but using a different approach.

Congratulation to your brilliant steps towards your future. And I agree on math, who said math is boring. I always found it interesting. Good luck