ftp.xmission.com/2014.06.ftp.xmission.com.tar/ftp.xmission.com/pub/lists/fractdev/archive/v01.n016

Internet Message Format | 1998-12-07 | 40KB

From: [e-mail] (fractdev-digest)
To: [e-mail]
Subject: fractdev-digest V1 #16
Reply-To: fractdev-digest
Sender: [e-mail]
Errors-To: [e-mail]
Precedence: bulk


fractdev-digest       Tuesday, December 8 1998       Volume 01 : Number 016




----------------------------------------------------------------------

Date: Fri, 4 Dec 1998 22:24:47 -0600
From: "Tim Wegner" <[e-mail]>
Subject: (fractdev) Need Borland tlink

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:   [e-mail]
Get Commands:   [e-mail] "help"
Administrator:  [e-mail]
Unsubscribe:    [e-mail] "unsubscribe fractdev"

------------------------------

Date: Sat, 5 Dec 1998 10:38:12 -0600
From: "Tim Wegner" <[e-mail]>
Subject: (fractdev) New synch for 1961p58

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:   [e-mail]
Get Commands:   [e-mail] "help"
Administrator:  [e-mail]
Unsubscribe:    [e-mail] "unsubscribe fractdev"

------------------------------

Date: Sat, 5 Dec 1998 11:06:15 -0600
From: "Tim Wegner" <[e-mail]>
Subject: Re: (fractdev) New synch for 1961p58

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:   [e-mail]
Get Commands:   [e-mail] "help"
Administrator:  [e-mail]
Unsubscribe:    [e-mail] "unsubscribe fractdev"

------------------------------

Date: Sat, 5 Dec 1998 17:41:24 -0500 (EST)
From: [e-mail] (Kragen)
Subject: Re: (fractdev) Re: source code

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?!

- --
<[e-mail]>       Kragen Sitaker     <http://www.pobox.com/~kragen/>
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:   [e-mail]
Get Commands:   [e-mail] "help"
Administrator:  [e-mail]
Unsubscribe:    [e-mail] "unsubscribe fractdev"

------------------------------

Date: Sun, 06 Dec 1998 09:40:50 -0800 (PST)
From: Jiho Kim <[e-mail]>
Subject: (fractdev) Thanks and happy wishes

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:   [e-mail]
Get Commands:   [e-mail] "help"
Administrator:  [e-mail]
Unsubscribe:    [e-mail] "unsubscribe fractdev"

------------------------------

Date: Sun, 06 Dec 1998 12:44:08 -0700
From: Phil McRevis <[e-mail]>
Subject: Re: (fractdev) Re: source code

In article <[e-mail]>,
    [e-mail] (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 :)
- --
<http://www.xmission.com/~legalize/>    Legalize Adulthood!
    ``Ain't it funny that they all fire the pistol,
      at the wrong end of the race?''--PDBT
[e-mail]    <http://www.eden.com/~thewho>

- --------------------------------------------------------------
Thanks for using Fractdev, The Fractint Developer's Discussion List
Post Message:   [e-mail]
Get Commands:   [e-mail] "help"
Administrator:  [e-mail]
Unsubscribe:    [e-mail] "unsubscribe fractdev"

------------------------------

Date: Sun, 6 Dec 1998 18:44:40 +0100
From: "Dean-Christian Strik" <[e-mail]>
Subject: Re: (fractdev) Re: source code

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.


<silence>

>I am slightly puzzled what FP fractal calculation has to do with PNG
>support.


Nothing. Who said so?

- --

Dean-Christian Strik
   ICQ: 11760568
 [e-mail]
[e-mail]

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?!
>
>--
><[e-mail]>       Kragen Sitaker     <http://www.pobox.com/~kragen/>
>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:   [e-mail]
>Get Commands:   [e-mail] "help"
>Administrator:  [e-mail]
>Unsubscribe:    [e-mail] "unsubscribe fractdev"
>



- --------------------------------------------------------------
Thanks for using Fractdev, The Fractint Developer's Discussion List
Post Message:   [e-mail]
Get Commands:   [e-mail] "help"
Administrator:  [e-mail]
Unsubscribe:    [e-mail] "unsubscribe fractdev"

------------------------------

Date: Sun, 6 Dec 1998 19:36:17 -0600
From: "Tim Wegner" <[e-mail]>
Subject: Re: (fractdev) Re: source code

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:   [e-mail]
Get Commands:   [e-mail] "help"
Administrator:  [e-mail]
Unsubscribe:    [e-mail] "unsubscribe fractdev"

------------------------------

Date: Mon, 7 Dec 1998 00:20:51 -0200 (EDT)
From: Humberto Rossetti Baptista <[e-mail]>
Subject: (fractdev) Evolver & Diffusion

    Hi Robin,

On Fri, 4 Dec 1998 [e-mail] 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
    [e-mail]

- ---------------------------------------------------------------------------
Insite - Solucoes Internet                         http://www.insite.com.br


- --------------------------------------------------------------
Thanks for using Fractdev, The Fractint Developer's Discussion List
Post Message:   [e-mail]
Get Commands:   [e-mail] "help"
Administrator:  [e-mail]
Unsubscribe:    [e-mail] "unsubscribe fractdev"

------------------------------

Date: Mon, 7 Dec 1998 00:25:48 -0200 (EDT)
From: Humberto Rossetti Baptista <[e-mail]>
Subject: RE: Re: (fractdev) Synchronous Orbits

On Fri, 4 Dec 1998 [e-mail] 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
    [e-mail]

- ---------------------------------------------------------------------------
Insite - Solucoes Internet                         http://www.insite.com.br


- --------------------------------------------------------------
Thanks for using Fractdev, The Fractint Developer's Discussion List
Post Message:   [e-mail]
Get Commands:   [e-mail] "help"
Administrator:  [e-mail]
Unsubscribe:    [e-mail] "unsubscribe fractdev"

------------------------------

Date: Mon, 7 Dec 1998 00:42:44 -0200 (EDT)
From: Humberto Rossetti Baptista <[e-mail]>
Subject: Re: (fractdev) Re: source code

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
    [e-mail]

- ---------------------------------------------------------------------------
Insite - Solucoes Internet                         http://www.insite.com.br


- --------------------------------------------------------------
Thanks for using Fractdev, The Fractint Developer's Discussion List
Post Message:   [e-mail]
Get Commands:   [e-mail] "help"
Administrator:  [e-mail]
Unsubscribe:    [e-mail] "unsubscribe fractdev"

------------------------------

Date: Sun, 6 Dec 1998 21:45:38 -0500
From: Jonathan Osuch <[e-mail]>
Subject: Re: (fractdev) Evolver & Diffusion

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:   [e-mail]
Get Commands:   [e-mail] "help"
Administrator:  [e-mail]
Unsubscribe:    [e-mail] "unsubscribe fractdev"

------------------------------

Date: Mon, 7 Dec 1998 00:46:23 -0200 (EDT)
From: Humberto Rossetti Baptista <[e-mail]>
Subject: Re: (fractdev) Parallel processing (was Synchronous Orbits)

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 <b> 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
    [e-mail]

- ---------------------------------------------------------------------------
Insite - Solucoes Internet                         http://www.insite.com.br


- --------------------------------------------------------------
Thanks for using Fractdev, The Fractint Developer's Discussion List
Post Message:   [e-mail]
Get Commands:   [e-mail] "help"
Administrator:  [e-mail]
Unsubscribe:    [e-mail] "unsubscribe fractdev"

------------------------------

Date: Mon, 7 Dec 1998 00:56:04 -0200 (EDT)
From: Humberto Rossetti Baptista <[e-mail]>
Subject: Re: (fractdev) Worklist and future directions

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
    [e-mail]

- ---------------------------------------------------------------------------
Insite - Solucoes Internet                         http://www.insite.com.br


- --------------------------------------------------------------
Thanks for using Fractdev, The Fractint Developer's Discussion List
Post Message:   [e-mail]
Get Commands:   [e-mail] "help"
Administrator:  [e-mail]
Unsubscribe:    [e-mail] "unsubscribe fractdev"

------------------------------

Date: Mon, 7 Dec 1998 01:00:05 -0200 (EDT)
From: Humberto Rossetti Baptista <[e-mail]>
Subject: Re: (fractdev) Need Borland tlink

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
    [e-mail]

- ---------------------------------------------------------------------------
Insite - Solucoes Internet                         http://www.insite.com.br


- --------------------------------------------------------------
Thanks for using Fractdev, The Fractint Developer's Discussion List
Post Message:   [e-mail]
Get Commands:   [e-mail] "help"
Administrator:  [e-mail]
Unsubscribe:    [e-mail] "unsubscribe fractdev"

------------------------------

Date: Mon, 7 Dec 1998 01:06:28 -0200 (EDT)
From: Humberto Rossetti Baptista <[e-mail]>
Subject: Re: (fractdev) New synch for 1961p58

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
    [e-mail]

- ---------------------------------------------------------------------------
Insite - Solucoes Internet                         http://www.insite.com.br


- --------------------------------------------------------------
Thanks for using Fractdev, The Fractint Developer's Discussion List
Post Message:   [e-mail]
Get Commands:   [e-mail] "help"
Administrator:  [e-mail]
Unsubscribe:    [e-mail] "unsubscribe fractdev"

------------------------------

Date: Mon, 7 Dec 1998 01:23:01 -0200 (EDT)
From: Humberto Rossetti Baptista <[e-mail]>
Subject: (fractdev) Announce: new features ;-)

    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
    [e-mail]

- ---------------------------------------------------------------------------
Insite - Solucoes Internet                         http://www.insite.com.br


- --------------------------------------------------------------
Thanks for using Fractdev, The Fractint Developer's Discussion List
Post Message:   [e-mail]
Get Commands:   [e-mail] "help"
Administrator:  [e-mail]
Unsubscribe:    [e-mail] "unsubscribe fractdev"

------------------------------

Date: Mon, 7 Dec 1998 11:43:57 +0100 (MET)
From: "Michael R. Ganss" <[e-mail]>
Subject: Re: (fractdev) Synchronous Orbits

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
[e-mail]              Stulle der hat einen drin.

- --------------------------------------------------------------
Thanks for using Fractdev, The Fractint Developer's Discussion List
Post Message:   [e-mail]
Get Commands:   [e-mail] "help"
Administrator:  [e-mail]
Unsubscribe:    [e-mail] "unsubscribe fractdev"

------------------------------

Date: Mon, 7 Dec 1998 09:54:09 -0500 (EST)
From: [e-mail] (Kragen)
Subject: Re: (fractdev) project list

On Thu, 3 Dec 1998, Phil McRevis wrote:
> Formula parser improvements:
>   C optimizer                           GM (under way)

What exactly does this mean?

- --
<[e-mail]>       Kragen Sitaker     <http://www.pobox.com/~kragen/>
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:   [e-mail]
Get Commands:   [e-mail] "help"
Administrator:  [e-mail]
Unsubscribe:    [e-mail] "unsubscribe fractdev"

------------------------------

Date: Mon, 7 Dec 1998 10:34:15 -0500 (EST)
From: [e-mail] (Kragen)
Subject: RE: Re: (fractdev) Synchronous Orbits

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.

- --
<[e-mail]>       Kragen Sitaker     <http://www.pobox.com/~kragen/>
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:   [e-mail]
Get Commands:   [e-mail] "help"
Administrator:  [e-mail]
Unsubscribe:    [e-mail] "unsubscribe fractdev"

------------------------------

Date: Mon, 7 Dec 1998 17:17:03 -0500
From: "Peter Gavin" <[e-mail]>
Subject: RE: (fractdev) Re: source code

    // 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: <[e-mail]>
=A0* Homepage: <http://garnet.acns.fsu.edu/~pbg1854>
=A0* Please send any comments or questions
=A0* directly to me. Spam, flames, and other
=A0* unsolicited e-mail should be sent to
=A0* <[e-mail]>
=A0* Thank you, and have a nice day.
=A0******************************************/


- --------------------------------------------------------------
Thanks for using Fractdev, The Fractint Developer's Discussion List
Post Message:   [e-mail]
Get Commands:   [e-mail] "help"
Administrator:  [e-mail]
Unsubscribe:    [e-mail] "unsubscribe fractdev"

------------------------------

Date: Tue, 8 Dec 1998 01:55:44 -0200 (EDT)
From: Humberto Rossetti Baptista <[e-mail]>
Subject: RE: Re: (fractdev) Synchronous Orbits

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
    [e-mail]

- ---------------------------------------------------------------------------
Insite - Solucoes Internet                         http://www.insite.com.br


- --------------------------------------------------------------
Thanks for using Fractdev, The Fractint Developer's Discussion List
Post Message:   [e-mail]
Get Commands:   [e-mail] "help"
Administrator:  [e-mail]
Unsubscribe:    [e-mail] "unsubscribe fractdev"

------------------------------

Date: Tue, 8 Dec 1998 02:02:02 -0200 (EDT)
From: Humberto Rossetti Baptista <[e-mail]>
Subject: (fractdev) Arbitrary precision & BC 3.1

    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
    [e-mail]

- ---------------------------------------------------------------------------
Insite - Solucoes Internet                         http://www.insite.com.br


- --------------------------------------------------------------
Thanks for using Fractdev, The Fractint Developer's Discussion List
Post Message:   [e-mail]
Get Commands:   [e-mail] "help"
Administrator:  [e-mail]
Unsubscribe:    [e-mail] "unsubscribe fractdev"

------------------------------

Date: Tue, 8 Dec 1998 02:07:49 -0200 (EDT)
From: Humberto Rossetti Baptista <[e-mail]>
Subject: (fractdev) Unity+Atan bug/feature?

    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
    [e-mail]

- ---------------------------------------------------------------------------
Insite - Solucoes Internet                         http://www.insite.com.br


- --------------------------------------------------------------
Thanks for using Fractdev, The Fractint Developer's Discussion List
Post Message:   [e-mail]
Get Commands:   [e-mail] "help"
Administrator:  [e-mail]
Unsubscribe:    [e-mail] "unsubscribe fractdev"

------------------------------

Date: Tue, 8 Dec 1998 18:32:59 -0500
From: Jonathan Osuch <[e-mail]>
Subject: Re: (fractdev) Unity+Atan bug/feature?

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:   [e-mail]
Get Commands:   [e-mail] "help"
Administrator:  [e-mail]
Unsubscribe:    [e-mail] "unsubscribe fractdev"

------------------------------

End of fractdev-digest V1 #16
*****************************