sjaakiejj

You've got a few problems in your code that I can spot straight off. I haven't used GL_STREAM_DRAW myself, so I'd try using GL_STATIC_DRAW to make sure your code is working correctly.

So your initialisation should look a bit like this:

  GLuint pVertexBufferObj; //You should remember this one, as it specifies the "location" of the data in GPU memory

  /* Generate a buffer object, and bind it with the data */
  glGenBuffers(1, &pVertexBufferObj);
  glBindBuffer(GL_ARRAY_BUFFER, pVertexBufferObj);
  glBufferData(GL_ARRAY_BUFFER, sizeof(Vertex) * t->NumberVertices, t->vertices,  GL_STATIC_DRAW);

  /* Tell OpenGL we're now done providing it our data */
  glBindBuffer(GL_ARRAY_BUFFER, 0);

Next in the draw call you would specify the following:

    
  glEnableClientState(GL_VERTEX_ARRAY);
 // glEnableClientState(GL_NORMAL_ARRAY); //If we're using normals
 // glEnableClientState(GL_TEXTURE_COORD_ARRAY); //If we're using textures

 glBindBuffer( GL_ARRAY_BUFFER, pVertexBufferObject);
//3 = Number of elements (xyz), GL_FLOAT = Type of elements, sizeof(Vertex) = size of your elements in bytes, 0 = offset from the start of your vertex buffer object array
   glVertexPointer(3, GL_FLOAT, sizeof(Vertex), 0 ); 
   //Same for Normal & Texture pointers

  glPushMatrix();
    glDrawArrays(GL_TRIANGLES, 0, t->NumberVertices);
  glPopMatrix();

glBindBuffer( GL_ARRAY_BUFFER, 0 );
//glDisableClientState( GL_TEXTURE_COORD_ARRAY );
//glDisableClientState( GL_NORMAL_ARRAY );
glDisableClientState(  GL_VERTEX_ARRAY );

Important thing to note here is that Vertex Buffer Objects do not have their coordinates stored in the CPU memory, but in the GPU memory. Sending the vertices off to a buffer object at every draw call defeats the purpose of using them, as they exist to reduce the bandwidth usage between CPU and GPU.

This is your problem:

glutInitDisplayMode(GL_DOUBLE | GL_RGBA);

Should be

  
glutInitDisplayMode(GLUT_DOUBLE | GLUT_RGBA);

Easy to identify on Linux (You get an X error if the window parameters are incorrect), though based on your error log I suppose it's not quite as easy on windows, where it just crashes because of invalid window parameters (without actually telling you why).

Edit:
Just for future reference, it's easy to remember which enumerations go where in OpenGL. If the function starts with "glut", then the parameters should always be "GLUT_", where as functions that start on "gl" should always have parameters starting with "GL_". They're two different libraries, though since GLUT complements OpenGL it's easy to get confused if you don't pay attention to this detail

In regards to Resources on Java, one of my old lecturers wrote a book about Java, going over every important topic in the language, making extensive use of Inheritance and Generics in the later chapters. It's the book that he also uses for his lectures, and it makes an excellent resource for the language.

http://www.amazon.com/Java-Just-Time-John-Latham/dp/1848900252/ref=sr_1_1?ie=UTF8&qid=1312562473&sr=8-1

It's easy to read, down-to-earth, and dives much deeper into inheritance than "I'm a dog called steve".

Does anyone know of a tool to help me visualize my design?

Either DIA as mentioned above, or my personal favourite; Violet. Violet is in Java, so it works on any operating system. It's also specific to UML, making it quite a bit easier and more convenient to use.

Otherwise , you culd spend your life using other people work and fool yourself your are a professional game developer, no matter how good the results look and how fast those results are achieved.
I just wanted to tell you- try some OpenGL / Direct3D examples first. Some of them are even more simple and good looking than setting an Ogre development environment and creating a game loop.

Can't quite agree with what you say. High level abstractions such as 3D Graphics Engines are able to abstract away a lot of the often more difficult details of how OpenGL or DirectX work. To learn how to build games with OpenGL is definitely important, but I'd say it's also something that you'd do after you know how a game works, not before. Otherwise you're just making it much more complicated for yourself.

I've never programmed anything gaming related.... hence my frustrations... the other day I got pong to work in freeglut (just the graphics) But nothing works. Just draws the 2 bars and a ball.... closest I've ever gotten to a game.

I can't speak from personal experience, but I have heard that some of the programming techniques you learn from a straight computer science approach don't mesh well with game design.
I would hate to semiquote a kevin bacon movie, but it sounds to me like you have the BCD and you don't have the A of game programming.

the quote from hollowman: "Genius is the ability to go from A to D without having to go through B and C." Sebastian can do that, but for me, I gotta have the B and C.

I appreaciate the post... but I don't fully understand it.... with game programming my main problem is the graphics. I have no idea how to do the things taht need to be done. I know the desing but don't know how to do it.

I've always liked this quote by (Well not confirmed he said it, but likely anyway) Thomas Edison, when someone asked Thomas about failing to create a lightbulb a 1000 times:
"I have not failed a 1000 times. I have successfully discovered 1000 ways to not make a light bulb"


Essentially this is the quote that keeps me going when I hit another brick wall in my learning process. For me the quote's like this:
"I have not failed a 1000 times. I have successfully discovered 1000 ways to not make a video game"

If Game Development is what you're passionate about, remember that quote, always pick yourself back up, and re-do it until you find the right way. If you've tried every way not to do it, there's only one way left!

To avoid future mistakes put literal constants on left side so that you can caught this potentially nasty bug at compile time:

...
if( 11 = x )//error
if(11 == x) //fine and same as if(x == 11)

I've seen this kind of thing before, but I don't know if it really helps anything: If you can remember to put the number first, you can also remember to write "==" instead of "=".

It does help, as doing that every time makes it a habbit, whilst missing out an "=" can often be due to a typo, and lead to an incredible headache when debugging.