Textures...

[ReneMiner]

upcoming changes in mind i think about textures and i think would be useful to have some built-in-pool that will avoid loading the same texture multiple times into memory.
Textures only have one real property that can be requested: containing the filename where it was loaded from.
This of course not if texture is made any other way - as from a string or due render/draw to texture-methods.

I think a very foolproof way were, if the future TBGL-Engine would not allow the user simply to use any texture-slot by native (type/class-) methods but the engine will assign automatic a free slot and return the number or in case the same texture is already loaded- just reload it - perhaps user changed it with a drawing progam... and return the slot where it's located - instead of loading it twice into graphics memory.

Users might request a free slot to render or draw/store screenshot onto etc. anytime.

Instead of having a filename the slot should know it's "freestyle" now, occupied - until released by user again- or it becomes a filename by built-in save-methods.

I know - it could reduce the infinite opportunities to a few less than infinite - but it makes coding much easier & faster and more foolproof.

[ReneMiner]

the most of the above i have solved already...

Because Textures are big chunks of data mostly it should be avoided to pass these huge amounts of data Byval repeatedly from one function to another to the final destination.

Currently still fighting the user-defined textures-stuff & optional buffers...
What i miss were some equivalent to TBGL_MakeTexture which instead of a string just wants the position of the data as



TBGL_MakeTexturePtr pData, TypeOfData, Width, Height, TextureIndex, TextureFiltering [, AnisotropicLevel [, TransparentColor ]


so not to have to Memory_Get(pData, Heap_Size(pData) ) and to create another string of the data wich is already present at pData.

Also size of data is known to TBGL = TypeOfData * Width * Height

nice side-effect were: it would also accept stringpointers.

[Petr Schreiber]

Hi Rene,

passing huge strings byVal is of course performance killer, but once you define it as byRef, it is internally just about passing pointer - so super fast.

Many good ideas here. TBGL already checks, whether texture is already loaded, and if that is the case, it does not load it from disk.


Petr

[ReneMiner]

Yes, concerning already loaded texture- my approach were simply to have a



TBGL_TextureReload(Index)


in case user wants to reload a maybe edited texture.
Filtering & Aniso-Level, as well as transparent colors and filename of course - would be assumed to be the same.

[ReneMiner]

thinking of passing "dynamic string" byref, the problem is, one has to



Local myData As String = Memory_get( pMem, SizeInBytes )

- so it creates and allocates a local string that contains a copy of the memory before i can pass it ByRef.

but if one could do this



String toMemorize = "hello world, this is a string of data"

' place a DWord containing the length in front as a real stringpointer has
Dword pMem = Heap_AllocByStr( MKDWD$(Len(toMemorize)) & toMemorize )

' tell thinBasic to treat this as a dynamic string

Local myData As String At pMem + SizeOf(Dword)

' now could pass virtual dynamic String myData ByRef without having to create a copy each time

restriction were the content of virtual dynamic string can be read only

[ReneMiner]

back to textures and a simple question:

I can set a texture to a slot in TBGL. Now TBGL copies the data and places it somewhere to GPU-access and gets a pointer for this?

If i knew the textures dimensions and the pointer where they are - can i manipulate the texture-data (in its current dimensions of course) directly by placing some virtual TBGL-TRGBA-grid upon to set certain pixels without having to re-pass the whole texture again?

Is there a way to retrieve that pointer? Could functions as load- and makeTexture return this pointer when a texture gets created? Or could a function as TBGL_TextureGetPtr(texIndex) do it?

[Petr Schreiber]

Hi Rene,

it is possible to update just part of the texture, there is OpenGL function for it, so could be added.

I was processing the eclipse images (http://www.thinbasic.com/community/showthread.php?12550-Full-Solar-Eclipse&p=91926&viewfull=1#post91926) in TBGL and realized how less-than-optimal the support for image formats and manipulation is in ThinBASIC.
We have some TImage module, but it is still not what I need. What do you think about cooperating on separate module for easy image format handling?

We could use this as a start point, and then adjust TBGL, or TBGL-Next, to take advantage of it. To keep everything modular.

Before starting coding, we would iron out the whole specs, to make sure the thing makes sense in highlevel view. I would be okay with support of Windows XP and newer.

Let me know, if good, we could setup GitHub project.


Petr

[ReneMiner]

thought-collection:

Yes TImage & freeImage are not giving a native feeling on use.
Perhaps a GL-textures-module can make use of GDIp-functions
WinXP were ok for me since no older windows-software than this will run on my pc.
Users of Win98/ME still can refer to last official stable release 1.8.9,
i guess the new thinBasic + OpenGL 4.5 and higher is too much for their single-cores to handle anyway.

It would allow us certainly to have native *.png as a texture.
A compressed, lossless format that allows an alpha-channel - a real alternative for uncompressed *.tga which equals *.bmp in size.

A simple own texture-format to enable manipulating, saving and reloading of textures



Type tTexturedata
DataFormat As Long ' Value %TBGL_Data_BGR[A] etc.
' could be also in filename-extension of saved data

Width As Long
Height As Long

sTexture As String

[sIdentity As String] ' filename mostly. If not created from a file then this might hold a date-time-stamped default-name
[Changed As Boolean] ' False if data equals data on disk

End Type


could set .DataFormat *= (-1) to signalize .sTexture is in zipped condition.

Also a few built-in DrawTo-textures-functions that can not be achieved by RenderToTexture currently, for example
FloodFill(X, Y, R, G, B [, A, Tolerance, Opacity])
AddColor(R, G, B [, A] )
MixColor(X, Y, R, G, B [,A, Opacity] )

[Petr Schreiber]

Rene, great!

Instead of forging the API first, maybe we should put together wish items in general.

Image lib
- wide image support format (PNG/JPG/BMP for a start should be good)
- loading ... and saving too
- easy BGRA, BGR retrieval
- per pixel operations (add, mix, fill, maybe some more)

Texture lib
- texture upload from file
- texture upload from memory
- sub texture update
- texture download
- easy resource management, no more IDs!

Let me know of more ideas...


Petr

[ReneMiner]

away from sprites i saw it needs this when creating my last 2d-game



' -------------------------------------------------------------------------
Sub TexturedRect(ByVal TexID As Long, _
ByVal X As Long, _
ByVal Y As Long, _
ByVal width As Long, _
ByVal height As Long )
' -------------------------------------------------------------------------

'[?] If width < 1 Or height < 1 Then Exit Sub Or draw into other direction...
'[?] width -= 1 (X1, X2 thinkeable too)
'[?] height -= 1 (Y1, Y2...)

' function could have an optional parameter telling if width or X2 is meant
' or 2 Functions: "TexRectPos, TexRectSize"
' or stick to pos and user always has to pass "pos+size-1" if needed

TBGL_PushState %TBGL_TEXTURING

TBGL_BindTexture(TexID)

TBGL_BeginPoly %GL_QUADS
TBGL_TexCoord2D 0, 0
TBGL_Vertex X, Y + height
TBGL_TexCoord2D 1, 0
TBGL_Vertex X + width, Y + height
TBGL_TexCoord2D 1, 1
TBGL_Vertex X + width, Y
TBGL_TexCoord2D 0, 1
TBGL_Vertex X, Y
TBGL_EndPoly

TBGL_PopState


End Sub


Probably could be a default-textures-function to simply draw it 2D at given coords in given size :)