Jump to content

  • Log In with Google      Sign In   
  • Create Account

Calling all IT Pros from Canada and Australia.. we need your help! Support our site by taking a quick sponsored surveyand win a chance at a $50 Amazon gift card. Click here to get started!


Member Since 16 Mar 2012
Offline Last Active Aug 28 2012 12:52 PM

Topics I've Started

How does a nobody actually make a game?

12 August 2012 - 03:10 AM


This is a purely hypothetical question.

Suppose, I actually had a great idea for a game, and suppose, that were it to be produced, it would not only be hugely successful, it would be really big. Just suppose.

How does someone like me (a little knowledge of c++ and a good idea of how to develop this game IF I had a big wad of cash) actually go about getting it done?

I see thread after after thread (all over the net) advising not to bother/it'll never happen/do something else, but there are obviously people who have managed to make it happen. So what do they do that's so different?

Essentially, what I am asking is this:

Suppose I have a great enough idea for a game (an some idea as to how to execute the design), that you're convinced it will, if made, be a phenomenal success. What would you suggest I do with it? Send to Eidos? Approach the bank? Slog away in my own time for the next 12 years?

Honestly, there must be some way of doing this.

Nested Classes ~ I think

08 May 2012 - 03:41 AM

Edit: Sorry, I should have said, this is c++.

Could someone please help me out with some code.

I have a global class - cGameEngine.

I have two other classes - cRenderEngine and cGameStates.

cGameEngine manages the game, initialises the other two classes and manages the game states.

cRenderEngine handles OpenGL, and cGameStates is an abstract base class from which I derive my game states - InitialState, PlayState and so on.

So far cGameEngine initialises cRenderEngine on creation and has functions to Model 3D, 2D and to render - called through the renderengine object.

cGameEngine also creates a game states stack, and initialises some game states.

So far so good (although I have no idea if this is a wise way of doing things - it's as far as I've been able to work out).

What I want to happen, is for the game states to handle the renderengine though the gamengine object.

I can get the renderengine to function through the gameengine object, because the renderengine object is a member of the game engine object, but I can't get the game state objects to access the gameengine object, because the game states are object members of gameengine.

I understand that I need to pass a pointer from gameengine to the game states, but I can't find how to do this with out upsetting something.

I've managed to find a way to pass a gameengine pointer as far as the gamestates base class, but it isn't inherited by the derived game state objects, and gives me an error regarding explicit and default constructors.

Could some body please provide the code I would need to add to the cGameStates abstract base class, and the derived gamestate classes.

Also, is this a sensible way of doing things? It seems pretty tidy, but I'm a bit worried about memory leaks and so on, not really knowing how to look for them.

Thanks to everyone looks and/or comments.

VBO error

04 May 2012 - 04:55 AM

Can someone please tell me why this piece of code is not working? I've been messing around with it for days.

If I enter the vertex data in immediate mode (glBegin/glEnd) it renders with no problems.

So what am I dong wrong?

float Vertices[9] =
300.0f, 200.0f, -1.0f,

350.0f, 150.0f, -1.0f,

250.0f, 150.0f, -1.0f
void DrawTriangle(int numVertices, float Vertices[])
glGenBuffers(1, &VBOID);
glBufferData(GL_ARRAY_BUFFER, numVertices*sizeof(float), &Vertices[0], GL_STATIC_DRAW);
glVertexPointer(3, GL_FLOAT, 0, 0);
glDrawElements(GL_TRIANGLES, 9, GL_FLOAT, &Vertices[0]);
glDeleteBuffers(1, &VBOID);

This is ultimately going to go back into the class it's failing to work in. It took me a day to wok out that the this bit of code is what is wrong with it. It was a long day.


Efficient vertex arrays

16 March 2012 - 02:22 AM

Hi all,

I'm new to this site and c++ programming and openGL and, well, all of this. But I have been making steady progress. I'm fairly confident with c++ (syntax not withstanding) and have gotten to the stage where I can create a window, create some objects and move them about. I'm now going over what I now and trying to make it as efficient and functional as possible.

So far I have progressed from entering all object generation methods between glBegin and glEnd tags directly in may game loop, to creating object generation classes for much simpler object specification. I am now trying to creating a method that enables polygons and objects to share vertex references, minimising the number of necessary calls.

This is the bit I need a little guidance on.

What I am hoping to do is the following:

Create an array of vertices for each object (the vertex array will also hold normal, texture, etc information).
Create an array of vertex references.
Construct objects using vertex references, enabling my polygons to share vertexes.
Add simple functions for constructing and manipulating objects.

I'm pretty comfortable with all of this, however I was wondering how sensible this approach is; whether it is the most efficient way of doing this, whether I have forgotten or overlooked something, or whether the openGL vertex array method would render this approach redundant.

I've looked through the specification regarding the openGL vertex array method and am assuming it basically does what I am intending to do, though (I think) in a slightly less efficient way.

I've also read somewhere suggesting that using glBegin/glEnd is to be avoided. The draw functions within my object generation class would use this method, though it would be specifying vertex data through references, rather than literals.

Also using my own vertex and reference arrays, I am making my classes a bit more universal ( i.e. not so bound to openGL). In case that matters. Am I correct I'm this assumption?

Does anyone have any suggest/advice/input?

I'm eager to do as much of this myself as possible, but I certainly don't want to start getting myself into any bad habits.