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!

Features

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:

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.

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.

I really like the entire approach of this project. I would like to use this technology for an anticipated project, but after reading the homepage and wiki, I understand that it is in a premature development phase. Do you have any sort of project communication like quakenet IRC? The epsilon forum seems to be down.

Currently this is done using the ModDB page. The forum is indeed down since the forum software fails to run with the new PostgreSQL server version for some unknown reason (only application on my server right now breaking down on this version). Fixing this forum did not have priority so far but I can try changing this if people want a forum already now.

Not necessary. I am mostly interested in some technical information concerning how the game logic can be plugged in. there seem to be modules to support dragonscript and two others, but I will probably want to plugg unscripted. that probably means, I'll implement an own 'script' module that implements the game logic, and there I'd be interested in the API.

For the game logic you choose a Scripting Module. This choice defines which language you use for your game scripts as well as how the engine is abstracted (ranging from mostly wrapping engine classes all the way to point and click). If you can manage you should choose an existing Scripting Module and start from there. If you want to use a new language not supported yet you can create a new Scripting Module. The module itself has to be available online though so every user (using their launcher of choice) can obtain it to play the game. People are always welcome to add more Scripting Modules.

In general the Scripting Module sort of defines the API you access the engine with and the Scripting/Programming language to use it. So unless the language is not supported there is no need to write a new module since you get with the existing modules (all three languages) already full wrapper access (engine API mostly wrapped 1-to-1). Hence by writing a new Scripting Module one does not gain much more customization. I hope this explains it a bit already otherwise just keep asking.

well, it confirms my expectations :-). It is good information though, that all engine classes are wrapped as an API by the three existing script modules.

What I would want to do, is implement more high level game logic facilities inside compiled code (unscripted) and then probably add a different script on top that makes use of these facilities. maybe you could call it a game logic tool box. As long as I don't know what is already part of the API, I can just guess, that I would want such a tool box.

Is there some sort of documentation available of the current API wrapped by the scripting modules?

Such a documentation does not yet exist. In general though one can look at the Wiki which contains a more descriptive description of some basic building blocks provided by the engine (and exposed more or less 1-1 by the Scripting Modules) as well as the Doxygen of the C++ Engine API (http://dragengine.rptd.ch/docs/dragengine/latest/index.html, that said, I should update it again). Since the Scripting Modules wrap the Engine API one can get an idea there. In the scripts it's simpler since C++ related problems like memory management or type safety is taken care of there already.

Concerning un-scripted. In general you should be able to do complex game logic using scripts only in a fast way (I'm doing this with the Epsylon project). The way the engine is designed all the number crunching stuff is done by the engine and made available to the scripts through the wrappers. Hence by combining the building blocks properly one should be able to delegate all time critical computations to the engine modules which in turn optimize them.

Otherwise Python has support for byte code generation in general (*.pyc). I did not check out yet how to incorporate this into an embedded Python session but this is similar to JIT like in Java. Hence if you plan to do number crunching not handled by the engine this language should provide you with a pure scripted solution which still runs fast without having to worry about compiling.

Thanks for updating the doxygen :-). Let's see if I can summarize the API in a few handy words.

- under common the folders curve, math, shape for base geometry, color data classes and operations on them.

- the folder filesystem plus under common the folders string, xmlparser, file for base text persistence classes and operations on them.

- the folders logger, errortracing plus under common the folders exceptions for cross cutting error handling.

- the folder resources which seems to include mid and high level visual entities, artificial intelligence, physical and networking.

- the folder systems, containing the folder modules, containing interfaces for all modules, which then probably during runtime get their different implementations plugged at the will of the user.

All in all a neat setup :-). Maybe slightly unbalanced folder tree and a bit inconsistent sorting of the related structures, but oh well, systems grow and have a life ;-).

Now taking a look at the scripting:

- first impression is, it seems to be heavily relying on events and the implementation seems to be required to implement a lot of callbacks for AI, physics, rendering, network... . That sure covers the necessities for game logic, but seems quite cumbersome as a base layer.

- first idea is, I'd want to provide base game logic entities like avatar, tool, material, product, monster, machine, and some abstract game facilities to bind all the nuts and bolts together to something easily accessible. But maybe my short skim over the documentation made me overlook some gems that possibly already fulfill such desires?

Yes I do. Currently you can use the texture property "refraction.distortion" which simulates Fresnel refraction behind transparent objects. In the video in the previous news post the glass window uses this property to simulate an uneven glass. I'll though also add a Fresnel texture property later on for more accurate refraction. In general all these properties can be also applied to particles. Distorted particles are though more costly since full transparent rendering is required and here I use a speed hack for the more common case of particles.

It is a texture problem. It's an image (Mercator mapped) I obtained from the Internet for testing purpose and the resolution is not optimal (1024 for 360° is not much). I've done some additional photo shooting of real sky around my home place but I have not got around so far to process the images for actual use.

Concerning the how it is done in general you can use multiple layers with each layer containing an image, optional any number of bodies (sun/moon for example), lighting properties and own color/transparency/orientation. Images can be spherical (Mercator mapped), box (cube map) or planar (typical for clouds, I'll show that some time later). So you have various ways to make static and dynamic skies.

The rendered mesh and the portal system are two different meshes/objects. The rendered mesh is a "Model" resource (and exported as .model file). The portal system is a "Portal System" resource (and exported as .posys file). They are independent so the model is as you expect it while the portal system mesh just requires two textures to indicate which face is a wall and which a portal. So you can edit the two individually at any time.