[gephex-devel] opengl and gephex

[Philipp Promesberger [c]]

Martin Bayer wrote:

> [...]
>
>
>Resources like textures are transfered via id types. E.g a mixer module
>gets two texture buffer inputs and one texture buffer output. The
>resource ids of the output texture can be used to set the render target
>via the gl_core object.
>
>inputs: gl_core, gl_texture, gl_texture, numbertype
>outputs: gl_texture
>
>  
>
>>Thus easy
>>rendering via Input_texture->Set(); and Output_texture->SetActive();
>>will be possible (this would in the case of opengl bind a texture to a
>>certain stage and set Output_texture as an active rendertarget). (this
>>is still just a draft, so thoughts are welcome). 
>>    
>>
>
>gl_core->texture_input_set(in_tex_1)
>gl_core->texture_output_set(out_tex_1)
>
>  
>
I'd really prefer the non-id variant (using a texture class instead) 
over this for the reasons we talked about, that is, it doesn't simplify 
gl at all - instead you have one huge core in the end which does exactly 
the same as opengl. A more object oriented approach would make it a lot 
more convenient to work with systems as opengl or directx. Not that the 
above approach wouldn't work, but IMO it's very c-ish and i don't see 
the advantages over a non-id based handling of gl-dependent objects.

>>Every Module can expect
>>their inputs/outputs to be initalized (Texture(Core*)). (Note: this has
>>to go into 0.5 since this is heavily concerning  the implementation of
>>links).
>>    
>>
>
>Only the gl_core object know the implementation of the resource types.
>It can and must initialize them lacy with the first access.
>  
>
Objects are always dependend on the core making it possible for them to 
initialize themselves at construction time and free their own resources 
upon destruction. A core object (and therefore a (possibly hidden at 
first) renderwindow) is crucial for all objects using opengl and has to 
be treaded special (which it is anyway since it will get connected to 
gl-modules automatically), meaning: be initialized.

Seems like we didn't fully agree after all :)
I propose to leave this up to discussion.
To summarize the two approaches:
(1) Having an object oriented libraries with a thin core wrapping 
hardware rendering functionality with every object in that library being 
dependant on that core.
(2) Having a "monolithic" core that wraps the access to everything in 
relation to any hardware rendering whatsoever.
For (dis-)advantages of both method see the above.

Ah...and the subject was meant to say "gephex and opengl" of course :)

-coma


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