MekaWars' simulator

Almost three months have passed since the last post. I was quite busy and it was impossible for me to publish the promised daily post.
However recently I've found some spare time to spend and I used it to continue the development of MekaWars Offline. In particular I have successfully ported the already working Lua simulator to C++, so very large starship battles are going to be possible.
The port wasn't very difficult, because the Lua code was already object oriented, and the final result is more mantainable and error proof.

CodeBlocks & Borland C++ at work
to compile the MekaWars simulator

As you may know, MekaWars Offline is a project different from MekaWars Online. In fact, the latter is going to be played online among a large number of users, who are going to manage their empire like in other browser games, but its core will be the battle simulator of MekaWars Offline. This one will be more similar to a mixture of JRobots and Gun-Tactyx (where the players are only going to share the algorithms of their bots), as I'm going to describe in the next posts.

New FORUMS at SourceForge

Thanks to Tom, the official forums related to the APOCALYX 3D Engine has been hosted at xfuj.com for a long time. Now SourceForge.net has provided phpBB support to their users, so I have decided to free Tom's server and move to the new phpBB server. Thank Tom for you great service!

The new APOCALYX Forums are divided into the usual sections:

• GENERAL SUPPORT
  This section is devoted to questions about the general usage of the engine, such as, but not only, the use of a particular feature or library, report strange behaviors in your own code, or ask for help in the development of tricky algorithms. Also questions about the Lua scripting language are welcome, because Lua is the main language used in the development of APOCALYX-based demos and games.


• GAMES DEVELOPMENT
  This section is devoted to questions about the development of games using THIS ENGINE (not games development in general), such as, but not only, the application of particular features or libraries to realize a certain technique useful for your game, report strange behaviors in a large project, or ask for help in the development of the game itself.
  Remember also that I post daily news about the development of my own games on the APOCALYX 3D Engine BLOG.


• ENGINE DEVELOPMENT
  This section is devoted to questions about the LGPL C++ sources of the engine, such as, but not only, the included source code of a third-party library, report strange behaviors in C++ code that you have modified, or ask for additional built-in features. Questions about the C++ language are NOT welcome, because the modification of existent code requires a very good knowledge of C++.


• TOOLS SUPPORT
  This section is devoted to questions about the third-party tools that you may used to develop your APOCALYX-based demos and games, such as, but not only, the use of a particular source editor (there is a very good one, currently in development, known as NsEditor), the use of certain resource editors (like the BSP editor GtkRadiant), or the other tools listed in the Tools page of the official APOCALYX site.
  In this case, I can't guarantee to help you much with my answers, because my knowledge of those tools is not advanced, but I'll try to answer anyway.

I hope that these new forums are going to be a useful tool for all the APOCALYX users.
Feel free to post frequently! I'll answer as soon as possible.

APOCALYX 3D Engine 0.9.3

The APOCALYX 3D Engine 0.9.3 release is finally available. It includes some improvements and bug fixes. To download the engine in a easy-to-get 60 Mb installer, or in smaller selected pieces, visit to the APOCALYX Official Site's Downloads page.

New features:

• Added MDLModel functions: setTransition(), setTransitionTimer(), getStoppedTransition()
• Added IM (Imaging Toolkit) support in IUP GUI
• Added primitives: Cylinder, Disk, PartialDisk, Sphere
• Added setPointerVisible(), isPointerVisible()
• Added string.pack(), string.unpack()
• Fixed bug in collisions between ODE objects and BSP geometry
• Added support for Arbitrary Precision Math (MAPM)
• Added support for Video Capture functions (experimental)
• Added support for MySQL databases
• Added support for SQLite databases
• Removed AngelScript language support
• Removed SMALL language support
• Removed CSL language support

New demo (in full-installer):

• Mushroom's Ride, that shows some of the engine features at work.

You can download the runtime of the engine and the demo packages from the Downloads page. For more detailed descriptions of the demos, visit the Demos page. Feel free to ask more about the new capabilities of the engine on the forums or by e-mail. Visit the APOCALYX Blog (this one) to read daily news about the engine and its development.

APOCALYX 0.9.3 alpha3

Yesterday I posted a link about the new preview of the next release of the engine (download the new executable here)
Apart the bug related to eSpeak that I discussed yesterday, the preview includes some improvements as listed in the history document:

• Added MDLModel functions: setTransition(), setTransitionTimer(), getStoppedTransition()
  
• Added IM (Imaging Toolkit) support in IUP GUI
  
• Added primitives: Cylinder, Disk, PartialDisk, Sphere
  
• Added setPointerVisible(), isPointerVisible()
  
• Fixed bug in collisions between ODE objects and BSP geometry
  
• Added support for SQLite and MySQL databases
  
• Removed AngelScript, SMALL and CSL language support
  

These are only some of the improvements fully available when the next release will be published.
For any question, feel free to post on the forums.

APOCALYX 0.9.3 alpha2

I made some modifications to the engine, not enough yet to justify a new release. Anyway the blog readers can download here the new executable.

A description of the modifications:

• The collision between ODE objects and BSP geometry is finally fixed. Try the demo "BallsOnTriMesh.lua", and you'll see that now the balls bounce correctly on the BSP level
  
• The IUP GUI, now includes the IM Imaging Toolkit: this means that also images and icons can be displayed in a GUI created with IUP
  
• Added a few new primitives: Cylinder, Disk, PartialDisk, and Sphere
  
• the MDLModel has 3 new functions that are very useful to perform smooth transitions between different sequences
  
• The AnimatedTexture class now contains functions to stop the animation and show specific frames
  
• Added the functions setPointerVisible() and isPointerVisible()
  
• Removed the AngelScript, SMALL and CSL scripting languages
  

The ancient origins

Users sometimes ask how much time I have spent in the development of the APOCALYX 3D engine, but I don't know which is the correct answer. In fact, I have developed most of the engine in intensive short periods, then for long weeks or months I couldn't write a line. They also ask about the name: where does that "APOCALYX" come from? The current logo has nothing to do with the origin of the name. It is a recent acquisition, suggested by a reader of the blog, so it appeared long after the name.

To answer, I must tell when precisely the engine began its first steps. In the far 2000, after a few years of experience in Java programming and the initial success of my online game JROBOTS, I planned to create a similar game implemented in a shiny 3D graphics, that became in 2002 the first GUN-TACTYX. My early attempts were DirectX based (at the time still version 6 and then 7), but I wasn't very satisfied because I ignored the basic techniques on which 3D engine were based.

In 2001, the owner of the famous NeHe site (who has published for years tutorials about OpenGL programming) organized a mythic contest known as the 2001 NeHe Apocalypse Contest. Among the entries there was one of an italian programmer, good enough to win the third prize of the contest. The author included in his demo the complete sources, based on OpenGL and written for my beloved Borland compiler. That sources were a revelation and the author kindly gave his permission to use them in my first demos and, as time passed, a more complete and powerful engine has grown up. Some lines of the original code are still there at the base of a more complex structure, now completely based on Lua scripts.

In conclusion, I must thank Matteo "Fuzz" Perenzoni and his "Apocalypse demo" written for the "NeHe's Apocalypse Contest", that's where the engine and the APOCALYX name, modified in the final characters to become unique in Google searches, come from.

Terrain performances (II)

After the comparison between the terrains of Irrlicht and APOCALYX, now it's the turn of the promised comparison between the terrains of Ogre3D and APOCALYX. I have extracted the height-map and color-map from the Ogre3D terrain demo and, then, I have passed the data to the APOCALYX "infinite terrain". The following screenshots show the results.

Ogre3D above, APOCALYX below

Again it's not easy to compare the results. Also Ogre3D, like Irrlicht, applies the color-map to the height-map and superimposes the detail-map. Then the borders of the map are the usual unrealistic square linear cut all around. As I have already explained, APOCALYX applies a color-map (the shadows) to the height-map, then a coarse-map and, finally, the detail-map. No cuts are noticeable when the heigth-map presents periodic boundaries.
Another difficulty was to choose similar detail maps, because the Ogre3D original ones were too light for APOCALYX. Finally, I lost myself in the map and I couldn't set the same view. Anyway, those two pictures give almost the same frame rate.
At the end of the tests, the conclusion is the same as the other comparison: more detail in Ogre3D and Irrlicht, (fake) larger landscapes in APOCALYX.

Terrain performances

Yesterday I compared the rendering speed of Irrlicht and APOCALYX. I used the same MS3D model and the performences were almost the same. Now it’s the turn of terrains.
I have extracted the height-map, the color-map and the detail-map from an Irrlicht demo. Then that data was read by an APOCALYX “infinite terrain”. The results are shown in the following screenshots.

Irrlicht above, APOCALYX below

It’s difficult to compare the results, because Irrlicht simply applies the color-map (that becomes the main texture) to the height-map, then superimposes the detail-map. In addition when you reach the border of the map, you can see an unrealistic linear cut all around. Instead, APOCALYX applies a color-map (that defines the shadows and the overall color) to the height-map, then a coarse-map (a periodic main texture) and, finally, superimposes the detail-map. No cuts are noticeable if the heigth-map presents toroidal boundaries.
As you can see, I had several difficulties in setting the same parameters in the two demos, but I got two roughly comparable pictures at the end. Unluckily, this time APOCALYX loses 220 fps against 260, but I think that there are too differences for a reliable comparison, because the two kind of terrains possess different advantages: more detail in Irrlicht, larger landscapes in APOCALYX.

MS3D performances

A few weeks ago I made a comparison between the render speed of similar models in MS3D and MD3 format (read the post) and I realized that the engine can render a large number of MD3 models at the same frame rate of a small number of MS3D models.
One may ask if other 3D engines render MS3D models better. Read below to discover that… APOCALYX wins again!

Irrlicht above, APOCALYX below

In the screenshots above, you can see the same MS3D dwarf model rendered by Irrlicht (top) and APOCALYX (bottom). The Irrlicht’s picture is taken from the mesh viewer programmed in C++ of that engine, while the APOCALYX’ picture is rendered by the Lua demo “ModelMS3D” included in DemoPack2 (I simply removed the shadow and the terrain, because the Irrlicht viewer does not show any of the two, only the skybox).
In conclusion, which are the results? APOCALYX beats Irrlicht 330 fps against 320. Well, let’s say it’s a draw, but this comparison says that the MS3D viewer included in APOCALYX is as good as the one of Irrlicht.
We get another surpsising results: an engine developed by a single coder can compete against more advertised engines developed by a team of programmers. For other surprising results read the comparison between the BSP viewer of Irrlicht and APOCALYX and the BSP viewer of Ogre3D and APOCALYX.

Watermarks

This blog begins to give some good feedbacks. First of all, the poll about the model that you wish to see in GUN TACTYX 2 is going to find its winner, in a few days, between "The Trenches" and "The Specialists".

Then, thanks to a comment by Robert, I realized that the Ogre screenshots look better than APOCALYX also because there is an appealing watermark attached. The suggestion was about an atomic mushroom, so I unchained my poor graphic capabilities to produce the front-image of the blog, a powered-by button and a watermark. You are going to see this watermark superimposed on the demos in the next release of the engine.

If you want to draw a better watermark and post it, I'll be very happy to open a new poll to choose among the best ones.

GameDev's "Image of the Day"

Some screenshots of APOCALYX are now featured in the "Image of the Day" at GameDev.

GameDev is a great site for game developers: interesting articles, useful resources, well frequented forums, challenging contests etc.

Probably I hardly could develop most of the APOCALYX code without the help of sites like GameDev.net, Nehe.GameDev.net, OpenGL.org, GameProg.it, Gamasutra.com, CFXweb.net, FlipCode.net (the latter two no more updated). Thank you guys!

BSP performances (II)

Yesterday I promised a comparison between APOCALYX and Ogre about the rendering of Quake3 BSP levels. I tested a level taken from the Ogre demos, that you can see below, and the result is surprising: while Irrlicht and APOCALYX behave almost the same, Ogre is much slower! Ogre got only 61 frames per second against 213 using the same configuration (same resolution and no vertical sync enabled in both cases).

The result may be surprising, but you must consider that Ogre renders some animated textures that APOCALYX ignores. The differences are evident in the screenshots.

Ogre is more than three times slower, but the scene looks much better. In conclusion, it's time to improve the BSP support of APOCALYX, trying to keep it fast, of course.

Ogre above, APOCALYX below

BSP performances

From time to time, occasional users of the engine say: your engine is interesting, but in rendering Quake3 BSP maps it is slower than Irrlicht, Ogre, or... (put here your preferred open source engine). Then I discover that occasional user has compared different maps, in different situations. A typical mistake of unexperienced users: a comparison between the Irrlicht "Quake3Map.exe" demo at the default resolution (640x480) and my "BSPLevel.lua" at 1024x768!

So, in conclusion, is APOCALYX really slower than Irrlicht in rendering BSP levels? Below you can see two screenshots of the same level from above (taken from the Irrlicht demos). In the same conditions, the utility "Fraps" reports almost the same frame rate.

In the next days, I'll make the same comparison between APOCALYX and Ogre. I need just the time to extract a BSP level from the Ogre demos.

Irrlicht above, APOCALYX below

A new movie

It's a long time since the last (and first) movie featuring some of the engine demos, so I've collected several cuts from the most significative demos, a few of them not yet published, in a 20 Mb file.

This movie and the old one give an idea of the graphic capabilities of the engine, but it's always better to try the features on the field, of course, so run to the APOCALYX site and download the demos.

The APOCALYX Blog is here!

Ok, I know it's boring to wait for news about the APOCALYX 3D Engine on the official site, so I have decided to start this blog that I'm going to update often with news about the recent developments. Stay tuned!

In the picture you can see APOCALYX featuring the great MD2 dragon model by Magarnigal. You may notice the flame following the dragon's mouth: it's not easy to attach a particle emitter to an MD2 model, but the engine can do the trick. Give new life to your MD2 models!