Printable View
I'm making a game, or atleast planning, and ran into how I should structure everything. Should I make a separate .cpp for the main menu, or just put it in with my game.cpp? Should I put graphics and loading functions into a separate file? Also, when I get the menu up, and the user selects new game, how should I go about initializing everything? I'm using SDL and C++ with Windows. Thanks!
have a class for each entity in your game (such as a menu). You can also model things like a game configuration with a class (you'd create and populate one based on the users menu input), then your game can use a configuration class to run with the appropriate settings.
You generally want a separate cpp and h file for each class.
1 object=1 source file and 1 header file.
Usually.
>> Should I put graphics and loading functions into a separate file?
For everything like texture loading, window initialisation, timing management etc etc, I create a new Singleton class (derived from the attached singleton base class I borrowed from gamedev.net) and keep the definition in a .h with the implementation in a .cpp. Also, I have one .h that is a sort of inclusion point for all standard headers which gets #include'd in just about every .cpp.
The project I'm working on right now is something I want to be able to re-use. 80% of what I've written can be used a base for any number of games (and replacing the rendering / windowing code takes about 20 minutes).
EDIT: Oh yeah the Singleton base:
Code:#pragma once
/*
Singleton
Base class for all singleton classes.
*/
#include <assert.h>
template <typename T> class Singleton
{
static T* ms_singleton;
public:
Singleton()
{
#pragma warning(disable :4311) // Pointer truncation from <class> to 'int'
#pragma warning(disable :4312) // Conversion from 'int' to <class> of greater size
assert(! ms_singleton);
// use a cunning trick to get the singleton pointing to the start of
// the whole, rather than the start of the Singleton part of the object
int offset = (int)(T*)1 - (int)(Singleton <T>*)(T*)1;
ms_singleton = (T*)((int)this + offset);
#pragma warning(default :4312) // Conversion from 'int' to <class> of greater size
#pragma warning(default :4311) // Pointer truncation from <class> to 'int'
}
~Singleton()
{
assert(ms_singleton);
ms_singleton = 0;
}
static T& GetSingleton()
{
assert(ms_singleton);
return *ms_singleton;
}
static T* GetSingletonPtr()
{
assert(ms_singleton);
return ms_singleton;
}
};
template <typename T> T* Singleton<T>::ms_singleton = 0;
When using someone else's code, please give credit to that person. This code is part of a tutorial on GDNet. As for singletons, I would much rather use a namespace than make singleton classes. It's much more simple and cleaner in my opinion. Also, I prefer not to make everything an object. Doing so is just as bad as never using OO. People either abusively use it or never use it, this is wrong, in my opinion.
As for the OT, I would make a different header / implementation file for each module / sub-module.
Yeah because I was so looking forward to going surfing around gamedev looking for his name while planning my reply.
So even though my designs "click together" and expose an interface that is easy to use and maintain, I've been abusing OOP? Looks like I've got to redesign my whole project.
:)
I didn't say you were. I'm just saying that sometimes people go crazy about OOP and will make classes like this one:
I'm exagerating (sp ?) a bit but I've seen people abusing OOP.Code:class LightBulb {
public:
LightBulb() : state(false) { }
LightBulb(bool s) : state(s) { }
LightBulb(const LightBulb& lb) : state(lb.state) { }
bool IsOn() { return state; }
void SetState(bool s) { state = s; }
private:
bool state;
};
Well your light bulb class would work just fine given a 3D graphics API. You could control the exact state, graphic technique, etc, etc. You could then add the light bulb to an array of allowed light sources to be used by the engine shader.
So that's not abusing OOP. The only abuse I've seen here of object oriented code is not using it when you should be.
Your light bulb class would be perfect for a game. I don't see the issue. And the singleton class might be from gamedev but ahluka engineered it to fit into his game engine for his purposes, which I see no problem with.
You don't see the problem ? The whole class is the problem. You could have a single boolean variable and it would be just as good without all of the hassle that comes with the (useless) LightBulb class. Besides, having Get/Set methods without doing anything more than returning the variable itself and setting the variable without doing any other computation (such as resizing a window or adjusting the value of other variables or whatever) is completely useless. The variable could have been public and it would have done the very same job. If you only needed booleans to know if a LightBulb is on or off a vector or an array would have done the job just as good with much less crap involved.
My article on the subject.
http://code-dynasty.net/articles/C_A...Programming/83
Edit: Added link.
Edit2: I don't care if he uses the code, he has the right to; however, he didn't even mention that the code wasn't his.
It depends on how you are using the class. If a light bulb is more than just a boolean then the class is perfectly fine.
Perhaps your use of 'light bulb' as an example on a game programming board wasn't the best idea. A light bulb or a light source in a game is a helluva lot more than a boolean.
And his singleton hardly qualifies as a non-object. He is probably going to use it for a texture manager or some other resource manager. He has way more than just a boolean so your example for this post is invalid.Code:class LightSource
{
LP3DXBUFFER *m_pShader;
D3DXVECTOR3 m_vecPos;
D3DXVECTOR3 m_vecDir;
D3DXCOLOR m_Ambient;
D3DXCOLOR m_Diffuse;
D3DXCOLOR m_Specular;
...
};
class LightBulb:public LightSource
{
...
};
Perhaps in another post your problem has merit, but for the context of this one, I don't see that it does.
Your code is fine ahluka.
It's not his.
http://www.gamedev.net/reference/art...rticle1954.asp
Look toward the end. The author says himself the code is from a book.
Are you guys purposely stupid ? It was an example of abuse, I didn't point out anyone and said they were abusing OOP. I was simply stating that going all OOP wasn't the best idea as sometimes you can code something much simpler that will do the same thing. In the case of Singletons, I prefer using namespaces.
That is just your opinion. Who are you to say what is right and what is wrong and who is stupid and who is not?
Did I say I was correct ? No.Quote:
Originally Posted by Desolation
We've all posted stuff here from books. Hell most algos in games are from books. That is the general idea of Game Programming Gems, Shader Gems, etc, etc.
Nothing is original and it is the free sharing of information and code that grows the industry.
Ahluka not quoting a public site like gamedev IMO is no big deal. It's obvious to me if it's found in several books and sites then the info is probably commonly known as is no longer qualified as original or stealing if you use it. It's obvious the creator of the code did not intend on copyrighting it and was just sharing information.
We are not writing academic posts here with quotes and references and as well Ahluka has demonstrated research and knowledge in this area as well as the ability to adopt complex concepts and use them in his own design.
To me that's called a game programmer and he doesn't need ridiculed by someone like you with a beef that's assinine as yours.
And yet you are the one who has responded to the this thread with an issue that isn't even related to the topic at hand?Quote:
Are you guys purposely stupid ?
I'm not even going to get into 'how you should layout your source code' because my stuff has tons of functionality laid out in a completely disorganized mess.
I will say, however, that I want to psycopathically murder the inventors of the C++ programming language.
EDIT:
>>When using someone else's code, please give credit to that person.
He replied with this:
>>derived from the attached singleton base class I borrowed from gamedev.net
and that's good enough. I really didn't even expect him to say it was from a tutorial on GDNet, because I don't really care. Please stop being a douchebag. I'll defend ahluka with all of my might, and I'm pretty mighty.
:)Quote:
I'm not even going to get into 'how you should layout your source code' because my stuff has tons of functionality laid out in a completely disorganized mess.
I will say, however, that I want to psycopathically murder the inventors of the C++ programming language.
In certain terms I wholeheartedly agree. C++ is often deemed as a higher language than C yet the more you use it the more you realize that it can be higher, as long as you are willing to write the low-level base classes and functionality in a way as to be usable and efficient.
A lot of times my code gets to be a huge mess and so I feel your pain Bob. C++ is awesome but man it's also so friggin annoying.
:)
>> In the case of Singletons, I prefer using namespaces.
I don't understand your reasoning for that.
Namespaces are a way to, well, name a space. As far as I'm concerned they are not part of OOP; they're not something you really use in a design unless you know you're going to be colliding names with the STL or another library.
How the hell do they function as a Singleton? I guess you could have a global (namespace level) variable and a function to work it like a singleton but then it's just a whole bunch of C-esque clobber wrapped in a name.
You might not like this because it is not OOP but this is still a good replacement solution. I'll translate a passage of my French version of Bjarne Stroustrup's The C++ Language about namespaces.Code:namespace Whatever {
/* typenames and function declarations */
/* here you can have globals */
};
"A namespace is a mechanism allowing one to make logical groupments. That is if some declarations can be associated following some criterions." (p.188 ch. 8.2)
You know, a class is also, technically, a namespace. The only difference between a namespace defined using the namespace keyword and a singleton class is that at least with a singleton class you have an object that you can use to communicate through other constructs of your engine (e.g. if you do ultimately have a very OOP design...I don't like OOP designs but it also may help people understand their layout better...it's sort of a personal choice if you're an amateur programmer).
My point is that you do not need to go all-OOP.
I keep things pathologically simple...the simplest design that works is always my path of choice. I choose ugliness and simplicity, with only very very basic object oriented constructs. Granted, everything I do is object oriented, but only in nature (it would make just as much sense if everything I am showing you was just a bunch of functions in .h and .cpp files).
So, lets look at a few of my classes, I've got a few biggies:
-glrenderer
-texture manager
-frustum
-bsp
and a few others which I won't post. Collectively, these classes make up the data and functionality which make up the engine. None of these are singleton classes, I could technically create more than one instance of each, but I don't (no need).
In my main module, I create these objects, globally. Through them you can access and manipulate data. When I want to access these objects, I either use the extern keyword and/or pass them into a helper function as a parameter (Yes, I know, a lot of this is particularly inefficient and slow, e.g. accessing global variables, esp through pointers, is probably the most inefficient computationally speaking).
This is at the top of my main module:
Here's how a hovertank accesses the engine functionality to be able to render itself (adding a ms3d model to the renderer, along with some debug stuff, on top of doing a frustum test):Code:
//All of the main game engine variables
GLRenderer *gpGLRenderer = new GLRenderer(50000,50000);
NTGLAPI *gpNTGLAPI = new NTGLAPI("OPENGL32.DLL");
TextureManager *gpTextureManager = new TextureManager;
FPS_t *gpFPS = new FPS_t;
Frustum *gpFrustum = new Frustum;
BSP *gpBSP;// = new BSP;
TextManager *gpTextManager = new TextManager(500);
PhysicsManager *gpPhysicsManager = new PhysicsManager(100.0f, 5.0f ,METER(5.0f));
That's the design I use...brute and ugly but ultimately very useful and reusable, easy to design and maintain, etc. I started my design where *everything* required for the engine was in a single interface, but because of that build times went through the roof (change one thing that uses the engine or is the engine functionality to itself and nearly everything in the project is completely rebuilt, whereas with this I can create a palette of the functionality I need).Code:#include "Hovertank.h"
#include "GLRenderer.h"
#include "Quake3BSP.h"
#include "Frustum.h"
#include "TextManager.h"
#include "PhysicsManager.h"
#include "FPS.h"
#include "GameExport.h"
extern GameExport Export;
extern BSP *gpBSP;
extern GLRenderer *gpGLRenderer;
extern Frustum *gpFrustum;
extern TextManager *gpTextManager;
extern PhysicsManager *gpPhysicsManager;
extern FPS_t *gpFPS;
....
void Hovertank::Render()
{
if(gpFrustum->SphereInFrustum(CurrentState.mPosition,mRadius))
{
Matrix4x4 final_render_mat;
final_render_mat.SetTranslation(&CurrentState.mPosition);
final_render_mat = CurrentState.mMat_Orientation;
gpGLRenderer->AddMS3DModelToRenderer(final_render_mat,mpModel);
}
}
workspace