From: owner-fractdev-digest@lists.xmission.com (fractdev-digest) To: fractdev-digest@lists.xmission.com Subject: fractdev-digest V1 #4 Reply-To: fractdev-digest Sender: owner-fractdev-digest@lists.xmission.com Errors-To: owner-fractdev-digest@lists.xmission.com Precedence: bulk fractdev-digest Monday, February 2 1998 Volume 01 : Number 004 ---------------------------------------------------------------------- Date: Thu, 29 Jan 1998 13:01:15 -0600 From: "Damien M. Jones" Subject: Re: (fractdev) fractint list postings Rich, - This whitesq thing has always struck me as "fractint trying to be all - things to all people". Why not just render the two/four/N fractals - you want to combine in such a checkerboard fashion and have an image - manipulation program combine them? This is precisely what I do, and once you throw an image editor into the mix, you have a lot more combination options than simply 50/50 mixing. For this reason, I seldom use PHC/PTC approaches for my own work. However, I understand two powerful reasons the people like the PHC/PTC approach. First, you can zoom in on both "layers" simultaneously, greatly easing exploration of composite fractals. And second, these images can be color-cycled. This is why, even though I don't normally *use* these techniques, I think they are a good idea--at least until FractInt is fully true-color capable and can handle multiple layers at once. :) Damien M. Jones \\ dmj@fractalus.com \\ http://www.icd.com/tsd/ (temporary sanity designs) \\ http://www.fractalus.com/ (fractals are my hobby) - - - ------------------------------------------------------------ Thanks for using Fractdev, The Fractint Developer's Discussion List Post Message: fractdev@xmission.com Get Commands: majordomo@xmission.com "help" Administrator: twegner@phoenix.net Unsubscribe: majordomo@xmission.com "unsubscribe fractdev" ------------------------------ Date: Thu, 29 Jan 1998 12:21:27 -0700 From: Rich Thomson Subject: Re: (fractdev) fractint list postings In article <3.0.3.32.19980129130115.02ff41ec@megspo.megsinet.net> , "Damien M. Jones" writes: > [...]--at least until FractInt is fully > true-color capable and can handle multiple layers at once. :) For that sort of thing, you'd probably be better off making fractint a plug-in! - -- Rich Thomson rthomson@ptc.com - - - ------------------------------------------------------------ Thanks for using Fractdev, The Fractint Developer's Discussion List Post Message: fractdev@xmission.com Get Commands: majordomo@xmission.com "help" Administrator: twegner@phoenix.net Unsubscribe: majordomo@xmission.com "unsubscribe fractdev" ------------------------------ Date: Thu, 29 Jan 1998 14:45:10 -0500 From: George Martin <76440.1143@compuserve.com> Subject: Re: (fractdev) fractint list postings Rich, > why doesn't the optimizer detect unused variables and not bother computing them? < Not much to say here, except that "it just doesn't". The variables which are calculated once each pixel (scrnpix, whitesq, and pixel) are hard coded into the "per pixel" routines, and are not part of the sequence of function pointers which makes up the formula calculation, and which are examined for possible optimizations by Chuck Ebbert's fast parser. BTW, I am working right now on adding the optimizer to the C code. This will ultimately be a much more efficient way to optimize, with a side benefit that the C code formulas will run somewhat faster. Chuck has a comment in the optimizer which suggests that adding the "pushes" and "pulls" (which are used when the FPU stack gets filled up) would be better done after the optimization than before, as it is now. This will also be a side benefit of C optimization. George - - - ------------------------------------------------------------ Thanks for using Fractdev, The Fractint Developer's Discussion List Post Message: fractdev@xmission.com Get Commands: majordomo@xmission.com "help" Administrator: twegner@phoenix.net Unsubscribe: majordomo@xmission.com "unsubscribe fractdev" ------------------------------ Date: Thu, 29 Jan 1998 14:30:58 EST From: RBarn0001@aol.com Subject: Re: (fractdev) fractint list postings In a message dated 98-01-28 18:16:06 EST, you write: << I wonder if a few of you could post some on topic (non-test) messages to the fractint list so we can see if it is working. I don't know if the lack of activity is because folks *think* the list is down or if there's a problem. Thanks. Tim >> Tim, What is the most recent file with complete source code for Fractint? I wanted to start looking into true color implementation. Ron - - - ------------------------------------------------------------ Thanks for using Fractdev, The Fractint Developer's Discussion List Post Message: fractdev@xmission.com Get Commands: majordomo@xmission.com "help" Administrator: twegner@phoenix.net Unsubscribe: majordomo@xmission.com "unsubscribe fractdev" ------------------------------ Date: Thu, 29 Jan 1998 13:59:30 -0600 From: "Damien M. Jones" Subject: Re: (fractdev) fractint list postings Rich, - > [...]--at least until FractInt is fully - > true-color capable and can handle multiple layers at once. :) - - For that sort of thing, you'd probably be better off making fractint a - plug-in! Actually, the Photoshop plug-in architecture only allows a plug-in access to the current layer; you can't make a plug-in modify multiple layers at once. No, what I was thinking here was something I wrote about a while back, in a certain text file that has seen limited distribution. :) An "ordinary" fractal is one layer, one set of parameters; a PHC fractal is two layers, and a PTC is three or four. A multi-layered fractal is one in which each layer has its own formula, palette, location, coloring method, etc., and a "recipe" for combining them all together. Zooming on a multi-layer fractal zooms the location of each layer in sync, but otherwise the layers are pretty much autonomous. FWIW, Frederik Slijkerman already has a working implementation of this feature (albeit limited, currently) in his Ultra Fractal 2.0. It's like PHC/PTC, only better. :) The biggest problem with multi-layered fractals is not producing the image--but in creating an interface that makes the feature usable. Damien M. Jones \\ dmj@fractalus.com \\ http://www.icd.com/tsd/ (temporary sanity designs) \\ http://www.fractalus.com/ (fractals are my hobby) - - - ------------------------------------------------------------ Thanks for using Fractdev, The Fractint Developer's Discussion List Post Message: fractdev@xmission.com Get Commands: majordomo@xmission.com "help" Administrator: twegner@phoenix.net Unsubscribe: majordomo@xmission.com "unsubscribe fractdev" ------------------------------ Date: Fri, 30 Jan 1998 11:17:50 -0700 From: Rich Thomson Subject: (fractdev) progress.txt 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) SIMPLGIF 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 GM xfractint visual selection RT Parameter Evolver RBu, JO (mostly done) Memory use overhaul JO Current Developers: - ------------------- RBa Ron Barnett RBu Robin Bussell GM George Martin <76440.1143@compuserve.com> JO Jonathan Osuch ? RT Rich Thomson TW Tim Wegner - - - ------------------------------------------------------------ Thanks for using Fractdev, The Fractint Developer's Discussion List Post Message: fractdev@xmission.com Get Commands: majordomo@xmission.com "help" Administrator: twegner@phoenix.net Unsubscribe: majordomo@xmission.com "unsubscribe fractdev" ------------------------------ Date: Fri, 30 Jan 1998 11:18:57 -0700 From: Rich Thomson Subject: (fractdev) Re: progress.txt Developers: Please review the progress.txt file I just mailed out under separate cover. Add any projects you are working on that aren't listed and give an idea where the project stands relative to completion, if you can. Also, what is Jonathan Osuch's email address? - -- Rich Thomson rthomson@ptc.com - - - ------------------------------------------------------------ Thanks for using Fractdev, The Fractint Developer's Discussion List Post Message: fractdev@xmission.com Get Commands: majordomo@xmission.com "help" Administrator: twegner@phoenix.net Unsubscribe: majordomo@xmission.com "unsubscribe fractdev" ------------------------------ Date: Fri, 30 Jan 1998 10:49:16 -0800 From: "Jay Hill" Subject: (fractdev) Another wish list for fractint Tim, 1) The present solid guessing has options like levels 1, 2, or 3. We get - what - 4 passes at most, where the resolution is high. Now when I want a very quick look I can use 320x200 but then the most we get in passes is 2. This means the first pass over the image takes about the same time as guessing at 1024x768. Here is the thing I'd like, at what ever resolution I'm using, be able to set the passes to more so the image is shown approximately very fast. The validity of this image would be about that of a thumb nail image, 80x60 for example. But if it looks interesting I can let it continue one or two passes to see more. Now it would be at a moderate resolution having, say, two passes to go to finish. At this point I may have enough info for a pan or zoom. Or I could hit 'B' for later processing. 2) Another option would be the image starts processing in the center first (that is where we are zooming toward in search mode). This could either be start complete horizontal scans but in the center rather than top, or even better some kind of tressal with the center filing first. 3) Is there hope for a coordinate box like Winfract had? It should have complete digits available (winfract showed fewer than the precision of the calculations). Also, if the pointer remains on the 'focus' of the box, I'd like to get info on the escape iteration or the period. This information should be capturable by the windows clip board. If we have a DOS app, switching to one of the text windows (like hitting TAB) lets me snip data. This is very useful as a research tool. 4) Lets say I make a special formula, a Julia set type. Now I can off line derive a corresponding Mandelbrot set (see my recent postings for an example, (as if you all didn't know) ). When I hit 'space' with the usual MSet, I get a Julia. Now we need a way to link the two formula I derive so this feature will work there two. What I do now is run two copies of Fractint, one with M and one with J. I use the clip board to move coordinates around. It is very clumsy because only one number will copy at a time. And worse, windows clipboard includes a C/R at the end which launches a half baked parameter. If the parameters were in line horizontal, I could transfer two at once. Well until we get into deep zooming. Then none of this works. Thanks for the time... Jay - - - ------------------------------------------------------------ Thanks for using Fractdev, The Fractint Developer's Discussion List Post Message: fractdev@xmission.com Get Commands: majordomo@xmission.com "help" Administrator: twegner@phoenix.net Unsubscribe: majordomo@xmission.com "unsubscribe fractdev" ------------------------------ Date: Fri, 30 Jan 1998 14:48:56 -0500 From: George Martin <76440.1143@compuserve.com> Subject: (fractdev) Re: progress.txt Rich, >give an idea where the project stands relative to completion The "formula parser improvements" covers quite a range of ideas. When the new release of Fractint is imminent, we'll be able to just stop with whatever is done at that point and go with it. George - - - ------------------------------------------------------------ Thanks for using Fractdev, The Fractint Developer's Discussion List Post Message: fractdev@xmission.com Get Commands: majordomo@xmission.com "help" Administrator: twegner@phoenix.net Unsubscribe: majordomo@xmission.com "unsubscribe fractdev" ------------------------------ Date: Fri, 30 Jan 1998 13:16:51 -0700 From: Rich Thomson Subject: Re: (fractdev) Re: progress.txt In article <199801301453_MC2-3149-6393@compuserve.com> , George Martin <76440.1143@compuserve.com> writes: > The "formula parser improvements" covers quite a range of ideas. Yep :). > When the new release of Fractint is imminent, we'll be able to just > stop with whatever is done at that point and go with it. That's fine. The only reason I asked for "status" was not to crack the whip on anyone, but just that when someone comes asking for a feature that person Y is working on, we can point to the document and say "In November of 1996, Y said it would be ready 'Real Soon Now'" :) - -- Rich Thomson rthomson@ptc.com - - - ------------------------------------------------------------ Thanks for using Fractdev, The Fractint Developer's Discussion List Post Message: fractdev@xmission.com Get Commands: majordomo@xmission.com "help" Administrator: twegner@phoenix.net Unsubscribe: majordomo@xmission.com "unsubscribe fractdev" ------------------------------ Date: Fri, 30 Jan 1998 15:45:56 -0600 From: "Damien M. Jones" Subject: Re: (fractdev) progress.txt Rich, Please add "M-set Pentium Optimization" to the list. It's about half done, in that the code is written and works outside of FractInt, but needs to be tested and integrated into FractInt. Some work on this was already done, before I started, making the M-set almost twice as fast... but the code I've got is more than twice as fast as that, which is why I'm trying to stick it in. Man, some of this assembly sure is a mess. =) Damien M. Jones \\ dmj@fractalus.com \\ http://www.icd.com/tsd/ (temporary sanity designs) \\ http://www.fractalus.com/ (fractals are my hobby) - - - ------------------------------------------------------------ Thanks for using Fractdev, The Fractint Developer's Discussion List Post Message: fractdev@xmission.com Get Commands: majordomo@xmission.com "help" Administrator: twegner@phoenix.net Unsubscribe: majordomo@xmission.com "unsubscribe fractdev" ------------------------------ Date: Fri, 30 Jan 1998 15:45:56 -0600 From: "Damien M. Jones" Subject: Re: (fractdev) progress.txt Rich, Please add "M-set Pentium Optimization" to the list. It's about half done, in that the code is written and works outside of FractInt, but needs to be tested and integrated into FractInt. Some work on this was already done, before I started, making the M-set almost twice as fast... but the code I've got is more than twice as fast as that, which is why I'm trying to stick it in. Man, some of this assembly sure is a mess. =) Damien M. Jones \\ dmj@fractalus.com \\ http://www.icd.com/tsd/ (temporary sanity designs) \\ http://www.fractalus.com/ (fractals are my hobby) - - - ------------------------------------------------------------ Thanks for using Fractdev, The Fractint Developer's Discussion List Post Message: fractdev@xmission.com Get Commands: majordomo@xmission.com "help" Administrator: twegner@phoenix.net Unsubscribe: majordomo@xmission.com "unsubscribe fractdev" ------------------------------ Date: Fri, 30 Jan 1998 16:25:11 -0700 From: Rich Thomson Subject: Re: (fractdev) progress.txt In article <3.0.3.32.19980130154556.02f56e40@megspo.megsinet.net> , "Damien M. Jones" writes: > Please add "M-set Pentium Optimization" to the list. Done. Thanks for reminding me, I forgot about that one. - -- Rich Thomson rthomson@ptc.com - - - ------------------------------------------------------------ Thanks for using Fractdev, The Fractint Developer's Discussion List Post Message: fractdev@xmission.com Get Commands: majordomo@xmission.com "help" Administrator: twegner@phoenix.net Unsubscribe: majordomo@xmission.com "unsubscribe fractdev" ------------------------------ Date: Fri, 30 Jan 1998 21:26:34 -0600 From: "Tim Wegner" Subject: Re: (fractdev) progress.txt From the project list: > SIMPLGIF encoder fix TW (done) This should be > Fractint encoder fix TW (done) I have removed the existing LZW compression code from both Fractint and Simplgif and replaced them with the LZW code from the Unix compress utility. To date there are no known bugs in either Fractint's or Simplgif's new GIF encoder or in Fractint's decoder. There is a known bug in Simplgif's decoder. I plan to replace Simplgif's decoder with Fractint's. Then Simplgif should operate on anything you can throw at it. I owe several people sources for the fractint developer version and simplgif. I'll put something together, hopefully this weekend. We need a way to exchange patches. While posting attachments is a non-no on the fractint list, perhaps posting context diffs as zipped-up attachements would be OK here. (The zipping protects against inevitable mailer mashing of diff files.) I can also post things at my ftp site (ftp://ftp.phoenix.net/pub/USERS/twegner). Maybe my ftp site is the best bet. What works best is for active developers to keep current with each developer patch. It would be especially helpful to have an Xfractint developer keep current also, to help me out. I will publish some kind of current synch of the developer's source soon. There are a few people subscribed to this list who are unknown to me. Since any fairly enterprising person can investigate xmission and discover the existence of this list and join it, it isn't really a private list. I'm not planning on removing those folks as long as there are no problems. This list has not been publicized because I want to keep it mostly limited to serious developers. However, I am happy for people who have helped in the past to be on the list. I have also invited some of our artists because their testing and feedback is invaluable. I don't mind if others of you invite people you think are interested, as long is the list traffic is from people who are really interested in helping. Tim - - - ------------------------------------------------------------ Thanks for using Fractdev, The Fractint Developer's Discussion List Post Message: fractdev@xmission.com Get Commands: majordomo@xmission.com "help" Administrator: twegner@phoenix.net Unsubscribe: majordomo@xmission.com "unsubscribe fractdev" ------------------------------ Date: Fri, 30 Jan 1998 21:26:34 -0600 From: "Tim Wegner" Subject: Re: (fractdev) Re: progress.txt George wrote: > The "formula parser improvements" covers quite a range of ideas. When the > new release of Fractint is imminent, we'll be able to just stop with > whatever is done at that point and go with it. Maybe specific parser projects should be itemized, since it's too big a category. For example, adding the assembler optimizations to the parser C language code is probably a separable project. Tim - - - ------------------------------------------------------------ Thanks for using Fractdev, The Fractint Developer's Discussion List Post Message: fractdev@xmission.com Get Commands: majordomo@xmission.com "help" Administrator: twegner@phoenix.net Unsubscribe: majordomo@xmission.com "unsubscribe fractdev" ------------------------------ Date: Sat, 31 Jan 1998 08:37:12 -0600 From: "Tim Wegner" Subject: (fractdev) Welcome to Jonathan Folks, welcome Jonathan Osuch. For quite a while now Jonathan has been a steady mainstay of the Fractint development team. His contributions are many. At the moment, he's working with Robin on the evolver. He also wrote the memory library that unifies the various types of memory on the PC, and will greatly faciltate the ports of Fractint to other platforms. As of a few minutes ago, Jonathan is on this list. Jonathan, I didn't sign you up for the fractint list. I'll be happy to, but be prepared to be inundated by mail if you join! To see who is on this list, send the message who fractdev to majordomo@lists.xmission.com Rich, maybe we should add a list of platforms to the developer info table. Mine are Win95, Linux, and DOS. My compilers are MSC 7.0 and MASM 6.1, dgjpp, and gcc (Linux). Tim - - - ------------------------------------------------------------ Thanks for using Fractdev, The Fractint Developer's Discussion List Post Message: fractdev@xmission.com Get Commands: majordomo@xmission.com "help" Administrator: twegner@phoenix.net Unsubscribe: majordomo@xmission.com "unsubscribe fractdev" ------------------------------ Date: Sat, 31 Jan 1998 12:24:08 -0500 From: George Martin <76440.1143@compuserve.com> Subject: (fractdev) Welcome to Jonathan Rich, >list of platforms George Martin - Borland 3.1 George - - - ------------------------------------------------------------ Thanks for using Fractdev, The Fractint Developer's Discussion List Post Message: fractdev@xmission.com Get Commands: majordomo@xmission.com "help" Administrator: twegner@phoenix.net Unsubscribe: majordomo@xmission.com "unsubscribe fractdev" ------------------------------ Date: Sat, 31 Jan 1998 13:43:41 EST From: RBarn0001@aol.com Subject: Re: (fractdev) Welcome to Jonathan Rich, I am using Visual C++ 1.52 and MASM 6.0. I have Visual C++ 5.0 if we ever get to that point . Ron Barnett - - - ------------------------------------------------------------ Thanks for using Fractdev, The Fractint Developer's Discussion List Post Message: fractdev@xmission.com Get Commands: majordomo@xmission.com "help" Administrator: twegner@phoenix.net Unsubscribe: majordomo@xmission.com "unsubscribe fractdev" ------------------------------ Date: Sat, 31 Jan 1998 22:45:28 -0600 From: "Tim Wegner" Subject: (fractdev) Synching Up I have Xfractint working up to 1961 patch 20. There is a problem with patch 21, which I will look at tomorrow, unless Jonathan beats me to finding the problem. When I get Xfractint up to patch 27 (the current patch), I will release a patch 28 with the changes needed for Xfractint, including Rich's changes. At that point everyone can get synched up. This will take a few more days, depending on how things go at work. I have a big software delivery due Friday. Tim - - - ------------------------------------------------------------ Thanks for using Fractdev, The Fractint Developer's Discussion List Post Message: fractdev@xmission.com Get Commands: majordomo@xmission.com "help" Administrator: twegner@phoenix.net Unsubscribe: majordomo@xmission.com "unsubscribe fractdev" ------------------------------ Date: Mon, 02 Feb 1998 10:27:44 -0700 From: Rich Thomson Subject: Re: (fractdev) progress.txt In article <199801310324.VAA08430@virtual3.c-com.net> , "Tim Wegner" writes: > > SIMPLGIF encoder fix TW (done) > > This should be > > > Fractint encoder fix TW (done) Fixed. > I owe several people sources for the fractint developer version and > simplgif. I'll put something together, hopefully this weekend. We > need a way to exchange patches. While posting attachments is a non-no > on the fractint list, perhaps posting context diffs as zipped-up > attachements would be OK here. (The zipping protects against > inevitable mailer mashing of diff files.) I can also post things at > my ftp site (ftp://ftp.phoenix.net/pub/USERS/twegner). Maybe my ftp > site is the best bet. Please DON'T zip the diffs. There is no problem with "mailer mashing of diff files". I don't know where you got this idea. I have transmitted diff files by email for 10+ years and never, ever, ever, had a problem. ZIPing text files only causes more problems in getting the text files portably to another system because you zip your DOS text file and when I get it to unix, then I have to strip line feeds or vice-versa. If the file is transmitted as a text file, then we won't have to deal with that. - -- Rich Thomson rthomson@ptc.com - - - ------------------------------------------------------------ Thanks for using Fractdev, The Fractint Developer's Discussion List Post Message: fractdev@xmission.com Get Commands: majordomo@xmission.com "help" Administrator: twegner@phoenix.net Unsubscribe: majordomo@xmission.com "unsubscribe fractdev" ------------------------------ Date: Mon, 02 Feb 1998 10:28:50 -0700 From: Rich Thomson Subject: Re: (fractdev) Re: progress.txt In article <199801310324.VAA08434@virtual3.c-com.net> , "Tim Wegner" writes: > For example, adding the assembler optimizations to the parser C > language code is probably a separable project. These are the items I had in the "to do" list; which of these are you working on currently, George? 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 - -- Rich Thomson rthomson@ptc.com - - - ------------------------------------------------------------ Thanks for using Fractdev, The Fractint Developer's Discussion List Post Message: fractdev@xmission.com Get Commands: majordomo@xmission.com "help" Administrator: twegner@phoenix.net Unsubscribe: majordomo@xmission.com "unsubscribe fractdev" ------------------------------ Date: Mon, 02 Feb 1998 10:47:23 -0700 From: Rich Thomson Subject: Re: (fractdev) Welcome to Jonathan Would someone email me Jonathan Osuch's email address for the developer's list? Thanks. - -- Rich Thomson rthomson@ptc.com - - - ------------------------------------------------------------ Thanks for using Fractdev, The Fractint Developer's Discussion List Post Message: fractdev@xmission.com Get Commands: majordomo@xmission.com "help" Administrator: twegner@phoenix.net Unsubscribe: majordomo@xmission.com "unsubscribe fractdev" ------------------------------ Date: Mon, 2 Feb 1998 13:16:01 -0500 From: George Martin <76440.1143@compuserve.com> Subject: Re: (fractdev) Re: progress.txt Rich, > 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 < type info - I need more information about what is wanted here, and why. This is not a high priority item for me right now, and should probably wait until other projects are done. modulus function - We can do this, but what *is* the modulus of one complex number divided by another? C Optimizer - Working on now. High priority. This is part of an overall rewrite to make parsing, error warning, and memory allocation more efficient in the parser. Once-per-image section - Not working on now. Could you give some examples of what is wanted here? I've already started tinkering with trisq and quadsq. calling user functions - Not working on now, but right up my alley. I tried to make the if..else flexible enough to allow adding while and do..while loops, and goto statements. George - - - ------------------------------------------------------------ Thanks for using Fractdev, The Fractint Developer's Discussion List Post Message: fractdev@xmission.com Get Commands: majordomo@xmission.com "help" Administrator: twegner@phoenix.net Unsubscribe: majordomo@xmission.com "unsubscribe fractdev" ------------------------------ Date: Mon, 02 Feb 1998 11:33:22 -0700 From: Rich Thomson Subject: Re: (fractdev) Re: progress.txt In article <199802021319_MC2-319A-8C08@compuserve.com> , George Martin <76440.1143@compuserve.com> writes: > type info - I need more information about what is wanted here, and why. > This is not a high priority item for me right now, and should > probably wait until other projects are done. What is wanted: something similar to the C cast operator for expressions and typing of variables for declarations. We already have the ability to take the integer portion of a value by doing int(x) (what is the meaning of int(z), with z complex?). If one could type variables as integer or real: int iter, real x, then the parser could know that it didn't need to do complex arithmetic on these quantities. Further, for "iter" it could use integer math. Its a small quest for additional efficiency that motivates the proposal. > modulus function - We can do this, but what *is* the modulus of one complex > > number divided by another? Good point! > Once-per-image section - Not working on now. Could you give some examples > of what is wanted here? I've already started tinkering with > trisq and quadsq. I didn't propose this, but I seem to recall the discussion going something like this. People have user-defined functions and they want to do some computationally expensive setup calculations. However, these calculations need only be done once for the entire image (computing critical points of the iterated function, for instance). Currently, they have to recompute the critical points for every pixel. Again, efficiency seems to be the motivation for this proposal, but I don't know that anyone put together anything specific on a proposed syntax. I will add your updated info to the appropriate files! :) - -- Rich Thomson rthomson@ptc.com - - - ------------------------------------------------------------ Thanks for using Fractdev, The Fractint Developer's Discussion List Post Message: fractdev@xmission.com Get Commands: majordomo@xmission.com "help" Administrator: twegner@phoenix.net Unsubscribe: majordomo@xmission.com "unsubscribe fractdev" ------------------------------ Date: Mon, 02 Feb 1998 11:56:20 -0700 From: Rich Thomson Subject: Re: (fractdev) Re: progress.txt In article <199802021319_MC2-319A-8C08@compuserve.com> , George Martin <76440.1143@compuserve.com> writes: > modulus function - We can do this, but what *is* the modulus of one complex > number divided by another? I looked into a reference on complex numbers and it didn't seem to define the remainder of a complex number anywhere. Division is defined, but its unclear how to compute the remainder of a complex division. It might be handy to define z modulus w as: z = a + b i w = c + d i z % w = (a % c) + (b % d) i This would make implementing whitesq, trisq, quadsq, etc. trivial in the per-pixel initialization. However, I'm not sure that's the way we want to define complex modulus in general. Then again, maybe it is if that's the real reason we want complex modulus :) - -- Rich Thomson rthomson@ptc.com - - - ------------------------------------------------------------ Thanks for using Fractdev, The Fractint Developer's Discussion List Post Message: fractdev@xmission.com Get Commands: majordomo@xmission.com "help" Administrator: twegner@phoenix.net Unsubscribe: majordomo@xmission.com "unsubscribe fractdev" ------------------------------ Date: Mon, 02 Feb 1998 10:31:24 -0700 From: Rich Thomson Subject: Re: (fractdev) Welcome to Jonathan In article <199801311434.IAA12941@virtual3.c-com.net> , "Tim Wegner" writes: > Rich, maybe we should add a list of platforms to the developer info > table. Mine are Win95, Linux, and DOS. My compilers are MSC 7.0 and > MASM 6.1, dgjpp, and gcc (Linux). I'm not sure why this would be of help to other people? - -- Rich Thomson rthomson@ptc.com - - - ------------------------------------------------------------ Thanks for using Fractdev, The Fractint Developer's Discussion List Post Message: fractdev@xmission.com Get Commands: majordomo@xmission.com "help" Administrator: twegner@phoenix.net Unsubscribe: majordomo@xmission.com "unsubscribe fractdev" ------------------------------ Date: Mon, 2 Feb 1998 11:16:38 -0800 From: "Jay Hill" Subject: (fractdev) modulus function and image precalc George wrote >modulus function - We can do this, but what *is* the modulus of one > complex number divided by another? I asked for this functionality. The trunc() function almost does it all. And its use is for reals and also for integers. Reals for working with angles, for example. And integers for working with the iter or some color data. The format might be like the C++ functions. As for the precalc (the once per image), will we have access to the image center/mag/rot data so we can make some kind of pre-scan to help set up the parameters? I'm thinking of several applications - 1) a coloring scheme (someone in the UNIX world used it) checked a few hundred scattered spots on his 1280x1024 image and scaled the color map based on these samples. He always had a nice flow of colors from the edge to the densest parts. 2) special parameters can be computed for any 'inside' components found. It there is array capability, an array of special parameters can be made which helps 'instant' filling of these components and/or special coloring schemes for the insides of these components. I'm experimenting with a few of these now. Is there a function that tells us the pixel spacing.? If c=pixel and pixel moves up one or right one, what is the change in c? Jay - - - ------------------------------------------------------------ Thanks for using Fractdev, The Fractint Developer's Discussion List Post Message: fractdev@xmission.com Get Commands: majordomo@xmission.com "help" Administrator: twegner@phoenix.net Unsubscribe: majordomo@xmission.com "unsubscribe fractdev" ------------------------------ Date: Mon, 02 Feb 1998 14:22:24 -0600 From: "Damien M. Jones" Subject: (fractdev) Notion: coloring formulae I've been thinking about using the formula parser to define coloring algorithms. Obviously, I already have one way to do it--but this requires editing the formula every time a new core fractal equation is to be used. So I was thinking about ways to generalize the technique, that are actually somewhat easy to bolt on to FractInt. :) How's this idea sound? Allow a second formula--a coloring formula--to be written. This formula has its own p1, p2, p3, fn1, and fn2; it has access to z from the main "formula", as well as the other built-in variable types of the formula parser. Like a "normal" formula, it has an init section, a per-iteration section, and a keep-iterating section (so the coloring formula can force a bailout as well as the fractal formula). Essentially, it re-uses almost all of the existing formula parser. Ah, well, it was just a thought. I'd rather see looping abilities added to the formula parser, which will let me play around with a few other coloring techniques which right now aren't too practical. :) Damien M. Jones \\ dmj@fractalus.com \\ http://www.icd.com/tsd/ (temporary sanity designs) \\ http://www.fractalus.com/ (fractals are my hobby) - - - ------------------------------------------------------------ Thanks for using Fractdev, The Fractint Developer's Discussion List Post Message: fractdev@xmission.com Get Commands: majordomo@xmission.com "help" Administrator: twegner@phoenix.net Unsubscribe: majordomo@xmission.com "unsubscribe fractdev" ------------------------------ Date: Mon, 2 Feb 1998 17:21:51 -0500 From: George Martin <76440.1143@compuserve.com> Subject: Re: (fractdev) Re: progress.txt Rich, > We already have the ability to take the integer portion of a value by doing int(x) < The function is "trunc()", which lops of the fractional part of both the real and imaginary components of a complex number. George - - - ------------------------------------------------------------ Thanks for using Fractdev, The Fractint Developer's Discussion List Post Message: fractdev@xmission.com Get Commands: majordomo@xmission.com "help" Administrator: twegner@phoenix.net Unsubscribe: majordomo@xmission.com "unsubscribe fractdev" ------------------------------ Date: Mon, 02 Feb 1998 15:49:56 -0700 From: Rich Thomson Subject: Re: (fractdev) Notion: coloring formulae - ------- =_aaaaaaaaaa0 Content-Type: text/plain; charset="us-ascii" Content-ID: <24035.886459792.1@woody> In article <3.0.3.32.19980202142224.02ed2ea8@megspo.megsinet.net> , "Damien M. Jones" writes: > I've been thinking about using the formula parser to define coloring > algorithms. Obviously, I already have one way to do it--but this requires > editing the formula every time a new core fractal equation is to be used. > So I was thinking about ways to generalize the technique, that are actually > somewhat easy to bolt on to FractInt. :) Damien, does the attached message look familiar? :) - -- Rich Thomson rthomson@ptc.com - ------- =_aaaaaaaaaa0 MIME-Version: 1.0 Content-Type: message/rfc822 Delivery-Date: Mon, 19 Jan 1998 11:54:14 -0700 Received: from dbank (dbank.ptc.com [199.6.17.9]) by woody (950413.SGI.8.6.12/950213.SGI.AUTOCF) via SMTP id LAA01209 for ; Mon, 19 Jan 1998 11:54:14 -0700 Received: from poster (poster.ptc.com) by dbank (5.x/SMI-SVR4) id AA08348; Mon, 19 Jan 1998 11:54:11 -0700 Received: from lists.xmission.com by poster (5.x/SMI-SVR4-NN) id AA18912; Mon, 19 Jan 1998 13:53:17 -0500 Received: from domo by lists.xmission.com with local (Exim 1.73 #4) id 0xuMKj-0002Uk-00; Mon, 19 Jan 1998 11:54:05 -0700 Message-Id: <199801191852.LAA01190@woody> To: fractint@xmission.com Subject: (fractint) generalizing coloring methods Organization: Design Software Group, Parametric Technology Corporation Date: Mon, 19 Jan 1998 11:52:54 -0700 From: Rich Thomson Sender: owner-fractint@lists.xmission.com Precedence: bulk Reply-To: fractint@lists.xmission.com In anticipation of 24-bit (and 32-bit) rendering modes in fractint, I've been wondering if there isn't a way to unify all the various coloring tricks embedded in FRMs as well as fractint's internal coloring algorithms. Here is what I have been thinking... if we define a coloring "formula" and apply it to the iteration. Here is the proposed anatomy of a coloring formula: name { initialization : per-iteration finalization } name The name of this coloring method initialization Similar to the initialization section for a formula; "pixel" and other magic variables are initialized so they can be used by the coloring formula. The coloring formula can introduce its own variables and initialize them here. per-iteration For coloring methods where the variables must be updated every iteration, change that information in this section finalization After the orbit has finished (because it bailed out, or reached maxiter, or hit a period cycle, etc.), this section assigns the pixel's color value Here are some examples of the builtin coloring methods fractint has: iter { index = 0 : index++, color=colormap[index] } epsilon_cross { axis = 0, index = 0 : if (!axis && (imag(z) < .01)) then axis = 1 else if (!axis && (real(z) < .01)) then axis = 2 endif index++, if (axis == 1) then color = green else if (axis == 2) then color = yellow else color = colormap[index] endif } In the epsilon_cross case, you might want to be able to have a way to terminate the orbit early when you detect it nearing the axis. A new syntax could be introduced to allow the coloring scheme to affect the bailout, or there could be a statement that aborted the iteration because of the coloring test. I think this kind of scheme encompasses all the existing coloring modes of fractint and also covers the kinds of balls/stalks/etc. types of colorings that others have embedded into their formulas. The nice thing about this kind of approach is that it separates the formulas from the coloring. Want a fancy colored M-set? No need to avoid the builtin type=mandel then, just specify the fancy coloring. What do others think of this idea? Are there coloring schemes that DON'T fit into this framework? I'd like to get something that is as general as possible before doing any work on writing fractint code to support it. - -- ``Between stimulus and response is the will to choose.'' -- Steven Covey =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= 3D Paint: The Power to Create in 3D; Rich Thomson email me for more info rthomson@ptc.com - - - ------------------------------------------------------------ Thanks for using Fractint, The Fractals and Fractint Discussion List Post Message: fractint@xmission.com Get Commands: majordomo@xmission.com "help" Administrator: twegner@phoenix.net Unsubscribe: majordomo@xmission.com "unsubscribe fractint" - ------- =_aaaaaaaaaa0-- - - - ------------------------------------------------------------ Thanks for using Fractdev, The Fractint Developer's Discussion List Post Message: fractdev@xmission.com Get Commands: majordomo@xmission.com "help" Administrator: twegner@phoenix.net Unsubscribe: majordomo@xmission.com "unsubscribe fractdev" ------------------------------ End of fractdev-digest V1 #4 ****************************