PDA

View Full Version : Tips on my Engine (or what it is so far)



xill
12-27-2002, 03:44 AM
I am coding an engine, without a real purpose yet, but just something to create all kind of things.

It contains very structured and real clean code, so its easy to take a quick look at a part of it.

Every single tip on a single part of the engine woud be highly appreciated!

for example how to speed things up a little

here's the link with vc.net source and exe (http://www.development-tech.nl/xill/source.zip) .

(sorry for ppl with vc6, but the code is still compilable, only the project file cant be opened)


**changed URL

[This message has been edited by xill (edited 12-27-2002).]

gaby
12-27-2002, 05:03 AM
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...

Regards,

Gaby

xill
12-27-2002, 05:29 AM
well it IS an engine, but nothing like a complete engine, i know...

tips on how to make my code cleaner are welcome too anyway.

thx anyway

jwatte
12-27-2002, 07:40 AM
/*
==========================
bool CreateGLWindow(char* title, GLint width, GLint height, GLint bits, bool fullscreen)
==========================
*/

bool CreateGLWindow(char* title, GLint width, GLint height, GLint bits, bool fullscreen)



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;
};

class IModelInstance {
public:
virtual void releaseModelInstance() = 0;
virtual void setPosOri( Float4 pos, Quat ori ) = 0;
virtual void setAnimationFrame( unsigned int frame ) = 0;
virtual void renderOpaqueParts() = 0;
virtual void renderTransparentParts() = 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.

Good luck.

xill
12-27-2002, 08:04 AM
hey, thx for the reply, the comment is not comment yet actually, i still have to write in there what the functions are for.

But dont you think its a little low FPS for only 1 model loaded?

jwatte
12-27-2002, 07:27 PM
I didn't run the application, so I couldn't say.

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.

xill
12-28-2002, 07:18 AM
you're completely right.

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 :P

jwatte
12-28-2002, 07:43 AM
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.

WhatEver
12-29-2002, 04:58 AM
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.

Coriolis
12-29-2002, 02:12 PM
jwatte, in partial answer to your first response:

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 http://www.opengl.org/discussion_boards/ubb/biggrin.gif

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).