[gephex-devel] opengl and gephex

[Philipp Promesberger [c]]

Martin Bayer wrote:

> [...]
>
>You need a way to create a new texture if it isn't yet initialized. And
>initialization is only possible with a pointer to the gl_core object.
>And this object is only available at update() time.
>  
>
For 0.4 I can see a variety of solutions to this.
For 0.5...what speaks against making it possible to construct links with 
parameters (and if it's just a void*)? I don't know the current 
design/implementation state very well so I can't know if this is 
conflicting completely with what has been done so far. I can picture 
this being useful for other (more complicated link types) too.

>1.) you can wrap all methods in something like that.
>
>if( in_text_1->is_valid() )
> core->create_texture(in_text_1)
>in_text_1->set_output()
>
>2.) call the methods indirect via the core
>
>core->texture_set_output(in_text_1)
>
>core can do the lacy init work for you and delegates the method call to
>the (new) object
>
>core::texture_set_output(in_text_1)
>{
>  if( in_text_1->in_valid() )
>    create_texture(in_text_1)
>  in_text_1->set_output()
>}
>
>3.) add the core pointer to all texture methods:
>
>in_text_1->set_output(core)
>
>You can then implement the lacy init stuff in the set_output method of
>the texture object.
>
>
>  
>
I suppose (1) should say if ( !in_tex1->is_valid() ) ? Otherwise I don't 
get it. Where exactly is this check going to happen? Do you want to 
leave this up to the plugin coder?
However, I do not really like any of these methods. Method 2 is directed 
towards a HUGE core interface. Of course this is just the interface to 
the plugin coder, but this is exactly what I don't like about it. As a 
new plugin coder I would certainly not be attracted by an architecture 
like that
Method 3 is a bit better, but i would have a check/lazy init in EVERY 
method of EVERY class I code? No way.

Please consider changing the linktype design in a direction that is more 
flexible. If opengl is about to be integrated into gephex it's gonna 
become a very important part....and all these methods proposed above 
look to me as if we were about to hack this into gephex at a very late 
point and therefore have to make it comply to a design that has already 
been implemented and can't be changed easily.
I don't say i want to enforce this, I just ask for consideration or an 
explanation, why this could not be done.

Thx.
-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 16:59:46 UTC.
Verify this digital signature at http://www.ciphire.com/verify.
------------------- [ CIPHIRE DIGITAL SIGNATURE ] -------------------
Q2lwaGlyZSBTaWcuAVdnZXBoZXgtZGV2ZWxAbGlzdHMuZ2VwaGV4Lm9yZwBjb21hQGdlc
GhleC5vcmcAZW1haWwgYm9keQCYBwAAfAB8AAAAAQAAAIIYq0KYBwAAowIAAgACAAIAIB
+oZ0QQT9njneW0BJbMBFNhWVl5dPLKbVD4NhL1uvURAQCAY+pi9xDkKQY80xF9IH5q1/2
gCQ+37YHuT7nVIQT0MXcUfEZVmNhU8MgHhhTazadmhulQCBiuRoPNQkOFtQcdys3MU2ln
RW5k
--------------------- [ END DIGITAL SIGNATURE ] ---------------------