Wow I really love it, there are so many answers on such a short time!
Ok thanks! This lightened up my mind. It's not my fault the user didn't read how to work with my engine.
And yes, no one will ever work with my engine because there are better ones.


Hodgman, a long time ago I read you can't make 2 window classes ( WNDCLASSEX ) with the same name. I'm not sure this will call a break error when you try it, but it will do things you don't want to happen. But as you say, waisting time on this I don't really need now. Already got less time


techlord, I'm not sure if "Make your game engine" is bad advice.
I know there are many good libraries. I was going to learn DirectX for my GUI but this year I noticed we get graphics programming next year. And there we will see how DirectX works. And we will make shaders too( vertexshaders & pixelshaders ), these shaders are for our 3D models. ( we make 3D objects in 3DsMax ).

I'm not concerning about pure GUI now because GUI can be very hard to program.
Always creating things from scratch is foolish yes. A friend in my class has made his own string class. All because there is a _UNICODE and with his class he can do everything with the strings & wstrings. ( the type that will be used depends on unicode ).

But I use something else for the unicode


#ifdef _UNICODE
#define tstring wstring
#else
#define tstring string
#endif // _UNICODE


Here is how I start a game in my engine. Might give you some ideas


#include "engine.h"

int WINAPI WinMain(HINSTANCE hInstance,
HINSTANCE hPrevInstance,
LPSTR lpCmdLine,
int nCmdShow)
{
Graphics * graphics = new Graphics(hInstance, nCmdShow);

// parameters are title, width, height, fullscreen
if(!graphics->initialize("Game", 1920, 1200, true))
return 0;

// Main game loop
while(graphics->GameLoop())
{
graphics->BeginRender();

// Render Sprite/Mesh/View etc

graphics->EndRender();
}

graphics->release();
return 0;
}


By the way many professional engines use a similar approach, an example would be leadwerks engine

Thanks !!

I can see you made a pointer to your graphics object. Why haven't you just created an object on the stack?

Thanks !!

I can see you made a pointer to your graphics object. Why haven't you just created an object on the stack?

This way is more OOP (Object Oriented) and it is much easier for the programmer to create new functions and call them from this object. Some times you want to have two instances of the Graphics class so it would give you more control

But will it have more performance? Because calling an object on the stack is faster then calling the pointer that points to the object on the heap.

Ok it is more easier for the programmer but I think it will have less performance.

But will it have more performance? Because calling an object on the stack is faster then calling the pointer that points to the object on the heap.

Ok it is more easier for the programmer but I think it will have less performance.

I really don't recommend using the stack because it is some what limited. I have seen people create objects on the stack but it causes them so many problems like a program crash or exit unexpectedly. Using the heap also might cause memory leaks if the programmer doesn't free the memory. I would only use a stack for primitive types..

But will it have more performance? Because calling an object on the stack is faster then calling the pointer that points to the object on the heap.
Ok it is more easier for the programmer but I think it will have less performance.

It is certainly faster to allocate objects on the stack rather than from the heap because it's a simple stack pointer manipulation. But the actual function call itself on a stack allocated vs heap allocated object is negligible. The key point to remember is that stack space is limited considerably compared to that of the available heap memory. Typically you would want to use a stack variable when it's lifetime is confined to the containing scope and it's size is known at compile-time. You should consider heap allocation should the scope of the object be beyond a simple function call's scope and/or the size is unknown at compile time.

EDIT: As Oxford points out, I prefer to use the stack for primitives as well and any class or structure objects I tend to allocate from the heap unless the context falls in line with where it's use is limited and therefore a stack allocation is sufficient.

[quote name='Oxford Oliver' timestamp='1323372054' post='4891903']
[quote name='turbello' timestamp='1323371705' post='4891898']
I can see you made a pointer to your graphics object. Why haven't you just created an object on the stack?

This way is more OOP (Object Oriented) and it is much easier for the programmer to create new functions and call them from this object.[/quote]
It's really not, and no it isn't. 'More OOP' is a nebulous claim at best, and because you are constructing the instance right there, there isn't any advantage to holding it by pointer (if you were allocating a concrete subclass of an abstract baseclass using a factory, it might be a different matter).

But will it have more performance? Because calling an object on the stack is faster then calling the pointer that points to the object on the heap.

This is the kind of performance question you shouldn't care about at your stage of learning. Any difference is negligible.
[/quote]

What you said is true but he want to do it in C++ not C. What I mean is I could just create a structure and do this

Graphics graphics;
graphics.initialize() ...


That would really look more like C not C++
I would rather use this for variables like
int x; ...
Not a class