The latest TBGL version

This post contains the latest TBGL version with help file.

Added since ThinBASIC 1.8.9.0 release
[A] tbgl_PushLineWidth / tbgl_PopLineWidth, tbgl_PushLineStipple / tbgl_PopLineStipple, bgl_PushPointSize / tbgl_PopPointSize, tbgl_PushColor / tbgl_PopColor, tbgl_PushPolygonLook / tbgl_PopPolygonLook, tbgl_PushTexture / tbgl_PopTexture, tbgl_PushAlphaFunc / tbgl_PopAlphaFunc , tbgl_PushBlendFunc / tbgl_PopBlendFunc, tbgl_PushDepthFunc / tbgl_PopDepthFunc
[A] %TBGL_TEX_CRISPANISO
[A] tbgl_SpriteExists
[I] tbgl_Color - this function can now take optional alpha parameter
[I] tbgl_EntitySetPos, tbgl_EntityMove, tbgl_EntityPush, tbgl_EntitySetRot, tbgl_EntityTurn - These functions can now ommit Z parameter
[I] tbgl_Rect - this function can now take optional parameter to force plane aligned rendering
[F] tbgl_GetFontTextSize - works now for all font slots
[A] tbgl_BindWindowEvent, tbgl_UnBindWindowEvent, tbgl_OnDropFiles_GetFileCount, tbgl_OnDropFiles_GetFileName
[A] tbgl_GetTextureData
[F] %TBGL_TEX_ANISO, %TBGL_TEX_CRISPANISO presume level 2 of anisotropy in case programmer does not specify it.
[A] tbgl_EntityGetTexture
[A] tbgl_PrintFont2D
[I] tbgl_BuildFont - returns font slot
[F] tbgl_GetWindowPos, tbgl_SetWindowMinClient
[F] tbgl_ShowCursor
[F] tbgl_PrintFont, tbgl_PrintFont2d
[A] tbgl_GetFreeTextureIndex

How to install?
The attached ZIP file contains two directories - Lib and Help. Your thinBASIC directory contains these directories as well, so you can simply patch the existing installation with the attached update with no further changes necessary.
To make new keywords recognised in ThinAIR, please run the following script in your installation:
\thinBasic\thinAir\Syntax\thinBasic\thinBasic.CreateSyntaxIni.tBasic

Hi Petr,

what are the changes from the 1.8.6 beta release? I saw that the sprite functions are still in the help file. Are they inside the module too?

Michael

Hi Michael,

the changes are the following:

Fixed:

• issue with TBGL_NewListSpace
• Possible TBGL_Viewport recursive behavior
• Possible problem in M15 rendering if programmer supplies nonsense info :)
• Possible problem in Windows Vista/7 in TBGL_SaveScreenshot

Improved:

• TBGL_EntitySetScale can use 1 to 3 scale parameters

Added:

• tbgl_DisplayGetCount
• tbgl_DisplayGetInfo
• tbgl_SendWindowToDisplay
• tbgl_GetWindowDisplay
• tbgl_PeriodicBindFunction
• tbgl_PeriodicProcessFunction
• tbgl_PeriodicUnBindFunction
• tbgl_PeriodicChangeFunction
• tbgl_PeriodicChangeInterval
• tbgl_EntityGetScale

And of course some internal cleanups and tunning.

I leave the Sprites inside (if it is not problem for you) until we have the separate module ready and documented.


Petr

Thanks for the info,

i am fine with that. Last night I looked at everything and the splitting has more effect than I initially thought about. Mainly because of texture management plus that I own PB8. I wanted to use TBGL's texture loading but then I learned again, that it is just an index you get when you load a texture in TBGL. What I would need to use is the texture handle. :(

So I decided I will completely redo these functions/module/dll. This makes sence when I port it to a different language anyway as my PB8 is outdated. Adding to that I feel that the best result will be a dll with an thinBasic include script so it will still be usable once Eros switches to his OOP based SDK. I probably will do the same with all my modules.


Michael

Hi Mike,

in fact the texture handle = texture ID. On the TBGL initialization, I preallocate 1024 handles using OpenGL for this purpose, which are thanks to this fact numbers 1..1024. So this should not be problem for now. For future I plan to add dynamic texture loading with direct handle return, such as:

Code:

---

handle = TBGL_LoadTexture "Cat.bmp", %TBGL_DYNAMIC, %TBGL_TEX_MIPMAP

---

... so people could get around the whole concept of slots if they don't like it. I liked it in the beginning for the simplicity, but now I am more into dynamic allocations. Compatibility will be preserved of course.

Regarding SDK - if I read the article by Eros correctly there won't be something like switch to completely OOP SDK, but you will be able to use both procedural and/or OOP style.

In future, the whole TBGL could explode to multiple DLLs, and maybe it could provide some functionalities for some module interop, but I need to think about this more in depth.


Petr

Yes, but these handles(slots) are the index of your internal texturelist table. Does this table look like this:

Code:

---


texturelist(1) = 1
texturelist(2) = 2
etc.

---

Or does it look like that?

Code:

---


texturelist(1) = hB5F3
texturelist(2) = hA964
etc.

---

Hi Mike,

like first one. It is strange, but that is how current OpenGL implementations work - the handle is not classic "random DWORD value" but it is growing sequence.


Petr

Quote:

---

Originally Posted by Petr Schreiber

Regarding SDK - if I read the article by Eros correctly there won't be something like switch to completely OOP SDK, but you will be able to use both procedural and/or OOP style.

---

Yes, when introduced it will allow to use PB9x OOP in module and take advantage of that in script.

But this will not substitute current way of creating modules. It will even possible to have both ways inside the same module.
So nothing to change but something to get more if wanted and needed.

So do not worry about that.
Ciao
Eros


PS: Michael, if you need PB9x just let me know. It has really great improvements.

Quote:

---

Originally Posted by Petr Schreiber

in fact the texture handle = texture ID.

---

But there must be a reason why you have this internal table. Could it be that at some point, the table could look like this?

Code:

---


texturelist(1) = 1
texturelist(2) = 5
texturelist(3) = 3
texturelist(4) = 4

---

Quote:

---

Originally Posted by ErosOlmi

Yes, when introduced it will allow to use PB9x OOP in module and take advantage of that in script.

But this will not substitute current way of creating modules. It will even possible to have both ways inside the same module.
So nothing to change but something to get more if wanted and needed.

So do not worry about that.
Ciao
Eros


PS: Michael, if you need PB9x just let me know. It has really great improvements.

---

Thanks Eros about the clarification. So I understand that PB8 will still work? I guess not, as you will have a new thinCore with elements that are available in PB9 only?

Quote:

---

Originally Posted by Michael Hartlef

But there must be a reason why you have this internal table. Could it be that at some point, the table could look like this?

Code:

---


texturelist(1) = 1
texturelist(2) = 5
texturelist(3) = 3
texturelist(4) = 4

---

---

In TBGL -> It should not - before I generated texture handles for fonts first, which made handle offset from the begining. That is why it was handled that way. Now first go the textures and then fonts... so in TBGL, it will match.

But! "Thanks" to this, that TBGL init goes first, in sprites module your texture handles will start at bigger number, not from 1. And as I think of it, it will not be good idea to use fixed size texture list at all. Better to generate new texture handle for each sprite using glGenTextures command.

I can write you "garbage collector" for this if you need. In the end it will be more transparent and I will do such a thing in TBGL as well for the already mentioned "dynamic" approach.


Petr

Hmm,

checking the texture right now... it seems I will add TBGL_GetTextureHandle( slot ) function. Otherwise we would dance on thin edge ... specs say the number series do not have to be consecutive... I did not see such a implementation yet, but better not play with fire.


Petr

Quote:

---

Originally Posted by Petr Schreiber

Hmm,

checking the texture right now... it seems I will add TBGL_GetTextureHandle( slot ) function.

---

I think that is all I need. Than I just have to get rid of the Load functions and can create the sprites from the loaded TBGL textures with the texture handle. Makes my life easier i think.

Quote:

---

Originally Posted by Michael Hartlef

Thanks Eros about the clarification. So I understand that PB8 will still work? I guess not, as you will have a new thinCore with elements that are available in PB9 only?

---

thinCore exposes functions interfaces not related to the version of the compiler with which are built. You can and will be able to create modules with PB8 without any problem even if thinCore is built with PB9 and implements new interface functions.

Of course you will be able to get advantages of new thinCore interface functions only if you will have PB9 that implements COM OOP but this is another story.

So do not worry about your PB8 compiler it will work as usual.

Ciao
Eros

Thanks for the clarification.

Hi,

I added the TBGL_GetTextureHandle function for Mike (I am sorry it took so long), and also included very important fix of aspect ratio related problems in case of custom entity camera with user defined field-of-view, reported by user Bernie.

See the latest version in the first post of this thread, as usually.


Petr

Thanks Petr.
Very soon there will be a new thinBasic release with all libraries updated included.

Just for the naming-conventions, I thought you made TBGL_Periodic's all to start with the same name so TBGL_BindPeriodic..., TBGL_UnbindPeriodic... became obsolete.
Now for the TBGL_...WindowEvent it's the "old way" again - so this is no big problem. I still could exchange in my script and the few downloaders of it probably will understand if Syntax changes before it's out-of-beta-stage ;)

Yes, it was a bit of dilema :)
But all Window related functions take form of TBGL_*Window* (TBGL_SetWindowText, TBGL_ShowWindow, ...), so I followed it with events too.

Both TBGL_BindPeriodicFunction and TBGL_PeriodicBindFunction works. Marking it with obsolete means mostly "do not use in new scripts, it might get removed in future".

Petr

Petr,

I just downloaded the new TBGL version. Is it still necessary
to run the following script: \thinBasic\thinAir\Syntax\thinBasic\thinBasic.CreateSyntaxIni.tBasic

I've already updated my thinBasic.

Bill

yes- I would recommend this if you downloaded from the support. To check for example type in - TBGL_BindWindowEvent - if becomes blue and bold then your thinAir "knows" the new TBGL-stuff already

Yes. Or you can wait for official ThinBASIC 1.9.6.0 release, which will have everything ready.
The TBGL in this thread is targeted for users who need the bleeding edge features.


Petr