Paul, I fully understand the limitations of Fractint's mostly very, very old code, so I certainly affirm the need for the improvements you suggest. I'm certainly not a candidate to help. I have been happy to provide web hosting for the project and occasional testing, and still (just barely) have the ability to recompile the old DOS code. I tell myself I still could jump in and code, but the truth is I haven't in decades and have been retired now for eight years from my NASA software development career. And I have a very full and satisfying life, of which fractals take just a tiny part. So I'm not a candidate to help you disentangle some legacy Fractint code in ManpWIN. Good luck! I'm not saying you should do this, but if you made the ManpWIN code and development environment public, you never know who might appear. Over the years I have received many messages along the lines of "Where's the fractint code? Point me to it and I'll make huge contributions before next Friday". Of course, in every case, we never hear from them again, because the source code is daunting. But others come from out of the blue, and their first message to us is that they have made some amazing contribution already, and sent it to us. Having the code public makes that possible. Not saying you would have that experience today, fractals are not the big deal they were with Mandelbrot was writing. Tim On Mon, Jul 6, 2020 at 9:04 PM Paul <pdeleeuw@deleeuw.com.au> wrote:
Dear Friends of Fractint,
I have been thinking a lot about possible upgrades to Fractint. It is a remarkable piece of software. However, there are many issues as I try to port much of the code to my program ManpWIN.
The main issue is the use of global variables for everything. I recognise the need for them in the purely DOS days to get every bit of speed possible. I want to upgrade the code to allow multi-threading. In order to do this there can't be any global variables as one thread will overwrite the value of another. C++ helps by allowing variables to be global for each object but not for others. So an object can be used for each thread.
Other possible improvements.
1. I have replaced the bignum library with MPFR because it is thread safe and is quicker than Fractint's bignum library. 2. I have created a complex number bignum library that simplifies many of the complex number routines 3. I have ported all the plotting routines to C++ and added a couple of my own 4. Incorporate perturbation theory for faster bignum calculations at high zoom levels. This works very well and is mult-threaded 5. Offer slope clculations to show a 3D effect. This is also multi-threaded
However, I am still stuck on the main Fractint portions of my code because of all the remaining global variables. I would dearly love to make it multi-threading, especially when we zoom deep into arbitrary precision.
Is anyone interested in looking at these issues? I am happy to share some of my source code if anyone wants it.
Thanks,
Paul.
---------------------------------------------------------- Paul de Leeuw Computers NSW Central Coast, Australia Email: pdeleeuw@deleeuw.com.au www: <https://www.deleeuw.com.au> ABN 72 360 822 562 ----------------------------------------------------------
_______________________________________________ Fractdev mailing list Fractdev@mailman.xmission.com https://mailman.xmission.com/cgi-bin/mailman/listinfo/fractdev