Jump to content

  • Log In with Google      Sign In   
  • Create Account

14 years ago on June 15th Gamedev.net was first launched! We want to thank all of you for being part of our community and hope the best years are ahead of us. Happy birthday Gamedev.net!

NumberXaero

Member Since 29 Apr 2002
Offline Last Active Today, 11:42 AM
*****

Posts I've Made

In Topic: My opengl program is really slow, what's the problem?

14 May 2013 - 03:44 PM

If its not caused by the state queries from glGet*() calls, then it probably related to the drawing calls, unless its something somewhere else.

 

When you changed to unsigned short, did you also make sure to change all the GL_UNSIGNED_INT's to GL_UNSIGNED_SHORT and all the sizeof(unsigned int) across all the buffer setup calls and draw calls?

 

You said the fps are not accurate in your first post, is the scene sluggish? can you profile where the time is being consumed? if not, make sure the fps are correct so you have a solid value to go by.

 

You might try bypassing vaos and just binding buffers and enabling arrays at draw time. I had a problem once with vertex array objects causing problems, it was related to the way the gl functions were being loaded by glew, it required glewExperimental set to true before calling glewInit(), not sure if its was on amd or nvidia. Im not sure how youre loading gl calls, maybe its relevant. Valve software released a doc "Porting source to linux" where they said vaos were slower then glVertexAttribPointer on all implementations.

 

Depending on your targeted GL version you might want to look at the gl_vertex_attrib_binding extension.


In Topic: My opengl program is really slow, what's the problem?

10 May 2013 - 06:18 PM

There have been times ive found glGetUniformLocation being called too often during run time to be a problem, after building the shader get the uniform location and save it, look it up locally at run time and by pass calling glGetUniformLocation at run time, unless the shader changes dynamically the location shouldnt change.

 

Also, you may not always want to consider -1 locations as incorrect, -1 uniform locations can mean a few things. If the shader doesnt make use of a uniform, either it was optimized out or commented out but still declared, the shader may run fine even with a uniform having a -1 location, it doesnt always mean a the uniform had a typo or wasnt found.

 

my model has more faces than the maximum unsigned short supported

 

the index buffer indexes vertices, not faces, many faces may share the same vertex, reducing the vertex count, the whole purpose of index buffers. So if the numbers from your first post are correct the vertex count easily fits in unsigned short.

 

 

In general dont call the "glGet*()" series of commands as they stall rendering to retrieve the state being asked for.

So assert(isInUse()); calls glGetInteger() which is probably the problem, comment all those out.


In Topic: My opengl program is really slow, what's the problem?

10 May 2013 - 03:09 PM

Just going on whats been posted its difficult to tell (what hardware is it running on?), but two areas I would look at, 1 try using unsigned short for the index type if possible. 2, your shaders are being set by string, not sure how thats done, is it doing a lookup every frame? are you using the string to get the uniform index every frame? if so, try getting the uniform location once, when the shader loads and links.


In Topic: OpenGL glTranslatef problems

26 April 2013 - 08:07 PM

Read up on orthographic projections, the whole point is that things wont change in size, the far and near plane values are probably culling the triangle after you move back.


In Topic: Following a path, determining when to move on to the next point

19 April 2013 - 06:21 PM

What if you created a plane out of the target point and the current travel vector, then test if the current object position is on the positive side of the plane, which would mean you passed the target point.


PARTNERS