Endogine C#


This page is no longer being updated. More recent info can be found in this
CodeProject article

Some Endogine-based projects:



Endogine is a 2D graphics/game engine project that has been under development since late 2004, first in Director/Lingo, and now in C#. It arose from the need to improve on the aged Director graphical engine, and from my prevision that Director wonít be around much longer. With a stable implementation of my engine in Lingo, I could port it to another, future-proof, environment, and for this I chose C#/.NET.


It seems to be common for open-source projects of this magnitude to cease development half-way. This will hopefully not happen to Endogine, as itís not just a hobby project Ė Iím a professional game developer and I need a good environment to work in when I cut my last ties with Director. Unless I stumble upon another open-source project that has everything I need, I really have to continue developing Endogine.


Download source:

http://www.endogine.com/CS/endogine_src.zip (310kB)

.NET 1.1 and DirectX SDK April 2005 update needed



Download example:

http://www.endogine.com/CS/endogine_demo.zip (220kB)

.NET 1.1 and DirectX 9.0c needed



NOTE: Some people have problems running the example. I think the root of the problem is incompatible versions of Managed DirectX, but Iím not sure yet.



Thereís also an article at CodeProject:




I have kept some of the concepts of Director/Lingo to make the transition easier.

There are lots of TODO remarks in the text below, but most of them are still in my head.

Features at a glance

Use Lingo-like commands to manage sprites and members

spriteX.MemberName = ďMyGifAnimationĒ;

spriteX.LocX = 50;

Mouse/keyboard handing

Sprites are notified about Enter/Leave/Up/Down/Click/UpOutside events, and delegates are implemented so other objects can easily register for notification as well.

A keyboard class simplifies gaming keyboard detection.

Multiple rendering modes

GDI+ and Direct3D are implemented, and itís easy to extend to other APIs as well. Irrlicht is probably next, and maybe OpenGL later.

Sprite hierarchy

Set one sprite Aís parent to sprite B, and sprite A will inherit loc, rotation, stretch etc. This makes the system more similar to Flash or Directorís 3D engine than the oldschool Director sprite engine.

Collision detection

Line/line, circle/line, circle/circle collisions. TODO: Iíve found some open-source code to automatically create line collision hulls for bitmaps which Iíll add later.

Bitmap fonts with kerning

Each letter is a sprite, so individual letter animations are easy to add.


Skinnable windows, frames, buttons, checkboxes, sliders. On the TODO-list (they already exist in the Lingo version): treeviews, datagrids. Dialogs such as Painter-style color palette, expandable buttons (like Photoshop), gradient editor.


Works pretty much like Directorís behaviors: Add any number of behaviors to a sprite to modify how it acts.


Message/console window (input doesnít work yet), Sprite property inspector, Scene graph editor. TODO: behavior editor, animation editor, resource library manager (an evolved Director ďcastLibĒ)


Color space converters (HSB<->RGB<->CMYK<->Lab), Animator, procedural texture generators, particle system, interpolators.

Import/export to other formats

Director animation (not scripts) import/export will soon be implemented. Photoshop, Flash and XAML are on the TODO-list.

Cross-platform / language independent

In the future, hopefully... GDI+ is ported to Linux and MacOS through the mono project, so in theory Endogine can run on these platforms as well. And from what I understand, when compiled into a .dll, the engine can be called from any .NET language.



Note: Many of the features above (especially the IDE) can be translated to a 3D game development environment, which is something I may look at later.



Direct3D, DirectDraw and GDI+ rendering can be used (not simultaneously). D3D textures and DD surfaces can easily be converted to/from GDI+ bitmaps, for high level image manipulation (anti-aliased splines, pattern fills, shaped gradients and more).

GDI+ / DirectDraw rendering

Iíve dropped the DirectDraw code development, as I found it supports neither alpha blending nor rotation. GDI+ works, albeit a bit slow. As a test, Iíve added an text mode which renders graphics as ASCII art.

Direct3D rendering

Supports both windowed and fullscreen modes.


No pixel shader support yet, only RenderSource SourceBlend/DestinationBlend combinations, but I havenít really figured out how to use them.

Per-pixel operations

The blending supported by video hardware or GDI+ isnít always adequate, so Iíve added functionality to write custom raster operations.

At the moment the algorithm can work on GDI+ bitmaps or DirectDraw surfaces. Havenít look into how to modify it for 3D (must learn to access the back buffer).


Director style operations (Inks): Add/AddPin, Subtract/SubstractPin, Lightest/Darkest

Photoshop-style operations: multiply, screen, overlay, color dodge, color burn, difference.

TODO: HSB shift (using one bitmapís RGB channels to modify the underlying pixelsí HSB values), Displacement.

Alpha compositing  (merges two bitmaps with alpha channels like a layer merge in Photoshop)

Use with Irrlicht 3D engine

Iíve been looking a bit at 3D engines lately, and Irrlicht seems to be very good. It shouldnít be too hard to make Endogine play along with it. I could add a RenderStrategy that uses Irrlicht 3D planes instead of communicating directly with D3D, and benefit from lots of its rendering features.


Some nice-to-have features of Endogine.


Initialize with a keyframe list, and get an interpolated value at any point in time. Currently it supports simple linear and spline interpolation, but it can be extended with more advanced algorithms (like the animation keyframes in 3DSMax). Also used for generating color gradients.

Animation system

Uses an Interpolator to send values to a sprite. The sprite has a method setOneProp which accepts a string (for which property to set) and a value of any type. If the Animator is initialized with ďMemberAnimationFrameĒ, the spriteís animation frame will change depending on the value in the Interpolator.

Sprites using a member that contains animation (like animated GIFs) will automatically create an Animator and activate it.

Particle system

A simple particle system with wind and gravity. Each particle is a Sprite, so itís easy to modify the functionality. This also means the particlesí texture is automatically animated if their member has an animation.

The interpolator is used for particlesí changes over time, so they can have any number of color or size changes during their lifetime, not just start and end values.

The emitter is also a sprite, and itís Rotation and Rect is used to decide emitting angle and area. However, the particles are not child sprites of the system, so the emitter can be moved without the whole system (already emitted particles) moving with it.

Procedural textures

So far 2D Perlin noise (including wood and marble variations) and N-octave Plasma. To get interesting colors, just send in a InterpolatorColor-compatible list. Perlin isnít optimized, so donít use for large bitmaps or try to animate. Itís an inspiring part of CG, and Iíll try to add new algorithms like Reaction-Diffusion, and cellular automata (Totalistic, Catalytic Reactions).


Some basic widgets are implemented. Itís easy to inherit and extend the functionality of the widgets.

TODO: (except for more widgets): Widget skinning, with which you can change the appearance of the GUI (programmatically or by loading an XML style file).


splits a bitmap into 9 parts and stretches the edges to fit a rectangle. At the moment 9 sprites are used (18 polygons) which might not be a good idea when thereís a lot of widgets on screen. TODO: add a generic RenderToTexture function (probably GDI-based) so I can tell the frame to render the sprites to a single texture, so only 1 sprite is needed.


for each state (enter/leave/down etc), a sprite can be defined which will be made visible when that state is activated.

TODO: default button should have a text and an icon.


a resizable window with dragbar and close button.


Operates within 1 or 2 dimensions (X, Y or XY)


Text (editable and static), and scrollbars are the most important now, because they will be needed for the debugging tools.


Scene graph

View all sprites and their relations

Sprite inspector

Select a sprite and get/set its properties

Message/Console window

Displays text output. TODO: execute C# commands (with a pre-compiler which simplifies code input)


Vector graphics/animation import

I have a half-finished Flash importer written in Lingo, which Iíll fix and port to C#. Vector graphics can be rendered with GDI+ to textures or bitmaps, and then used with sprites. Flash layers can be rendered to separate textures, so that they can be moved around freely.

As XAML/Avalon is the next big standard Iíll look at that too Ė itís not impossible that it will render the Endogine core will be superfluous if itís fast enough and video card makers start adding hardware acceleration for it.

Photoshop import/export

I know how to parse most of the psd file format, but only implemented it in the Lingo version so far. Each layer corresponds to a sprite, so you can use Photoshop to layout a scene. Effect layers will probably be too hard/slow to implement.

Director import

Import a Director Movieís score and its media (by using a Lingo script that exports the all spriteís settings and changes over time to an XML file, and the members to files)