Thread: 3D engine project

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!

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.