The silence inside the fractal - GBuffers (how many may be used ?)

[RobbeK]

Hi all,

Still investigating some things.
All measured on the change in orbit value -- some insides (red) amazingly flat, others not (though the scale of the reds = 5000x the one of the greens (outside). (lowering the iteration number, gives them more relief).

2-3 GBuffers over the top ?? (it's handy to have certain values in different arrays - and as the arrays are already there, so ... )


best, Rob

[Petr Schreiber]

Hi Rob,

don't be afraid to use multiple GBuffers, they are the most optimized geometry element in TBGL (at cost of restricted flexibility).
In computer games, it is not rare to process tens-of-thousands of GBuffer-like objects on GPU... so keep adding :)

There is trick you might want to try:

Add the following after Uses:


%GL_POINT_SMOOTH = &H00B10
Declare Sub glEnable Lib "opengl32.dll" Alias "glEnable" (ByVal cap As DWord)


Add the following after TBGL_BindCanvas:


TBGL_PointSize(5)
glEnable(%GL_POINT_SMOOTH)
TBGL_BlendFunc(%GL_SRC_ALPHA, %GL_ONE_MINUS_SRC_ALPHA)
TBGL_UseBlend(TRUE)


It should make the points big and round. Sadly it does not work 100% on all implementations of OpenGL, that is why it isn't added as native to TBGL.
But worth a try, the worst you can get is the points remain rectangular...


Petr

[RobbeK]

Hi Petr,

A lot of cubes (infact more something like squares?) here - not a nice look ;-)
Gbuffers, good , great - they avoid a high number of interpreted iterations (20000 in this case). That's very good news, with O2 it's possible to write lightning fast routines on those arrays - (making slices etc ... whatever).

thanks again
Rob

[Petr Schreiber]

Yes, that is sadly the issue I was talking about.

You can see how it looks on my PC in the attachement.

Similar effect could be achieved via billboarding and entity system, but it wouldn't allow that fast updates.


Petr

[RobbeK]

Hi Petr,

Yep, I got floating quads ;-)

Program is more respectable in the mean time ....
for my Timer exam ;-)


regards Rob

[mike lobanovsky]

Gentlemen,

I'm sorry to say but neither of these scripts shows anything on my screen under XP Sp3. thinBasic launches but no window is seen and the CPU load is approx. 75%. 2 instances saturate the CPU at 100% and the processes can only be killed from my Task Manager with great difficulty.

I've got the latest nVidia drivers and TB and I've also installed the "bleeding edge" TBGL as Petr suggested.

:(

[Petr Schreiber]

Hi Mike,

everything works here with latest TB & TBGL. I will try to update to the last WHQL Nvidia drivers now and see, if it might cause problem.
Does the metallica sample still run okay for you?


Petr

EDIT: Tested on Win7 and Win8 PC, no issues observed. Mike, can you launch the script in ThinAir and try to step it via F8 debugger? Searching for XP based PC in the meantime, stay tuned.

[RobbeK]

Mike , Petr ...

FWIIW the bundle doesn't run on my wife's laptop either - XP SP3.
Older bundles (containing the modules ui , O2 (older) , TBGL (older) do run)

Furthermore, after the latest code attempted to run , the older ones also give up (DLL's still active ? - why are these not replaced ? (in case))

best Rob
(Running Win7 Ultimate).

Petr, if you run Win7 can't you switch to "XP mode" compatability or is that just an emulator ?

[Petr Schreiber]

Thanks Rob!,

that sounds serious, I arranged possiblity to test on XP PC tomorrow. I hope to see to discover what causes the problem.


Petr

P.S. Running in XP mode on Windows 8 does not cause any problems.

[mike lobanovsky]

Thanks Rob!, that sounds serious

Didn't that sound serious when reported by me, Petr? ;)

[Petr Schreiber]

Not. At. All. <trying to keep poker face> :D

I am currently waiting for XP machine owner to... wake up.


Petr

[Petr Schreiber]

Okay,

I used Fractal Invest B0 and FractalInvest as test scripts.

I performed the following tests on Windows XP based PC:

Installed clean ThinBASIC 1.9.11.0

Script hangs on O2_Exec


Updated with new Oxygen

Script hangs on O2_Exec


Updated with latest TBGL

Script hangs on O2_Exec




I attach screenshot from the debugger and at this moment I am contacting Charles about the issue.


Petr

[mike lobanovsky]

Thanks Petr,

Looking forward to Charles' comments.

Cheers,

[Charles Pegge]

Hello all,

I don't have an XP available, but I think the problem is procedural order:

This is how it should be:

Dim px , pc As Long


O2_Basic o2
If O2_Errno Then
MsgBox 0, O2_Error
Stop
Else
O2_Exec
End If


Declare Function compute() At pc
Declare Function bye () At px

...

' <Any note here. Breakpoint will be set to line following this statement>
'O2_Exec
[B]compute()

...

bye()

Try the modified FractalInvest below:

[mike lobanovsky]

Sorry Charles,

Still doesn't work under XP Sp3 here even after a cold reboot.

:(

[Charles Pegge]

Have you had XP problems with any other thinBasic/Oxygen examples, Mike?

[RobbeK]

Hi Charles, Mike , Petr ...

I mixed up to code somewhat (without cleaning) .. I started with the idea that a compile with linked functions would generate valid links for TB , when I got the TB message there was no valid function at that specific address, I changed into that the function was called from a O2_exec. (I inserted the main compute() at the tail of script)
Probably I'm overlooking that the O2 code also needs one run-time to set up the correct linkage for functions marked for linking. (I tested this now, corrected it and saw where I was mistaken).
Nevertheless the code runs on Win7 and > -- so it's something beyond.
I tried to run it on 1.8.9.0 , but it hangs "somewhat" , it only gives one GBuffer content - the red dots are gone, and there are some other mistakes, after a while resulting in a crash ...

best Rob

[mike lobanovsky]

@Charles

There are no pure TB samples from the 1.9.11 distro that don't work for me. But many Oxygen samples either start or end with an error code and many report syntax errors too. I'm sorry to say that this was happening rather often in the past two or three years.

Surprisingly, SampleScripts\Oxygen\Graphical\GBuffers_TexCP6.tbasic works! :D

@Rob

Have you moved onto Win 7 permanently?

Regards,

[Charles Pegge]

All the samples included in \Oxygen\ should work in XP and above, with the most recent Oxygen. There are no Vista or Windows7 specific dependencies. But a number of earlier examples have breakages due to changes in syntax during the course of development.

Latest:
http://www.thinbasic.com/community/showthread.php?t=12175

[mike lobanovsky]

Yes Charles,

I guess they should but they don't. The package that you pointed me to (thanks!) contains just a handful of examples all of which work fine with the new 400K Oxygen.dll.

But the official TB 1.9.11 package contains a hundred times more O2 examples and very many of them fail with both old and new DLL alike in almost every subfolder from A to Z. I am not picking fleas (or whatever a similar notion in proper English is), I'm just pointing out there is an inconsistency in how the code behaves under XP and Vista+.

All versions of Fractal Invest crash XP badly with either old or new set of Oxygen.dll and its dependencies, and that's exactly what Petr asked me to do, i.e. report bugs whenever I see one. If you don't want me to, I won't.

May I ask the moderator to kindly move this polemics into the official Bug Report Section of the site please, as a last favor?

Kind regards,

[Charles Pegge]

Yes, I see all the old examples in the thinBasic package now. I think we need to drop all of them, and just distribute the new set.

Anyway, if all the new graphical examples work on you system, Mike, then that greatly diminishes the possibility of an XP-specific bug in Oxygen, and the problem lies somewhere within the FractalInvest script.

[mike lobanovsky]

Exactly, Charles.

For example, the TB distro's noise doesn't work with either DLL for me. The both GBuffers samples do work with either DLL. The new noise sample works with the new DLL only.

Unfortunately, Fractal Invest GBuffers don't work at all.

[Charles Pegge]

It will have to be a process of deconstruction:

The TbMain function encapsulation is redundant since the FractalInvest script already contains main-code outside of it.

These 2 lines can be commented out
'Function TBMain()
...
'End Function


PS:

Also replaced some more o2_exec with compute. I missed them.

[RobbeK]

Hi Charles, Mike , all

Charles, is it possible (I've been comparing some programs that worked before the pow(-2,2) history and gave up with the new DLL(s)" )
that you changed something in the step of the for next loop.
I may be dreaming but I do think they accepted floating point numbers (as a literal and as a variable) ?
They don't do this any more ..

best Rob

(sometimes they do work (?) , but the first output of the loop sometimes seems to be a #qNAN - followed by the correct values afai can intercept the results )

[RobbeK]

Addendum : yep , some strange things happening


best Rob

[Charles Pegge]

Yes Rob, I found an FPU stack overflow, on float steps. I don't think this bug is connected with the XP problem

update here

http://www.thinbasic.com/community/showthread.php?t=12175

[RobbeK]

Thanks Charles,

It may be connected with Mike's remark that older code doesn't work any more - I had the same problem and they all had the for...step...next in common. (they worked/work fine with the DLL from before the pow(x,y) update )

best, Rob

[Charles Pegge]

One potential problem with float iteration is cumulative error, especially with single precision floats:

single i
int j
for i=1 to 10000 step .1
j++
next
print j " " i

result: 100005 10000.05..

Cumulative errors can be avoided, without significant change in performance, by scaling an integer iterator.

for j=1 to 100000
i=j*.1
next
print "count: "j " final value: " i cr

result: 100001 10000

[RobbeK]

Hi Charles,

Yes, and even worse things are possible, p.e. using the loop index as the index of an array etc....

Speaking about this : (not related with above)

I used to declare the shared arrays "pseudo" dynamic , with the idea that the address and an index would be sufficient ... but they go wrong if you replace the (in this example) m(33) with just a plain m .... they crash after iteration #3-4 (shown in the MsgBox - the index get a weird value) , if the loop is based on integers it works.
Ah, yes to get a clearer idea about O2 -- the O2_basic, ... asm etc.. envokes the compiler and linker?? but declaration as ...

function(...) as... link #something ,
is this set up during run-time of the compiled code ????

8853

================================

Uses "Console" , "oxygen"



Dim m(33) , n(33) As Single
Dim s As String

s="
dim m as single at #m
dim n(33) as single at #n ' needs to be indexed avoiding a crash
dim i as integer
dim j , dz as single

dz=1/33
For i=0 To 32
m(i+1)=i*dz
Next

i=1

For j=0 To 1-dz step dz
print "Iteration #"+str(i)+" result : "+str(j)
n(i)=j
i++
Next

"
O2_Basic s
If O2_Errno Then
MsgBox 0, O2_Error
Stop
End If




O2_Exec

PrintL "test complete"

WaitKey
=============================================================


best Rob, thanks for your help !

[Charles Pegge]

Hi Rob, the linkage is set up at compile time. But the problem was the placement of at.

at needs to come before as, when the type is specified on the right

dim m at #m as single
dim n at #n as single

some other possibilities:

dim m at #m, n at #n as single


dim as single m at #m, n at #n


single m at #m, n at #n



' Empty thinBasic CONSOLE file template


Uses "Console" , "oxygen"





Dim m(33) , n(33) As Single
Dim s As String


s="
dim m at #m as single
dim n at #n as single
'
'dim m at #m, n at #n as single
'
'dim as single m at #m, n at #n
'
'single m at #m, n at #n


'
dim i as integer
dim j , dz as single


dz=1/33
For i=0 To 32
m(i+1)=i*dz
Next


cr=chr(13,10)
tab=chr(9)
pr=""
i=1
For j=0 To 1-dz step dz
pr+= "Iteration #"+str(i)+" result : "+str(j) cr
n(i)=j
i++
Next
print pr




"
O2_Basic s
If O2_Errno Then
MsgBox 0, O2_Error
Stop
End If






O2_Exec


dim i as long


For i=1 to 33
printl "Iteration #"+str$(i)+" result : "+str$(n(i))
Next


WaitKey

[RobbeK]

Oops, stupid me ;-)
probably mixing things up with function .... as link #x (I wonder how many times I made this mistake :-(

Thanks Charles

[Charles Pegge]

There is a breakage somewhere. It should be able to cope with your syntax, to maintain consistency with functions, so I will aim to fix it.

[RobbeK]

Hi Charles,

Yes, but if people are used to it ... unless both syntaxes are accepted, it's not difficult to remember it now.
BTW the Oxygen generated DDLs are completely conform concerning floating point numbers with the GFA compiler.
GFA is fast, compiles to native code , but Oxygen is faster ;-)
I have some older programs I can convert now by managing the time critical parts. (I already converted the graphics routines by using BMPs and and poking in them).
(well, yes, GFA accepts inline assembler, but the last code I wrote was for the 6502 and the Z80).
I hope to get a 2x speed (IIRC GFA was already 6x faster than VB - the old ones , not .NET)

best Rob

[Charles Pegge]

Done! It won't break any of the other formats

dim v as single at #v

http://www.thinbasic.com/community/showthread.php?t=12175

[Petr Schreiber]

Charles, thanks for the update!


Petr

[RobbeK]

Thanks Charles !