simplui 1.0.4 released

New in this version:

  • Support for multiple windows
  • Java-style flow layout
  • Full batching
  • Numerous performance enhancements and bug fixes
  • Minor theme tweaks
  • setuptools/easy_install support

Given the speed of development, simplui has moved to its own googlecode project:

http://simplui.googlecode.com

You can obtain the source from Mercurial, or download the binary package there.

In addition, simplui has been integrated with setuptools/easy_install. You can find the package listing in the PyPI directory (here), or you can install immediately with easy_install:

easy_install simplui

(note that easy_install will not install the demo application and themes)

This release does come complete with a few of caveats:

  • simplui is only compatible with pyglet 1.1 maintenance – not the experimental version in trunk
  • There is a bug in pyglet 1.1.3 which can cause crashes if un-patched.
  • On Mac OS X, you may need to upgrade setuptools (sudo easy_install -s /usr/bin setuptools)

simplui 1.0.3 released

No major features this time, instead a slew of small bug fixes, an update to the API, and the rendering code has been rewritten for performance (primarily though batching).

I wasn’t intending to push a release out until more features were added, so consider this a maintenance release.

You can download the tarball, or browse the source in SVN.

Simplui 1.0.2 released – now with themes!

The default themes provided by simplui

The default themes provided by simplui

Today brings the 1.0.2 release of simplui. This is a beta release, previewing major enhancements, and I need as much feedback as possible on the new features. As such, this release isn’t heavily optimised – that is on the wishlist for next release.

The big news for this release is themes support. The GUI is now fully skinned, using a variant on the ninepatch method code developed by Joe Wreschnig and Alex Holkner on the pyglet mailing list.

Each GUI frame can use a different theme (even in the same time!), and the theme can be changed at runtime. I have included two sample themes, one modelled on the Mac OS X ‘Aqua’ interface, and the other on the PyWidget GUI toolkit.

Also included are the usual crop of bug-fixes, including the squashing (hopefully for the last time) of the persistent event clipping bug.

As per usual, grab the tarball, or visit SVN, and let me know if you have any comments or suggestions.

Starfall: planet rendering

I just posted a quick youtube video to demonstrate the current state of the planet renderer. This is early development stuff, and the eye candy is minimal, but it should give you some idea of the scope.

I will follow up with a more technical blog post in the next few days, explaining all that is going on behind the scenes, and can’t be seen in a video.

Part of the rationale behind this video is to stremline the whole video capture and posting process. Unfortunately, it hasn’t been entirely straightforward so far. I went through a number of video capture tools before settling on FRAPS, which works well enough (though I would have prefered a free tool).

I also have had a terrible time converting the video for youtube – ATI’s Avivo video converter is blazingly fast, but apparently produces an incompatibe audio codec in any of the high-quality settings. I was forced to fall back to the CPU-based Auto Gordian Knot, which both does a worse job, is very slow on my little Athalon 64 x2.

I am now experimenting with ffmpeg, but the command line options are confusing to say the least. If anyone has any clues/tips/tricks for getting FRAPS encoded video (and audio) into a suitable format for youtube HD, please let me know.

simplui v1.0 released

A quick demo of simplui's controls and capabilities.

A quick demo of simplui's controls and capabilities.

I like pyglet a lot. Much more than a lot.

However, the lack of a compelling GUI toolkit for development purposes has been a major irritation of late. This week I finally sat down and wrote my own GUI toolkit, from scratch, and I am happy enough with the way it works to release a first version to the public.

Continue reading

Procedural Planets

Normal-mapped planet.

Normal-mapped planet.

The semester is over at last, and my grades should be in by Monday. It has been a tiring semester, but not a bad one, with interesting courses in database implementation and parallel architectures, not to mention philosophy.

With the end of the semester comes a little more free time, and I have spent a chunk of it recreating my old procedural planet demo in Python/Pyglet.

The first big plus is that whereas my previous implementation was over 5,000 lines of C++ code, the python version is under 1,000 loc, plus a few hundred lines of tightly optimised C for the tile generation back end.

The other plus is that this version actually works. I finally found the time to fully implement the crack fixing algorithm, and the results are very good (although there are still a couple of unresolved edge cases).

I also implemented normal map generation in GLSL, to offload the computation to the GPU. This more than doubles the performance of tile generation, to the point where several tiles can be subdivided or combined each frame.

Wireframe of planet.

Wireframe of planet.

From a technical standpoint, the planet starts as a cube, and each face is subdivided to form a quad tree. For each tile at the deepest level of the quad tree, a small heightmap is generated using 32 octaves of 3-dimensional simplex noise. This heightmap is used to generate the vertices for the tile, and passed as a texture to the GPU in order to generate the normal map.

Because applying tangent-space normal maps to a sphere is an absolute nightmare, I take the unusual approach of generating object-space normal maps. These are considerably more expensive to generate, but avoid the tangent-space mismatch at cube edges, and look fairly decent in practice.

Interestingly, this version allows one to fly right down to the planet surface, and maintains interactive framerates even on my Intel integrated X3100 (complete with the awful Mac drivers). By the time I add atmosphere shaders and detail textures, I expect that I will have to switch over to my desktop, but for now, I am very happy with the performance.

Of course, there are still several challenges to overcome, in particular the issue of depth buffer precision. The planet you see above does not suffer from a lack of depth buffer precision, but it is only 1/10 scale of the Earth, and ideally I would like to be able to render gas giants on the order of Jupiter as well. This requires some clever on-the-fly adjustment of the camera frustum, and I don’t quite have a handle on the best way to accomplish it.

Love

If you haven’t already, go watch Eskil Steenberg’s GDC videos of his game Love, and the tools he uses to build it. The game itself is fresh and beautiful, but as an programmer, it is his tools that have blown me away.

The last game development tool to really catch my fancy was Carmack’s co-operative world and megatexture editor for ID Tech 5, which was demoed back in 2007, but I can honestly say that it pales by comparison to Eskil’s tools.

And the best part? All of Eskil’s tools are open-source.

Ashima IV – a brief postmortem

A couple of weeks ago I submitted a space sim to the udevgames competition (see my previous blog post). Ashima IV didn’t win any prizes, but that was hardy unanticipated, given that the game was barely to a playable state. Overall, I think the experience was very rewarding, and I hope a few of the lessons learned can be informative to others as well… Continue reading

Ashima IV

Splash screen/main menuI haven’t had much time to update here in a while, having been hard at work on an entry for the udevgames contest. If you read my earlier post, you may recall I was initially going to enter a pixel-art lemmings clone, but midway through development, I decided that the concept was basically not fun to play.

So I switched over to building a 3D space-sim, with only a single month remaining in the competition. The plus side was that I have much more experience with 3D graphics, but lack of time was still a killer. I can’t honestly say it is much more fun to play, given its unfinished state, but the core gameplay is certainly there.

The game is basically a prototype, and an example of a larger game produced with Python and Pyglet. As per the rules of the competition, the game is open source, although in its present state, it probably isn’t much use to anyone. When I have the time, I intend to cleanup and comment the code, which will hopefully be useful to others starting out with Python, Pyglet, or games development in general.

Space combatDespite the code being cross-platform, I only have a Mac binary up for now, as I have unable to coerce ODE into even a semblance of stability under Windows. When or if I manage to sort the crashes out, it will run fine on both platforms.

So if you have a Mac, and want to take the binary out for a spin, you can grab it from http://www.udevgames.com/games/entry/ashima_iv, or if you would like to browse the source, visit the project page at http://darkcoda.googlecode.com. While you are about it, consider taking the time to check out the other entries to this year’s udevgames contest, and remember to vote for your favourites!

RAII: why is it unique to C++?

Many programmers (in particular aspiring game developers), despite endless advice to the contrary, learn C++.  There seems to be a widespread belief that all commercial games are written in C++, along with an idea that it is the ‘only real programming language’ – apparently they missed the earlier, identical memo about C 😉

Now, I am not saying that C++ is a bad language – on the contrary, it is as powerful and flexible as you typically need, and for its intended purpose as a systems language, it does very well. But C++ is a painful language to use, with myriad design flaws, all plastered over by the slow creep of feature bloat. The archaic preproccessor and complicated template mechanism in no way match their counterparts in dynamic languages, and the compilation model is simply heinous.

The language does have a couple of high points – in particular the standard library is excellent, with a wide selection of containers and algorithms, a generally very high implementation quality, and a simple, uniform interface. But to my mind, the most useful (and often undervalued) feature is RAII, “Resource Acquisition Is Initialisation”.

With RAII, we create an object (sometimes known as a ‘handle’) to manage the lifetime of some resource (a file, socket, block of memory, …). The object is designed so that the resource is allocated and/or initialised in the object’s constructor, and destroyed in the object’s destructor.

This means that we no longer have to explicitly manage the lifetime of the resource – just create a handle on the stack, and the resource is automatically created. As soon as the handle falls out of scope, the resource will be destroyed. We can even wrap the handle with a reference-counted smart point (such as boost::smart_ptr), and the resource will now stay alive as long as any client object is using it, and be destroyed as soon as the last client finishes. And the benefits don’t end there either – destructors are called during exception unwinding, which means that our handle will correctly dispose of its resource even in the event of a failure or crash (very important for resources such as global semaphores, which will other wise hang around forever).

So why is this incredibly useful technique not fully present in newer languages, at least a few of which have been billed as ‘C++ killers’? Many of these newer languages offer a limited form of RAII, but at least Java and Objective C lack RAII entirely.

D’s scope keyword, Python’s with statement and C#’s using declaration all provide limited RAII, by allowing resources to have a scoped lifetime, but none of them readily or cleanly support the clever tricks allowed by C++’s combination of smart pointers and RAII, such as returning handles from functions, multiple handles in the same scope, or handles held by multiple clients.

The answer seems to be garbage collection: all of these newer languages are garbage collected, while C++ (at least in its current form) is not. C++ ties RAII to object destruction, which becomes an issue with garbage collection, as most garbage collectors do not guarantee when they will destroy objects, or even if they will destroy objects at all.

But this lack is more than a little annoying to someone who learned to program in C++: take as an example OpenGL vertex buffers or textures. These buffers need to be released as soon as possible (to free up precious video memory), but unfortunately the same vertex buffer may be shared by many copies of a model.

Since we can’t afford to give each model it’s own copy of the buffer, we need to implement reference counting. In C++ this would be as simple as wrapping the buffer object in a smart_ptr, but in any of these languages we have to explicitly implement reference counting in the buffer object, and explicitly call these functions from each client – which isn’t bad for a single type of resource, and a single type of client, but quickly becomes tedious when there are 10, or 20, or even more, and reference counting has to be invoked from 100’s of locations in the code.

Now I finally come to the point behind all this: I have moved away from C++ for the majority of my programming, but I haven’t really come up with a satisfactory solution to this (apart from manual reference counting). So I am fishing for your thoughts and suggestions here – please comment, and let me know how you deal with replacing RAII in modern languages?