The latest TBGL version

[Petr Schreiber]

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

[Michael Hartlef]

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

[Petr Schreiber]

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

[Michael Hartlef]

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

[Petr Schreiber]

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:

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

[Michael Hartlef]

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

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

Or does it look like that?

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

[Petr Schreiber]

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

[ErosOlmi]

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.

[Michael Hartlef]

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?

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

[Michael Hartlef]

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?