OpenGL vertex buffer functionality, I mock thee too! Why couldn’t they make the specification simple&clear, and then why can’t the implementations work as expected?

It started out like this: converting some existing code that generates geometry on the fly. It used to generate that into in-memory arrays and then Just Draw Them. Probably not the most optimal solution, but that’s fine. Of course we can optimize that, right?

So with all my knowledge how things used to work in D3D I start “I’ll just do the same in OpenGL” adventure. Create a single big dynamic vertex buffer, a single big dynamic element buffer; update small portions of it with glBufferSubData, “discard” it (=glBufferData with null pointer) when the end is reached, rinse & repeat.

Now, let’s for a moment ignore the fact that updating portions of index buffer does not actually work on Mac OS X… Everything else is fine and it actually works! Except for… it’s quite a lot slower than just doing the old “render from memory” thing. Ok, must be some OS X specific thing… Nope, on a Windows box with GeForce 6800GT it is still slower.

Now, there are three things that could have gone wrong: 1) I did something stupid (quite likely), 2) VBOs for dynamically updated chunks of geometry suck (could be… they don’t have a way to update just one chunk without one extra memory copy at least), 3) both me and VBOs are stupid. If I was me I’d bet on the third option.

What I don’t get is: D3D has had a buffer model that is simple to understand and actually works for, like, 6 years now! Why ARB_vertex_buffer_object guys couldn’t just copy that? The world would be a better place! No, instead they make a way to map only whole buffer; updating chunks is extra memory copy; there are confusing usage parameters (when should I use STREAM and when DYNAMIC?); performance costs are unclear (when is glBufferSubData faster than glMapBuffer?) etc. And in the end when an OpenGL noob like me tries to actually make them work - he can’t! It’s slow!

Awards: Hey, we‘ve got a “runner up” award in Apple Design Awards 2006, Best Use of Graphics category! Yeah, a runner up is more like “the first of the losers”, but oh well. Got beaten by modo 201, which probably is a fair trade. It’s just that we thought we’d be in Best Developer Tool category, but that is apparently for text editors and scripting languages :)

Demos: In the other news, fellow ReJ with TBL just won Assembly 2006 demo competition with an Amiga demo, putting all PC demos faces’ to dust. Check it out. Art direction over hardware capabilities, one more time.

Drivers: why oh why the graphics drivers must be so bad? The other day I was thinking why can’t they auto-update themselves (with an option to turn it off for corporate users etc.). Now you’ve got a (not so recent!) driver that is able to parse vertex programs wrong, and a user who does not have a clue that he should update it. It’s bad enough to have a bug in the first place, but auto-update at least would fix…

Or you have a driver that says “I’m OpenGL 1.2!” but the 3D texture functions are null. And it’s the most recent driver for a particular graphics card that you can buy today! And it’s not even a hard problem! What the developers are thinking - they go over the required GL 1.2 functionality, see that some is actually missing and decide “ah, screw it, we’ll say it’s 1.2 anyways”?!

I just don’t get it. I could use some enlightenment on this.

Getting multithreaded code right is just so damn hard. Reasoning about it’s behavior or correctness is even harder! We’ll be doomed until we get something of much higher level than threads and locks.

Why I’m writing this? Because my head hurts from trying to make the renderer run in one thread, and the containing application in the other. With added spice that most (win32) GUI stuff must happen in one thread, OpenGL contexts can only be active in a single thread, simple functions must be split into complex chains of inter-threading calls, etc. etc. The result is a mess that nobody can understand.

I hope I’m not missing something obvious (well, aside from the suggestion “just don’t use threads”).

The company I was working at for some three years, closed it’s offices in Kaunas recently. Well, it was almost a year when both intera and motion parts of the name didn’t already make any sense… At start we were doing computer vision, various game/graphics/entertainment stuff, but in the last year all development was about some computer networks management system. A couple of programmers will stay for some time to support existing systems, but afaik any new development is suspended.

I feel kinda sad, even if I blame the management for the failures mostly (we programmers never blame ourselves, you know :)). Yes, I/we could have worked harder, done better etc., but all the way I (and probably ‘we’) felt that the ambitions were too unrealistic^*, the business plans were too non-existant, the management was just a bit too poor, and some forward-thinking was ‘just a bit missing’.

I guess that’s just my attempt to transfer blame to someone else :)

That said, it’s still sad. Oh well, just keep going on.

* Ambitions: “by that time Sony, Nintendo and Konami will be years behind us” doesn’t sound very realistic, does it? :)

They suck! Well, this probably isn’t fresh news to anyone, but right now I’m working with code where basically everything includes everything else. The code is template-heavy so that makes things even worse. Try changing that file without 20 minute rebuild later - good luck!

Yeah, I know, the code is a product of 2 years of wandering in the darkness :) - prototyping, adding something and removing something, and when you constantly have to actually produce “working demos” in short timeframes, it ain’t easy to actually sit down and refactor whole thing. Oh well, the reality…

Still, code with lots of dependencies does suck of course.

On the other hand, I’m pretty happy with the module I’m writing. All the outside just needs one header file that’s right now 76 lines long and that includes only very basic “resource id” header file. The insides of my module also need some of the outside functionality; I’ve written some “outside interface” for that - a header file with something like 50 lines and also absolutely no includes.

That’s what I consider to be a low-dependency interface. That’s good. That doesn’t suck :)

[EDIT] The code I was referring to isn’t so bad (e.g. it really doesn’t “includes everything else”, but “includes quite large amount of stuff”). I’m just somewhat frustrated at the moment, and anything that’s not very ideal in the codebase irritates me.