Well… I’m all time interested in have a look to really structured and clean C++ code !
I’ve looked at your “engine”… Well, you really cannot say it is an engine !!! It doesn’t have 1 percent of a full engine’s features… Clean code ? I’m not very convinced…
Well, download and parse the criterion’s Renderware Platform, Lithtech’s or Alchemy engine, or every egine API, and you’ll understand lot of things…
What is the purpose of that comment, other than to make your source 6 lines longer, and thus harder to read?
Anyway, you seem to be lacking in abstraction. All your implementation classes are publicly exposed to the world. An alternative way of doing things would be to use factory functions (or interfaces) that make concrete instances, but return only an abstract interface to the functionality. This leads to better code isolation and easier extensibility.
Here’s a straw-man example:
class IModel {
public:
virtual void releaseModel() = 0;
virtual bool readFromFILE( FILE * f ) = 0;
virtual unsigned int textureCount() = 0;
virtual char const * textureNameAt( unsigned int ix ) = 0;
virtual IModelInstance * newInstance() = 0;
};
You could then have a C3dsModel class returned from the function New3dsModel; you could have another CMd2Model class returned from the function NewMd2Model. They would both be returned to their users using the same abstract interface.
Note that a real mesh interface for a real engine will be substantially more complex because it needs to support different materials, material substitutions (“skin swaps”), skinning/animation, allocating models on a specific renderer, and a bunch of other things, but this is a start.
I suggest concentrating on correctness first, then a useful, flexible and efficient API for dealing with geometry/geometry instancing/materials on the rendering side, and THEN worry about frame rates. Oh, and only measure frame rates on full-load scenes with the actual poly count you’re interested in, as there might be a lot of overhead per frame.
Once that’s done, to turn it into an engine, you only need to add animation/posing support, collision detection, rigid body dynamics (or at least collision response) and some world scene and state management and you could make a simple game with it! Well, maybe a menu system and integrating some scripting language would be necessary, too.
What i thought is that i needed to optimise my code while its is still small to gain highest FPS, but i need more before i do that idd.
My next step would be collision detection like you said, does someone have a link to a good article about it? The tutorials i read just show you how to do it but dont really explain. I’ll ‘googlelize’ some more
I sincerely suggest you go with some available source code, rather than rolling your own. Even if it doesn’t do exactly what you need, it’s faster to change existing, working code than to write your own.
I’d suggest OPCODE (http://www.codercorner.com/) if you need a lightweight, fast, mesh collision system, or ODE if you need an open-source dynamics system (which doesn’t natively do meshes, unfortunately).
Another thing I totally forgot, and which actually is the most important thing of all, is the tools that let your artists and game designers get content from the tools where they create it (MilkShape, 3dsmax, Q3radiant, whatever) into your application. In the end, you can have all the whiz-bang features you want; if there are no tools, nobody will use them.
If you’re really bent on writing your own code, or you really enjoy discovering how they do it, or you want to know how so you can improve on it, then write your own code. If you just want to make a game, then find all the free tools you can and use them.
I started a project called Spider3D because I wanted to know more about 3D. I’ll have to admit I’ve learned a lot. Right now the project is on hold, and I don’t know for how long. Anyway, you can get the project with all it’s source code here under the Spider3D Free page: http://www.spider3d.com
You can get an idea of how large a project can get if you want it to do it all…which Spider3D is far from doing but is on the right track.
In the world of color-coding text editors, I find comments at the start of each function makes browsing source files easier. If your editor is still monochromatic, then yes, it will slow your browsing of the source file down. I also find it means I always have a place to put special information about the behavior or requirements of this function, which seems to just dangle unanchored to my sense of aesthetics when the function name comment is absent.
I don’t put the argument lists or return types in this “marker comment” though. For one thing, it makes find-in-files results less useful. For another, I find that overloaded functions tend to cause more confusion than they are worth, especially on team projects, but even when working by yourself and revisiting old code. I typically only have multiple argument lists for the same function if it is a constructor or an operator in a vector class. Since it is just a marker anyway for easy locating the top of a function, you just look a couple lines down for the argument lists.
I suspect that he picked up that particular style from id’s source code, since the comment you quoted looks just like many I’ve seen before. I don’t like it nearly as much as a set of // lines though, since sometimes I like to comment out large chunks of a file and have them get color-coded green, and because /* comments tend to take two extra lines. I work around the problem with #if 0, but then the disabled code is not color-coded
I wrote a macro for VC6 and ported it to VC7 that will auto-generate the “marker comment” with arguments deleted from the function declaration line. It works solidly enough for my purposes, gives me my marker comments, and makes it easy to keep the names in synch (though it is still not automatic).
