Objectification TBGL suggestion by Rene

[ReneMiner]

OK...
TBGL improvement for me would mean to split all those different sections into objects. Like
TBGL.Sprite.<member>...
TBGL.Entity.<member>...
TBGL.Window.<member>...
TBGL.Displaylist.<member>...
TBGL.Matrix2d.<member>...
TBGL.Matrix3d.<member>...
...

where member is a property or method of course.
Even enumerations and/or constants could exist in dot-notation.

And once thinAir knows how to autocomplete when user types a dot, coding will be much easier too. It saves a lot of time if the user gets presented a list of possible options instead of searching through documentation for correct spelling or keyword-order.
Was it

TBGL_GetMouseButtonLeft
or
TBGL_MouseGetLeftButton
or
TBGL_LeftMouseButtonGet
or
TBGL_MouseButtonLeftGet
or just
TBGL_GetMouseLButton...?

Dot-notation + autocomplete would make it easy.
And once we have the correct order we still can check help - without further search - for required parameters.
And of course to have an eye on the logic order in future.
-TBGL first anyway
-Library second ( i.e. Entity, Window, Mouse...)
-[Property], [Sub-properties]
- Method in the end

To read left mousebutton it would mean

If TBGL.Mouse.Button.Left.Get Then ...

or just

If TBGL.Mouse.LButton Then ...

Since .Set is not doable logically from within code as a method but by the users finger on the mouse.

Anyway, thanks for the module, I had lots of fun using it.

[Petr Schreiber]

Hi Rene,

interesting ideas as always

I do like the concept, although the same benefit as you mentioned could be achieved with pure procedural approach, just having the part of name in "correct" order.

I like the object oriented approach as a concept, however, while it can be tempting to separate everything via dot, it can have significant overhead, as I mentioned in my article on UDTs.

I will think about it more.


Petr

[ReneMiner]

OK, too many dots will slow things down. I understand that.
But anyway if it's objectified and i

Dim win As New TBGL.Window
Dim Player As New TBGL.Entity

We save one dot already

I will not call
TBGL.Entity.Rotate(Player,x,y,z)
(What nonsense!)
But
Player.Rotate(x,y,z)

[Petr Schreiber]

I agree, it would make a lot of sense for scene-entity system.

Currently, TBGL grew a lot in size, I would like to split it to smaller parts - something like small core + entity system, model system and so on as optional parts.

All of that while preserving backwards compatibility.


Petr

[ReneMiner]

I fear backward compatibility will make the module bigger than it is now. And as your idea to include only the needed libraries like entity, displaylist or sprite it would mean to have like a

TBGLCore :
window and basic functionality only
and the user has to include what he needs like
TBGLSprite
TBGLEntity
TBGLDL - display list...
TBGLM15
...
That would keep the used memory as low as needed and for backward-compatibility - old scripts - will still include classic TBGL.

The advantage would be it were possible to add future extensions without touching the current ones. Maybe TBGLObj- or TBGLNif- model system

[Petr Schreiber]

No bloating of the original DLL, basically as you write - the newly designed components can be added via separate DLLs. I think I already posted regarding this decision.

My vision is to perform smooth, yet painless transformation for the current users.

TBGL will dissolve from one monolith to thin TBGL Core + optional components.

As long as you use uses "TBGL", you will get the classic TBGL, and new redesign will be avialable for example as TBGL.Core, TBGL.SceneSystem and other modules.


Petr

[ReneMiner]

Yes that's what I imagine too. A core-engine-object providing several extensions and being expandable with things that we don't know yet. We can add those in future without touching the core nor bloating the module itself. It's up to the user to include the new stuff if he wants or needs it. He's not condemned to include m15-models if he wants to use 2d-sprites only nor will he be forced to include scene + entity-system if he wants just an in future possibly added "isometric 2.5d-sprite-library" or whatever we don't have yet...

Give them Lego to play with