Jump to content
  • Advertisement

janharal

Member
  • Content Count

    52
  • Joined

  • Last visited

Community Reputation

138 Neutral

About janharal

  • Rank
    Member
  1. janharal

    VBO squashes my Vertex Arrays!

    Shouldn't there be an "glBindBufferARB( GL_ARRAY_BUFFER_ARB, 0 );" at the end of the VBO render method?
  2. EXT_framebuffer_object should handle this well. (It's an offscreen buffer so it's should be limited by maximum texture dimensions and not the size of the window or viewport)
  3. janharal

    liquid tube effects. how to?

    It looks like a multi-textured, distorted cylinder. You can probably recreate it by drawing the geometry and using the texture matrices to animate the texture coordinates.
  4. The error occurs because the texture you use for DEPTH_ATTACHMENT is an RGBA texture. This needs to be a DEPTH_COMPONENT texture. Apart from that, your second example should work just fine.
  5. janharal

    Render to texture FPS

    Take a look at frame buffer objects (GL_EXT_framebuffer_object).
  6. janharal

    In Game Fur

    take a look at this: http://research.microsoft.com/~hoppe/#fur A simpler (and less good looking) approach is to store fur-length in the alpha channel of the diffuse texture, and then draw the fur multiple times with alpha testing enabled - scale the geometry slightly upwards and lower the alpha threshold for each pass.
  7. I doubt that you'll see any/much difference either way. As far as I know it is the number of state changes (of any kind) that can cause problems. This happens simply because each change requires a separate draw call. Even if you don't combine similar meshes into a single draw call, the driver might be able to if the state is completely unchanged. I'd suggest you order by the most commonly shared resource. (e.g. textures if lots of objects share the same texture). Whether that is textures/vbos/shaders depends on the usage scenarios you have in mind for the engine.
  8. janharal

    texture in OpenGL ES

    Like Kusma said: check if you need to inherit any interface classes (like MImageHandlerCallback). If you already have an example it should be easy to look up...
  9. janharal

    gl_lights - disable normal calculation?

    I think you can specify one normal - pointing in the direction of the camera - and render the whole mesh using that normal. This should at least work with the begin-end paradigm - I can't remember if anything changes if you switch to drawElements or VBOs.
  10. janharal

    Preprocessor Processor Defines

    There might be some compiler specific flags for this, but the easiest would probably be to just add a compile time define yourself. (i.e. g++ file.cpp -m64 -D_COMPILE_AS_64_BIT_).
  11. janharal

    Shadow mapping problem

    Are pbuffers involved in this? I've had problems with ATI cards and depth components when they have been involved.
  12. You need to declare your static variable somewhere - usually in your .cpp file like this: vector<light> light::lightpool; BTW: You should probably store pointers to light in the vector to avoid unnecessary copying. edit: formatting
  13. janharal

    Time Based movement, crappy?

    You should scale the speed by the time elapsed since your applications started instead of the time since the previous frame. Doing it this way removes frame rate dependencies.
  14. janharal

    OpenGL lighting issue...

    glNormalPointer wants vertex-normals. Normals can be flipped just by inverting them. You might want to try moving the lightsource around to see if there's any reaction. Your lightsource position seems a bit strange to be, but that depends on your geometry of course.
  15. janharal

    OpenGL lighting issue...

    Normals facing in the wrong direction? Where is the lightsource placed? Which colour is specified in glColor? Just brainstorming here ;-)
  • Advertisement
×

Important Information

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

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!