{"id":23079,"date":"2014-05-29T11:15:25","date_gmt":"2014-05-29T16:15:25","guid":{"rendered":"http:\/\/www.shamusyoung.com\/twentysidedtale\/?p=23079"},"modified":"2014-05-29T13:44:01","modified_gmt":"2014-05-29T18:44:01","slug":"things-that-drive-me-nuts-about-opengl","status":"publish","type":"post","link":"https:\/\/www.shamusyoung.com\/twentysidedtale\/?p=23079","title":{"rendered":"Things that drive me nuts about OpenGL"},"content":{"rendered":"

A little while ago someone linked to this list of complaints on OpenGL<\/a> from Valve Developer Rich Geldreich. It’s pretty common knowledge that I use OpenGL in all my projects, and some people are wondering what I think of this list.<\/p>\n

Here we’re talking about the OpenGL API. API is Application Programming Interface<\/em>. If I write some code and bundle it up in a package for others to use, then the API dictates how you (another programmer) can use it. It’s the control panel for my code. The design of an API involves a lot of things. I can give you lots of power at the expense of making things really complicated. I can make things very clear at the expense of making you do a lot of typing. I can save you some typing at the expense of making everything inscrutable abbreviations. A good API is easy to read, offers you exactly the functionality you need, and once you learn half of it you can intuit how the rest works. A bad API will send you to the docs again and again so you can figure out why it’s not working even though it totally should because I copy-pasted right from the example and it’s still not working what the hell!?!?<\/em><\/p>\n

I can’t actually comment on a lot of the points Geldreich makes. The author is coming at OpenGL from a very different angle. I’ve never messed with console ports. I haven’t touched Microsoft’s toolset since the 90’s. I’m usually mucking around with procedural content, not pushing the hardware as hard as I can. (Although my current project is a tiny step in correcting this.) All of this means that I don’t have anything to compare OpenGL to, because I haven’t really used it in difficult circumstances or explored the alternatives. Furthermore, my low-tech work means I’m just less sensitive to quirks in the system.<\/p>\n

On the PC, the two big players have been Direct 3D and OpenGL, and I gather they’ve been playing tug-of-war since the 90’s. At first OpenGL was faster. Then D3D. Then OpenGL again. Now it sounds like D3D has the performance edge. Again, I’m just extrapolating. I don’t have any first-hand experience with D3D. <\/p>\n

But I suppose I can comment on a couple of these points. Here is what I think, put in plain language for non-coders. (Bolded text is from original article.)<\/p>\n

This was what the world looked like when OpenGL was designed. Image credit: <a href=\"http:\/\/vintagecomputing.com\/\">VintageComputing.com<\/a><\/a><\/td><\/tr>
This was what the world looked like when OpenGL was designed. Image credit: VintageComputing.com<\/a><\/td><\/tr><\/table><\/p>\n

1. 20 years of legacy, needs a reboot and major simplification pass<\/strong><\/p>\n

I agree. OpenGL was first introduced in 1992, which was so different from today that it might as well have been invented on another planet. <\/p>\n

One example of how OpenGL shows its age: There’s a lot of unused stuff in the API for dealing with rendering using a 16 or 256 color palette, which hasn’t been relevant since the early 90’s. <\/p>\n

The problem here is getting people to agree on which stuff needs to be thrown out. This might be one of those situations where everyone only uses 10% of the API, but each of them uses a slightly different<\/em> 10%. Still, I’m sure there are a few things nobody uses.<\/p>\n

But it’s not just about unused things. It’s also about very, very old ways of doing things. For example, at any given time there are a ton of switches you can turn on and off to control how things are drawn. Want to disable texture mapping so everything is flat color?<\/p>\n

glDisable (GL_TEXTURE_2D);<\/pre>\n
Want to enable it again?<\/p>\n
glEnable (GL_TEXTURE_2D);<\/pre>\n
Here, let me set a bunch of switches:<\/p>\n
glEnable (GL_CULL_FACE);\r\nglDisable (GL_FOG);\r\nglEnable (GL_DEPTH_TEST);\r\nglDisable (GL_LIGHTING);\r\nglEnable (GL_BLEND);\r\n<\/pre>\n
This syntax is pretty old-school. glEnable ()<\/code> just takes any old value you like, so it’s possible to confuse things. I might accidentally do glEnable (GL_DEPTH_FUNC)<\/code> instead of glEnable (GL_DEPTH_TEST)<\/code>. The first actually doesn’t make any sense and will probably do something random. (Like flip some other, unrelated switch that I may or may not even care about.) A more modern design would make it so that using a wrong value like this will immediately be flagged as an error, letting me know the thing I’m trying to enable isn’t an on\/off switch and shouldn’t be used this way. <\/p>\n
More confusing is stuff like this:<\/p>\n
glDepthWrite (bool enable);<\/pre>\n
Er. So we’ve got all these switches we can turn on and off with  glEnable ()<\/code> and  glDisable ()<\/code>, but then here we have a special switch with its own name. Why doesn’t it work like all the others? Why does it get its own special function like this? There’s even a value in the headers that makes it look like glEnable (GL_DEPTH_WRITEMASK)<\/code> should work, but no. (If you arrived via Google and are wondering why this doesn’t work: GL_DEPTH_WRITEMASK is just for use with glGet () so you can see if it’s on or off. You still have to use glDepthWrite ()<\/code>.)<\/p>\n
There are dozens of oddball conventions like this. All of them can trip you up and lead you to wrong conclusions. <\/p>\n
2. GL context creation hell:<\/strong><\/p>\n
YES. Gah. So annoying.<\/p>\n
Okay, so in order to start drawing stuff we first need a window. How it works on Windows is that we create a Windows-windowDamn you Microsoft, this sentence  is all your fault. You shouldn’t name your operating system WINDOWS for the same reason you don’t create a model of car called AUTOMOBILE or ENGINE.<\/span> and then we plug that window into OpenGL so it knows where it is supposed to be doing its drawing. This ends up being pages and pages of boilerplate code<\/a>. <\/p>\n
And then when you port to Linux you need to re-write all of it.<\/p>\n
And then again for Mac, Xbox, Playstation, UNIVAC, or wherever else you’re trying to port to. Since OpenGL has to have a bunch of talking-to-windows code that’s unique to each platform, couldn’t it just do me a favor and also create the damn thing while it’s at it? <\/p>\n
So what happens is we all turn to some third-party solution (yet another API) to abstract away all of this stuff. <\/p>\n
5. glGetError()<\/strong><\/p>\n
OpenGL lets you call this as a way of asking if anything is wrong. “Hey, is anything screwed up?” The problem is that it’s not terribly useful. The errors it returns are obtuse to the point of comedy. They boil down to “You did something you shouldn’t have at some point.” So if you’re looking for where you went wrong, you can either check glGetError()<\/code> every single time you do ANYTHING (which would be insane) or just check it once per frame and if it has a problem you go hunting for it manually. <\/p>\n
9. GLSL version of the week hell:<\/strong><\/p>\n
I wrote about this a couple of weeks ago<\/a>.<\/p>\n
I’ll add my biggest gripe, which arguably might be part of #10 on Geldreich’s list:<\/p>\n
No basic types for dealing with polygon data. <\/strong><\/p>\n
When you’re throwing polygons around, you need vectors of xyz values. You need tables of numbers (called a matrix) for manipulating those values. You need red-green-blue color values. OpenGL, being old as hell, doesn’t offer this stuff. Which means EVERYONE writes their own. This becomes fun when systems collide. I write my own vectors from scratch. Maybe I call my vector a Shamus3D.  Then I use some code written by someone else for importing 3D models. That guy needed vectors in his project, so he wrote them and named them Bob3D. Oh! And this physics library has vectors called PhysicsThreeDeeVectorFloats<\/code>You can always tell which programmers have massive jumbotron monitors. They’re the people who seem to think screen space is limitless and variable names are a great place to tell your life story.<\/span>. And here’s another vector with this positional audio package. <\/p>\n
And now I’ve got four or five different types of vectors that supposedly do the same thing but which aren’t compatible. <\/p>\n
In newer versions of OpenGL, the matrix stack is deprecated. Meaning, you’re not supposed to use the matrix system that’s built into OpenGL. But since OpenGL doesn’t come with matrix variables it means everyone will need to write their own matrix code. There’s no way that doesn’t end in tears. <\/p>\n
I think the bare minimum you need for doing ANY kind of graphics programming is: Vectors, matrices, and RGB color values. Vectors should do basic arithmetic with each other and matrices. <\/p>\n
And that’s just to save us from living like savages. To have a really robust toolset we should also be able to do dot product, cross product, reflection, and normalization on the vectors. And we should also have quaternions<\/a>. <\/p>\n
The danger here is that this is the stuff of holy wars. What do we call the vectors? <\/p>\n
OGLvector? <\/p>\n
It doesn’t say how many dimensions it has, which can lead to confusion if we add a 2D vector later.<\/strong><\/p>\n
OGLvector3D?<\/p>\n
Ugh. Long and mixed case, with capital letters on the front AND back. <\/em><\/p>\n
OGLv3d? <\/p>\n
Yeah, no. Looks like it says “Ogleved”. Maybe the types should have a lowercase prefix like the rest of the library.<\/strong><\/p>\n
glvector3d?<\/p>\n
Actually, the rest of the library uses  lowercase “gl” followed by a capitalized word.<\/em><\/p>\n
glVector3d?<\/p>\n
Is the d really necessary?<\/strong><\/p>\n
glVector3?<\/p>\n
Now it looks like Hungarian notation<\/a>. People will think “gl” is the type.<\/em><\/p>\n
That’s not how you’re supposed to use Hungarian!<\/strong><\/p>\n
That doesn’t change the fact that it’s confusing!<\/em><\/p>\n
It’s not the job of the API to protect us from bad coders!<\/strong><\/p>\n
YOU’RE a bad coder.<\/em><\/p>\n
Your MOM is a bad coder!<\/strong><\/p>\n
Anyway. Even if we can get these idiots to agreeAnd good luck with that. There aren’t two agendas in this argument, there are dozens.<\/span> how to name stuff, we’re still faced with the problem of where to draw the line. How much stuff do we add? Vectors are nice, but we could do more. This isn’t just a slippery slope, this is a mountain of grease. What I outlined above is nice, but you could make a strong case for adding a lot more:<\/p>\n
2D vectors would be handy for dealing with texture coords or 2D rendering. We’ll also need them to do arithmetic with each other. And they should probably interact with matrices and 3D vectors in a sensible way. Maybe we should have some kind of abstract “model” class that ties a bunch of vectors, vexture coords, and color values together into something we can render. <\/p>\n
And nearly everyone needs tools for reading image files and turning them into textures, so we should probably add that too. And if we’re doing that, then we might as well add the ability to convert between various internal image formats. And if we’re importing images then on top of RGB color values, we ought to have a HSVHue, saturation, value. In this system we define a color by what hue it is, how saturated the color is, and how bright it is.<\/span> value and the ability to freely convert between the two. <\/p>\n
Model manipulation! Animation formats! Variables for holding triangle indices! Bounding boxes! Common GLSL tools like Lerp ()<\/code> and Smoothstep ()<\/code>! A flashlight and a can opener! <\/p>\n
OpenGL has been about the low-level interactions with graphics hardware for as long as there’s been graphics hardware. But if you go too far then you end up making a massive “game engine” instead of a simple “graphics API”. And I think the minimalist design is one of OpenGL’s strong points. <\/p>\n
Still, I think the basics of vectors, matrices, and RGB color values are warranted. <\/p>\n
Wrapping up:<\/strong><\/p>\n
OpenGL is old. It’s odd. But it’s basically the only way to get polygons on the screen if you’re not looking to to create an arranged marriage between your project and Microsoft. We need it, but it would be great to have this functionality with a modern interface. <\/p>\n","protected":false},"excerpt":{"rendered":"
A little while ago someone linked to this list of complaints on OpenGL from Valve Developer Rich Geldreich. It’s pretty common knowledge that I use OpenGL in all my projects, and some people are wondering what I think of this list. Here we’re talking about the OpenGL API. API is Application Programming Interface. If I […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[66],"tags":[388],"class_list":["post-23079","post","type-post","status-publish","format-standard","hentry","category-programming","tag-opengl"],"_links":{"self":[{"href":"https:\/\/www.shamusyoung.com\/twentysidedtale\/index.php?rest_route=\/wp\/v2\/posts\/23079","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.shamusyoung.com\/twentysidedtale\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.shamusyoung.com\/twentysidedtale\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.shamusyoung.com\/twentysidedtale\/index.php?rest_route=\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.shamusyoung.com\/twentysidedtale\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=23079"}],"version-history":[{"count":0,"href":"https:\/\/www.shamusyoung.com\/twentysidedtale\/index.php?rest_route=\/wp\/v2\/posts\/23079\/revisions"}],"wp:attachment":[{"href":"https:\/\/www.shamusyoung.com\/twentysidedtale\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=23079"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.shamusyoung.com\/twentysidedtale\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=23079"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.shamusyoung.com\/twentysidedtale\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=23079"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}