BinaryPhysics

On a side note what is the difference between lg and log?

Different subjects deal with different bases regularly and so tend to be lazy and create small notation.

 

'log' written on its own should be assumed as base 10 if a base isn't specified, 'ln' is to the base 'e', and 'lg' I think is commonly base 2 but that notation is fairly informal (is my understanding).

Everytime I talk to someone about game programming they always say "just do it". So "just doing it I am". However, I was wondering if I could get a slight bit of feedback on my current idea. I'm going to keep pursuing it until I hit a brick wall for educational purposes but I was curious how common this kind of structure in a game is.

 

I was recently reading a book that brought up the concept of a 'system'. Systems have inputs, outputs, feedback mechanisms, etc. It occured to me that all game engines are just a series of systems (and the award for over-simplification of the year goes to...!).

 

My current structure simply involves all game parts (input manager, rendering engine, networking) inheriting from an interface ISystem. This makes all systems completely isolated from each other.

 

Systems can also contain subsystems. If the game itself is a system then it can contain a input manager system, a rendering system, and so on.

 

The way I've defined the interface means that systems can communicate via a message passing interface. Messages derived from an IMessage interface and carry their type with them so that certain systems can receive specific information. I've previously looked at DOOM-3's source in brief and after reading 'All Signs Point to "No-No"' here (http://www.gamasutra.com/view/feature/132500/dirty_coding_tricks.php?page=2) I figured this was a better idea than enforcing simple packing.

 

Systems keep an output-restricted deque to allow important messages to skip to the front of the message handling process.

 

This is my first real project and I was really wondering what someone with actual experience thought of this idea. Have I been paying attention to everything I've been reading in books/online or have I missed the point entire and should probably be shot.

 

Thank-you for any comments.

Something that'd make life easier for sharing code like this would be GitHub; it'd also mean you wouldn't need anyone to worry about mentally filtering out object files or generated executables. But that's completely off topic.

 

It's nice to see somewhat consistent formatting. Definitely a great start.

 

Only thing I can really see is the use of the 'TYPE' enumeration in 'entity.h'. You've tied the entity class quite heavily to it but you've kept the enumeration outside of the class. I'd recommend putting the definition of the enumeration as a public member of the class. It means if you copied the class you'd not accidently forget about including it.

 

EDIT: Also, Bjarne Stroustrup recommends making base classes take care of themselves. You've provided an interface for tracking member changes but you've also made all the members 'protected' giving derived classes access anyway. Make them private and force access through through functions; at least that way you can enforce value ranges, etc in an easier fashion.
 

I'm going to be honest. I actually prefer 'pragma once' now. It's not 'standard' (before everyone has a go at me, I mean that it isn't written in the standards document that describes C++. Yes a lot of compilers support it but no-one is required to) so you can't write absolutely 100% portable code.

 

However, for my current project I use several other Visual Studio specific additions of pragma so I'm not concerned with portability. 'pragma once' has the added benefit of possibly speeding up the compile time as the compiler can refuse to open the file again.

 

That said if you wanted to go back to include guards Google's C++ programming guide dictates that include guard names are written as $(PROJECT_NAME)_$(FILE_DIR)_$(FILENAME)_H. I thought that was quite a simple and elegant method of generating unique guards.

My friend introduced me to Git last year and I use it for everything. It's an amazingly powerful tool and its documentation is unbelievably complete. Particularly with a branching model like git-flow.

'typedef' is considered grammatically as storage class. It aliases types (it does not create new types).

C/C++'s grammar is, at least in my opinion, beautiful because everything can be reduced to the same make-up:[source lang="cpp"][type-qualifier] [storage class] type-specifier declarator [= initializer];[/source]Where 'declarator' is:[source lang="cpp"][type-modifier] identifier[/source]There's a few subtlies I fail to capture there but I recommend reading about it.

Anyway, a type-modifier is like a pointer or a function call. But each type-modifier can be place inside another recursively  this means you can build a theoretically infinitely deep type.

The issue is that the operators bind slightly differently. But you can use parentheses to force certain 'alignment' (just like you can in normal expressions.

This means that while:[source lang="cpp"]char *fn(void)[/source]is a function returning a pointer to a character (because the function-type modifier binds more tightly than the pointer modifier)[source lang="cpp"]char (*fn)(void)[/source]is a pointer to a function that takes no arguments and returns a single character.

Using 'typedef' as the storage class means that the identifier becomes an alias for the type you have just created. So:[source lang="cpp"]typedef char (*fn)(void)[/source] aliases a new type 'fn' that can be used to specify when a pointer to a function taking no arguments and returning a character is required.

This technique is used extensively for callbacks and often in COM (which I imply from the code you've presented).

Just remember that identifiers aren't allowed to gain 'function status' through type-defines. That is you can't do:[source lang="cpp"]typedef char *fn(void)fn a, b, c;[/source]

'pragma' is used to express implementation dependent preprocessor statements. The idea, the use of 'once' that is, (as far as I know) is specific to the compiler that Visual Studio uses. Such a technique isn't portable if you wanted to jump to a different compiler.

It is a far, far better idea to use header guards (defining a macro constant and testing for its existence) because all parts of the construct are standard compliant.

With respect to whether you should use it everywhere take a look at translation units and use the '/C' and '/P' flags for cl.exe; that spits out a pre-processed source file. Really the idea only needs to be used in header files because they are the only things that should really be 'included'.

There's no harm in using it in every file. In fact it probably makes your life easier in the long run in case you start re-adding the file elsewhere. That said, if you can guarantee you'll never include the file in another header then you can leave it out because it's not needed. Like I said though, probably easier to just get into the habbit of guarding every header for the delayed convenience.

I cannot think of any reasonable justification for a complete beginner learning C++ over something like C#. "Complete freedom" for a beginner = enough rope to hang yourself many times over.

This is such a negative outlook. Yes, C++ doesn't provide all the comforts of C# but what you might learn from repeatedly tying your own noose is invaluable.

Really C?
It isn´t even object oriented. Thats definitly not what you want to do if you want to get a game dev. Objects are the base of a game. C seems to be the worst decision for a beginner

My apologies but this attitude pisses me off. It is perfectly possible to do small projects in C. Hell, the original Quake is in C (complete with source code available online). OOP is not the be all and end of of life. People need to stop being so hung up on it.

Um. I'm not totally sure. If you wrote everything yourself from the ground up maybe 2 years? You could cut that down if you started using external libraries like Bullet Physics. Please don't quote me on that figure (it's nothing more than an guesstimate and I would hate to present you with fictional information).

What you want to do is absolutely obtainable but I think it would be a good idea to sit down and look at C++ first. The best piece of advice I ever saw was "know your language". You don't want to be wondering why something won't compile simple because you don't understand what you did wrong with a library function or syntax.

Also if you want to write 'big' projects I cannot rate something like Git (http://git-scm.com) more highly. There's a lot of cool project GitHub too (https://github.com/). A book I own is Game Engine Architecture (http://www.amazon.co.uk/Game-Engine-Architecture-Jason-Gregory/dp/1568814135) which demonstrates the complexity of such systems.

Ultimately I think just starting a language is the best way to go. Learn syntax, learn the standard library, and come up with projects. There's a lot to learn. Don't get distracted or discouraged.

From a beginner standpoint you'll probably not end up using the features in which they differ. Intelliesence is much nice in VC++2012 though.

C++ is great because it allows complete freedom in the style you use. I think it'd be better of C# simply because of this. It's standard library is organised in a slightly odd way (coming from C) but I'd say it'd introduce you into more, faster.

Actually, I learnt way more using NMAKE; but then I'm not sure where you stand in terms of previous experience. NMAKE means you don't generate all those extra files from Visual Studio that detract from what your actually doing. Points out what your actually doing far more.

MessageBoxA(0, str, "Memory leaked!", MB_OK | MB_ICONWARNING);

You make this call multiple times. Don't. Just use 'MessageBox'. The reason that there's a macro defining the name is for character width (I think).

In Visual Studio 2010 click on the project that you want to view the files for within the solution explorer.

Then, under where it says "Solution Explorer", click the second icon along (if you hover the mouse over it, it says "Show All Files").

I have a non-terminated string [...]

'sz' is the Hungarian prefix for a zero-terminated string. Only use it if you indeed mean what rip-off has assumed.

The problem that I am having is that when I try to compare with if() statements the result is never true.

[source lang="cpp"]if(szParam == "player") /* compare the address of szParam to the location where "player" is stored */[/source]

String literals are actually constant pointers. It isn't possible to compare them this way because you're trying to compare two pointers and not the data they point to.

The easiest method would be to use strncmp in the Standard C library. It obeys the rules that arkane7 stated but allows you to specify a maximum number of characters to compare.

[source lang="cpp"]if(strncmp(szParam, "player", sizeof("player")) == 0){ /* the two strings are equal */}[/source]

Remember that str{n}cmp is a character-by-character check of two strings. If one string is longer than the other you'll flow over the end of the smaller string.

If you *really* want to learn C++ as your first language, try to avoid the C parts of it as long as possible.

Just to jump in (imagine that! Joining a discussion on a forum; madness) but this is a terrible, terrible idea. Learning C either alongside or before or after is a great idea. C++ articles and books tend focus a lot on treating everything as a class. Everything everywhere (at least in my experience).

Stuff that uses C tends to have a tighter focus on small programs and I learnt a lot about memory through it.

It's just important to note that C++ doesn't simply extend C.

As far as i understand it, you need to learn a programming language and how to program.

This is also a very, very good point. Don't forget to study outside the language you're learning.

Just as a side note - that code comes with a solution file for Visual Studio. If you download that you can right-click on any variable, constant (basically any identifier) and click "Go To Definition".

Brilliant tool for looking at other people's code.