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