Elysian Shadows

RandomDever wrote:OK so I've looked a bit at VBOs and I have this pseudo-code:

Code: Select all

GLuint colorBuffer = NULL;
GLuint positionBuffer = NULL;

GLubyte colors[] = { 255, 255, 255, 128 };

glGenBuffers( 1, &colors );
glBindBuffer( GL_ARRAY_BUFFER, colorBuffer );
glBufferData( GL_ARRAY_BUFFER, 4 * sizeof(GLubyte) );
glColorPointer( 4, GL_UNSIGNED_BYTE, 0, 0 );

GLfloat positions[] = { -1.0F, -1.0F, 1.0F, -1.0F, 1.0F, 1.0F, -1.0F, 1.0F };

glGenBuffers( 1, &positions );
glBindBuffer( GL_ARRAY_BUFFER, positionBuffer );
glBufferData( GL_ARRAY_BUFFER, 8 * sizeof(GLfloat) );
glVertexPointer( 2, GL_FLOAT, 0, 0 );

glEnableClientState( GL_VERTEX_ARRAY );
glEnableClientState( GL_COLOR_ARRAY );

glDrawArrays( GL_QUADS, 0, 4 ); //Not entirely sure how this works

glDisableClientState( GL_COLOR_ARRAY );
glDisableClientState( GL_VERTEX_ARRAY ); 

I don't exactly know what the third parameter of 'glDrawArrays' does, but besides that, is this code correct?
Also the example I drew from to make the above code draws a square with 2 triangles ( for some reason )
but it doesn't have a texture so how would I do that?

struct Vertex {
    GLfloat position[3]; // x, y, z
    GLfloat texture[2];  // u, v
    GLfloat color[4];    // r, g, b, a
    GLubyte padding[28]; // pads structure to 64 bytes for efficiency
};

////////////
// Uploading
GLuint name;
glGenBuffers(1, &name);
glBindBuffer(GL_ARRAY_BUFFER, name);

Vertex vertices[4] = {
    //  x     y     z       u     v       r     g     b     a
    { {0.0f, 0.0f, 0.0f}, {0.0f, 0.0f}, {1.0f, 0.0f, 0.0f, 0.0f}, { 0 }},
    { {1.0f, 0.0f, 0.0f}, {1.0f, 0.0f}, {0.0f, 1.0f, 0.0f, 0.0f}, { 0 }},
    { {1.0f, 1.0f, 0.0f}, {1.0f, 1.0f}, {0.0f, 0.0f, 1.0f, 0.0f}, { 0 }},
    { {0.0f, 1.0f, 0.0f}, {0.0f, 1.0f}, {1.0f, 0.0f, 1.0f, 0.0f}, { 0 }},
};
glBufferData(GL_ARRAY_BUFFER, sizeof(vertices), reinterpret_cast<GLvoid const*>(&vertices), GL_STATIC_DRAW);

//////////
// Drawing
glEnableClientState(GL_VERTEX_ARRAY);
glEnableClientState(GL_TEXTURE_COORD_ARRAY);
glEnableClientState(GL_COLOR_ARRAY);
glVertexPointer  (3, GL_FLOAT, sizeof(Vertex), reinterpret_cast<GLvoid const*>(offsetof(Vertex, position)));
glTexCoordPointer(2, GL_FLOAT, sizeof(Vertex), reinterpret_cast<GLvoid const*>(offsetof(Vertex, texture)));
glColorPointer   (4, GL_FLOAT, sizeof(Vertex), reinterpret_cast<GLvoid const*>(offsetof(Vertex, color)));
glDrawArrays(GL_QUADS, 0, sizeof vertices / sizeof(Vertex));
glDisableClientState(GL_COLOR_ARRAY);
glDisableClientState(GL_TEXTURE_COORD_ARRAY);
glDisableClientState(GL_VERTEX_ARRAY);

Nokurn wrote:

RandomDever wrote:Yes 'BlitTexture', based on your description, does use immediate mode.
It would be fairly easy to make it use a display list, but I'll have to do some research on VBOs, after I get some sleep.
Because essentially I am building this engine to be as fast as fast as possible, while trying to maintain some ease of use. ( As well as finally implementing a bunch of cool debug features to make it a lot easier to find bugs )
And also to make a 2D platformer.

Keep in mind that premature optimization can often cause more problems than it solves. In this case, however, I don't think you will regret implementing a proper renderer.

Also, try to focus on the game aspect of the project. Too often people start out to write a game, then start writing an engine, then get sidetracked by the engine. Many engines grow naturally as you develop a game. Once the game is done, you can pull out the engine code and then work on it as an engine. Or, you could incorporate it in another game, let it grow, and continue the cycle. You'll end up with a much more mature engine than if you specifically wrote an engine.

RandomDever wrote:

Nokurn wrote:

RandomDever wrote:Yes 'BlitTexture', based on your description, does use immediate mode.
It would be fairly easy to make it use a display list, but I'll have to do some research on VBOs, after I get some sleep.
Because essentially I am building this engine to be as fast as fast as possible, while trying to maintain some ease of use. ( As well as finally implementing a bunch of cool debug features to make it a lot easier to find bugs )
And also to make a 2D platformer.

Keep in mind that premature optimization can often cause more problems than it solves. In this case, however, I don't think you will regret implementing a proper renderer.

Also, try to focus on the game aspect of the project. Too often people start out to write a game, then start writing an engine, then get sidetracked by the engine. Many engines grow naturally as you develop a game. Once the game is done, you can pull out the engine code and then work on it as an engine. Or, you could incorporate it in another game, let it grow, and continue the cycle. You'll end up with a much more mature engine than if you specifically wrote an engine.

I plan to make things as I need them while developing the game, but since the rendering system is so important I am focusing on getting that up to snuff before going all out on the game.
And I had a pretty 'mature' engine before this one but I decided to rebuild from the ground up with OpenGL, because replacing the current engine would take longer anyway.

EDIT: Thanks for the code I'll implement it whenever I get over being sick...
EDIT 2: Wait... UV is where the texture goes. but what about the texture id?

RandomDever wrote:So what do you not know what you're talking about?

RandomDever wrote:Does it use the bound texture or not?

RandomDever wrote:Also. I'm assuming I can modify this buffer at any time correct?

RandomDever wrote:The only thing I would change is the alpha.

RandomDever wrote:BTW the implementation you gave me and the one I saw when I researched used per vertex coloring.
I don't need this yet so is there a more efficient way to make VBOs? Or does it have to have per vertex color data?

RandomDever wrote:Also. Do VBOs take rotation and scale data? Or can I just use glRotate and glScale?

RandomDever wrote:Also. I want my games to support changing resolution. But when the screen is stretched textures (especially text) look a bit pixelated.
Is there a good way to deal with this? Or do I have to make textures for the highest resolution I want to support so that they never get scaled up?

RandomDever wrote:What exactly are 'shaders' and how would you use them for coloring and alpha blending?

• Vertex shaders are called for each vertex being rendered. You use them to transform the vertex's position in 3D space. This is where you would apply transformation matrices (projection, world, local) in a modern pipeline (the built-in OpenGL transformation functions were deprecated in 3.0 and removed in 3.1).
• Fragment shaders are called for each fragment (similar to a pixel) being rendered. You use them to alter a pixel's final appearance, including color, alpha, and depth. This is where you would sample a texture to determine the color for the pixel.

RandomDever wrote:Also, how should I handle changing aspect ratios?
My game is going to be designed for 4:3 but I want it to support 16:9 as well.
But is there a good way to have it support both without stretching?

• Lock the aspect ratio; don't let the player choose a resolution without your target aspect ratio. Full screen will always be stretched without some form of black bars.
• Render a larger portion of the scene to accomodate widescreen monitors. This is typically the best way to go for 3D games where you can control the fov, but for 2D games it may give too much of an advantage to allow the player to see more of the playfield.
• Maintain different sets of assets for different aspect ratios. For unexpected aspect ratios, select the nearest match. This is a lot of work, but you'll get the best visual results for 2D games. It's been done several times before, and most games that run on both iPod/iPhone and iPad use this technique.