Hi again. I know I’ve been really silent these last few months, but that doesn’t mean progress on this project has stopped. Quite the opposite, actually. If you have been checking the Subversion logs, you might know that a lot has been done in that time. Many bugs were fixed, and a lot of code has changed, so I will recap the features that have landed in the latest development version.

Resource Browser

Previously to this feature, if you wanted to add a model in the scene, you had to add a new entity, add a new Model component, and choose the mesh resource file. This still works, but is quite slow and has no preview. So I worked on a resource browser that will render all the meshes it finds the resource locations to a thumbnail. Then you can add it to the scene with a simple drag and drop to where you want it placed. The thumbnails are cached and an hash of the original file is also saved, so they can be regenerated only if the mesh changes.

Particles

A particle system was introduced in the engine. They are used to simulate effects like fire, rain, snow, smoke and also used in games to model combat effects. Our system is quite basic at the moment, using OpenGL point sprites to render the particles. It’s all on the CPU for now, though a GPU shader-based version might be added in the future. Further developments will be done to make this system more flexible, to allow more types of effects.

Lua Scripting

The editor is based on a scripting workflow paradigm, very much like the popular Unity3D engine. You work on your visual of the game in the editor, while adding behaviour with Lua scripts. So it’s no surprise that Lua has been already integrated with the engine. Scripts work like regular resources, so they get things like automatic reloads in case you change the code while working.

I started the binding process with Luabind, which is a template-heavy library that helps to bind C++ to Lua. It worked fine, but I didn’t like the increase in compile times and code size. Also the bindings had to be mantained manually in the source code. So I switched to SWIG, a tool that you run on your code, and automatically generates bindings. I’m still not satisfied with some of the way it binds some constructs but in general it’s stable and is working fine.

Here’s an example of a simple script:



function onUpdate()

    local pos = transform:getPosition()

    pos.y = pos.y + 0.1

    transform:setPosition(pos)

end

Sound

The audio subsytem was actually worked on last year, but it was never integrated in the scene. It uses OpenAL, a free SDK that allows playback of 2D and 3D audio. It’s available on all popular platforms, like PC, Linux, Mac OS X, iPhone. I refactored the audio subsystem code to be up standards with the rest of the engine.

To playback sound you just need to add a Listener, which is usually attached to the main camera, and one source for each thing that emits sound. The engine will automatically manage all the buffers and playback the sources. The sounds can be in OGG, but a WAV loader will be added later, since it’s faster to decode than OGG, which can be useful for short sounds.

Streaming is still not available, but I will work on it. It’s very useful for background music, because you don’t need to keep all the audio loaded in memory at all times. It will progressively decode the sound as needed.

Fixed Pipeline

Since the start of vapor3D, I had the goal of using only shaders. Well, in the real world this doesn’t cut it. Some friends of mine with an old graphics card wanted to try the editor, but since I was relying on OpenGL 2.0 only features, and their graphics card only had OpenGL 1.5, they couldn’t run it. So I added support for a fixed pipeline path. It was actually easier than I thought, but since the engine and renderer itself are nicely modularized, it was made in a couple of hours.

Of course in this path some features might not work, and you might have degraded graphics quality, but it’s better to run with slightly worse graphics than not run at all. I think this will be important for vapor3D, especially since I want to do casual games later with it. The last statistics I looked at regarding this, showed that Intel graphics card are still very popular, and some models don’t have shader support.

Mobile platforms like the iPhone and Android also have a lot of devices that only support OpenGL ES 1.0/1.1 (no shaders) so this will be pretty good to later port the engine to those devices.

Build System and Dependencies

In the past, we have been using Visual C++ 2008, which needed to be upgraded to the Service Pack 1. We also needed Boost because we were using some new C++ stuff that wasn’t available.

Now the default IDE and compiler is based on the Visual C++ 2010 platform. All the dependencies were recompiled with this new compiler. Boost was removed, and due to that, some of the code that depended on it (threads, events) had to be replaced. The code is now simpler and with reduced size, since Boost is a little heavy on templates.

I also took quite some time to make the engine more modular, reducing the headers that have to be included in many files. This should result in a faster build in all platforms. Some measures to combat symbol bloat were also implemented.