tbgl_createWindowEx vs USES "tbgl"

[DirectuX]

keywords like tbgl_UseTexturing and tbgl_UseAlphaTest are not effective right after USES "tbgl".
They began to be taken into account only after tbgl_createWindowEx.

• Is there a reason why we could not 'prepare' settings , then create the view ?
• Suppose we destroy the window and recreate one another, are all settings lost ?

[primo]

Hi DirectuX, this reminds me of the Petr advice "you must perform the Declare Set Address once you have active OpenGL context, that is, after TBGL_CreateWindowEx" https://www.thinbasic.com/community/...ll=1#post95191
whatever the OpenGL context means , it seems specific to opengl. in contrast the constant Pi is ready when we say Uses "Math" but not opengl.
if you don't have there is a collection of nice programs here to test opengl:
zzzhttps://www.thinbasic.com/downloads/thinBasic_Bonus_Packs/TBGL_BonusPack_1_8_0_0.zip
zzzhttps://www.thinbasic.com/downloads/thinBasic_Bonus_Packs/TBGL_BonusPack_Pro_1.4.0.zip
just remove the zzz so not to make a hot linking
a nice alpha test is in example TGA_masking inside the first BonusPack

[DirectuX]

Hi Primo,

thanks for the answer. Thanks for the bonus packs, I knew them already from this website's upper menu
I would understand your answer about opengl if we where dealing directly with opengl, but since we use a wrapper, and a fortiori here, since we have only one opengl instance/context, I thought it could handle settings internally then apply them when needed; like we can do when programming udt way. Note that tbgl_UseTexturing and tbgl_UseAlphaTest are just switches, they do not perform any action. In that, they could be set at any time.

[Petr Schreiber]

Hi Sebastian,

all the states modified by TBGL_Use* function are bound to underlying active OpenGL context.

This is why they are valid only between window creation and destruction.

I kind of prefer the fact TBGL_CreateWindowEx gets you to some standard state.

State management is one of my most disliked aspects of OpenGL, this is why I came up with TBGL_PushState/TBGL_PopState as first reaction to it, but I would like to think about something even better, as even this alternative approach is not very good. No ETA, as I am currently overloaded at work.


Petr