3D engine project

Why are you so desperate to get rid of the entire STL? I mean, a 3D engine is nice, but why not simply use the STL rather than re-write all you need? In some cases it may be faster, but I wouldn't bother with it until you can actually proof it's faster. I think these is merely premature optimization.

Also, have you drawn out the design of the engine yet? Like a UML diagram?

The STL fills the executable with lots of useless information. For example, when i use iostream the output file is more than 400 KB in size, for a simple "Hello World!" program.

Originally Posted by EVOEx

Also, have you drawn out the design of the engine yet? Like a UML diagram?

I will, i just need to build the core files first.

Originally Posted by Sipher

The STL fills the executable with lots of useless information. For example, when i use iostream the output file is more than 400 KB in size, for a simple "Hello World!" program.

Just like any other sizeable library out there, including your own. However it will be added only once. So those 400K -- or whatever in the end it amounts to -- are not going to grow in size as your project does.

Just some quick comments . . . .

Code:

142 	const matrix4 operator* (const matrix4& other) const{
143 	return matrix4(mat[0]*other.mat[0] + mat[1]*other.mat[4] + mat[2]*other.mat[8] + mat[3]*other.mat[12],
144 	mat[0]*other.mat[1] + mat[1]*other.mat[5] + mat[2]*other.mat[9] + mat[3]*other.mat[13],
145 	mat[0]*other.mat[2] + mat[1]*other.mat[6] + mat[2]*other.mat[10] + mat[3]*other.mat[14],
146 	mat[0]*other.mat[3] + mat[1]*other.mat[7] + mat[2]*other.mat[11] + mat[3]*other.mat[15],
147 	mat[4]*other.mat[0] + mat[5]*other.mat[4] + mat[6]*other.mat[8] + mat[7]*other.mat[12],
148 	mat[4]*other.mat[1] + mat[5]*other.mat[5] + mat[6]*other.mat[9] + mat[7]*other.mat[13],
149 	mat[4]*other.mat[2] + mat[5]*other.mat[6] + mat[6]*other.mat[10] + mat[7]*other.mat[14],
150 	mat[4]*other.mat[3] + mat[5]*other.mat[7] + mat[6]*other.mat[11] + mat[7]*other.mat[15],
151 	mat[8]*other.mat[0] + mat[9]*other.mat[4] + mat[10]*other.mat[8] + mat[11]*other.mat[12],
152 	mat[8]*other.mat[1] + mat[9]*other.mat[5] + mat[10]*other.mat[9] + mat[11]*other.mat[13],
153 	mat[8]*other.mat[2] + mat[9]*other.mat[6] + mat[10]*other.mat[10] + mat[11]*other.mat[14],
154 	mat[8]*other.mat[3] + mat[9]*other.mat[7] + mat[10]*other.mat[11] + mat[11]*other.mat[15],
155 	mat[12]*other.mat[0] + mat[13]*other.mat[4] + mat[14]*other.mat[8] + mat[15]*other.mat[12],
156 	mat[12]*other.mat[1] + mat[13]*other.mat[5] + mat[14]*other.mat[9] + mat[15]*other.mat[13],
157 	mat[12]*other.mat[2] + mat[13]*other.mat[6] + mat[14]*other.mat[10] + mat[15]*other.mat[14],
158 	mat[12]*other.mat[3] + mat[13]*other.mat[7] + mat[14]*other.mat[11] + mat[15]*other.mat[15]);
159 	}

A loop won't kill you. Any compiler worth its salt will unroll the loop if it's worth it when you turn on optimizations. Plus it's much less error-prone and more readable.

I'd definitely use the STL. We all know you can write a linked list class. But why waste time doing it now? You'll probably have a few tiny bugs to fix and it will be a bit slower and discourage other programmers from using your code. Imagine all the software a typical game uses. I'll simplify greatly and draw a dependency diagram like this (stuff on top depends on stuff below):

Code:

game
renderer, physics, sound
STL, packets, image loader
operating system
compiler

[That's a really silly stack, but bear with me.] You're not writing your own compiler, right? No, you're using someone else's. You're not writing your own operating system, right? If you want to target the middle of that stack wherever "game engine" fits, then don't worry about trying to reproduce everything that lies underneath . . . because if you don't trust the STL, why are you trusting TCP? Why are you trusting that handy BMP loader you found on the internet? Etc.

Regarding the design of vectors: I once wrote a fairly large OpenGL project where I had separate 2D and 3D vector classes. It was a huge pain, having to convert between them all the time. You think it will be easy, but somehow, it will come back to haunt you. Mind you, I didn't make vector3 inherit from vector2, that's an interesting idea. But I think it will still backfire. What if you want a function like length(), which is different for vector2 and vector3? If you have a vector3 which you pass to a function expecting a vector2, the length() might report something unexpected. And you wouldn't want to make the function virtual because virtualness is a bad idea for something as primitive as a vector.

I'm not saying that your design won't work. It probably will. Just spend a few minutes thinking about all the ways you're going to use this code and how you need to convert between the classes. In a different project of mine I created a 4D point class which I used almost everywhere. Even for places that needed just two dimensions. And then later on in the project I created other point classes, such as a WidgetPoint for the GUI, which was 2D but also understood the overall dimensions of the screen; and other point classes for texture coordinates, and screen coordinates (which were different from GUI ones, since GUI coordinates were subject to scaling). It allowed for a nice evolution. I'm not saying you should do this, but at least think about it a little.

Now, if I were you I'd be asking the harder questions about game design. For example: is this game engine going to support networking? If you allow for networked physics then it influences the whole design, because certain parts of objects can be serialized and sent over the network, and other attributes are clearly local or recomputable from the primary attributes. What is your object (I mean physical/game object) heirarchy going to look like, if you have a predefined one? It may be a good idea to separate physics from rendering and from general game state, have separate inheritance heirarchies for each. Then use composition rather than inheritance to build game objects, so that a box can be a Box class with SolidRenderer and a MobilePhysics component (google "composition versus inheritance").

Are you going to allow multithreading at all? (I suggest not. Really.) How are events going to be communicated between different components of the game? Having a good event system for communicating between components makes your life a lot easier. Imagine being able to say EMIT_EVENT(new ClientConnected(client)) and then somewhere else write an observer which automatically sends an updated world to this new client. Sorry, I have multi-player game engines on my mind. But you know what I mean.

All this to say, don't take my words to mean "You'll never succeed, give up now." The only way to get better is to try something. Just don't be surprised when it breaks, or your design was horrible and you have to refactor *all* of the vector code, or you leave in ad-hoc printing for so long that it's a nightmare to start using your new logging system, or you create a brilliant settings system which is never used anywhere, or your resource loader became an absolute mess when you were looking the other way and just adding one line at a time. Spend a little bit of time thinking about your options, maybe post a question here or there. Rewrite what needs rewriting. You've gotten started, which is one of the hard parts. Keep at it!

P.S. These are just my ideas of what's important for a game engine. Other people have different insights. No one said you had to listen to me.

Firstly, thank you for taking the time to read what i've done so far.

I don't use loops for the matrices because i want the engine to be close to its release speed when i'm debugging it. If a compiler, at least gcc, doesn't optimise, and optimisation is rarely used with debugging, then none of these improvements are made.
I hear you about the STL, and i agree that it's a pretty useful ready-for-use library, but i'm designing something very smaller for the needs of the engine only.
About the vectors, just as a 4D homogenious vector can be added to a 3D vector, i wanted the same to happen for 3D to 2D. Now all these dimensions are linked together.
Now about multithreading, it seemed silly to me at first that physics and rendering are used to be done separately, in different threads. But it's obvious that if a CPU has more than 1 cores, the engine is almost sure to benefit from.
Networking... hmmm... i'll think about that later!

Thanks for your pointers!

Honestly, I was interested in helping. But your answers, and dwks's post snippet (I missed that one) and the lack of a design (at least drawn out somewhere) kind of stopped that.

Originally Posted by Sipher

I don't use loops for the matrices because i want the engine to be close to its release speed when i'm debugging it. If a compiler, at least gcc, doesn't optimise, and optimisation is rarely used with debugging, then none of these improvements are made.

Well, I guess that's a good reason. If you have a good reason for this reason. I mean, why would you want the debug speed to be remotely similar to the optimized speed? There's really no point, unless you want to run a game in debug mode, which is kind of useless anyway.
I'm not saying it's not slightly useful to have a good debugging speed. I'm just saying that it's pretty surely not worth so heavily impacting readability and increasing the likeliness of bugs.

Originally Posted by Sipher

I hear you about the STL, and i agree that it's a pretty useful ready-for-use library, but i'm designing something very smaller for the needs of the engine only.

So you want your engine to be as small as possible as well, at the cost of more readability, writeability (both for coders not exactly knowing the syntax and internal workings of it), likeliness of bugs and time to spend coding? Just so that the library is 400k less in size? I'm not sure I understand that either. I mean, in what case could you possibly care about 400 kb for a game? Maybe *MAYBE* you could care a tiny bit for a phone-based game or something similar with little ram/disk space available (but then again, this is Windows based). But even for phones people won't really care much for 400 kb. It's maybe a few seconds of extra downloading, a few pictures they might have to delete, worst case a single mp3...
But at least you saved 400 kb...

Maybe you should do an STL implementation project first, where you don't have to link to every feature but only to the ones you use... Not only can you save 400 kb in your library, but you could help anybody wanting to save 400 kb in their project.

Seriously, you should re-consider your choices and their consequences, positive and negative, and make sure the positive weigh out the negative, because I highly doubt it. And judging by some other replies, so do some others. Your code itself looked good to me though, with the exceptions I noted.

Don't get me wrong, I wish you the best of luck. I'm just trying to help you increase your chances of this luck.

Originally Posted by EVOEx

Well, I guess that's a good reason. If you have a good reason for this reason. I mean, why would you want the debug speed to be remotely similar to the optimized speed? There's really no point, unless you want to run a game in debug mode, which is kind of useless anyway.

To add to this, any kind of direct performance analysis during debugging is not only pretty useless, but also fundamentally wrong since the only thing resulting from it is early optimization. Something that we are told to avoid. If there is a reason to measure direct performance during the development stage -- and I certainly expect there is, particularly when implementing core functionality that must be subject to an ad hoc evaluation -- I expect anyone to build a quick release version and test from there. Especially because there's no level of compiler optimization that can take place in debug mode.

Furthermore, doing direct performance analysis of an algorithm (how long does it take to run) is even rarely useful in release mode. Everything is so dependent on the system being tested on and will have no correlation with user systems, that I can't even imagine one reasons anyone would want to do this. It also forces the the person doing it to concentrate their efforts in achieving a performance level they are satisfied with and stop there, often not realizing there are portions of their code that could be significantly optimized further. And to actually achieve this knowledge, what they should study is the relative weight of their algorithms. Something that can (and should) be done in debug mode. The greatest contribution to any system optimization is detecting and correcting code bottlenecks. A task that at one point can only be achieved by using proper code profiling tools.

Finally, about debugging speed... It's usually great. Very good indeed. So good in fact, there's no type of project development I know of that will ever require a programmer to change their code just because they require debug mode to behave in a certain way. The mere thought of adopting coding practices in function of Debug mode is so wrong in fact, I don't even know exactly where to start. Changing the way I code something because of debug mode is a sure sign of a bad design and an awfully wrong coding practice.

@EVOEx, I'll reconsider about it, because I see you have a point there.

@Mario F., honestly, to me it's far more readable and easier to understand, especially the multiplication part. Anyway, i don't intend writing more of the like, so i don't believe there'll be a problem.