pyroENGINE SDK v1.0

[Pyrogine]

RELEASE
pyroENGINE SDK v1.0.1.178 (Beta 1)

Welcome to pyroENGINE SDK ("PESDK"), a 2D rendering API for PC's running Microsoft Windows. This release is aimed specifically at Direct3D with 3D hardware.

PESDK is feature complete and can easily create any type of 2D game with D3D for rendering. It was designed to be easy to use, robust and feature rich and should be easy to use in your projects.

FEATURES
* Language support for Delphi 2007 for Win32 and C++ Builder 2007.
* Uses Direct3D 9 for fast 2D rendering
* 32 bit surfaces and textures
* Free scaling, rotation, alpha blending and other special effects
* Windowed and fullscreen modes
* Frame based timing support
* INI file configuration support with config file variables
* Unified Streaming system (memory, file, zip archive)
* Can render to default application window or to a specified window handle
* Advanced render target and swap chain support
* Textured fonts (includes a font editor tool and support for custom fonts)
* Graphics primitives (lines, circles, rects, points)
* Advanced polygon rendering (scale, rotate, control line segment visibility)
* Support for rendering large images (640x480, 800x600 for example)
* Advanced sprite management
* Polypoint collision system for fast precise collision detection
* Mouse and keyboard input management
* Unified audio system with support for WAV|MP3|MID|OGG|MOD|IT|S3M|XM streaming music and WAV samples
* Comprehensive math routines (vectors, angles, line intersection, clipping)
* Logfile support
* AI management via an event driven state machine
* Robust and feature rich

SYSTEM REQUIREMENTS
* Pentium class CPU, 366Mhz
* At least 64MB of RAM
* 20MB of free Hard Drive space
* Microsoft Windows 9x, 2000, ME, XP (NT is not supported )
* DirectX 9 summer 2003 runtime
* Direct3D compliant 3D video card that can do 3D in a window (minimum recommend card INVIDIA FX5200)
* DirectSound compliant audio card (optional)

INSTALLATION
* Add {installdir}\Bin to your windows system path
* Add {installdir}\Sources to Delphi search path
* Add ..\Bin as the output location for the examples
* When using C++ Builder, you have to add the .pas unit file to your project and the .hpp and .obj files will be automatically generated. Add #include <unit> and #pragma comment(lib, unit) in the include section of your source to be use this unit.
* See the docs and examples for more information on how to use PESDK

HISTORY
Version 1.0.1.178 (Beta 1):[*] Initial Release

KNOWN ISSUES
* Docs currently work-in-progress
* Examples & Tutorials work-in-progress
* The SDK has not yet been fully tested in C++ Builder
* You have to manually set the proper paths in Delphi/C++ Builder to use the SDK

DOWNLOAD
pyroENGINE SDK

SUPPORT
If you have any problems and/or suggestions & comments about PESDK you can reach us in several ways:
* Our Website - http://www.pyrogine.com
* Via Email - see the README in the distro
* Support Forums - at pyrogine.com and pascalgamedevelopment.com

[arthurprs]

Recently im using SDL and asphyre and i will try Phoenix and pyro soon

[Pyrogine]

arthurprs
Great! Let me know if I can assist you.

Over several posts I will talk a little about some of the great features in pyroENGINE. To start off I will speak a little about the Actor System.

In PESDK all objects are derived from a base class called TPEObject. This class implements fundamental functionality that is needed throughout the SDK so that all the different parts work together as a whole. An important feature that this class implement is that it's a node object and can be placed on a double linked list called TPEObjectList. An object can also be assigned attribute values (0-255). This is important because now you can query a group of objects based on these values. An object can be "blue" and be a "powerup" or "red" and can "teleport" for example.

An actor (TPEActor) is the base level object that can exist and have representation in the game world. It has a OnRender, OnUpdate, OnCollide and OnMessage virtual methods that you can override to make your actors behave in a specific way. They live on a derived TPEObjectList class called TPEActorList. You just create an instance of your actor and drop it on a list and during the game loop call the Update and Render methods of the list object and all the actors will come to life. Since an actor can have up to 255 attributes set, if you wish to only render or update certain actors, you just pass this attribute value when you call TPEActorList.Update/Render.

Another object called TPEScene allows you allocate as many lists as you desire to manage a whole scene of actors. For example, you can have your particles on list #0, your player on list #1 and the enemy actors on list #2. When you call TPEScene.CheckCollision you can specify which list to do collision checks on. In this case you would test collisions between the player and an enemy and avoid looping through the many particle objects that would never be part of the collision. This makes collision detection even more efficient. This can be combined with the fast and accurate PolyPoint collision system of the SDK.

In addition to grouping actors by attributes, the object list supports a message system. You can broadcast a message to every actor in the world or expect an actor to respond to your message. An example of using broadcast is where you drop a nuke and it will destroy all objects in the world out to a certain distance. When the nuke spawns, it will send out a message saying "I'm a nuke and if you're are 100 units or less from me you must die." When the actor's gets this message via their OnMessage event handler, then can respond accordingly and destroys themselves.

The TPEEntity object is a high level class that is made from a group of sprite images. It can be positioned, rendered, scaled, rotated and more. It includes such methods as Thrust, RotateToAngle, RotateToPos and many more that can make it really easy to have robust and dynamic objects. For example, the ThrustToPos method can rotate the entity towards a position and it will accelerate towards this position until it reaches a slow down distance at which point it will start to slow down as it comes near. The entity object is derived from TPEAIActor and has a StateMachine that allows you to manage your AI. I will talk more about AI in a future post.

[Pyrogine]

The AI is based around an event driven state machine. The basic AI class is TPEAIState which has virtual OnEnter, OnExit, OnUpdate and OnRender methods that you can override to add your own functionality. The class to manage these states is TPEAIStateMachine. After you have added your states to the state machine, if you change states, the current state's OnExit method will be called and you can free any resource used, then the new state's OnEnter method will be called and you can set this state up to execute. Next the current state's OnUpdate and OnRender methods will be called each frame to update and render this state. You can also set a global state which will be also be executed along with the current state and you can revert back to a previous state. TPEGame/TPEDemo both have state machines in addition to TPEAIActor and TPEEntity classes.

The PolyPoint collision system (TPEPolyPoint, which the TPEEntity and TPESprite classes have) will auto trace arbitrary shaped sprites (this was not easy to get working) with a polygon outline. The line segments in this polygon is then used to test against intersection, the result is a fast and accurate system for testing collisions between sprites. Since entities are created from a group defined in a TPESprite class, you can also copy the PolyPoint mask from the same group that can be defined in the TPESprite class. This will minimize the trace time when you have multiple entities on screen.

[pstudio]

Wow. It sounds like you've worked really hard on this engine. And from you list of features and you rdescription it sounds quite impressive. I hope to get a chance to check this out, as soon as I get Delphi installed on my new comp.

The only negative thing is that it uses Directx and not OpenGL but I can live with it.

Oh and it sounds really impressive with your auto trace sprite contour :shock:

[arthurprs]

I actually like to do much as i can with my hands, but these features sounds much great

What is the licence of the SDK ?

[NecroDOME]

Any screenshots?

[Pyrogine]

pstudio
Thanks. Yea, an enormous amount of work has gone into the SDK. It's been evolving now for more than 10+ years. It represent solutions to all the different problems and circumstances I've dealt with in game development. The engine started back in 1994 as a high speed blitting library for Turbo/Borland Pascal and used Mode 13h (remember that graphics mode. *sigh* that sure does take me back). I've been enhancing it all these years with each new project I've release (or worked on but never finished). As I would run into a new problem and solve it, I then would try and generalize it and add it to the SDK. So, indeed lots of work and now as result, proven solutions that you can take advantage of that "just works." There have been several forks over the years that included a 3D version first using OpenGL then DirectX8. The 3D version was developed when I worked on an unfinished 3D space combat game.

The first shareware game that I released that used the SDK was Astro3D, followed by Astro3D II and Xarlor. A3D1 was 32bit DOS mode 13h and A3D2 and Xarlor used Windows version of the SDK. Man, those were the good old days when I was learning about all this stuff. Forgetting to init your pointer and rebooting your computer because your now trying to write to invalid memory. In fact back in the DOS days, I made a routine called GV_Reboot that did just that, wrote to null pointer and would reboot your system. Hehe. Those where the days. Around 2000 I started working on what would eventually become pyroENGINE. The first project that I released using this new code base was a 2D space combat game called FreeStrike. The prior 3D game I was working was taking way too long to finish so I decided to make some smaller 2D games that I could actually finish in a reasonable amount of time. So I worked on a framework that would allow me to do this where I could make 3-4 games a year before I had to do a major overhaul on the engine. In order to do this, I would need all the features in the SDK to be ready and working where I could concentrate on making the game.

arthurprs
I understand what you mean. I am the same too. The nice thing about PESDK is that it is both low and high level. They are designed to work together, but if you need to just establish the graphics mode and render some textures you can do this. If you want high level objects in your game world with your own entity types, you can just derived your class from TPEActor and implement it yourself. The is the great flexibility that is offered. You can use as much or as little as you like. You want to implement your own collision detection, no problem, just override the Overlap and Collision virtual methods, which is how I've implemented the offered collision system. Overlap check for radius overlap, then Collision calls the PolyPoint collision routines. Very robust in that you can use the SDK the way that you feel most comfortable with. Again, all those years of development with careful thought about implementation is the result.

About the license: you can use it free of charge in your freeware projects and a commercial license is required for any project that you make money from. I am a big believer in high quality, affordable development tools so the commercial license will be very affordable. The final price has not been set, but in the range of $14.95-$19.95US for the 1.x version, no royalties. This way, you use the SDK as long as you desire to see if it meets your needs up to the point where you're ready to ship your product and for a small fee you can go to commercial.

NecroDOME
I will post some screen shots soon. In the meantime the SDK has pre-compiled examples that you can run right away.

[arthurprs]

Yeah freeware, thats what i like to hear.

[Pyrogine]

Another interesting feature is support for configuration. For simplicity, I am currently using INI files, there is a TPEIniFile class to deal wih this. In addition to basic INI management there is a TPEConfigFile class that supports the notion of configuration file variables. This class has DefineXXXVar methods where you can define a variable of type boolean, integer, float and string. Now, any data written to these variables will be automatically be saved and loaded from the INI file when TPEConfigFile.Save/Load is called. TPEDemo/TPEGame declares a TPEConfigFile object and loads and saves configuration data automatically for you. You just have to define your variables and forget about manually saving/loading them. There are Init/Load/SaveConfig virtual methods that you can override to do specific things.

Also, the SDK support object streaming. Any object that is a descendant of TPEPersistent can be streamed. After the class type is registered with the streaming system you can override the virtual Save/Load methods to deal with data transport. I first used this object streaming system in Astro3D and it was very effective.

Other features include swap chains, multiple view ports, dynamic textures (you can lock and update your textures in real-time) and texture render targets. I will talk more about these features in a future post.