Introduction

Endogine is a sprite and game engine, originally written in Macromedia Director to overcome the many limitations of its default sprite engine. I started working in my spare time on a C# version of the project about a year ago, and now it has far more features than the original - in fact, I've redesigned the architecture many times so it has little in common with the Director++ paradigm I tried to achieve. Moving away from those patterns has made the project much better. However, there are still a lot of things I want to implement before I can even call it a beta.

Background

I had been developing games professionally in Macromedia Director for 10 years, and was very disappointed with the development of the product the last 5 years. To make up for this, I wrote several graphical sub-systems, some very project-specific, but finally I designed one that fulfilled the more generic criteria I had for a 2D game creation graphics API. It was being developed in Director's scripting language Lingo from autumn 2004 to spring 2005, and since then it's a C# project..

It's a prototype

The current engine design is not carved in stone, and I have already made several major changes during its development, and even more are planned.

Optimizations will have to wait until all functionality is implemented. The GDI+ mode is extremely slow, because I haven't ported my dirty rect system yet. The D3D full-screen mode has the best performance.

The code is poorly commented at this stage, as it is still possible I'll rewrite many parts. If there is a demand for documentation, I will create it as questions appear. For now, you can get a feel for how to use it, by investigating the Tests project.

Example projects

There are two solutions in the download. One is the actual engine, including a project called Tests which contains most of the examples and code. I choose to include it in the solution since it's a little bit easier to develop/debug the engine if the test is part of it, but that's not the way your own projects should be set up. The MusicGame project is closer to how it should be done.

There's also a simple tutorial text on how to set up your own project.

I wanted to have a simple, but real-life testbed, so I'm creating a few game prototypes. Currently, they are Puzzle Bobble, a scrolling asteroid game, a golf/snooker game, CaveHunter, and Space Invaders. Other non-game tests are also available in the project. Turn them on and off by bringing the main window into focus and select items from the "Engine tests" menu.

Example walkthrough

Note: For using dialogs / editors, the Endogine.Editors.dll has to be present in the .exe folder. For sound, include Endogine.Audio.Bass.dll and the files in BASS.zip (shareware license).

To try out some of the examples in the Tests project, run the Tests solution and follow these steps:

Start in 3D/MDI mode (default).

Set focus on the Main window, so the Engine Tests menu appears in the MDI parent.

Select Particle System from the menu. The green "dialog" controls a few aspects of the particle system. The top slider is numParticles, the bottom the size. The buttons switch between color and size schemes. After playing around with it, turn it off by selecting Particle System again from the menu.

Select GDI+ random procedural, and also Font from the menu. This demonstrates a few ways to create procedural textures and manipulate bitmaps, as well as the support for bitmap fonts. Each letter sprite also has a behavior that makes it swing. Note that both are extremely slow - they're using my old systems. I'll upgrade them soon which will make them a hundred times faster.

Go to the SceneGraphViewer, and expand the nodes until you get to the Label sprite. Right-click it and select the Loc/Scale/Rot control. Try the different modes of changing the properties. Notice the mouse wrap-around feature.

Close the Loc/Scale/Rot control, go back to the SceneGraphViewer, expand the Label node. Right-click one of the letter sprites and select Properties (the LocY and Rotation properties are under the program control so they are hard to change here).

Click the Behaviors button to see which behaviors the sprite has. Mark ThisMovie.BhSwing, and click Remove to make it stop swinging. (Add... and Properties... aren't implemented yet).

Stop the program, and start it again, but now deselect MDI mode (because of .NET's keyboard problems in MDI mode).

Set focus to the Main window and select Puzzle Bobble from the menu. Player 1 uses the arrow keys to steer (Down to shoot, Up to center), player 2 uses AWSD. Select it again to turn it off. Note: due to changes in the ERectangle(F) classes, there's currently a bug which makes the ball stick in the wrong places. Will look into that later. (May be fixed.)

Select Snooker from the menu and click-drag on the white ball to shoot it. Open the Property Inspector for the topology sprite object, change Depth and Function to see how a new image is generated, use the Loc/Scale/Rot control to drag it around, and see how the balls react (buggy, sometimes!).

Select Parallax Scroll from the menu and try the Asteroids-like game. Arrow keys to steer, Space to shoot. Note: the Camera control's LOC won't work now, because the camera is managed by the player, centering the camera over the ship for each frame update. That's how the parallax works - just move the camera, and the parallax layers will automatically create the depth effect.

(Broken in the Feb '06 version) Go to the main menu, Edit, check Onscreen sprite edit, and right-click on a sprite on the screen, and you'll get a menu with the sprites under the mouse LOC. Select one of the sprites, and it should appear as selected in the SceneGraph. It doesn't update properly now, so you'll have to click the SceneGraph's toolbar to see the selection.

Using the code

Prerequisites: .NET 2.0 and DirectX 9.0c with Managed Extensions (Feb 06) for the demo executable, and DirectX SDK Feb 06 for compiling the source. You can download SharpDevelop 2.0 or Microsoft's Visual Studio Express C# for free, if you need a C# developer IDE. Read the README.txt included in the source for further instructions.

Note that Managed DirectX versions aren't backwards nor forwards compatible. I think later versions will work if you recompile the project, but the demo executable needs MDX Feb 06.

I'm currently redesigning the workflow, and you would need a fairly long list of instructions in order to set up a new solution which uses Endogine, which I haven't written. The easiest way to get started is by looking at the Tests project. You can also have a look at the MusicGame solution, which is more like how a real project would be organized.

Most of the terminology is borrowed from Director. Some examples of sprite creation:

Road map

I'll be using the engine for some commercial projects this year. This means I'll concentrate all features that are necessary for those games, and that I probably won't work on polishing the "common" feature set a lot.

There will be a number of updates during the year, but I've revised my 1.0 ETA to late autumn '06. I expect the projects to put an evolutionary pressure on the engine, forcing refactoring and new usage patterns, but resulting in a much better architecture. Another side effect is documentation; I'll have to write at least a few tutorials for the other team members.

Currently, I put most of my spare time into PaintLab, an image editor, which is based on OpenBlackBox, an open source modular signal processing framework. They both use Endogine as their graphics core, and many GUI elements are Endogine editors, so it's common that I need to improve/add stuff in Endogine while working on them.

Goals for next update (unchanged)

I've started using Subversion for source control, which will make it easier to assemble new versions for posting, so updates with new tutorials and bug-fixes should appear more often. Some probable tasks for the next few months:

Refactoring: WinForms elements are being moved out of the main project into a separate DLL. Simplifies porting to mono or WPF, and makes the core DLL 50% smaller.

Improved Canvas, Vector3, Vector4, and Matrix4 classes.

Improved PSD parser.

More collision/intersection detection algorithms.

Several new or updated user controls.

Update 2006-03-15

I've focused on releasing the first version of OpenBlackBox, so most of the modifications have been made in order to provide interop functionality (OBB highly dependent on Endogine).

Optimizations (can be many times faster when lots of vertices are involved).

Continued transition to .NET 2.0.

Requires DirectX SDK Feb '06.

Simple support for HLSL shaders and RenderToTexture.

Better proxies for pixel manipulation - Canvas and PixelDataProvider classes instead of the old PixelManipulator.

Extended interfaces to the rendering parts of Endogine. Projects (such as OpenBlackBox) can take advantage of the abstracted rendering API without necessarily firing up the whole Endogine sprite system.

Forgot to mention it last time, but there's a small tutorial included since the last update.

That's pretty much it. But don't miss OpenBlackBox, in time it will become a very useful component for developing applications with Endogine!

Update 2006-02-01

Some major architectural changes in this version, especially in the textures/bitmap/animation system. The transition isn't complete yet, so several usage patterns can co-exist and cause some confusion. Some utilities will be needed to make the animation system easier to use.

Moved to .NET 2.0. Note: refactoring is still in progress (e.g., generics isn't used everywhere yet).

The Isometric example has been removed. I've continued to work on it as a separate project, which I'll make available later if possible.

Renderers are now plug-ins, allowing for easier development/deployment. (Also started on a Tao- based OpenGL renderer, but lost my temper with its API.)

PixelManipulator - easy access to pixels regardless of if the source is a bitmap or texture surface.

Examples of how to use the PixelManipulator (adapted Smoke and Cellular Automata3 from processing.org - thanks Mike Davis and Glen Murphy for letting me use them).

Started on a plugin-based sound system. Currently, I've implemented two sound sub-systems: BASS and a simple DirectX player. OpenAL can be done, but BASS is cross-platform enough, and it has a better feature set. Later, I'll add DirectShow support.

Included a modified version of Leslie Sanford's MidiToolKit (supports multiple playbacks and has a slightly different messaging system). Thanks!

Flash parser/renderer has been restructured and improved. Can render basic shapes and animations.

System for managing file system and settings for different configurations (a bit like app.config but easier to use and better for my purposes).

RegEx-based file finder (extended search mechanism so you can use non-regex counters like [39-80] and [1-130pad:3] - the latter will find the string 001 to 130).

Helper for creating packed textures (tree map packing).

Abstraction layer for texture usage - the user doesn't have to care if a sprite's image comes from a packed texture or not.

The concept of Members is on its way out, replaced by PicRefs. Macromedia Director terminology in general will disappear over time from now on.

New, more abstracted animation system. Not fully implemented.

.NET scripting system with code injection. Currently only implemented for Boo, but will support other languages. Will be restructured later, with a strategy pattern for the different languages.

Added "resource fork" for bitmap files - an XML file with additional info such as number of animation frames and offset point.

Update 2005-10-04

OK, it's over a month late, and it doesn't include stuff you might have been waiting for, and the things I've been working on - mainly creating two script languages - aren't that useful in their current state (especially with no good examples of their use). I think it was worth putting some time into, as I'm certain FlowScript will become a great tool later on. Here's what I've got for this version:

Sprite Behaviors: easy way to add functionality to sprites. The swinging letters animation is done with a behavior.

Behavior Inspector: add/remove/edit behaviors in runtime.

Inks use an enumeration instead of an int (ROPs.Multiply instead of 103).

Switched from MS' too simplistic Point(F)/Rectangle(F) classes to my own EPoint(F)/ERectangle(F), which have operator overloading and many more methods. Note that I've chosen to write them as classes, not structs - i.e., they're passed as references, not values.

Easier keyboard handling (assigns names to keys - makes it easier to let the user define keys, or to have multiple players on one keyboard).

Puzzle Bobble allows multiple players in each area.

You can read about my early thoughts about the Endogine concept, future plans, and see some Shockwave/Lingo demos here.

I have added a Endogine C# specific page here, but it probably lags behind this page.

License

This article has no explicit license attached to it but may contain usage terms in the article text or the download files themselves. If in doubt please contact the author via the discussion board below.

I am making my first steps with Mono and C#, so maybe I missed something.
But to me it seems as if Endogine does currently not support mono / linux. Am I correct?

So...
1. Are there plans to support mono / Linux?
2. Do you know an alternative to mono, that would allow me to use this library on Linux (Ubuntu)?
3. Would it work if I just need a subset of Endogine? Such as, without any GUI and display support.

-----

My use case:
I'd like to produce a simple commandline tool that can deconstruct a psd file (Photoshop) into xml + png. So, exactly what PSDParser is supposed to do.
I don't need any GUI and friends.

What about switching only a stable version to support slimDX?
( There's another 2D framework called gorgon that use it. Personally I loath to switch my whole project to yet another framework, only because the other is in (more) active development today. )

Or have you thought about to branch your current unstable work to be continued by an community on platforms like goolge code, codeplex or sourceforge ?

I was playing with the particle system, and realized that if you change the particle generation speed to something REALLY fast (1.0f), then run it, and watch your RAM Usage, it slowly but surely climbs at a constant speed (I stopped when it hit the 200MB Marker)

Has this been fixed in the current version, and how old IS that other page - It lacks any dates

That is very possible - haven't really used it since I wrote the example. One thing do I know is that the code doesn't reuse "dead" particle sprites at all (which should be a given in a particle system), it just goes on creating new ones, so until the GC kicks in it'll just keep growing.

All published material concerning the engine is very old, for reasons mentioned in the thread below. But work has started on a fresh new version!

When doing a Google Search for something like "C# Particle System", yours is BY FAR the most promising that comes up! All the others either max-out processor usage as soon as they start, or are just rather stupid (MS-Paint Graphics )

Also, try use less Forms this time I've been hacking away at the code, and by forcing it to use D3D I've totally eliminated the selection Form, a few other Forms, A LOT of Code and am just left with the Black-Screen with a very modified particle system, and that other form (That doesn't actually do anything (Except initialize the main window), but is a mission to get rid of -_-)

You're absolutely right - this time the main design will be totally agnostic of Windows.Forms (but it will be used in one of the "Platform" plugin that provides the engine with system events and APIs).

And feel free to assault to your heart's content! Maybe you'll come up with some nice classes to add to the new project once it's on codeplex.

Yes and no. There's been a whole lot of development on the engine, but it's grown wild because I'm always finding new and better patterns for things. I've had to keep the old ones around since I have products depending on them. I don't want to release something in that state - it's a mess for someone who's not already intimely familiar with it.

I've just started working on a v2.0 which takes only the best of v1.x, and improves on the architecture even more. The first alpha version will probably be targeted at the Unity runtime (unity3d.com), and thus run both in browsers and as standalones on Windows/OSX/Wii (and possibly iPhone). Later, I will add support for SlimDX, and maybe XNA to get a wider range of delivery mechanisms.

If you have references to all the Sprite-derived instances, just Dispose() them, otherwise you can iterate through the root sprite's (normally Stage.DefaultParent) children and Dispose() those, and they will dispose all their children recursively.

If you're going to use the engine seriously, I can provide a link to the latest version. There have been massive additions (and some breaking changes) to it since the last update here, but I haven't had time to rewrite the article or create tutorials for it.

I've had to remove some resources and projects because of copyright issues (eg BASS libraries), so you might get a few error messages when opening the solution, but you should be able to just ignore them.

Unfortunately, I won't have time to give any support ATM, so I'm afraid you're on your own - don't throw away your old projects just yet

The OpenGL renderer is experimental, you should exclude that projects from the solution. The Irrlicht renderer, which provides DX/OGL/Software modes, actually works pretty OK, but I had to add some features to the Irrlicht engine so it's not one of the standard dlls (and there's still work to do on it).
You can download my Irrlicht dlls here:
http://flowlabs.net/Download/Irrlicht.rar