Author Topic: The buddhabrot (challenging ?)  (Read 26065 times)

0 Members and 1 Guest are viewing this topic.

JRS

  • Guest
Re: The buddhabrot (challenging ?)
« Reply #45 on: January 03, 2015, 07:56:17 PM »
Sweet Mike!

I was about a 1/2 hour out to finishing the SB conversion of Rob FB example but I think I'm going to use your code and SDL_gfx instead.

I love to watch code getting makeovers as it's passed around the forum table.  8)

« Last Edit: January 03, 2015, 08:31:01 PM by John »

Mike Lobanovsky

  • Guest
Re: The buddhabrot (challenging ?)
« Reply #46 on: January 03, 2015, 09:36:43 PM »
Nice animation, John! :)

Here comes another Buddha hypostasis, this time an irate one. I can also clearly see a wolf's muzzle with open chops on Buddha's belly. When displayed in its full resolution, I can even see its narrowed eyes and fangs in its mouth. But perhaps my imagination is just a bit too wild. :)

By the way, the fractal's layout and coloration seem to be perfectly symmetrical about its central vertical axis. This enables us to cheat by calc'ing only one half of it and mirroring it simply onto the other side in the trailing nested for() loop of DynC plot_matrix() only. This can effectively double the existing drawing speed. 8)

.

JRS

  • Guest
Re: The buddhabrot (challenging ?)
« Reply #47 on: January 03, 2015, 11:22:45 PM »
Here is a reference to help you extend life to buddhabrot.



.

Mike Lobanovsky

  • Guest
Re: The buddhabrot (challenging ?)
« Reply #48 on: January 04, 2015, 06:26:54 AM »
Hehe, I have strong doubts as to whether vibrio cholerae can really extend life to anybody or anything.

On the other hand, Buddha is above the top of the tree of Life with about a dozen stages of enlightment separating Him from ordinary mortals. I'd venture to say, we're evolutionally much closer to those protozoa above than to Him.

And no, I am an Orthodox Christian. :)

RobbeK

  • Guest
Re: The buddhabrot (challenging ?)
« Reply #49 on: January 04, 2015, 07:35:42 AM »
Hi, thanks again ..  John , Mike , all ..

Oops, I made a serious error then (@ Mike)  -- poking outside arrays is lethal (or should be).
For the moment I can not prove (how simple as it may sound) that p.e. orbits may come closer and then vanish to infinity.

More important, your compare is drifting me to abandon Japi.  It was handy because it comes with GCL , Stalin Sheme , Bigloo and easy to adapt in other applications. 
I do not want to give up Lisp , but packages for Windows are hardly stable -- timer events often missing because not adapted from Linux.

Maybe the better idea is using something as tB , FBSL , SB setting up a pipe to NewLISP and use Oxygen for the time critical piecas in the code.  This means giving up the heavy weight Common Lisps (and also Racket Scheme ).

The idea of using GFA may be a good idea , I can use NewLISP with it , Oxygen DLL's within it , it accepts inline assembler , I have OpenGL , glu , glut already worked out for it and I can inject the newer XP style in the executables or distribute it together with a manifest file doing the same. 
Maybe I'll do this ...   as an experiment tried same program (working with a bitmap now)

what'd you think ??

any advice appreciated -- 

best Rob (in the prog you can change the iteration level)

.
« Last Edit: January 04, 2015, 07:43:02 AM by RobbeK »

JRS

  • Guest
Re: The buddhabrot (challenging ?)
« Reply #50 on: January 04, 2015, 11:15:57 PM »
Rob,

I was able to get the GFA/OCX example to run in Wine. Seems to generate the image quickly.



.

JRS

  • Guest
Re: The buddhabrot (challenging ?)
« Reply #51 on: January 04, 2015, 11:54:29 PM »
Here is the VB6 version of this. I attached the compiled .exe if you want to give it a try yourself.


.

Mike Lobanovsky

  • Guest
Re: The buddhabrot (challenging ?)
« Reply #52 on: January 05, 2015, 02:46:31 AM »
Yes John,

That's the algo I used for my initial FBSL orbit trap example in BB.zip on the preceding page in this thread.

With the only exception that when set to use a 500*500 px canvas, run 2 500 000 iterations and draw a frame every 50 000 iterations (you can set these options on the main form), VB6 compiled to native code would take 42 seconds to complete the task on my PC while FBSL would take only 7.

No big deal.

:)

JRS

  • Guest
Re: The buddhabrot (challenging ?)
« Reply #53 on: January 05, 2015, 04:37:28 AM »
This one is still my favorite that you did.

Mike Lobanovsky

  • Guest
Re: The buddhabrot (challenging ?)
« Reply #54 on: January 05, 2015, 07:52:49 AM »
For that one, all the glory goes to Rob. I gather it's based off of a completely original algo hitherto unbeknownst to Man. :D

RobbeK

  • Guest
Re: The buddhabrot (challenging ?)
« Reply #55 on: January 12, 2015, 05:00:25 AM »
The thing in 3D and a question :

On a Linux computer for the moment , why -- under Wine -- applications (as attached)   , gray-out after a certain number of seconds when running in a loop ?  (almost an indication the app should be hanging ) ..  John ? u probably have experience with this ?

best, Rob

written in GFA (openGL seems working well )
ah, you have to push "start" first at least one time ...

use the ...thingsDV.exe (it uses a timer , and calls lists (a lot better)

.
« Last Edit: January 12, 2015, 10:38:09 AM by RobbeK »

Mike Lobanovsky

  • Guest
Re: The buddhabrot (challenging ?)
« Reply #56 on: January 12, 2015, 02:17:11 PM »
Hi Rob,

Your 3D animation with a timer looks nice. :)

Yet ...things3DV.exe also has a bomb in it, which is its OpenGL test/STOP button. People, do not press it! It freezes my computer to total unresposiveness and the only way out is a cold reboot!

In a GUI applucation, Windows must have its own time slot to process window(s) messages in the respective callback(s). Every Windows version has a fixed period (XP, the longest, 7+, the shortest) within which the system waits for a return from the callback -- not more than just a few seconds. If a window message goes to the callback but there's no return from it for a longer time than this fixed period allows, the entire application is marked as "unresponsive" and its execution is forcibly interrupted by the system.

That said, a Windows GUI app must not perform any activity running in a tight Do/While/For loop unless this loop:
  • either is very short, i.e. shorter than the aforesaid fixed period
  • or has some statement that enforces the time slice in which the app can consume and execute the messages that have been accumulated in the message queue by that time.
Such enforcement is usually done with the help of DoEvents statement in the languages that support it, e.g. VB or FBSL, or its equivalent in those that don't.

The simplest DoEvents implementation would be a simple While statement as shown below in pseudo-code: (do not use If instead of While because message handling must at all times have higher prioriry in a GUI program than any other task!)

While PeekMessage(PM_REMOVE)
  TranslateMessage()
  DispatchMessage()
WEnd


The entire DoEvents implementation in the VB6 sources counts more than a thousand lines of C++ code!

Clearly enough, any form of DoEvents will slow down the loop but this is a natural trade-off for the pleasure of working in a civilized GUI environment rather than in a medieval console/terminal/punchcard/abacus/whatever.

Your OpenGL test runs in a Do/Until loop that doesn't allow Windows to execute its pending WM_ messages. OpenGL render tasks do not and cannot substitute the genuine callback in an implementation like this.

I believe your Linux Wine grayouts are of the same nature as my stall/reboot and are caused by the phenomena that I've described above. Wine is supposed to mimic Windows as close as possible after all, isn't it? ;)
« Last Edit: January 12, 2015, 02:29:09 PM by Mike Lobanovsky »

RobbeK

  • Guest
Re: The buddhabrot (challenging ?)
« Reply #57 on: January 12, 2015, 02:40:31 PM »
Hi Mike,

thanks for that info ...  indeed, yes , the test opengl procedure grays-out when running under Wine, the main demo (timer controlled (every 40 msec ) doesn't.  (running it on Win7 here,  however gave no problems (for whatever reasons - only under Linux , while giving an the images turned them gray ).
OK, the solutions will be easy, i hope --  have to look at the main GFA loop too ( do sleep  until me is nothing )  there is also   : doevents reading the manual..

thanks again for your expert help   Rob
(strangely, that evil part was something i found on the web  (named DEMO1 ) the code is   DO ...... some ogl ... UNTIL mouse-click- I used it for testing the ogl was working, i'll remove it and improve the 3D , for the moment Z value is restricted to max 255 (because coming from the bitmap )
« Last Edit: January 12, 2015, 02:53:10 PM by RobbeK »

Mike Lobanovsky

  • Guest
Re: The buddhabrot (challenging ?)
« Reply #58 on: January 12, 2015, 03:25:37 PM »
Perhaps Do/Until without DoEvents inside would be feasible when run in a separate worker thread (there are app implementations that take much of OpenGL rendering out of the main thread), but in a simple single-threaded sample like that one, your best bet would be either DoEvents within the loop (luckily it appears to be available in GFA) or a timer.

RobbeK

  • Guest
Re: The buddhabrot (challenging ?)
« Reply #59 on: January 14, 2015, 12:39:48 PM »
Hi Mike,

Yes, it's working in a safe way now -- I added DoEvents inside the 2D loop and kept timing the 3D loop.
Changed the concept by not working on a BMP now (with the advantage the hits are not restricted to a max val of 255).
In the attached prog you can find a mathematical correct app now (with a serious scaling of the Z values - the max is mentioned in the info field)
The |stop| only works on the timer (it will not stop the 2D loop).

Another question (infact 2)
- You told me the abs() is rather expensive - but (thinking about this) then p.e. abs(x) > a  is identical with x*x>a*a (and a>0) --  the latter the faster ???
(I used this trick now).
- Working on the Linux 'puter, I tried something in the Austin Kyoto Common Lisp , and while it was here the fastest , on the Win7 it is the slowest (except the interpreters and the bytcode compiler CLISP)  ..  It is extremely frustrating to read the esoteric Lisp documentation ,  (maybe on purpose  ::)  )  -- digging into the fragments, rags of documentation , i found that on Windows GCL is translated into C , and then does a DynLoad (????)  --  on Linux it is compiled with the (part of the system) GCC - on Win I have not such a thing ....   what's DynLoad ???

thanks in advance, Rob


.
« Last Edit: January 14, 2015, 12:51:58 PM by RobbeK »