Side project update

| categories: luftballons, tech, libason | View Comments

Consider this the obligatory "sorry I don't post more" post.

I have a couple of econ/political rants brewing, and I'll get to one of those in a minute, but for today let's talk about software.

Luftballons

Making a game engine is hard.

I knew this, of course, and I planned for it. There's a reason that despite being little more than a messy OpenGL demo, Luftballons arrived on the net with a website, a mailing list, an IRC channel (#luftengine on Freenode), and a big list of lofty goals. I never thought I could do it alone, and, not being terribly sure how to promote a project that wasn't going to have any usable form for quite some time, I just put as much community infrastructure in place as I was able to and made some noise.

I have taken a single patch.

The internet is littered with the remains of game engines that never took off. If this just ends up being an ever-unfinished personal tinkering project, I've hit par for the course.

That said, a couple of personal friends have shown interest in poking around in the code lately, and I worked up the energy to dust the code off and look it over.

It no longer worked.

It seems one of the libraries I used to parse a certain thing I hate not only managed to change APIs in the gap, but introduce a fatal bug in the process. Bug filed. I've exercised some neighboring open source code, the project has done good in the world. Plus the experiment the developer had me try seems to work, so the demo works again on my laptop at least. Hopefully there will be a consumable patch soon.

libason

Databases? New forms of algebra? Also hard.

Since release, the biggest thing that's shown up in libason is a disk B-tree file format which was intended to be the beginning of persistent storage. I'm a big believer in the "write one to throw away" software approach, and I will probably throw most of this away. I still don't know what I was thinking. I'm sorry. It's all wrong.

I'm still finding bugs in how we reduce values to simplest form too. That code is due for some major renovation soon. It's way too intricate for steady maintenance.

And that's it. See you in six months for my next apology.

Read and Post Comments

Valgrind etc.

| categories: luftballons, tech, valgrind | View Comments

My last post attracted some... awkward press. I didn't intend to cause a panic, and I'm hoping nobody other than Phoronix took it that way.

I hemorrhaged disclaimers in the previous post, so let's skip the apologies and get right to the point: when I took the advice I got from the Mesa devs and rebuilt libdrm with Valgrind's development headers installed, the number of errors was reduced to 3 (filed). Turning up leak checking revealed some more intrigue, but still nothing to panic about.

The point I was making was about Valgrind itself and development practices, and that still stands. I wish we could build more of our packages against Valgrind, so packages with special needs like Mesa could offer a better developer experience out of the box, but it would make the dependency tree fairly ugly, which can be its own pain.

So let's all relax. I fixed the problem I originally had and have pushed a pile of Luftballons changes. It's closer than ever to having a complete (though admittedly slow) graphics stack. Good things are happening. Everything is going to be ok.

Read and Post Comments

Luftballons

| categories: tech, free software, luftballons | View Comments

Remember in my last post when I talked about video games as an example of economic inefficency created by proprietary software, because they duplicate so much effort? I've actually been thinking about that idea a lot, for a long time. More specifically I've been thinking about it in terms of the technology; the graphics engines etc. Studios are constantly competing to best eachother in graphics, and they end up creating more or less the same product; most games are about on a level. The competition is clearly driving some innovation, but the fact that they can't build on eachother's work means a lot of wasted effort to maintain what tends to look like a stalemate from without. It's not a terribly gross example of IP going haywire; again, the innovation is getting driven, but open source has been very good at cutting out this kind of inefficiency, for better or worse.

I guess what I'm trying to say is I'm writing a video game engine.

Meet Luftballons.

There's more than a few open video game engines out there. It's probably fair to ask why write another one. To be fair, the eventual scope of Luftballons is to be much more than an engine; I'd like to build an entire suite of open source game development tools that will allow users to develop games from start to finish (there's some proprietary things like this already, but for paranoia's sake I'm not mentioning them). I could build that around another engine, and of the other options out there I'd say I probably looked closest at the nominally successful Ogre3d, but after reading that it did not intend to support deferred rendering pipelines, I decided to sniff around elsewhere. Eventually I conceptualized something unique enough that I felt it was worth striking out on my own.

Luftballons is basically an experiment in how much difficulty I can remove from the OpenGL API without removing any significant functionality. I chose to aggressively target modern OpenGL (somewhat tempered by Mesa only just barely implementing OpenGL 3 on most hardware), and build a framework that would cater to most of the use cases in question, but be dramatically less intricate than OpenGL. The trick is in considering what the OpenGL API can do, but abstracting away the how; removing all the tiny decisions around order of operations and allocation methods and whether to use instanced geometry, etc. The theory is that we can expose a simpler API that is feature-competitive with the raw drawing API if we don't worry about performance and just assume the most obvious way to draw is fine for everyone. The much more exciting theory is that we can then teach the implementation to be clever and do the optimization behind the scenes without hassling the user with more details. More importantly, a simple API is inherently more future-proof, as new OpenGL features just mean small API extensions or improvements to that under-the-hood optimization.

There's obviously a lot more to do, as well as some cleanup on what I already have (hand-rolling makefiles is great! I've only done it for one project and already my hatred of Automake is completely gone! (seriously, early adopters, I swear it will be in autotools within a week. Promise.)) but I have high hopes. Absorbing that inefficiency I mentioned means creating a ubiquitous open source game development platform. Whether it is this project or something else that does it, I'm hoping to one day reach a point where building a new game without using the most common open game engine is as absurd as building a new embedded platform without using the Linux kernel.

In the meantime, who wants to play with GLSL?

Read and Post Comments