Tag Info

New answers tagged

0

Yes, it is absolutely possible. Fill rate is not such a problem because mobile graphics chips are designed to deal with very high resolution screens. In fact, deferred rendering helps with this because your lighting calculation is independent from scene complexity, so overdraw doesn't cause a slowdown. Here is my implementation on a fourth generation ...


3

Fragment shaders operate with floats. This is an abstraction over the actual underlying hardware format (GLSL is a high-level language after all), so you shouldn't expect that to indicate that you've actually got a floating-point framebuffer. You'll always use vec4 in your fragment shader irrespective of if you have a 16-bit, 32-bit, 64-bit or 128-bit ...


4

Well, OpenGL is a state machine, so inorder to plot function dependencies you need to plot a state machine, there is this one that models the most recent versions of OpenGL pipeline including ES2.0 and 4.0. Unfortuantely I couldn't find a diagram the plots function dependencies but I guess that can be mostly deduced from the state machine.


2

"Is this approach even possible?" What you could do is make a fine resolution full screen "quad" that has it's verticies displaced in the vertex shader according to a lookup into your "depth buffer" texture. That way, the perceived depth of your grayscale image will be written into the currently bound framebuffers depth buffer. "I want to write a shader ...


0

This is a known bug in Adreno GPUs. Your problem is this little snippet of code: Bones[boneIndex] Many Adreno GPUs have a bug when accessing mat4 uniform arrays with non-constant indices. They will always silently return the first element in the array. This discussion on the qualcomm forums has some more background on this problem. This bug applies only ...


0

I guess that the problem is in the uninitialized variable skinTransform. You should always explicitly initialize all your variables. So, you need to define and initialize the variable skinTransform like this: mat4 skinTransform(0.0); See The OpenGL ES Shading Language documentation at section 5.4.2 Vector and Matrix Constructors for more information. ...


1

To get to your main question, whether or not to influence the vertices before or during the shader, using a shader is preferred. If you know how to write a routine that can take into account the viewport and coordinate system, using a shader is preferred as it allows many sprites to be adjusted in parallel. Also, it ensures the "cosmetic" coordinates stay ...


1

Wow that was fast. It's crazy how sometimes just writing out the question helps you figure out how to approach a solution. Here is my matrixPerspective function: void matrixPerspective(float angle, float near, float far, float aspect, mat4 m) { //float size = near * tanf(angle / 360.0 * M_PI); float size = near * tanf(degreesToRadians(angle) / ...


0

First I agree with the other answer about camera location code. On your display loop I would draw everything first, then update everything after that, then repeat. Second, I have a game I'm working on right now that has a character (space ship) that can travel anywhere in a 2d world (3d game with a flat map). I use something like this to change the ...


2

I think I would store two sets of coordinates. One used for drawing your objects DISPLAY POSITION and a second used for keeping a TRUE POSITION. This way you can draw sprites with rounded coordinates to eliminate the distortion caused by fixed size of your view area. But this also allows you to keep the exact location without influencing any of your ...


1

from looking at the docs I have found your issue public static void rotateM (float[] m, int mOffset, float a, float x, float y, float z) Added in API level 1 Rotates matrix m in place by angle a (in degrees) around the axis (x, y, z). Parameters: m source matrix mOffset index into m where the matrix starts a angle to rotate in ...


3

I'd go for a second shader that accepts two textures and does the desaturation. Performance loss will be minimal. uniform sampler2D tex; uniform sampler2D texA; void main() { vec4 texelColor = texture2D(tex, gl_TexCoord[0].xy); vec4 maskColor = texture2D(texA, gl_TexCoord[1].xy); vec4 desatColor = texelColor * vec4(0.3, 0.59, 0.11, 1.0); // ...


0

I'm answering based on my OpenGL non-ES knowledge, which I hope works on ES as well. It sounds like you want to use GLushort in your C code, referred to as GL_UNSIGNED_SHORT when passing the data to OpenGL in C, and then use type int or uint in GLSL. One gotcha is to use the function VertexAttribIPointer instead of VertexAttribPointer when sending the data ...



Top 50 recent answers are included