• Advertisement
Sign in to follow this  

designing an extremely simple graphics engine?

This topic is 4425 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

hello folks, Up until now all of my c++/OpenGL applications have been limited to a structure like the following: main.cpp (using GLUT) TextureLoader.cpp ModelLoader.cpp TextureLoader.h Texture.h (storage for textures) ModelLoader.h (storage for models, etc) I also had any additional classes that may have been of some use. What I want to do is divide my main.cpp up into a type of graphics core that I can use in all my projects. main.cpp is usually structured like this: include headers define variables loadTextures(){} loadModels(){} // this code just loops through the triangles of any mesh I pass it and helps remove the code from my render function drawMesh(){} RenderScene() { //opengl stuff drawMesh(); //opengl stuff } SetupRC(){} ChangeSize(){} main(){} ---------- Moving on... I want to use Win32 code instead of GLUT to handle my window creation from now on as well. With all that out of the way... how should I structure my project so that it is closer to the model that graphics engines use... ie. programLogic.cpp or main.cpp etc... whatever. graphicsCore.cpp LoadTexture.cpp LoadModel.cpp graphicsCore.h LoadTexture.h LoadModel.h ---------------- Please let me know if I'm not being clear. I don't need actual code here, just a way to structure my files and to know how those files might be structured so that things are a little easier to manage and so that I can pass my graphicsCore and loaders onto other projects in the future. like a very very simple graphics engine. :) no audio, no input, just rendering. Thanks for any and all the help you may offer.

Share this post


Link to post
Share on other sites
Advertisement
You could place all Win32 window initialization code in your main.cpp file, I don't see a problem there -- or did I miss what you were trying to ask?

Share this post


Link to post
Share on other sites
right... but where would i put my program logic, and what about my rendering code?

that's kind of what i'm after. :)

I mean think of the simplest graphics/rendering engine you can think of and how would you structure it. I'm fairly new to the concept of using engines.

Share this post


Link to post
Share on other sites
Ok, upon a second reading I think you're asking how to structure your overall engine code into separate .cpp files. It all depends on how you want to do it. If you want to go the object-oriented way you can create individual classes for each sub-system and create the objects in main.cpp, calling the functions when you need them. If you don't wish to go OOP you can create LoadTexture() and RenderObjects() (or whatever) functions and place them in the appropriate files, calling the functions when needed in the main loop (in main.cpp). I personally prefer the OOP approach and would be more than happy to write you up some sample structure code.

Hope that helps.

Share this post


Link to post
Share on other sites
yes!! I am all about OOP, I came from a Java background. :)

I would love to see samples on how to structure things.

Share this post


Link to post
Share on other sites
Is there a business reason for using Win32?

SDL does a perfectly good job of handling the window creation and updating stuff (ie. hiding the win32 specific calls and WndProc for example)..

Anyways, for projects like what it looks like you're doing, I have a central stdafx.h header file with the function declarations. Then every other .cpp file just includes that one.

main.cpp - game logic
graphics.cpp - rendering logic
sound.cpp - audio logic

etc..

hth,

Share this post


Link to post
Share on other sites
Ok, I cooked up some rough code for you to follow. I don't suggest copy and pasting it directly as I just wrote it in notepad and don't know if it's truly syntactically correct ;) It should however give you a basic idea of what to do, hope it helps.

main.cpp:
#include "graphicsCore.h"

bool MakeWindow();
bool MainLoop();
bool CleanUp();

bool GameRunning;

CGraphicsCore* gc;

int main()
{
//Create a new instance of the graphics core
gc = new CGraphicsCore();

//Put all your window initialization here
MakeWindow();

//Initialize the render scene
gc->InitializeScene();

GameRunning = true;

//Enter the main loop
MainLoop();

//Once MainLoop() returns we can CleanUp();
CleanUp();
};


bool MainLoop()
{
//Note: Your windowing code may play a part in how you
//do your main loop.

while(GameRunning == true)
{
gc->RenderScene();
}

return true;
};

bool CleanUp()
{
delete gc;
gc = 0;
return true;
};




graphicsCore.cpp:
#include "graphicsCore.h"

bool CGraphicsCore::InitializeScene()
{
//initialize the scene, whatever that may mean to you
return true;
};

bool CGraphicsCore::RenderScene()
{
//render the scene
return true;
};

bool CGraphicsCore::DestroyScene()
{
//clean up the mess you made ;)
return true;
};




graphicsCore.h:
class CGraphicsCore
{
public:
CGraphicsCore(){};
~CGraphicsCore(){};

bool InitializeScene();
bool RenderScene();
bool DestroyScene();
};

Share this post


Link to post
Share on other sites
Thanks so much, I'll try out the structure. :) Let you all know what happens. :)

Share this post


Link to post
Share on other sites
You know, this is just the sort of thing I've been looking for as well. Hope you don't mind if I use a similar style,cvg_james...?

Share this post


Link to post
Share on other sites
Well, I managed to get it working. I think I'm going to play around with chopping it up into a few more pieces so it's easier to maintain. Anyway, thanks so much for the help. :)

Share this post


Link to post
Share on other sites
If anyone is interested, I can e-mail my code to you. It is a somewhat advanced codebase I have made that works to black box(put in OOP) everything that you need for OpenGL under Win32. I have support for input and sound/music using DX and OpenGL calls are mostly covered within my class as well. I also have classes that render and animate MD2 models, and a "stuff.h" that has classes for vectors as well as a few other functions, like RandNumber stuff. I don't have it very well commented or documented, but it is pretty easy. If anyone wants it, either e-mail me or post here.

Share this post


Link to post
Share on other sites
I'll take any help I can get, just send it to dockode@yahoo.com. Thanks very much.

---

Plus a new question! [looksaround]

Lets say I have serveral classes describing data like:


class playerMesh
{
public:
playerMesh();
~playerMesh();

//more stuff describing the data that this class should hold
}



Should I put each class into a seperate playerMesh.ccp or playerMesh.h file, or should I combine similar classes (playerMesh, enemyMesh) into a common file like gameEntities.cpp or gameEntities.h?

[Edited by - DocKode on January 4, 2006 11:47:00 AM]

Share this post


Link to post
Share on other sites
Personally, even in a simple engine like this I would separate the concept of a mesh.
I would have a class the describes a generic mesh and then have other classes: Player, Monster, etc, that either privately keep hold of a mesh object (or could be a pointer/reference to a mesh) or it could publicly inherit from the mesh object.

You could even go one better and have a generic Mesh object and a generic Entity object. The Entity class keeps hold of a Mesh, whilst Player, Monster, etc inherit from Entity.

Idealy I think you would have each entity class in a different file. Then you could group all the entity files under a single folder directory.

Share this post


Link to post
Share on other sites
Okay... I've got something basic up and running... but I would still like to seperate my Win32 code from my main project. I would like to be able to plug my Win32 code into any project I want to use and just call it to make a window and then move on to coding. Any suggestions for how to implement such a system?

By the way I'm using Win32 because Windows is the target platform, and libraries like SDL do way too much extra stuff (sound and input), and the maker of GLUT says to avoid using it in larger projects and I think I should follow that advice.

Thanks again guys.

Share this post


Link to post
Share on other sites
It all depends on how you want things structured. gameEntity could be the lowest level common object in the game, and gameMesh could inherit its properties. You could then have even higher level classes called Player and Enemy which inherit from gameMesh. Player and Enemy would then have all the qualities of a mesh and an entity (which, in the end, they both are). This higher level of abstraction (where you start to see inheritance, virtual functions, etc) are overkill for "an extremely simple graphics engine." Just go with what you have now until you want more advanced features. However, when you do want to expand your engine to handle more complex sub-systems, scenegraph management would benefit from the inheritance and virtual functions.

Share this post


Link to post
Share on other sites
Fascinating thread, thank you cvg_james for enlightening me on an OOP structure of game rendering engines. I reckon this would be most useful to me in the future.

Share this post


Link to post
Share on other sites
ild recommend using sdl instead of win32 ( i changed over from win32->sdl about 4/5 years ago + havent regretted it )
reasons to prefer sdl
* simplier
* stability (tested on 1000s diferent hardware configs)
* speed (not to much u can do wrong here though)
* open source with lots of developers (so pretty bug free)
* multiplatform

the only case u may wanna use win32 over sdl is if youre doing a (nongame) app which uses lots of widgets etc

Share this post


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

  • Advertisement