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 ----------------------------------------------------------
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
Paul, Tim,
...global variables for everything... Are you aware of the fact that many of these kinds of issues in Fractint's code have already been taken care by Richard in a code base he's made freely available?
A while ago he told me that he did not currently have time to finalize his refactoring of the DOS Fractint code to Windows Fractint conversion/port project. However, I have previously successfully used (many features of) Richard's most recent "Fractint for Windows beta 5" executable -- most notably calculating and posting Jim's FOTD to the Fractint list for a long time -- using Richard's version -- (when Paul N. Lee was no longer able to do this). Richard's (older) description of his work is here: https://legalizeadulthood.wordpress.com/2007/04/13/fractint-for-windows-beta... An extract from the above article: ======================================== ...a major restructuring of the entire code base has been done to remove all the DOS-isms: segments, near pointers, far pointers, interrupt calls to the BIOS and the 16-bit assembly language. Furthermore, restructuring passes have been made on the source code to replace ‘magic numbers’ with symbolic names, naming global data and file scope data with prefixes to indicate their storage class, eliminating fallback code for systems with no FPU accelerator (386 and earlier) or even just 80287 FPU specific code, and sanitizing function names wherever possible. There probably isn’t a single line of code in the entire source base that I haven’t touched in one way or another. In ‘legacy code’ terms I did a hell of a lot of “Rename Method”, “Rename Variable” and “Rename Parameter” refactorings along with a few “Extract Method” refactorings along the way. Most of these changes have been refactorings because they are not intended to change the behavior of FractInt. ... ... ...marking all global and file-scope data with a special prefix (g_ and s_, respectively) at least helps you know at a glance what kind of data any particular statement is manipulating. Giving things clearer names helps other people to understand what the data is about. Defining symbolic names for the valid values helps you see that this piece of data is treated like an enum with a set of specific values, that piece of data is treated as a set of bitflags with that set of flags, and this other piece of data is treated as an integer value. ... ======================================== Fractint for Windows has been renamed "iterated dynamics" and moved from CodePlex.com to: https://github.com/LegalizeAdulthood/iterated-dynamics/ "Iterated Dynamics is an open source fractal renderer that can..." I *strongly* suggest you: - Read Richard's description of what he has already done to the Fractint code base https://legalizeadulthood.wordpress.com/2007/04/13/fractint-for-windows-beta... and - take a look at Richard's code base: https://github.com/LegalizeAdulthood/iterated-dynamics/releases/tag/fractint... Note that I'm not familiar with it myself -- just the fact that Richard was refactoring it in the way he describes it at the wordpress link (and extract) above. - Try installing and running his code. P. S. I just now downloaded his Windows MSI installer and zipped code to verify that it was still available. P. P. S. Like Tim, my coding days are pretty much behind me. ☹ P. P. P. Congratulations on your multi-threaded code! After zip file extraction, much of Richard's code seems to be in: fractint > win32 and fractint > win What's your opinion of the usefulness of Richard's code base? - Hal Lane ######################## # hallane@earthlink.net ######################## -----Original Message----- From: Fractdev <fractdev-bounces@mailman.xmission.com> On Behalf Of Paul Sent: Monday, July 6, 2020 10:03 PM To: 'Fractint developer's list' <fractdev@mailman.xmission.com> Subject: [Fractdev] Upgrades for Fractint Importance: High 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 recognize 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 calculations 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: mailto:pdeleeuw@deleeuw.com.au www: <https://www.deleeuw.com.au> ABN 72 360 822 562 ---------------------------------------------------------- _______________________________________________ Fractdev mailing list mailto:Fractdev@mailman.xmission.com https://mailman.xmission.com/cgi-bin/mailman/listinfo/fractdev
Harold asked:
Are you aware of the fact that many of these kinds of issues in Fractint's code have already been taken care by Richard in a code base he's made freely available?
Yes I'm very aware 😅. Rich did an amazing job. However Jonathan and I were committed to keeping the code base compatible with the DOS and Xfractint versions, so we didn't see a way to take advantage of Rich's fine work. This (understandably) frustrated Rich quite a bit. In any case, Rich's code is available, and Paul can use it if he wishes. Everyone in this effort from the beginning was always empowered to participate as they wished. That is still true. Tim
Hi Tim, Here are my replies without HTML format: From: Paul [mailto:pdeleeuw@deleeuw.com.au] Sent: Thursday, 9 July 2020 12:37 PM To: 'Fractint developer's list' Subject: RE: [Fractdev] Upgrades for Fractint Hi Tim, I broke away from the Fractint base because I wanted a few things Fractint didn’t offer, like true colour, instant formula parsing and animation. ManpWIN just took off from there J I’ll explore Richard’s code and see if I can use it to improve ManpWIN. Thanks. By the way, I am happy to share the source code for ManpWIN with an yone who wants it. Regards, Paul. From: Paul [mailto:pdeleeuw@deleeuw.com.au] Sent: Thursday, 9 July 2020 12:21 PM To: 'Fractint developer's list' Subject: RE: [Fractdev] Upgrades for Fractint G’day Tim, Great to hear from you again. “but if you made the ManpWIN code and development environment public, you never know who might appear” What is the best way to make it public? I actually like the Fractint environment as there is some familiarity with the concepts. ManpWIN is built on the core of WINFRACT. I have worked with others to develop chaotic oscillators, perturbation theory and slope calculations, but sometimes developers want to go into tangents. I’d dearly love to work with Richard as he has intimate knowledge of the fractint code. Let’s see what happens. Paul. ---------------------------------------------------------- Paul de Leeuw Computers NSW Central Coast, Australia Email: <mailto:pdeleeuw@deleeuw.com.au> pdeleeuw@deleeuw.com.au www: < <https://www.deleeuw.com.au> https://www.deleeuw.com.au> ABN 72 360 822 562 ---------------------------------------------------------- From: Fractdev [mailto:fractdev-bounces@mailman.xmission.com] On Behalf Of Timothy Wegner Sent: Wednesday, 8 July 2020 7:23 AM To: Fractint developer's list Subject: Re: [Fractdev] Upgrades for Fractint Harold asked:
Are you aware of the fact that many of these kinds of issues in Fractint's code have already been taken care by Richard in a code base he's made freely available?
Yes I'm very aware 😅. Rich did an amazing job. However Jonathan and I were committed to keeping the code base compatible with the DOS and Xfractint versions, so we didn't see a way to take advantage of Rich's fine work. This (understandably) frustrated Rich quite a bit. In any case, Rich's code is available, and Paul can use it if he wishes. Everyone in this effort from the beginning was always empowered to participate as they wished. That is still true. Tim
participants (3)
-
Harold Lane -
Paul -
Timothy Wegner