The Stack Overflow podcast is back! Listen to an interview with our new CEO.
10

The difference in which pixels are covered depending on the vertex order is related to rasterization rules. They're the rules that the GPU hardware uses to determine exactly which pixels are covered by a primitive. Rasterization rules are a bit subtle. One of their goals is to ensure that whenever you draw multiple primitives that are connected water-...


7

This type of artifact is a tell-tale sign that you've messed up your texture image format at the byte level. It's hard to tell what exactly is wrong, but it's something along the lines of bad pitch or a component layout mismatch. Have a read of this wiki page and try again. glTexImage2D should work, keep trying until it does.


6

There is no 100% consensus on what order matrix multiplication should model things, worse the industry is split along this. Some sources use row major and some sources use column major matrices. Great care should be taken to verify which is being used in your source and what is being used by your API! Some API's go as far as allowing one to multiply vectors ...


5

OpenGL uses column-major matrices. For example, the translation values will be in the last row rather than the last column of the matrix. For example when loading matrices into uniforms in glsl, the glUniformMatrix4fv() function takes its matrix parameters in column-major order: Each matrix is assumed to be supplied in column major order. In glm, the ...


5

Your screen isn't 3D, so how do you display 3D objects on it? You need to map 3D coordinates into 2D space. This also explains why your OpenGL code is not behaving how you're expecting it to. Sorry if parts of this answer are things you already know (just trying to be comprehensive). What do the model view and projection matrices do? The model view matrix ...


5

Normally if you paint a background image you simply draw a textured full-screen square while depth testing and writing is disabled before drawing the actual scene (where you re-enable depth) In the code you posted you draw the quad but then clear the screen again. Don't do that. Move the drawing of the quad from main to right after the glClear call.


3

From looking at your example images this looks like a case of Alpha blending being applied to the RGB channel of the font-atlas texture and then again applied via the A channel when rendering. The tell-tale sign of this is usually a feint dark halo surrounding your glyphs which is caused by the unwanted mid-greys present in the texture being multiplied by ...


2

I see you use glEnable(GL_TEXTURE_GEN_S); but also use glTexCoord(...) to load coordinates. These are mutually exclusive features IIRC. If you are supplying your own texture coordinates you should not need to use glEnable(GL_TEXTURE_GEN_n).


2

for (i = 0, i < 3, ++i) glTexCoord3d(texturePoint[i].x, texturePoint[i].y, 0); glVertex3d(v[i]->x(), v[i]->y(), v[i]->z()); This code calls glTexCoord3d three times and glVertex3d only once. You need more braces around your for loop.


1

You can compile it into a Vertex vertices[] = {{posx, posy, posz, texu, texv, ..}, {posx, posy, posz, texu, texv, ..}, //... } and then loop over them: glBegin(GL_TRIANGLES); for (int i = 0; i < arraycount(vertices); i++){ glTexCoord2f(vertices[i].texu, vertices[i].texv); //... ...


1

It sounds like what you need is a scissor test. It's specifically designed for clipping against an unrotated rectangle, and should be faster than messing about with the stencil buffer.


1

Your geometry may be prepared for Direct3D, which has texture space origin placed differently (top-left vs bottom-left corner). Try flipping either the texture's Y coordinates (i.e. load it from the bottom to the top), or the V texture coordinate (glTexCoord3d(texturePoint[i].x, 1.0f - texturePoint[i].y, 0);).


Only top voted, non community-wiki answers of a minimum length are eligible