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

Internet Message Format | 1998-02-27 | 48KB

From: Rich Thomson <[e-mail]>
Subject: Re: (fractdev) progress.txt
Date: 02 Feb 1998 10:27:44 -0700


In article <[e-mail]> ,
    "Tim Wegner" <[e-mail]>  writes:
> > SIMPLGIF encoder fix                    TW (done)
>
> This should be
>
> > Fractint encoder fix                    TW (done)

Fixed.

> I owe several people sources for the fractint developer version and
> simplgif. I'll put something together, hopefully this weekend. We
> need a way to exchange patches. While posting attachments is a non-no
> on the fractint list, perhaps posting context diffs as zipped-up
> attachements would be OK here. (The zipping protects against
> inevitable mailer mashing of diff files.) I can also post things at
> my ftp site (ftp://ftp.phoenix.net/pub/USERS/twegner). Maybe my ftp
> site is the best bet.

Please DON'T zip the diffs.  There is no problem with "mailer mashing
of diff files".  I don't know where you got this idea.  I have
transmitted diff files by email for 10+ years and never, ever, ever,
had a problem.  ZIPing text files only causes more problems in getting
the text files portably to another system because you zip your DOS
text file and when I get it to unix, then I have to strip line feeds
or vice-versa.  If the file is transmitted as a text file, then we
won't have to deal with that.
--
                                               Rich Thomson
                                               [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) Re: progress.txt
Date: 02 Feb 1998 10:28:50 -0700


In article <[e-mail]> ,
    "Tim Wegner" <[e-mail]>  writes:
> For example, adding the assembler optimizations to the parser C
> language code is probably a separable project.

These are the items I had in the "to do" list; which of these are you
working on currently, George?

    Formula Parser
    --------------
    - Add type information for expressions and variables
    - Add remainder (modulus) operator/function
    - Make C versions of corresponding assembly functions more efficient
      (reduce function call overhead, apply optimizations)
      - Provide a way to perform user-defined computations once per-image
      - Provide a way to define and call named user functions like regular
       functions
--
                                               Rich Thomson
                                               [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) Welcome to Jonathan
Date: 02 Feb 1998 10:47:23 -0700


Would someone email me Jonathan Osuch's email address for the
developer's list?  Thanks.
--
                                               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) Re: progress.txt
Date: 02 Feb 1998 11:33:22 -0700


In article <[e-mail]> ,
    George Martin <[e-mail]>  writes:
> type info - I need more information about what is wanted here, and why.
>         This is not a high priority item for me right now, and should
>             probably wait until other projects are done.

What is wanted: something similar to the C cast operator for
expressions and typing of variables for declarations.  We already
have the ability to take the integer portion of a value by doing
int(x) (what is the meaning of int(z), with z complex?).  If one could
type variables as integer or real:

    int iter,
    real x,

then the parser could know that it didn't need to do complex
arithmetic on these quantities.  Further, for "iter" it could use
integer math.  Its a small quest for additional efficiency that
motivates the proposal.

> modulus function - We can do this, but what *is* the modulus of one complex
>
>             number divided by another?

Good point!

> Once-per-image section - Not working on now. Could you give some examples
>               of what is wanted here? I've already started tinkering with
>               trisq and quadsq.

I didn't propose this, but I seem to recall the discussion going
something like this.  People have user-defined functions and they want
to do some computationally expensive setup calculations.  However,
these calculations need only be done once for the entire image
(computing critical points of the iterated function, for instance).
Currently, they have to recompute the critical points for every pixel.
Again, efficiency seems to be the motivation for this proposal, but I
don't know that anyone put together anything specific on a proposed
syntax.

I will add your updated info to the appropriate files! :)
--
                                               Rich Thomson
                                               [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) Re: progress.txt
Date: 02 Feb 1998 11:56:20 -0700


In article <[e-mail]> ,
    George Martin <[e-mail]>  writes:
> modulus function - We can do this, but what *is* the modulus of one complex
>             number divided by another?

I looked into a reference on complex numbers and it didn't seem to
define the remainder of a complex number anywhere.  Division is
defined, but its unclear how to compute the remainder of a complex
division.  It might be handy to define z modulus w as:

    z = a + b i
    w = c + d i
    z % w = (a % c) + (b % d) i

This would make implementing whitesq, trisq, quadsq, etc. trivial in
the per-pixel initialization.  However, I'm not sure that's the way we
want to define complex modulus in general.  Then again, maybe it is if
that's the real reason we want complex modulus :)
--
                                               Rich Thomson
                                               [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) Welcome to Jonathan
Date: 02 Feb 1998 10:31:24 -0700


In article <[e-mail]> ,
    "Tim Wegner" <[e-mail]>  writes:
> Rich, maybe we should add a list of platforms to the developer info
> table. Mine are Win95, Linux, and DOS. My compilers are MSC 7.0 and
> MASM 6.1, dgjpp, and gcc (Linux).

I'm not sure why this would be of help to other people?
--
                                               Rich Thomson
                                               [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) modulus function and image precalc
Date: 02 Feb 1998 11:16:38 -0800


George wrote


>modulus function - We can do this, but what *is* the modulus of one
>          complex  number divided by another?


I asked for this functionality. The trunc() function almost does it all.
And its use is for reals and also for integers. Reals for working with
angles, for example. And integers for working with the iter or some
color data.

The format might be like the C++ functions.


As for the precalc (the once per image), will we have access to the
image center/mag/rot data so we can make some kind of pre-scan
to help set up the parameters? I'm thinking of several applications -
1) a coloring scheme (someone in the UNIX world used it) checked a
few hundred scattered spots on his 1280x1024 image and scaled the
color map based on these samples. He always had a nice flow
of colors from the edge to the densest parts.
2) special parameters can be computed for any 'inside' components
found. It there is array capability, an array of special parameters can
be made which helps 'instant' filling of these components and/or
special coloring schemes for the insides of these components.
I'm experimenting with a few of these now.

Is there a function that tells us the pixel spacing.? If c=pixel and
pixel moves up one or right one, what is the change in c?


Jay



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


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

From: "Damien M. Jones" <[e-mail]>
Subject: (fractdev) Notion: coloring formulae
Date: 02 Feb 1998 14:22:24 -0600

I've been thinking about using the formula parser to define coloring
algorithms.  Obviously, I already have one way to do it--but this requires
editing the formula every time a new core fractal equation is to be used.
So I was thinking about ways to generalize the technique, that are actually
somewhat easy to bolt on to FractInt. :)

How's this idea sound?  Allow a second formula--a coloring formula--to be
written.  This formula has its own p1, p2, p3, fn1, and fn2; it has access
to z from the main "formula", as well as the other built-in variable types
of the formula parser.  Like a "normal" formula, it has an init section, a
per-iteration section, and a keep-iterating section (so the coloring
formula can force a bailout as well as the fractal formula).  Essentially,
it re-uses almost all of the existing formula parser.

Ah, well, it was just a thought.  I'd rather see looping abilities added to
the formula parser, which will let me play around with a few other coloring
techniques which right now aren't too practical. :)

Damien M. Jones   \\
[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: George Martin <[e-mail]>
Subject: Re: (fractdev) Re: progress.txt
Date: 02 Feb 1998 17:21:51 -0500

Rich,

>
 We already have the ability to take the integer portion of a value by
doing int(x)
<

The function is "trunc()", which lops of the fractional part of both the
real and imaginary components of a complex number.

George

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


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

From: Rich Thomson <[e-mail]>
Subject: Re: (fractdev) Notion: coloring formulae
Date: 02 Feb 1998 15:49:56 -0700

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

In article <[e-mail]> ,
    "Damien M. Jones" <[e-mail]>  writes:
> I've been thinking about using the formula parser to define coloring
> algorithms.  Obviously, I already have one way to do it--but this requires
> editing the formula every time a new core fractal equation is to be used.
> So I was thinking about ways to generalize the technique, that are actually
> somewhat easy to bolt on to FractInt. :)

Damien, does the attached message look familiar? :)
--
                                               Rich Thomson
                                               [e-mail]

------- =_aaaaaaaaaa0
MIME-Version: 1.0
Content-Type: message/rfc822

Delivery-Date: Mon, 19 Jan 1998 11:54:14 -0700
Received: from dbank (dbank.ptc.com [199.6.17.9]) by woody (950413.SGI.8.6.12/950213.SGI.AUTOCF) via SMTP id LAA01209 for <rthomson@woody>; Mon, 19 Jan 1998 11:54:14 -0700
Received: from poster (poster.ptc.com) by dbank (5.x/SMI-SVR4)
    id AA08348; Mon, 19 Jan 1998 11:54:11 -0700
Received: from lists.xmission.com by poster (5.x/SMI-SVR4-NN)
    id AA18912; Mon, 19 Jan 1998 13:53:17 -0500
Received: from domo by lists.xmission.com with local (Exim 1.73 #4)
    id 0xuMKj-0002Uk-00; Mon, 19 Jan 1998 11:54:05 -0700
Message-Id: <199801191852.LAA01190@woody>
Organization: Design Software Group, Parametric Technology Corporation
Sender: [e-mail]
Precedence: bulk
Reply-To: [e-mail]

In anticipation of 24-bit (and 32-bit) rendering modes in fractint,
I've been wondering if there isn't a way to unify all the various
coloring tricks embedded in FRMs as well as fractint's internal
coloring algorithms.  Here is what I have been thinking... if we
define a coloring "formula" and apply it to the iteration.  Here is
the proposed anatomy of a coloring formula:

    name {
    initialization :
    per-iteration
    finalization
    }

name        The name of this coloring method

initialization    Similar to the initialization section for a formula;
        "pixel" and other magic variables are initialized so
        they can be used by the coloring formula.  The
        coloring formula can introduce its own variables and
        initialize them here.

per-iteration    For coloring methods where the variables must be
        updated every iteration, change that information in
        this section

finalization    After the orbit has finished (because it bailed out,
        or reached maxiter, or hit a period cycle, etc.), this
        section assigns the pixel's color value

Here are some examples of the builtin coloring methods fractint has:

    iter {
    index = 0 :
    index++,
    color=colormap[index]
    }

    epsilon_cross {
    axis = 0, index = 0 :
    if (!axis && (imag(z) < .01)) then
       axis = 1
    else if (!axis && (real(z) < .01)) then
       axis = 2
    endif
    index++,
    if (axis == 1) then
       color = green
    else if (axis == 2) then
       color = yellow
    else
       color = colormap[index]
    endif
    }

In the epsilon_cross case, you might want to be able to have a way to
terminate the orbit early when you detect it nearing the axis.  A new
syntax could be introduced to allow the coloring scheme to affect
the bailout, or there could be a statement that aborted the iteration
because of the coloring test.

I think this kind of scheme encompasses all the existing coloring
modes of fractint and also covers the kinds of balls/stalks/etc. types
of colorings that others have embedded into their formulas.  The nice
thing about this kind of approach is that it separates the formulas
from the coloring.  Want a fancy colored M-set?  No need to avoid the
builtin type=mandel then, just specify the fancy coloring.

What do others think of this idea?  Are there coloring schemes that
DON'T fit into this framework?  I'd like to get something that is as
general as possible before doing any work on writing fractint code to
support it.
--
  ``Between stimulus and response is the will to choose.''  -- Steven Covey
 =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
     3D Paint: The Power to Create in 3D;        Rich Thomson
     email me for more info                [e-mail]

-
Thanks for using Fractint, The Fractals and Fractint Discussion List
Post Message:   [e-mail]
Get Commands:   [e-mail] "help"
Administrator:  [e-mail]
Unsubscribe:    [e-mail] "unsubscribe fractint"

------- =_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: Rich Thomson <[e-mail]>
Subject: Re: (fractdev) Re: progress.txt
Date: 02 Feb 1998 15:50:26 -0700


In article <[e-mail]> ,
    George Martin <[e-mail]>  writes:
> The function is "trunc()", which lops of the fractional part of both the
> real and imaginary components of a complex number.

Oops, you're right. Sorry :)
--
                                               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) modulus function and image precalc
Date: 02 Feb 1998 16:07:34 -0700


In article <[e-mail]> ,
    "Jay Hill"<[e-mail]>  writes:
> As for the precalc (the once per image), will we have access to the
> image center/mag/rot data so we can make some kind of pre-scan
> to help set up the parameters? I'm thinking of several applications -
> 1) a coloring scheme (someone in the UNIX world used it) checked a
> few hundred scattered spots on his 1280x1024 image and scaled the
> color map based on these samples. He always had a nice flow
> of colors from the edge to the densest parts.

Hey, generalize this a little more and its a great way to exploit the
formula parser -- algorithmic colormap generation.  Ideally you'd like
a way to invoke the per-pixel function rather than duplicating the
function body so that the algorithmic colormap can be used with many
different fractal types and formulas.

> Is there a function that tells us the pixel spacing.? If c=pixel and
> pixel moves up one or right one, what is the change in c?

You know what, I thought that was available, but not according to the
documentation...looks like there might be other stuff that should be
available in the environment as well.
--
                                               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) modulus function and image precalc
Date: 02 Feb 1998 17:21:31 -0600

Rich,

 - > Is there a function that tells us the pixel spacing.? If c=pixel and
 - > pixel moves up one or right one, what is the change in c?
 -
 - You know what, I thought that was available, but not according to the
 - documentation...looks like there might be other stuff that should be
 - available in the environment as well.

Hmm, the problem is, pixel doesn't always map linearly--if inversion is
turned on, mainly.  So I don't think you want to write a formula which
relies on pixel proximity.

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) Notion: coloring formulae
Date: 02 Feb 1998 17:19:54 -0600

Rich,

 - Damien, does the attached message look familiar? :)

Whoa, totally trippy man.  Like, deja vu all over again.  I'm gonna take a
nap, I'm feeling too weird to stay awake.

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) Notion: coloring formulae
Date: 02 Feb 1998 16:41:19 -0700


In article <[e-mail]> ,
    "Damien M. Jones" <[e-mail]>  writes:
> Whoa, totally trippy man.  Like, deja vu all over again.  I'm gonna take a
> nap, I'm feeling too weird to stay awake.

I wondered why noone commented at all on that message when I sent it
to fractint.  There was a deafening silence in response :).  Then
again, with so many messages, I shouldn't be surprised it got lost in
the noise.  However, you did add one extra thing that I didn't include
in my proposal which is adding the color-iteration bailout condition.
For most standard colorings, this is just 1 (exception: epsilon-cross,
etc., methods).
--
                                               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: Re: (fractdev) modulus function and image precalc
Date: 02 Feb 1998 16:05:43 -0800


Damien M. Jones wrote
>Rich,
> - > Is there a function that tells us the pixel spacing.? If c=pixel and
> - > pixel moves up one or right one, what is the change in c?
 -
> - You know what, I thought that was available, but not according to the
> - documentation...looks like there might be other stuff that should be
> - available in the environment as well.
> Hmm, the problem is, pixel doesn't always map linearly--if inversion is
> turned on, mainly.  So I don't think you want to write a formula which
> relies on pixel proximity.
Good point. But I have at least on coloring formula where I need at
least an estimate of the rapidity of iteration count change with image
position. So to first order these can be computed with calculus, even
in non-linear space. I can compute everything right up to the image
scaling with Fractint.

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: "Tim Wegner" <[e-mail]>
Subject: Re: (fractdev) progress.txt
Date: 02 Feb 1998 18:19:03 -0600

Rich wrote:

> Please DON'T zip the diffs.  There is no problem with "mailer mashing
> of diff files".  I don't know where you got this idea.  I have
> transmitted diff files by email for 10+ years and never, ever, ever,
> had a problem.

Ahh - OK, but when you say there is no problem, you are saying there is no
problem for you. There are a zillion mailing programs in the world and many of
them wrap lines. But I am willing to try. I personally like getting diffs
zipped because then I know I am receiving things exactly. Fractint developers
have been exchanging zipped up context diffs for the same 10 years you have
been having no problems via mail <grin!> Rich, I am not saying you are wrong,
just be aware that there is no accounting for taste or habit.

Another reason for not posting diffs to the list is that diffs can get very
big. Yet another is that we Stone Soupers usually distribute object code for
changed assembler files so that developers don't need to own MASM. This off
course doesn't apply to Unix.

Whatever works is OK by me.

> ZIPing text files only causes more problems in getting
> the text files portably to another system because you zip your DOS
> text file and when I get it to unix, then I have to strip line feeds
> or vice-versa.  If the file is transmitted as a text file, then we
> won't have to deal with that.

The SIMPLE solution for this is to use the free unzip with the -a option. This
converts text files to the local line end convention. It's a real life saver. I
even zip of files going between DOS and Linux on my own PC precisely because it
solves the CR/LF problem.

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) Welcome to Jonathan
Date: 02 Feb 1998 18:19:03 -0600

Rich asked:

> I'm not sure why this would be of help to other people?

If you have platform specific problems, you know who to ask. But if you don't
want to capture the information, it's OK with me. With time we'll learn who has
what.

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) Notion: coloring formulae
Date: 02 Feb 1998 18:19:03 -0600



> I've been thinking about using the formula parser to define coloring
> algorithms.

I think this is a terrific idea, and I don't think it would be too
hard. Not trivial, but it could re-use parser code.

Rich claims to have thought of this before, and so do I <grin!>

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) progress.txt
Date: 02 Feb 1998 17:53:32 -0700


In article <[e-mail]> ,
    "Tim Wegner" <[e-mail]>  writes:
> Rich, I am not saying you are wrong,
> just be aware that there is no accounting for taste or habit.

Well there is taste/habit, and then there is broken software.

Broken software should not be excused or tolerated; it should be fixed
or replaced.  If I "owned" fractint, I would say "hey, all you people
with broken MIME mailers, get your software fixed", but I don't, so I
can't and we have 500 message threads about "3D disease".
--
                                               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) Welcome to Jonathan
Date: 02 Feb 1998 17:54:35 -0700


In article <[e-mail]> ,
    "Tim Wegner" <[e-mail]>  writes:
> If you have platform specific problems, you know who to ask.

OK, I've added this stuff to the "progress.txt" file.
--
                                               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) Notion: coloring formulae
Date: 02 Feb 1998 17:55:14 -0700


In article <[e-mail]> ,
    "Tim Wegner" <[e-mail]>  writes:
> Rich claims to have thought of this before, and so do I <grin!>

I don't claim to be the first to think of it (most good ideas have
already been thought of before), but considering my post to fractint
on the exact same subject, it was funny :)
--
                                               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: Jonathan Osuch <[e-mail]>
Subject: Re: (fractdev) Welcome to Jonathan
Date: 02 Feb 1998 21:29:05 -0500

>> Would someone email me Jonathan Osuch's email address for the
developer's list?  Thanks. <<

Rich,

[e-mail]

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"


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

From: "Tim Wegner" <[e-mail]>
Subject: (fractdev) Developer's Version 1961p28
Date: 02 Feb 1998 22:24:51 -0600

I have uploaded both the Xfractint and Fractint sources. They are
accessible via ftp as:

ftp://ftp.phoenix.net/pub/USERS/twegner/1961p28.zip
ftp://ftp.phoenix.net/pub/USERS/twegner/x1961p28.zip

I cheated slightly - realdos.c in Xfractint is slightly later than
the Fractint version. (The change does not affect fractint).

Let me know if you have any problems.

Rich, I had to re-comment one of the defines in port.h that you had
uncommented in order to get arbitrary precision to work.

The files soi1.c and soi.c are not permanent. To try SOI, uses
passes=s. I intend to integrate the code better with fractint, and
also make an arbitrary precision version.

The fractint source does not have assembler object code. If anyone
needs it, let me know.

See what's new for all the changes. There's a lot!

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: [e-mail]
Subject: Re: (fractdev) Developer's Version 1961p28
Date: 03 Feb 1998 09:28:28 EST

In a message dated 98-02-02 23:30:12 EST, you write:

<< The fractint source does not have assembler object code. If anyone
 needs it, let me know.

 See what's new for all the changes. There's a lot!

 Tim
  >>

Tim,
Is MASM 6.0 satisfactory?
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: George Martin <[e-mail]>
Subject: (fractdev) image precalc
Date: 03 Feb 1998 10:33:11 -0500

Tim,

>precalc (the once per image)

There have been suggestions for a pre-initialization section in formulas
which only calculates once per image rather than at the beginning of each
pixel.

It seems to me this result is already easily accomplished in a formula with
the following:

IF (scrnpix==0 && imag(scrnpix)==0)
  all the once per image stuff
ENDIF

Is there any situation (viewwindows, solid guessing, e.g.) where the
beginning coordinates are not both 0 on the first pixel, and never
thereafter?

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: "Damien M. Jones" <[e-mail]>
Subject: Re: (fractdev) image precalc
Date: 03 Feb 1998 10:40:19 -0600

George,

 - Is there any situation (viewwindows, solid guessing, e.g.) where the
 - beginning coordinates are not both 0 on the first pixel, and never
 - thereafter?

Resuming calculation of an interrupted, saved, and restored image.

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) image precalc
Date: 03 Feb 1998 10:12:16 -0700


In article <[e-mail]> ,
    George Martin <[e-mail]>  writes:
> Is there any situation (viewwindows, solid guessing, e.g.) where the
> beginning coordinates are not both 0 on the first pixel, and never
> thereafter?

Does scrnpix start at zero with a view window?
--
                                               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) Developer's Version 1961p28
Date: 03 Feb 1998 20:31:00 -0600


> Tim,
> Is MASM 6.0 satisfactory?

I vaguely remeber some bugs, but I suggest you try. I'd be happy to
upload the object code if you need it.

Thanks for hanging in there. I really do want to work with you on
truecolor. Just seems like I have too many things to do first. If I
can't put PNG in quick enough, it is very easy to save as Targa,
which we could use for truecolor.

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: [e-mail]
Subject: Re: (fractdev) Developer's Version 1961p28
Date: 06 Feb 1998 13:23:21 EST

In a message dated 98-02-03 21:32:37 EST, you write:

<<
 I vaguely remeber some bugs, but I suggest you try. I'd be happy to
 upload the object code if you need it.

 Thanks for hanging in there. I really do want to work with you on
 truecolor. Just seems like I have too many things to do first. If I
 can't put PNG in quick enough, it is very easy to save as Targa,
 which we could use for truecolor.

 Tim
  >>

No problem!

My time has been at a real premium lately. My company is doing a spin off,
followed by a major downsizing. Right now I am just trying to keep my head
above water.
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: "Tim Wegner" <[e-mail]>
Subject: (fractdev) Simplgif source
Date: 08 Feb 1998 16:01:17 -0600

I have uploaded the simplgif source to

ftp://ftp.phoenix.net/pub/USERS/twegner/simplsrc.zip

This source SHOULD be portable, but isn't. I can compile it with MSC
large model, but not djgpp (it crashes). I'll make it portable after
I replace the decoder in pdgif.c with a new encoder. Then pdgif.c
will be gone completely. This version uses either the pdgif encoder
or the compress encoder, but always uses the pdgif decoder.

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: "Justin A. Kolodziej" <[e-mail]>
Subject: (fractdev) test
Date: 24 Feb 1998 16:31:07 -0600

This is a test-please ignore.

If you didn't, I'm checking to see if I'm subscrbed because "which"
didn't work.
--
Justin A. Kolodziej
I sense a great disturbance in the Source.
Justin Kolodziej is [e-mail]
Marquette University is www.mu.edu

-
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) simplgif
Date: 24 Feb 1998 23:50:08 -0600

I have uploaded a massively revised simplgif program to

ftp://ftp.phoenix.net/pub/USERS/twegner/simplgif.zip

Included are executables compiled with MSC (large model) and djgpp
and the C source. I haven't tried, but I would expect the source to
complile with minimal problems under Unix.

I did some editing of the encoder and decoder sources, mostly
unifying some typedefs and "ansifying" the old K&R style. However, I
felt it would be unwise to edit the reliable encoding and decoding
sources too radically. Given the variable quality of GIF sources, I
am really happy with the compress encoder and Steve Bennett's
decoder.

This version has a new decoder, basically the same one as in
Fractint.

Let me know if you have any suggestions. The buffering scheme used in
reading and writing the tempory file is the same as in the original
simplgif by Bert Tyler. This could be made more efficient. I made a
start at eliminating signed 16 bit integers in favor of unisgned, so
that simplgif would work with 64K rows. I doubt this is complete, so
most likely the limit is 32K.

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: Mac Port of FracInt?
Date: 27 Feb 1998 10:41:18 -0700


I'm replying to fractdev...

In article <l0313031bb11bb0fbb729@DialupEudora> ,
    DeRobertis <[e-mail]>  writes:
> How much of a speed gain would putting critical sections in assembly gain?
> I could learn PPCAsm, if nessisary.

It would probably be significant, especially for formula type
fractals.  The C formula parser isn't very optimized.  Formulas run
pretty darn slow on my SGI which is no slouch at FPU computations
compared to your typical Pentium/PPC.

> Is this the way it is in XWindows? Hmmm....maybe I'd better get down to
> reading the megs of sources as soon as I finish fixing the other Mac.

X uses an event model very similar to the Mac.  If you examine the
'trick' that the xfractint code uses to handle events, you should be
able to adapt that to the Mac event loop.

> Anyway, it might be possible to write some quick things to get it running
> on the Mac soon. However, it may take time to do a complete Macinization of
> it.

We (fractdev list members) have talked about separating the UI portion
of fractint from the computation engine part.  Abstracting away the UI
would make your Mac port MUCH, MUCH easier if you wanted to get a
"full, Mac-like" interface on everything.  However, you can adopt a
combination of winfract and xfractint techniques to get a
fully-functioning fractint port on the Mac, it would just have
fractint's keyboard interface on it and not the typical Mac menus,
etc.  If you are really gun-ho about making a complete Mac "look and
feel" to fractint, then let's coordinate on defining the UI functions
and separating out the computation from the UI.  Then we can fold that
work back into the fractint source base, making the move to a Win32
programming model even easier for whoever takes on that task.

> PS: How much of this will need to be re-written to work under a 32-bit
> environment?

If you use the xfractint source code, you should be able to get it all
to compile cleanly.  The xfractint version uses C code for everything
(most of the 16-bitness is embedded in the assembly code portions) and
the rest of the code that has 16-bitness aroma to it is bracketed with
#ifdef XFRACT directives.  When compiling for xfractint/unix, XFRACT
is defined, so that will probably be the version that you will want to
use in your Mac port.

> PS(2): What are the sizes of int's, long's, float's, and double's over
> there? Where is it important that I preserve these?

Note sure about that; perhaps Tim can offer a suggestion?

One thing I'd like to suggest before you start modifying code is that
you set yourself up with a source code revision system on your Mac.  I
am not sure what's available for the Mac, but I've had good experience
with RCS and CVS.  CVS is better, it builds on top of the foundation
provided by RCS.  However, you can do source file management with RCS
itself.  The reason I suggest this is that it makes it much easier to
share code changes since you can use the 'diff' and 'patch' tools to
generate deltas between source files from one developer's tree, use
email to communicate the delta and then another developer can use
patch to incorporate your delta into their source tree.  Works really
great.
--
                                               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) Re: (fractint) Mac Port of FracInt?
Date: 27 Feb 1998 10:45:01 -0700


I'm replying to fractdev...

In article <l0313031ab11bb02b862c@DialupEudora> ,
    DeRobertis <[e-mail]>  writes:
> Speedwise, how much of a gain will I get with the asm code over a
> good-optimizing compiler?

I wouldn't worry about speed just yet :).
"First make it right, then make it tight."
--
                                               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) Re: Mac Port of FracInt?
Date: 27 Feb 1998 19:44:17 -0600


> PS(2): What are the sizes of int's, long's, float's, and double's over
> there? Where is it important that I preserve these?

The important things to preserve are

short = 16 bits
long = 32 bits

These are *usually* the same on different platforms. The main place
where size is important is when writing fractal data to the GIF file.
We'll get rid of this before too long. Unfortunately, we wrote binary
representations of doubles to files. Ken Shirriff wrote some code
that unmangles these so they make sense under UNIX.

We'll get out from under writing binary data to files soon, and this
will cease to be a problem.

Arbitrary precision will use a long double if it is available.

Rich wrote:

> One thing I'd like to suggest before you start modifying code is that
> you set yourself up with a source code revision system on your Mac.

It is sufficient to have the diff and patch programs. We distribute
patches in the form of diffs made with diff -c. However, if diff is
not available on the Mac, we can work out something.

I know the developer who does the POV-Ray Mac ports. We introduced
diff and patch to the POV-Ray team and it is now their standard
medium for exchanging changes. I can ask their Mac guy how he handles
the context diffs.

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"