Koehler

Just set a stencil bit when you draw your skybox, and stencil test for that bit being unset when applying bloom. If you've got the same depth/stencil buffer attached, you'll apply bloom to everything else, while leaving your skybox untouched.

That's probably what your issue is. Just call glCreateVertexArray to create a VAO, and then glBindVertexArray to bind it before you do your glBindBuffer, glEnableVertexAttribArray and glVertexPointer calls (Do this once). From that point on, all you have to do is bind the vertex array in your render loop and the rest is of the state (which was saved by making those calls with a VAO bound) is set up automatically.

So my draw method should look like this, given that m_Program is a compiled, linked, shader program..?
(snip)

That looks correct! Just remember that if you're drawing later on with glPolygonMode(GL_FRONT,GL_FILL), you might as well re-enable GL_CULL_FACE. It should not affect your visual results and should improve performance. When you're ready to add uniforms, you'll pass them in your GLModel::RenderElements() function.

In C++, the choice between matrix[16] and matrix[4][4] comes down to which you like better. matrix[1][1] in the second is the same offset as matrix[4] in the first. The important thing to remember for openGL is that it is column-major in its memory layout (so array element 0 (or [0][0]) is row 0, column 0, but element 1 (or [0][1]) is row 1, column 0.  Fortunately, if you want to access your 2D array as matrix[row][column], you can tell OpenGL to transpose it when you pass it in as a uniform (third argument to any of the glUniformMatrix_fv functions).

That said, it's probably easiest to work with a Matrix class so that you can do things like this:

mat4x4 viewProjectionMatrix = projectionMatrix*viewMatrix;

.
note that in shader code vectors and matrices are pre-defined types, so code like the above would work.

You may notice that I've referred to "ViewProjection" matrix above, whereas OpenGL has stacks for the "ModelView", and "Projection" matrices. As you move away from using the matrix stack, the easiest way to think of this is as three separate matrices, Model ,View, and Projection. Under the hood, it's effectively doing this:

	 vec4 finalVertexPos = Projection*View*Model*vertexPos;

For convenience's sake, since the camera doesn't change over the course of a single frame, I like to combine the view and projection matrices together just once, and use the result like this:

     vec4 finalVertexPos = viewProjection*Model*vertexPosition; 

I'm a bit short on time to explain how to generate view and projection matrices. For a temporary solution you can use glGetFloatv with GL_MODELVIEW_MATRIX or GL_PERSPECTIVE_MATRIX to extract the ones you're already making with the matrix stack (exclude your last glTranslate if you want just your view matrix)

Warning: glGet calls are comparatively slow and you are far better off generating your own, but for comparison's sake this will give you matrices that you can start with.

One step at a time is best.
First focus on getting a shader to compile, using view/projection matrices you copied out of the stack with glGetFloatv, and replacing your glTranslate with a glUniform3f() to move your object around. This will give you a working set of values to verify your shader functions with.
Once that's done, start building (or just download one that already exists) a matrix math library, and work on building full model transforms (translation*rotation*scale) as well as your own view/projection calculations.

Generic Attribute Buffers?

That was me not properly referring to VAO's. You've got them already, so this is done

It doesn't look like you're using shaders to draw, but are trying to use generic vertex attributes (with glVertexAttribPointer). the first argument to glVertexAttribPointer is supposed to be an attribute index in the shader program you plan to draw with, that you either bound before linking said program or retrieved via glGetAttribLocation after. I believe that on some hardware the way you're doing it (by mapping position to 0, normal to 1, and tex coords to 2) might work, but I wouldn't trust it.

If you just want to get what you have now working without shaders, try using glVertexPointer, glNormalPointer, and glTexCoordPointer in lieu of glVertexAttribPointer, and replace glEnableVertexAttribArray with glEnableClientState (call it 3 times, passing one of GL_NORMAL_ARRAY, GL_TEXTURE_COORD_ARRAY, GL_VERTEX_ARRAY each time)

Not to nitpick, but 3.3 core has deprecated the matrix stack as well. If you want to bring your code completely "up to date", I would recommend handling matrices yourself or with a library, making use of shaders for drawing geometry, and also using generic attribute buffers (glVertexAttribPointer and the like).

You'll need to look up a feature called "Transform Feedback" in OpenGL. You can disable polygon rasterization and have the output of a vertex shader stored directly in a VBO. This feature was enabled at least as early as 3.3

It looks like you can actually hack this, kind of.


as of 4.0, when using multiple render targets, XNA associates the depth buffer with the render target bound to index 0. (I assume you've got a couple, to represent color/depth/normal).

This is just a guess, but I think you can reuse your depth values by doing the following:

1. Pick a render target you DON'T need for image composition. Set it to preserve contents (or I guess you could bind a  "dummy" texture that you won't sample here);
2. Bind this render target to index 0, put your color, specular power, whatever other targets you render to on higher indices.
3. Clear color and depth.
4. Do your G-buffer pass.
5. Disable depth writing
5. Unbind your render targets for now.
6. Do your light pass.
7. Disable depth testing, and rebind the render target you had on index 0 for the G-Buffer pass (once again to index 0)
8. Bind the render target for your final deferred shading output to index 1 (or whichever index you choose that is > 0)
9. Do the image composition pass, writing the final color into the render target on index 1.
10. re-enable depth testing. (Writing should stay OFF if you want consistency in the appearance of your translucent objects)
11. Draw your transparent geometry, outputting the lit color value to index 1
12. Disable depth testing again
13. Bind the render target from index 1 as a texture, and copy it to the backbuffer via a full screen draw. This also gives you an opportunity to post-process your rendered image however you see fit.

..Long list, but I think it'd do the trick.

..Alternatively you could write a light prepass renderer, where your "image composition" pass involves re-drawing your opaque geometry anyway, and just associate the correct depths with your composition render target automatically. The only way to know which would be more efficient in XNA would be to try both (or see if somebody has).

This code won't port to OpenGL ES. The matrix stack (glTranslate, glRotate, etc) doesn't exist in that standard. You are expected to keep track of them yourself and pass the values to shaders, where you transform the vertices yourself. It also does not support the glVertex line of functions ( You have to use vertex arrays or VBOs), and works without a fixed-function pipeline (meaning shaders are required).

It sounds like linear interpolation is yielding magenta "fuzz" because it's averaging magenta with zero alpha with whatever your sprite color is, (at 1.0 alpha most likely).
If you call

glEnable(GL_ALPHA_TEST);
glAlphaFunc(GL_LESS_EQUAL, f);

Where f is a floating-point value between 0 and 1 (you'd have to experiment to see what looks good), your fuzz might clear up. Note that this means any pixels with an alpha value below f will now not be drawn!

If your sprites are blurry and you want them pixelated, the thing to try would be

GL11.glTexParameteri(GL11.GL_TEXTURE_2D, GL11.GL_TEXTURE_MIN_FILTER,GL11.GL_NEAREST);
GL11.glTexParameteri(GL11.GL_TEXTURE_2D, GL11.GL_TEXTURE_MAG_FILTER,GL11.GL_NEAREST);

When you create your textures, which will use nearest-neighbor sampling instead of mipmapping or linear interpolation for sampling texels that don't line up perfectly with the screen. (so a pixel that's halfway between two texels will be the color of the one it is closest to)

If that doesn't clear up the lines, another option to try (possibly along with the previous one) would be to add  0.5/spriteHeight to your texture coordinates' Y value, and see if that doesn't help.

Failing that, the other solutions I know of involve using shaders, which it doesn't look like you're doing here. LWJGL has some documentation on using them (and VBO's, which are unrelated here but quite useful) on its wiki, which could help you get started.