|Engine Module Type String||Graphic|
|Module Type Usage||Single Type|
Graphic Modules enable the Drag[en]gine to render the game to the screen or a window. Graphic modules are Single Type modules since only one can access the screen at the same time. This module is one of those modules most important for the end user. The right choice is important to get the best out of games. You can use though for different games different Graphic modules if you like. Launchers usually do not download Graphic modules on their own since games do not request them. Pick from the list of available Graphic modules the one which matches best your system as well as your taste.
Every computer installation is unique which makes it difficult for game developers to produce an optimal engine. With the Drag[en]gine you can pick what works best on your system. Choosing the right Graphic module is an important task and requires some testing if you want to get the most out of your system. Each Graphic module has different properties worth investigating.
How powerful is my machine?
Rendering graphic is an operation of heavy work load. Graphic modules range from simple ones which can run on low end systems up to big beasts which can wrestle down even high end cards. The first step is to get look for a Graphic module which matches the performance of your system. The informations of the individual modules state how they are expected to run on various graphic cards.
How much eye candy am I looking for?
Usually the more eye candy you are looking for the more powerful the Graphic module gets hence this question has to be answered along the previous question. Graphic modules try to provide as much eye candy as they can but they are not required to provide all possible eye candy. Some games require huge graphics to look, feel and play well whereas others do not require a huge graphic feast to be a blast to play. You can change the Graphic module used on a per game basis if required or you can use one for all your games.
What operating system am I using / What graphics API do I want to use?
What works on one operating system or graphics API does not necessarily have to work on another one. Graphic modules are usually optimized for one operating system and/or graphics API. If you have the choice between different graphics APIs on your system it is worth it trying out different Graphic modules to find the one with the best performance.
Launchers will provide you with a default choice for a Graphic module. Usually this is a reasonable choice but often you can get better results doing some manual testing and adjusting. The good thing is that once you have found your optimal Graphic module you do not have to worry anymore getting new games.
Since rendering is a big performance bottle neck the focus on Graphic modules is to make things as fast as possible. To aid in this task the Drag[en]gine game engine provides a Peer System with fine grained notifiers. Whenever the state of a resource changes you are notified. All resources are first loaded into CPU memory and reside inside the game engine. For each resource the Graphic module is queried to create a Peer object which is your personal data object containing data in the form you require it for fast rendering. The Drag[en]gine game engine as well as other modules do not know neither do they care what or how you store things inside your Peer objects. You are not entangled by engine data structure formats or other limitations giving you the freedom you need for fast rendering.
Graphic modules are required to be able to render to multiple windows if required. Usually a Launcher only creates one window to render to but other launchers or applications can use more. Each render window is represented by a deRenderWindow object. Use the Peer object to link all the resources you need. Render windows can be full screen, windowed or hidden and have an optional window title. To render to such a window the game scripts create first a deRenderTarget object. Render targets provide the target for rendering calls and can be bound to a render window or are free. Whereas bound render targets render to a render window free ones render to an off screen image. This off screen image held by a free render target can then be used for texturing or as the source of other render calls. Every render window owns one render target which is called the Primary Render Target. The game scripts can create additional free render targets if required. Rendering on such a render target is done using a deGraphics object. This object works similar to the Graphics class found in Java and provides calls to render various shapes as well as entire worlds. Using the CreateContext function the game script can obtain a deGraphics object for a small area of the render target. The viewport and clipping is done by the Graphic module.
Most important is rendering worlds. The system is rather simple although it looks a bit complex at the beginning. To render a single deWorld object is used. A world object composes of a set of geometry, objects or other elements. To render the world the deCamera object is used which is attached to a world object. The game scripts just fill the world with all the data without caring about optimizations. The Graphic module is responsible to determine the visible content of the world to speed up rendering. Pay attention to the Peer object notifications to cut down processing time to a minimum.
There are a couple of elements stored inside the world. The deSky object provides support to render skies in various forms. The sky is organized in layers. Each layer contains an image, an orientation relative to camera and a list of sky bodies. All sky bodies use the image stored in the layer and have a relative orientation in reference to the layer. This is a simple way to simulate celestrical bodies moving across the sky. The background is currently only a color but will be more sophisticated in the future.
Terrain Meshes provide the static world geometry. They are a good candidate for optimizations since they are by definition static unless the application is an editor. In an editor the terrain meshes can be moved around. Since there it is only important that you can see how it looks later on ingame the speed is not much of a concern. For a game they are static. Terrain Meshes have to be updated by the Graphic module during update calls to the world they reside in.
Dynamic objects are all represented using a deComponent object. This object glues together Model, Skin and Rig resources to produces a 3D object on the screen. Components are updated by the game scripts and therefore do not have to be updated during world update calls. Components contain an important flag for rendering, lighting and shadow casting. The value ranges from 0 to 100 and indicates the level from which on the component can be neglected for rendering, lighting or shadow casting. This way the Graphic module can not render, light or cast shadows by components to speed things up.
Lights are provided using deLight objects. Lights contain a isStatic hint flag to signal if they are supposed to not change their position. Often though this is not enough since many dynamic lights stay static for quite some time before moving. The Graphic module receives informations about changes using the Peer object notifications and has to decide itself which lights are mostly static or very dynamic. Since lighting and shadow casting is a time consuming process here to exist importance flags to allow the Graphic module to discard lights for speed increase. The importance flag works the same as for components.
The various effects based on the deEffect class have to be applied after rendering the world. Most of them are simply operations and they are extensible. The camera and world object define what effects to use. There are also debugging objects around using the deDebugDrawer object. Graphic modules are not required to optimize them since they are only used for debugging purpose. Frame to frame coherence can be implemented using the camera Peer object.
How many functionality your Graphic module provides is up to you. Not every Graphic module is required to support all eye candy and advanced features. This is especially the case if the Graphic module is destined to run on weaker system or consoles providing only limited support in hardware. There are a lot of classes involved to get a Graphic module working and many have been mentioned already. To get you started on Graphic modules have a look at the deBaseGraphicModule module.
Every Graphic Module has to provide a compatibility value which indicates how well the module suits the computer it is running on. This value is a percentage value with 100% indicating full support and 0% indicating not running at all. Values above 50% are considered playable. The value has to be determied by examining the possible abilities of the Graphic Module compared with the usable ones. If there is some support missing 0% has to be returned.
Games can request certain graphical features to be present. This value indicates how well the Graphic Module can handle those features. A value of 100% indicates full support for all requested features whereas 0% indicates no requested feature is supported. If at least one feature is not supported 0% has to be returned. Usually this value is simply the number of supported features divided by the number of requested features. This value is important for the engine to propose a module to the user. Only modules with 100% are proposed. Should there be no matching module the best matching one is proposed with a warning about possible non-playability. Games are required to only request for features which are really a must for the gameplay and not neglectable at all.
Note: The graphic system is still work in progress and will change until the first release.