Jump to content
  • Advertisement
Sign in to follow this  
coderWalker

Deprecation?

This topic is 2614 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

I downloaded the gDEBugger for OpenGL.

I thought at first my program would not work with the Profiler, however after a while a discovered the problem.
To anyone else attempting to use gDEBugger
If your program requires external resources (images, sound, etc)
When running the Profiler it will change the current file path.
The only way for it to not change the path is to move all DLL files your
program uses to the same directory that contains your executable.


After running the profiler it stated that I am using alot of Deprecated funcitons ( just like everyone else, it seems)
My question is are these deprecated functions inefficient, causing slowdowns?
I know it takes alot of work to stop using these functions is it worth the hassle?

Most importantly I thought that glEnableClientState() was deprecated and replaced immediate mode.
This recommends that I use Vertex Shaders (which I have no experience with) instead.
Is that how I would bring that function up to date?

*remember these numbers are average # of calls per frame.

gDEBugger Output
deprecated.png

Share this post


Link to post
Share on other sites
Advertisement

*remember these numbers are average # of calls per frame.
[/quote]

My understanding of gdebugger says that those numbers are the total number of calls since the program started, not per frame. Otherwise I really doubt you're calling glOrtho 1000 times per frame :)



My question is are these deprecated functions inefficient, causing slowdowns?
[/quote]

Probably not causing slowdowns in most cases, though without knowing how you're using them its hard to say. Most of all these are deprecated because they use the fixed pipeline, which isn't necessarily slower than using shaders, its just less flexible.

I raise my eyebrow a bit at glBegin/glEnd however, I think there's very rarely a good time to use immediate mode (that's usually pretty slow).

Also if you're looking for perf, maybe take it easy on the enable/disable client state? It does you no good to disable vertex clients and reenable them for every single thing you draw. Try to batch things up so that you can just enable your states, draw a bunch of things, and then disable. Or locally just cache the state so you only switch it when you need to. It may seem like good programming practice to clean up your state after you exit each object.draw() command, but issuing so many commands is expensive for opengl. Each API call that you make has some performance cost, try to weed out what you don't need.



Is that how I would bring that function up to date?
[/quote]

glEnableClientState is superceded by glEnableVertexAttribArray, which works with shaders only.

Share this post


Link to post
Share on other sites
My own preferred approach is to set the required state at the start of each drawing function, through wrapper functions which filter redundant changes. State isn't cleared or reset at the end - a drawing function doesn't (and shouldn't) know about what's going to follow it. It's not always possible to achieve this ideal, but it's worth shooting for and designing with a goal of most of your state changes coming from such a model.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • 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!