Re: WinFract, parallel development, etc
Hi, Florian's wish list sounds very appealing, and also fairly familiar - I've seen similar discussions before (eg http://protofractals.sourceforge.net/ has very similar suggestions). Where things become difficult is translating the grand plan into practice both because it's a huge amount of work and because with such a plethora of platforms (Windows, DOS, Linux X11, command-line, Java, Mac...) it becomes hard to serve them all well. It's also hard to get enough developers to agree on a common approach to implement the grand plan - witness just how many small fractal programs are listed on SourceForge. While this discussion on approaches is going on, I thought I'd mention that I'm currently tinkering with my own fractal program (http://gnofract4d.sourceforge.net/). Currently it's limited to Linux and to a small set of built-in fractals, though internally it's divided into a fairly platform-neutral C++ library and a front-end which does the GUI stuff. One interesting quirk which I've found is great for performance (but not so great for portability) is that to draw a fractal it splices together fragments of C++ code at runtime, runs the compiler, and calls the resulting code. This means that everything runs at full speed- the iteration and bailout functions can be inlined completely. My latest scheme is a full-blown compiler for Fractint (and some UltraFractal) formulas, which will compile the formula to C. This way I hope to be able to run user-specified formulas as fast as built-in functions. I have this about half-implemented - the lexer, parser and translation to intermediate code are all working - next I need to sort out the back end. Anyway, it's good to see some ideas being thrown about. I'd be interested in collaborating if anyone has any concrete plans... Regards, -- Edwin
In article <1068536385.11076.44.camel@localhost.localdomain>, Edwin <edwin@bathysphere.org> writes:
Florian's wish list sounds very appealing, and also fairly familiar -
Yes, it has been discussed in the context of fractint many, many, many, many times before. It seems that every few months someone proposes this grand re-organization of the fractint source code. It sounds great until they actually get into the code and then the sheer size of the task generally has them leaving without further comment. I'm not saying that Florian couldn't do what he proposes, but the number of previous victims laying dead along that path should serve as fair warning to anyone else proposing the journey. I travelled farther down the path than most, and still it seems people want to re-do what I did instead of build on it. -- "The Direct3D Graphics Pipeline"-- code samples, sample chapter, FAQ: <http://www.xmission.com/~legalize/book/> Pilgrimage: Utah's annual demoparty <http://pilgrimage.scene.org>
Hi Guys, I've seen a lot of valuable discussion and think that ther most valuable way forward is to keep as much of the system independent code as 'standard C' like a jpeg or png library. Then each of us can add GUI, screen and i/o independantly. The think that makes this difficult is the monmolithic modules and the over use of globals (needed in early versions for speed). In ManpWIN, I have tried to separate out the modules such as guess(), boundary() etc to simplify the process. I still believe that converting all of fractint is an arduous task and have chosen to do a fractint shell and add the WINDOWS specific stuff to that. The main contribution I can make is WINDOWS 32 bit, true colour palette design and true colour processing. Is there a way we can 'simply' generate a 'standard c' library for the platform independant components with a mnimal use of globals? This would help us all. ---------------------------------------------------------- Paul de Leeuw Computers Central Coast Australia Email: pdeleeuw@deleeuw.com.au www: <http://www.deleeuw.com.au> ABN 72 360 822 562 ---------------------------------------------------------- -----Original Message----- From: fractdev-bounces@mailman.xmission.com [mailto:fractdev-bounces@mailman.xmission.com]On Behalf Of Rich Sent: Wednesday, 12 November 2003 4:07 AM To: Fractint developer's list Subject: Re: [Fractdev] Re: WinFract, parallel development, etc
It seems that every few months someone proposes this grand re-organization of the fractint source code. It sounds great until they actually get into the code and then the sheer size of the task generally has them leaving without further comment.
In article <IFEOLDIDHJENENHBALGPKEIECLAA.pdeleeuw@deleeuw.com.au>, "Paul" <pdeleeuw@deleeuw.com.au> writes:
Is there a way we can 'simply' generate a 'standard c' library for the platform independant components with a mnimal use of globals? This would help us all.
The actual work is simple. There's just so much of it... -- "The Direct3D Graphics Pipeline"-- code samples, sample chapter, FAQ: <http://www.xmission.com/~legalize/book/> Pilgrimage: Utah's annual demoparty <http://pilgrimage.scene.org>
Is there a way we can 'simply' generate a 'standard c' library for the platform independant components with a mnimal use of globals? This would help us all.
The actual work is simple. There's just so much of it...
One little request to any brave soldier willing to take this on, please define any variable or function which defines colour anywhere in the code as at least 16 bits (prefer 24 bits) to allow for true colour. Pleeeeeease :o) Thanks!!! ---------------------------------------------------------- Paul de Leeuw Computers Central Coast Australia Email: pdeleeuw@deleeuw.com.au www: <http://www.deleeuw.com.au> ABN 72 360 822 562 ---------------------------------------------------------- -----Original Message----- From: fractdev-bounces@mailman.xmission.com [mailto:fractdev-bounces@mailman.xmission.com]On Behalf Of Rich Sent: Wednesday, 12 November 2003 8:05 AM To: Fractint developer's list Subject: Re: [Fractdev] Re: WinFract, parallel development, etc In article <IFEOLDIDHJENENHBALGPKEIECLAA.pdeleeuw@deleeuw.com.au>, "Paul" <pdeleeuw@deleeuw.com.au> writes: Fractdev mailing list Fractdev@mailman.xmission.com http://mailman.xmission.com/cgi-bin/mailman/listinfo/fractdev
In article <IFEOLDIDHJENENHBALGPKEIGCLAA.pdeleeuw@deleeuw.com.au>, "Paul" <pdeleeuw@deleeuw.com.au> writes:
The actual work is simple. There's just so much of it...
One little request to any brave soldier willing to take this on, please define any variable or function which defines colour anywhere in the code as at least 16 bits (prefer 24 bits) to allow for true colour. Pleeeeeease :o)
I'll second that request, but amend it to be at least 32-bits. We want at least 8 bits of red, green, blue, and ALPHA. Don't forget alpha. Its the key to going forward with 3D graphics and multiple layers. -- "The Direct3D Graphics Pipeline"-- code samples, sample chapter, FAQ: <http://www.xmission.com/~legalize/book/> Pilgrimage: Utah's annual demoparty <http://pilgrimage.scene.org>
Hi Team, Just a little more on true colour:
One little request to any brave soldier willing to take this on, please define any variable or function which defines colour anywhere in the code as at least 16 bits (prefer 24 bits) to allow for true colour. Pleeeeeease :o)
I'll second that request, but amend it to be at least 32-bits. We want at least 8 bits of red, green, blue, and ALPHA. Don't forget alpha. Its the key to going forward with 3D graphics and multiple layers.
I realise that it is not acually colour that needs to be defined, but maximum iteration count. Adding colour too early forces machine dependency. I still think that 32 bits is fine as it allows a huge range of maximum iteration counts but colour processing should be kept out of the generic code. Also, I have been doing a lot of work on fractal animation. Attached is the source code for a script file generator for ManpWIN. The output of the code is: The first line of the script generates the basic fractal parameters including starting iteration count, the second line is the end iteration count and the number of frames and this is followed by the x and y co-odinates and the vertical height for each frame. Is there any interest in this kind of thing "out there"? Regards, Paul de. ---------------------------------------------------------- Paul de Leeuw Computers Central Coast Australia Email: pdeleeuw@deleeuw.com.au www: <http://www.deleeuw.com.au> ABN 72 360 822 562 ----------------------------------------------------------
In article <IFEOLDIDHJENENHBALGPAEHDCMAA.pdeleeuw@deleeuw.com.au>, "Paul" <pdeleeuw@deleeuw.com.au> writes:
I realise that it is not acually colour that needs to be defined, but maximum iteration count. Adding colour too early forces machine dependency. I still think that 32 bits is fine as it allows a huge range of maximum iteration counts but colour processing should be kept out of the generic code.
I'll go along with that. Color handling is intimately associated with whatever display driver you're using.
Also, I have been doing a lot of work on fractal animation. [...] Is there any interest in this kind of thing "out there"?
Yes, I think animations (aside from the obvious color cycle or image pan/zoom) are a great way to extend fractals with new life. -- "The Direct3D Graphics Pipeline"-- code samples, sample chapter, FAQ: <http://www.xmission.com/~legalize/book/> Pilgrimage: Utah's annual demoparty <http://pilgrimage.scene.org>
Paul de Leeuw wrote:
....fractal animation. Attached is the source code for a script file generator for ManpWIN.
Thanks for the code.
Is there any interest in this kind of thing "out there"?
I have seen more people involved with fractal animation, movies, and videos than any other time in the past. It seems with the raw power of computing these days, now is the best time for many people to try out the next level of fractal image creation. Developing anything which can easily create multiple images into some form of fractal animation would be one of the major considerations for fractal software generators. At least that is the way I see current trends heading towards. Sincerely, P.N.L. ------------------------------------------------- http://home.att.net/~Paul.N.Lee/PNL_Fractals.html http://www.Nahee.com/Fractals/
Rich writes:
It seems that every few months someone proposes this grand re-organization of the fractint source code. It sounds great until they actually get into the code and then the sheer size of the task generally has them leaving without further comment.
I'm not saying that Florian couldn't do what he proposes, but the number of previous victims laying dead along that path should serve as fair warning to anyone else proposing the journey. I travelled farther down the path than most, and still it seems people want to re-do what I did instead of build on it.
I agree. I too started reworking the allegro branch a couple of months ago, but then I lost interest because I couldn't even compile properly because of 16-Bit-Problems and weird DOS routines (was ist the allegro branch? I cannot even remember). Apart from that, I didn't want to branch away too much from the existing code base (I did a lot of reorg). If at all you want to create a portable C-Engine by _reworking_ existing code, I guess it would be best to start off with xfractint. If you want to _rewrite_ I'd still do a C-based (or C++-based) engine, taking existing pieces from xfractint one by one.
From a practictal point of view, it may be best to start a GPL-licensed project from scratch on http://www.sourceforge.com/. That way, you can have a centralized CVS repository, web-space, task tracker, downloads and all that stuff.
Don't underestimate the desgin! Do not start coding until you know what it shoud look like (unless you want to do lots of 'extreme programming'). The key to software design is to divide into modules, with simple, yet effective interfaces ... Just some thoughts... Florian A side note, Rich, I think people tend to build stuff from scratch because it is in their nature. But the real challenge is not to reinvent the wheel, but to put pieces together to create something that is bigger than the sum of its pieces (is that how you say it english?) Ugh, huge words at 2:30 in the morning ...
-----Original Message----- From: fractdev-bounces@mailman.xmission.com [mailto:fractdev-bounces@mailman.xmission.com]On Behalf Of Rich Sent: Tuesday, November 11, 2003 6:07 PM To: Fractint developer's list Subject: Re: [Fractdev] Re: WinFract, parallel development, etc
In article <1068536385.11076.44.camel@localhost.localdomain>, Edwin <edwin@bathysphere.org> writes:
Florian's wish list sounds very appealing, and also fairly familiar -
Yes, it has been discussed in the context of fractint many, many, many, many times before.
It seems that every few months someone proposes this grand re-organization of the fractint source code. It sounds great until they actually get into the code and then the sheer size of the task generally has them leaving without further comment.
I'm not saying that Florian couldn't do what he proposes, but the number of previous victims laying dead along that path should serve as fair warning to anyone else proposing the journey. I travelled farther down the path than most, and still it seems people want to re-do what I did instead of build on it. -- "The Direct3D Graphics Pipeline"-- code samples, sample chapter, FAQ: <http://www.xmission.com/~legalize/book/> Pilgrimage: Utah's annual demoparty <http://pilgrimage.scene.org>
_______________________________________________ Fractdev mailing list Fractdev@mailman.xmission.com http://mailman.xmission.com/cgi-bin/mailman/listinfo/fractdev
I have to agree with nearly everything Rich said (though I don't share either his skill or enthusiasm for Windows, though I respect him for both). There's a huge amount of development and debugging work captured in Fractint that is easy to underestimate. The minute one starts to re-architect the code in a significant way, a whole lot of functionality is immediately lost. The past ports that were successful made preserving current functionality and code-base compatibility a high priority. Echoing Rich, this is not to discourage anyone who wants to try. Just know that the work is measured in man-years. Go right ahead! There is a way forward. Major architectural changes can be made incrementally with the program actually working each step of the way. One giant step has already been taken: fractint runs in a 32 bit memory environment, namely X/Linux. The assembler and integer code have already been removed. We need to start there. Fractint internally already has some abstraction. That's why it has successfully been ported to 16 bit windows and X/linux. (For example internal routines for reading/writing pixels/lines -- different ports just implement these worker routines differently and things just work.) Everybody agrees that a lot more abstraction of the graphics/interface layer is needed. Rich made a big start in that, but had to drop it before he was finished. I believe Jonathan tried to pick up Rich's changes, but I don't know where that effort stands. My suggested roadmap forward would be: 0. Repackage existing DOS developer version as a new version. This would be the end of the road for development of the DOS version. As long as someone wants to work with the DOS version, obviously, they could. I think it could live a long time using FreeDOS if we could compile it with the now-free Watcom compiler. Right now only Jonathan and I seem to have the development enviuronment for this version! However, the rest of these comments assume that maintaining a common source base with the DOS version would be dropped. The project would fork, and one branch of the fork would leave DOS behind. 1. Start with float-only Xfractint. Complete merging Rich's changes, which were directed at separating the graphics from the underlying engine. Unless Jonathan reports one of his efforts is a better starting point, I'd do this with Xwindows. 2. The next priority is to find a way to get a parallel version working on Windows. There's more than one way to do this, but native X is not the way to go. a. wxwindows interface for both Linux and Windows - ports pretty much as-is to windows. Advantage is unified code base. b. separate Windows interface, leveraging the now-better separation of the engine from interface. c. Both a. and b. - these options are not mutually exclusive. 3. A whole lot of other improvements that can be done incrementally (some of them before or in parallel with 2.), including, but not limited to: a. memory allocation. All those fixed arrays eliminated. b. global variable cleanup c. somewhere along the way, merge in Paul's truecolor support. d. Since fractint already makes heavy use of function pointers, I think the grand scheme of how everything hangs together could be radically redesigned. We've done this before, we could do it again using a more object-oriented approach. I have some ideas about this. This is a feasible way forward. Platform would be C language or possibly C++. Orientation is more conservative than many would like, aimed at preserving 80% or so of the legacy functionality, but providing an improved design that would facilitate new features and growth. Tim
On Tuesday 11 November 2003 07:51 pm, Tim Wegner wrote:
1. Start with float-only Xfractint. Complete merging Rich's changes, which were directed at separating the graphics from the underlying engine. Unless Jonathan reports one of his efforts is a better starting point, I'd do this with Xwindows.
The Allegro port *is* a merge of Rich's changes. The X portion is just broken right now. I should fix it one of these days. Take a look at the XMfract source. I like the way the routines have been split up into smaller files. Not that I want to start from that source, but it can give us ideas. Jonathan
Jonathan wrote:
The Allegro port *is* a merge of Rich's changes. The X portion is just broken right now. I should fix it one of these days.
Great! My "step one" is nearly done!
Take a look at the XMfract source. I like the way the routines have been split up into smaller files. Not that I want to start from that source, but it can give us ideas.
Will do. I can't put in huge hours, but if I just got my teeth in something I could work steadily. I have a friend at work who is a brilliant physicist who just happens to have enormous software talent. I collaborate with him a lot. Current projects are various Kalman filters for processing GPS data from the shuttle and the space station. He writes very modular semi- object- oriented C code that I have no trouble understanding and could probably do something similar. He creates structures for objects, has an open() call that returns a pointer, various routines that operate on the object, and a close() routine. Since Fractint already uses function pointers for the setup and per_pixel routines, I don't think it would be so hard to use this approach. After the image dimensions are determined, we would open() a fractal. Tim
On Tuesday 11 November 2003 08:19 pm, Tim Wegner wrote:
The Allegro port *is* a merge of Rich's changes. The X portion is just broken right now. I should fix it one of these days.
Great! My "step one" is nearly done!
Except, it is still at patch 4 (needs to be at 5). And, I have another patch in the works. Jonathan
Do we have a CVS server for the allegro fork? -- "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 <200311122104.51679.osuchj@avalon.net>, Jonathan Osuch <osuchj@avalon.net> writes:
On Wednesday 12 November 2003 07:49 pm, Rich wrote:
Do we have a CVS server for the allegro fork?
No. I appear to be CVS challenged.
Is there any legal reason we can't put it on sourceforge? I know we aren't "GPL", but sourceforge also allows you to specify your own custom license. I think fractint should qualify under that scenario. -- "The Direct3D Graphics Pipeline"-- code samples, sample chapter, FAQ: <http://www.xmission.com/~legalize/book/> Pilgrimage: Utah's annual demoparty <http://pilgrimage.scene.org>
Also -- if we can't do sourceforge, didn't Damien setup cvs.fractint.org for us to use? -- "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 <3FB13DAF.12614.460218@localhost>, "Tim Wegner" <twegner@swbell.net> writes:
I have to agree with nearly everything Rich said (though I don't share either his skill or enthusiasm for Windows, though I respect him for both).
I'm a self-confessed mass-market slut! :-) However, I would never propose making a sweeping change to fractint that would make it a Windows only program. I do believe in writing a native UI for each target platform rather than trying to do a least-common-denominator approach to a UI, but native UIs are a farther off point from where the Allegro port is right now. The changes I made to xfractint should make it -more- portable to new platforms rather than less, and you would have the ability to have multiple 'drivers' (think: GDI vs. DirectX for Windows, for instance, or curses vs. X11 for linux) for a single platform and switch between them dynamically. My book project is finally feeling like it is near the end and fractint is a project dear to my heart that I want to resume once that is over. -- "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 (7)
-
Edwin -
Florian Kolbe -
Jonathan Osuch -
Paul -
Paul N. Lee -
Rich -
Tim Wegner