Life 3D pseudo - questions.

[RobbeK]

Hi all,

1st attempt - not really 3D, just layered 2D - it's more complex than it seems , a same algorithm on XY and repeated on YZ does not work.
(that's the easy way .. it needs a 1 pass 3D evaluation I think .. maybe later, it's more an excercise learning about TBGL).

But I did notice periodical slow downs during displaying things -- It's probably something else, but at first sight it looks like something caused by incomplete garbage collection ..

I have no idea about memory management under GL , maybe these things are just over the top on my old computer ... ? ( i mean coordinate translations over and over again ? )

Working with spheres (or similar 3D objects) .. this is the best way ?

best, Rob

[Petr Schreiber]

Hi Rob,

when I try to run the code, I get immediate GPF after pressing space key. Is there any chance there could be issue in your O2 code?


Petr

[RobbeK]

Hi Petr,

The exe should run (I even ran it on a Linux distribution), the script not . I think the problem is , it uses the latest oxygen.dll (together with thinbasic_oxygen.dll). Both are in the bundle - on my system it was copied into the Lib folder on 20/10/13 (IIRC Charles gave the download link, after that pow(-2,2)=-4 history ). This same program also did not run with the newer dll. Maybe there's something between thinbasic_oxygen.dll and oxygen.dll that causes this.
I attached the dll's (Not sure they will run from a temp directory for testing when running the script - probably windows uses its registration in the original directory while TB was installed ) -- anyway in any case keep your old dll's to avoid future problems !

best Rob ,

[Petr Schreiber]

Hi Rob!,

thanks to your assistence I could run the code and profile it a bit.

Well, it is quite polygon intensive application - with around 500 spheres, each of them around +/- 1000 polygons, that is tough :)

One of the affecting factors could be vertical synchronization.

Imagine your display refreshes at 60 Hz. If your script is able to compute fast enough to spit 60FPS, or better, it is okay and 60FPS will be produced.
But, if there is performance problem (which might be, with half a million polygons), and you render on slightly less than 60FPS, the vertical synchronization kicks the frame rate to locked 30 FPS.
And if you are not able to render even at 30, it kicks it again to 15, cutting it in half all way down again and again.

So here few tips to improve performance:

use TBGL_UseVSync(0) before main loop, it will prevent dropdowns in speed
use TBGL_SetPrimitiveQuality 12 to decrease the sphere detail
use the following to cache the sphere object:



Long mySphere = 1
TBGL_NewList mySphere
TBGL_Sphere 1.4
TBGL_EndList


instead of TBGL_Sphere 1.4 use TBGL_CallList mySphere to invoke cached geometry



Let me know...

Petr

[RobbeK]

Hi Petr,

I have to thank you again -- every suggestion helped , the highest execution speed increase came from "SetPrimitiveQuality x" -- it doesn't matter if the object is a sphere or a double pyramid ;-)
I even could increase the number of layers somewhat (attached - you have to run the exec again -- I think I'm going to install the older oxygen module again -- this is confusing ... )
I also added terminate into the oxygen script .. maybe useless, oxygen should reallocate memory automatic when leaving , I know , but it will not hurt anything doing so ...

About the program : for the moment there is no vertical interaction ... from there layered 3D .. I had the stupid idea I could split things in 2 passes (horizontal and vertical evalution and then combine them .. I'm not sure it can be done this way .. i have to do some thinking about this ).

thanks for ur kind and expert help , Rob

[Charles Pegge]

One rather obscure problem I encountered with the new ThinBasic_Oxygen is that it can cause a GPF on termination when used in combination with other modules. This only appears to happen when Oxygen is the first module in the list. I think the problem is due to late secondary binding to Oxygen.dll.

So the best workaround, until I nail it, is to ensure that Oxygen is the last module in the "uses" list.

Rob, you may like to try this variation of your program. Instead of calling o2_exec repeatedly, functions are created and linked to thinBasic. Then Oxygen will set up its mappings and global workspace once only - on o2_exec . Thereafter the Calculate function can be called directly with very little overhead. I have marked the changes with '***

[RobbeK]

Thanks Charles !

A lot "cleaner" this way, I think ... is the reverse possible ? (in an easy way - calling TB functions/subs from within Oxygen ? ) -- I would like to do all the TBGL iterations controled by Oxygen ... (is this possible without a TB VM and p-codes ?)
best, Rob

[Charles Pegge]

Hi Rob,

It is not possible to call TBGL functions directly from Oxygen, unlass you can persuade Petr to provide a binary interface, a side-entrance into TBGL :)

But you can use OpenGL functions directly from Oxygen, in sync with TBGL, and do all the high-speed stuff like building shapes and textures on-the fly. I have an example called examples\graphical\psva10.tbasic. It is quite a complex piece, with some useful goods like mouse view-control, and texture synthesis.

This is made possible by the fact that Oxygen is able to operate within the graphics context set up by TBGL, and is also able to read the TBGL headers provided with thinBasic.

[Petr Schreiber]

Hi Charles,

maybe Rob asks about calling ThinBASIC user functions (functions defined in TB code) from Oxygen. They could encapsulate all TBGL stuff inside.
I think there was a such an example somewhere, although there were some specifics regarding parameter passing. And maybe I am confusing it with something else. And maybe Rob meant it as you understood it. Hehe.

Dual interface for TBGL - in theory possible thing (with few issues - how to wrap functions behaving in polymorph way), but not on my list currently. Will see.


Petr

[Charles Pegge]

Hi Petr,

Yes, Oxygen can call TB User functions but it is quite expensive, especially wrapping TBGL calls.

examples\general\O2CallbackTB.tbasic

If you were able to provide a pointer to a table of function-pointers and some form of commented pseudo header. Oxygen would be able to cope with almost any polymorphism, though it may get a bit complex, for the user, if several primitives are used for each high-level TBGL call.

[ErosOlmi]

To me, among other fantastic points, the biggest advance of Oxygen/thinBasic integration is the possibility to compile and execute in memory a dynamic string having some of the data (variables) shared between the two languages.
And this should be exploited to the maximum making dynamic Oxygen scripts compiled on the fly using as many parameters as possible taking them from the main script.

An example can be seen here where I used great script from Rob adding few params: http://www.thinbasic.com/community/showthread.php?t=12258&p=90145&viewfull=1#post90145

[ReneMiner]

And oxygen can perform TBGL-statements "under false flag" too: Just


#INCLUDE "thinbasic_gl.inc"

' within o2-code:
DECLARE SUB TBGL_TexCoord2D LIB "opengl32.dll" ALIAS "glTexCoord2f" (BYVAL tU AS Float, BYVAL tV AS Float)
DECLARE SUB TBGL_Vertex LIB "opengl32.dll" ALIAS "glVertex3f" (BYVAL x AS Float, BYVAL y AS Float, BYVAL z AS Float)
DECLARE SUB TBGL_Normal LIB "opengl32.dll" ALIAS "glNormal3f" (BYVAL nX AS Float, BYVAL nY AS Float, BYVAL nZ AS Float)
DECLARE SUB TBGL_Color LIB "opengl32.dll" ALIAS "glColor3b" (BYVAL red AS Byte, BYVAL green AS Byte, BYVAL blue AS Byte)


and within TBGL_NewList/_Endlist you can let do oxygen the construction of the mesh using fake declared TBGL-Functions in no time flat... :D
(i'm not sure now if it's "float" or "single" in o2 - but Charles can tell) - especially useful when loading data written as Ascii (much faster creating displaylists), so this way you can abuse oxygen as "TB-Interpreter/Translator" - create static meshes/displaylists visual & save them to TB-Code using this (http://www.thinbasic.com/community/showthread.php?t=12060)

[Petr Schreiber]

BASICally yes, just the TBGL_Vertex is actually both glVertex3f and glVertex2f :P


Petr