From: "Tim Wegner" Subject: (fractdev) Welcome Humberto Date: 01 Dec 1998 22:16:08 -0600 Welcome to Humberto Baptista! I see you joined the list. I haven't been able to run my version compiled with Borland 5 (complains about not enough memory) although I believe earlier Borland compilers work. I'll have to reinstall my old Borland 3.1. Microsoft C/C++ 7 works the best. I will be uploading the developer's source for the DOS and Linux versions of Fractint to my FTP site in a few days. No need to check site, I'll alert folks first. We may begin releasing some developer version executable to the public, but we have to decide details first. We could discuss this here if you like. One concern would be to include a readme stating that the package could only be posted in a few designated places (e.g. spanky). The reason for this is that developer's versions last about a week typically (though we likely wouldn't release every tiny change to the public) and we don't want Fractint put places where it won't be updated. Tim Thanks for using Fractdev, The Fractint Developer's Discussion List Post Message: fractdev@lists.xmission.com Get Commands: majordomo@lists.xmission.com "help" Administrator: twegner@phoenix.net Unsubscribe: majordomo@lists.xmission.com "unsubscribe fractdev" ------------------------------------------------------------------------------- From: Humberto Rossetti Baptista Subject: Re: (fractdev) Welcome Humberto Date: 02 Dec 1998 13:08:31 -0200 (EDT) On Tue, 1 Dec 1998, Tim Wegner wrote: > Welcome to Humberto Baptista! I see you joined the list. Hello all in the list > I haven't been able to run my version compiled with Borland 5 > (complains about not enough memory) although I believe earlier > Borland compilers work. I'll have to reinstall my old Borland 3.1. > Microsoft C/C++ 7 works the best. I'm compiling fine with BC 3.1 (or 3.0) although after some patching and modifing I noticed that the arbitray precision code locks up the machine. I guess it is some overlay pushed (or pulled) beyond som bounday. As I do not know the overlay scheme used very well now I cannot say for sure. > I will be uploading the developer's source for the DOS and Linux > versions of Fractint to my FTP site in a few days. No need to > check site, I'll alert folks first. OK, what would be best to post the patches or to send them directly to twegner@phoenix.net? > We may begin releasing some developer version executable to the > public, but we have to decide details first. We could discuss this > here if you like. One concern would be to include a readme stating Yes I would like to discuss it and my tow inital cents are: place it in one or two sites (like spanky and some friendly mirros) and allow the download via HTTP only. A prety clear statement that it is beta code would surely be better understood if on the download page that in some README that is not alway read. > change to the public) and we don't want Fractint put places where > it won't be updated. Agreed. []'s Humberto R. Baptista humberto@insite.com.br Insite - Solucoes Internet http://www.insite.com.br Thanks for using Fractdev, The Fractint Developer's Discussion List Post Message: fractdev@lists.xmission.com Get Commands: majordomo@lists.xmission.com "help" Administrator: twegner@phoenix.net Unsubscribe: majordomo@lists.xmission.com "unsubscribe fractdev" ------------------------------------------------------------------------------- From: comdotatdotcom@csi.com Subject: RE: (fractdev) Welcome Humberto Date: 02 Dec 1998 17:46 0000 Hi Tim & Humberto, >We may begin releasing some developer version executable to the >public, but we have to decide details first. We could discuss this >here if you like. I'm gane! How about tentatively suggesting a christmas or new year rrelease for public beta code? seems like a handy date in the not too near, not too distant future. >One concern would be to include a readme stating >that the package could only be posted in a few designated places >(e.g. spanky). I can host stuff at ukonline as usual for the european side of things. Cheers, Robin. Thanks for using Fractdev, The Fractint Developer's Discussion List Post Message: fractdev@lists.xmission.com Get Commands: majordomo@lists.xmission.com "help" Administrator: twegner@phoenix.net Unsubscribe: majordomo@lists.xmission.com "unsubscribe fractdev" ------------------------------------------------------------------------------- From: "Damien M. Jones" Subject: RE: (fractdev) Welcome Humberto Date: 02 Dec 1998 12:42:26 -0600 - >One concern would be to include a readme stating - >that the package could only be posted in a few designated places - >(e.g. spanky). - - I can host stuff at ukonline as usual for the european side of things. ftp.fractalus.com is also available, if you want me to include the files there. Damien M. Jones \\ dmj@fractalus.com \\ Fractalus Galleries & Info: \\ http://www.fractalus.com/ Please do not post my e-mail address on a web site or in a newsgroup. Thank you. Thanks for using Fractdev, The Fractint Developer's Discussion List Post Message: fractdev@lists.xmission.com Get Commands: majordomo@lists.xmission.com "help" Administrator: twegner@phoenix.net Unsubscribe: majordomo@lists.xmission.com "unsubscribe fractdev" ------------------------------------------------------------------------------- From: Humberto Rossetti Baptista Subject: (fractdev) Idea of beta release date and way tomirror betas (was: RE: Welcome Date: 02 Dec 1998 17:31:21 -0200 (EDT) On Wed, 2 Dec 1998 comdotatdotcom@csi.com wrote: > I'm gane! How about tentatively suggesting a christmas or new year > rrelease for public beta code? seems like a handy date in the not too > near, not too distant future. That's a very nice idea, most of the usersI talk to are feeling "abandoned" by the development of Fractint. > I can host stuff at ukonline as usual for the european side of things. I can also host it here for Latin America/Brasil access. []'s Humberto R. Baptista humberto@insite.com.br Insite - Solucoes Internet http://www.insite.com.br Thanks for using Fractdev, The Fractint Developer's Discussion List Post Message: fractdev@lists.xmission.com Get Commands: majordomo@lists.xmission.com "help" Administrator: twegner@phoenix.net Unsubscribe: majordomo@lists.xmission.com "unsubscribe fractdev" ------------------------------------------------------------------------------- From: Humberto Rossetti Baptista Subject: (fractdev) Worklist and future directions Date: 02 Dec 1998 17:35:33 -0200 (EDT) Hi, As I'm new I would like to ask the list about what are the current worklines (to avoid doing things twice and messing with others work). Other thing that I have been thinking for some time now. Should we think of a 32 bit version of fractint? Yes i know lot of people like to use fractint on 16 bit machines, but the root of fractint were speed, speed and speed :-) and although we have LOTS of stuff there it still is _very_ fast. I keep wondering if the development wete on a flat memory space and 32 bit mode things could go a lot faster and less troublesome. Any ideas/experiences/thoughts? []'s Humberto R. Baptista humberto@insite.com.br Insite - Solucoes Internet http://www.insite.com.br Thanks for using Fractdev, The Fractint Developer's Discussion List Post Message: fractdev@lists.xmission.com Get Commands: majordomo@lists.xmission.com "help" Administrator: twegner@phoenix.net Unsubscribe: majordomo@lists.xmission.com "unsubscribe fractdev" ------------------------------------------------------------------------------- From: Tim Gilman Subject: Re: (fractdev) Worklist and future directions Date: 02 Dec 1998 12:03:03 -0800 Hello there! I'll pipe up and describe what I'm up to, as I'm sort of working in isolation. I'm working on a Mac port of Fractint. It's coming together slowly; I've got fractals drawing to the screen, most of the built-in fractal types display correctly, zooming works, option-screens in the form of dialogs, etc. The biggies left for me are file-parsing (PARs FRMs MAPs), palette editing, and general UI cleanup. I'm currently working on getting color-cycling to work in-a-window with monitor-depths set to greater than 8 bit. I say I'm working in isolation 'cause I've been mangling the xfract source base to get most the scaffolding work done. That, and I'm mostly writing Mac-specific code which doesn't really affect the underlying engine. There's some places where I've had to do some minor surgery, but merging those parts back into the xfract base won't be too much of a chore (I'll eat those words!). Future directions? I vote for a cleaner layer of abstraction seperating Fractint from platform/gui. POV-Ray is my inspiration! 2 cents in the Soup, Tim Gilman tgilman@cats.ucsc.edu http://www.scruz.net/~tgilman/tim/macfract/ > Hi, > > As I'm new I would like to ask the list about what are the current >worklines (to avoid doing things twice and messing with others work). > > Other thing that I have been thinking for some time now. Should we think >of a 32 bit version of fractint? > > Yes i know lot of people like to use fractint on 16 bit machines, but >the root of fractint were speed, speed and speed :-) and although we have >LOTS >of stuff there it still is _very_ fast. I keep wondering if the >development wete >on a flat memory space and 32 bit mode things could go a lot faster and less >troublesome. > > Any ideas/experiences/thoughts? > > []'s > > Humberto R. Baptista > humberto@insite.com.br > >--------------------------------------------------------------------------- >Insite - Solucoes Internet http://www.insite.com.br > > >-------------------------------------------------------------- Thanks for using Fractdev, The Fractint Developer's Discussion List Post Message: fractdev@lists.xmission.com Get Commands: majordomo@lists.xmission.com "help" Administrator: twegner@phoenix.net Unsubscribe: majordomo@lists.xmission.com "unsubscribe fractdev" ------------------------------------------------------------------------------- From: kragen@pobox.com (Kragen) Subject: Re: (fractdev) Worklist and future directions Date: 02 Dec 1998 17:00:38 -0500 (EST) On Wed, 2 Dec 1998, Humberto Rossetti Baptista wrote: > Other thing that I have been thinking for some time now. Should we think > of a 32 bit version of fractint? xfractint is 32-bit on 32-bit machines, and 64-bit on 64-bit machines. -- Kragen Sitaker It frightens the daylights out of me whenever I hear people proclaim that the less knowledge our children have access to, the better. -- Duane Lindstrom, at Thanks for using Fractdev, The Fractint Developer's Discussion List Post Message: fractdev@lists.xmission.com Get Commands: majordomo@lists.xmission.com "help" Administrator: twegner@phoenix.net Unsubscribe: majordomo@lists.xmission.com "unsubscribe fractdev" ------------------------------------------------------------------------------- From: Humberto Rossetti Baptista Subject: Re: (fractdev) Worklist and future directions Date: 02 Dec 1998 20:17:14 -0200 (EDT) On Wed, 2 Dec 1998, Kragen wrote: > On Wed, 2 Dec 1998, Humberto Rossetti Baptista wrote: > > Other thing that I have been thinking for some time now. Should we think > > of a 32 bit version of fractint? > > xfractint is 32-bit on 32-bit machines, and 64-bit on 64-bit machines. I meant to have a common base on the DOS version that is 32 bit without the memory constraints and optimized to take advantage of the operations in 32 bits. The source in the DOS version is somewhat far from this, but seeing the work done on xfract maybe not so far. []'s Humberto R. Baptista humberto@insite.com.br Insite - Solucoes Internet http://www.insite.com.br Thanks for using Fractdev, The Fractint Developer's Discussion List Post Message: fractdev@lists.xmission.com Get Commands: majordomo@lists.xmission.com "help" Administrator: twegner@phoenix.net Unsubscribe: majordomo@lists.xmission.com "unsubscribe fractdev" ------------------------------------------------------------------------------- From: comdotatdotcom@csi.com Subject: RE: (fractdev) Worklist and future directions Date: 02 Dec 1998 22:35 0000 Hi Humberto, > As I'm new I would like to ask the list about what are the current >worklines (to avoid doing things twice and messing with others work). I'm currently puttng better sound support in, and generally fiddle about with uncomplicated interface issues :-) > Other thing that I have been thinking for some time now. Should >we think >of a 32 bit version of fractint? Definately, though first would come the interface/ calculation engine abstraction.... in fact we should really be aiming for 'portable' rather than '32 bit' IMHO It would be really nice to adopt one of the open devlopment platforms available these days. .... not that I lay any claim to knowing how to go about it of course :-) >on a flat memory space and 32 bit mode things could go a lot faster >and less >troublesome. Flat memory space would be soooooo nice! Cheers, Robin Thanks for using Fractdev, The Fractint Developer's Discussion List Post Message: fractdev@lists.xmission.com Get Commands: majordomo@lists.xmission.com "help" Administrator: twegner@phoenix.net Unsubscribe: majordomo@lists.xmission.com "unsubscribe fractdev" ------------------------------------------------------------------------------- From: "Tim Wegner" Subject: Re: (fractdev) Worklist and future directions Date: 03 Dec 1998 00:31:24 -0600 Kragen wrote: > xfractint is 32-bit on 32-bit machines, and 64-bit on 64-bit machines. Yes, but because Fractint and Xfractint share sources, Fractint holds Xfractint back. Once Fractint itself is 32 bits, then we can start taking advantage of it in both programs. Tim Thanks for using Fractdev, The Fractint Developer's Discussion List Post Message: fractdev@lists.xmission.com Get Commands: majordomo@lists.xmission.com "help" Administrator: twegner@phoenix.net Unsubscribe: majordomo@lists.xmission.com "unsubscribe fractdev" ------------------------------------------------------------------------------- From: "Tim Wegner" Subject: RE: (fractdev) Welcome Humberto Date: 03 Dec 1998 00:31:24 -0600 Hi Robin! I see you have a new identity! > I'm gane! How about tentatively suggesting a christmas or new year > rrelease for public beta code? seems like a handy date in the not too > near, not too distant future. It just depends on the team being ready. But I have many fewer reservations about publishing the public *source*, it is a bigger deal to publisg the beta *executable*. I have had beta source at my FTP site for a long time, but I hadn't kept it up because no one here in fracvtdev asked for it. > I can host stuff at ukonline as usual for the european side of things. If we post a beta executable, I think spanky and your site would be sufficient. Tim Thanks for using Fractdev, The Fractint Developer's Discussion List Post Message: fractdev@lists.xmission.com Get Commands: majordomo@lists.xmission.com "help" Administrator: twegner@phoenix.net Unsubscribe: majordomo@lists.xmission.com "unsubscribe fractdev" ------------------------------------------------------------------------------- From: "Tim Wegner" Subject: Re: (fractdev) Worklist and future directions Date: 03 Dec 1998 00:31:24 -0600 Tim Gilman wrote: > Future directions? I vote for a cleaner layer of abstraction seperating > Fractint from platform/gui. You are welcome to propose changes. But it will be hard if you have had to change the code to extensively. What made the Xfractint port work was that much of the code sources are exactly shared. But I am not telling you that is what you should do because you have different goals. When we finally get people working seriously in 32 bit environments the first order of business will be separating out the platform sprecific code. Then the platform independent part of the code could evolve faster because more people could contribute. Tim Thanks for using Fractdev, The Fractint Developer's Discussion List Post Message: fractdev@lists.xmission.com Get Commands: majordomo@lists.xmission.com "help" Administrator: twegner@phoenix.net Unsubscribe: majordomo@lists.xmission.com "unsubscribe fractdev" ------------------------------------------------------------------------------- From: "Tim Wegner" Subject: Re: (fractdev) Worklist and future directions Date: 03 Dec 1998 00:31:24 -0600 > As I'm new I would like to ask the list about what are the current > worklines (to avoid doing things twice and messing with others work). When you see the beta source you will see. Robin Bussell has added an "evolver" feature that perturbs parameters as well as sound (we need the sound ported to Linux!). George Martin has been overhauling the parser. Chuck Ebbert has been speeding up the parser. Jonathan Osuch has been facilitating all the above and done more changes than I can remember. The "what's new" gives the whole patch by patch history. I have added synchronous orbits, but feel like it is fairly worthless unless ported to 32 bits. Which brings us to ... > Other thing that I have been thinking for some time now. Should we think > of a 32 bit version of fractint? We've been *thinking* a whole lot. You need to understand that some of the developers have intgense professional lives, and speaking for myself, I'm not expanding my programming skill at work because I do mostly project management (seniority has its pitfalls). I have few hours outside of work and a daunting learning curve. There are dozens of routes to porting to 32 bits, we've discussed them a lot. I'm tired of discussing it, because words are cheap. What is needed are skilled people with the proper expertise willing to put in several thousand hours, not people who write on Robin's wish list "port to 32 bits please" I have bought Visual C/C++ 5 and Borland C++ Builder 3. But I have a big learning curve ahead of me before I can be productive, and limited outside of worktime. We could also port to djgpp. Any approach we take will take a huge performance hit until we port at least some of the assembler. But we could get something up and running based on the Xfractint ciode, which I have been keeping up. I also have been maintaing a version withg the integer math taken out. >> I keep wondering if the development wete > on a flat memory space and 32 bit mode things could go a lot faster and less > troublesome. A flat memory model is an absolute necessity. But don't expect speed at first. Tim Thanks for using Fractdev, The Fractint Developer's Discussion List Post Message: fractdev@lists.xmission.com Get Commands: majordomo@lists.xmission.com "help" Administrator: twegner@phoenix.net Unsubscribe: majordomo@lists.xmission.com "unsubscribe fractdev" ------------------------------------------------------------------------------- From: "Tim Wegner" Subject: Re: (fractdev) Welcome Humberto Date: 03 Dec 1998 00:31:24 -0600 Humberto asked: > OK, what would be best to post the patches or to send >them directly to > twegner@phoenix.net? I'd rather get them directly. But it would be better to wait until you get the latest version which I will upload shortly (by Saturday). We are up to 19.61 patch 58! I could probably merge your patches relative to an older version but I'd much prefer if you are working off the same version we are. > Yes I would like to discuss it and my tow inital cents are: place it in > one or two sites (like spanky and some friendly mirros) and allow the > download via HTTP only. A prety clear statement that it is beta code would > surely be better understood if on the download page that in some README that is > not alway read. Good suggestion. Also, it is very good to hear from you, it has been a few years! Tim Thanks for using Fractdev, The Fractint Developer's Discussion List Post Message: fractdev@lists.xmission.com Get Commands: majordomo@lists.xmission.com "help" Administrator: twegner@phoenix.net Unsubscribe: majordomo@lists.xmission.com "unsubscribe fractdev" ------------------------------------------------------------------------------- From: fjslman@wins.uva.nl (F.J. Slijkerman) Subject: Re: (fractdev) Worklist and future directions Date: 03 Dec 1998 14:46:37 +0100 (MET) Tim, > I have bought Visual C/C++ 5 and Borland C++ Builder 3. But I > have a big learning curve ahead of me before I can be productive, > and limited outside of worktime. Sorry for the intrusion, but maybe you'll appreciate some of my thoughts about this. If you feel you have little time and lots of work to do, I would recommend C++ Builder because it's much easier to use than Visual C, and it's cheaper so more developers can buy their copy (at least the Standard version!). I don't know about its portability though. If you are going to create a true 32-bit Windows version, you more or less have to make the fractal engine an "object" so you can create more than one instance of the engine. This is necessary for MDI and probably multi-threading. Also, it helps a lot to keep the code clean and easy to understand. Since the current Fractint code is 16-bit and single-document-based (iow: uses lots of global variables), I'd recommend you to dump it (well, as a matter of speaking) and starting from scratch. You can of course probably use large chunks of code from the old Fractint, but you'll have to abandon the structure of the code, I think, and use a modern object-oriented approach (which C++ Builder almost demands). It may seem silly or a waste of time to start again, but as a project manager you will know that developing new projects from scratch is much easier than poking around in old code and rewriting it -- and in the end it takes much less time, too. Plus you have the ability to separate the GUI code and the fractal engine. Just my $0.02... Best regards, Frederik. Thanks for using Fractdev, The Fractint Developer's Discussion List Post Message: fractdev@lists.xmission.com Get Commands: majordomo@lists.xmission.com "help" Administrator: twegner@phoenix.net Unsubscribe: majordomo@lists.xmission.com "unsubscribe fractdev" ------------------------------------------------------------------------------- From: Humberto Rossetti Baptista Subject: Re: (fractdev) Worklist and future directions Date: 03 Dec 1998 12:21:30 -0200 (EDT) On Thu, 3 Dec 1998, Tim Wegner wrote: > When you see the beta source you will see. Robin Bussell has > added an "evolver" feature that perturbs parameters as well as Great, if I it is what I imagine, one less item on my personal worklist :-)))) > sound (we need the sound ported to Linux!). George Martin has Sound and linux, hm. > been overhauling the parser. Chuck Ebbert has been speeding up > the parser. Anybody thinking in extending the parser to deal with orbit-like fractals? If not I'll get the hang of what's going on around the parser and will do something on this direction soon. > Jonathan Osuch has been facilitating all the above and > done more changes than I can remember. The "what's new" gives > the whole patch by patch history. My saturday seems SO far :-))) > I have added synchronous orbits, ? What are these ? > > Other thing that I have been thinking for some time now. Should we think > > of a 32 bit version of fractint? > > We've been *thinking* a whole lot. You need to understand that > some of the developers have intgense professional lives, and I never underestimated this (I run a little consulting firm myself working quite a lot, and unfortunatedly my development time is rather short also). Please if i sounded like demanding it was due to my "not-so-good" english. I love the work you've been doing in Fractint and do not want to see such a nice thing interfere negatively with anybody's live. > speaking for myself, I'm not expanding my programming skill at > work because I do mostly project management (seniority has its > pitfalls). I bet you're not the only one :-))) > I have few hours outside of work and a daunting learning > curve. There are dozens of routes to porting to 32 bits, we've > discussed them a lot. I'm tired of discussing it, because words are > cheap. Sorry to have brought this again, as I'm a newbie to the dev I prefer to be more annoying in the star to understand the work and the blend in without getting us all to "old" and "worn" points. > What is needed are skilled people with the proper expertise > willing to put in several thousand hours, not people who write on > Robin's wish list "port to 32 bits please" Agreed, I may be able to find one or two good coders to help with this (some students that have made arcade games both in DOS and Linux with gcc and djgcc) Does the list have a archive that can be searched? Or better does anyone have a list of the main dificulties involved on 32 bit ports or maybe a djgcc port? > I have bought Visual C/C++ 5 and Borland C++ Builder 3. But I > have a big learning curve ahead of me before I can be productive, > and limited outside of worktime. :-( Me too. > We could also port to djgpp. Any > approach we take will take a huge performance hit until we port at > least some of the assembler. yes. I guess that will be the worst part. > But we could get something up and > running based on the Xfractint ciode, which I have been keeping up. Yes. > >> I keep wondering if the development wete > > on a flat memory space and 32 bit mode things could go a lot faster and less > > troublesome. > > A flat memory model is an absolute necessity. But don't expect > speed at first. Yes. I was thinking only in terms of facilitating other people to put their peebles in the soup :-) That is why i like so much of the suggetion made previously in the list to use opens source tools to the job. []'s Humberto R. Baptista humberto@insite.com.br Insite - Solucoes Internet http://www.insite.com.br Thanks for using Fractdev, The Fractint Developer's Discussion List Post Message: fractdev@lists.xmission.com Get Commands: majordomo@lists.xmission.com "help" Administrator: twegner@phoenix.net Unsubscribe: majordomo@lists.xmission.com "unsubscribe fractdev" ------------------------------------------------------------------------------- From: Humberto Rossetti Baptista Subject: Re: (fractdev) Welcome Humberto Date: 03 Dec 1998 12:25:28 -0200 (EDT) On Thu, 3 Dec 1998, Tim Wegner wrote: > I'd rather get them directly. But it would be better to wait until you > get the latest version which I will upload shortly (by Saturday). We > are up to 19.61 patch 58! No problem (just holding my anxiety :-)))))) > Good suggestion. Also, it is very good to hear from you, it has > been a few years! Glad you remembered. Ah, BTW I've been doing a kind of HOWTO to help me to create new built in formulas and I hope to produce some other documents like this, I know it is not the main trend with such a fast parser ;-> but we could have a little library of short tutorials to help newcommers code in faster. I'll post it to the list sometime in these days (they're not long). []'s Humberto R. Baptista humberto@insite.com.br Insite - Solucoes Internet http://www.insite.com.br Thanks for using Fractdev, The Fractint Developer's Discussion List Post Message: fractdev@lists.xmission.com Get Commands: majordomo@lists.xmission.com "help" Administrator: twegner@phoenix.net Unsubscribe: majordomo@lists.xmission.com "unsubscribe fractdev" ------------------------------------------------------------------------------- From: Humberto Rossetti Baptista Subject: Re: (fractdev) Worklist and future directions Date: 03 Dec 1998 12:29:43 -0200 (EDT) Getting the drift of Frederik and Robin I'd like to ask if the abstraction/port to C++ / isolation of platform specific features have been discussed here a lot or not? I kept thinking on OO structures reading the code, and I REALLY would like to create a arithmetic class to deal w/ all the numeric engines FRINT has:-))) more 2c (is this a stone soup or a cent soup :>>>> ) []'s Humberto R. Baptista humberto@insite.com.br Insite - Solucoes Internet http://www.insite.com.br Thanks for using Fractdev, The Fractint Developer's Discussion List Post Message: fractdev@lists.xmission.com Get Commands: majordomo@lists.xmission.com "help" Administrator: twegner@phoenix.net Unsubscribe: majordomo@lists.xmission.com "unsubscribe fractdev" ------------------------------------------------------------------------------- From: fjslman@wins.uva.nl (F.J. Slijkerman) Subject: Re: (fractdev) Worklist and future directions Date: 03 Dec 1998 15:45:57 +0100 (MET) Humberto, > > Getting the drift of Frederik and Robin I'd like to ask if the > abstraction/port to C++ / isolation of platform specific features have been > discussed here a lot or not? > I believe the general attitude of the Fractint development team so far has been to port the code in its current form instead of rewriting it using OOP technology. Best regards, Frederik. Thanks for using Fractdev, The Fractint Developer's Discussion List Post Message: fractdev@lists.xmission.com Get Commands: majordomo@lists.xmission.com "help" Administrator: twegner@phoenix.net Unsubscribe: majordomo@lists.xmission.com "unsubscribe fractdev" ------------------------------------------------------------------------------- From: comdotatdotcom@csi.com Subject: RE: Re: (fractdev) Welcome Humberto Date: 03 Dec 1998 21:23 0000 > Glad you remembered. Ah, BTW I've been doing a kind of >HOWTO to help me >to create new built in formulas and I hope to produce some other >documents like >this Good idea! it's the initial getting used to the layout of things that is the worst every time I get back to fractint after a break of a few weeks or more. Cheers, Robinn Thanks for using Fractdev, The Fractint Developer's Discussion List Post Message: fractdev@lists.xmission.com Get Commands: majordomo@lists.xmission.com "help" Administrator: twegner@phoenix.net Unsubscribe: majordomo@lists.xmission.com "unsubscribe fractdev" ------------------------------------------------------------------------------- From: comdotatdotcom@csi.com Subject: (fractdev) Beta Date: 03 Dec 1998 20:12 0000 >Hi Robin! I see you have a new identity! Oh yes, sorry, I forgot to mention that, they closed my account at Lucent without warning (fair enough as I don't work there at the moment) and I think I've tied off all loose ends so far :-) I still have robin.b2@ukonline.co.uk too, but that's for other mailing lists. > I have many fewer >reservations about publishing the public *source*, it is a bigger deal >to publisg the beta *executable*. It might ease the support burden if I set up another list lke the wishlist for bug reports, that way there should a lot less duplication of reports, and no one get's deluged with mail! It would also be easy to provide a standardised form for bug reports so that details such as machine type, video card, cpu, OS, and all the other things that are usually needed. I've got some time off work next week so I'll knuckle down and get my stuff more finished with docs etc. Cheers, Robin. Thanks for using Fractdev, The Fractint Developer's Discussion List Post Message: fractdev@lists.xmission.com Get Commands: majordomo@lists.xmission.com "help" Administrator: twegner@phoenix.net Unsubscribe: majordomo@lists.xmission.com "unsubscribe fractdev" ------------------------------------------------------------------------------- From: comdotatdotcom@csi.com Subject: RE: Re: (fractdev) Worklist and future directions Date: 03 Dec 1998 20:52 0000 >> When you see the beta source you will see. Robin Bussell has >> added an "evolver" feature that perturbs parameters as well as > Great, if I it is what I imagine, one less item on my personal >worklist >:-)))) Glad you like the sound of that! I'd be interested to hear how your vision of a fractal evolver differs from my implimentation.... so that the best bits can be incorporated of course :-) Cheers, Robin Thanks for using Fractdev, The Fractint Developer's Discussion List Post Message: fractdev@lists.xmission.com Get Commands: majordomo@lists.xmission.com "help" Administrator: twegner@phoenix.net Unsubscribe: majordomo@lists.xmission.com "unsubscribe fractdev" ------------------------------------------------------------------------------- From: comdotatdotcom@csi.com Subject: RE: Re: (fractdev) Worklist and future directions Date: 03 Dec 1998 20:52 0000 >> When you see the beta source you will see. Robin Bussell has >> added an "evolver" feature that perturbs parameters as well as > Great, if I it is what I imagine, one less item on my personal >worklist >:-)))) Glad you like the sound of that! I'd be interested to hear how your vision of a fractal evolver differs from my implimentation.... so that the best bits can be incorporated of course :-) Cheers, Robin Thanks for using Fractdev, The Fractint Developer's Discussion List Post Message: fractdev@lists.xmission.com Get Commands: majordomo@lists.xmission.com "help" Administrator: twegner@phoenix.net Unsubscribe: majordomo@lists.xmission.com "unsubscribe fractdev" ------------------------------------------------------------------------------- From: Phil McRevis Subject: Re: (fractdev) Worklist and future directions Date: 03 Dec 1998 16:26:26 -0700 In article <199812022002.MAA55938@scv4.apple.com>, Tim Gilman writes: > Future directions? I vote for a cleaner layer of abstraction seperating > Fractint from platform/gui. POV-Ray is my inspiration! What's POV-Ray's abstraction? Looking though the fractint code, as well as the xfractint code, I suggested earlier division along the lines of some simple routines to handle dialogs from some new structures, some simple text scrolling window routines for the help file browsing and a graphics window I/O set for setpixel, etc. These are all easy to add to the existing code. The big chore in separating the last bit of UI from the code is to move to an event-oriented model of input rather than polling. Currently polling of the keyboard to abort an operation in progress is sprinkled liberally throughout the code. I think xfractint has a hack to get around this and process the message queue, but its just a hack. The code should be reorganized to handle the message-queue input model. On the subject of 32-bitness, I beliee Tim was working on an incremental change to use a DOS 32-bit extender and eliminate the 16-bit specific assembly. I'm not sure what the status of that is right now. Tim? I'm currently spending my free time working on other programming projects, but I did manage to put together a "to do" list for fractint's growth. There is also a web page maintained by a list member (I'm sorry, I've forgotten who!) that contains a "wish list" of items from users. Periodically that wish list is culled down to a reasonable list of "demands" :) and posted here to this list. -- Rich Thanks for using Fractdev, The Fractint Developer's Discussion List Post Message: fractdev@lists.xmission.com Get Commands: majordomo@lists.xmission.com "help" Administrator: twegner@phoenix.net Unsubscribe: majordomo@lists.xmission.com "unsubscribe fractdev" ------------------------------------------------------------------------------- From: Phil McRevis Subject: (fractdev) project list Date: 03 Dec 1998 16:27:42 -0700 This file attempts to list the works "in progress" at the time of the current fractint release (19.6) and the people working on them. It is hoped that this file will help developers coordinate their efforts and eliminate any duplicate effort. This file last updated January 29th, 1998 Project(s) Developer & Status PNG support TW 24-bit support RBa, TW, others? (just starting) SIMPLGIF improvements TW (encoder done, decoder needed) GIF encoder fix TW (done) Relaxing 2K image sizelimit TW (nearly done) float-only version TW (mostly done) synchronous orbits TW (under way) Formula parser improvements: C optimizer GM (under way) xfractint visual selection RT Parameter Evolver RBu, JO (mostly done) Memory use overhaul JO Pentium M-set assembly optimization DJ (approx. 1/2 done) Current Developers: ------------------- RBa Ron Barnett Win95/DOS (MS VC++ 1.52, MASM 6.0, MS VC++ 5.0) RBu Robin Bussell DJ Damien M. Jones GM George Martin <76440.1143@compuserve.com> Win95/DOS (Borland 3.1) JO Jonathan Osuch <73277.1432@compuserve.com> RT Rich Thomson Win95/DOS (Borland C++ Builder 1.0, 3.0), Solaris (unix/gcc) TW Tim Wegner Win95/DOS (MSC 7.0, MASM 6.1, djgpp), linux (gcc) Thanks for using Fractdev, The Fractint Developer's Discussion List Post Message: fractdev@lists.xmission.com Get Commands: majordomo@lists.xmission.com "help" Administrator: twegner@phoenix.net Unsubscribe: majordomo@lists.xmission.com "unsubscribe fractdev" ------------------------------------------------------------------------------- From: Phil McRevis Subject: (fractdev) to do list Date: 03 Dec 1998 16:28:18 -0700 This file contains a list of things that are on the "To Do" list of the fractint development team, practiced in the true Stone Soup tradition. Any item on this list is up for grabs and you are encouraged to use this as a starting point for your fractint contributions! This document is arranged by the functional area within fractint. The functional areas are listed in alphabetical order with each idea that's been suggested for improving the various sections. This file last updated March 20th, 1998 3D Support ---------- - Provide a way to plug-in a 3D driver by name; platform support determines what drivers are available. Fractint "native" 3D support available on all platforms. - Add arcball for iteractive manipulation of 3D viewing parameters (interactively manipulate viewed object by its bounding box) Arbitrary Precision ------------------- - Extend arbitrary precision arithmetic to other fractal types, most notably formula types - Allow arbitrary precision values to be entered into text field boxes and PAR files Deep Color Support ------------------ - 24-bit color modes - 32-bit color modes (RGB plus alpha) - PNG 24/32-bit output/input - Coloring pixels by formulas - Texture mapping (probably best integrated into formula coloring) Formula Parser -------------- - Add type information for expressions and variables - Add remainder (modulus) operator/function - Make C versions of corresponding assembly functions more efficient (reduce function call overhead, apply optimizations) - Provide a way to perform user-defined computations once per-image - Provide a way to define and call named user functions like regular functions Fractal Types ------------- - Add 2D cellular automata - Add continuously valued automata, a la CAPOW - Various 3D fractal types that could be added - Volume rendered fractal types (3D projection of quaternion julia set) Fractal Types: Cellular ------------- - Extend 1D cellular automata types beyond existing totalistic automata Help Files ---------- - Add formula tutorial - Add formula coloring methods tutorial - Add color editor tutorial - Add support to the help compiler for generating postscript / PDF / HTML output. - Add support for inlined images in help browser (initially present only in PS/PDF/HTML versions) Image Computation ----------------- - Provide anti-aliasing support directly (requires deep color) - Synchronous Orbits Iteration Image I/O --------- - Provide PNG support for both 8-bit and deeper video modes; handle gamma correction properly on output Platform Support ---------------- - Create "fractint GUI API" that abstracts out fractint's ideas of dialogs, text boxes, number boxes, keyboard navigation of dialogs, etc., so that ports to other windowing systems are more readily accomplished from the same body of source code a la xfractint/fractint as opposed to the completely native port of winfract (which lags); this will abstract out the interface from the computation engine, which enhances portablity (something fractint sorely lacks) to other platforms and also makes it easy to reuse fractint's compute engine. - Support for generalizing the assembly code to other architectures such as 68k, MIPS, etc., by segregating assembly code into architecture specific directories and integrating xfractint C emulation of assembly routines for all other architectures. - Support "video modes" by name/number/capability rather than by function key assignment. Since video modes vary by platform, and even on the same platform they can vary from user to user, a way of specifying the video mode in terms of its capability is needed. Something like video=x-res/y-res/depth, i.e. video=640/480/8. In a windowed environment, the video "mode" is used to guide window size, palette emulation, etc. Platform Support: DOS --------------------- - Eliminate overlays / move to 32-bit flat address space DOS protected mode app (gives up 286 support) - Option for displaying dialogs and text screens in graphics video mode with image save/restore; eliminates switching back and forth from text mode to graphics mode, saving wear and tear on monitors - port code to DOS version of "fractint GUI API" - Improve performance of native DOS 3D driver - Compute an image larger than the screen resolution and allow panning through the larger image by the screen. Platform Support: Win95/NT -------------------------- - Win32 port - long filename problems? - DirectX support? - 3D drivers: Direct3D / OpenGL - animation support? (AVI, MPEG, etc.) Platform Support: unix/X ------------------------ - Visual selection assumed root is 8-bit psuedocolor; improve to select appropriate visual for requested video mode (could be 24-bit with deep color support) - Eliminate use of curses and xterm in favor of native X-based text windows - Fix function key support (probably a free side-effect of previous item) - Use Xt for interface components of "fractint GUI API" - 3D drivers: OpenGL, PEX, native X - Generate /bin/sh scripts instead of MS-DOS bat files for "b" command - long filename problems? Platform Support: Mac/Amiga/BeOS/NeXT/other - Someone needs to do the port! :) Zoom Box -------- - Use XaoS like techniques to speedup the zoom box and/or initialize the screen from the zoomed section. Delivery-Date: Mon, 16 Mar 1998 15:43:22 -0700 Received: from dbank (dbank.ptc.com [199.6.17.9]) by woody (950413.SGI.8.6.12/950213.SGI.AUTOCF) via SMTP id PAA27065 for ; Mon, 16 Mar 1998 15:43:21 -0700 Received: from poster (poster.ptc.com) by dbank (5.x/SMI-SVR4) id AA13391; Mon, 16 Mar 1998 15:43:09 -0700 Received: from Erich.Triumf.CA by poster (5.x/SMI-SVR4-NN) id AA28994; Mon, 16 Mar 1998 17:43:06 -0500 Received: by triumf.ca (MX V4.0-1 VAX) id 187; Mon, 16 Mar 1998 14:34:51 PST Message-Id: <009C3471.20A0D478.187@triumf.ca> Hi Rich, You wrote: > Noel, one of the things I've been considering adding to fractint is > support for HTML output directly from fractint's "help compiler". I > suspected that you manually created the HTML (probably with the help > of some simple text processing scripts) from fractint's help files or > the fractint text documentation. I like the no-nonsense style of your > web version of the fractint docs. If you have any suggestions or > know of any 'gotchas' you learned while converting the docs to HTML, > I'd be happy to hear them. Unlike many fractint 'developer projects', > this is one I could actually do rather quickly since the help compiler > is a rather small program and doesn't suffer from all the overlay and > memory contortions of fractint. I've certainly had some thoughts about what I would have done differently had I been starting fresh. The first thing I would do is establish some sort of perl script or similar text processor to parse the complete document and substitute any angle brackets, quote characters, ampersands etc, with the accepted strings. Anything that means something in html should be replaced. Do that before you break anything into small files or add any real html code. Then I would come up with a mechanism to parse for internal page references and translate them into an internal url. This would imply that you have some sort of algorithm established for a file naming convention. This is also a very good idea on its own. I broke all the docs up into small files to take the load off the server, but I named all the docfiles somewhat arbitrarily, so consiquently I have to make all the links by hand. I don't know what you should use as a criteria for file breaks. Chapter headings is to coarse. I've also set a convention that equations and formulae get displayed in a different text. I use the
html for this. I think it is very useful. I don't know how you could set up a parser to know what is a formula or an equation unless you inserted some invisible tag in the docs. Maybe there is a way with a cgi-script to do all this on the fly and create an html file from sections of the main document. Then you could allow the cgi to do searches as well and produce an index on the search results and allow the user to select a page from the search results, pass it back to the cgi-script and build the requested page. I'm sure that there are a lot more things that I haven't thought about, and I'll pass them along to you as they occur to me. I think your idea for fractint to create it's own web docs is a good idea. Use any images you want off my pages if you think they are worth adding. Perhaps the little thumbnails of all the fractint fractal types could be inserted. Cheers, Noel Thanks for using Fractdev, The Fractint Developer's Discussion List Post Message: fractdev@lists.xmission.com Get Commands: majordomo@lists.xmission.com "help" Administrator: twegner@phoenix.net Unsubscribe: majordomo@lists.xmission.com "unsubscribe fractdev" ------------------------------------------------------------------------------- From: Phil McRevis Subject: (fractdev) Re: source code Date: 03 Dec 1998 16:30:47 -0700 Tim, Is the source being kept in a version control system like RCS or CVS? I would think this would be almost mandatory for some of the changes recently brought up again (UI/platform portability, 32-bitness). -- Legalize Adulthood! ``Ain't it funny that they all fire the pistol, at the wrong end of the race?''--PDBT legalize@xmission.com Thanks for using Fractdev, The Fractint Developer's Discussion List Post Message: fractdev@lists.xmission.com Get Commands: majordomo@lists.xmission.com "help" Administrator: twegner@phoenix.net Unsubscribe: majordomo@lists.xmission.com "unsubscribe fractdev" ------------------------------------------------------------------------------- From: Phil McRevis Subject: Re: (fractdev) C++ builder Date: 03 Dec 1998 16:34:48 -0700 I have C++ Builder too, and while it is a great product, I would not recommend attempting to rewrite all of fractint using Builder's object model. The problem is that Builder's object and GUI model is not portable to other compilers, much less other operating systems like unix/linux/Mac. This is why it is important to separate out the GUI from the computation. The GUI is going to be Xt/Xlib on linux/unix and Mac Toolbox on the Mac (or whatever their favorite new app interface is), homebrew on DOS, and Win32 on Win95/Win98/NT. Aside from some form of pixel abstraction for image rendering, fractint's GUI needs are relatively modest for a straight port/rewrite. -- Legalize Adulthood! ``Ain't it funny that they all fire the pistol, at the wrong end of the race?''--PDBT legalize@xmission.com Thanks for using Fractdev, The Fractint Developer's Discussion List Post Message: fractdev@lists.xmission.com Get Commands: majordomo@lists.xmission.com "help" Administrator: twegner@phoenix.net Unsubscribe: majordomo@lists.xmission.com "unsubscribe fractdev" ------------------------------------------------------------------------------- From: "Tim Wegner" Subject: (fractdev) Synchronous Orbits Date: 03 Dec 1998 21:14:41 -0600 Humberto asked: > > I have added synchronous orbits, > > ? What are these ? A few years ago a program was distributed called Fractal Witchcraft that claimed to be many times faster than Fractint for deep zooms. It turned out that the claims were legitimate. Our implementation is based on AlmondBread by Michael R. Ganss. See http://www.cs.tu-berlin.de/~rms/AlmondBread If this isn't current try searching for AlmondBread. The idea is to "fly" four points by generating their orbits in parallel. For some regions of a deep zoom, neighboring points create orbits that stay syhchronous (parallel) for many iterations. When the orbits start to go on separate paths, the algorithm interpolates between the points, creating estimated orbit values for that iteration for the in-between points, and continues. So the computational effort for all the iterations up to that point for the values in the interior of the region bounded by the original four points is saved. The results can be amazing - an order of magnitude faster in some cases. However there are several disadvantages. 1. The algorithm is not completely general, and needs tuning for different formulas. 2, The algorithm only starts being effective near the limit of double precision, so zooming can only be done for a limited range. 3. The algoritm is recursive, which puts a big strain on the limited stack of our medium memory model. I was able to overcome this, but had to hack up the code a bit. Another reason to go to a flat memory model. What obviously needs to happen is to move the SOI (Synchronous Orbits) code to arbitrary precision. This marriage has potential because of course arbitrary precision is free of zoom depth limitations, and is very slow, so could really use the speedup. I contemplated this, but it too needs to await rehosting Fractint to a better environment. At present the developer's version has two versions of SOI in fractint, neither one too well integrated (most options don't work). One uses double and one uses long double. Tim Thanks for using Fractdev, The Fractint Developer's Discussion List Post Message: fractdev@lists.xmission.com Get Commands: majordomo@lists.xmission.com "help" Administrator: twegner@phoenix.net Unsubscribe: majordomo@lists.xmission.com "unsubscribe fractdev" ------------------------------------------------------------------------------- From: "Tim Wegner" Subject: (fractdev) Platforms Date: 03 Dec 1998 21:14:42 -0600 Frederick wrote: > Sorry for the intrusion, but maybe you'll appreciate some of my > thoughts about this. I've followed your work and value your comments. Methinks we have discussed this before > If you feel you have little time and lots of > work to do, I would recommend C++ Builder because it's much easier > to use than Visual C, and it's cheaper so more developers can buy > their copy (at least the Standard version!). I don't know about > its portability though. You put your finger on the problem. You are right that C++ Builder would take less time to learn, but it would tie us to Borland. The most likely scenario is that if we clean up and restructure the underlying engine, lots of front ends will develop. Getting started is the hard part. I hate to start a project that I can't finish in a short period of time these days :-(. BTW VIsual C/C++ does not have a long double. I'm not sure about Borland. Tim Thanks for using Fractdev, The Fractint Developer's Discussion List Post Message: fractdev@lists.xmission.com Get Commands: majordomo@lists.xmission.com "help" Administrator: twegner@phoenix.net Unsubscribe: majordomo@lists.xmission.com "unsubscribe fractdev" ------------------------------------------------------------------------------- From: "Tim Wegner" Subject: (fractdev) Bouncing messages Date: 03 Dec 1998 21:14:41 -0600 When this list came back to life, several of you attempted to post messages that bounced because you sent the messages from a different email address than the one you are subscribed under. (This is a good idea - I see, but you don't, all the SPAM that get's sent to the list but doesn't make it!) I can post the bounced messages by hand, but I'd won't unless you explicitly ask me because there are a few of them. I'll help anyone who after some effort still can't post messages. Tim Thanks for using Fractdev, The Fractint Developer's Discussion List Post Message: fractdev@lists.xmission.com Get Commands: majordomo@lists.xmission.com "help" Administrator: twegner@phoenix.net Unsubscribe: majordomo@lists.xmission.com "unsubscribe fractdev" ------------------------------------------------------------------------------- From: "Tim Wegner" Subject: Re: (fractdev) Re: source code Date: 03 Dec 1998 21:23:52 -0600 Rich asked: > Is the source being kept in a version control system like RCS or CVS? > I would think this would be almost mandatory for some of the changes > recently brought up again (UI/platform portability, 32-bitness). We keep changes as context diffs in a linear sequence. This is very simple, non-automated but effective. The only tools are diff and patch. It works really well for us, and makes merging changes easy, but I probably will put the source in some kind of version control system especially if we start having multiple versions. I already maintain 1. Fractint 2. Xfractint (based on 1.) 3. Non-integer Fractint Tim Thanks for using Fractdev, The Fractint Developer's Discussion List Post Message: fractdev@lists.xmission.com Get Commands: majordomo@lists.xmission.com "help" Administrator: twegner@phoenix.net Unsubscribe: majordomo@lists.xmission.com "unsubscribe fractdev" ------------------------------------------------------------------------------- From: George Martin Subject: (fractdev) project list Date: 04 Dec 1998 03:21:59 -0500 Correction to the list: Current Developers: ------------------- . . . GM George Martin <76440.1143@compuserve.com> Win95/DOS (Borland 3.1) ^^^^^ should read Win3.1 George Thanks for using Fractdev, The Fractint Developer's Discussion List Post Message: fractdev@lists.xmission.com Get Commands: majordomo@lists.xmission.com "help" Administrator: twegner@phoenix.net Unsubscribe: majordomo@lists.xmission.com "unsubscribe fractdev" ------------------------------------------------------------------------------- From: Humberto Rossetti Baptista Subject: Evolver (was: RE: Re: (fractdev) Worklist and future directions) Date: 04 Dec 1998 11:34:40 -0200 (EDT) On Thu, 3 Dec 1998 comdotatdotcom@csi.com wrote: > >> When you see the beta source you will see. Robin Bussell has > >> added an "evolver" feature that perturbs parameters as well as > > Great, if I it is what I imagine, one less item on my personal > >worklist > >:-)))) > > Glad you like the sound of that! I'd be interested to hear how your > vision of a fractal evolver differs from my implimentation.... so that the > best bits can be incorporated of course :-) Sure, I was thinking of udoing something along the lines Richard Dawkinks (I guess, the author of "The Blind Watchmaker") has done: to put the original fractal in the center of a, say, 3 x 3 matix (on screen reduced by the "V" algorithm) and variations in two parameters aolong the axes x and y: like this: V x-1 y-1 V y-1 V x+1 y-1 V x-1 Orig. V V x+1 V x-1 y+1 V y+1 V x+1 y+1 (I also think that Protoshop in some recent version has something like this) The "x" and "y" above are parameters, byt I was yet trying to figure out a clean way to represent changes in all possible/interesting numerical parameters avaliable in Fractint (opposed to only changing the fractal type parameters, but only this would be very nice). []'sx Humberto R. Baptista humberto@insite.com.br Insite - Solucoes Internet http://www.insite.com.br Thanks for using Fractdev, The Fractint Developer's Discussion List Post Message: fractdev@lists.xmission.com Get Commands: majordomo@lists.xmission.com "help" Administrator: twegner@phoenix.net Unsubscribe: majordomo@lists.xmission.com "unsubscribe fractdev" ------------------------------------------------------------------------------- From: "Ron Barnett" Subject: RE: (fractdev) project list Date: 04 Dec 1998 08:39:05 -0500 My email address is now Ron Barnett . I started a new job as a senior project manager for a startup software company about 7 months ago, and I have been on the road about 90% of the time, so I haven't been able to devote much time to 24 bit color support. Hopefully that will change in January when I become the development site manager and will be mostly working out of an office in Albany, NY. To my knowledge there is only one general algorithm which works for all fractals and gives a result which looks similar to the normal iteration escape-base coloring. (I haven't tested them all :-), but none have failed so far. I call the method exponential smoothing, which I discovered in 1997. I have a beta program available on my web site to demonstrate some 24 bit coloring techniques. The help file contains a description of exponential smoothing. The site is http://www.hiddendimension.com I will post some details on the method soon. I have tried to maintain compatibility with the 256 color fractint maps because I feel this is one of the strengths of fractint. 24 bit color is provided by smooth interpolation using either RGB or HSI color spaces. There are numerous examples of fractals generated this way on my web site, including some conversions for fractint formulae. The test program can utilize fractint FRM files after minor modifications to the files. RBa > -----Original Message----- > From: owner-fractdev@lists.xmission.com > [mailto:owner-fractdev@lists.xmission.com]On Behalf Of Phil McRevis > Sent: Thursday, December 03, 1998 6:28 PM > To: fractdev@xmission.xmission.com > Subject: (fractdev) project list > > > This file attempts to list the works "in progress" at the time of the > current fractint release (19.6) and the people working on them. It is > hoped that this file will help developers coordinate their efforts and > eliminate any duplicate effort. > > This file last updated January 29th, 1998 > > Project(s) Developer & Status > -------------------------------------- > -------------------------------------- > PNG support TW > 24-bit support RBa, TW, others? (just starting) > SIMPLGIF improvements TW (encoder done, decoder needed) > GIF encoder fix TW (done) > Relaxing 2K image sizelimit TW (nearly done) > float-only version TW (mostly done) > synchronous orbits TW (under way) > Formula parser improvements: > C optimizer GM (under way) > xfractint visual selection RT > Parameter Evolver RBu, JO (mostly done) > Memory use overhaul JO > Pentium M-set assembly optimization DJ (approx. 1/2 done) > > Current Developers: > ------------------- > RBa Ron Barnett > Win95/DOS (MS VC++ 1.52, MASM 6.0, MS VC++ 5.0) > RBu Robin Bussell > DJ Damien M. Jones > GM George Martin <76440.1143@compuserve.com> > Win95/DOS (Borland 3.1) > JO Jonathan Osuch <73277.1432@compuserve.com> > RT Rich Thomson > Win95/DOS (Borland C++ Builder 1.0, 3.0), Solaris (unix/gcc) > TW Tim Wegner > Win95/DOS (MSC 7.0, MASM 6.1, djgpp), linux (gcc) > > -------------------------------------------------------------- > Thanks for using Fractdev, The Fractint Developer's Discussion List > Post Message: fractdev@lists.xmission.com > Get Commands: majordomo@lists.xmission.com "help" > Administrator: twegner@phoenix.net > Unsubscribe: majordomo@lists.xmission.com "unsubscribe fractdev" > Thanks for using Fractdev, The Fractint Developer's Discussion List Post Message: fractdev@lists.xmission.com Get Commands: majordomo@lists.xmission.com "help" Administrator: twegner@phoenix.net Unsubscribe: majordomo@lists.xmission.com "unsubscribe fractdev" ------------------------------------------------------------------------------- From: Humberto Rossetti Baptista Subject: Re: (fractdev) Worklist and future directions Date: 04 Dec 1998 11:56:26 -0200 (EDT) On Thu, 3 Dec 1998, Phil McRevis wrote: [...] > of input rather than polling. Currently polling of the keyboard to > abort an operation in progress is sprinkled liberally throughout the > code. I think xfractint has a hack to get around this and process the > message queue, but its just a hack. The code should be reorganized to > handle the message-queue input model. The fact that we're dealing with a single-{process/thread} makes things a little bit more complicated, but I guess we can limit the amount of polling and implement a real message queue on the code. > On the subject of 32-bitness, I beliee Tim was working on an > incremental change to use a DOS 32-bit extender and eliminate the > 16-bit specific assembly. I'm not sure what the status of that is > right now. Tim? Hm. I've listed a few items that have appeared here and that I remembered being an issue to port a 16bit DOS app to 32-bit flat model (optionally in a djgcc compatible fashion), specifficaly in the case o Fractint: - Assembly code (treatment of sements, direct access to mem. etc.)(gcc: any way to use Intel's syntax on gcc??) (optimizations to 32 bit processors (pentium class and above)?) - Video access: direct mem access, VESA is a real mode API isn't it? That would mean switching evey video access? I have read this in some list asking why Linux did not use VESA. There is an article on September Linux Jounal (page 54, if i remebember it) talking a little of this and making some paralels on SVGAlib (on linux) and Video access on DOS. - Overlays (is it hard??) - Compiler specific code (havent' seen _much_ of it except in regard to the points above) - Linker (may be aproblem together with the assembly issue) - Variable size/alignment (hm.. the first means new bugs, the second less speed unless optimized) (anything else?) > I'm currently spending my free time working on other programming > projects, but I did manage to put together a "to do" list for > fractint's growth. There is also a web page maintained by a list > member (I'm sorry, I've forgotten who!) that contains a "wish list" of > items from users. Periodically that wish list is culled down to > a reasonable list of "demands" :) and posted here to this list. Robin, on http://web.ukonline.co.uk/members/robin.b2/olig/fracwish.htm ? []'s Humberto R. Baptista humberto@insite.com.br Insite - Solucoes Internet http://www.insite.com.br Thanks for using Fractdev, The Fractint Developer's Discussion List Post Message: fractdev@lists.xmission.com Get Commands: majordomo@lists.xmission.com "help" Administrator: twegner@phoenix.net Unsubscribe: majordomo@lists.xmission.com "unsubscribe fractdev" ------------------------------------------------------------------------------- From: Humberto Rossetti Baptista Subject: Re: (fractdev) project list Date: 04 Dec 1998 12:06:20 -0200 (EDT) On Thu, 3 Dec 1998, Phil McRevis wrote: > This file attempts to list the works "in progress" at the time of the > current fractint release (19.6) and the people working on them. It is > hoped that this file will help developers coordinate their efforts and > eliminate any duplicate effort. > > This file last updated January 29th, 1998 [snip] January? ups. Are the "mostly done" done then? :-))))) OK, my peebles: new fractal types: * Generalized julia popcorn with functions and complex parameters (the images are sooo col. :-)) * Latoocarfians - new orbit like fractal based on Pickovers' book. * New drawing method, suggested name: diffusion. Based on an aticle I wrote for Computer & Graphics (supposed to be printed on issue 24(3)): this method draws the poing evenly ditribuited over the screen. Two options: a block filling option, that resemples solid guessing and a non filling option (fillcolor==0) that "sprays the points over (kind of a "fade in" from the bk color). All are done and docs ready, have debugged the first two and the last is being debugged (some problems in save/restore). The patches will be with tim by the weekend. BTW: the latoocarfians are the first, nad I promissed to myself, the last orbit-like fractal I do (unless in VERY special cases). I plan to use the parser to implement a "roll-your-own" orbit fractal in the next round :-) []'s Humberto R. Baptista humberto@insite.com.br Insite - Solucoes Internet http://www.insite.com.br Thanks for using Fractdev, The Fractint Developer's Discussion List Post Message: fractdev@lists.xmission.com Get Commands: majordomo@lists.xmission.com "help" Administrator: twegner@phoenix.net Unsubscribe: majordomo@lists.xmission.com "unsubscribe fractdev" ------------------------------------------------------------------------------- From: Humberto Rossetti Baptista Subject: Re: (fractdev) project list Date: 04 Dec 1998 12:06:20 -0200 (EDT) On Thu, 3 Dec 1998, Phil McRevis wrote: > This file attempts to list the works "in progress" at the time of the > current fractint release (19.6) and the people working on them. It is > hoped that this file will help developers coordinate their efforts and > eliminate any duplicate effort. > > This file last updated January 29th, 1998 [snip] January? ups. Are the "mostly done" done then? :-))))) OK, my peebles: new fractal types: * Generalized julia popcorn with functions and complex parameters (the images are sooo col. :-)) * Latoocarfians - new orbit like fractal based on Pickovers' book. * New drawing method, suggested name: diffusion. Based on an aticle I wrote for Computer & Graphics (supposed to be printed on issue 24(3)): this method draws the poing evenly ditribuited over the screen. Two options: a block filling option, that resemples solid guessing and a non filling option (fillcolor==0) that "sprays the points over (kind of a "fade in" from the bk color). All are done and docs ready, have debugged the first two and the last is being debugged (some problems in save/restore). The patches will be with tim by the weekend. BTW: the latoocarfians are the first, nad I promissed to myself, the last orbit-like fractal I do (unless in VERY special cases). I plan to use the parser to implement a "roll-your-own" orbit fractal in the next round :-) []'s Humberto R. Baptista humberto@insite.com.br Insite - Solucoes Internet http://www.insite.com.br Thanks for using Fractdev, The Fractint Developer's Discussion List Post Message: fractdev@lists.xmission.com Get Commands: majordomo@lists.xmission.com "help" Administrator: twegner@phoenix.net Unsubscribe: majordomo@lists.xmission.com "unsubscribe fractdev" ------------------------------------------------------------------------------- From: Humberto Rossetti Baptista Subject: Re: (fractdev) C++ builder Date: 04 Dec 1998 12:30:01 -0200 (EDT) On Thu, 3 Dec 1998, Phil McRevis wrote: [...] > unix/linux/Mac. This is why it is important to separate out the GUI > from the computation. The GUI is going to be Xt/Xlib on linux/unix > and Mac Toolbox on the Mac (or whatever their favorite new app > interface is), homebrew on DOS, and Win32 on Win95/Win98/NT. Agreed, I woudn't be good to compromise with specific compiler/application frameworks or classes in Fractint. > Aside from some form of pixel abstraction for image rendering, fractint's > GUI needs are relatively modest for a straight port/rewrite. Is it? I guess i do not know the code enought. I would like to see (or do if time permits) the abtraction with linkd to some items in the todo list and, for instance, fast (possibly hw linked) {blok,area}-filling routines etc. []'s Humberto R. Baptista humberto@insite.com.br Insite - Solucoes Internet http://www.insite.com.br Thanks for using Fractdev, The Fractint Developer's Discussion List Post Message: fractdev@lists.xmission.com Get Commands: majordomo@lists.xmission.com "help" Administrator: twegner@phoenix.net Unsubscribe: majordomo@lists.xmission.com "unsubscribe fractdev" ------------------------------------------------------------------------------- From: Humberto Rossetti Baptista Subject: Re: (fractdev) Synchronous Orbits Date: 04 Dec 1998 13:11:53 -0200 (EDT) Hm. This sound great, and by what yo've written I gues that is what the other program does. BTW: i war discussing fractint with some friends from a Parallel Computing Lab and they've asked what kind of support/hook it has beccause fractals are _so_ easy to distribute among processores, pipelines, vector registers, machines etc. I am (for some time now) thinking about a _very_ simple way to put several machines working on a same images autommatically (work distribution) ans via network, but I keep wondering if we can come up with a code organization/API/abstratcion that can suppor multiprocessors, pipelining and vector computing. This is very similar to the syncronous orbit, except fro the interpolation part, I mean: if we did the work by chunks some "magic trick" could come up to split the work and/or to make similar operations "pipeline" friendly and/or to alocare chunks to vector machines. Have you discussed along this lines? Any ideas? []'s Humberto R. Baptista humberto@insite.com.br Insite - Solucoes Internet http://www.insite.com.br Thanks for using Fractdev, The Fractint Developer's Discussion List Post Message: fractdev@lists.xmission.com Get Commands: majordomo@lists.xmission.com "help" Administrator: twegner@phoenix.net Unsubscribe: majordomo@lists.xmission.com "unsubscribe fractdev" ------------------------------------------------------------------------------- From: Humberto Rossetti Baptista Subject: Re: (fractdev) Re: source code Date: 04 Dec 1998 13:14:47 -0200 (EDT) On Thu, 3 Dec 1998, Tim Wegner wrote: [...] > already maintain > > 1. Fractint > 2. Xfractint (based on 1.) > 3. Non-integer Fractint I haven't looked to the Xfractint nor the non-integer, but aren't they "mergeable" with the original DOS? Except for a bunch of ptatform specific stuff in separate file of course. I keep thinking of the linux kernel tree. It is really something to be able to compile and prepare kernel in such a number of patforms and yu always get ALL the code to all platforms. []'s Humberto R. Baptista humberto@insite.com.br Insite - Solucoes Internet http://www.insite.com.br Thanks for using Fractdev, The Fractint Developer's Discussion List Post Message: fractdev@lists.xmission.com Get Commands: majordomo@lists.xmission.com "help" Administrator: twegner@phoenix.net Unsubscribe: majordomo@lists.xmission.com "unsubscribe fractdev" ------------------------------------------------------------------------------- From: Humberto Rossetti Baptista Subject: RE: (fractdev) project list Date: 04 Dec 1998 13:20:55 -0200 (EDT) On Fri, 4 Dec 1998, Ron Barnett wrote: > To my knowledge there is only one general algorithm which works for all > fractals and gives a result which looks similar to the normal iteration > escape-base coloring. (I haven't tested them all :-), but none have failed > so far. I call the method exponential smoothing, which I discovered in 1997. Hm. Moving average exponential smoothing? Or exponential smoothing over all points? how does it maps from iterations -> color? > I have a beta program available on my web site to demonstrate some 24 bit > coloring techniques. The help file contains a description of exponential > smoothing. The site is http://www.hiddendimension.com I will post some > details on the method soon. I have tried to maintain compatibility with the > 256 color fractint maps because I feel this is one of the strengths of > fractint. 24 bit color is provided by smooth interpolation using either RGB > or HSI color spaces. There are numerous examples of fractals generated this > way on my web site, including some conversions for fractint formulae. The > test program can utilize fractint FRM files after minor modifications to > the files. Would it help to have a HLS/HSI/HSB mode on the pallet editor? I could do this in a short time if it is helpful. And what do you (list?) think about other means of mapping from Iterations -> colors? Formulas? Tranpareny controls over multiple methods? Ah, I forgot to mention:my diffusion drawing scheme can be used to interpolate a image and help with the anti-alias regardless of the original drawing method. []'s Humberto R. Baptista humberto@insite.com.br Insite - Solucoes Internet http://www.insite.com.br Thanks for using Fractdev, The Fractint Developer's Discussion List Post Message: fractdev@lists.xmission.com Get Commands: majordomo@lists.xmission.com "help" Administrator: twegner@phoenix.net Unsubscribe: majordomo@lists.xmission.com "unsubscribe fractdev" ------------------------------------------------------------------------------- From: "Damien M. Jones" Subject: Re: (fractdev) Platforms Date: 04 Dec 1998 09:57:38 -0600 Tim, - BTW VIsual C/C++ does not have a long double. I'm not sure about - Borland. I knew VC++ 4 didn't have it, but I thought it had been restored in later versions. I will be very sorry to hear it has not. - (This is a good idea - I see, but you don't, all the SPAM that get's - sent to the list but doesn't make it!) Well, I may not see it for FractDev, but I see it for Fractal-Art and UltraFractal... makes me glad I'm using a similar option, else those lists would be spammed regularly. Damien M. Jones \\ dmj@fractalus.com \\ Fractalus Galleries & Info: \\ http://www.fractalus.com/ Please do not post my e-mail address on a web site or in a newsgroup. Thank you. Thanks for using Fractdev, The Fractint Developer's Discussion List Post Message: fractdev@lists.xmission.com Get Commands: majordomo@lists.xmission.com "help" Administrator: twegner@phoenix.net Unsubscribe: majordomo@lists.xmission.com "unsubscribe fractdev" ------------------------------------------------------------------------------- From: "Damien M. Jones" Subject: Re: (fractdev) Parallel Processing Date: 04 Dec 1998 10:12:09 -0600 Humberto, I once wrote a fractal generator for a dual-processor system, where the processors were not quite equal in speed. The naive approach is to assume you have N processors, so the image should be divided into N portions and assigned to each processor. Even if all the processors are equal in speed, this assumes it takes the same amount of time to render each piece, which is of course not true for most fractal images. What I did was a little different. I kept a single variable common to all processors that indicated the "next" line that needed to be drawn. When a processor is looking for a line to be drawn, it atomically fetches and increments this counter, and then begins drawing the line. For the system I was programming, using a shared memory location like this was cheap, and I needed real-time performance. In other environments, communication may be more expensive, but real-time performance is not required. I would suggest increasing the "unit size" from a single line to four or eight lines. This would also allow guessing logic to be applied easily to the strip assigned to each processor. Damien M. Jones \\ dmj@fractalus.com \\ Fractalus Galleries & Info: \\ http://www.fractalus.com/ Please do not post my e-mail address on a web site or in a newsgroup. Thank you. Thanks for using Fractdev, The Fractint Developer's Discussion List Post Message: fractdev@lists.xmission.com Get Commands: majordomo@lists.xmission.com "help" Administrator: twegner@phoenix.net Unsubscribe: majordomo@lists.xmission.com "unsubscribe fractdev" ------------------------------------------------------------------------------- From: comdotatdotcom@csi.com Subject: (fractdev) RE: Evolver Date: 04 Dec 1998 17:54 0000 >"V" algorithm) and variations in two parameters aolong the axes x and >y: like >this: > > V x-1 y-1 V y-1 V x+1 y-1 > V x-1 Orig. V V x+1 > V x-1 y+1 V y+1 V x+1 y+1 > The "x" and "y" above are parameters, Great minds think alike apparantly :-) This is the present setup of the evolver, the matrix can be any odd number in size and fractal type is about the only thing it doesn't change! Random parameter scrambling is also available, I'm still mulling over various possibilities for 'breeding' images, though these all require storing complete parameter sets for the images and would eat too much ram at present I suspect. I like the sound of your diffusion plotting method, I had a go at something similar recently using modulo arithmetic and a pair of magic numbers.... I couldn't get it to work at all resoutions due to me borrowing somebody elses algorithm without compreheding it fully :-) Have you tested the diffusion method with small amounts of image panning? this causes very radical aspect ratio image segments to be calculated and broke my attempt at a new plotting method quite thoroughly! Cheers, Robin. Thanks for using Fractdev, The Fractint Developer's Discussion List Post Message: fractdev@lists.xmission.com Get Commands: majordomo@lists.xmission.com "help" Administrator: twegner@phoenix.net Unsubscribe: majordomo@lists.xmission.com "unsubscribe fractdev" ------------------------------------------------------------------------------- From: comdotatdotcom@csi.com Subject: RE: RE: (fractdev) project list Date: 04 Dec 1998 18:07 0000 Hi Ron, >I haven't been able to devote much time to 24 bit color support. >Hopefully that will change in January I was hoping to put in some hooks for 24bit colour testing soon, basically by having variables for red,green,and blue which could be assigned values in the formula parser and then used to colour the pixel after the formula has bailed out. But I need to comprehend the parser properly first! the rest is allready there thanks to Bert Tyler. Addressing the CLUT from within the parser should be pretty straight forward too.....maybe! Cheers, Robin. Thanks for using Fractdev, The Fractint Developer's Discussion List Post Message: fractdev@lists.xmission.com Get Commands: majordomo@lists.xmission.com "help" Administrator: twegner@phoenix.net Unsubscribe: majordomo@lists.xmission.com "unsubscribe fractdev" ------------------------------------------------------------------------------- From: comdotatdotcom@csi.com Subject: RE: RE: (fractdev) project list Date: 04 Dec 1998 18:30 0000 > And what do you (list?) think about other means of mapping >from iterations -> colors? Formulas? Tranpareny controls over >multiple methods? Formulae, definately. The Parser's already there, keep the pallette as well but different methods can do different things with it. Don't forget that people are managing to do amazing things with all sorts of orbit behavior checking, not just iterations! Robin. Thanks for using Fractdev, The Fractint Developer's Discussion List Post Message: fractdev@lists.xmission.com Get Commands: majordomo@lists.xmission.com "help" Administrator: twegner@phoenix.net Unsubscribe: majordomo@lists.xmission.com "unsubscribe fractdev" ------------------------------------------------------------------------------- From: comdotatdotcom@csi.com Subject: RE: Re: (fractdev) Synchronous Orbits Date: 04 Dec 1998 18:24 0000 > I am (for some time now) thinking about a _very_ simple way to >put >several machines working on a same images autommatically (work Hi Humberto, I've been wanting this to happen to fractint for year now! I had thought along the lines of just using disk video mode, a shared file, and a slightly modified single pass mode (just check the leftmost pixel in each row, if it's color 0 then set it to grab the row, cmpute a row of pixels, write them back and so on... not optimal but possibly very easy, just ignore the odd occasion when two cpus grab the same row ) Once the calculation engine is serperated from the UI then I suppose it gets much easier, just replace the user with a segmenter/dispatcher routine. Cheers, Robin. Thanks for using Fractdev, The Fractint Developer's Discussion List Post Message: fractdev@lists.xmission.com Get Commands: majordomo@lists.xmission.com "help" Administrator: twegner@phoenix.net Unsubscribe: majordomo@lists.xmission.com "unsubscribe fractdev" ------------------------------------------------------------------------------- From: Phil McRevis Subject: Re: (fractdev) Re: source code Date: 04 Dec 1998 14:09:54 -0700 In article <199812040323.VAA01599@voyager.c-com.net>, "Tim Wegner" writes: > [manual versioning via diff/patch...] I probably will put the source in > some kind of version > control system especially if we start having multiple versions. I > already maintain If it helps, I can offer a public CVS repository. (What's CVS? See below) What's nice about this is that you can control access by assigning usernames and passwords (including a published user/password pair for read-only access to the source) and giving active developers the power to update/checking their code remotely at any time. It also automates the versioning. To make a "release" you just tag all the code, then the "release" is whatever version was tagged. They are using it for the GPL licensed Harvest code and it works well. RCS and CVS are available for DOS/Win32 and for unix with source under GPL as well. -- Rich CVS/RCS - What is it? RCS is a version control system that managed file versions as a collection of context diffs against the most recent version. RCS lets you branch versions so that multiple versions of the same file can exist concurrently in the version control system. Each revision entered into the system has a timestamp, userid of the person making the change, and an optional freeform log message. RCS deals exclusively with individual files and their revision histories, it has no concept of a group of related files or a hierarchical group of related directories containing source files. CVS is a layer of source code management built on top of RCS, ultimately invoking RCS commands on the revision trails and source files. CVS deals with entire directories and related groups of files however. CVS also provides the ability to check out source code over a network by converting to a CVS server on the internet. The transfer of source code is accomplished by compressing the source streams before transfer and also handles end-of-line differences between the server machine and the client machine. This means that when you checkout unix source code remotely from a CVS server onto a local DOS (or Win32) box, all the source files have the DOS EOL convention. When you checkin a file from your DOS box, the EOL is switched back to whatever is native for the original source file. -- Legalize Adulthood! ``Ain't it funny that they all fire the pistol, at the wrong end of the race?''--PDBT legalize@xmission.com Thanks for using Fractdev, The Fractint Developer's Discussion List Post Message: fractdev@lists.xmission.com Get Commands: majordomo@lists.xmission.com "help" Administrator: twegner@phoenix.net Unsubscribe: majordomo@lists.xmission.com "unsubscribe fractdev" ------------------------------------------------------------------------------- From: Phil McRevis Subject: Re: (fractdev) C++ builder Date: 04 Dec 1998 14:30:42 -0700 In article , Humberto Rossetti Baptista writes: > > Aside from some form of pixel abstraction for image rendering, fractint's > > GUI needs are relatively modest for a straight port/rewrite. > > Is it? I've browsed the code some, but mostly I have just been thinking of how fractint deals with everything input-wise. It either does some modest screen/mouse graphics, or it uses a text-only mechanism. As usual, its sloth not technology that holds us back :) -- Legalize Adulthood! ``Ain't it funny that they all fire the pistol, at the wrong end of the race?''--PDBT legalize@xmission.com Thanks for using Fractdev, The Fractint Developer's Discussion List Post Message: fractdev@lists.xmission.com Get Commands: majordomo@lists.xmission.com "help" Administrator: twegner@phoenix.net Unsubscribe: majordomo@lists.xmission.com "unsubscribe fractdev" ------------------------------------------------------------------------------- From: "Tim Wegner" Subject: Re: (fractdev) Re: source code Date: 04 Dec 1998 19:25:45 -0600 Humberto asked: > I haven't looked to the Xfractint nor the non-integer, but aren't they > "mergeable" with the original DOS? Except for a bunch of ptatform specific stuff > in separate file of course. I keep thinking of the linux kernel tree. It is > really something to be able to compile and prepare kernel in such a number of > patforms and yu always get ALL the code to all platforms. I didn't say quite enough. Fractint and Xfractint absolutely share source with NO changes. You can copy the fractint source on top of the Xfractint source and compile it. Some fractint files are not used (for example, NONE of the assembler is used) and Xfractint has some additional files. There is code of the form #ifdef XFRACT ... #else ... #endif to allow for places in the source where Xfractint must be different from the DOS version. We could probably clean up a lot of those. The ugliest thing is that Fractint naively saves parameters by writing the binary values to disk. Xfractint has some code that translates the byte order and converts numbers to IEEE. When we finally abandon DOS I intend also to abandon GIF and use PNG, and redo the method of saving parameters in ASCII or other portable scheme (something like imbedding the PAR entry in the image instead of a binary image of the fractal info structure. I have even reserved a PNG chunk name (fRAc) for this purpose. This source compatability between Xfractint and Fractint has had several tremendous advantages. For a time we received code updates from the Xfractint folks that Fractint immediately inherited, and vice versa. It is an easy matter to keep of Xfractint. The Motif Fractint port suffered death by neglect because it differed sufficiently from Fractint (dramatically in fact) that we couldn't maintain it. The down side is that the Xfractint interface is very idiosyncratic and un-X-like. Because it is the fractint interface, except that the graphics and text screens are in different windows. The non-integer version came about because I was trying to save resources to use in adding PNG support. Plus it is clear to me integer math has no future, first because it is no longer faster than floating point, and second because integer math will almost certainly not survive any port to a flat memory model because the guts are in assembler. (Having said that, if someone cared, the assemble could be ported, at least to Intel platforms.) Sofar, though, the team has not agreed to give up integer math yet, although I believe that everyone agrees that we will abandon it at the ame time we abandon the medium memory model. The non-integer version has many code differences from the regular version, and is not really mergeable. But it is not too hard to maintain. I patch in every diff, and simple deal with all the failed hunks. Not to bad for small changes. I truly believe that once we are cut loose from DOS we will be able to do a major reorganization of the architecture in a short order. I don't think of this as abandoning Fractint and starting over as Frederick suggested, but my view is not so different than his. In early years Bert Tyler and I took turns making serious global restructurings. We could, for example, get rid of the global vatriables in a few weekends of work if we had already abandoned the assembler. Tim Thanks for using Fractdev, The Fractint Developer's Discussion List Post Message: fractdev@lists.xmission.com Get Commands: majordomo@lists.xmission.com "help" Administrator: twegner@phoenix.net Unsubscribe: majordomo@lists.xmission.com "unsubscribe fractdev" ------------------------------------------------------------------------------- From: "Tim Wegner" Subject: (fractdev) Parallel processing (was Synchronous Orbits) Date: 04 Dec 1998 19:25:45 -0600 > I am (for some time now) thinking about a _very_ simple way to put > several machines working on a same images autommatically (work distribution) ans > via network, but I keep wondering if we can come up with a code > organization/API/abstratcion that can suppor multiprocessors, pipelining and > vector computing. This is very easy to do, although what I have in mind is less sophisticated than you have in mind. The "divide and conquor" mechanism in the command generates a batch file that builds images piecewise. All you need is a shell script that can cause fractint (Xfractint) to execute remotely, each piece on a separate processor, and return the GIF file. This doesn't require any changes to fractint itself. Thge logic to divide up, process, and recombine the pieces is already there. The value of this approach is that the method of starting processes on different processors is machine dependent, so not a good candidate to put *inside* fractint, hench the shell script approach. Tim Thanks for using Fractdev, The Fractint Developer's Discussion List Post Message: fractdev@lists.xmission.com Get Commands: majordomo@lists.xmission.com "help" Administrator: twegner@phoenix.net Unsubscribe: majordomo@lists.xmission.com "unsubscribe fractdev" ------------------------------------------------------------------------------- From: "Tim Wegner" Subject: Re: (fractdev) C++ builder Date: 04 Dec 1998 19:25:45 -0600 Rich wrote: > I've browsed the code some, but mostly I have just been thinking of > how fractint deals with everything input-wise. It either does some > modest screen/mouse graphics, or it uses a text-only mechanism. > > As usual, its sloth not technology that holds us back :) Actually, I've found your comments encouraging. It probably would not be hard to make a simple fractint GUI interface, and also would not be hard to port the whole source as long as it was a single document with no multi-threading. I may have talked myself out something I could do. Tim Thanks for using Fractdev, The Fractint Developer's Discussion List Post Message: fractdev@lists.xmission.com Get Commands: majordomo@lists.xmission.com "help" Administrator: twegner@phoenix.net Unsubscribe: majordomo@lists.xmission.com "unsubscribe fractdev" ------------------------------------------------------------------------------- From: "Tim Wegner" Subject: Re: (fractdev) Worklist and future directions Date: 04 Dec 1998 19:25:46 -0600 > The fact that we're dealing with a single-{process/thread} makes things > a little bit more complicated, but I guess we can limit the amount of polling > and implement a real message queue on the code. When Bert Tyler wrote Winfract (The WIndows 3.1 port, now hopelessly obsolete) he found that we have enough checks for keypresses that he could check for events inside the keypress check routine. This actually worked really well, though it probably makes real Windows programmers shudder Winfract actually shared most of Fractint's code. > Hm. I've listed a few items that have appeared here and that I > remembered being an issue to port a 16bit DOS app to 32-bit flat model > (optionally in a djgcc compatible fashion), specifficaly in the case o Fractint: > > - Assembly code (treatment of sements, direct access to mem. etc.)(gcc: > any way to use Intel's syntax on gcc??) (optimizations to 32 bit processors > (pentium class and above)?) Assembly code needs to be rewritten or else Fractint will be slower. But all the integer code can go, and the floating point code may not be hard to port. Plus we can do this later and start with the Xfractint C. > - Video access: direct mem access, VESA is a real mode API isn't it? > That would mean switching evey video access? I have read this in some list > asking why Linux did not use VESA. There is an article on September Linux Jounal > (page 54, if i remebember it) talking a little of this and making some paralels > on SVGAlib (on linux) and Video access on DOS. The easiest possible port would be to djgpp. To do this: 1. Merge the non-integer code with Xfractint . 2. Cut out all the Xwindows stuff, and add video support via the Linux SVGA lib. (Did you know that Xfractint does not need Xwindows? Invoke Xfractint -disk and the program works in 100% character mode.) 3. Port the the Linux version to djgpp, using the SVGALIB. I don't think we should reinvent the well. If we want a DOS version, we should use existing SVGA libraries. Of course for all GUI ports we write to a virtual screen. I believe it is possible to add assembler back in that would be portable between Linux and DOS. Some people might think this is a waste a time, but once Fractint was ported to 32 bits flat memory, even though DOS or non-X Linux, we could then get rid of all the memory saving junk like re- used arrays, get rid of global variables, etc. etc., and evolve a decent underlying engine. > - Overlays (is it hard??) Non issue! Flat memory models allow big footprints! No 640K limit. Just make one big executable that would eat 2 mb or so. > - Compiler specific code (havent' seen _much_ of it except in regard to > the points above) This is already identified and #ifdef'ed out in Xfractint. > - Linker (may be aproblem together with the assembly issue) ???? > - Variable size/alignment (hm.. the first means new bugs, the second > less speed unless optimized) The main issue is the way parameters are written inside GIFs, which I have addressed elsewhere. Tim Thanks for using Fractdev, The Fractint Developer's Discussion List Post Message: fractdev@lists.xmission.com Get Commands: majordomo@lists.xmission.com "help" Administrator: twegner@phoenix.net Unsubscribe: majordomo@lists.xmission.com "unsubscribe fractdev" ------------------------------------------------------------------------------- From: "Dean-Christian Strik" Subject: Re: (fractdev) Welcome Humberto Date: 03 Dec 1998 19:41:17 +0100 I'm sorry to say, but I think it's getting all to private for a 'public' beta... I don't think it's right to almost keep it's existence a secret... -- Dean-Christian Strik ICQ: 11760568 dean2@bigfoot.com cstrik.isg@hetnet.nl The nice thing of standards is that there are so many to choose from. -- Andrew S. Tanenbaum -----Original Message----- Humberto asked: > OK, what would be best to post the patches or to send >them directly to > twegner@phoenix.net? I'd rather get them directly. But it would be better to wait until you get the latest version which I will upload shortly (by Saturday). We are up to 19.61 patch 58! I could probably merge your patches relative to an older version but I'd much prefer if you are working off the same version we are. > Yes I would like to discuss it and my tow inital cents are: place it in > one or two sites (like spanky and some friendly mirros) and allow the > download via HTTP only. A prety clear statement that it is beta code would > surely be better understood if on the download page that in some README that is > not alway read. Good suggestion. Also, it is very good to hear from you, it has been a few years! Tim Thanks for using Fractdev, The Fractint Developer's Discussion List Post Message: fractdev@lists.xmission.com Get Commands: majordomo@lists.xmission.com "help" Administrator: twegner@phoenix.net Unsubscribe: majordomo@lists.xmission.com "unsubscribe fractdev" Thanks for using Fractdev, The Fractint Developer's Discussion List Post Message: fractdev@lists.xmission.com Get Commands: majordomo@lists.xmission.com "help" Administrator: twegner@phoenix.net Unsubscribe: majordomo@lists.xmission.com "unsubscribe fractdev" ------------------------------------------------------------------------------- From: "Dean-Christian Strik" Subject: Re: (fractdev) Worklist and future directions Date: 03 Dec 1998 19:28:38 +0100 Problem's just most people haven't converted to unices yet... :) -- Dean-Christian Strik ICQ: 11760568 dean2@bigfoot.com cstrik.isg@hetnet.nl The nice thing of standards is that there are so many to choose from. -- Andrew S. Tanenbaum -----Original Message----- >On Wed, 2 Dec 1998, Humberto Rossetti Baptista wrote: >> Other thing that I have been thinking for some time now. Should we think >> of a 32 bit version of fractint? > >xfractint is 32-bit on 32-bit machines, and 64-bit on 64-bit machines. > >-- > Kragen Sitaker >It frightens the daylights out of me whenever I hear people proclaim that >the less knowledge our children have access to, the better. >-- Duane Lindstrom, at > > >-------------------------------------------------------------- >Thanks for using Fractdev, The Fractint Developer's Discussion List >Post Message: fractdev@lists.xmission.com >Get Commands: majordomo@lists.xmission.com "help" >Administrator: twegner@phoenix.net >Unsubscribe: majordomo@lists.xmission.com "unsubscribe fractdev" Thanks for using Fractdev, The Fractint Developer's Discussion List Post Message: fractdev@lists.xmission.com Get Commands: majordomo@lists.xmission.com "help" Administrator: twegner@phoenix.net Unsubscribe: majordomo@lists.xmission.com "unsubscribe fractdev" ------------------------------------------------------------------------------- From: "Dean-Christian Strik" Subject: Re: (fractdev) Welcome Humberto Date: 03 Dec 1998 19:35:40 +0100 Tim W. wrote: > Hi Robin! I see you have a new identity! Seems more like an internet overload ;-) >> I'm gane! How about tentatively suggesting a christmas or new year >> rrelease for public beta code? seems like a handy date in the not too >> near, not too distant future. > > It just depends on the team being ready. But I have many fewer > reservations about publishing the public *source*, it is a bigger deal > to publisg the beta *executable*. I have had beta source at my FTP > site for a long time, but I hadn't kept it up because no one here in > fracvtdev asked for it. I don't see the problem with beta executables, really. I know some beta testers who don't even know how to write a dos batch file.... executables are a lot more attractive to many people. Is it just that it's because of the beta? -- Dean-Christian Strik ICQ: 11760568 dean2@bigfoot.com cstrik.isg@hetnet.nl The nice thing of standards is that there are so many to choose from. -- Andrew S. Tanenbaum Thanks for using Fractdev, The Fractint Developer's Discussion List Post Message: fractdev@lists.xmission.com Get Commands: majordomo@lists.xmission.com "help" Administrator: twegner@phoenix.net Unsubscribe: majordomo@lists.xmission.com "unsubscribe fractdev" ------------------------------------------------------------------------------- From: "Dean-Christian Strik" Subject: Re: (fractdev) Worklist and future directions Date: 03 Dec 1998 19:27:54 +0100 Hi, >form of dialogs, etc. The biggies left for me are file-parsing (PARs >FRMs MAPs), palette editing, and general UI cleanup. I'm currently There can hardly be real mac-specific code for par-parsing, can there? I hope I'm not showing too much of my ignorance here ;-) >Future directions? I vote for a cleaner layer of abstraction seperating >Fractint from platform/gui. POV-Ray is my inspiration! I hope I'm parsing this right... You write you're writing mac-specific code. This separation you're proposing is, however, contrary to that. Too bad really. -- Dean-Christian Strik ICQ: 11760568 dean2@bigfoot.com cstrik.isg@hetnet.nl The nice thing of standards is that there are so many to choose from. -- Andrew S. Tanenbaum Thanks for using Fractdev, The Fractint Developer's Discussion List Post Message: fractdev@lists.xmission.com Get Commands: majordomo@lists.xmission.com "help" Administrator: twegner@phoenix.net Unsubscribe: majordomo@lists.xmission.com "unsubscribe fractdev" ------------------------------------------------------------------------------- From: Phil McRevis Subject: Re: (fractdev) Parallel processing (was Synchronous Orbits) Date: 04 Dec 1998 20:46:52 -0700 In article <199812050125.TAA19284@voyager.c-com.net>, "Tim Wegner" writes: > This is very easy to do, although what I have in mind is less > sophisticated than you have in mind. The "divide and conquor" > mechanism in the command generates a batch file that builds > images piecewise. All you need is a shell script that can cause > fractint (Xfractint) to execute remotely, each piece on a separate > processor, and return the GIF file. This doesn't require any changes > to fractint itself. Thge logic to divide up, process, and recombine > the pieces is already there. Another alternative is to write a "fractal daemon" that listens on a socket for work requests. It processes its work and sends the result back over a socket. You have to define the communications protocol that is used over the socket (don't forget byte-ordering and machine-dependent floating point issues of you're transporting more than image data), but that is not too hard. The nice thing about the proliferation of the internet is that it makes TCP/IP and sockets available on pretty much every machine these days, becoming the defacto networking API between heterogeneous hosts (amazing, considering that is the point of TCP/IP in the first place :). Parallel processing becomes just a matter of network socket I/O. Of course, you have network bandwidth and latency to deal with, which can often be more costly than doing some kind of architecture specific SMP type thing. On the other hand, its very portable to a machine with sockets, which is most machines these days. -- Legalize Adulthood! ``Ain't it funny that they all fire the pistol, at the wrong end of the race?''--PDBT legalize@xmission.com Thanks for using Fractdev, The Fractint Developer's Discussion List Post Message: fractdev@lists.xmission.com Get Commands: majordomo@lists.xmission.com "help" Administrator: twegner@phoenix.net Unsubscribe: majordomo@lists.xmission.com "unsubscribe fractdev" ------------------------------------------------------------------------------- From: "Tim Wegner" Subject: (fractdev) Need Borland tlink Date: 04 Dec 1998 22:24:47 -0600 Does anyone have Borland 4.5? I bought Borland 5.01, and understand that the tlink.exe does not properly support overlays, so I need the tlink.exe from Borland C 4.5x. Fractint runs with the message "too big to fit in memory". Tim Thanks for using Fractdev, The Fractint Developer's Discussion List Post Message: fractdev@lists.xmission.com Get Commands: majordomo@lists.xmission.com "help" Administrator: twegner@phoenix.net Unsubscribe: majordomo@lists.xmission.com "unsubscribe fractdev" ------------------------------------------------------------------------------- From: "Tim Wegner" Subject: (fractdev) New synch for 1961p58 Date: 05 Dec 1998 10:38:12 -0600 I have posted the source synch for 1961p58.zip in a new form. You should download ftp://ftp.phoenix.net/pub/USERS/twegner/s1961p58.zip If you have MSC but not MASM, the object code is in o1961p58.zip. If you don't have patch.exe, download diffpat.zip. These versions of diff and patch are pretty old. I have newer GNU versions of diff and patch that perhaps I could upload if anyone needs them. The idea is that you make a clean directory, copy the public source for 19.6 into the directory, then unzip the s1961p58.zip file in the same directory. Then run the batch file synch.bat, which applies all the patches. Make sure the standard UNIX-clone patch utility is the one accessible first in your PATH - Borland and others have different patch programs with the same name. If this is causing problems, let me know. My reason for doing it this way is: 1. the file is smaller 2. diff/patch is the way we distribute changes, so from my point of view (maybe not yours!) it is a Good Thing for you to use diff and patch :-) 3. This approach gives you not only the current patch but ALL the versions. It is a simple matter to reconstruct any version by just editing synch.bat so it stops at the desired point. My number one debugging method is to discover in what version a bug appears. Then I look in the context diff for that version and can usually see the error right away. Having said this, I am willing to upload a zip archive with all the files if it is needed. I will upload an Xwindows source file for 1961p58 later this weekend. I wouldn't advise anyone to try to reconstruct it from the patches for the DOS version. I will also upload the non-integer source. Borland 3.1 users can compile using the bcfract.bat batch method. The Borland IDE project files probably don't work. Microsoft users need a 16 bit compiler that was distributed as MSC 7.0 or the earlier Visual C/C++ distributions. Microsoft no longer distributes 16 bit compilers with their Visual C/C++. SOI doesn't work with the Borland compile. Probably needs to be compiled with increased stack, but I'm not positive what the problem is. Use the help (F1) to see what's new. Look for the evolver, sound, browser improvements, and who knows what all. I think 58 patches is some kind of a record, even though we have been working more slowly than in the past. At this point I don't want to distribute the executable compiled from this code, please honor this and don't upload it anywhere. However, we will probably decide to release some of these beta versions fairly soon. If you want to send us patches, use the -c option on diff and run diff in a directory with the current version (1961p58). Name your dif file something OTHER than 1961p59.dif and send it to me zipped up (not in an email message where the formatting might get messed up). The less work we have to do the more likely we are to make your patch official, so edit the help?.src files also. If any questions please ask! Tim Tim Thanks for using Fractdev, The Fractint Developer's Discussion List Post Message: fractdev@lists.xmission.com Get Commands: majordomo@lists.xmission.com "help" Administrator: twegner@phoenix.net Unsubscribe: majordomo@lists.xmission.com "unsubscribe fractdev" ------------------------------------------------------------------------------- From: "Tim Wegner" Subject: Re: (fractdev) New synch for 1961p58 Date: 05 Dec 1998 11:06:15 -0600 It occurs to be that if you have a version based on a recent synch, you can try to patch in the recent patches. This might work with no problems. For example, if Humberto added some features to patch 44, he could patch in 1961p45.dif through 1961p58.dif (in a clean directory of course). It is always possible that our changes clash with yours, but usually this results in failed hunks that can easily be implemented by hand. If the changes don't clash you are home free. Tim Thanks for using Fractdev, The Fractint Developer's Discussion List Post Message: fractdev@lists.xmission.com Get Commands: majordomo@lists.xmission.com "help" Administrator: twegner@phoenix.net Unsubscribe: majordomo@lists.xmission.com "unsubscribe fractdev" ------------------------------------------------------------------------------- From: kragen@pobox.com (Kragen) Subject: Re: (fractdev) Re: source code Date: 05 Dec 1998 17:41:24 -0500 (EST) On Fri, 4 Dec 1998, Tim Wegner wrote: > The non-integer version came about because I was trying to save > resources to use in adding PNG support. Plus it is clear to me > integer math has no future, first because it is no longer faster than > floating point, It's still faster than FP on non-Intel machines (or Intel StrongARMs) and on old machines. Sometime next year I plan to get an eight-processor StrongARM machine if I can dig up the money for it. I am slightly puzzled what FP fractal calculation has to do with PNG support. > The non-integer version has many code differences from the regular > version, and is not really mergeable. But it is not too hard to > maintain. I patch in every diff, and simple deal with all the failed > hunks. Not to bad for small changes. I guess I should probably look at the code, because I don't understand what you're saying here. The FP versions of the {IFS,escape-time,Lsystem,orbital,bifurcation} fractal engines are separate from the integer versions, but similar enough that you can usually apply the same diff to the integer and FP code?! -- Kragen Sitaker This radically anti-cynical approach to life is not just a shared disposition but also an act of conscious dissent. -- Alan Bershaw, on the attitude of Jewel fans ("everyday angels") Thanks for using Fractdev, The Fractint Developer's Discussion List Post Message: fractdev@lists.xmission.com Get Commands: majordomo@lists.xmission.com "help" Administrator: twegner@phoenix.net Unsubscribe: majordomo@lists.xmission.com "unsubscribe fractdev" ------------------------------------------------------------------------------- From: Jiho Kim Subject: (fractdev) Thanks and happy wishes Date: 06 Dec 1998 09:40:50 -0800 (PST) As one of those people who are patiently awaiting the next iteration of Fractint (or whatever it'll be called), I'd like to thank and wish many happy thoughts to those working more or less dilegently on it. Keep it up! Smiles, Jiho Thanks for using Fractdev, The Fractint Developer's Discussion List Post Message: fractdev@lists.xmission.com Get Commands: majordomo@lists.xmission.com "help" Administrator: twegner@phoenix.net Unsubscribe: majordomo@lists.xmission.com "unsubscribe fractdev" ------------------------------------------------------------------------------- From: Phil McRevis Subject: Re: (fractdev) Re: source code Date: 06 Dec 1998 12:44:08 -0700 In article , kragen@pobox.com (Kragen) writes: > I am slightly puzzled what FP fractal calculation has to do with PNG > support. Like everything else in the 16-bit code, it has to do with memory. Adding the PNG code meant something else had to go, or more overlay shuffling had to take place. The 16-bit code is chafing against the 16-bit memory model big time. > [...] The FP versions of the > {IFS,escape-time,Lsystem,orbital,bifurcation} fractal engines are > separate from the integer versions, but similar enough that you can > usually apply the same diff to the integer and FP code?! I think what Tim meant was that he has a version of fractint with the integer code and a version of fractint without the integer code. Patches to other parts of fractint can be applied relatively easily to these two 'branches' of development. (CVS would keep all this straight much easier, ya know :) -- Legalize Adulthood! ``Ain't it funny that they all fire the pistol, at the wrong end of the race?''--PDBT legalize@xmission.com Thanks for using Fractdev, The Fractint Developer's Discussion List Post Message: fractdev@lists.xmission.com Get Commands: majordomo@lists.xmission.com "help" Administrator: twegner@phoenix.net Unsubscribe: majordomo@lists.xmission.com "unsubscribe fractdev" ------------------------------------------------------------------------------- From: "Dean-Christian Strik" Subject: Re: (fractdev) Re: source code Date: 06 Dec 1998 18:44:40 +0100 Kragen wrote: >It's still faster than FP on non-Intel machines (or Intel StrongARMs) >and on old machines. Sometime next year I plan to get an >eight-processor StrongARM machine if I can dig up the money for it. >I am slightly puzzled what FP fractal calculation has to do with PNG >support. Nothing. Who said so? -- Dean-Christian Strik ICQ: 11760568 dean2@bigfoot.com cstrik.isg@hetnet.nl The nice thing of standards is that there are so many to choose from. -- Andrew S. Tanenbaum >> The non-integer version has many code differences from the regular >> version, and is not really mergeable. But it is not too hard to >> maintain. I patch in every diff, and simple deal with all the failed >> hunks. Not to bad for small changes. > >I guess I should probably look at the code, because I don't understand >what you're saying here. The FP versions of the >{IFS,escape-time,Lsystem,orbital,bifurcation} fractal engines are >separate from the integer versions, but similar enough that you can >usually apply the same diff to the integer and FP code?! > >-- > Kragen Sitaker >This radically anti-cynical approach to life is not just a shared >disposition but also an act of conscious dissent. -- Alan Bershaw, on the >attitude of Jewel fans ("everyday angels") > > >-------------------------------------------------------------- >Thanks for using Fractdev, The Fractint Developer's Discussion List >Post Message: fractdev@lists.xmission.com >Get Commands: majordomo@lists.xmission.com "help" >Administrator: twegner@phoenix.net >Unsubscribe: majordomo@lists.xmission.com "unsubscribe fractdev" > Thanks for using Fractdev, The Fractint Developer's Discussion List Post Message: fractdev@lists.xmission.com Get Commands: majordomo@lists.xmission.com "help" Administrator: twegner@phoenix.net Unsubscribe: majordomo@lists.xmission.com "unsubscribe fractdev" ------------------------------------------------------------------------------- From: "Tim Wegner" Subject: Re: (fractdev) Re: source code Date: 06 Dec 1998 19:36:17 -0600 Dean-Christian wrote: > >I am slightly puzzled what FP fractal calculation has to do with PNG > >support. > > > Nothing. Who said so? I took the integer math out of a version of fractint hoping to free up memory resources to give me room for PNG, which needs much more memory than GIF. That is the connection. I concluded that a medium memory model Fractint will never directly support PNG. I do believe it is possible to shell out to a protected mode program to implement PNG, but I don't think this is work the effort, which should be directed to getting Fractrint moved to a flat memory model. After that adding PNG would be easy. Tim Thanks for using Fractdev, The Fractint Developer's Discussion List Post Message: fractdev@lists.xmission.com Get Commands: majordomo@lists.xmission.com "help" Administrator: twegner@phoenix.net Unsubscribe: majordomo@lists.xmission.com "unsubscribe fractdev" ------------------------------------------------------------------------------- From: Humberto Rossetti Baptista Subject: (fractdev) Evolver & Diffusion Date: 07 Dec 1998 00:20:51 -0200 (EDT) Hi Robin, On Fri, 4 Dec 1998 comdotatdotcom@csi.com wrote: > Great minds think alike apparantly :-) This is the present setup of the Gues I could say that too :->>> > evolver, the matrix can be any odd number in size and fractal type is > about the only thing it doesn't change! Random parameter scrambling is > also available, I'm still mulling over various possibilities for 'breeding' > images, though these all require storing complete parameter sets for the > images and would eat too much ram at present I suspect. I've managed to put everything up from Tim's patches (from ftp.phoenix.net) and the evolver was VERY much what I had in mind. BTW I couldn't play around enough, but some things came up about the patch 58 implementation: - we cannot vary th eiteration number (it may do some difference in certain kinds of fractals). - the restriction on orbit/infinite-running seems a bit too restrictive. - there could be a keyboard shortcut to switch back and forth to the evolver (Yes, i know that's a big problem :-) ). - I do not know the amount of work/logic involved bu on deterministic arrays (the ones we use x, y, x+y etc) I should be possible (in theory) to simply copy the part of the array around the new chosen image to avoid recalculation. What do you think? - No pallete loading from the evolver :''-( > I like the sound of your diffusion plotting method, I had a go at [snip] Then bug Tim to pass the patch around :-) As I invented (at least as fas as I know) this method I was able to handle the extreme cases (like creating a image 1 x n or n x 1 etc.) And I spent a reasonable time (on what's avaliable) to enhance its' speed. If you like the method we can work together to make a "paralell" evolver that plots all images at the same time :-))) []'s Humberto R. Baptista humberto@insite.com.br Insite - Solucoes Internet http://www.insite.com.br Thanks for using Fractdev, The Fractint Developer's Discussion List Post Message: fractdev@lists.xmission.com Get Commands: majordomo@lists.xmission.com "help" Administrator: twegner@phoenix.net Unsubscribe: majordomo@lists.xmission.com "unsubscribe fractdev" ------------------------------------------------------------------------------- From: Humberto Rossetti Baptista Subject: RE: Re: (fractdev) Synchronous Orbits Date: 07 Dec 1998 00:25:48 -0200 (EDT) On Fri, 4 Dec 1998 comdotatdotcom@csi.com wrote: > I've been wanting this to happen to fractint for year now! I had thought > along the lines of just using disk video mode, a shared file, and a > slightly modified single pass mode (just check the leftmost pixel in each > row, if it's color 0 then set it to grab the row, cmpute a row of pixels, > write them back and so on... not optimal but possibly very easy, just > ignore the odd occasion when two cpus grab the same row ) I've been thinking about this for some time too (mind parallelism again :-) but discussing this with some friends that do program very well in other environments like Unix I was "convinced" no to rely on shared fies and such. I was thinking of a subset of the HTTP protocol end to make the "master" fractint just wait for the others (slaves ;-) It would be easy and not too disruptive to a non multithreaded app. The choice of HTTP is interesting because it is very portable and there are lots of GNU/free libraries around. > Once the calculation engine is serperated from the UI then I suppose it > gets much easier, just replace the user with a segmenter/dispatcher > routine. Agreed. []'s Humberto R. Baptista humberto@insite.com.br Insite - Solucoes Internet http://www.insite.com.br Thanks for using Fractdev, The Fractint Developer's Discussion List Post Message: fractdev@lists.xmission.com Get Commands: majordomo@lists.xmission.com "help" Administrator: twegner@phoenix.net Unsubscribe: majordomo@lists.xmission.com "unsubscribe fractdev" ------------------------------------------------------------------------------- From: Humberto Rossetti Baptista Subject: Re: (fractdev) Re: source code Date: 07 Dec 1998 00:42:44 -0200 (EDT) On Fri, 4 Dec 1998, Tim Wegner wrote: > I didn't say quite enough. Fractint and Xfractint absolutely share > source with NO changes. You can copy the fractint source on top [...] I haven't browsed enought :-) [...] > image instead of a binary image of the fractal info structure. I have > even reserved a PNG chunk name (fRAc) for this purpose. This idea is VERY interesting and allows a great deal of things by manipulating the PNGs and running Fractint from simple scripts (in perl for instance) > The non-integer version came about because I was trying to save > resources to use in adding PNG support. Plus it is clear to me > integer math has no future, first because it is no longer faster than > floating point, and second because integer math will almost > certainly not survive any port to a flat memory model because the > guts are in assembler. (Having said that, if someone cared, the > assemble could be ported, at least to Intel platforms.) Hm. I also favor the platform independence, but I do not know if a good recoding in assmbly optimized for 586 class machines (using perhaps even MMX and such) wouldn't give some speedup. Tim, do you thing it would be possible to coordinate the non-integer and the current versions? I ask because if we could have, say, some platform specific directories with hand optimized assmbly language it could make a HUGE difference in some platforms. As we're thinking about this we could consider the possibility of compiling fractint on _very_ alien machines :-)) [...] > restructurings. We could, for example, get rid of the global > vatriables in a few weekends of work if we had already abandoned > the assembler. A few more weekends to port it all to C++ :->>> (kidding) []'s Humberto R. Baptista humberto@insite.com.br Insite - Solucoes Internet http://www.insite.com.br Thanks for using Fractdev, The Fractint Developer's Discussion List Post Message: fractdev@lists.xmission.com Get Commands: majordomo@lists.xmission.com "help" Administrator: twegner@phoenix.net Unsubscribe: majordomo@lists.xmission.com "unsubscribe fractdev" ------------------------------------------------------------------------------- From: Jonathan Osuch <73277.1432@compuserve.com> Subject: Re: (fractdev) Evolver & Diffusion Date: 06 Dec 1998 21:45:38 -0500 Humberto, >> - No pallete loading from the evolver :''-( << That's easy enough to fix. I'll add it back in with my next patch. Jonathan Thanks for using Fractdev, The Fractint Developer's Discussion List Post Message: fractdev@lists.xmission.com Get Commands: majordomo@lists.xmission.com "help" Administrator: twegner@phoenix.net Unsubscribe: majordomo@lists.xmission.com "unsubscribe fractdev" ------------------------------------------------------------------------------- From: Humberto Rossetti Baptista Subject: Re: (fractdev) Parallel processing (was Synchronous Orbits) Date: 07 Dec 1998 00:46:23 -0200 (EDT) On Fri, 4 Dec 1998, Tim Wegner wrote: > This is very easy to do, although what I have in mind is less > sophisticated than you have in mind. The "divide and conquor" > mechanism in the command generates a batch file that builds > images piecewise. All you need is a shell script that can cause > fractint (Xfractint) to execute remotely, each piece on a separate > processor, and return the GIF file. This doesn't require any changes > to fractint itself. Thge logic to divide up, process, and recombine > the pieces is already there. And how can we assemble back the pieces? If that means using the actual code and extending it no problem. > The value of this approach is that the method of starting processes > on different processors is machine dependent, so not a good > candidate to put *inside* fractint, hench the shell script approach. Yes i agree. My idea was to come up with something simple enought to make fractint "network aware" and then communicate the chunks around. []'s Humberto R. Baptista humberto@insite.com.br Insite - Solucoes Internet http://www.insite.com.br Thanks for using Fractdev, The Fractint Developer's Discussion List Post Message: fractdev@lists.xmission.com Get Commands: majordomo@lists.xmission.com "help" Administrator: twegner@phoenix.net Unsubscribe: majordomo@lists.xmission.com "unsubscribe fractdev" ------------------------------------------------------------------------------- From: Humberto Rossetti Baptista Subject: Re: (fractdev) Worklist and future directions Date: 07 Dec 1998 00:56:04 -0200 (EDT) On Fri, 4 Dec 1998, Tim Wegner wrote: > 1. Merge the non-integer code with Xfractint Is the non-integer source avaliable anywhere? I could try to catch up with mu Unix programming skills and make the port to SVGAlib > 2. Cut out all the Xwindows stuff, and add video support via the > Linux SVGA lib. (Did you know that Xfractint does not need > Xwindows? Invoke Xfractint -disk and the program works in 100% > character mode.) Yep. I used this a lot i Unix statiosn to generate animations :-) > 3. Port the the Linux version to djgpp, using the SVGALIB. > > I don't think we should reinvent the well. If we want a DOS version, > we should use existing SVGA libraries. Of course for all GUI ports > we write to a virtual screen. Hm I am not sure but I do not know if there is a port of the SVGAlib to DOS. Is it? > I believe it is possible to add assembler back in that would be > portable between Linux and DOS. I'll only add the this should be done in a fashion that allows COMPLETE independence of the assembly (I have said more before) > Some people might think this is a waste a time, but once Fractint > was ported to 32 bits flat memory, even though DOS or non-X > Linux, we could then get rid of all the memory saving junk like re- > used arrays, get rid of global variables, etc. etc., and evolve a > decent underlying engine. Waste of time???!! No comments. We could then start to experiment in new directiosn the REALLY use up memory :-) (I have just thought of saving all x,y,iteration values up to play with coloring techiniques, etc.) > > - Variable size/alignment (hm.. the first means new bugs, the second > > less speed unless optimized) > > The main issue is the way parameters are written inside GIFs, > which I have addressed elsewhere. Also on a major cleanup without the memory concerns we can align avery variable to where it's going to be better fetched. []'s Humberto R. Baptista humberto@insite.com.br Insite - Solucoes Internet http://www.insite.com.br Thanks for using Fractdev, The Fractint Developer's Discussion List Post Message: fractdev@lists.xmission.com Get Commands: majordomo@lists.xmission.com "help" Administrator: twegner@phoenix.net Unsubscribe: majordomo@lists.xmission.com "unsubscribe fractdev" ------------------------------------------------------------------------------- From: Humberto Rossetti Baptista Subject: Re: (fractdev) Need Borland tlink Date: 07 Dec 1998 01:00:05 -0200 (EDT) On Fri, 4 Dec 1998, Tim Wegner wrote: > Does anyone have Borland 4.5? I bought Borland 5.01, and > understand that the tlink.exe does not properly support overlays, > so I need the tlink.exe from Borland C 4.5x. Fractint runs with the > message "too big to fit in memory". Does the tlink from BC 3.1 work? I have it here. []'s Humberto R. Baptista humberto@insite.com.br Insite - Solucoes Internet http://www.insite.com.br Thanks for using Fractdev, The Fractint Developer's Discussion List Post Message: fractdev@lists.xmission.com Get Commands: majordomo@lists.xmission.com "help" Administrator: twegner@phoenix.net Unsubscribe: majordomo@lists.xmission.com "unsubscribe fractdev" ------------------------------------------------------------------------------- From: Humberto Rossetti Baptista Subject: Re: (fractdev) New synch for 1961p58 Date: 07 Dec 1998 01:06:28 -0200 (EDT) On Sat, 5 Dec 1998, Tim Wegner wrote: > Borland 3.1 users can compile using the bcfract.bat batch method. > The Borland IDE project files probably don't work. Microsoft users Hi, I'm sending tim the fractint.prj corrected to the newest additions. > SOI doesn't work with the Borland compile. Probably needs to be > compiled with increased stack, but I'm not positive what the I'm having problems with the switch to arbitrary precision I'll look at this later. > If you want to send us patches, use the -c option on diff and run diff IMHO use: diff . .. -c2 -o -b > yourdif.dif the -c2 gives 2 lines of context, the -o ignores the files only in one directory and the -b ignores the changes in whitespace/tabs so common among differente text editors. []'s Humberto R. Baptista humberto@insite.com.br Insite - Solucoes Internet http://www.insite.com.br Thanks for using Fractdev, The Fractint Developer's Discussion List Post Message: fractdev@lists.xmission.com Get Commands: majordomo@lists.xmission.com "help" Administrator: twegner@phoenix.net Unsubscribe: majordomo@lists.xmission.com "unsubscribe fractdev" ------------------------------------------------------------------------------- From: Humberto Rossetti Baptista Subject: (fractdev) Announce: new features ;-) Date: 07 Dec 1998 01:23:01 -0200 (EDT) Hi, I've sent Tim my recent contributions to fractint: - A new orbit type: the Latoocarfians (From Pickover's book) - A new map type: a generalization from PopCornJul - A new drawing technique: the diffusion Scan. The last one has worked very well with the original 19.6 and the current version 19.61p58 and allow for the ingremental generation of images without the introduction of image artifacts like in solig guessing teseral and boundary tracing. As it is not magic, it takes longer than these because it calculates ALL points, but I have added a "resolution enhancer"(1) that allows the user to preview the image ahead of any other method. (1) in reality it is a technique inspired by the blocks solid guessing uses to refine the image. When tim publishes the code send you comments! I'll mess around with the pallet editor and the evolver next ;-)))) (i think :->>> ) []'s Humberto R. Baptista humberto@insite.com.br Insite - Solucoes Internet http://www.insite.com.br Thanks for using Fractdev, The Fractint Developer's Discussion List Post Message: fractdev@lists.xmission.com Get Commands: majordomo@lists.xmission.com "help" Administrator: twegner@phoenix.net Unsubscribe: majordomo@lists.xmission.com "unsubscribe fractdev" ------------------------------------------------------------------------------- From: "Michael R. Ganss" Subject: Re: (fractdev) Synchronous Orbits Date: 07 Dec 1998 11:43:57 +0100 (MET) hi all, > Our implementation is based on AlmondBread by Michael R. > Ganss. See http://www.cs.tu-berlin.de/~rms/AlmondBread > If this isn't current try searching for AlmondBread. the URL is still valid, although I haven't updated the pages in over a year. "professional responsibilities" currently do not allow me to further develop AlmondBread nor participate in the development of Fractint. I had originally planned a port of AlmondBread to Windows, but got very frustrated with Visual C++ (it took me ages to get a simple hello world to work), so I gave that up. However, I'm still very interested in the development of Fractint. Regarding SOI, I think what Tim said is true insofar as it would benefit tremendously from being integrated with arbitrary precision. ap, IMHO, is a prime candidate for an object-oriented implementation (i.e., C++), so before that's done, I don't recommend hacking up the SOI code further, since it's a little terse already. One thing I was always very interested in was cardioid checking for cardioids of arbitrary degree. Jay Hill has done some great work in this area. I wonder if there has been development in this area lately. -- Michael R. Ganss Didi: Wat seh ick da ick gloob ick spinn rms@cs.tu-berlin.de Stulle der hat einen drin. Thanks for using Fractdev, The Fractint Developer's Discussion List Post Message: fractdev@lists.xmission.com Get Commands: majordomo@lists.xmission.com "help" Administrator: twegner@phoenix.net Unsubscribe: majordomo@lists.xmission.com "unsubscribe fractdev" ------------------------------------------------------------------------------- From: kragen@pobox.com (Kragen) Subject: Re: (fractdev) project list Date: 07 Dec 1998 09:54:09 -0500 (EST) On Thu, 3 Dec 1998, Phil McRevis wrote: > Formula parser improvements: > C optimizer GM (under way) What exactly does this mean? -- Kragen Sitaker This radically anti-cynical approach to life is not just a shared disposition but also an act of conscious dissent. -- Alan Bershaw, on the attitude of Jewel fans ("everyday angels") Thanks for using Fractdev, The Fractint Developer's Discussion List Post Message: fractdev@lists.xmission.com Get Commands: majordomo@lists.xmission.com "help" Administrator: twegner@phoenix.net Unsubscribe: majordomo@lists.xmission.com "unsubscribe fractdev" ------------------------------------------------------------------------------- From: kragen@pobox.com (Kragen) Subject: RE: Re: (fractdev) Synchronous Orbits Date: 07 Dec 1998 10:34:15 -0500 (EST) On Mon, 7 Dec 1998, Humberto Rossetti Baptista wrote: > The choice of HTTP is interesting because it is very > portable and there are lots of GNU/free libraries around. If we want to use GNU GPL libraries in Fractint, we'd have to change the licensing of Fractint (which currently prohibits selling Fractint for money). Which means, I think, that we'd have to get consent from everyone whose code is currently in Fractint. Which is probably infeasible. I don't think this is likely to come up for HTTP, anyway. -- Kragen Sitaker This radically anti-cynical approach to life is not just a shared disposition but also an act of conscious dissent. -- Alan Bershaw, on the attitude of Jewel fans ("everyday angels") Thanks for using Fractdev, The Fractint Developer's Discussion List Post Message: fractdev@lists.xmission.com Get Commands: majordomo@lists.xmission.com "help" Administrator: twegner@phoenix.net Unsubscribe: majordomo@lists.xmission.com "unsubscribe fractdev" ------------------------------------------------------------------------------- From: "Peter Gavin" Subject: RE: (fractdev) Re: source code Date: 07 Dec 1998 17:17:03 -0500 // I took the integer math out of a version of fractint hoping // to free up // memory resources to give me room for PNG, which needs much // more memory than GIF. That is the connection. I concluded that a // medium memory model Fractint will never directly support PNG. I // do believe it is possible to shell out to a protected mode // program to // implement PNG, but I don't think this is work the effort, which // should be directed to getting Fractrint moved to a flat memory // model. After that adding PNG would be easy. I've thought about this a few times, and figured DJGPP would be best for this, especially considering that 1) it supports 32-bit, and (even better= ) 2) it's free. Unfortunately, the assembly code would have to be re-writt= en, but that shouldn't be too much of a problem... I'm just beginning to lea= rn asm, otherwise I would've taken a crack at it myself :) Pete /******************************************* =A0* Peter Gavin =A0* E-mail: =A0* Homepage: =A0* Please send any comments or questions =A0* directly to me. Spam, flames, and other =A0* unsolicited e-mail should be sent to =A0* =A0* Thank you, and have a nice day. =A0******************************************/ Thanks for using Fractdev, The Fractint Developer's Discussion List Post Message: fractdev@lists.xmission.com Get Commands: majordomo@lists.xmission.com "help" Administrator: twegner@phoenix.net Unsubscribe: majordomo@lists.xmission.com "unsubscribe fractdev" ------------------------------------------------------------------------------- From: Humberto Rossetti Baptista Subject: RE: Re: (fractdev) Synchronous Orbits Date: 08 Dec 1998 01:55:44 -0200 (EDT) On Mon, 7 Dec 1998, Kragen wrote: > If we want to use GNU GPL libraries in Fractint, we'd have to change the > licensing of Fractint (which currently prohibits selling Fractint for > money). Which means, I think, that we'd have to get consent from > everyone whose code is currently in Fractint. Which is probably > infeasible. I'm not quite sure I understand what you meant, but there are a number of implementations around that use less restrictive licences (Artistic, FreeBSD like etc.) and several good libraries use LGPL wich does not force fractint to become GPL itself. > I don't think this is likely to come up for HTTP, anyway. Why? Humberto R. Baptista humberto@insite.com.br Insite - Solucoes Internet http://www.insite.com.br Thanks for using Fractdev, The Fractint Developer's Discussion List Post Message: fractdev@lists.xmission.com Get Commands: majordomo@lists.xmission.com "help" Administrator: twegner@phoenix.net Unsubscribe: majordomo@lists.xmission.com "unsubscribe fractdev" ------------------------------------------------------------------------------- From: Humberto Rossetti Baptista Subject: (fractdev) Arbitrary precision & BC 3.1 Date: 08 Dec 1998 02:02:02 -0200 (EDT) Hi, I told Tim recently that I've encountered some problems with arbitrary precision when compiling the sources under BC 3.1 (no I haven't tried MSC). I found Fractint in an infinite loop that was not suposed to happen in floattobn (bignum.c). As I could figure port.h does _not_ define USE_BIGNUM_C_CODE as it should (all the #defines are inside specific #if's) I then tried to acivate a #define USE_BIGNUM_C_CODE that was commented out and the infinite loop went away. Unfortunatedly fractint the started to print several messages (in the "red" text messages, like errors) like if it was debugging and I could not make it work, any ideas? The users of Borland BC 3.1 in the list have any clue? []'s Humberto R. Baptista humberto@insite.com.br Insite - Solucoes Internet http://www.insite.com.br Thanks for using Fractdev, The Fractint Developer's Discussion List Post Message: fractdev@lists.xmission.com Get Commands: majordomo@lists.xmission.com "help" Administrator: twegner@phoenix.net Unsubscribe: majordomo@lists.xmission.com "unsubscribe fractdev" ------------------------------------------------------------------------------- From: Humberto Rossetti Baptista Subject: (fractdev) Unity+Atan bug/feature? Date: 08 Dec 1998 02:07:49 -0200 (EDT) Hi, Ive found a strange behaviour of the outside=atan in the unity fractal. It seems that the one evaluation of atan and/or unity leaves something for the next and we can see that easily changing the drawing method (for instance solig guessing, 1 pass and teseral produce VERY different results). Is it something to do with atan or unity? Is is a feature or a bug? :-) []'s Humberto R. Baptista humberto@insite.com.br Insite - Solucoes Internet http://www.insite.com.br Thanks for using Fractdev, The Fractint Developer's Discussion List Post Message: fractdev@lists.xmission.com Get Commands: majordomo@lists.xmission.com "help" Administrator: twegner@phoenix.net Unsubscribe: majordomo@lists.xmission.com "unsubscribe fractdev" ------------------------------------------------------------------------------- From: Jonathan Osuch <73277.1432@compuserve.com> Subject: Re: (fractdev) Unity+Atan bug/feature? Date: 08 Dec 1998 18:32:59 -0500 Humberto, >> Ive found a strange behaviour of the outside=3Datan in the unity fractal.It seems that the one evaluation of atan and/or unity leaves something for the next and we can see that easily changing the drawing method (for instance solid guessing, 1 pass and teseral produce VERY different results). Is it something to do with atan or unity? << I went back to version 17.2 and the Unity type gives strange results in that version also. You can see similar problems with any of the outside=3D= options except iter, so it isn't exclusively an outside=3Datan problem. Jonathan Thanks for using Fractdev, The Fractint Developer's Discussion List Post Message: fractdev@lists.xmission.com Get Commands: majordomo@lists.xmission.com "help" Administrator: twegner@phoenix.net Unsubscribe: majordomo@lists.xmission.com "unsubscribe fractdev" ------------------------------------------------------------------------------- From: "Tim Wegner" Subject: Re: (fractdev) Worklist and future directions Date: 08 Dec 1998 17:57:45 -0600 Humberto asked: > Is the non-integer source avaliable anywhere? I could try to catch up > with mu Unix programming skills and make the port to SVGAlib > I''ll upload it in a few days. However I should point out that you don't need to wait for me - the XFRACT defines effectively eliminate integer math anyway. > Hm I am not sure but I do not know if there is a port of the SVGAlib to > DOS. Is it? I believe that the SVGALIB for djgpp is essentially the same as the UNIX version. Tim Thanks for using Fractdev, The Fractint Developer's Discussion List Post Message: fractdev@lists.xmission.com Get Commands: majordomo@lists.xmission.com "help" Administrator: twegner@phoenix.net Unsubscribe: majordomo@lists.xmission.com "unsubscribe fractdev" ------------------------------------------------------------------------------- From: Humberto Rossetti Baptista Subject: (fractdev) SVGALib and BC compiling. Date: 09 Dec 1998 16:54:39 -0200 (EDT) On Tue, 8 Dec 1998, Tim Wegner wrote: > I believe that the SVGALIB for djgpp is essentially the same as the > UNIX version. That sounds intresting I'll look into it this weekend (time permitting). About bugs in BC compiling: One i've already mention: the macro USE_BIGNUM_C_CODE was commented in port.h. Uncommenting it avoided an infinite loop (mentioned in the comments). A bug persisted and digging deeper I found some problems with the overlay options in BC compile files/project files: FRACTALB.C cannot be overlaid because the addresses of the routines bn/bfMODbailout are assigned to bignumbailout (I guess in CMDFILES.C or somethign like it). In the ,LNK (link conf) user in BC the FRACTALB.C was overlaid as a whole (different than MSC that overlays chunks acording to directives on the code). Well summing up: #define USE_BIGNUM_C_CODE must be ucomented (this could be problem in MSC as well) FRACTALB.C must not be overlaid in BC (I'll send the new .LNK and .PRJ files to Tim later today). []'s Humberto R. Baptista humberto@insite.com.br Insite - Solucoes Internet http://www.insite.com.br Thanks for using Fractdev, The Fractint Developer's Discussion List Post Message: fractdev@lists.xmission.com Get Commands: majordomo@lists.xmission.com "help" Administrator: twegner@phoenix.net Unsubscribe: majordomo@lists.xmission.com "unsubscribe fractdev" ------------------------------------------------------------------------------- From: "Tim Wegner" Subject: (fractdev) function variable presets Date: 12 Dec 1998 11:53:04 -0600 I have a question for users about the function variables in Fractint. These are the variables fn1, fn2, etc. that are used in some built-in fractal types and can also be used in formula types. Currently there are no preset values for these that are fractal-type- specific. For example, if fn1 = sin and fn2 = tanh, these values are remembered when you change fractal types even though the function variables probably have completely different meaning for the new type. 0100,0100,0100I have two related issues, both relating to some code contributed by Humberto Baptista. 0000,0000,00001. Humberto has added a new type (another from the prolific Cliff Pickover) that generates just a naked blue dot with the default values of the function variables. This fractal type is begging for some different default function variable values, but I'm not sure what the logic would be. Change to the defaults only when the fractal type changes? But if you played with this fractal, moved to a different type, then came back, would the function variables be reset? Or should Fractint remember the function variable values, and have separate defaults, for each fractal that uses them? 2. Humberto has also added a generalized popcornjul fractal. I dislike adding new types unncessesarily, and would prefer to merge the generalized type with the limited one. This, however, requires making the function variables default to the values that make the generalized popcornjul the same as the ungeneralized one, so the issue of preset values for function variables comes up again. Does anyone object to giving all fractals that use function variables preset values that are reset to the defaults whenever the fractal type is changed to that type? 0100,0100,0100Tim Thanks for using Fractdev, The Fractint Developer's Discussion List Post Message: fractdev@lists.xmission.com Get Commands: majordomo@lists.xmission.com "help" Administrator: twegner@phoenix.net Unsubscribe: majordomo@lists.xmission.com "unsubscribe fractdev" ------------------------------------------------------------------------------- From: Phil McRevis Subject: Re: (fractdev) function variable presets Date: 12 Dec 1998 13:37:07 -0700 In article <199812121753.LAA05705@voyager.c-com.net>, "Tim Wegner" writes: > 0100,0100,0100I have two related issues [...] Umm..... Tim, what's that? ^^^^^^^^^^^ > Does anyone object to giving all fractals that use function variables > preset values that are reset to the defaults whenever the fractal > type is changed to that type? Let me restate it to see if I understand it correctly: When you switch to a fractal type that uses the fn variables, they will be set to default values? Sounds fine. I would expect all fractal "state" to be initialized when I switch fractal types. I think there are some other little bits of state that I have noticed didn't get reset, but I can't remember what they are right now. -- Rich Thanks for using Fractdev, The Fractint Developer's Discussion List Post Message: fractdev@lists.xmission.com Get Commands: majordomo@lists.xmission.com "help" Administrator: twegner@phoenix.net Unsubscribe: majordomo@lists.xmission.com "unsubscribe fractdev" ------------------------------------------------------------------------------- From: Humberto Rossetti Baptista Subject: Re: (fractdev) function variable presets Date: 13 Dec 1998 22:23:23 -0200 (EDT) On Sat, 12 Dec 1998, Tim Wegner wrote: > Does anyone object to giving all fractals that use function variables > preset values that are reset to the defaults whenever the fractal > type is changed to that type? Since this is the behaviour when it comes to numerica and bailout options I guess it would beconsistente right now to make the same with preset funcions. If sometime later fractint remembers all the other parameters then we can extend (or build for) it to care for the functions. []'s Humberto R. Baptista humberto@insite.com.br Insite - Solucoes Internet http://www.insite.com.br Thanks for using Fractdev, The Fractint Developer's Discussion List Post Message: fractdev@lists.xmission.com Get Commands: majordomo@lists.xmission.com "help" Administrator: twegner@phoenix.net Unsubscribe: majordomo@lists.xmission.com "unsubscribe fractdev" ------------------------------------------------------------------------------- From: "Tim Wegner" Subject: Re: (fractdev) function variable presets Date: 13 Dec 1998 20:20:48 -0600 Humberto wrote: > Since this is the behaviour when it comes to numerica and bailout > options I guess it would beconsistente right now to make the same with preset > funcions. If sometime later fractint remembers all the other parameters then we > can extend (or build for) it to care for the functions. Jonathan Osuch pointed out to me that the generalized bifurcation types already have function variable faults, so I'll just follow what he did. The defaults get reset whenever you set that fractal type, but you can change the settings as long as you don't change to a different default. I've already done this for latoocartofian in my version. BTW Humberto, what country do you live in? I knew once but I have forgotten. Not that it matters :-) Tim > > []'s > > Humberto R. Baptista > humberto@insite.com.br > > --------------------------------------------------------------------------- > Insite - Solucoes Internet http://www.insite.com.br > > > -------------------------------------------------------------- > Thanks for using Fractdev, The Fractint Developer's Discussion List > Post Message: fractdev@lists.xmission.com > Get Commands: majordomo@lists.xmission.com "help" > Administrator: twegner@phoenix.net > Unsubscribe: majordomo@lists.xmission.com "unsubscribe fractdev" > Thanks for using Fractdev, The Fractint Developer's Discussion List Post Message: fractdev@lists.xmission.com Get Commands: majordomo@lists.xmission.com "help" Administrator: twegner@phoenix.net Unsubscribe: majordomo@lists.xmission.com "unsubscribe fractdev" ------------------------------------------------------------------------------- From: Humberto Rossetti Baptista Subject: Re: (fractdev) function variable presets Date: 14 Dec 1998 01:05:57 -0200 (EDT) On Sun, 13 Dec 1998, Tim Wegner wrote: > Jonathan Osuch pointed out to me that the generalized bifurcation > types already have function variable faults, so I'll just follow what he > did. The defaults get reset whenever you set that fractal type, but > you can change the settings as long as you don't change to a > different default. I've already done this for latoocartofian in my > version. hmpf. I haven't dug enought :-)))) Since you're in to it what about setting the default in the popcornjulfn to sin/tan/sin/tan as in the original? > BTW Humberto, what country do you live in? I knew once but I > have forgotten. Not that it matters :-) At least my accent didn't gave me out :-)))) I live in Brasil, and it matters when we are making fractint development statistics ("Developped in more than nnn countries ...") and when it's time to return home ;->>> []'s Humberto R. Baptista humberto@insite.com.br Insite - Solucoes Internet http://www.insite.com.br Thanks for using Fractdev, The Fractint Developer's Discussion List Post Message: fractdev@lists.xmission.com Get Commands: majordomo@lists.xmission.com "help" Administrator: twegner@phoenix.net Unsubscribe: majordomo@lists.xmission.com "unsubscribe fractdev" ------------------------------------------------------------------------------- From: Ron Barnett Subject: (fractdev) Exponential Smoothing Date: 21 Dec 1998 18:59:28 -0500 Kerry Mitchell's ghost formulae provide a good platform to illustrate the exponential smoothing method to provide smooth 24 bit coloring. In his formulae he applied the Vepstas log method which works well only for power functions. With the formulae and pars presented here I apply exponential smoothing to the mandelbrot set (to give a result very similar to Kerry's application of the Vepstas formula), a more complex function using trig functions, and a complex newton. For non-convergent functions (e.g. the Mandelbrot function), use the formula iterexp = 0 (initialize) iterexp = iterexp + exp(-cabs(z)) at each iteration. Then use iterexp to color rather than the iteration number. For convergent functions (e.g. any of the Newton methods), use the formula iterexp = 0 (initialize) oldz = 0 (initialize) iterexp = iterexp + exp(-1/cabs(oldz-z)) oldz = z The following are the formulae to use: ======================================================================== ======== MandExpGhost = { ; Ron Barnett, 1998 - modified from Kerry Mitchell ; ; colors Mandelbrot set by combining the smoothed iteration ; with a background of rays from the center ; ; use decomp=256 ; real(p1) = bailout ; imag(p1) = "ghost" adjustment: set to 0 for only ; background rays, try 2 ; calculation performed on variable zc, z used for coloring ; maxr = real(p1), scale = imag(p1)*pi/128 iterexp = 0, iter = 1, zc = 0, c = pixel, background = pixel: iterexp = iterexp + exp(-cabs(zc)), iter = iter + 1, zc = sqr(zc)+c ; ; bailout ; compute smoothed iteration as "angle" ; multiply angle by background to get final z ; set z to background for interior points ; set "iteration done" flag (iter=-1) ; IF ((|zc| > maxr) || (iter == maxit)) smooth = iterexp*scale ang = cos(smooth)+flip(sin(smooth)) z = background*ang IF (iter == maxit) z = background ENDIF iter = -1 ENDIF iter > 0 } JMaskghost = { ; Ron Barnett, 1998 ; use decomp=256 ; real(p1) = bailout ; imag(p1) = "ghost" adjustment: maxr = real(p1), scale = imag(p1)*pi/128 iterexp = 0, iter = 1, zc = fn1(pixel), background = pixel: iterexp = iterexp + exp(-cabs(zc)), iter = iter + 1 zc = P2*fn2(zc)^2 + P3 IF ((cabs(zc) > maxr) || (iter == maxit)) smooth = iterexp*scale ang = cos(smooth)+flip(sin(smooth)) z = background*ang IF (iter == maxit) z = background ENDIF iter = -1 ENDIF iter > 0 } CmplxNewtghost = { ; Ron Barnett, 1998 ; use decomp=256 ; real(p1) = bailout ; imag(p1) = "ghost" adjustment: ; p2 = complex power ; p3 = complex root maxr = real(p1), scale = imag(p1)*pi/128 oldz = 0 iterexp = 0, iter = 1, zc = pixel, background = pixel: iterexp = iterexp + exp(-1/cabs(oldz - zc)), iter = iter + 1 oldz = zc z1 = (p2-1)*zc^p2 + p3 z2 = p2*zc^(p2-1) zc = z1/z2 IF ((0.000001 > cabs(oldz-zc)) || (iter == maxit)) smooth = iterexp*scale ang = cos(smooth)+flip(sin(smooth)) z = background*ang IF (iter == maxit) z = background ENDIF iter = -1 ENDIF iter > 0 } ============================================================== Here are the actual pars: MandExpGhost { ; . t= 0:01:02.12 ; Ron Barnett, Dec 1998 ; On a Toshiba Pentium II at 800 x 600 reset=1960 type=formula formulafile=rebexp01.frm formulaname=mandexpghost passes=1 corners=-2.5/1.5/-1.5/1.5 params=1000000/10 float=y maxiter=100 inside=0 decomp=256 periodicity=0 colors=e0W<42>10W00W00W00V<65>W0GW0GW1H<63>WxyWyzWzzWzz<50>z1Wz0Wz0W<20>\ f0W cyclerange=0/255 } calipers { ; . t= 0:02:49.38 ; Copyright Ron Barnett, Dec 1998 ; On a Toshiba Pentium II at 800 x 600 reset=1960 type=formula formulafile=rebexp01.frm formulaname=JMaskghost function=acos/cosh center-mag=-2.22045e-016/0/0.6666667/1/-90 params=100/50/1/0/-0.766/0 float=y maxiter=1000 inside=0 decomp=256 periodicity=0 colors=mJ9<32>zVFzVGzWGzWGyVG<32>X1GW0GW0GW0G<80>zy0zz0zy0<48>W10W00W00<\ 47>mI9 cyclerange=0/255 } dirty_spiral { ; . t= 0:24:03.94 ; Copyright Ron Barnett, Dec 98 ; On a Toshiba Pentium II at 800 x 600 reset=1960 type=formula formulafile=rebexp01.frm formulaname=jmaskghost function=atan/sin center-mag=-0.138173/0.415693/6.666667 params=1000/5/1/0/0/0.5932500000000001 float=y maxiter=5000 inside=0 decomp=256 periodicity=0 colors=vSG<29>X1GW0GW0GW0G<80>zy0zz0zy0<48>W10W00W00<46>mI9mI9mJ9mJ9nK9<\ 28>yUFzVFzVFzVGzWGzWG<2>wTG cyclerange=0/255 } Complex Spiral { ; . t= 0:05:34.61 ; Copyright Ron Barnett, Dec 1998 ; On a Cyrix 6x86(P200+) at 800 x 600 reset=1960 type=formula formulafile=rebexp01.frm formulaname=CmplxNewtghost passes=1 center-mag=0.238245/0.19598/1.718213 params=1000000/4/1/4/1/3 float=y maxiter=256 inside=0 decomp=256 periodicity=0 colors=WWW<50>lD6lC6lD6<79>zy0zz0zz0zz0<64>XH0WG0WG0WG0<50>WWW cyclerange=0/255 } ======================================================================== ====== Ron Barnett Thanks for using Fractdev, The Fractint Developer's Discussion List Post Message: fractdev@lists.xmission.com Get Commands: majordomo@lists.xmission.com "help" Administrator: twegner@phoenix.net Unsubscribe: majordomo@lists.xmission.com "unsubscribe fractdev"