Jump to content
  • Advertisement


  • Content Count

  • Joined

  • Last visited

Community Reputation

150 Neutral

About theZapper

  • Rank
  1. theZapper

    OpenGL/GPU operations expensiveness?

    Thanks guys, I guess I'll carry on trawling the GPU makers sites to see what info they give out. Interestingly, the DirectX article mhagain linked to backs up what Phantom says, it has shader changes at the top of the list and texture changes fairly low down. I'm also working in the context of mobile development with OpenGL ES 2.0, so VAO's are out of the question for me, along with 2k textures!
  2. Can you not just use [font=Arial, Lucida, sans-serif]gl_FrontFacing in the pixel shader?[/font]
  3. theZapper

    Shader Problem?

    The Z positions of your vertices are all at 0.0, which is probably the same as the view location. Try changing them to -2.0 to put them in front of the viewport (and possibly clipping plane).
  4. Hi There I've been wondering for a while if there is a list somewhere that shows all the GPU operations and how expensive they are relative to each other. For example, is binding a new shader more costly than binding a new VBO? And if so, by how much? I'm guessing Nvidia/ATI/Imagination publish this information as I'm always reading books that say "operation A is cheaper than B" or "operation C is very expensive". This information would be very useful when trying to batch up operations to keep the expensive operations less frequent.
  5. You superstar! In the meantime I've actually just put this bit of code in... GLint infoLength; glGetShaderiv(shaderHandle, GL_INFO_LOG_LENGTH, &infoLength); if (infoLength > 0) { char infoLog[512]; glGetShaderInfoLog(shaderHandle, infoLength, NULL, infoLog); std::cout << infoLog; } ... which started pumping out errors (Notice the correct usage of glGetShaderiv this time though!) I'm betting I inserted the wrong function name by not paying attention to the intellisense popup in Xcode. So it's all Xcode's fault really. I also found that you need to stick a precision qualifier on the problem vec4 light definition, I thought it was only the varyings and global type ones, but there we go. Thanks again mate!
  6. Yep, here are the two methods. buildShader always seems to pass and return a valid shader handle, even when I the shaders have errors. void cShader::buildProgram(const char* vShader, const char* fShader){ cout << vShader << "\n" << fShader; ifstream myfile(vShader); std::stringstream ss; if (myfile.is_open()) { ss << myfile.rdbuf(); //cout << ss.str().c_str() << endl; myfile.close(); } GLuint vertexShader = buildShader(ss.str().c_str(), GL_VERTEX_SHADER); myfile.open(fShader); if (myfile.is_open()) { ss.clear(); ss.str(""); ss << myfile.rdbuf(); //cout << ss.str().c_str() << endl; myfile.close(); } GLuint fragmentShader = buildShader(ss.str().c_str(), GL_FRAGMENT_SHADER); programHandle = glCreateProgram(); glAttachShader(programHandle, vertexShader); glAttachShader(programHandle, fragmentShader); glLinkProgram(programHandle); GLint linkSuccess; glGetProgramiv(programHandle, GL_LINK_STATUS, &linkSuccess); if (linkSuccess == GL_FALSE) { GLchar messages[256]; glGetProgramInfoLog(programHandle, sizeof(messages), 0, &messages[0]); std::cout << messages; exit(1); } // save often used parameters for later projectionUniform = glGetUniformLocation(programHandle, "uni_proj"); } GLuint cShader::buildShader(const char* source, GLenum shaderType) { GLuint shaderHandle = glCreateShader(shaderType); glShaderSource(shaderHandle, 1, &source, 0); glCompileShader(shaderHandle); GLint compileSuccess; glGetProgramiv(shaderHandle, GL_COMPILE_STATUS, &compileSuccess); if (!compileSuccess) { GLchar messages[256]; glGetProgramInfoLog(shaderHandle, sizeof(messages), 0, &messages[0]); std::cout << messages; exit(1); } return shaderHandle; } These are the shaders I'm currently trying to compile. I've systematically commented bits in and out to find the problems. Vertex Shader: // Attributes change on a per vertex basisattribute vec4 att_pos; //attribute vec4 srcCol; attribute vec2 att_tex01; attribute vec4 att_nml; // Varyings are output to the fragment shader and are interpolated between vertices //varying vec4 destCol; varying vec2 var_tex01; varying vec4 var_nml; varying vec4 var_pos; // Uniforms remain constant over the course of the draw call uniform mat4 uni_proj; uniform mat4 uni_modelView; //uniform vec3 uni_pointLight1; void main() { //destCol = srcCol; //var_tex01 = att_tex01; var_nml = att_nml; var_pos = uni_modelView * att_pos; gl_Position = uni_proj * uni_modelView * att_pos; } Pixel Shader: [color=#FF3DF7]//varying lowp vec4 destCol;uniform sampler2D uni_texture0; //uniform vec3 uni_pointLight1; varying mediump vec2 var_tex01; varying mediump vec4 var_nml; varying mediump vec4 var_pos; void main() { //vec4 light = vec4(0.0, 1.0, 0.0, 0.0); //vec4 L = normalize(light - var_pos); //float diff = max(dot(var_nml, L), 0.0); //gl_FragColor = vec4(0.0, 1.0, 0.0, 1.0);// * diff; gl_FragColor = var_nml; //texture2D(uni_texture0, var_tex01); [color=#971F8E]} As they stand, these two currently compile and link, but if I comment in the first line in the pixel shader (vec4 light...) they will still compile but fail to link. I had similar problems with the variables in the vertex shader being spelt wrong, which should give a syntax error and un-recognised symbol error, but they quite happily compiled then failed to link.
  7. I'm pretty confused here. I'm trying to write an OpenGL ES 2.0 app for iOS. However, when my shaders compile I get no errors messages, even if they contain obvious errors like undefined variables. I then get link errors saying [font="Menlo"]ERROR: One or more attached shaders not successfully compiled.[/font] [font="Menlo"] [/font]Does anyone know why this would be? I'm using iOS sdk 4.3 on the simulator, I'm still waiting for my iPod for testing. Cheers
  8. theZapper

    Render Targets and Antialiasing (DX9)

    Ok, I was being retarded, that's exactly how to do it. Cheers Adam.
  9. theZapper

    Render Targets and Antialiasing (DX9)

    Ok, I was being retarded, that's exactly how to do it. Cheers Adam.
  10. theZapper

    Render Targets and Antialiasing (DX9)

    But StretchRect is for copying surfaces to surfaces, and I'm yet to find a way of converting a surface to a texture (the other way is easy) so I can use it as the source in shader operations. It must be possible to do it, think of all the games out today using post processing effects on the whole scene. [edit] Actually, I suppose I just create a target texture and get it's surface pointer, then copy the source surface the the target's surface.
  11. Morning I'm trying to render my scene to an RGBA texture so I can get the alpha channel. Problem is I need to have Anitialiasing on and from what I can tell so far you can't do AA on a texture. I looked into IDirect3DDevice9::CreateRenderTarget which can create an AA surface but I can't find any way of creating a texture object from a surface. And I don't want to use this surface and just copy it to the back buffer as I want to apply the R2T texture to a screen aligned quad so I can render it using a shader for special effects. Any ideas? Cheers
  12. theZapper

    Shader inputs and outputs

    I'm using D3DFVF_XYZRHW for ther verticies which I've just seen in another thread means the vertex shader is ignored. I changed my shader so the pass didn't include the Vertex shader and got the same green result, is this the reason then?
  13. I'm trying to get a filter working but my vertex shader isn't passing values through to my pixel shader. Currently I have these shaders void bayerFilter_VS(float4 position : POSITION, float2 tex : TEXCOORD0, out float4 Position : POSITION, // vertex position out float4 center : TEXCOORD0, out float4 xCoord : TEXCOORD1, out float4 yCoord : TEXCOORD2) { sourceSize = float4(1920.0, 1080.0, 1.0/1920.0, 1.0/1080.0); center.xy = tex; center.zw = float2(0.5, 0.5);// tex * sourceSize.xy + float2(0.0, 0.0); float2 invSize = sourceSize.zw; // .zw = fractional distance between pixels on source tecture xCoord = center.x + float4(-2.0 * invSize.x, -invSize.x, invSize.x, 2.0 * invSize.x); yCoord = center.y + float4(-2.0 * invSize.y, -invSize.y, invSize.y, 2.0 * invSize.y); // verticies are pre-transformed Position = position; } void bayerFilter_PS( float4 center : TEXCOORD0, float4 xCoord : TEXCOORD1, float4 yCoord : TEXCOORD2, out float4 outColour : COLOR) { outColour = float4(center.z, center.w, 0.0, 1.0); } the pixel shader is currently stripped down to nothing just to see if the vales are making it through. As you can see the vertex shader puts (0.5, 0.5) into the .zw components of center which is bound to the TEXCOORD0 semantic. I'm outputting the .zw components in the pixel shader and would expect this to render a dull reddish green texture at the end, but it comes out bright green which indicates that the .zw component is not getting passed through correctly. Can anyone tell me why this is? Cheers
  14. theZapper

    Currently best free email?

    You don't like the fact it folds up previous messages above the current message? I LOVE that feature. I also like the "Update conversation" notification you get when someone send you a reply to the message you're already replying to. p.s. Okey-dokey
  15. theZapper

    Quadro Cards vs. Games Cards

    Thanks for the info guys. I've also notice lots of the features seem to be optimised for OpenGL, i.e. OpenGL is mentioned a lot in the documents I've read and the new cards only support DX10.1 but OpenGL 3. Seeing as we're using DirectX, and only DX9 at the moment would that mean we're not getting any extra value from a Quadro card other than the SDI option?
  • Advertisement

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!