GP2X File Structure

[timbobsteve]

Hi everyone,

A couple of questions:

Question 1: Code and File Stucture (*answered)

I am just getting back into C/C++ programming (gp2x style ) and I wanted to know your thoughts on a few things. While not gp2x specific it would be nice to know what others think.

Anyways.. as you all know splitting a project into multiple files is much easier than one monolithic main.cpp but I am sorta new to this, having only really used M$ based languages (C# and Delphi/Pascal) where multiple files never really came into it, or were handled by the IDE, how does everyone go about structuring things?

I have seen one idea, but I am not sure if its the right way to go. It entails creating a file called includes.h that basically acts as a pool for all includes throughout the program e.g.

// Includes.h

#include "SDL.h"
#include "system.h"
#include "game.h"
#include "player.h"
#include "sound.h"

then every other header file just includes includes.h at the beginning.

For one I can't see this working because system.h will have #include "includes.h" in it and it will in turn include system.h... and around we go... so I don't think this would work very well.

I am starting my first project and want to get it right before going to far into it only to discover that I have to restructure it all. How does everyone else go about splitting a project across multiple files?

I have been putting all header file information between #ifndef statements like so:

// System.h

#ifndef SYSTEM_H
#define SYSTEM_H

	  prototypes here....

#endif

I have been trying to figure it out by myself for a few hours and I think I have gotten a little lost.... Would be nice to have someone help me find my bearings on this.



Question 2: To Objectify or Not?

I am currently writing a 2d engine for a game I want to make. I am using this as my learning project. For someone who has not really programmed anything major before, should I strive to objectify the engine code, or stick with my current procedural codebase?

On one hand it would force me to learn the ins and outs of OOP, on the other... well I am lazy ;D hahahhahaha.

What do you think for a first timer?

EDIT: Added new ? instead of creating new thread.

Thanks.

 

[Dzz]

I have seen one idea, but I am not sure if its the right way to go. It entails creating a file called includes.h that basically acts as a pool for all includes throughout the program e.g.

The "includes.h" approach is one popular way to do this, it saves time figuring out exactly what to include from each source module. The cost is that you include a bunch of stuff you might not need which slows things down a bit. I don't do it myself but lots of people like the approach.

For one I can't see this working because system.h will have #include "includes.h" in it and it will in turn include system.h... and around we go... so I don't think this would work very well.

normally you would not include includes.h from anything except your C/CPP files (so system.h would not include it).

I have been putting all header file information between #ifndef statements like so:

// System.h

#ifndef SYSTEM_H
#define SYSTEM_H

	  prototypes here....

#endif

That also solves the "include files including each other" problem so it is a popular way of dealing with it.

Sounds to me like you're on the right track. Use whichever of these things appeals to you most, you're not off in the forest somewhere doing anything unusual with any of the ideas you have put forward.

 

[timbobsteve]

Thanks Dzz, most appreciated. I think what got me confused was thinking that each header file had to include includes.h as well oops....

 

[yaustar]

This might help:
http://www.gamedev.net/reference/articles/article1798.asp

 

[timbobsteve]

Thanks vaustar.... I did find this article last night when I posted this... but my interweb was playing up and I couldn't access that particular article.... now I can... and it is really really good... gotta love gamedev.net

 

[timbobsteve]

EDIT: Added a new question up the top. Save creating a new topic for a simple question.

 

[luteijn]

EDIT: Added a new question up the top. Save creating a new topic for a simple question.

I'd avoid trying to learn two new things at a time, as it usually doesn't give me synergy, but makes me do worse at both tasks.

Also, I don't think OOP is worth it but that's another holy war .

P.

 

[Parkydr]

I personally use OOP (because I like it and do it for a living), but if you've already got the code, I don't see the point in converting it.

Having said that, games do lend themselves to using objects e.g. a character class with move operations etc

 

[timbobsteve]

Hmmm on one hand objectifying it will make it easier to handle objects as I would already have an object manager in place.... but then again I would have to learn OOP from scratch to do it.

As long as there is no major outcry from people when the word "procedural code" is mentioned I might stick with that. Funny... i thought OOP was the only REAL way if making games... silly me.

 

[Parkydr]

Eeee, young people today, didn't have yer fancy OOP in my day!

 

[yaustar]

Hmmm on one hand objectifying it will make it easier to handle objects as I would already have an object manager in place.... but then again I would have to learn OOP from scratch to do it.

As long as there is no major outcry from people when the word "procedural code" is mentioned I might stick with that. Funny... i thought OOP was the only REAL way if making games... silly me.

You be surprised how many of the current generation games still use C code. . I am doing something similar (making a 2D engine) and doing it in an OO way.

 

[timbobsteve]

I got a copy of Game Programming Complete 2nd Edition, by Ultima4/5/6 Mike, so hopefully that will shed some light on things. I know the examples in the book are all OOP, but I might be able to take some of the architecture from his designs and apply it to my engine.

I can do alot of the basics like player movement, drawing to the screen, basic levels etc (alot of which I got from Sol's SDL tutorialis), but I have no idea how to bring it all together in one cohesive unit.

I keep reading that one feature that is a must is a Messaging system that sits in between the player input and the game objects. Right now that is what is confusing me the most. Everything I have done up until this point involved the player object being moved by detecting key states directly

player_move(bool gKeys[323])
{
	if(gKeys[SDLK_UP] == true)
		player_ypos -= movement_speed;
	if(gKeys[SDLK_LEFT] == true)
		player_xpos -= movement_speed; 
}

NOTE: Thats not really my code, just a quick overview of how I usually do it. I usually have the key-state-tests right in the player_move() function.... and from what I have read this is a really bad way to go about it.

I have also read somewhere, perhaps gamedev.net, that a good messaging system allows for easy implamentation of a quake-style console system... that would be neat for debuging.

OK now I am rambling... Has anyone seen a good piece of code for parsing ini files? Ulitima4/5/6 Mike uses DirectX and there is already a function for doing it easy in that... anyways.

:blink: I got alot of reading to do this week. This is going to be fun.

 

[yaustar]

You can try TinyXML for XML parsing or just write your own ini parser (which is a lot easier in C++ thanks to stringstreams ) Strangely I have that same book in the post at the moment.