I've just done multisampling in DirectQ 2.0.0, and after some brief hiccups, it works. However the debug layer (D3D has a proper debug layer - isn't that awesome?) warns me that I'm trying to read from a multisampled texture via a standard Texture2D object in my render-to-texture shaders. That sucks - D3D9 was able to handle this automatically.
Some further investigation reveals that I need to use a Texture2DMS object instead (the "MS" stands for "multisampled", I guess), which needs the number of samples explicitly specified. Hold on a moment? Does that mean that I need to create a new version of each such shader for each multisample level?
OpenGL Uniform Buffer Objects were added to my Quake II engine. The intention was to do much the same as for DirectQ constant buffers - upload a chunk of common values (the current MVP matrix, the current Ortho matrix for 2D stuff, player positioning info, etc) at the start of each frame and have them available to all shaders.
They run slower than plain uniforms; the OpenGL buffer object specification strikes again. No amount of glBufferData (...NULL...) or GL_MAP_UNSYNCHRONIZED_BIT can prevent them from stalling the pipeline. This is a pure API/Driver problem - it doesn't happen with constant buffers in D3D11 because D3D11_MAP_WRITE_DISCARD works as advertised; the hardware is clearly capable. Rip them out and go back to standard uniforms.
I can do "layout(location = 0) in vec4 position;" but I can't do "layout(location = 0) uniform mat4 localmatrix;"? Does the same person on the ARB who loves bind-to-modify also love glGetUniformLocation? Or are there two of them? (Yes, this was fixed in GL 4.2. Why was it not in GL 2.0? Sigh.)