Advertisement Jump to content
Sign in to follow this  
turbello

Writing a game engine

This topic is 2590 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

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. :wink:
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 :rolleyes:


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

Share this post


Link to post
Share on other sites
Advertisement
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

Share this post


Link to post
Share on other sites
Thanks !!

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites

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.

Who knows? Why don't you profile it instead of making guesses - because, you know, that's how real programmers do it.

Also, negligible performance improvements are best left alone until you really need them.

Share this post


Link to post
Share on other sites

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..

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

[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.

Share this post


Link to post
Share on other sites

[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

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!