ftp.xmission.com/2014.06.ftp.xmission.com.tar/ftp.xmission.com/pub/lists/fractdev/archive/fractdev.9801

Internet Message Format | 1998-01-31 | 85KB

From: "Tim Wegner" <[e-mail]>
Subject: (fractdev) GIF encoders
Date: 06 Jan 1998 23:16:25 -0600

Thought I'd wake everyone up and post something <g!>

We've had a devil of a time with the fractint GIF encoder. It works
OK most of the time, but for images with many repeated pixels it
sometimes fails. Similarly, the simplgif utility that mashes
multiple-image GIFs into single images fails easily for large images
(try making a 6x6 image with each piece at 600x600 and you'll see
what I mean.) These bugs are probably related because the sources for
PDGIF are based on the same original encoder code in Fractint. Many
of us of stared at the code for hours and can't see any problems.

Today I dug out some ancient encoder code based on the Unix Compress,
and it seemed to work well. There is no copyright in the sources,
although there are some names and an attribution to compress.

We're now working on removing the 2048x2048 pixel limit of Fractint,
which will expose the encoder bug even more. I don't think it would
be too hard to rip out the encoder and put in a new one.

Does anyone know of some good GIF encoder code that we could use, or
should I go ahead and use the code I found. I'm not sure where I got
it - possibly CompuServe. I'll see if I can track down the original.

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"


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

From: "Michael R. Ganss" <[e-mail]>
Subject: Re: (fractdev) GIF encoders
Date: 07 Jan 1998 19:14:34 +0100 (MET)

Tim,

I've used ppmtogif.c from netpbm in AlmondBread. I haven't had any
problems with it thus far and application extensions can be worked in
pretty easily as far as I remember. It has a bsd-style license. You
can get it from
<URL:ftp://ee.utah.edu/Misc/pbmplus/netpbm/ppm/ppmtogif.c> among
others.

--
Michael R. Ganss        Cooper:  Look!  Ducks!  On a lake!  Ahhh.
[e-mail]        http://www.cs.tu-berlin.de/~rms/AlmondBread/

-
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"


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

From: "Damien M. Jones" <[e-mail]>
Subject: Re: (fractdev) GIF encoders
Date: 07 Jan 1998 10:52:47 -0600

Tim,

 - We're now working on removing the 2048x2048 pixel limit of Fractint...

Woo-hoo!  That's one limit I'll be happy to see gone. :)

 - Does anyone know of some good GIF encoder code that we could use, or
 - should I go ahead and use the code I found. I'm not sure where I got
 - it - possibly CompuServe. I'll see if I can track down the original.

I would have suggested some code we used a while back, but I've just found
a problem with the reader not liking certain GIFs.  Since I haven't had
time to determine whether it's the LZW part or file parsing, and the LZW
compress and decompress routines are so similar, I didn't want to suggest
possibly buggy code.  And there's no telling when I'll get a chance to work
on it.

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


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

From: Rich Thomson <[e-mail]>
Subject: Re: (fractdev) GIF encoders
Date: 07 Jan 1998 12:04:49 -0700


In article <[e-mail]> ,
    "Tim Wegner" <[e-mail]>  writes:
> Does anyone know of some good GIF encoder code that we could use, or
> should I go ahead and use the code I found. I'm not sure where I got
> it - possibly CompuServe. I'll see if I can track down the original.

I have found the freely available GIF encoders/decoders to be of
varying quality.  The one in pbmplus has failed on occasion.  I have a
GIF image which reproduces this bug faithfully, but the subject matter
isn't fit for CDA audiences.

Basically the giftopnm code sometimes encounters bad data causing one
of the inner routines to fail with an error code that isn't checked by
the caller and the program goes into an infinite loop.  The author has
promised an update, but it hasn't materialized yet.  (He says he has a
much improved version in both reliability and performance.)

You can also try <URL: http://locke.ccil.org/~esr/giflib/index.html>
which contains a library for dealing with GIF files.  I haven't
tweaked this to compile properly on my machine at home, so I don't
know how well it will work for you.  (Then again, I have Borland
compilers.)
--
  ``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                [e-mail]

-
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"


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

From: "Tim Wegner" <[e-mail]>
Subject: Re: (fractdev) GIF encoders
Date: 07 Jan 1998 18:21:35 -0600

Thanks Michael, Damien, and Rich. I'll investigate all your
suggestions. However I think the code I have (based on compress)
looks good. I'll post something soon and let folks beat up on it.

Whatever works for simplgif I'll probably put in Fractint as well.

Note we are talking about encoding, not decoding. The decoder
Fractint uses is based on a compression routine by Steve Bennett that
I downloaded from compuServe a decade ago. It is fast and reliable,
very well crafted. I've never had a confirmed bug report from the
decoder. Obviously, when we get to bigger images, both the encoder
and decoder are stressed.

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"


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

From: "Tim Wegner" <[e-mail]>
Subject: Re: (fractdev) GIF encoders
Date: 08 Jan 1998 22:07:49 -0600

Michael,

> I've used ppmtogif.c from netpbm in AlmondBread.

Turns out this is based on the exact routine I found, which is in
turn based on the Unix compress!

Thanks, it makes me feel better to realize the compress routine is
widely used.

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"


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

From: "Tim Wegner" <[e-mail]>
Subject: Re: (fractdev) GIF encoders
Date: 08 Jan 1998 22:07:49 -0600

Rich,

> Basically the giftopnm code sometimes encounters bad data causing one
> of the inner routines to fail with an error code that isn't checked by
> the caller and the program goes into an infinite loop.

Fortunately I have a good decoder, I only need a decoder.

> You can also try <URL: http://locke.ccil.org/~esr/giflib/index.html>
> which contains a library for dealing with GIF files.

This looked very promising until I realized it was Borland only. But
thanks, this was a very useful reference.

I think I'm in good shape with the compress lzw code, we shall see.

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"


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

From: Rich Thomson <[e-mail]>
Subject: Re: (fractdev) GIF encoders
Date: 09 Jan 1998 11:20:49 -0700


In article <[e-mail]> ,
    "Tim Wegner" <[e-mail]>  writes:
> > You can also try <URL: http://locke.ccil.org/~esr/giflib/index.html>
> > which contains a library for dealing with GIF files.
>
> This looked very promising until I realized it was Borland only. But
> thanks, this was a very useful reference.

How did you determine that?  Because I have a borland compiler at home
and I need to hack it more in order to make it work without crashing.
--
  ``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                [e-mail]

-
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"


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

From: "Tim Wegner" <[e-mail]>
Subject: Re: (fractdev) GIF encoders
Date: 09 Jan 1998 17:05:16 -0600

Rich asked:

> How did you determine that?  Because I have a borland compiler at home
> and I need to hack it more in order to make it work without crashing.

The PC make file says it is for Turbo C, and many programs (all the
programs that have screen graphics) use BGI (Borland) drivers. But I
mispoke - I meant *PC support* is Borland only. It supports Unix (GNU
C), and I could probably make it work with djgpp. I could probably
make it work with Microsoft C if I didn't try any of the programs
that use graphics video modes.

I am filing this code away for future reference. Meanwhile, until I
see a proplem, the compress-based encoder looks like exactly what I
need.

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"


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

From: Rich Thomson <[e-mail]>
Subject: (fractdev) Re: (fractint) Simplgif update
Date: 12 Jan 1998 10:13:24 -0700


[Rerouted to fractdev]

In article <[e-mail]> ,
    "Tim Wegner" <[e-mail]>  writes:
> Be warned that simplgif does not save fractal data. Also make sure
> you have lots of disk space. Simplgif warns you how much it needs.

What exactly is simplgif's algorithm for combining the pieces?
--
  ``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                [e-mail]

-
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"


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

From: "Tim Wegner" <[e-mail]>
Subject: Re: (fractdev) Re: (fractint) Simplgif update
Date: 12 Jan 1998 18:35:33 -0600

Rich asked:

> What exactly is simplgif's algorithm for combining the pieces?

Simplgif opens a flat file equal to x*y bytes. Simplgif then opens
each subimage of the MIG and writes each pixel to the correct
location in the flat file, one subimage at a time. SImple, but
effective, if you have a large, fast disk.

This will be obsolete soon because we are removing the 2048 pixel
limit from the developer's version. But right now consensus is we
should release version 19.6 with the better lzw encoder as 19.6a or
19.7. The 2048 limit removal will have to wait longer.

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"


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

From: Rich Thomson <[e-mail]>
Subject: Re: (fractdev) Re: (fractint) Simplgif update
Date: 12 Jan 1998 17:51:09 -0700


In article <[e-mail]> ,
    "Tim Wegner" <[e-mail]>  writes:
> Simplgif opens a flat file equal to x*y bytes. Simplgif then opens
> each subimage of the MIG and writes each pixel to the correct
> location in the flat file, one subimage at a time. SImple, but
> effective, if you have a large, fast disk.

It seems to me this "large, flat file" approach is only needed because
the image pieces have all been merged into one "MIG" file.  If the
images were kept as separate files, then you shouldn't need more than
2N pixels worth of memory for outputting a final image of N pixels per
scanline.  Is there any purpose tot he "MIG" file other than preparing
input for simplgif anyway?
--
  ``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                [e-mail]

-
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"


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

From: "Tim Wegner" <[e-mail]>
Subject: Re: (fractdev) Re: (fractint) Simplgif update
Date: 12 Jan 1998 20:39:06 -0600

Rich wrote:

> It seems to me this "large, flat file" approach is only needed because
> the image pieces have all been merged into one "MIG" file.

No, the MIG is really nothing more than the concatenation of the
separate GIFs. There's little difference between the GIFs being
separate or merged in a MIG. If anything, having them in a MIG is a
bit simpler.

> If the
> images were kept as separate files, then you shouldn't need more than
> 2N pixels worth of memory for outputting a final image of N pixels per
> scanline.

Your basic point is well taken (though I don't think in separate
files has anything to do with it.) If one were willing to
simultaneously decompress all the images, no intermediate file would
be needed at all. Even if the requirement is to totally decompress
one image at a time, if the subimages are read left-to-right, the
file only needs to be as high as the subimages. That's a whole lot
less than a file for the whole image.

> Is there any purpose to he "MIG" file other than preparing
> input for simplgif anyway?

The only point of the MIG is to make the files safer by putting them
together. This is easily done with GIF, because as I said, with just
minor changes to the subimage headers, and the addition of one
overall image descriptor, the LZW doesn't even need to be
decompressed. The images are (almost) just concatenated.

The history of why simplgif is the way it is is this. Lee Crocker and
Bert Tyler wrote a public domain set of routines called pdgif. I'm
not sure they ever released it. When we needed to mash the GIFs in
the MIG, Bert volunteered to take pdgif and write the code. He did so
in a brute force way, writing the big file. Part of the idea was that
simplgif could read any GIF however complex, whether interlaced, a
MIG, or whatever, and convert it to a plain single image. The desire
to convert any GIF motivated the brute approach.

It's not a hard programming job to take any good GIF code or library
and make a MIG->GIF encoder. If one knows that the MIG is from
Fractint, along the lines you suggest it could be made more
efficient.

My adaptation of Bert's simplgif uses pdgif's decoder to write the
file, then uses the gifencod/gifcompr files from the modified UNIX
compress to do the encoding. I don't use pdgif's encoder at all
because it is buggy.

If anyone wants to see this code let me know. I could make simplgif
make a smaller temporary file along the lines you suggest, but I'm
not sure it would be worth it, given that in the developer's version
simplgif is not needed at all - giant GIFs are made directly.

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"


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

From: Rich Thomson <[e-mail]>
Subject: Re: (fractdev) Re: (fractint) Simplgif update
Date: 13 Jan 1998 10:28:56 -0700


Previously, Tim wrote:
> This will be obsolete soon because we are removing the 2048 pixel
> limit from the developer's version. But right now consensus is we
> should release version 19.6 with the better lzw encoder as 19.6a or
> 19.7. The 2048 limit removal will have to wait longer.

But Tim, there will always be _some_ limit, if only just imposed by
the size of an unsigned int.  So what is the size of the new limit?
32 bit unsigned int?

In article <[e-mail]> ,
    "Tim Wegner" <[e-mail]>  writes:
> Your basic point is well taken (though I don't think in separate
> files has anything to do with it.) If one were willing to
> simultaneously decompress all the images, no intermediate file would
> be needed at all. Even if the requirement is to totally decompress
> one image at a time, if the subimages are read left-to-right, the
> file only needs to be as high as the subimages. That's a whole lot
> less than a file for the whole image.

Let me see if I understand exactly how the MIGs are structured.  There
is a global "MIG header".  What's in this header?  (I looked in the
xfractint sources, but couldn't find any source for simplgif.)  Then
each subimage has a header that indicates its (x,y) position in the
larger image?  You could scan through once to build up a list of all
the images and their locations and then process everything in scanline
order and you wouldn't need the intermediate file at all.  Things
would go much faster.  There are more uses for the NxM tiling than
just getting around fractint's 2048 limit, ya know.  I use it to
naturally generate regular grids in the image plane.  However, that
does seem to be the whole point behind simplgif; for fractint, its
whole purpose in life is to stitch together images.
--
  ``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                [e-mail]

-
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"


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

From: "Tim Wegner" <[e-mail]>
Subject: Re: (fractdev) Re: (fractint) Simplgif update
Date: 14 Jan 1998 16:53:17 -0600

Rich queried:

> But Tim, there will always be _some_ limit, if only just imposed by
> the size of an unsigned int.  So what is the size of the new limit?
> 32 bit unsigned int?

At the moment there are a lot of variables that are signed ints,
which on a PC are 16 bits, so effectively the limit is 2^15 pixels.
However, we can systematically convert variables to unsigned and
increase the limit to 2^16 pixels.

The only way with the present architecture to achieve these high
resolutions (on the PC anyway) is via disk video, which is another
x*y flat file. So there's a disk size limit. Obviously Xfractint (or
any 32 bit flat memory port) will be able to overcome these limits
with a bit of work.

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"


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

From: Rich Thomson <[e-mail]>
Subject: Re: (fractdev) Re: (fractint) Simplgif update
Date: 14 Jan 1998 15:57:43 -0700


In article <[e-mail]> ,
    "Tim Wegner" <[e-mail]>  writes:
> At the moment there are a lot of variables that are signed ints,
> which on a PC are 16 bits, so effectively the limit is 2^15 pixels.

Actually, 2^16 - 1 for signed ints, right?

So the limit is something like 32K.  Better than 2K, but still
overflowed when rendering huge versions for anti-aliasing down to
1200dpi laser output.
--
  ``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                [e-mail]

-
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"


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

From: "Tim Wegner" <[e-mail]>
Subject: Re: (fractdev) Re: (fractint) Simplgif update
Date: 14 Jan 1998 17:23:58 -0600

Rich pointed out:

> Actually, 2^16 - 1 for signed ints, right?

Of course <g!>

This is actually easy to test with the devlopers version, since it is
possible to create diskvideo modes with resolutions like 32k x 20 or
some such. Of course 32k x 32k isn't practical.

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"


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

From: "Damien M. Jones" <[e-mail]>
Subject: Re: (fractdev) Re: (fractint) Simplgif update
Date: 14 Jan 1998 17:34:07 -0600

 - > Actually, 2^16 - 1 for signed ints, right?
 -
 - Of course <g!>

Pardon me for nitpicking, but isn't 32,767 actualy 2^15-1, not 16?

 - Of course 32k x 32k isn't practical.

Give Jon Noring a chance... I'm sure he'll find 32Kx32K useful for
something. :)

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


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

From: "Tim Wegner" <[e-mail]>
Subject: Re: (fractdev) Re: (fractint) Simplgif update
Date: 14 Jan 1998 18:22:00 -0600

Damien asked:

> Pardon me for nitpicking, but isn't 32,767 actualy 2^15-1, not 16?

Sorry, when I get home from a hard day at NASA my brain is entirely
disengaged. :-) Once again yes, with signed integers we are talking
2^15 - 1 or 32767. However, we can extend this to 2^16-1, and when we
go to PNG, we'll also change the way fractal parameters are stored,
and will make image dimensions essentially unlimited. PNG images
support image dimensions stored in signed 32 bit images I believe.

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"


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

From: Rich Thomson <[e-mail]>
Subject: (fractdev) formula fractals under xfractint
Date: 22 Jan 1998 17:48:48 -0700

Why are these so dang slow?  It takes aeons for my 250 Mhz R4000 SGI
to compute a single image.
--
  ``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                [e-mail]

-
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"


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

From: "Damien M. Jones" <[e-mail]>
Subject: Re: (fractdev) formula fractals under xfractint
Date: 23 Jan 1998 11:26:36 -0600

Rich,

 - Why are these so dang slow?  It takes aeons for my 250 Mhz R4000 SGI
 - to compute a single image.

Probably because the formula parser is written to run entirely in C, rather
than optimized assembly.  Which is too bad, because I think the formula
parser is the most important part of FractInt. :)

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


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

From: Rich Thomson <[e-mail]>
Subject: Re: (fractdev) formula fractals under xfractint
Date: 23 Jan 1998 16:49:26 -0700


In article <[e-mail]> ,
    "Damien M. Jones" <[e-mail]>  writes:
> Probably because the formula parser is written to run entirely in C, rather
> than optimized assembly.  Which is too bad, because I think the formula
> parser is the most important part of FractInt. :)

It seems worse than that though.  I think there are extra levels of
function calls that aren't needed.... but yes, it sure would be handy
to have the formula compiled to R3000 assembly.  Given that the MIPS
architecture is very regular, it might not even be too hard to
optimize for that.
--
  ``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                [e-mail]

-
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"


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

From: "Tim Wegner" <[e-mail]>
Subject: Re: (fractdev) formula fractals under xfractint
Date: 23 Jan 1998 20:01:45 -0600

Rich said:

> It seems worse than that though.  I think there are extra levels of
> function calls that aren't needed.... but yes, it sure would be handy
> to have the formula compiled to R3000 assembly.  Given that the MIPS
> architecture is very regular, it might not even be too hard to
> optimize for that.

Damien is basically right. Chuck Ebbert wrote the fast parser, which
is an incredible piece of work. It is fast both because of
parser language optimizations as well as assembler
optimizations keeping variables in registers as much as
possible. The logical stack of the parser is implemented directly
using the stack registers of the coprocessor! So it's fast
because the software design is directly implemented in the
hardware.

Unfortunately the presence of the fast parser has diverted the team
from optimizing the C. Many of the parser language optimizations in
the fast parser could be implemented in C as well. And certainly the
function call overhead could be improved. If anyone wants to work on
this, they should coordinate with George Martin.

Does the R3000 have an FPU stack analagous to the x87?

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"


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

From: Rich Thomson <[e-mail]>
Subject: Re: (fractdev) formula fractals under xfractint
Date: 26 Jan 1998 09:30:41 -0700


In article <[e-mail]> ,
    "Tim Wegner" <[e-mail]>  writes:
> Unfortunately the presence of the fast parser has diverted the team
> from optimizing the C. Many of the parser language optimizations in
> the fast parser could be implemented in C as well. And certainly the
> function call overhead could be improved. If anyone wants to work on
> this, they should coordinate with George Martin.

Which brings up another thought.... is anyone keeping an up-to-date
"issues" or "TODO" documents for xfractint/fractint?  I think we are
getting lots of good suggestions from the wish list and other areas
but they need to be kept organized into the source so that when people
download the source and are feeling energetic, they are already
presented with a list of things they could do to help.... bugs should
also be tracked and documented this way.

> Does the R3000 have an FPU stack analagous to the x87?

The MIPS architecture is regular and orthogonal being the first
popularized RISC architecture.  FPU instructions operate on registers,
and any register could be used as a pointer to the top of a stack in
memory.  It is more similar to the 68K architecture in that regard.
--
  ``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                [e-mail]

-
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"


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

From: Rich Thomson <[e-mail]>
Subject: Re: (fractdev) formula fractals under xfractint
Date: 26 Jan 1998 09:30:41 -0700


In article <[e-mail]> ,
    "Tim Wegner" <[e-mail]>  writes:
> Unfortunately the presence of the fast parser has diverted the team
> from optimizing the C. Many of the parser language optimizations in
> the fast parser could be implemented in C as well. And certainly the
> function call overhead could be improved. If anyone wants to work on
> this, they should coordinate with George Martin.

Which brings up another thought.... is anyone keeping an up-to-date
"issues" or "TODO" documents for xfractint/fractint?  I think we are
getting lots of good suggestions from the wish list and other areas
but they need to be kept organized into the source so that when people
download the source and are feeling energetic, they are already
presented with a list of things they could do to help.... bugs should
also be tracked and documented this way.

> Does the R3000 have an FPU stack analagous to the x87?

The MIPS architecture is regular and orthogonal being the first
popularized RISC architecture.  FPU instructions operate on registers,
and any register could be used as a pointer to the top of a stack in
memory.  It is more similar to the 68K architecture in that regard.
--
  ``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                [e-mail]

-
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"


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

From: "Tim Wegner" <[e-mail]>
Subject: Re: (fractdev) formula fractals under xfractint
Date: 27 Jan 1998 00:38:44 -0600

Rich said,

> Which brings up another thought.... is anyone keeping an up-to-date
> "issues" or "TODO" documents for xfractint/fractint?

If someone wants to do this, they are welcome.

I patched in your SGI fixes, and had no problems compiling under DOS.
I'll incorporate your suggestions in the next patch. I'll also test
them under Linux.

I need to set up a system for distributing the diffs to folks here.

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"


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

From: Rich Thomson <[e-mail]>
Subject: Re: (fractdev) formula fractals under xfractint
Date: 27 Jan 1998 09:53:47 -0700


In article <[e-mail]> ,
    "Tim Wegner" <[e-mail]>  writes:
> > Which brings up another thought.... is anyone keeping an up-to-date
> > "issues" or "TODO" documents for xfractint/fractint?
>
> If someone wants to do this, they are welcome.

OK, I volunteer.  Let me draft up something and mail it to this list
and then we can add whatever I've missed or forgotten.
--
                                               Rich Thomson
                                               [e-mail]

-
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"


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

From: "Tim Wegner" <[e-mail]>
Subject: (fractdev) fractint list postings
Date: 28 Jan 1998 17:14:46 -0600

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


-
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"


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

From: "Jay Hill"<[e-mail]>
Subject: (fractdev) Is this still a great list or what...
Date: 28 Jan 1998 15:41:36 -0800


Hi Fractintiers,

In case you have not been following the Fractal of the Night,
I have posted all of them here

http://home.san.rr.com/jayrhill/FotN/FotNindx.html

including the par files.  Last we heard, Dr J (the mad scientist
of fractal space) went to the FractoBowl. He has not been heard
from since. Some think he over consumed some beverages perhaps.

Among the nonsense, there are hopefully some helpful hints for
your Fractint formula programming from one who is learning
with the rest of this list.

Jay



-
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"


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

From: "Jay Hill"<[e-mail]>
Subject: Re: (fractdev) fractint list postings
Date: 28 Jan 1998 15:49:19 -0800


Hi guys,

Can the formula parser be extended to include these functions

IsOdd(x)  - returns 1 if x is odd integer, else 0

Remainder(x,y) - returns remainded of x/y (or what ever the usual C
conventions is)

Thanks,
Jay

PS  If there is a work around or a function that does this, fine. Let me
know.




-
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"


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

From: Rich Thomson <[e-mail]>
Subject: Re: (fractdev) fractint list postings
Date: 28 Jan 1998 17:08:32 -0700


In article <[e-mail]> ,
    "Jay Hill"<[e-mail]>  writes:
> Can the formula parser be extended to include these functions
>
> IsOdd(x)  - returns 1 if x is odd integer, else 0

    ; true if x/2 has any fractional part
    if (trunc(x/2) != x/2)
      ...
    endif

> Remainder(x,y) - returns remainded of x/y (or what ever the usual C
> conventions is)

    In C, this would be the % operator for integers, or fmod(x,y) for
    floating point.  What is the "remainder" of a complex divison
    though?  Anyway, you can do this until you get a builtin:

    remainder = y*(x/y - trunc(x/y))
--
                                               Rich Thomson
                                               [e-mail]

-
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"


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

From: "Tim Wegner" <[e-mail]>
Subject: Re: (fractdev) fractint list postings
Date: 28 Jan 1998 18:19:24 -0600

Jay asked:

> Can the formula parser be extended to include these functions
>
> IsOdd(x)  - returns 1 if x is odd integer, else 0
>
> Remainder(x,y) - returns remainded of x/y (or what ever the usual C
> conventions is)

Sure will do. If someone sees we can easily do these already, let me
know.

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"


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

From: "Jay Hill"<[e-mail]>
Subject: Re: (fractdev) fractint list postings
Date: 28 Jan 1998 16:26:52 -0800


Jay wrote

> IsOdd(x)  - returns 1 if x is odd integer, else 0
>
> Remainder(x,y) - returns remainder of x/y (or what ever the usual C
> conventions is)

Rich suggested trunc()

I knew that ...  :^)

Thanks Rich, that should do the job.  Tim, the only question is would
my functions be faster for working with our color counters, iter, and so
on.

Will later versions give us access to iter so we don't have to count our
own?

Jay



-
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"


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

From: Rich Thomson <[e-mail]>
Subject: Re: (fractdev) fractint list postings
Date: 28 Jan 1998 17:42:26 -0700


In article <[e-mail]> ,
    "Tim Wegner" <[e-mail]>  writes:
> > IsOdd(x)  - returns 1 if x is odd integer, else 0
> >
> > Remainder(x,y) - returns remainded of x/y (or what ever the usual C
> > conventions is)
>
> Sure will do. If someone sees we can easily do these already, let me
> know.

If you decide to implement these as builtins, consider just
implementing the equivalent of fmod().  IsOdd is really just a special
case of remainder: IsOdd(x) == Remainder(x, 2).  But rather than
calling the function "remainder", I'd suggest following C syntax and
using % as a modulus operator:

    IsOdd(x) := x % 2
    Remainder(x, y) := x % y;
--
                                               Rich Thomson
                                               [e-mail]

-
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"


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

From: "Jim sellers" <[e-mail]>
Subject: (fractdev) Virus
Date: 28 Jan 1998 18:38:10 -0800

I just received this message and know nothing about it but it camed from a
friend and thought I should pass it on
Jim Sellers
> > > Subject:
> > > Date: Fri, 23 Jan 1998 10:52:17 -0500 (EST)
> > > Message-ID: <l0310280db0ee27e83074@[140.103.60.92]>
> > >
> > > VIRUS WARNING
> > > If you receive an email titled "JOIN THE CREW," DO NOT open it. It
will erase everything on your hard drive. Forward this letter out to as
many people as you can. This is a new, very malicious virus and not many
people know about it. This informatio
n was announced Wednesday morning from IBM;

 please share it with everyone that might access the internet. Once
again, pass this along to EVERYONE in your address book so that this may
be stopped.

Also, do not open or even look at any mail that says
"RETURNED OR UNABLE TO DELIVER." This virus will attach itself to your
computer components and render them useless. Immediately delete any mail
items that say this.

AOL has said that this is a very dangerous virus and that
there is NO remedy for it at this time. Please practice cautionary
measures and forward this to all users.
> > >
> > > Gloria Litteral
> > > Administrative Assistant to the Dean
> > > Dean of Students' Office
> > > The College of Wooster
> > > Galpin Hall
> > > Wooster, Ohio   4469l
> > > Telephone: [phone]ll
> > > FAX: [phone]
> > > e-mail:  [e-mail]
> > >
> > > --------- End forwarded message ----------
> > Received this from a friend, and have no reason to doubt it.  I've
> > already had a couple of messages that were returned that should have
> > gone through.
> >
> > Pat Cline



-
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"


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

From: "Damien M. Jones" <[e-mail]>
Subject: Re: (fractdev) fractint list postings
Date: 28 Jan 1998 19:16:45 -0600

Tim,

Further suggestions for parser keywords:

  trisq - "tri" square, like whitesq but returns 0-2 for PTC fractals
  quadsq - "quad" square, returns 0-3 for PTC fractals
  iter - access to the iteration count

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


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

From: "Tim Wegner" <[e-mail]>
Subject: Re: (fractdev) fractint list postings
Date: 28 Jan 1998 21:55:40 -0600


> > IsOdd(x)  - returns 1 if x is odd integer, else 0
>
>     ; true if x/2 has any fractional part
>     if (trunc(x/2) != x/2)
>       ...
>     endif

IsOdd() might still be worthwhile to implement for clarity and
efficiency. But of course the argument is a complex number. At some
time we might try to create some integer data types.

>
> > Remainder(x,y) - returns remainder of x/y (or what ever the usual C
> > conventions is)
>
>     In C, this would be the % operator for integers, or fmod(x,y) for
>     floating point.  What is the "remainder" of a complex divison
>     though?  Anyway, you can do this until you get a builtin:
>
>     remainder = y*(x/y - trunc(x/y))

Once again, we're processing just the real part., right? This one
would be much more efficient is built it.

Jay, how about making a case for this with a sample formula. Hello
artists, do you want these, especially since Rich has shown how to
build them from existing functions?

The floor is open for other function proposals.

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"


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

From: George Martin <[e-mail]>
Subject: Re: (fractdev) fractint list postings
Date: 29 Jan 1998 08:53:06 -0500

Tim,

>Remainder(x, y)

A thought - if we're going to do something like this, let's keep intact the
formula parser convention of functions taking only one argument. The
remainder "function" should therefore be implemented as an operator.

George

-
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"


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

From: Rich Thomson <[e-mail]>
Subject: Re: (fractdev) Virus
Date: 29 Jan 1998 10:09:05 -0700


This is a variation on the well known "Good Times" hoax.  The virus is
the warning itself, you just propagated the virus by "warning" us.

See <URL: http://www.sarc.com/> under "virus hoaxes"

In the future, before you pass on a virus "warning" from someone else,
check a site like that one (sarc is Symantec AntiVirus Research Center,
run by Symantec, which makes Norton Anti-Virus).  The virus companies
are aware of all the hoaxes long before most people have heard of
them.  Whenever passing on a "security alert", it is crucial that you
check the truthfulness of the report.  Many times more harm than good
is done by passing false reports and causing people to worry about and
spend time investigating non-existent problems.
--
                                               Rich Thomson
                                               [e-mail]

-
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"


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

From: Rich Thomson <[e-mail]>
Subject: Re: (fractdev) fractint list postings
Date: 29 Jan 1998 10:35:42 -0700


In article <[e-mail]> ,
    "Damien M. Jones" <[e-mail]>  writes:
> Further suggestions for parser keywords:
>
>   trisq - "tri" square, like whitesq but returns 0-2 for PTC fractals
>   quadsq - "quad" square, returns 0-3 for PTC fractals
>   iter - access to the iteration count

Access to iter is a really good idea.  For compatability with old
formulas that used the variable called "iter" for their own iteration
count, you could detect this by examining the initialization section
of a formula -- if it contains a variable called "iter", then all
references to "iter" in the formula refer to this variable; it hides
the iter value maintained by fractint.

For trisq and quadsq, I'd prefer to see fractint's formula syntax
extended to include the keywords "int", "real", and "complex".  The
keyword precedes an expression or variable and casts the expression or
variable to that type.  Example:

    foo {
    int i = 0,        ; i is an integer variable
    z = 0,            ; default is still complex
    complex w = 0,        ; but we can also state it explicitly
    real mag = 0,        ; mag is a real variable
    trisq = scrnpix % 3    ; trisq's real/imag parts are 0-3
    quadsq = scrnpix % 4;    ; quadsq's real/imag parts are 0-4
    :
    z = sqr(z) + pixel    ; complex math
    i = i+1            ; integer math
    mag = |z|        ; real math (return magnitude of z)
    mag > 4.0
    }

Since integer variables are often being incremented or decremented, it
probably makes sense to either introduce the C syntax of ++/-- postfix
operators (and possibly prefix versions as well), or you could go the
pascalish route of providing inc/dec functions.  For trisq and quadsq,
I cheated a little in using a non-existing modulus operator.  However,
it does convey the intent.  In strict 19.6 fractint, we'd have to
write:

    trisq = 3*(real(scrnpix)/3 - trunc(real(scrnpix)/3)) +
        flip(3*(imag(scrnpix)/3 - trunc(imag(scrnpix)/3)))

Which isn't very efficient at all.  If we had a % operator that took a
complex c and an integer d as "c % d" and computed:

    c % d = (real(c) % d, imag(c) % d)

then we could easily compute trisq and quadsq like this:

    trisq = scrnpix % 3;
    quadsq = scrnpix % 4;

as above.  This would also be efficient, since the parser knows that
scrnpix is really two integers disguised as a complex.

However, if you want a complex modulus operator, you want
"complex % complex" to be defined differently than what I've shown
when the second argument is an integer.

These are issues to add to the TODO list for the formula parser.
--
                                               Rich Thomson
                                               [e-mail]

-
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"


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

From: George Martin <[e-mail]>
Subject: Re: (fractdev) fractint list postings
Date: 29 Jan 1998 13:43:59 -0500

Rich,

>quadsq - "quad" square, returns 0-3 for PTC fractals

whitesq is (row + col) % 2
trisq can be (row + col) % 3

but the pattern for the 4 layer PTCs is

          0 1 2 3 0 1 . .
          2 3 0 1 2 3 . .
          0 1 2 3 0 1 . .
          2 3 0 1 2 3 . .
          . . . . . . . .

which will require a little different approach.

Implementing "trisq" and "quadsq" as predefined variables will be easy
enough, and I'll go ahead and do it unless someone wants to discuss it
more. The only downside I see is a slight increase in the drawing time of
images with formulas that don't use these variables.

I'll also look at accessing the internal iteration count through a
variable. My own preference would be to call the variable something other
than "iter", since that is so commonly used in current formulas (although
the solution you suggested will work). Since we have "maxiter" already,
maybe something like "iternow", "icount" or "thisiter" (I like the way the
last one sounds, but not the way it looks in print). Anyone else with
thoughts on this?

George Martin

-
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"


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

From: Rich Thomson <[e-mail]>
Subject: Re: (fractdev) fractint list postings
Date: 29 Jan 1998 11:55:37 -0700


In article <[e-mail]> ,
    George Martin <[e-mail]>  writes:
> >quadsq - "quad" square, returns 0-3 for PTC fractals
>
> whitesq is (row + col) % 2
> trisq can be (row + col) % 3
>
> but the pattern for the 4 layer PTCs is
>
>           0 1 2 3 0 1 . .
>           2 3 0 1 2 3 . .
>           0 1 2 3 0 1 . .
>           2 3 0 1 2 3 . .
>           . . . . . . . .

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?  Then combining two fractals as a
PTC is a simple combination of the component fractals, instead of
writing all these whitesq formulas (with bugs and edits and debugging
of the formula) just to fake fractint into doing some remedial image
processing?

But, since we already have whitesq, regarding your comment about the
value of whitesq/trisq/etc. being computed even if not used -- my
question is why doesn't the optimizer detect unused variables and not
bother computing them?

> I'll also look at accessing the internal iteration count through a
> variable. My own preference would be to call the variable something other
> than "iter", since that is so commonly used in current formulas (although
> the solution you suggested will work). Since we have "maxiter" already,
> maybe something like "iternow", "icount" or "thisiter" (I like the way the
> last one sounds, but not the way it looks in print). Anyone else with
> thoughts on this?

Of the ones you listed, I like "thisiter" best, although naturally I
prefer my own solution as it is compatable with old formulas, and has
the intuitive name.
--
                                               Rich Thomson
                                               [e-mail]

-
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"


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

From: Rich Thomson <[e-mail]>
Subject: (fractdev) TODO list, as promised
Date: 29 Jan 1998 11:59:26 -0700

------- =_aaaaaaaaaa0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <13043.886100338.1@woody>

Here is my initial attempt at a TODO list to be incorporated into
the fractint source distribution so as to track existing ideas and
serve as a springboard for directing new eager developers into a
direction we've already discussed as the kind of things that "make
sense" in fractint.  (For instance, we've talked about fractal
music and sound options on fractint and fractal-art and generally
concluded that this kind of thing is a little far afield for
fractint; not to mean that if someone added such a thing it would
be rejected, but just that it doesn't seem to fit naturally within
fractint's framework.)

Please reply to me directly -- and not to the list -- if you have
something to add to the TODO list, so that I can keep things
straight.
--
                        Rich Thomson
                        [e-mail]

------- =_aaaaaaaaaa0
Content-Type: text/plain; name="todo.txt"; charset="us-ascii"
Content-ID: <13043.886100338.2@woody>

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.

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

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

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.
- 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: 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
- Use Xt for interface components of "fractint GUI API"
- 3D drivers: OpenGL, PEX, native X

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.

------- =_aaaaaaaaaa0--

-
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"


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

From: "Damien M. Jones" <[e-mail]>
Subject: Re: (fractdev) fractint list postings
Date: 29 Jan 1998 13:01:15 -0600

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


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

From: Rich Thomson <[e-mail]>
Subject: Re: (fractdev) fractint list postings
Date: 29 Jan 1998 12:21:27 -0700


In article <[e-mail]> ,
    "Damien M. Jones" <[e-mail]>  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
                                               [e-mail]

-
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"


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

From: George Martin <[e-mail]>
Subject: Re: (fractdev) fractint list postings
Date: 29 Jan 1998 14:45:10 -0500

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


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

From: [e-mail]
Subject: Re: (fractdev) fractint list postings
Date: 29 Jan 1998 14:30:58 EST

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


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

From: "Damien M. Jones" <[e-mail]>
Subject: Re: (fractdev) fractint list postings
Date: 29 Jan 1998 13:59:30 -0600

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


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

From: Rich Thomson <[e-mail]>
Subject: (fractdev) progress.txt
Date: 30 Jan 1998 11:17:50 -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)
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 <[e-mail]>
RBu     Robin Bussell <[e-mail]>
GM      George Martin <[e-mail]>
JO      Jonathan Osuch ?
RT      Rich Thomson <[e-mail]>
TW      Tim Wegner <[e-mail]>

-
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"


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

From: Rich Thomson <[e-mail]>
Subject: (fractdev) Re: progress.txt
Date: 30 Jan 1998 11:18:57 -0700

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

-
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"


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

From: "Jay Hill"<[e-mail]>
Subject: (fractdev) Another wish list for fractint
Date: 30 Jan 1998 10:49:16 -0800


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


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

From: George Martin <[e-mail]>
Subject: (fractdev) Re: progress.txt
Date: 30 Jan 1998 14:48:56 -0500

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


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

From: Rich Thomson <[e-mail]>
Subject: Re: (fractdev) Re: progress.txt
Date: 30 Jan 1998 13:16:51 -0700


In article <[e-mail]> ,
    George Martin <[e-mail]>  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
                                               [e-mail]

-
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"


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

From: "Damien M. Jones" <[e-mail]>
Subject: Re: (fractdev) progress.txt
Date: 30 Jan 1998 15:45:56 -0600

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


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

From: "Damien M. Jones" <[e-mail]>
Subject: Re: (fractdev) progress.txt
Date: 30 Jan 1998 15:45:56 -0600

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


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

From: Rich Thomson <[e-mail]>
Subject: Re: (fractdev) progress.txt
Date: 30 Jan 1998 16:25:11 -0700


In article <[e-mail]> ,
    "Damien M. Jones" <[e-mail]>  writes:
> Please add "M-set Pentium Optimization" to the list.

Done.  Thanks for reminding me, I forgot about that one.
--
                                               Rich Thomson
                                               [e-mail]

-
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"


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

From: "Tim Wegner" <[e-mail]>
Subject: Re: (fractdev) progress.txt
Date: 30 Jan 1998 21:26:34 -0600

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


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

From: "Tim Wegner" <[e-mail]>
Subject: Re: (fractdev) Re: progress.txt
Date: 30 Jan 1998 21:26:34 -0600

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


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

From: "Tim Wegner" <[e-mail]>
Subject: (fractdev) Welcome to Jonathan
Date: 31 Jan 1998 08:37:12 -0600

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

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


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

From: George Martin <[e-mail]>
Subject: (fractdev) Welcome to Jonathan
Date: 31 Jan 1998 12:24:08 -0500

Rich,

>list of platforms

George Martin - Borland 3.1

George

-
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"


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

From: [e-mail]
Subject: Re: (fractdev) Welcome to Jonathan
Date: 31 Jan 1998 13:43:41 EST

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 <g>.

Ron Barnett

-
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"


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

From: "Tim Wegner" <[e-mail]>
Subject: (fractdev) Synching Up
Date: 31 Jan 1998 22:45:28 -0600

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