TBGL 2.0.0 (WIP) range of vertices ?

[Petr Schreiber]

Hi,

I have developed new TBGL, but it will be shipped probably not sooner than in month.

New features are:

TBGL_m15DefBoneAddVertex ' This afternoon :D - thanks for reminding me of that Mike !
TBGL_m15DefBoneAnchor ' This afternoon :D
TBGL_m15DefBoneReset ' This afternoon :D

TBGL_SetWindowTitle

TBGL_GetWindowKeyOnce

TBGL_m15SetVertexTexN
TBGL_m15SetVertexTexXY
TBGL_m15SetVertexTexX
TBGL_m15SetVertexTexY
TBGL_m15SetVertexX
TBGL_m15SetVertexY
TBGL_m15SetVertexZ
TBGL_m15SetVertexPStop
TBGL_m15SetVertexR
TBGL_m15SetVertexG
TBGL_m15SetVertexB
TBGL_m15SetVertexLayer
... and few more model stuff

As this way it was possible to get/set value(s) of only 1 vertice at time, so it was quite loop intensive sometimes, I introduced extension to be able to set "range" instead of value.

But it has one big ... but :)

If index is negative, it is considered range.
To specify range, you should use -MAKLNG( lowerIndex, higherIndex ), which will convert this range to LONG value, from which I will extract limits using LoWrd and HiWrd internally.

But this way the range is limited to have minimal value 1 and maximal 65535.

So I have two questions -
* Is this way of range definition ok for you ? ( this way I will keep constant number of parameters, so good for speed )
* Is maximum of 65535 vertex index in range stuff problem for you ? ( you can access higher indexes just individualy )


Thanks,
Petr

[ErosOlmi]

Petr,

making limits is not nice so spending some more time is worth.
What is an example of syntax? Is it possible to pass 1 parameter plus another optional param? If only one param it will be single point. If 2 param they will be range.
This is possible with thinBasic parsing facilities.

Ciao
Eros

[Petr Schreiber]

Hi Eros,

you are right.

My idea was following...

Classic syntax is like:


TBGL_m15SetVertexR( %MYMODEL, 1, 255 )


With range ( 1 to 100 ) it would be:


TBGL_m15SetVertexR( %MYMODEL, -MAKLNG(1, 100) , 255 )


... so the same number of parameters = possibility to use thinbasic_parse3numbers( model, index, value ).

But I can go the classic parsing way, it would be little bit slower, but probably not so much.
You are right about limits...


Thanks a lot,
Petr

[ErosOlmi]

Petr,

I have an idea of a new aditional interface function: thinBasic_ParseXNumbers
This function will accept up to 6 extended passed BYREF and will return a number indicating how many numbers parsed.

So something like:

nFound = thinBasic_ParseXNumbers(MinNumToFound, Num1, Num2, Num3, Num4, Num5, Num6)
If nFound = 3 then
'...
elseif nFound = 4 then
'...
else
'... error
end if

thinCore will be responsible for generating a runtime error if nFound will be less than MinNumToFound otherwise module will be responsible to generate an error.

What do you think?
Eros

[ErosOlmi]

Petr,

see attached file. Check thinCore.inc file and look at thinBasic_ParseXNumbers function.

You should call something like:


dim nFound as long
dim Num1 as ext
dim Num2 as ext
dim Num3 as ext
dim Num4 as ext
dim Num5 as ext
dim Num6 as ext

nFound = thinBasic_ParseXNumbers(3, 4, Num1, Num2, Num3, Num4, Num5, Num6)
if nFound = 3 then
'...Call single vertex change and get Num1, Num2, Num3
elseif nFound = 4 then
'...Call range vertex change and get Num1, Num2, Num3, Num4
end if


Where 3 is the min number of params and 4 is the max number of params.

So your module function syntax will be double like that:


TBGL_m15SetVertexR( Model, Vertex, R)

or


TBGL_m15SetVertexR( Model, StartVertex, EndVertex, R)


I've not tested. Please let me know if it works.
Eros

ADDED: attach removed. New and fixed features now present in current preview release.

[kryton9]

Petr, the new version sounds exciting. It looks like Eros and you have ironed out the questions you had. Thanks for the progress report and also the insight into what is coming!

[Petr Schreiber]

Huh,

it seems I remained logged in for whole night :-[

Eros, this is exactly what I would like to have!
There is little problem - it seems to return 0 always to nFound,
but maybe I am doing something wrong ?



SUB EXEC_TBGL_m15SetVertexXRange()
DIM nFound AS LONG
DIM Num1 AS EXT
DIM Num2 AS EXT
DIM Num3 AS EXT
DIM Num4 AS EXT
DIM Num5 AS EXT
DIM Num6 AS EXT

nFound = thinBasic_ParseXNumbers(3, 4, Num1, Num2, Num3, Num4, Num5, Num6)
MSGBOX STR$(nFound)+STR$(Num1)+STR$(Num2)+STR$(Num3)

END SUB





thinBasic_LoadSymbol "TBGL_m15SetVertexXRange" , %thinBasic_ReturnNone , CODEPTR(EXEC_TBGL_m15SetVertexXRange ), %thinBasic_ForceOverWrite


Parameters are read correctly ( their values ), but nFound is reported as zero.
Also PB/IDE was angry that line with "DECLARE FUNCTION thinBasic_ParseXNumbers " in thinCore.inc is too long, I just splitted it on multiple lines to make it work.


Thanks,
Petr

[ErosOlmi]

I'm checking ...

[ErosOlmi]

My fault.
I didn't assign number of found numeric expression to FUNCTION return parameter.
Get new version here with also thinCore.INC fixed.

Let me know.

Also consider thinBasic_ParseXNumbers function automatically check if parens are present or now
IMPORTANT: I'm considering to delete interface functions thinBasic_Parse*NumbersAndParens because I will add parens checking to thinBasic_Parse*Numbers

Eros

ADDED: attach removed. New and fixed features now present in current preview release.

[Petr Schreiber]

Hi Eros,

works great, karma up :D


Bye,
Petr

[ErosOlmi]

Do not be stressed by karma.
I was just joking in the other post ;D

Anyhow, Karma + Karma motivation is a nice feature of this forum.

[ErosOlmi]

Petr,

I've modified a little interface function thinBasic_ParseXNumbers. See thinCore.inc
I've added some internal tricks using pointers to EXT instead of passing EXT BYREF and seems possible to pass only the parameters you need.
As you can see from new declaration from Num2 to Num10 all variable are OPTIONAL so you need to pass only the max number of parameters you need and not be oblidge to pass all variables even if you do not need them.

In declaration you can see BYREF EXT parameters but internally they are considered as BYVAL EXT PTR. From a compiler point of view they are the same but from a programming point of view an OPTIONAL BYVAL EXT PTR is much better because I can test if it is passed or not while an OPTIONAL BYREF EXT cannot be tested because immediatelly GPF if not passed.

Anyhow, let me know if it still works because if all is ok I have intention to make some nice interface additional functions that will let you spend less time and less lines in making modules.

IMPORTANT: see latest help file on what's new and DEPRECATED functions. TBGL seems using some of the functions I would like to remove, so please substitute them with the one I suggested when you will have time.

Ciao
Eros

[Petr Schreiber]

Thanks,

I will change TBGL to meet new standard :), although I am not 100% sure which parsing functions now became obsolete.


Bye,
Petr

[ErosOlmi]

Sorry, there is an error in help.
All interface functions whose name is thinBasic_Parse(x)NumberAndParens with (X) number from 1 to 6 will be removed.
Move to equivalent thinBasic_Parse(x)Numbers that will already parse the presence of any ( or )

Mike, please check also into TBDI module.

Thanks
Eros

[Petr Schreiber]

Now I see,

thanks a lot Eros, correction is done.
I will send you modified ( but just current version ) TBGL on email to be ready to go with next thinBASIC.


Bye,
Petr