WinFract, parallel development, etc
Re: Notes from Paul de Leeuw et al regarding WinFract I've been running FractInt formulas and Par's in a program I built in Visual (and Power) Basic. Before anybody laughs, I should point at that this is no Mickey-Mouse program at all! I divided the project into 4 distinct components: 1. Fractal Engine - raw calculations 2. Formula interpreter 2. Display/graphics 3. Front-end, UI VB's IDE made the engine development easy to modify and test. Once I had a good initial version I then switched it into PowerBasic (which runs VB-syntax code much faster and makes DLL's). All other functions are done by VB (using API for graphics, of course). I don't need anything fancy, as my preferred mode of operation is to use online display as a guide only - I save images (like Fractint does with the "saveiter"), and have a separate render program for experimenting with colouring. It's all floating-point, I use 80-bit FP in the Engine (PowerBasic has an "Ext" datatype for this), and am currently looking at GMP/MPFR as an arbitrary-precision option. The advantage of all this is that front-end changes and extensions are very easy to do in VB, and I don't have to deal with MFC at all, VB does it for me. Jim White MathImagics, Uki NSW, Australia Jim.White@defra.gsi.gov.uk Department for Environment, Food and Rural Affairs (Defra) This email and any attachments is intended for the named recipient only. Its unauthorised use, disclosure, storage or copying is not permitted. If you have received it in error, please destroy all copies and inform the sender. Whilst this email and associated attachments will have been checked for known viruses whilst within Defra systems we can accept no responsibility once it has left our systems. Communications on Defra's computer systems may be monitored and/or recorded to secure the effective operation of the system and for other lawful purposes.
White, Jim (ITD) wrote:
I've been running FractInt formulas and Par's in a program I built in Visual (and Power) Basic.
....into 4 distinct components:
1. Fractal Engine - raw calculations 2. Formula interpreter 2. Display/graphics 3. Front-end, UI
This sounds very interesting, and personally, I would very much like to give it a try. Are you making it available to others ?? Also, will you be making this available as Open Source ?? Sincerely, P.N.L. ------------------------------------------------- http://home.att.net/~Paul.N.Lee/PNL_Fractals.html http://www.Nahee.com/Fractals/
Hi, here are some notes I might add. I, too, had intended to reengineer xfractint, and this has been discussed times and times before. Here are some issues that might be worth discussing: (I hope I am not offending anyone too much, after all, all the contributors have done a great job!). So anyway: - From the portability point of view, it would be desirable too: - eliminate assembly code - divide into distinct components (like Jim White's project suggest): - pure calc engine - abstraction layer for pure graphics (raster and maybe even vector) - GUI around it - parser - batch processing - Never underestimate the power of design (architecture, choice of technology). There are a lot aspects to be thought of (some of them that come to mind right now): - portability (operating systems) - portability (hardware vs. assembly) - portablitty (16 vs. 32 vs. 64 bit) - internationalization - possibility to exchange GUI, GUI-less mode for batch processing - support for multhithreading (in order to support multiple CPUs) - protected investment: don't use old APIs like: - Win32 - VB - Motif - MFC (strictly dividing into GUI/Backend may make that less important) - The existing code doesnt really support 32 Bit. While we are at, you might as well make sure its also portable to 64 Bit. - I once tried to continue the 'Allegro' branch, but I gave up on the idea of trying to reuse the code directly. Although the approach for the abstraction of the 'graphics driver' was going in the right direction. - Common code base You can probably give up the idea of having a common code base with the existing application. It will basically be a rewrite. - Global variables The existing code simply has too much global variables, its just hell to work with. Elimination of global variables would be necessary to: - allow multiple documents (MDI) - allow multi-threading (for multiple CPUs) - fractint is not opensource, you cannot initiate a sourceforge/freshmeat project based on the same source, although a common CVS repository would be very desirable - if you want several people to co-develop, make sure you don't need commercial tools (like Visual Studio) - earlier discussion: You may wanna search for: - manpwin - allegro - Thread: Idea 'libfractint' - Thread: Compiling for DOS - give up memory models? (both around Feb/2003 Mar/2003) - my recommendation (as far as i can tell) is to completely rewrite in C/C++, with a GUI like GTK+ (that's what Gnome and GIMP are based on). Unfortunetely, Qt is commercial under Windows. - check out other fractal projects for inspiration: http://freshmeat.net/search/?q=fractals§ion=projects&x=17&y=6 xaos is actually quite popular, and it supports several interfaces, although is does not boast all the mathematics that fractint has, it may give you a model on the software design (e.g. look at ui.h from the source). Good luck! Florian
-----Original Message----- From: fractdev-bounces@mailman.xmission.com [mailto:fractdev-bounces@mailman.xmission.com]On Behalf Of Paul N. Lee Sent: Monday, November 10, 2003 4:50 PM To: fractdev@mailman.xmission.com Subject: Re: [Fractdev] WinFract, parallel development, etc
White, Jim (ITD) wrote:
I've been running FractInt formulas and Par's in a program I built in Visual (and Power) Basic.
....into 4 distinct components:
1. Fractal Engine - raw calculations 2. Formula interpreter 2. Display/graphics 3. Front-end, UI
This sounds very interesting, and personally, I would very much like to give it a try. Are you making it available to others ??
Also, will you be making this available as Open Source ??
Sincerely, P.N.L. ------------------------------------------------- http://home.att.net/~Paul.N.Lee/PNL_Fractals.html http://www.Nahee.com/Fractals/
_______________________________________________ Fractdev mailing list Fractdev@mailman.xmission.com http://mailman.xmission.com/cgi-bin/mailman/listinfo/fractdev
Florian wrote:
- fractint is not opensource, you cannot initiate a sourceforge/freshmeat project based on the same source, although a common CVS repository would be very desirable
True, fractint is not open source according to the strict definition, but if the code is re-written significantly, the new program could have an open source license. I would suggest GPL. Even though we can't just slap a GPL license on the existing program because there have been so many different contributors who can't now be contacted, I would have no problem with the new program being strongly based on the existing code (where it makes sense) but under a new license. Tim
My spin on all of this is - I look at all of the very good points that Florian made, and every single one of them can be addressed by creating a Java rewrite. For optimization purposes, Java can interface with a C++ module written to perform core computational code targeted to specific systems. I'm still right in the middle of learning Java, but I would be so excited to be involved in such an endeavour. - Greg __________________________________ Do you Yahoo!? Protect your identity with Yahoo! Mail AddressGuard http://antispam.yahoo.com/whatsnewfree
Except that java tends to be somewhat slow, as it is an interpreted language, and while a java front end might work, if it is in the calculations, there could be a signifigant time penalty on deep zooms. Kevin Greg Toombs wrote:
My spin on all of this is -
I look at all of the very good points that Florian made, and every single one of them can be addressed by creating a Java rewrite. For optimization purposes, Java can interface with a C++ module written to perform core computational code targeted to specific systems.
I'm still right in the middle of learning Java, but I would be so excited to be involved in such an endeavour.
- Greg
__________________________________ Do you Yahoo!? Protect your identity with Yahoo! Mail AddressGuard http://antispam.yahoo.com/whatsnewfree
_______________________________________________ Fractdev mailing list Fractdev@mailman.xmission.com http://mailman.xmission.com/cgi-bin/mailman/listinfo/fractdev
Which is why the option of coding computation modules in C++ is still probably a good idea. Like I said.. --- Kevin Sexton <sexton@QNET.COM> wrote:
Except that java tends to be somewhat slow, as it is an interpreted language, and while a java front end might work, if it is in the calculations, there could be a signifigant time penalty on deep zooms.
Kevin
Greg Toombs wrote:
My spin on all of this is -
I look at all of the very good points that Florian made, and every single one of them can be addressed by creating a Java rewrite. For optimization purposes, Java can interface with a C++ module written to perform core computational code targeted to specific systems.
I'm still right in the middle of learning Java, but I would be so excited to be involved in such an endeavour.
- Greg
__________________________________ Do you Yahoo!? Protect your identity with Yahoo! Mail AddressGuard http://antispam.yahoo.com/whatsnewfree
_______________________________________________ Fractdev mailing list Fractdev@mailman.xmission.com
http://mailman.xmission.com/cgi-bin/mailman/listinfo/fractdev
_______________________________________________ Fractdev mailing list Fractdev@mailman.xmission.com
http://mailman.xmission.com/cgi-bin/mailman/listinfo/fractdev __________________________________ Do you Yahoo!? Protect your identity with Yahoo! Mail AddressGuard http://antispam.yahoo.com/whatsnewfree
If those modules do get done, I think the most likely outcome will still be multiple versions, with OS specific UIs, and maybe a universal version in java. There are things that are hard to do in java, like real fullscreen graphics and java is limited in what it can do with the hardware, as it doesn't know what the hardware is, and it isn't allowed to do some things a C/C++ program can. Greg Toombs wrote:
Which is why the option of coding computation modules in C++ is still probably a good idea. Like I said..
--- Kevin Sexton <sexton@QNET.COM> wrote:
Except that java tends to be somewhat slow, as it is an interpreted language, and while a java front end might work, if it is in the calculations, there could be a signifigant time penalty on deep zooms.
Kevin
Greg Toombs wrote:
My spin on all of this is -
I look at all of the very good points that Florian made, and every single one of them can be addressed
by
creating a Java rewrite. For optimization purposes, Java can interface with a C++ module written to perform core computational code targeted to
specific
systems.
I'm still right in the middle of learning Java, but
I
would be so excited to be involved in such an endeavour.
- Greg
__________________________________ Do you Yahoo!? Protect your identity with Yahoo! Mail AddressGuard http://antispam.yahoo.com/whatsnewfree
_______________________________________________ Fractdev mailing list Fractdev@mailman.xmission.com
http://mailman.xmission.com/cgi-bin/mailman/listinfo/fractdev
_______________________________________________ Fractdev mailing list Fractdev@mailman.xmission.com
http://mailman.xmission.com/cgi-bin/mailman/listinfo/fractdev
__________________________________ Do you Yahoo!? Protect your identity with Yahoo! Mail AddressGuard http://antispam.yahoo.com/whatsnewfree
_______________________________________________ Fractdev mailing list Fractdev@mailman.xmission.com http://mailman.xmission.com/cgi-bin/mailman/listinfo/fractdev
Kevin Sexton wrote:
There are things that are hard to do in java, like real fullscreen graphics and java is limited in what it can do with the hardware..
..know not how well it does elsewhere, but in w98, it says it is able to switch to fullscreen, but it doesn't, eventualy.. (with jdk 1.4.xx) Greg Toombs wrote:
For optimization purposes, Java can interface with a C++ module written to perform core computational code targeted to specific systems.
and native compilers? i.e. creating a platform specific executable from a java source? it is said that its speed is fully comparable with an executable made from a C source.. charlie ____________________________________________________________ PC DEXX za 16.990 s DPH! Athlon XP 2200+, CDRW, 80G, 17" monitor. Poslední levný nákup před Vánoci! http://ad2.seznam.cz/redir.cgi?instance=65270%26url=http://www.dexx.cz/frame...
In article <20031111030330.7878.qmail@web41304.mail.yahoo.com>, Greg Toombs <gregtoombs@yahoo.com> writes:
I look at all of the very good points that Florian made, and every single one of them can be addressed by creating a Java rewrite. [...]
If fractint is rewritten in Java, I doubt I will ever contribute to it. I think you don't quite understand the magnitude of the fractint sources. When you print them all out on double-sided paper, its a stack of paper about 5 inches thick. You want to rewrite -all- of that in Java? Sounds like a colossal waste of time to me, frankly. -- "The Direct3D Graphics Pipeline"-- code samples, sample chapter, FAQ: <http://www.xmission.com/~legalize/book/> Pilgrimage: Utah's annual demoparty <http://pilgrimage.scene.org>
In article <000201c3a7e9$236dc1c0$017ba8c0@snoopy>, "Florian Kolbe" <flo@fkolbe.de> writes:
- portablitty (16 vs. 32 vs. 64 bit)
16 bit is dead. Use the DPMI real mode layers if you really need to run under DOS, IMO. As for all the rest, if anyone goes in this direction, please take advantage of the work I have -already- done in the xfractint code base to separate out the GUI from the rest of the code. -- "The Direct3D Graphics Pipeline"-- code samples, sample chapter, FAQ: <http://www.xmission.com/~legalize/book/> Pilgrimage: Utah's annual demoparty <http://pilgrimage.scene.org>
participants (8)
-
Charlie Chernohorsky -
Florian Kolbe -
Greg Toombs -
Kevin Sexton -
Paul N. Lee -
Rich -
Tim Wegner -
White, Jim (ITD)