BinaryPhysics

I'd actually recommend looking at ANSI C first. There's a lot of subtle stuff that C++ carries over from C (not surprisingly). That said I wouldn't treat C++ as an extension of C so that isn't really a necessity.

Also, I'd definitely look at COM before you look at DirectX. The book Inside COM is great (old though).

Is the far clipping plane the value I pass to zFar in glFrostum?

A viewing frustum has six clipping planes (http://en.wikipedia....Viewing_frustum). OpenGL checks vertices passed to it to see which side of the plane they exist on. If they are within the frustum then they are observable on screen.

You're sort of the right lines with your statement. The value you pass to zFar forms the z-coordinate that is used when creating the frustum.

[source lang="cpp"]glMatrixMode(GL_MODELVIEW);glPushMatrix(); /* perform camera movement */ glPushMatrix();   /* list coordinates */ glPopMatrix();glPopMatrix();glMatrixMode(GL_PROJECTION); /* switch to the projection matrix */glLoadIdentity(); /* load an identity matrix so we don't add to the previous matrix */glFrustum(-aspect, aspect, -1.0, 1.0, aspect / tan(fov / 2.0f), 1000.0); /* create a frustum */glViewport(0, 0, WIDTH, HEIGHT);[/source]

Where 'aspect' is defined as your aspect ratio (WIDTH / HEIGHT) and 'fov' is the desired field of view.

I didn't quite understand the whole idea behind matrices.

A matrix is a method presenting transformations in a coordinate system. OpenGL multiples the vertices that are passed to it by the matrix so that their final position can be determined. For example if you had a rotation matrix R that stored the details to rotate a model by 45 degrees and we had a model (a model is just a series of vertices) then we can multiple all of the points in the model by R and rotate the model.

I didn't really get the idea behind changing to matrix modes and what each matrix does.

OpenGL is written as a giant finite state machine. It contains three matrices - the projection matrix, the modelview matrix, and the texture matrix (I won't talk about the last).

Vertices that are passed to OpenGL are actually multiple by both the modelview and projection matrices. This is odd because it isn't like you can modify the camera in the projection matrix and coordinates in the modelview matrix (this is what I thought when I started).

OpenGL first multiples vertices by the modelview matrix to determine the 'eye'-coordinates. The eye coordinates are the position of the points in the world relative to the camera.

The projection matrix is used for clipping.

I also didn't understand what's the difference between glFrustum and glOrtho and when I should use each function.

They are different methods of projection. Frustum creates the illusion of depth because of the way objects are mapped to the final viewport and Ortho is short for orthographic.

And, I understood that gluPerspective is used as an alternative function to glFrustum, with both functions using different parameters, so when should I use each one?

The answer is that it doesn't really matter. I'm slightly hardcore (or stupid; probably) and I try and use only OpenGL's commands and avoid GLUT and the utility library (glu*). Both glFrustum and gluPerspective dump the same matrix on the projection matrix stack they just allow it to be specified with different ways.

Also, I don't know what's that "plane" that the author is talking about all the time. (probably because of my poor English)

A plane is a mathematical object that has only two dimensions (http://en.wikipedia....lane_(geometry)).

sorry but thats what my problem so i named it as such

This is a compile-time error. It'd be a good habit to get into call errors with their proper name. Initialisation is the issue of a object not having it's data properly set up and is a run-time error.

Everything in C++ must be declared before it is used or the compiler has no idea about what it's trying to use. Function declarations are simple because they just the function header (the header must be identical to the header in the definition).

The brilliant this about declarations is that you could move your function to a different source file and, as long as the function is declared, you are free to use it as much as you like.[source lang="cpp"]# include <stdlib.h>int getdamage(int, int);/* entry point */int main(int argc, char *argv[]){ /* function body */ return 0;}/* return damage */int getdamage(int damagebase, int damagerange){ return damagebase - damagerange += rand() % (damagerange * 2); /* we need to seed rand with a call to srand */}[/source]Also remember that identifiers for arguments in declarations don't necessarily need to be the same (or even exist at all).

You never call to change the seed for the random number function either. With that code you'll get the same effects over and over...

Anddd if you use the standard namespace at the beginning of the source file you don't need to then state the the string type your using is from it. There's no harm in it (in fact it's better to avoid using declarations completely for whole namespaces) it's just redundant.

While explicitly stating which member to use is legal it is ugly and a terrible idea. Not only does it then waste memory by creating multiple copies of the same object but that approach doesn't work when you start sealing off members with access-specifiers.

It works there because you're using a structure.

Just to be perfectly clear, both editor.h and system.h have include guards? You said all the others do.

If your on Visual Studio you can use the [source lang="cpp]# pragma once[/source] directive instead of:[source lang="cpp]# ifndef   __INCLUDE_H_#  define  __INCLUDE_H_ 1/*** include.h - a collection of useful headers*/# endif /* __INCLUDE_H_ */[/source]I tend not to like the first because it's not really a standard directive.

Failing that, I've found that I get compiling errors if I don't leave a blank line at the end of my files. I'm not sure of the technical reason why.

I hope this helps.

Also, you haven't accidently copied the class definition into one of the source files have you? It seems stupid I was adding to my engine the other day and I just started in a source file before I moved parts to a header.

The C Programming Language, Game Engine Architecture, and Game Coding Complete. Brilliant books.

If you wanted to get into DirectX, learn COM first everything makes a lot more sense then. I'd really recommend Inside COM (thought it was published in, like, 1995)..

Just thought I'd be a little more explicit about the concept that you're trying to use (not that any of the information fastcall22 gave was wrong).

Google, or research information about virtual functions and pure virtual functions. That is what you're after.

Functions that are marked as being virtual in a class declaration are able to be overridden by derived classes using that same name for one of their functions. The idea is used in polymorphism.

class Base
{
		public:
				virtual void VAnnounce();
};
class Derived : public Base
{
		public:
				virtual void VAnnounce();
}

In the above example Derived is free (but does not have too) to define it's own function that will be used when an instance is accessed through a pointer to Base.

Base *pBase = new Derived();
pBase->VAnnounce();

The extension, pure virtual functions, indicate that there is no definition in the base class and that any derived types must write there own definition.

class IBase
{
		public:
				virtual void VAnnounce() = 0;
};
class Derived : public Base
{
		public:
				virtual void VAnnounce();
}

Derived must contain a definition for VAnnounce.

Functions that contain pure virtual function become interfaces and it isn't possible to declare objects of that type.

Hopefully that explains what you're after in slightly more detail about the general topic.