Today was a bit of a topsy-turvy day.
For the last week, I’ve been working to update VectorStorm to render using OpenGL 3.2, where previously it used 2.1. The rendering tech build that I had been planning to put up tomorrow was intended to prove out OpenGL 3.2 rendering; make sure that it worked acceptably for lots of people on lots of different equipment.
Let’s talk a little about why I was doing that update.
In broad terms, OpenGL 1.x used what was called “fixed-function rendering”. Which is to say, the way that rendering worked was fixed; you couldn’t really affect it. You could tell the system where your geometry was and which direction its normals faced, but you couldn’t tell it how to apply lighting to a surface, how to blend between textures (beyond the preset options you’re offered), etc. Let’s say that OpenGL 1.x is broadly equivalent to Direct3D 6 or 7. The very first revision of the VectorStorm engine used this.
OpenGL 2.x added support for a programmable shader pipeline, in addition to the fixed-function pipeline from version 1.x. This basically means that instead of only being able to perform the rendering instructions which the manufacturer provided, you can instead program the GPU yourself, to do whatever you want with your vertex data, texture coordinates, etc. OpenGL 2.x is broadly equivalent to Direct3D 9. VectorStorm eventually added optional support for rendering based on OpenGL 2.1, which was initially just used for a bloom shader.
By OpenGL 3.x, the OpenGL committee was getting worried about all the baggage being left behind by needing to be backwards-compatible with OpenGL 1 and 2, and so brought in the idea of a “core context”. The core context, in theory, meant that you could draw using only the functionality desired by OpenGL 3.x, and nothing earlier; the fixed-function pipeline is entirely gone. What’s more, the vestiges of it seen in OpenGL 2 (built-in default shader variables, etc) were also gone. OpenGL 3.x is in many ways a lot simpler, as there are fewer ways to do things. And it’s a whole lot cleaner. And what’s more, a whole lot of useful features which were available only as extensions under 2.x where part of the core context in 3.x, and are guaranteed to be present and available. If you can use OpenGL 3.x, it’s very attractive to do so, since your code can be a lot simpler due to not having to always check whether or not a particular function is available on the current computer. OpenGL 3.x is broadly equivalent to Direct3D 10. The stats gathered by Steam and Unity both suggest that currently, about 95% of their gamers are capable of playing Direct3D 10 games (and thus, presumably, OpenGL 3.x games). So OpenGL 3.x is a pretty compelling argument.
Today, as I was setting up to build the Windows version of the rendering technology build, I ran into a problem which sort of threw me for a loop.
See, I have just one main development machine; a Macbook Pro. I also have a desktop Linux box, which I can dual-boot into Windows 7, but that Windows system is set up for playing games, not for development. When I’m making Windows builds, I always make them on the Macbook Pro, inside a Windows VM. Here’s the problem: No VM currently supports OpenGL 3. Not even a little. I can build a program which uses OpenGL 3, but I can’t test that it runs successfully, and I can’t debug any problems which might come up if any problems are reported.
So I’ve been wrestling all day over what to do; do I set up my current Windows game-box as a dev machine, and swap between machines as I work on different platforms? Do I partition my laptop’s internal drive (so little free space…) so that I can dual-boot the laptop into Windows? Do I buy an external drive and wrestle the laptop into dual-booting off the external drive? Do I buy a new Windows box? Whatever I do, actually wrangling cross-platform builds based on OpenGL 3 is going to be more difficult, more time-consuming, and likely more expensive than ones based on OpenGL 2.1.
And since I don’t have any compelling reason why I need to use OpenGL 3 instead of 2.1, apart from it being a bit nicer to work in, I’m calling the time I spent working with OpenGL 3 work a ‘sunk cost’, and am dropping back to the OpenGL 2.1-based renderer.
Which is not to say that there won’t be a ‘new rendering tech’ build tomorrow. There absolutely will — the current OpenGL 2.1 renderer is itself brand new — I haven’t released a game using it, yet. And some of the tech I wrote for OpenGL 3 I’ve back-ported to 2.1; the line triangulation code, for example, has been ported back, as has the (I expect) cheaper bloom shader. So I’m still planning to release a rendering tech build tomorrow, and I’m still interested to get everyone’s feedback on how well it works for them.
It’s just not quite as “cutting-edge” as it might have been otherwise.
