{"id":3194,"date":"2014-05-20T19:35:19","date_gmt":"2014-05-20T09:35:19","guid":{"rendered":"http:\/\/www.vectorstorm.org\/?p=3194"},"modified":"2014-05-20T19:35:19","modified_gmt":"2014-05-20T09:35:19","slug":"opengl-2-1-3-2","status":"publish","type":"post","link":"https:\/\/www.vectorstorm.com.au\/2014\/05\/20\/opengl-2-1-3-2\/","title":{"rendered":"OpenGL 2.1 and 3.2"},"content":{"rendered":"
Today was a bit of a topsy-turvy day.<\/p>\n
For the last week, I’ve been working to update VectorStorm to render using OpenGL 3.2, where previously it used 2.1.\u00a0 The rendering tech build that I had been planning to put up tomorrow was intended to prove out OpenGL 3.2 rendering;\u00a0 make sure that it worked acceptably for lots of people on lots of different equipment.<\/p>\n
Let’s talk a little about why I was doing that update.<\/p>\n
In broad terms, OpenGL 1.x used what was called “fixed-function rendering”.\u00a0 Which is to say, the way that rendering worked was fixed<\/em>;\u00a0 you couldn’t really affect it.\u00a0 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.\u00a0 Let’s say that OpenGL 1.x is broadly equivalent to Direct3D 6 or 7.\u00a0 The very first revision of the VectorStorm engine used this.<\/p>\n OpenGL 2.x added support for a programmable shader pipeline, in addition to the fixed-function pipeline from version 1.x.\u00a0 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.\u00a0 OpenGL 2.x is broadly equivalent to Direct3D 9.\u00a0 VectorStorm eventually added optional support for rendering based on OpenGL 2.1, which was initially just used for a bloom shader.<\/p>\n 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”.\u00a0 The core context, in theory, meant that you could draw using only the functionality desired by OpenGL 3.x, and nothing earlier;\u00a0 the fixed-function pipeline is entirely gone.\u00a0 What’s more, the vestiges of it seen in OpenGL 2 (built-in default shader variables, etc) were also gone.\u00a0 OpenGL 3.x is in many ways a lot simpler, as there are fewer ways to do things.\u00a0 And it’s a whole lot cleaner.\u00a0 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.\u00a0 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.\u00a0 OpenGL 3.x is broadly equivalent to Direct3D 10.\u00a0 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).\u00a0 So OpenGL 3.x is a pretty compelling argument.<\/p>\n 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.<\/p>\n See, I have just one main development machine;\u00a0 a Macbook Pro.\u00a0 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.\u00a0 When I’m making Windows builds, I always make them on the Macbook Pro, inside a Windows VM.\u00a0 Here’s the problem:\u00a0 No VM currently supports OpenGL 3.\u00a0 Not even a little.\u00a0 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.<\/p>\n So I’ve been wrestling all day over what to do;\u00a0 do I set up my current Windows game-box as a dev machine, and swap between machines as I work on different platforms?\u00a0 Do I partition my laptop’s internal drive (so little free space…) so that I can dual-boot the laptop into Windows?\u00a0 Do I buy an external drive and wrestle the laptop into dual-booting off the external drive?\u00a0 Do I buy a new Windows box?\u00a0 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.<\/p>\n 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.<\/p>\n Which is not to say that there won’t be a ‘new rendering tech’ build tomorrow.\u00a0 There absolutely will — the current OpenGL 2.1 renderer is itself brand new — I haven’t released a game using it, yet.\u00a0 And some of the tech I wrote for OpenGL 3 I’ve back-ported to 2.1;\u00a0 the line triangulation code, for example, has been ported back, as has the (I expect) cheaper bloom shader.\u00a0 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.<\/p>\n It’s just not quite as “cutting-edge” as it might have been otherwise.<\/p>\n","protected":false},"excerpt":{"rendered":" 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.\u00a0 The rendering tech build that I had been planning to put up tomorrow was intended to prove out OpenGL 3.2 rendering;\u00a0 make sure that it worked acceptably…<\/p>\n","protected":false},"author":1,"featured_media":3195,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"spay_email":""},"categories":[4,3],"tags":[],"jetpack_featured_media_url":"https:\/\/www.vectorstorm.com.au\/wp-content\/uploads\/2014\/05\/opengl-logo.gif","jetpack_sharing_enabled":true,"jetpack_shortlink":"https:\/\/wp.me\/po9WK-Pw","_links":{"self":[{"href":"https:\/\/www.vectorstorm.com.au\/wp-json\/wp\/v2\/posts\/3194"}],"collection":[{"href":"https:\/\/www.vectorstorm.com.au\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.vectorstorm.com.au\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.vectorstorm.com.au\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.vectorstorm.com.au\/wp-json\/wp\/v2\/comments?post=3194"}],"version-history":[{"count":1,"href":"https:\/\/www.vectorstorm.com.au\/wp-json\/wp\/v2\/posts\/3194\/revisions"}],"predecessor-version":[{"id":3196,"href":"https:\/\/www.vectorstorm.com.au\/wp-json\/wp\/v2\/posts\/3194\/revisions\/3196"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.vectorstorm.com.au\/wp-json\/wp\/v2\/media\/3195"}],"wp:attachment":[{"href":"https:\/\/www.vectorstorm.com.au\/wp-json\/wp\/v2\/media?parent=3194"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.vectorstorm.com.au\/wp-json\/wp\/v2\/categories?post=3194"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.vectorstorm.com.au\/wp-json\/wp\/v2\/tags?post=3194"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}