26 comments

[ 3.1 ms ] story [ 68.9 ms ] thread
Sounds great! Dare I try it on windows now? (The last n times I did ... things did not work out).

Kudos for taking also the texture colorspace issue into account - I've found people new to real time programming tend to find this initiaĺly one of the most bysantine minutiae one absolutely needs to get right

First time I've heard about it in any writings. Put onto my list how to implement it. Any good articles on the RGB vs sRGB colorspace issue in OpenGL ?
Briefly and massively simplifying: Unless otherwise specified, sRGB is the default storage and display colorspace for most digital applications dealing with RGB image data (excluding video)

https://en.wikipedia.org/wiki/SRGB

However, one cannot do computations on an image in sRGB colorspace since the colorspace is not linear - the values will turn out wrong. I.e. imaging algorithms expect source data to be in linear colorspace, and if fed sRGB data the result will turn out more or less wrong.

Thus, when doing any weighting calculations etc. on a set of samples the samples must be in linear (e.g. RGB) colorspace.

Your OpenGL implementation may or may not handle this automatically for you if you specify the image to be in one of the sRGB texture formats. https://www.opengl.org/registry/specs/EXT/texture_sRGB.txt

So, in the general sense, if doing any handcoded imaging routines, and reading e.g. PNG image, one needs to convert it to linear colorspace before processing, and back to sRGB before writing to disk/displaying.

Linear vs gamma space is not an OpenGL specific problem. Also the decode/encode doesn't require 3D API support, it can also be done in the pixel-shader (decode from gamma to linear when sampling color textures, and encode back into gamma during a post-effect pass that most engines have anyway).

'The importance of being linear' is the best introduction to the topic I know: http://http.developer.nvidia.com/GPUGems3/gpugems3_ch24.html

This seems fantastic compared to my experiments in C + glut. Great work!

The API has macros to automatically generate type boilerplate. Very clever

Excellent writing on the pitfalls of OpenGL and how to circumvent those. Applies to any OpenGL programming, not just Rust also.

Here's hoping Vulkan will fix these issues in the future and Apple also adapting this platform.

It seems unlikely Apple would adopt Vulkan at this point. Maybe if Vulkan came out a year ago. The only thing that might convince them is if big developers such as Blizzard and whoever else decides to write PC/Android games in Vulkan. EA's Dice was already pushing for Mantle, which is now part of Vulkan, so maybe most of EA's games could be written in Vulkan in the future. That might get Apple to adopt it, even if 80% of iOS games will use Metal instead of OpenGL ES by that point.
Unity and Unreal already support Metal and I imagine other engines are in the process of doing the same.

With all major engines on Metal, Apple has nothing to lose by not supporting Vulkan, other than a few indie devs that stay away from engines.

This is a fantastic example of how to make a foreign API safe and neat in a Rust-y kind of way. The author has done a great job with hlua too (see previous blog post).
> The “untextured objects” example of AZDO: drawing 64x64x64 individual moving objects. The glium version runs at approximately the same speed as the original pure OpenGL example.

Seems like Rust is making good progress (emphasis mine). I really should take the time to learn this language.

The fact that it runs at approximately the same speed isn't really important. You would get the same result with any language.

The AZDO examples show what the most optimized OpenGL techniques are, and I just wanted to show that you can do the same thing with glium as with raw OpenGL.

That being said, you should still try Rust!

So, Rust is ready for writing high performant games?
I don't know if it is, but it doesn't, it doesn't prevent people from trying. There is a community of rust game developer and a framework dedicated to game developpement : piston (http://www.piston.rs/).

Also a link related to game developement in rust : https://www.reddit.com/r/rust_gamedev

Semi-unrelated: The set of themed names around Rust will make it fun when and if a Rust game become available on Steam — “Today <game name>, a <game type> written in Rust with the Piston framework became available on Valve’s Steam game marketplace." It’s a steampunk fan’s dream.
And just imagine if they rewrote Rust in Rust! :P
Why not :)? Seems like a great fit to me, we'll see in the long run though.
Why not? I hope it will really shine in combination with Vulkan though, not with OpenGL.
Another cool thing he mentions is that it does something sort of like React's diffing.

When you tell Glium, "make me these three polygons, add a light source, apply a transform matrix", it optimizes the number of OpenGL calls it needs to do, and the kinds thereof, and puts them in the right order to run most efficiently.

Like React, it optimizes state changes required for speed to get a view from one state to another.

The fact that Glium needs to do this demonstrates how flawed the state-wrangling in OpenGL has become. Vulkan can't come fast enough.
A couple years ago I was trying to teach myself OpenGL, and I failed miserably for that exact reason, plus bad function naming conventions.

The weirdest thing about OpenGL is that you sometimes have to run one function before another function, for no good reason, but it gives you a giant performance boost.