The Drag[en]gine is an free software project with a highly modular structure based on the GLEM System. Its design is similar to an operating system. The entire functionality is provided by Modules comparable to device drivers. The engine itself acts like a system kernel managing modules, resources and abstracting the underlying system. Due to the loose coupling of the modules with the system and other modules it is very easy to exchange or improve them without interfering with the rest of the engine. As a result the modularity extends from the developer to the end user who can now choose the optimal module combination for his personal computer even down to per game setups ( and even while running a game ) if required. Developers do not have to worry anymore about low level concerns keeping them concentrated on their game. In contrary to other engines (including high-end commercial ones) the Drag[en]gine provides true 0-Day portability of games with no extra costs and no troubles neither for the developer nor the end user.

Advantages of the Drag[en]gine

... for the Game Designer:

  • Use your Scripting Language of choice.
  • Hardware is fully abstracted. You only have to know how your chosen Scripting Language works
  • Updating the engine and modules is handled by the respective teams. You only have to worry about updating your game
  • No need to write specific content for specific systems. The users choice of modules takes care of this for you

... for the Module Coder:

  • Play around with individual parts of the engine without disturbing any other part. Test easy and fast new algorithms or features
  • Various debugging features help to debug fast and easy modules even during run-time
  • Loose coupling and high encapsulation yields in a more stable game engine
  • Platform specific code is only handled in modules increasing portability

... for the Customer:

  • Choose the optimal combination of modules for your system. The Drag[en]gine adapts to match your system not the other way 'round!
  • Open standards and free file formats ensure unrestricted and easy modding using free software applications
  • Various Launchers allow you to use the Drag[en]gine for more than just gaming
  • The Crash Recovery System prevents a game from crashing to desktop. While CRS is running change parameters or entire modules and continue your game from where it went out for lunch.

For more information check out the Drag[en]gine Wiki.


Due to the modular nature a fixed list of engine features as other engines provide is not possible since it all depends on the customer's choices. To avoid cluttering the summary find the features list in this article:

Image RSS Feed Latest Screens
IGDE Game Definition Class Hiding Solidity comparison Language Pack Editor Preview Image
Blog RSS Feed Report abuse Latest News: New Year goodies with Core and Skinning

2 comments by Dragonlord on Jan 9th, 2015

Going Core... and fast please!

To get closer to a first release the OpenGL module has been reworked in terms of context handling. Up to now a compatible profile has been used based on extensions. This is mostly due to the way how the engine grew up. To get things better defined the system has been reworked to operate strictly on a minimal Core profile with the option to use higher Cores if the GPU supports it. This allows now to define better the minimunm specs a GPU has to support to be able to run the Graphic Module while allowing to still take advantage of higher Core profile features if available. So the OpenGL Graphic Module is now officially set to require a minimum OpenGL 3.3 capable GPU to run. This covers GPUs of the last couple of years and should not be a problem for most people. Certain features up to Core 4.3 are supported and will be used if present.

Besides this the Debug Drawer System has been reworked. This is the main debug visualization system provided by the Drag[en]gine. Since all editors and some modules are using this extensively the existing implementation went a bit out of scale. The system is now more speedy, clenaer and more stable than before. Also the bindings to the game scripts have been improved to allow better debugging visualization while developing the game scripts.

Improved World Editing

The IGDE Game Definition received now support for custom defined Class Hiding and Class Partial Hiding. It is now possible to defined tag lists for classes to fully or partially hide them while editing. The world editor provides a list of all hidding tags found in the current game definition. If a class hiding tag is set all elements with the affected classes are fully hidden from the edited world. If a class partial hiding tag is set all elements with the affected classes have their visual representation hidden but not their effect. For example if the "light" tag is set all light classes hide their light bulp box and are not selectable any more but their effect (the lighting) remains active. This allows to switch on and off custom sets of objects while editing the world reducing the clutter. I'm using this also as a quick preview mode.

IGDE Game Definition Class Hiding

GPU Skinning Improvement

With this topic I would like to stay a little bit. GPU skinning is the process of transforming models to render on the GPU instead of the CPU. GPU skinning in general suffers from various limitations (limited animations, limited model parameters or tricky batching) and the result are inaccurate (incorrect normal/tangent calculation). For this reason the skinning had been opimized CPU side so far. Over the year change I've experimented with ways to get the skinning on the GPU without the existing problems if possible. Out of this resulted three ways to do skinning the player can choose from.

The first is CPU Skinning. This is the slowest solution to choose from but is 100% accurate and serves as reference implementation.

The second is Accurate GPU Skinning. This version does all the complex CPU skinning calculation on the GPU using a combination of Transform Feedback and TBO Rendering. The calculation is nearly as accurate as the CPU version but faster. Brings the calculation time down to estimated 35% of the CPU version. This is the second best choice for players and usually only an option if the accuracy is really required.

The third is the Approximate GPU Skinning. This version is a short-cut version of the Accurate GPU Skinning. The basic problem with skinning is that while transforming positions is accurate transforming normals and tangents is not. To get proper normals/tangents you have to calculate face normals/tangents (from transformed vertices) and then sum up the normals/tangents over all face corners. This is the correct way and what the accurate methods are using. The approximate version just uses the weight matrices to approximate the correct normals/tangents. This is faster but results in errors if weights have certain characteristics. For example if a triangle runs across two bones and they just translate not rotate transforming normals/tangents with them lacks rotation. This result produces incorrect normals/tangents which can negatively affect physical rendering. Most of the time though you have models not showing this problem that much. Compared to the CPU version the Approximate GPU Skinning reduces calculation time down to estimated 11% while supporting all kinds of complex and large models without any restrictions. In general this method is the best choice for players.

Using the improved GPU skinning the number of online NPCs can be raised to make the life of players more interesting. But this is not the end of optimizations. I'm going to crank out more online NPCs in the new couple of days.

Media RSS Feed Latest Video

Epsylon Epsylon

Updated 4 months ago TBD Single Player Adventure

Epsylon - The Guardians of Xendron takes the player on a journey to a futuristic world investigating a very special Science-Fiction setup. With a team...

Post comment Comments  (70 - 80 of 88)
Froyok Dec 30 2009, 7:41am says:

Hmm, I little question :
multiplateforme ? What do you use for the video window : SDL, API Windows ?

+1 vote     reply to comment
Dragonlord Creator
Dragonlord Dec 30 2009, 8:09am replied:

Anything. The game engine does not define a graphic system to use. You as the gamer pick a Graphic Module which matches your system so anything is possible as long as a Graphic Module exists for it. Currently there is one Graphic Module available in three different builds. Each uses OpenGL and the native API of the matching OS, hence X11 for Un*x, W32Api for Windows and BeOS Interface Kit for BeOS/Haiku ( BeOS stuff work in progress since 3D accelerator drivers are still a problem there ). I plan to also add a DirectX module for Windows users as an alternative ( some GPUs work better with OpenGL others with DirectX ). There will later on also be an additional OpenGL module for weaker systems as the current one requires OpenGL 3.0 type extensions to run.

+1 vote   reply to comment
PedobearNED Aug 15 2009, 8:05am says:

tracking it is the coding lang really hard??? because i jsut wanna begin making something :D

+1 vote     reply to comment
Dragonlord Creator
Dragonlord Aug 16 2009, 6:58pm replied:

You choose the coding language. Currently a DragonScript module exists ( my own language, strongly typed OO language ) but a Python and SmallTalk based one is in the works too. Hence you are rather free there.

+1 vote   reply to comment
P4TRICK Jun 19 2009, 2:18pm says:

This looks interessting!

I will use this for a project ;)

Please tell me when its released!

+1 vote     reply to comment
Dragonlord Creator
Dragonlord Jun 19 2009, 3:15pm replied:

Just engine-watch this profile and you will get the informations. It will be posted here once it enters Alpha Stage ( meaning people can start poking at it ).

+1 vote   reply to comment
tokyolight May 11 2009, 7:10pm says:

Is this is in development??? My studios could use the engine.

+1 vote     reply to comment
Dragonlord Creator
Dragonlord May 12 2009, 5:10pm replied:

Sure it is in development. It is though not released yet. This is done since the high modularity requires a lot of interfaces and to avoid API breaking a stable implementation is looked for first. The plan still stands for a release this year if nothing goes wrong.

+1 vote   reply to comment
Theater Sep 18 2008, 10:22am says:

Is this engine opensource?
I'm considering using it for a game i'm making.

+1 vote     reply to comment
Dragonlord Creator
Dragonlord Sep 18 2008, 12:09pm replied:

It will be available under the GPL and other licenses if required ( for restricted platforms for example ).

+1 vote   reply to comment
timstro59 May 6 2009, 11:47am replied:

looks good

+1 vote     reply to comment
Post a Comment
click to sign in

You are not logged in, your comment will be anonymous unless you join the community today (totally free - or sign in with your social account on the right) which we encourage all contributors to do.

2000 characters limit; HTML formatting and smileys are not supported - text only

Windows, Linux
Team Epsylon
Send Message
Official Page
Release Date
Engine Watch
Track this engine
Embed Buttons

Promote Drag[en]gine on your homepage or blog by selecting a button and using the embed code provided (more).

61 of 701
Last Update
3 months ago
186 members