Kaptein

not bad at all, but even if you don't like OO (like me, i think people generally go way overboard with OO,)
it's still nice to use certain aspects of it, especially with matrices and vectors
passing pointers around is also something i like less and less, since its so easy to pass references around

its just better code, with no effort
nice demo though

One final thing:
If you try to render to a texture that you have for any reason bound to a texture unit, it won't work at all, or do strange things

Remember to explicitly check that you are in fact free to render to that texture.. If you are using many texture units, like me, it can take a long time to figure out why it won't work correctly (by trial and error)
I've also had issues (probably on specific cards) when not using D24S8 storage type for renderbuffer, so try that too if something doesn't work right
The depth is still in the .x swizzle

if statements that cause branching will be slower in a functional (block-data) enviroment
if you use constants, the compiler will work the same way as if it was a #ifdef SOMETHING ... #endif

http://http.developer.nvidia.com/GPUGems2/gpugems2_chapter34.html
outdated, but still useful
especially for mobile GPUs, which i personally pretend don't exist

ideally, your code should handle 250-500ms lag, and thus you'll need to interpolate between the data sent to you from another player
this is a game where lag will affect gameplay, and we don't care about cheating, so, i would just do very simple interpolation in between updates
and not worry so much about the actual amount of latency or updates..
the biggest problem you will face is "invariance," here being desynchs, but since you have a centralized server that makes all the decisions
this problem is already solved =)

i would implement fast interpolation pad_y = (0.9 * pad_y + 0.1 * pad_last_y); pad_last_y = pad_y;

nodelay is good in high-speed games (disabling nagle algo), but it might not always be enabled..
the drivers are free to do nothing, after all, and never tell you otherwise
udp isn't really any faster, it's just potentially smaller packets, and widely used for "positioning" that are high-frequent updates
when working with networking, you will never have a cpu bottleneck compared to high latency
high latency is measured in hundreds of milliseconds, and there isn't much you can do about it
increasing the amount of updates you are doing by too much will just cause the socket to throttle (and die) because its write buffer would be exceeded
the normal latency for local loopback is 0ms, LAN is 1ms+ and internet is at least 60ms
60ms is alot considering 30fps is 33ms, 60ms is ~16fps
that's why you'll always _always_ need to interpolate between moving visuals with high-frequency updates

that draw function isn't going to work well, because you are binding 4 VBOs in a row, which means that only the last one is bound before drawing
you are drawing tangents
you should have kept the "pointers" to the data, and even better if you want fast rendering - interleave the data in a single VBO using a struct
http://www.opengl.org/wiki/Vertex_Specification_Best_Practices

unfortunately i have to cut my reply short, i have an exam to go to =)

0.0001 is a very very small near plane value!
you have lost nearly all precision at z = 40.0 with 24bits

try znear = 0.1?

you probably want to read this:
http://www.sjbaker.org/steve/omniv/love_your_z_buffer.html
there's also a nifty calculator there!

if the skybox is exactly at 1.0 (zfar) by writing gl_FragDepth = 1.0 in the atmosphere shader,
you can avoid it by using a branch: if (depth < 0.99) { do stuff }
It will reduce performance of your SSAO shader, but i think it will work

in your example this could be:
if (normaltexel.a < 0.999)
{
   do ssao
}

well, in java you could serialize objects, and get perfect replicas (with data element and class -exceptions of your own choosing)
in C i would define structures that consist primarily of what i want, and the offsets between the specific data, so that my saves never get "old"
for example, a small int table in a savefile tells me where this and that starts (in bytes), and ill just grab some generic tables from these positions
assuming you have made changes to the internal structures recently, it will get complicated in C, but there may be tricks you can use in C++ (i don't know the language)

anyways, define structs (classes if you will) that contains pertinent information on the data, and let these structs be so generic that you won't have to go back and look at them ever again =)
harddisk space is .. the least of your problems make room for improvements!
when this is done, just put the structs one by one into the file at the locations you'd want them to be in, and disregard completely "open spaces between structs"
the only requirement here is that you know where they are, and that they don't overlap
if you use sizeof(struct) you can pack them well together, and you might still be able to load the structs later, if you consider the differences between any old and new scheme
i recommend discarding old data though, if you make any changes

so, if A is the main savefile struct, and B is a container for where some additional structs are stored, the file layout could be:
ABBBBBBB C C C C C C C C C C C C C C C
the procedure:

// tell our future selves what size A had when we made this file
put (sizeof(A))

// tell A what kind of size B had when we saved
A.container_size = sizeof(B)

// declare a position for where we are in the file, which simplifies things greatly,
// both for loading and saving
int position = 0; // (or 1, depending on if its 0- or 1-based file offsets, its ALWAYS in bytes though!)

// put the entire struct directly into the file
// and increase position by the size of this structure (note that the sizes of structs vary between compilers!)
// (however, differences between compilers is something we don't care about now, and sometimes the language is consistent )
put(A); position += sizeof(A);

// put each struct that tells us location of data, and its size
for (int i = 0; i < a.containers; i++)
{    put(B); position += sizeof(B);
}

// for each B, we put each C (for each collection of data, we put each data)
for each B for each C in B
{
// we want to remember the size of each data item, including what type it is, and any other information
// that you would need to know now, or in the future
B.data_size[index] = sizeof©;  // for example..!
// put to file, advance position
put© : position += sizeof©
}
close()

and so on .. and so forth =)
now the position you are in the file is incremented for each structure, packed tightly
and there is no confusion about where anything is located
this is an ultra-basic system, that leaves less room for problems in your code, but is still not completely resistant to future updates and changes
to compensate for future changes, a version system could be used, but then you'd need backwards compatibility in your games loading system
personally, i say if you make any changes to the saving system - make all the changes, and scrap the old system, if you can
i hope this helps

it looks like your reflection vector is in tangent-space rotated viewspace, which is extremely wrong
the reflection vector to a cubemap is in local-model space, meaning 0.0, 1.0, 0.0 is up etc.
to use it, you simply need to (for example):
l_reflect = reflect(-v_eye, v_normal) * mat3(camera_rotation);
this is assuming that v_eye is normalize(-position.xyz) in viewspace, and v_normal is the normal in view space

Note2: I'm using the term "matrot" here, so that you will understand we are talking about the "normal matrix"
which is the rotation part of a unit-scale view-matrix (or camera if you will) with the look-vectors
If your model AND view-matrix are simple: rotation and translation (no scaling), then you can use the 3x3 of matview

NOTE: in GLSL vector * matrix = transpose(matrix) * vector

another way:
l_reflect = reflect( (-v_eye) * mat3(matrot),  in_normal );

a third way:
l_reflect = reflect( normalize(position.xyz) * mat3(matrot), in_normal );


so, bottom line here is that the reflection vector must not be rotated even if the model which represents uses the cubemap is
because you are accessing the cubemap texture using a vector that is aligned to the cubemap, not any objects!
also: you don't have to normalize cubemap accesses! so avoid normalization!


once you have the texture, you'll want to rotate the normal:
// in fragment / pixel shader
// tangent space normal:
vec3 norm = cubeMap(blabla).xyz * 2.0 - 1.0;

// you have already created your 3x3 tbn matrix in your own code correctly
// rotate your normal from tangent to localized space:
norm = normalize( tbn * norm ); // you usually don't need to normalize this

// rotate local to view-space, where matrot is the 3x3 part of a simple view-matrix (no scaling)
vec3 v_norm = mat3(matview) * norm;

or
vec3 v_norm = myNormalMatrix * norm;

done.

Seeing you come from XNA I think you will feel more at home with DX11. That being said there is no reason to switch away from VS for OpenGL development just switch to C++ or use OpenTK in which case you can even stick with C#.

I've thought about it, but if I want to create a game for non-desktop platforms, C++ is more applicable . Also, I think that C++ is somewhat of industrial standard when it comes to game development, so with that in mind, I think it is better to use C++ than C#

It's entirely your choice to make. But yes, with C# you may be stuck with Windows.
With good multiplatform libraries C++ can let you make builds for linux/windows/macos with little or no hassle
GLFW is a good window library that simplifies OpenGL + window + mouse/keyboard/joystick and even timing for you
Some people use GLUT (most likely freeGLUT), or SDL (Simple Directmedia Layer)
I'm sure there are others
But for starters, with GLFW you have the basics, they work, it's not abandoned and its multiplatform
freeGLUT i'm not sure about, other than that it's simpler.. going from freeGLUT to GLFW (or vice versa) is a simple task
SDL is a huge library that is very powerful, but I don't know very much beyond that

you may get better FPS by not using indices, or by super-optimizing indices which may be a waste of time
deleting VBOs is completely safe, and completely necessary to keep from using too much vram
consider using columns of the entire world as a final VBO, then you will have let's say 32x32 VBOs, and you need only bind a few of them for each render
in minecraft 32x32 sectors x 16x16 blocks is the size of the world on "far render distance" setting
remember that the memory requirement for the game increases exponentially with each ring of sectors
you also need to parallellize the pipeline that assembles the world into vbo data
but you can only call gl* functions on the render threadi
that means that it's pointless to try to parallellize anything in the renderer, and instead focusing on optimizing hard on what the renderer has to do
and lift some weight off of it
ideally, the rendering thread should only do rendering, and nothing else =)
you can only call gl* functions from the same thread as the opengl context was created on, otherwise you are in trouble

you can use occlusion query objects to find out what isnt visible 1 frame from when you render them
this will let you draw alot less 1 frame after drawing everything in the frustum

you can solve this by not running at a fixed timestep
i run everything using floating point timesteps
then it HOPEFULLY doesnt matter what your "update speed", or any speed is
all that matters is the precision level you choose to use, and the precision of the timer
you'll still have to cap the difference between previous and next to avoid jumps in physics when the system stalls for whatever reason
but you can't get smoother than floating point...

if (_localtime - _lasttime(0) > timing_max_difference)
  _lasttime(0) = _localtime - timing_max_difference
time_d_factor = 1.0 + (_localtime - (_lasttime(0) + movement_scale)) / movement_scale
_lasttime(0) = _localtime

now you can just multiply everything (including floating point counters) with time_d_factor
movement_scale isn't a good name for a variable.. it's just a measure of how big you want your multiplier to be (so that it makes sense in your physics department)
for example if its 0.01 you'll measure things in 10ms and so on

so, i'm just posting it here in hopes someone will discount or confirm my idea..
this has worked well for me for a month or two now, and it's been very smooth

from reading your posts, you should be up and going in no time
starting out with python may be a wise choice, since it's user-friendly (just like programming should be!)
there are probably sites out there that describe the fundamentals of programming and programs, which is probably where your first stop should be
http://www.careercampus.net/resources/programming_fundas.htm
the link above seemed like a good fundamental description.. =) hope it helps

Programming is not more important than design..

idea -> design -> execution
without execution, you have nothing! Frankly, the vast amount of projects out there never passes execution
To a small degree, you also learn design by doing
A part of doing includes learning from other people, which in turn may have a much better design than you
Research &amp; Duplicate!

I agree with you though, but.. for beginners, i would just get on with the programming
Just spending time finishing the projects should be more than enough
With that time spent, the beginner programmer will notice all kinds of deficiencies and complexities in his code
I think, that over time a programmer will start designing naturally
It is just one more thing to help us stay sane, after all.. i hope

you probably are, a cheap alternative is simply glGenerateMipmaps
and the average luminance of the scene will be texture2DLod(.....,  ,  1000); just put as many zeroes as you feel like
it will sample the highest mipmap level (1px)
works well for me.. unfortunately i dont like bloom, and feel it doesnt add anything to my game except brightness, and problems...
you can't have white textures anymore, for example

note that you can use the same scheme to get lens flare and cheap godrays
just a little bit more complex..

has anyone actually used bloom successfully, ever?
http://registry.gimp.org/files/sample1bl.JPG
this is just a regular photo, with bloom filter, which looks ok
but in a game... bloom ruined my clouds