This page is no longer being updated. More recent
info can be found in this
CodeProject article
Some Endogine-based projects:
OpenBlackBox
PaintLab
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:
http://www.codeproject.com/csharp/Endogine.asp
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.
spriteX.MemberName = “MyGifAnimation”;
spriteX.LocX = 50;
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.
GDI+ and Direct3D are implemented, and it’s easy to extend to other APIs
as well. Irrlicht is probably next, and maybe OpenGL later.
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.
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.
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.
Director
animation (not scripts) import/export will soon be implemented. Photoshop,
Flash and XAML are on the TODO-list.
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).
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.
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.
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)
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.
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.
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.
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.
View all sprites and their relations
Select a sprite and get/set its properties
Displays text output. TODO: execute C# commands
(with a pre-compiler which simplifies code input)
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.
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.
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)