[gephex-devel] opengl and gephex

[Philipp Promesberger [c]]

Hi Manuel,

> [...]
>
>
>hm, maybe i misunderstood you there. do you want to offer the state
>handling via a higher-level c++ interface, or via a (necessarily complete)
>emulation of the gl layer?
>  
>
A higher-level c++ interface.

> [...]
>
>yepp, i guess gl has a somewhat more chaotic state handling mechanism.
>  
>
It has a lots of advantages over DirectX too though:)

>Nice poster to print out and impress your friends: 
>
>	http://www.opengl.org/documentation/specs/version1.1/state.pdf 
>
>might also be of use for the implementation, though :-)
>  
>
I got that...some opengl book featured it...and now that I'm actually 
doing gl, i can finally glue it to the wall :)

>  
>
>>A general way of handling IMHO is anyway: If you want something to be
>>set: set it. After that, you don't have to care about restoring any
>>states. I think that's the most consistent way of doing it.Of course
>>this could include some overhead for the module writer (setting all
>>those states which are "usually" set), but it's a clear guideline to
>>stick to and it's clean.
>>    
>>
>
>yes, one can certainly live with that. if it doesn't mean you have
>to disable everything you don't use (so that e.g. a
>"render-everything-in-a-shade-of-glibberish" pixelshader from
>the previous module won't affect you downstream). i think its
>majorly this (keeping a "barebone" or defined state on entry) which makes 
>the state manager a necessity. 
>
>i am not sure if the glPush{Client}Attrib(GL_{CLIENT_}ALL_ATTRIB_BITS) /
>glPop{Client}Attrib() encompass all (extension) state variables,
>but if so, they could yield the easiest solution to the barebone state
>restoration.
>
>(the following applies only if you do plan to emulate the gl layer:)
>  
>
Again: In DirectX you'd do this naturally (setting 
Pixelshader/Vertexshader)...in GL it seems to be somewhat of a big deal. 
Maybe a glcore::ResetStates()  (Resetting states to their default values 
as stated in the official opengl documentation) is a good thing to have 
if you want to be on the safe side.
Somehow you will have to disable what you aren't using though...since GL 
is a state machine and the core will only cache states I don't see a way 
around this. I have never had problems with this in Directx (where i 
coded a more basic effect framework). Mostly it's the very common states 
you'll set anyway like z-buffering, material states, vertex/pixelshader 
(-constants), transforms, lighting, stencil, alphablending....as a 
ground rule I would propose something like a set of states you do not 
have to worry about. Anything that's not in there is expected to get 
reset after the module is done...so the more "exotic" states won't cause 
any trouble.

>  
>
>>>mix them with video streams. the thing is, this is pure opengl and about
>>>20k loc. [and preferably resides in a shared library] it would be easy to
>>>      
>>>
>>I see where you're coming from. Well... most stuff WOULD have to go
>>through an indirection layer, there's no way around that. Be assured
>>though that generally a query/replace from "gl" to "glcore::core->" will
>>solve 90% of the work :) (that's ought to be case senstitive though ;) )
>>    
>>
>
>i agree that this shouldn't be a big problem for most applications, though
>it could be a bit inconvenient in some cases: if its a externaly maintained
>piece of gl software, you'll have to keep the (query/replace) module version
>in sync with the gl code base. okay, i know, there's sed :-)
>  
>
This is a bit unconvenient, yes...can't think of anything to avoid this 
though...

>but could one possibly set things up so that the modules just links to a
>glcore c-interface instead of "the real" gl lib? in the sense that glcore
>would provide the indirection transparently via c-bindings? sorry if i'm a bit
>clueless about linking issues - probably calls for "multiply defined symbol"
>hell.
>
>void glWhatever(GLint foobar)
>{
>	glcore::core->glWhatever(foobar);
>}
>  
>
I don't think this will work. Feel free to try though :)

> [...]
>
>oh, and i hope my comments don't come over as nitpicking, i just thought i'd
>add my "lazy gl programmer" perspective.
>  
>
No, I'm actually very happy that somebody more experienced with opengl 
than me is participating in this discussion...espcially somebody who's 
planning on using this lib later :)

>  
>
>>>i think i'll have to dive into the gephex code to get a grip of what's
>>>going on in there before i bother you with further discussions ;-) just
>>>need to pass an examination tomorrow (<panik-mode>arghh,
>>>today</panik-mode>)...
>>>      
>>>
>>good luck :)
>>    
>>
>
>thanks! surprisingly, i survived :-)
>
>btw, are there any documents regarding the gephex 0.5 architecture?
>  
>
Not that I'm aware of...you can download the code and look at it or 
search through the gephex-devel archive. But there hasn't been written 
anything "official" :)  (Martin, correct me if I'm wrong here please :D )

I'll update this thread on further progress...right know I'm trying to 
create a prototype module for the 0.4 architecture to see if everything 
planned works out as advertised...then I'll consider seriously designing 
a robust core (the version right now is merely a prototype..although 
most of it can probably be used already)....you're welcome to help with 
that :)

-philipp




--
------------------------ [ SECURITY NOTICE ] ------------------------
To: gephex-devel at lists.gephex.org.
For your security, coma at gephex.org
digitally signed this message on 16 June 2005 at 14:00:41 UTC.
Verify this digital signature at http://www.ciphire.com/verify.
------------------- [ CIPHIRE DIGITAL SIGNATURE ] -------------------
Q2lwaGlyZSBTaWcuAVdnZXBoZXgtZGV2ZWxAbGlzdHMuZ2VwaGV4Lm9yZwBjb21hQGdlc
GhleC5vcmcAZW1haWwgYm9keQAREQAAfAB8AAAAAQAAAAmGsUIREQAAIQIAAgACAAIAIB
+oZ0QQT9njneW0BJbMBFNhWVl5dPLKbVD4NhL1uvURAQCAY+pi9xDkKQY80xF9IH5q1/2
gCQ+37YHuT7nVIQT0MYDwXpPwknhszcg5WXEScLg0ygpac+YnieTvl+h8iGOf2AZFU2ln
RW5k
--------------------- [ END DIGITAL SIGNATURE ] ---------------------