Sign in to follow this  
  • entries
    201
  • comments
    88
  • views
    100360

Engine stuff

Sign in to follow this  
Metron

79 views

After having done some thread programming and making sure that my memory manager supports it as should, I've taken a look at the other components of my engine.

Currently I have these parts:

1. assert/debug lib: This lib contains an enhanced assert which is not only able to skip asserts for N times but which also can send an error report by email to the developer who has provided his email address.

2. baselib: which contains some stuff as different containers (string, dynamic arrays etc), the memory manager, the system stuff (such as the file system, streams and the plug in management), seeded random generators, etc.

3. config: contains reading of xml based data stuff (this can be an config file, but also any other data based on xml).

4. utils: which contains thread code, timer stuff and xml based parameter reading.

5. math: a math lib basically thrown together from various math sources, mostly the Eberly math stuff. Contains everything from color convertion to ray casting and collision detection.

6. input: Takes care of mouse, keyboard and joystick/pad input. Handles function to event binding (ie. the e key calls a function which opens the editor; the kind of keyboard mapping you find in games ;)). Those events contain also axis stuff like mouse up, mouse down, mouse wheel etc.

7. GFX File Formats: Basically I had a whole bunch of different plugins that were able to load different file formats. I switched to FreeImage and wrote a gfx plugin that was able to work with it. I still have to write a DDS file loader since FreeImage doesn't handle mipmaps.

8. Renderkernel: This is a DirectX based render kernel implementation which can do shaders (up to the latest version) and all things a neat renderer should be able to do.

9. CoreEngine: This is called core engine but in reality, this contains stuff like the scenegraph handling, the nodes (geometry, camera, lights, etc) but also the gui stuff (which contains everything from simple text output to buttons (check, radio, push) and input (editfields, editlines). The core engine also contains a complete animation engine, some physics stuff, a terrain engine, etc).

10. Scripting: I also have a lua 4.0 based scripting engine which is quite complicated to use.

11. Game Framework: The game framework is some kind of wrapper class which takes care of opening a window, initializing the important plugins (system, file access, renderer, input, etc) and which does the main loop. It calls overloaded functions such as DoLogic, Prerender, Render, Postrender. It also provides callback functions for input (event handling) and the gui (intermitten gui rendering).


Phew... this is some years of work ;)

Now, I have plans to do some changements:

1. The whole stuff has to be multitask able. Means that I want to be able to start different threads with different parts of the engine. One thread for physics, one for file access, one for the rendering, one for the logic etc.

2. I want to rewrite the render kernel to be shader based only. Right now it has a whole bunch of fixed function codes which I want to get rid of.

3. Scripting! I've taken a look at Lua 5.1. It seems to me that it is much easier to handle C++ classes (and their function calls) with this version. With 4.0 any function binding was a PITA. I tried converting the 4.0 code to 5.1 but it contains so much special cases... argh... I'm tempted to rewrite the entire scripting stuff from scratch.

I also want almost any part of my game engine accessible through Lua scripts.

4. I want to improve the ease of use. Don't get me wrong. Using the Game Framework doesn't take you any longer to have a new, running framework in less than 10 minutes. I want to make the function names and the usage more intuitiv.

5. Add some GFX file formats which can take care of mipmaps.

6. Improve the 3D format handling. Right now, I have my own exporter (for a known GFX software ;) ), but it's a pain to keep up with the fast releases of those applications. So I'm thinking of writing some main stream importers (MDx, Collada) and either have them integrated directly into the engine or write converter software. I want to be more or less independent of the gfx source; it's the format that matters, not the software.

7. Improve the core engine to better handle rendering to target, post processing (it has a complete post process engine but it's a PITA to configure it), shadow maps, ID buffers etc.

8. Try to seperate the physics from all the rest.

9. Rewrite the sound code (which is a fmod wrapper right know) and make it a plug in (as almost everything else).

Well... a lot of things to do ;)

Have fun.
Sign in to follow this  


2 Comments


Recommended Comments

Bllleeehhh engine stuff. I mean, I remember that kind of stuff being fun in a way, but I never really got much satisfaction from doing that kind of work. The problem with an engine is that it never really makes for a cool 'finished' product, simply because an engine is an engine - a tool to make the finished product.

I guess I'm simply not patient enough :3

Share this comment


Link to comment
I had some thoughts about releasing the engine as open source or handing it out as libs but since ie. the math lib is based on Eberly's Math stuff, I have some concerns about having to rewrite that part.

Also the engine uses some containers which are not ment for the public. Therefore I'm also considering replacing that container stuff with stl (StlPort?!?). I've already written and tested my memory manager binding to standard stl.

To be honest, I love the technical side of game development. Creating all that *stuff* around a game making the game developer's life easier. But then I like game development itself since I have some game ideas I would like to realize (if only I had the time, the money and the people willing to work on it ;) ).

Have fun...

Share this comment


Link to comment

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now