Ok, it looks like OpenGL 3.0 specification will be delayed a bit. Oh well, spec now, first drivers a bit later, sort-of-stable drivers a year or two later, and Joe-the-average-user will hopefully have some OpenGL 3.0 support in his Windows box after 5 years. Still, progress has to be made.

The idea of abandoning the old concept of “bind the current object and do stuff on it” and replacing it with direct functions that take object as parameter is very good. Too much state-machine-like functionality in current OpenGL is just a pain for no good reason. Also a very good idea is to make most objects immutable once they are created. Too much flexibility for no good reason just makes the lives of driver developers harder (and gives them much more opportunities to make bugs). All in all, OpenGL’s API is becoming more like Direct3D, which is good in my eyes.

What OpenGL needs, besides all the work that goes into OpenGL 3.0? Certainly not lengthy discussions on whether alpha test should be kept or removed (it does not matter! just pick one) or whether shader assembly is actually assembly (it’s not. but current implementations of GLSL are too unusable, so…).

What OpenGL needs is implementation quality.

Of all crashes in Unity 1.x web games, close to 100% are inside the dll of OpenGL driver, occurring in totally unpredictable situations. I’ve yet to see a crash in D3D driver of Unity 2.0 web games. Why is this?

My thinking is because in D3D, quite a chunk of work is done by Microsoft (the D3D runtime). And as it’s a component of the OS, they probably try hard to make it stable, and they have WHQL tests at least. It’s a somewhat similar situation on the Mac with OpenGL - Apple does the runtime, and IHVs do the drivers. Thus OpenGL in the Mac is much more stable than on Windows (it’s not as stable as I’d like it to be, but hey).

Get someone out of whole Khronos conglomerate to write GLSL parsers, format conversions, whatever else that is not directly tied to the hardware. Make it open source if you wish, so that some bugs can be found by mere mortals (instead of waiting indefinitely for IHVs to reply because we’re not important enough). Write very extensive testing suites that not just test rasterization rules, but also try to do something more complex than drawing a couple of primitives. The more tests the better. And make it required for all implementations to use this common codebase and pass all the tests, otherwise they won’t have the right to call themselves “OpenGL”.

Oh, and get more games to actually use OpenGL, because right now all drivers have to do is make sure the current id Software engine runs okay :)

Flashbang Studios just launched Splume, probably the first game out there* made with Unity 2.0. It just won our “Top DOG” competition by the way.

It’s a cute little gem, or alternatively, “Puzzle Bobble meets Ageia’s PhysX engine”. Lots of levels, user level editor, some AJAX magic and so on, and everything made in about four weeks. Matthew has some technical details for the curious.

Here are some shots and a youtube trailer for the lazy ones. The youtube trailer uses music from 8bitpeoples which can’t be bad :)

But really, you should just go and play it: splume.flashbangstudios.com

* I stand corrected: When Orcs Attack also was made with Unity 2.0, and it was released earlier!

Finally, Unity 2.0 is out. Took a bit longer than we expected (but not 3.1415926 times longer, so we’re all good), but now, after half a year in beta testing, over a dozen alpha/beta releases, it is finally shipped. Feels good!

It’s been in active development for about a year (though some of 2.0 features were in development for much longer), with source control commits graph looking roughly like this. We pretty much spent the summer doing 800 svn commits/month with about four major code monkeys :) Now that the release is done I fully expect the graph to drop off to low values again (is it called “burnout”?).

Last week there was the first Unity conference, and it was a blast. It was like, oh my, it’s full of people and all about unity! In other words, really really cool.

The night before the conference was spent in the hotel, doing last tweaks to the website and launch demos. If the presenters during keynote talk looked confused or exhausted, that’s a combination of trans-Atlantic flight and this last night of work. In fact, the very last fixes to the website were done during the keynote… oh well, Murphy’s law for the win.

Now what? Time to start working on Unity 2.x release :)

San Francisco, here we come.

The common knowledge is that drawing stuff in OpenGL is much more faster than in D3D9. I wonder - is this actually true, or just an urban legend? I could very well imagine that setting everything up to draw a single model and then issuing 1000 draw calls for it is faster in OpenGL… but come on, that’s not a very life-like scenario!

At work we now have a D3D9 and an OpenGL renderers on Windows. The original codebase was very much designed for OpenGL, so I had to jump through a lot of hoops to get it fully working on D3D… small differences that add up, like: there’s no object space texgen on D3D, shaders don’t track built-in state (world, modelview matrices, light positions, …), textures in GL vs. textures + sampler state in D3D, and so on. Anyway, the codebase was definitely not designed to exploit D3D strengths and OpenGL weaknesses, more likely the other way around.

But wait! I look at our benchmark tests, and D3D9 is consistently faster than OpenGL. Some examples:

• Real world scene with lots of shadow casting lights (different objects, different shaders, different lights, different shadow types in one scene):

  • Core Duo with Radeon X1600: 23 FPS D3D9, 13 FPS GL.

  • P4 with GeForce 6800GT: 16 FPS D3D9, 9 FPS GL.

  • Core2 Duo with Radeon HD 2600: 41 FPS D3D9, 35 FPS GL.

• High object count test (1000 objects, multiple lights, 5 passes per object total):

  • Core Duo with Radeon X1600: 18.3 FPS D3D9, 12.5 FPS GL.

  • P4 with GeForce 6800GT: 13.2 FPS D3D9, 9.4 FPS GL.

  • Core2 Duo with Radeon HD 2600: 34.8 FPS D3D9, 29.3 FPS GL.

• Dynamic geometry (lots of particle systems) test (this is limited by vertex buffer writing speed and CPU calculating the particles, not draw by calls):

  • Core Duo with Radeon X1600: 170 FPS D3D9, 102 FPS GL.

  • P4 with GeForce 6800GT: 108 FPS D3D9, 74 FPS GL.

  • Core2 Duo with Radeon HD 2600: 325 FPS D3D9, 242 FPS GL.

• …and so on.

To be fair, there are a couple of tests where on some hardware OpenGL has a slight edge. But in 95% of the cases, D3D9 is faster. Not to mention that we have about 10x less broken hardware/driver workarounds for D3D9 than we have for OpenGL…

What gives? Either our OpenGL code is horribly suboptimal, or “OpenGL is faster!!!!11oneoneeleven” is a myth. I have trouble figuring out in which places our code would be horribly suboptimal, I think we follow all advice given by hardware vendors on how to make OpenGL efficient (not that there is much advice out there though…).

There isn’t much software that can run the same content on both D3D and OpenGL and is suitable for benchmarking. I tried Ogre 3D demos on one machine (GeForce 6800GT card) and guess what? D3D9 is faster in tests that specifically stress draw count (like the instancing demo… D3D9 is faster both in instanced and non-instanced modes).

Am I crazy?