Sign in to follow this  
coderWalker

Deprecation?

Recommended Posts

coderWalker    127
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.
[b][i][size="2"]To anyone else attempting to use gDEBugger[/size][/i]
[/b]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 [b]alot [/b]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 [b]per frame[/b].

[b][i]gDEBugger Output[/i][/b]
[img]http://webstrand.comoj.com/pics/deprecated.png[/img]

Share this post


Link to post
Share on other sites
karwosts    840
[quote]
*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 :)


[quote]
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.


[quote]
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
mhagain    13430
My own preferred approach is to set the required state at the [i]start [/i]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

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this