A modeler with a difference.

Houdini.A few months back I had a friend demo me a 3D software package called Houdini from Side Effects software. Houdini is used extensively in film and movie circles and not so much in game industry, (which is dominated by 3D Max, Maya and to some extent XSI;) but mostly all big blockbuster films that have those great special effects that make you go “whoo”, “wow”, “cool” are pretty much made using this software. I am not exactly sure what my friend was working on, but it seems he was working an extension for the package and wanted some opinions on a custom file format. The thing that got me interested with Houdini was the way you work with the whole thing. It’s a little bit different from your conventional modelers (Max, Maya and XSI); in Houdini you basically do everything by combining operators. To tell you the truth I am not a great 3D artist. I have done most of the art-work in the game, yet my skills leave a lot to be desired. The only modeler I have ever worked with is Blender and you probably know Blender has a notorious and sometimes flawed reputation of being very difficult to use.

Houdini take a very different approach to 3D modeling. The reason I liked it is because it’s entire flow seems to be highly logic driven or as they say it “procedural”. This is an amazing concept and you have to actually see it to understand it fully. It has an interface that looks like a hierarchy of node graphs using which you pretty much model everything. The node-graphs create a kind of construction history which allows you go back and modify previous steps in a snap. This kind of flexibility means the overall productivity given by the software is unbelievable. It allows the artist to be as creative as he wants and at the same time also allows the entire design process to be non monotonous or in other words non-linear.

I would love to have a Houdini like software for designing a game, and I mean the entire game, with composition and everything. Having seen the software at work (, and being a 3D game engine developer,) made my mind race in 1000 different directions and I could see so many possibilities with the type of “procedural” flow. The creative potential could be enormous when applied to game creation. Now that I have looked at it, my guts tell me a procedural work-flow for any game design/creation/composition software will be a step in the right direction. Another very interesting aspect of this package is reuse. Besides the obvious benefits of a procedural type of work-flow the software encourages the use, or rather, the reuse of existing solutions and designs. This might sound like something out of a computer programming book, but it’s rather more subtle. Create a work-flow once, and then reuse it for several different solutions with minimum effort. That would be a game designer’s and an artist’s dream come true.

For those interested, there is a free learning edition called Houdini Apprentice provided by Side Effects.

Doofus runs on Wine!

Doofus on Wine.
Doofus 3D running on Wine!

Just before logging off of the Gutsy, I tried running the 0.0.5 beta version of Doofus 3D via Wine and “Voilà”, it actually ran! On Linux, with no tweaks of any kind, no nothing! Obviously only with the OpenGL driver, Wine has near absent DirectX support so it was only OpenGL, but still I was like blown away. I didn’t even expect it to work and I must say I could see no performance issues. Almost the same speed as Windows. I ran most of the unit tests and managed to finish the first 7 levels without any problems (, didn’t try any more but I am sure they will work just as well). To be frank I didn’t expect the game to run, and I mean run at all, let alone with the same speed as Windows.

I had no idea Wine had no DirectX support. I guess it must be very difficult to port the DirectX APIs (, but who’s complaining when the engine can run on OpenGL just as well) . The engine logs show Wine hooks in the native OpenGL driver on Linux, so I guess there is no visible performance loss while running the game using OpenGL renderer via Wine.

Update (Dec 17th, 2007): After reading Dan’s comments and some experimentation I could in fact run Doofus 3D via the DirectX renderer. However, the DirectX renderer will not run out of the box and there might be other legal issues associated with it, which are as yet unclear. You can read the entire comments here. I like to thank Dan for pointing out the error in the above post, Wine does have DirectX 9 support.

Apricot: The open game.

The Apricot game was officially announced, though the talk about the game has been going on for a long time now. I had almost forgotten about it entirely till I read the story on Gamedev today. A great initiative by the Open-Source and Blender communities on the whole I must say. I am really curious on how the team integrates CS with Blender and it’s definitely something I will be watching closely, though I don’t understand the rational behind using CS when Ogre was around. I am particularly interested in Blender-CS integration since Blender is also the modeler we are using for assets in the Doofus Game (,more here,) as well. I have particularly grown fond of it especially since the new compositing and multiple UV mapping tools were introduced. Just make it look pretty nifty, something like UnrealEd 😉 .

Blender is no doubt a good 3D modeler. Baring its unconventional interface, it has all the necessary bells and whistles needed for full-fledged game development. What the Apricot team is trying to achieve is commendable and I sincerely wish the Apricot team, “The very best of Luck” and hope we get to see a great game soon. Three cheers for Apricot! Hip hip hooray…!!!

Parallel computing using .NET.

My recent entries have all be about news events, and this one makes no exception. In fact it is just about the recently released Parallel computing extensions for the .NET platform (download). You will of-course need the also recently released .NET 3.5 framework update for them to work (, it comes bundled with the Visual Studio 2008; also released recently). On the very same page you will also find an interesting paper titled “The Manycore Shift”, which doesn’t do justice to it’s title I must say. The title makes you think that it has something to do about parallel core programming, but all it does is just outline what Microsoft intends to do with it’s parallel processing programming model. A marketing gimmick? I’ll let you decide. Looked to me like something written to sell an idea to company execs who have no knowledge of programming and/or the concept of parallel computing. The question is, why is it even shown on a MSDN developers page?

It’s been some time since I downloaded these extensions. Obviously (, if you are a frequent reader of this blog, you will know, ) I am a sucker for any technology that has the potential to provide performance enhancements. Unfortunately I have very little time to devote to anything right now so could couldn’t do too much testing with the extensions. Still, I did manage to glance through the documentation provided (, you can find the chm on the same download page,) and one thing that immediately caught my eye was the fact that the documentation talks about “different approaches for handling parallelism”. The framework allows you to have Data and Task parallelism using Imperative and Declarative models. The docs for the extension are good; hmm…. well not great I must say. They take for granted that the reader has some knowledge about the concept of parallel computing, and is pretty thorough with basic threading. Not the most friendliest of docs , but not a very big problem for someone with an experience of MSDN docs under his belt. The only other library I have seen that allows parallel computation using many cores is Intel’s Thread Building Blocks (TBB) which I think allows Task based parallelism.

Parallel Extensions to the .NET Framework contains a few different approaches for handling parallelism in your applications including imperative and declarative models for data and task parallelism.

I have not had enough time to experiment with either and I don’t think too much will change soon , but the fact I am writing this entry is because parallelism is going to become the single most important aspect of program design over the next few years. Especially in the area of game development where hardware and conventional programming approaches are being pushed to their very limit. There are going to be processors with 8 cores soon and there has been talk of next gen game consoles having > 20 cores. Any system that is being designed for tomorrows needs, has to take into consideration parallel computing. With a good documentation at hand, the Parallel computing extensions are a great way to get your hands dirty with the concept of parallel computing. The extensions also provide some real world examples. Invaluable for learning anything. (I am sure some of you are going to be very interested in the ray-tracer example 😉 .) Go get some!

Nintendo with an interesting Operating System.

Nintendo has released an Operating System named ES (read translated version, original Japaneses version ) under an Open Source License. What the whole idea is behind having an OS is still unclear to me. If they were planning on having an OS for their consoles, there are other more attractive alternatives like Linux. Sony has done something on these lines by having Yellow Dog Linux run on their PS3 consoles.

The website is pretty vague and doesn’t delve too deeply into what the OS is intended for, but it’s clearly something too keep and eye on. Maybe it is just some research project. Maybe the company is still toying with the idea and wants to see what the response from the community will be, who knows.

The OS itself seems pretty interesting. The kernel seems to be written in C++ and it runs natively on x86 and QEMU. They have a port of SmallTalk programming language called Squeak. I am not sure what the intension is really, will it be used for game development on that platform? I guess there must be some way to do C++ programming as well, considering it’s x86 compatible.

Visual Studio Express 2008 – First thoughts.

It’s been about a week since I downloaded Visual Studio Express Editions and I have done some fair (not too much) bit of coding using VC++ Express and not so much with Visual Web Developer. Didn’t touch any other editions as yet, so I am going to be very C++ centric with this one. Generally, the UI in new Visual Studio Express has become more responsive. Now don’t get me wrong, I am not saying 2005 was unresponsive but sometimes it took judicious amounts of time to open Dialog boxes. For example the Configuration dialog box took some time to come up initially, I mean the first time it was brought up, so did the search dialog. No such problems with this version, cool, that was a nag!

The compiler speed has increased, not by too much but it has. I must say I do use the /MP option a lot, but I still generally feel the speed of compilation is a little bit faster. Maybe on a faster machine the compiler could be a magnitude faster, but I still run a 3GHz 2 core machine that is 2 years old now. It’s always nice to have a faster compiler, especially if your project takes about 15 min to compile from scratch and is heavily templatized!

On the other side I have had crashes with the express editions, 4 times to be exact. Considering it’s been only a week, that’s just too many times I must say. Not much has changed since 2005, even then, I must say the express edition is pretty good. It does a lot of things not easily attainable in other IDEs and C++ compilers. People have complained about not having a resource editor; it’s not too much of a hindrance to a game developer like me who pretty much has no need for a resource editor. In any case there are a lot of free resource editors around that you could easily use to edit your resources, or just use wxWidgets!

On the whole the express edition of C++ is good. Hey and best of all, the express editions are free, should we even be complaining!

GP meets the GPU.

Things have been hotting up in the area of GPGPU lately and I am kinda feeling left out of the crowd especially since a couple of people I know have been seriously working on GPGPU projects in their spare time. Interestingly I have never had the inclination towards learning more about GPGPU until now that is. I have had only a passing glimpse at CUDA but never laid a hand on that technology. Partly because I don’t have any GPU that is GPGPU friendly and partly because I have been involved so much in developing the game and setting up the business along with it.

While GPGPU has been around for quite sometime, the advent of CUDA and some recent events make me believe we could be seeing a significant progress in this area soon. I was just reading up on Intel’s acquisition of Neoptica for their hush hush Larrabee project and it just makes me wonder if we could see a significant trend and a general upsurge in GPGPU related technologies in the near future. ATI has been close on the heels as well, just recently talking about their GPUs being used for all sorts of general purpose computations.

My experiments with GPUs have not yet gone beyond shaders until now and I think I should be looking at GPGPU very seriously from now on.

Some additions to yesterday’s update.

  • I was browsing through Visual Studio express page when my interest was drawn towards a toolkit called Game Creators GDK. The interesting thing is, it integrates with the express edition of Visual C++ and thats a little bit surprising. Or maybe not; many indie and aspiring game developers do tend to use express a lot. Just out of curiosity I did download it and the package seems to be a solid beginner level package especially since it is free. If you are a budding game developer you have to check this out. It also comes with a bunch of tutorials and extensive documentation. Yes, it’s a C++ SDK but, I didn’t delve in too deep so can’t say too much about it really.
  • I missed this one yesterday; but XNA Game Studio Beta 2.0 has been released. I tried a hand at XNA a long time back, when it was first released but never really got fully into it. It still remains a mystery why MDX was discontinued in favor of XNA. Maybe XNA is more of a complete game creation toolkit rather than a wrapper over DirectX.

Some recent news updates.

I generally have such an entry every 2-3 months so here goes.

  • Visual Studio 2008 is here!
    Microsoft recently released Visual Studio 2008 along with the Express editions. If you are like me then head on down there and start downloading the express editions, like now!
  • Delayed but good news from AMD/ATI:
    AMD (and ATI) has/have announced the availability of the HD 3870 and 3850 range of graphics cards, widely believed to be an answer to NVIDIA’s 8800 GT and GTS range of GPUs. They are based on ATI’s new RV670 graphics chip. Just how much of a challenge will they be to the 8800 has yet too be seen, but I am guessing we could be seeing stiff competition here. Read details of the spec here and here.

    In other news, very recently AMD also released the Phenom Quad core processor, X4 and the 7940FX chipset. Again to early to say how things pan out. More details here and here.

  • Updates from NVIDIA:
    As you know NVIDIA released Cg 2.0 Beta recently. Along with that two other releases from NVIDIA just rencently; 1) PerfHUD 5.1 and, 2) though I am not working on Cuda, I know some of you are, you can grab the Cuda 1.1 beta.
  • Disappointment in the OpenGL camp.
    As announced recently OpenGL 3.0 specification is delayed due to…. oh well, lets start that again; It seems OpenGL 3.0 has had some last minute changes and the specification release was put on hold. Let me not say anything further, I don’t like getting hate mails.

Selecting a scripting engine – Part 3.

Some more RnD on scripting languages. This is the 3rd part of the series, the first 2 parts [1] and [2]. I generally do all the RnD on this when I take time away from working on the current game or I am generally bored or stuck on a bug somewhere. This time I focused on Python again and also tried something with Squirrel. Both are very different languages and each one has different challenges to overcome. I also took a dig at something I haven’t touch before and that is C#, yes, as a scripting language.

Python:
Python is general is very good as an extension language. You could bind all your code with python and then use only python to code your entire game. Python is clearly designed as heavy duty application development language and embedding it is not what is recommended. While you could very well do so, I found it to be rater clunky and non-intuitive, that’s not to say it can’t be done. So I focused primarily on “extending” and not “embedding” while working with python. There is no real advantage or disadvantage to either method, but I rather want to carry the O2 engine in the direction of “extending” too keep the engine accessible to people who have no, or limited knowledge of C++.

This time I focused on Boost.Python more than SWIG. I haven’t benchmarked anything as yet, but I guess any overhead via bindings would mean a small (, or minuscule) decrease in speed. That doesn’t really bother me since most of the heavy duty calculation stuff will be done in the C++ libraries anyways. However what bothers me is the maintenance and scalability of the binding code. Any binding code is difficult and uninteresting work. It is something that I know programmers will hate to do and it is something that will have to be done time and again as and when the engine scales. Another thing is time. It takes ridiculously large amount of time to write large portions of binding code. That is where I think Boost.Python edges out slightly over SWIG, hello to the Py++ bindings code generator!

Apparently the code generator parses C++ code to GCC-XML and then uses the XML to generate the bindings. It seems too good to be true, but that is what it does. To be fair I have only tried a very small program with it and I have no clue about larger programs. I might try something larger with Py++ this weekend, again, maybe. However, larger projects like PythonOgre already successfully use it so I don’t think it will be too much of a problem with the O2Engine. Check out the next in the series for that.

Squirrel:
Squirrel is a lightweight language, much lighter than Python and supports all modern programming features. “Squirrel is a high level imperative/OO programming language, designed to be a powerful scripting tool that fits in the size, memory bandwidth, and real-time requirements of applications like games.” I experimented a lot with squirrel for the past couple of weeks. The language is cool, there are no two opinions to that. It is all what they say it is and more. It tastes like an embeddable language but I am sure it will do an equally good job at extension. In someways it is a lot better than python. For one it is designed to be embeddable while python is not. It has a much smaller memory footprint and, even though I have no numbers to prove, it must be faster than, or at least equal in speed to python.

The big negative part of this language is it’s bindings. Seeing the binding code will make you cringe! It is hopelessly complicated, almost impossible to understand at times. Binding even a small piece of code with about 5 classes took me over and hour, and those classes were not even extensive. I hate to think what will happen while integrating a heavily templatized game engine! For some reason the bindings have to be integrated into classes themselves and even if you did bypass that, it is not clean at all. A lot of glue code needs to be put in, too much I think. While there are binding systems like SQPlus and jkBind, bindings in Squirrel are non trivial. jkBind is particularly interesting and easier than SQPlus, but even then it misses out on functionality that is critical to extending any language. Scaling any such binding system on a large live project having multiple developers will be a nightmare.

If the binding systems were improved, Squirrel would have been my choice hands down. Having said that, I am currently not discounting any language outright. Choosing a scripting language can be tricky and my choice could very have a significant consequence in the future.

C#: (& Mono)
Ah! So I finally got around to having a go at this language. I have only tried a couple of things thus far but I am already impressed. First, C# is by no means a scripting language. OK to be clear I have never used C# before, just had some fleeting glimpses at it, but never worked on any project involving C#. It is a full fledge high level language and is very very powerful, but I bet you already knew that. Extending C++ code using the Microsoft compiler is easy, maybe not as trivial as Py++. One thing I can say for certain is C# is faster than Python. I am not so sure about Squirrel but I bet it must be a little bit faster to that as well. I won’t go into too many details just as yet because I still want to do some more testing and extending before I make some claims. So more on C# later.

In my next part of this series I will try and post some timing values. Timing values will allow for better comparisons of languages and binding systems. I will also try and post some binding code. That will just give a better overview of the task and effort required to have a binding for a language.