wrapping up those dirty dirty functions

Started by
14 comments, last by fireking 20 years, 4 months ago
quote:Original post by fireking
When you call something like gl.Enable(SOME_CAPABILITY), it will only enable it if its not already enabled.


I would trust the OpenGL libraries already do that kind of things.



[ Start Here ! | How To Ask Smart Questions | Recommended C++ Books | C++ FAQ Lite | Function Ptrs | CppTips Archive ]
[ Header Files | File Format Docs | LNK2001 | C++ STL Doc | STLPort | Free C++ IDE | Boost C++ Lib | MSVC6 Lib Fixes ]
"Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it." — Brian W. Kernighan
Advertisement
quote:Original post by Fruny
I would trust the OpenGL libraries already do that kind of things.

Surprisingly enough, it may not. From the OpenGL.org site (sorry, didn''t catch the HREF):
quote:
The advice in this section is focused on the matrix mode state, but pitfalls that relate to state changing and restoring are common in OpenGL. OpenGL''s explicit state model is extremely well suited to the stateful nature of graphics hardware, but can be an unwelcome burden for programmers not used to managing graphics state. With a little experience though, managing OpenGL state becomes second nature and helps ensure good hardware utilization.



The chief advantage of OpenGL''s stateful approach is that well-written OpenGL rendering code can minimize state changes so that OpenGL can maximize rendering performance. A graphics- interface that tries to hide the inherently stateful nature of well-designed graphics hardware ends up either forcing redundant state changes or adds extra overhead by trying to eliminate such redundant state changes. Both approaches give up performance for convenience. A smarter approach is relying on the application or a high-level graphics library to manage graphics state. Such a high-level approach is typically more efficient in its utilization of fast graphics hardware when compared to attempts to manage graphics state in a low-level library without high-level knowledge of how the operations are being used.



If you want more convenient state management, consider using a high-level graphics library such as Open Inventor or IRIS Performer that provide both a convenient programming model and efficient high-level management of OpenGL state changes.


"Sneftel is correct, if rather vulgar." --Flarelocke
I would trust the OpenGL libraries already do that kind of things.



thats the thing, they dont....
--FirekingOwner/LeaderFiregames Development &Blackdragon Studios
quote:Original post by CraZeE
taking ur point on trapping redundancies, have u considered the additional execution layers involved in wrapping the function into class functions? co assuming u''re wrapping at an extremely low level, such as Vertex(...) to substitute glVertex*, then wouldnt these be true:

1. class functions have an explicit passing of the ''this'' pointer making function initiation ever so slightly slower.


didnt consider that, although i dont think it will be that much of a burden? Any way to specify that you dont want the this pointer? (er actually, its needed in a few places, for checking states)

quote:
2. i dunno if object overloading works anywhere like virtual functions, but i suppose mapping the proper overloaded function could entail a speed hit.


not sure what you mean here...

quote:
3. though these hits are small, but at low levels, they may end up being called enuf times to accumulate their bloat


highly unlikely. The entire point of the class is to prevent unneccessary function calls. I figure thats what a lot of engines do anyways.

quote:
also, thinking about state changes verification, it is a nice thing to avoid state changes when its not already necessary. But that would perform some logic computation which would usually be quick. but are state changes really THAT taxing to make this necessary versus verifying?

just curious


it is definately necessary to keep track of the state changes on your own. If you design your entire engine so that it never binds the same texture twice, then kudos to you because you just did what everyone is trying accomplish. This is one way of doing it (kind of). Im not that great at programming, most smart people will be able to admit that (because programming is so vast). If i was carmack, i wouldnt be asking/talking about stuffs like this here, because I''d already know . But since I dont, i come here to express my ideas. If you can find good reasons why my ideas aren''t good ideas, I appreciate you telling me. All of you .

I''m beginning to think that writing a shadow function for every single gl function there is, tis a big rediculous, so im currently re-evaluating how I should accomplish this elegantly. But the ideas ive already expressed are definately good ones. The state watching, and the function overloading is ok. Im just not so sure if i should wrap EVERY function. I need to take a look at all the functions, as a whole, and figure out which ones would be the best ones to wrap. The ones that should not be wrapped should just be inlined (copy the original gl function), because you still want to have everything localized. (you dont want to call gl.Vertex at one place, then call glBlendFunc somewhere else).
--FirekingOwner/LeaderFiregames Development &Blackdragon Studios
oh and to clear something up

the state query is fast, all states are stored in a boolean array. The array is synced once (at start up). Then, from there on, when you enable or disable something, we dont ask opengl if its enabled, we refer to our array. The array is completely accurate this way (you dont have to ask opengl, because you keep track of it accurately). Since its synced once, all states are accurate from the get go. The class keeps track of it from then on. Wanna know if something is enabled, just call GetState(state), which returns states[state]''s value (true or false).
--FirekingOwner/LeaderFiregames Development &Blackdragon Studios
also consider this->

http://msdn.microsoft.com/library/en-us/dnopen/html/msdn_gl3.asp
--FirekingOwner/LeaderFiregames Development &Blackdragon Studios

This topic is closed to new replies.

Advertisement