[[Solved] Why not displacement maps instead of normal maps?]

Displacement maps create additional faces, so they are much heavier to render:

http://www.ru.is/kennarar/hannes/useful/blendermanual/htmli/ch11s03.html

I think instead of displacement mapping you could just create the details with real faces and then use a normal map on top of the details.

 

Thanks Lumooja.

 

Yes. They write the answer in your link

 

For distant/non-critical items, NOR mapping should still be used. NOR maps, compared to Displacement maps, impose very little additional CPU cost per renderface, and you can NOR map independently of renderface count. Use of Displacement maps quickly leads to millions of faces in a scene.

[[Solved] Why not displacement maps instead of normal maps?]

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?

[Facebook publish give surprising results]

lol. Wow, thats some good modeling. How did you do that from a forum picture?

From a drawing by a friend of mine.

She will have a bit cartoon style when done

[Facebook publish give surprising results]

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

[window.h]

I get this error now.

 

MyGame-Debug.exe not found or not built by the last incremental link; performing full link

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

[Upcoming header fixes]

Great and thanks

[foreach VS 2010 macro]

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;
}

[Check out the tutorials]

lol I think to know enough the differences between C# and C++, but since my "LE language" is C# then I could be interested on writing some tutorials for that and I doubt its correct category would be "C++". Well, if I will be interested on writing some C# tutorials I will request a C# category.

Of course there must be a C# category

[std::vector problems]

Roland the error occurs in the main loop and not in the end of program. But I had such problems as you described and solved it as you pointed. Thanks.

Aha.. Sorry. I misunderstood you problem then.

 

Lumooja I like to use pointers but need to be more cearefull. And I dont see -> sign is so ugly I can live with it.

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.

[std::vector problems]

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() ;
}

[String error]

Hello,

 

i'm making a function to load a number of textures to make an animated one.

 

void LoadTextureSeq(string name,int num)
{
TTexture tex[4];
string path="objs/monsters/DK1/";
string tn;
int n;
for(n=1;n!=num;n++)
{
	tn=path;
	tn+=name;
	tn+=n;
	tn+=".dds";
	tex[n-1]=LoadTexture(tn);

}
}
.
.
.
LoadTextureSeq("electric",5);

 

this gives me that error:

 

error C2664: 'LoadTexture' : cannot convert parameter 1 from 'std::string' to 'str'

 

Please, what am i doing wrong ? thank you.

 

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

[FREE GAME ENGINES AND WHAT YOU THINK!]

I did test the UDK and it may be good as you all say,

but I really didn't like the UDK editor. It was like

have been transfered back to the 90's with it's totally

bloated editor. If you think that Blender has a awkward

user interface. That's nothing compared to the UDK.

 

The free version of Unity is modern and has a very nice

editor, but its graphics is on the downside.

 

Blender has a built in game engine but I have not tested

that one. But the little I have seen leads me to think

its best suited for simple games. I might be wrong on that though.

However it's builds on the free Crystal Engine.

 

I think that Leadwerks with its almost free price is a far

better choice that those mentioned.

[Official documentation]

But this whole thread IS about new or not to new. It says in the title "Documentation", and the documentation will need to use either new, reference (same as new, just modern way to do it), or the old Create() style:

 

So I suppose we are discussing now the content of the documentation, since the documentation site has been already done with custom mysql database.

 

As Shakespeare would have put it

"To new or not to new. That is the question"

 

You might be right.

[Official documentation]

You are calling Mesh destructor twice, since Mesh is a base class of Cube.

It should be:

Mesh& cube = Cube(Vec3(0,0,1));

I tested it with this code:

#include <iostream>
using namespace std;

class Mesh
{
public:
Mesh(){cout<<"mesh initialized"<<endl;}
virtual ~Mesh(){cout<<"mesh uninitialized"<<endl;}
};

class Cube : public Mesh
{
public:
Cube(){cout<<"cube shape created"<<endl;}
virtual ~Cube(){cout<<"cube shape destroyed"<<endl;}
};

int main()
{
Mesh& cube = Cube();
}

 

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.

[Official documentation]

I'm never going to use new since it breaks the dot notation of OOP, and I want cross-language compatible code, so I can copy paste from C++ to BlitzMax, Lua, and other OOP languages. Besides, other engines use Create() too, so it's also slowly getting an industrial standard.

 

Even if the tutorials use new, I can still use scope allocations:

 

Tutorial:

Mesh* cube=new Cube();
Vec3* v=new Vec3(0,0,1);
cube->Move(v);
delete v;
delete cube;

My Way:

Mesh cube;
cube.Move(Vec3(0,0,1));

 

The only difficulty in My Way when LE is using new notation, is to create global objects, but it can be done with deferred instancing:

map<string,World> world;
map<string,Mesh> mesh;

void deferred_init(void)
{
   World world;
   world["main"]=world;
   Cube cube;
   mesh["cube"]=cube;
}

int main()
{
   deferred_init();
   mesh["cube"].Move(Vec3(0,0,1));
}

 

 

My way:

Mesh cube = Cube( Vec3(0,0,1) ) ;
...
... some code
...

 

or

 

Mesh* pcube = new Cube( Vec3(0,0,1) ) ;
...
... some code
...
delete pcube ;

[Official documentation]

@Roland

I thought we were talking about CreateObject() as in CreateCube(), LoadModel() etc. ..Maybe i'm missing the whole point, it's 4AM here

 

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

[..Korona again..]

Your EXE fails to start without any error message on my ATI 4870.

 

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

[..Korona again..]

That image looks quite amazing.

I downloaded the exe and ... wow I say

[Official documentation]

Internally STL map uses also new, but the user doesn't have to know it, and to deal with ugly forgotten delete instructions, plus setting the pointer manually to NULL after that.

 

You could use STL containers for all variables, then you have also the possibility to loop through all your variables, and to lookup them. It would allow you to save/load the program state from disk also.

 

Having all objects randomly spread out through the code without any kind of control when they are created and deleted, is not so good.

 

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

[Official documentation]

Yes, but I showed also that new and Create() is both not needed. I just use a STL map and set values into it.

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

[Official documentation]

You can do it even easier, like I did in my GUI:

GUI gui;

gui.AddWindow("About");
gui.AddButton("About","OK");

Then you can check if the button was pressed:

if( gui.ButtonClicked("About","OK") )
{
}

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.

[Official documentation]

I agree on the concept of Object myObject = new Object1(); instead of object = CreateObject().

 

It is a personal choice though:

New programmers will probably like the CreateObject() command because it is a slightly more obvious command. More experienced programmers will like the resemblance with the C# like structure.

 

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.

[Official documentation]

I think you mean 'querying' not queering... thats a whole different concept...

Yes .. thats the word.

[Official documentation]

Holy cow. I've been using pointers for 10 years now and have never had my computer destroyed

 

Smart pointers could be used. The whole Create(CREATENOW) thing is just an ugly design. I'll take an ugly operator over an ugly design

 

Could not agree more

[Programming Poll]

I've not experienced that, but if it happens to someone, it might be that you are running the C++ in debug mode with the debug define enabled, which will use the debug.dll, which is very very very slow. Also without the debug.dll the C++ debug mode can be slower than BlitzMax in release mode.

 

If your C++ is slower in release mode, then it might be that the slowness of blitzmax comes with the dll, and since there are more blitzmax commands in the dll than in the blitzmax version, then C++ has to process more slow code.

 

When the dll is made in C++, there will be fast code inside, and the dll code will be also fast. So BlitzMax will be faster with LE3 than it is now, and C++ will be also faster than BlitzMax.

 

Yes. I agree on that