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

Internet Message Format | 1997-08-30 | 157KB

From: "Tim Wegner" <[e-mail]>
Subject: (fractdev) Hello!
Date: 09 Aug 1997 19:03:56 -0600

I see that Lee and Sylvie have arrived. Welcome?

How does it look?

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: Lee Skinner <[e-mail]>
Subject: (fractdev) Hello!
Date: 09 Aug 1997 21:54:29 -0400

Tim,

>>I see that Lee and Sylvie have arrived. Welcome?

How does it look?<<

You said that you wanted a critique of the welcome message when it arrive=
d.
The above two lines from you are the only sort of any welcome message tha=
t
I have received.

Lee

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: Sylvie Gallet <[e-mail]>
Subject: (fractdev) Hello!
Date: 10 Aug 1997 03:29:32 -0400

Hi Tim,

>> I see that Lee and Sylvie have arrived. Welcome?

>> How does it look?

  It looks OK, with one of your favorite typos <g>:

>> You can contact the the fractdev list administrator, Tim =

                   ^^^
  Cheers,

        -  Sylvie

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 Dorothy
Date: 10 Aug 1997 09:58:44 -0600

I see Dorothy Gibbs just joined the two lists. Dorothy, did you get a
welcome message saying you had subscribed and including the list
charter? The message wouldn't have been a message like this, but one
from [e-mail].

The other folks should have also received such a welcome, except one
of the messages was defective. From my compuserve account I
"unjoined" (majordomo won't let me use the right words for this!!)
then "joined" again, and I got the revised welcome messages OK. You
can also get part of the welcome message (the charter part) by
sending

info fractint

or

info fracdev

in a message body (followed by CR) to [e-mail]

(BTW this message bounced because it had the "join" and "unjoin"
commands in it! Since I am resending this, I already know Sylvie is
on the list, but I'll leave the original question below in this
message.)

Sylvie, did you attempt to sign up for the fractint list? I have you
down for only fractdev. The reason I ask is that as soon as I have a
bit more verification that things are working, I'm going to go
public. All the activity will be in fractint. We can use fractdev
temporarily to discuss how things are going with the lists, and
reserve fractint for the actual public discussion. The activity here
in fractdev (besides housekeeping) depends on some internet based
developers coming on board.

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) When to go public
Date: 10 Aug 1997 16:01:49 -0600

I think we're ready to go public, but I want to hear from Rich
Thomson first. The complication is I will be away four days starting
Sunday a week from today. I don't know if one dares to leave a
mailing list unadministered that long :-) It might be prudent to wait
until I come back before we go public. I'll get Rich's opinion.

Is there anyone interested in volunteering to learn the ropes for
this responsibility? It might be for the future rather than for now.
There are only a few commands to learn, and you handle it entirely by
email. What happens is only that bounced mail do to bad addresses and
mis-directed subscribe/unsubscribe commands would come to your email
address.

Having spent an afternoon learning this, I think it's a useful skill
to know how to administer a majordomo list. (I'm not sure
"administer" is the right word, I'm talking about being the owner of
a particular list, not the adminstrator of a whol majordomo software
installation with many lists.)

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: Sylvie Gallet <[e-mail]>
Subject: (fractdev) When to go public
Date: 10 Aug 1997 17:32:42 -0400

Tim,

>> Is there anyone interested in volunteering to learn the ropes for =

>> this responsibility? It might be for the future rather than for now. =


  I am interested and I am still on vacation.

        -  Sylvie

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) When to go public
Date: 10 Aug 1997 18:48:37 -0600

Sylvie said:

>   I am interested and I am still on vacation.

I asked Jon Noring about this, and he said that being away several
days is no big deal. However, have a look at

http://docuspace.uchicago.edu/g_maj-adm.html

which is a great summary about what owning a list is all about. From
what Jon says it is sufficient for a few folks on the list to know
I'm not around. It may be in the future we'll want to share this
responsibility, or take turns.

Right now I favor going public after I hear from Rich, probably
Monday.

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) When to go public
Date: 10 Aug 1997 18:53:28 -0600

Welcome to Les and George!

There's not much here yet. I'm thinking of going public with
the fractint list Monday. For the time being we can use fracdev for
discussing list management mechanics and keep it non-public.

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: Dorothy Gibbs <[e-mail]>
Subject: Re: (fractdev) Welcome Dorothy
Date: 11 Aug 1997 11:23:55 +0100

In message <[e-mail]>, Tim Wegner
<[e-mail]> writes
>I see Dorothy Gibbs just joined the two lists. Dorothy, did you get a
>welcome message saying you had subscribed and including the list
>charter? The message wouldn't have been a message like this, but one
>from [e-mail].
>
Yes I did thanks.
I look forward to seeing what appears on here now!

Dorothy
--
Dorothy Gibbs     :In Brookmans Park, Hertfordshire, UK
EMail             :[e-mail]
Compuserve        :100014,1155

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: Sylvie Gallet <[e-mail]>
Subject: Re: (fractdev) When to go public
Date: 11 Aug 1997 12:54:17 -0400

Tim wrote:

>> However, have a look at =

>>
>> http://docuspace.uchicago.edu/g_maj-adm.html
>>
>> which is a great summary about what owning a list is all about.

  I did it.  Interesting!

>> From what Jon says it is sufficient for a few folks on the list to kno=
w =

>> I'm not around. It may be in the future we'll want to share this =

>> responsibility, or take turns.

  I'll be glad to help.

        -  Sylvie

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) When to go public
Date: 11 Aug 1997 18:23:40 -0600

>   I'll be glad to help.

Maybe at some point you can take over one of the list owners (or
for that matter start another sublist, should that be desired.) So
far, the list owner doesn't seem hard at all. Unfortunately at the
moment I don't see a way to share the list owner job.

Everyone, I have changed the procedure for joining the list so it is
now a two step process. When you try to join, you get sent back an
authentication number, which you send back to majordomo. I tried this
from my Compuserve account, and it seems to work fine. If anyone is
curious about this, just unjoin the list and join again. (Notice I'm
avoiding using the right word instead of "join" that starts subsc*
because majordomo will bounce the message back to me if I do <g!>)

The reason for the more complex signup procedure (no, I'll say it,
"subscibe" procedure, I think it's safe this late in the message
<g!>) is to thwart mail bombers which sek out lists, subscribe, and
then broadcasr junk mail.

I'm planning to go public with the fractint list tonight. I'd
appreciate it if several of you would start some discussions
tomorrow on some favorite PARs etc. to get the list going. Don't
worry about this this, I'm only concerned about the fractint list.

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) When to go public
Date: 11 Aug 1997 19:02:39 -0600

OK, I sent an announcement about the fractint (not the fractdev) list
to fractal-art and to sci.fractals. Here goes nothing!

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) alive yet?
Date: 13 Aug 1997 12:35:17 -0600

Is this list alive yet, Tim? :)
--
  ``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) alive yet?
Date: 13 Aug 1997 18:00:09 -0600

Rich asked:

> Is this list alive yet, Tim? :)

I haven't made this list public. I'm taking off in a few days to take
my son to college, and at the moment I don't have any non-compuserve
developers knocking at the door waiting, unless you are one <g!>

I can start it at any time if there are people who need to
communicate here. Most of the compuserve developers and artists
belong to this list already, we just haven't started any conversation
here.

It's usually pretty quiet in the summer anyway.

If you have anything to discuss, go ahead <g!>

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) alive yet?
Date: 13 Aug 1997 18:18:54 -0600


In article <[e-mail]> ,
    "Tim Wegner" <[e-mail]>  writes:
> I haven't made this list public. I'm taking off in a few days to take
> my son to college, and at the moment I don't have any non-compuserve
> developers knocking at the door waiting, unless you are one <g!>

Yes, I am :)

> If you have anything to discuss, go ahead <g!>

My skill set is in computer graphics and X/unix environments.  I don't
have a PC compilation environment yet.

Here is a list of things I made earlier when thinking about fractint
and wish lists, etc.  If an item doesn't make sense or you would like
me to talk more about it, please feel free to ask :)

- better X support:
    - "video modes" for each of the available visual types
    - render into different visuals properly
    - put text screens in X-based windows (i.e. no need for xterm)
    - possibly use a widget set / integrate Motif port

- enhanced zooming:
    - interpolate / extrapolate zoomed region to init next screen

- truecolor support:
    - truecolor pixel coloring methods/formulas

- build abstract layer between UI and calculation engine
    - enhances integration of dos/windows/X versions

- support for parallelism
    - decompose image into chunks,
      scatter chunks to farm of processors,
      gather rendered chunks

- file I/O:
    - add batch parameters to GIF file as text comment
    - add JPEG support (parameters as text comment)
    - add PNG support (parameters as text comment)

- parameterized L-systems
    - a la Prusinkiewicz

- better 3D support
    - possible use of OpenGL

- specify any video mode from command line

- fractal breeder

- anti-aliasing support

- prioritized computation of chunks

- source configured with autoconf
--
  ``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) alive yet?
Date: 13 Aug 1997 21:45:18 -0600

Here are my comments on your list. I should say that my comments
aren't limiting - our openness to ideas is inversely proportional to
the amount of work we have to do to accomodate the ideas :-)

> - better X support:
>     - "video modes" for each of the available visual types
>     - render into different visuals properly
>     - put text screens in X-based windows (i.e. no need for xterm)
>     - possibly use a widget set / integrate Motif port

This would be great. Do you know anything about TK? Darryl House's
opinion was that Motif was too limiting in terms of popularity of the
platform. He agrred that TK might be a good interface to use. We
might even be able to have the same interface under X and
Windows. He did provide me a licensed version of Motif that I can run
under Linux. I know very little about it, but I was able to compile
the XMFract port.

> - enhanced zooming:
>     - interpolate / extrapolate zoomed region to init next screen

Users would love this but for me it's low priority.

> - truecolor support:
>     - truecolor pixel coloring methods/formulas

The foundations of this need to be thought through very carefully.
What are the main parameters we need (iteration, x and y of last
orbit etc.). Format to save image. Procedural algorithms vs super
palettes. Consideration for saving off the fundamental pixel
information and true-coloring as a post process.

For starters, I favor algorithms that interpolate between colors so
that users can explore and color with 256 colors. A lot of work has
been done on this. The fractal-art archives contain discussion, and
there are many code fragments. I'm interested, but so far haven't
taken the time to dive into this. Fractint already has VESA truecolor
drivers built in. High priority.

> - build abstract layer between UI and calculation engine
>     - enhances integration of dos/windows/X versions

Something along these lines is important. Portability is a high
value.

> - support for parallelism
>     - decompose image into chunks,
>       scatter chunks to farm of processors,
>       gather rendered chunks

This is low priority for me because I don't have an environment where
I can use it (or even test it.) But I know it's a priority for you
for go for it. The logic to break things up already exists in "divide
and conquor", the <b> command.

> - file I/O:
>     - add batch parameters to GIF file as text comment
>     - add JPEG support (parameters as text comment)
>     - add PNG support (parameters as text comment)

I'm only inderested in PNG support. When we do PNG we can totally
change how parameters are stored. There is no value IMHO in changing
how data is stored in GIF. Once we support PNG and we're confident of
a conversion process, we can drop GIF (though I'd be willing to let
GIF hand on a while.) I don't see the point in direct JPEG support in
Fractint. PMG can be converted to JPEG as a post-process.

I have worked hard on the PNG team to get medium model support. I
succeeded, but didn't have the time or energy to get PNG into the DOS
fractint. My reluctance is probably due to my deep fear that we'd run
into resource limitations - mostly memory. Integrating PNG into
Fractint under a 32 bit environment would be relatively easy. I have
already reserved a chunk name for fractal data. My idea is to define
PNG-like subchunks for various fractal items. However, PAR-like text
might be better.

I *should* reserve a coule of weekends to integrate PNG under DOS. I
might even succeed!

>
> - parameterized L-systems
>     - a la Prusinkiewicz

I don't know too much about this. I know there are some great
3D L-systems that work with POV-Ray.

>
> - better 3D support
>     - possible use of OpenGL

The existing 3D is truly horrible code, but after all this time it's
still pretty popular. I wrote it from first principles with no
experience or previous knowledge, and it shows. I quit when I got it
working. Today it excites me less, with one exception. The
4D quaternion and hypercomplex types fascinate me. It would be easy
to improve the julibrot depth modulation, and have some pseudo-3D
rendering. The 3D fractals have been implemented with a bit more
generality (arbitrary slicing places) in POV-Ray. I'd like to make a
direct connection between Fractint and POV-Ray so Fractint could be
an exploration toold for POV-Ray. I'd also like to connect the 2D
quaternion and hypercomplex fractals with the 4D ones so that the 2D
ones could be used to explore. (This is possible now by hand, but you
have to know what you are doing.)

At this point I don't see how OpenGL helps with Fractint's 3D because
of the nature of fractals. But I'm open to learn at the feet of an
expert <g!> This probably needs a Windows port to do on the PC end.

> - specify any video mode from command line

The DOS version does this. I agree it's a big weakness of the
Xfractint version.

> - fractal breeder

Robin's evolver is a great start toward this. I need to upgrade Linux
to the latest developer version so you can see. The latest Fractint
executable is in

ftp.phoenix.net/pub/users/twegner/tw01.zip

This isn't secret but I'm not ready to send dveloper versions out to
the public with big publicity. Anyone who sees this, please don't
upload this anywhere else, as developer versions have a short life.

Your other ideas would be welcome as well.

Be patient with us. I find the pace of my own develper contributions
has slowed a lot, but by the same token, I have learned to keep
things in balance so I can maintain my fractint participation for the
long haul. I generally do end up implementing things I talk about
wanting to do, but it can take years <g!>

The biggest issue is how to get out from under DOS. One of
the big obstacles is that we have ported all the assembler already,
but users LOVE the fast assembler. We need a Windows port (preferably
done with a portable GUI built with TK or some such) that has some of
the assembler ported, particularly the fast parser and
Mandlbrot/Julia.

Having said all this, what I should personally do next is take some
time and finish off SOI (Synchronous Orbits) and port it to arbitrary
precision. Or I could drop it and tackle PNG. Or I should buy Visual
C++. Or I should plunge into TK under Linux, which means I need a new
hard drive. You see my problem <ggg!>

George Martin pretty much focuses on the formula parser. Jonathan is
working at the moment on memory management and helping Robin with the
evolver. Nobody in this effort as any deadlines. Like me, they work
slowly as schedule permits. Wes Loewer has gone to Kenya to
teach. Bert Tyler lurks <g!>

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) alive yet?
Date: 14 Aug 1997 12:02:00 -0600


In article <[e-mail]> ,
    "Tim Wegner" <[e-mail]>  writes:
> > - better X support:
>
> This would be great. Do you know anything about TK? Darryl House's
> opinion was that Motif was too limiting in terms of popularity of the
> platform. He agrred that TK might be a good interface to use. We
> might even be able to have the same interface under X and
> Windows. He did provide me a licensed version of Motif that I can run
> under Linux. I know very little about it, but I was able to compile
> the XMFract port.

I don't know much about Tk.  When I was thinking of a widget set, I
was thinking of the 3D athena widgets, which are freely available
source code and widely available.  Fractint doesn't need very much in
the way of user interface widgets.  As for having the same interface
on Windows as X, this was what I was referring to later in my mail
about separating the UI from the calculation engine with some sort of
abstract layer.  While windowing systems like X and Win32 provide many
functions and ways of creating a user interface, fractint's needs are
really quite pedestrian.  Help screens, parameter dialogs, file
selectors, and a graphics output screen.

I do know that Tk is built on top of Tcl.  In the past, I have had a
hard time installing Tk/Tcl based applications because it requires
that so many other things be installed first in a certain way.  Maybe
it was just the way they were packaged.  I'm not a Tcl expert.  I have
been reading about how the FSF (Free Software Foundation, the gnu
folks) have rebelled against Tcl and instead are proposing an
alternative scripting tool.  Is it possible to distribute a
"standalone" Tk/Tcl-based application?  Or does it always require the
user install something else first?  For window system oriented
versions of fractint, I'd like it to be as standalone as possible.

> > - enhanced zooming:
> >     - interpolate / extrapolate zoomed region to init next screen
>
> Users would love this but for me it's low priority.

The code should be fairly easy to add, though.  Its a doubly nested
loop and some pixel I/O.

> > - truecolor support:
> >     - truecolor pixel coloring methods/formulas
>
> The foundations of this need to be thought through very carefully.

Yep :)

Here are some of my thoughts in the questions you raise:

> What are the main parameters we need (iteration, x and y of last
> orbit etc.).

That's a good start.

> Format to save image.

PNG or GIF (floyd-steinberg dither on the resulting 24-bit image to
"best" 256 colors).

> Procedural algorithms vs super
> palettes.

My thoughts were to allow both by supporting a "coloring formula".  To
get super palettes, your formula is just a colormap lookup:

    truecolor=map[iter]

> Consideration for saving off the fundamental pixel
> information and true-coloring as a post process.

Isn't this in fractint 19.6 right now?

> I favor algorithms that interpolate between colors so
> that users can explore and color with 256 colors.

Can you elaborate on what you mean here?

> A lot of work has
> been done on this. The fractal-art archives contain discussion, and
> there are many code fragments. I'm interested, but so far haven't
> taken the time to dive into this. Fractint already has VESA truecolor
> drivers built in. High priority.

I'm not familiar with those discussions; has anyone collected them
together so they could be reposted to fractdev?

> > - build abstract layer between UI and calculation engine
> >     - enhances integration of dos/windows/X versions
>
> Something along these lines is important. Portability is a high
> value.

Yes, this makes doing the "X port" much, much easier.  Also, things
are looking really interesting with the folks at Be Inc. having
announced an Intel port coming.  (See <URL: http://www.be.com>.)  The
BeOS is a totally different UI model, so having the UI separated
cleanly from the computation engine would make things easier.

> > - support for parallelism
> >     - decompose image into chunks,
> >       scatter chunks to farm of processors,
> >       gather rendered chunks
>
> This is low priority for me because I don't have an environment where
> I can use it (or even test it.) But I know it's a priority for you
> for go for it. The logic to break things up already exists in "divide
> and conquor", the <b> command.

Cool.  This might become more popular than you think!  Seeing as how
winsock is widely available on people's machines nowadays, their might
be a way to coordinate different machines over the internet to
cooperatively render fractals.  Another advantage of having the UI
cleanly separated from the calculation engine is that a network
compute node can simply have its UI replaced with a network "stub".

> > - file I/O:
>
> I'm only inderested in PNG support. [...]

> There is no value IMHO in changing how data is stored in GIF.

What I was suggesting is that we keep the application extension block
but also add a par definition style text comment as well.  (If you
extract the printable comments with a GIF utility, then you have the
par file without having to load the file into fractint.)

> I don't see the point in direct JPEG support in
> Fractint. PMG can be converted to JPEG as a post-process.

Here is why I think direct JPEG support is important in fractint's
future:

    o   PNG images, while pixel correct, tend to be much larger than
    JPEGs.  I know people always say "trade the par file", but with
    deep zooming and images that take 5 days to render on a
    Pentium II, I'd rather trade the image!  Trading JPEGs is
    easier on the modem/bandwidth than trading PNGs.

    o   PNG -> JPEG conversion gets you the image, but loses the
    parameter information that generated the image.  This is
    already a reason why people complain about using JPEG for
    trading fractint fractals.  The parameters could easily be
    embedded in the JPEG file just as easily as the GIF.

    o   When truecolor support is added, the images should exhibit
    less of the Gibbs Phenomenon that makes so many people object
    to JPEG.

    o   Choice is good :)

> I have worked hard on the PNG team to get medium model support.

What's medium model support?

> My reluctance is probably due to my deep fear that we'd run
> into resource limitations - mostly memory.

I don't have a feel for what the memory budget of fractint is right
now.  I'm still trying to understand the layout of the source code :).
I did notice that fractint is using overlays?  If someone could post a
rough memory map of DOS fractint's memory usage, that might be
helpful.

> Integrating PNG into
> Fractint under a 32 bit environment would be relatively easy.

Is it an option to include features (say, PNG & JPEG support) in some
ports but not others?  For instance, let DOS have only GIF I/O, to be
eventually replaced by PNG, but no other file formats.  Or does this
lead to an unhappy divergence among platforms?

> PNG-like subchunks for various fractal items. However, PAR-like text
> might be better.

I like PAR-like text because it can easily be extracted from whatever
file its embedded in (the unix "strings" command, for instance, can
extract printable strings from arbitrary binary data).

> > - parameterized L-systems
> >     - a la Prusinkiewicz
>
> I don't know too much about this. I know there are some great
> 3D L-systems that work with POV-Ray.

The best reference on this is "The Algorithmic Beauty of Plants", by
P. Prusinkiewicz -- and no, I'm not sure I've spelled his name right
:).  Parameterized L-systems allow you to evolve an L-system
continuously rather than as discrete polygonalized steps.  Its how
P.P. generated beautiful animations of growing plants from seedling to
mature plant to flowering stages and so on.  Great stuff.

> > - better 3D support
> >     - possible use of OpenGL
>
> The existing 3D is truly horrible code, but after all this time it's
> still pretty popular.

:)

I think this is another case where a clear interface for the 3D
features used by fractint would be a win.  There are a wide variety of
3D rendering devices/APIs available.  If fractint can clearly define a
base set of operations that it uses in its 3D rendering, then we should
be able to have fractint rendering its 3D output in a variety of
ways.  I would even think that 3D file output should be subsumed
within that paradigm.

> I'd also like to connect the 2D
> quaternion and hypercomplex fractals with the 4D ones so that the 2D
> ones could be used to explore. (This is possible now by hand, but you
> have to know what you are doing.)

Can you explain more of this mechanism?  I'm not familiar with POV-ray
(guess I need to download it!)

> At this point I don't see how OpenGL helps with Fractint's 3D because
> of the nature of fractals. But I'm open to learn at the feet of an
> expert <g!> This probably needs a Windows port to do on the PC end.

On many unix boxes (and soon PC boxes too, under Win95), OpenGL
rendering is more featureful and has higher performance than rendering
through the window system mechanism.  For instance, OpenGL supports
the idea of images with transparency channels, whereas X does not.  (I
don't know if Win32 supports RGBA pixels though.)

> > - specify any video mode from command line
>
> The DOS version does this. I agree it's a big weakness of the
> Xfractint version.

I think the DOS version lets you only specify video modes that are
tied to a function key?  What if you want to select a video mode that
isn't tied to a function key?  Can it be selected without changing the
key mapping first?

> > - fractal breeder
>
> Robin's evolver is a great start toward this.

Yes, I cheered inside when I saw you mention this on the fractint list
:)

I have some thoughts on the concept, but I'd like to go into them in a
separate message as this one is already too long! :)

> The biggest issue is how to get out from under DOS. One of
> the big obstacles is that we have ported all the assembler already,
> but users LOVE the fast assembler. We need a Windows port (preferably
> done with a portable GUI built with TK or some such) that has some of
> the assembler ported, particularly the fast parser and
> Mandlbrot/Julia.

How does DOS assembler differ from Windows assembler?  You lost me
there :).  I have been writing software since 1978, but never learned
much detail about programming under DOS.

> Having said all this, what I should personally do next is take some
> time and finish off SOI (Synchronous Orbits) and port it to arbitrary
> precision. Or I could drop it and tackle PNG. Or I should buy Visual
> C++. Or I should plunge into TK under Linux, which means I need a new
> hard drive. You see my problem <ggg!>

I would suggest finishing SOI, and we could work on PNG together or
something, I dunno :).  SOI seems more important than those other
things, but what do I know, I'm just getting up to speed <g>.

                        -- Rich
--
  ``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: robin bussell <[e-mail]>
Subject: Re: (fractdev) alive yet?
Date: 15 Aug 1997 01:31:30 +0100

Rich Thomson wrote:
>
> > > - fractal breeder
> >
> > Robin's evolver is a great start toward this.
>
> Yes, I cheered inside when I saw you mention this on the fractint list
> :)
>
> I have some thoughts on the concept, but I'd like to go into them in a
> separate message as this one is already too long! :)

Please do! I've been wanting to have some good meaty discussions about
this for ages, at the moment I hope I've made things fairly tweakable.
It's based around an array of structures which have pointers to
variables and corresponding functions to mutate those variables. The
interface is the main thing that can do with beefing up, it'd be great
to have lots of control panel windows available on screen at once for
tweaking things and displaying the underlying mutations... definately
better implemented in a windowed environment.

Looking forward to your ideas, especially as regards some form of proper
breeding between mutations.

Cheers,
     Robin.




>
> > The biggest issue is how to get out from under DOS. One of
> > the big obstacles is that we have ported all the assembler already,
> > but users LOVE the fast assembler. We need a Windows port (preferably
> > done with a portable GUI built with TK or some such) that has some of
> > the assembler ported, particularly the fast parser and
> > Mandlbrot/Julia.
>
> How does DOS assembler differ from Windows assembler?  You lost me
> there :).  I have been writing software since 1978, but never learned
> much detail about programming under DOS.
>
> > Having said all this, what I should personally do next is take some
> > time and finish off SOI (Synchronous Orbits) and port it to arbitrary
> > precision. Or I could drop it and tackle PNG. Or I should buy Visual
> > C++. Or I should plunge into TK under Linux, which means I need a new
> > hard drive. You see my problem <ggg!>
>
> I would suggest finishing SOI, and we could work on PNG together or
> something, I dunno :).  SOI seems more important than those other
> things, but what do I know, I'm just getting up to speed <g>.
>
>                                                 -- Rich
> --
>   ``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"

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) alive yet?
Date: 15 Aug 1997 12:52:47 -0600


I wrote:
> > I have some thoughts on the concept, but I'd like to go into them in a
> > separate message as this one is already too long! :)

In article <[e-mail]>,
    robin bussell <[e-mail]>  replies:
> Please do! [...]

Are you familiar with William Latham's book "Evolutionary Art and
Computers"?  (He has a web site at <URL:
http://www.artworks.co.uk/home.html>.)  This is where most of my
inspiration comes from; that and the fractal evolver control panel in
Kai's Power Tools.

Now to get a little more specific on fractint.

Consider the parameter set that reproduces an image to be its
"genome".  Within each parameter set, I would classify the variables
into the following categories, in order of significance:

    type
    Lots of other parameters only make sense for certain types of
    fractals.  p1 may set a bailout value for one type and a
    perturbation parameter for another type

    rendering parameters
    These are parameters that control the computation of the
    fractal (usually expressed as a per-pixel iteration count,
    but for other fractal types may mean something different
    such as the number of points to compute in an IFS).  Most
    of them are on the x, y, and z screens.

    coloring parameters
    inside, outside, colormap, etc.

    viewing parameters
    (for 3d fractals where one can change perspectives)

Now if you are familiar with the evolver panel in KPT, you might see
where I am going with this.  A fractal can be "mutated" in a number of
ways, some of which have subtle effects on the image (i.e. only a
colormap change), whereas changing the fractal type can result in a
somewhat rude mutation. :)  A "mutation level" control should let you
restrict the mutation to one of the classes listed above.  For mild
mutations you might just want to change the colormap only.  For
"medium" mutations you might want to change various parameters from
the x,y,z screens.  For huge mutations, you are basically asking
fractint to generate random collections of par values from its
repetoire and display them.

Now the above discussion operates from an "asexual" reproduction
model.  This is similar to the evolver panel in KPT, where the
"parent" is shown in the center of a 3x3 grid of images:

                +--------+--------+--------+
                |        |        |        |
                | Child  | Child  | Child  |
                | 1      | 2      | 3      |
                +--------+--------+--------+
                |        | Parent |        |
                | Child  |        | Child  |
                | 4      |        | 5      |
                +--------+--------+--------+
                |        |        |        |
                | Child  | Child  | Child  |
                | 6      | 7      | 8      |
                +--------+--------+--------+

Each of the child images is a mutation from the parent; how much a
mutation is controlled by a "mutagenic tree" control on the KPT
evolver panel.

This is different from Latham's scheme of evolved forms where the
"gardener" selects various forms for cross-breeding.  The resultant
offspring have characteristics of both parents.

I'm not sure I know how to incorporate this kind of paradigm into
fractint, but it might be possible to experiment outside of fractint
by writing a program that manipulates PAR files only to experiment
with the idea.  The PAR files could then be rendered in 19.6 to
examine the results.  Not exactly interactive, but at least it would
provide you with a testbed.

Now, onto some ideas about implementation:

The "mutation level" control determines the maximum level of mutation
that can occur between parent and child.  Let's suppose this is an
integer called mutation_level.  Next, generate the mutation threshold
for each of the child images, a random integer between 1 and
mutation_level, inclusive.  (A mutation threshold of 0 would indicate
no change from the parent.)  Now we take each child image's threshold
and mutate any parameters that fall below the threshold.  A more
restrictive approach might mutate only a single parameter, or mutate
the parameter by an amount in proportion to the difference between the
image's threshold and the parameter's threshold.

Some experimentation is probably needed to pick one method that works
well.  I think its best not to flood the user with too many controls
they barely understand; the point of the evolver is to do away with
understanding the parameters and navigate the multi-dimensional
parameter space visually.

Now, having said all that, there is another, distinct way of looking
at the mutation.  View the genome of the fractal as a collection of
bits.  Based on the mutation level, pick a fraction of the bits to be
changed during the mutation process.  The mutation process changes the
bits and generates the new child fractal from the mutated parameter
set.  This method treats all the bits in the genome as identical
candidates for permutation (and thus perhaps ought not to include
fractal type).  An implementation might choose to use its internal
binary data structure as the "genome" -- probably along with a bit
mask to indicates which portions of the data structure are
contributing bits to the genome.

The latter approach has a certain simplicity that makes it attractive,
but it doesn't appeal to me as much.  I like the idea that the evolver
would understand that some parameters are for very low-level mutations
and others are only to be used when you crank up the mutation
control.  The anonymous genome bit approach can only approach this by
changing more bits in the genome when the mutation control is cranked
up.  At any rate, those are my thoughts on the idea.
--
  ``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: (fractdev) quadtree based zoom/pan
Date: 15 Aug 1997 14:33:03 -0600

Something occurred to me last night.  It would be cool to use the disk
as a database for an "infinitely zoomable/pannable" rendering of the
M-set.  The more you explore various regions of M, the more data will
be stored in your database on disk (iteration counts).  A program can
then use the multiresolution properties of quadtrees with efficient
disk access algorithms (they already exist in published form) to allow
panning/zooming into various regions of M without recomputing portions
you have visited before.  Hmm... in writing this, I don't know if I've
made the idea clear enough for anyone else to understand it :), but
I'll put it out there for you to chew on!
                        -- Rich
--
  ``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: (fractdev) Short absence
Date: 15 Aug 1997 18:54:13 -0600

I'll be gone from Saturday morning (August 16) through Wednesday
(August 20). List traffic can continue as normal, but I won't be
available to handle any special fractdev list problems until I get
back.

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) alive yet?
Date: 15 Aug 1997 23:05:42 -0600


> > I favor algorithms that interpolate between colors so
> > that users can explore and color with 256 colors.
>
> Can you elaborate on what you mean here?

There are algorithms that cause smoothly varying colors between the
escape-time bands, but match (one side of) escape-time borders. They
look similar to their 256-color cousins, only no sharp boundaries.

Lee Skinner forwarded some correspondence from the fractal-art list.
I can retrieve the messages, but it might be better to see if the
fractal-art archive is available at aros.net.

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) alive yet?
Date: 15 Aug 1997 23:05:42 -0600


> > Consideration for saving off the fundamental pixel
> > information and true-coloring as a post process.
>
> Isn't this in fractint 19.6 right now?

Very simple, written to a Targa file, done to facilitate
experimentation. I believe the iteration is saved, not the last orbit
value which is also needed for many algorithms.

> Cool.  This might become more popular than you think!  Seeing as how
> winsock is widely available on people's machines nowadays, their might
> be a way to coordinate different machines over the internet to
> cooperatively render fractals.

If one isn't worried about sophistication, this is close to being
done now. Fractint creates a DOS batch file that creates a grid of
images one-by-one. It could just as easily create a shell script that
shot off fractint parallel processes across the network. The parallel
part could be done by an external program that launched fractint
processes. However I expect you'd want to do this in a slicker way.
<g!> As it is now, it is very easy to do group projects. make the
batch file, and have different people generate parts of it, then
assemble them back together.

> What I was suggesting is that we keep the application extension block
> but also add a par definition style text comment as well.  (If you
> extract the printable comments with a GIF utility, then you have the
> par file without having to load the file into fractint.)

This would be extremely easy. I'm still prejudiced against the idea
though <g!>

>
> Here is why I think direct JPEG support is important in fractint's
> future:

You make good arguments for JPEG, but there's no argument for GIF
once PNG is onboard. I'm not familiar with JPEG enough to know about
it's comment support, but being able to add PAR info would be good.

> What's medium model support?

Old DOS programs have 6 memory models: tiny, small, compact, medium,
large, and huge. The variations basically deal with the variations on
Intel's hated segmentation. Fractint uses the medium model. Data is
near, code is far. That means that data is accessed by 16 bit
pointers in one 64K segment, but code can be in multiple 64K
segments. The original choice was made on the basis of performance.
On early Intel chips, there was an advantage to having 16 bit
pointers.

> I don't have a feel for what the memory budget of fractint is right
> now.  I'm still trying to understand the layout of the source code :).

There is some method to the madness :)

We ran out of 640K a long time ago. Overlays saved us. Near space has
run out. Everytime you create a global variable or a static variable
or array, you eat near memory. Usually if this is needed, we just
clean up code someplace to free up near memory to pay for it. New
code that goes into overlays usually doesn't eat up any resources.
But space has to allocated for the largest overlay. You don't want to
hear about the details <g!> We will let you know when we had
problems. For example, the SOI code had a recursive routine with a
zillion local variables. This eats stack. Unix machines may have an
infinite amount, but we have 10K or so. In order to make the SOI code
work, I had to prune the local variables way back.

This is bad, but it isn't necessarily as bad as it sounds.

> Is it an option to include features (say, PNG & JPEG support) in some
> ports but not others?  For instance, let DOS have only GIF I/O, to be
> eventually replaced by PNG, but no other file formats.  Or does this
> lead to an unhappy divergence among platforms?

We can decide this on a case by case basis. We're in charge of
ourselves so we (that includes you) can do what we want <g!> We can't
forget users though. The main ones are here, reading every word ...
<g!> They mainly use the DOS version.

> The best reference on this is "The Algorithmic Beauty of Plants", by
> P. Prusinkiewicz --

I have this book. I think to do Lsystems justice a ray tracer is
needed.

> I think the DOS version lets you only specify video modes that are
> tied to a function key?  What if you want to select a video mode that
> isn't tied to a function key?  Can it be selected without changing the
> key mapping first?

There's a scrollable list of all the modes in fractint.cfg. You can
select modes not attached to function keys (use the <del> key to get
this menu.)

> How does DOS assembler differ from Windows assembler?  You lost me
> there :).  I have been writing software since 1978, but never learned
> much detail about programming under DOS.

Floating Point assembler is much the same under Windows, but CPU
assembler is probably a lot different. Hopwever I know nothing about
it <gg!>

> I would suggest finishing SOI, and we could work on PNG together or
> something, I dunno :).  SOI seems more important than those other
> things, but what do I know, I'm just getting up to speed <g>.

I'll look at SOI when I get back from taking my son to Baltimore for
college. We're leaving early (Saturday) so we can take in a Saturday
night in the New Orleans French Quarter listning to jazz.

There's a lot in your message to respond to. I'll talk about POV-Ray
another time. Check out www.povray.org. But if you get into ray
tracing we'll never see you again. :-) I'd love it though if some of
our fractal artists got POV-Ray up and running and tried the 4D
fractals that we implemented.

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) alive yet?
Date: 18 Aug 1997 10:25:39 -0600


In article <[e-mail]> ,
    "Tim Wegner" <[e-mail]>  writes:
> > The best reference on this is "The Algorithmic Beauty of Plants", by
> > P. Prusinkiewicz --
>
> I have this book. I think to do Lsystems justice a ray tracer is
> needed.

Perhaps, but the kinds of L-systems in P's book can just as easily be
rendered with polygon rendering capabilities.  (OpenGL would have no
problem with it.)

> There's a scrollable list of all the modes in fractint.cfg. You can
> select modes not attached to function keys (use the <del> key to get
> this menu.)

Right, but I thought I read in the docs that you can't select a video
mode from a PAR file or command line option unless it is assigned to a
function key?

> Floating Point assembler is much the same under Windows, but CPU
> assembler is probably a lot different. Hopwever I know nothing about
> it <gg!>

Well obviously the CPUs are the same, so the only part that might
change (to my mind) would be the calling convention -- how variables
are passed in, how memory is managed, traps, etc.

> There's a lot in your message to respond to. I'll talk about POV-Ray
> another time. Check out www.povray.org. But if you get into ray
> tracing we'll never see you again. :-) I'd love it though if some of
> our fractal artists got POV-Ray up and running and tried the 4D
> fractals that we implemented.

I've used RayShade before, and I know fractint has some support for
rayshade output as well as POV ray.  But I will take a look at POV ray
as well.
--
  ``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: robin bussell <[e-mail]>
Subject: (fractdev) Re: fractals.. alive yet?
Date: 18 Aug 1997 01:20:53 +0100

Rich Thomson wrote:
>
> I wrote:
> > > I have some thoughts on the concept, but I'd like to go into them in a
> > > separate message as this one is already too long! :)
>
> In article <[e-mail]>,
>     robin bussell <[e-mail]>  replies:
> > Please do! [...]
>
> Are you familiar with William Latham's book "Evolutionary Art and
> Computers"?  (He has a web site at <URL:
> http://www.artworks.co.uk/home.html>.)  This is where most of my
> inspiration comes from; that and the fractal evolver control panel in
> Kai's Power Tools.
>

I'm familiar with his work but I've yet to read the book, I love his
animations though (do you watch reboot? nice 'web creature' inspired by
his work ).
I've not used KPT either... If I'd realised there was an evolver in
there I might had paid more attention than "hey! classy interface" :-)

> Now to get a little more specific on fractint.
>
> Consider the parameter set that reproduces an image to be its
> "genome".  Within each parameter set, I would classify the variables
> into the following categories, in order of significance:

<snip>
> Now if you are familiar with the evolver panel in KPT, you might see
> where I am going with this.  A fractal can be "mutated" in a number of
> ways, some of which have subtle effects on the image (i.e. only a
> colormap change), whereas changing the fractal type can result in a
> somewhat rude mutation. :)  A "mutation level" control should let you
> restrict the mutation to one of the classes listed above.  For mild
That's a good idea! at the moment the user is presented with a screen
that allows the mutation of each of the variables to be switched on and
off at will.
Having groups is a definate plus.. especially if it's hidden in a
generic mutation level as you suggest. I'll definately do something like
that, nice one!

But as it stands the evolver doesn't just do random mutations...


> Now the above discussion operates from an "asexual" reproduction
> model.  This is similar to the evolver panel in KPT, where the
> "parent" is shown in the center of a 3x3 grid of images:
>
>                 +--------+--------+--------+
>                 |        |        |        |
>                 | Child  | Child  | Child  |
>                 | 1      | 2      | 3      |
>                 +--------+--------+--------+
>                 |        | Parent |        |
>                 | Child  |        | Child  |
>                 | 4      |        | 5      |
>                 +--------+--------+--------+
>                 |        |        |        |
>                 | Child  | Child  | Child  |
>                 | 6      | 7      | 8      |
>                 +--------+--------+--------+
>
> Each of the child images is a mutation from the parent; how much a
> mutation is controlled by a "mutagenic tree" control on the KPT
> evolver panel.

The evolver does the same but also has a 'field mapping' mode whereby
the grid is larger and parameters are varied smoothly in the x and Y
directions. This produces a sort of pseudo 4d display (must think of a
better name) whereby each image sits in a position in it's own 2d
parameter space and shows the image produced by that neighbourhood of
parm-space.... if you see what I mean!
The user can then select an image to form the centre of the next parm
space map which will be a zoomed version of the previous one.
In this way the user can explore parameter space in a more orderly
fashion, large grids of small images can be used to visualise the
underlying patterns in parameter space, forinstance the default settings
of parameter offsets and ranges across screen allow the julia sets to be
mapped across the space occupied by the mset, if the grid size (number
of images on each side) is set high then an underlying Mset is clearly
seen. This is tricky to explain but hopefully you'll be able to try it
yourself soon :-)

It's interesting (but not too startling :) ) to notice when using this
tool that the parameter spaces are just as chaotic as the usual complex
plane.

At the moment random mutation is implemented as a random walk variation
mode that does what it suggests :-) any parameter can be selected to
wanders about between images. Between generations the (global) scale
factor of the walk (maximum delta per parm between images) can be
reduced automatically thus allowing the mutations to become more subtle
as the exploration continues (though it can easily be blasted back up
again with a few keystroke if things get stagnant).




>
> This is different from Latham's scheme of evolved forms where the
> "gardener" selects various forms for cross-breeding.  The resultant
> offspring have characteristics of both parents.
>
> I'm not sure I know how to incorporate this kind of paradigm into
> fractint,

This has been bugging me somewhat too... initial ideas forming in a
foggy fashion at the back of my mind are along the lines of storing the
genes in delta form i.e if parm(0) is the last generation, for each
image store parm(1)-parm(0)... for each parameter. This would allow two
sets of variations from the last generations chosen image to be combined
by simple addition, and maybe then used as a template for the next
generation of images. This would only really be valid for those
parameters that have a floating point value like c for julia sets or the
intial perturbation in Msets. Other parms like inside value or bailout
test that take integer values and differ wildly in effect from one to
the next  need different treatment, possibly trying to bias any random
variations towards them in some way.... tricky one this!




> Now, onto some ideas about implementation:
>
> The "mutation level" control determines the maximum level of mutation
> that can occur between parent and child.  Let's suppose this is an
> integer called mutation_level.  Next, generate the mutation threshold
> for each of the child images, a random integer between 1 and
> mutation_level, inclusive.  (A mutation threshold of 0 would indicate
> no change from the parent.)  Now we take each child image's threshold
> and mutate any parameters that fall below the threshold.  A more
> restrictive approach might mutate only a single parameter, or mutate
> the parameter by an amount in proportion to the difference between the
> image's threshold and the parameter's threshold.

I'm not fully sure what you're getting at here.. what sort of range of
values do you envision for the mutation level? do you mean a mutation
threshold for each parameter in each child image? This scheme is good in
that it wouldn't mutate every parameter in each image, mine at present
has possibly everything changing though not necessarily by much.

>
> Some experimentation is probably needed to pick one method that works
> well.  I think its best not to flood the user with too many controls
> they barely understand; the point of the evolver is to do away with
> understanding the parameters and navigate the multi-dimensional
> parameter space visually.


YES! Right on brother! Definately the point of the whole effort, I keep
on losing sight of this as I get captured by the possiblities of
controllable exploration as well as random evolution ( guess the nerd in
me just likes the knobs and whistles too much :-) ) ... you're spot on
though, it's got to be easy to just spin the wheel and see what comes
out... have you thought about the possibility of building in some neural
net analysis of all the parms and the images chosen to maybe allow
unnatended production of images that it's statistically fairly certain
the user who trained it would like! (way beyond my programming ability
but a nice pipe dream :-) )

>
> Now, having said all that, there is another, distinct way of looking
> at the mutation.  View the genome of the fractal as a collection of
> bits..... This method treats all the bits in the genome as identical
> candidates for permutation ......
> The latter approach has a certain simplicity that makes it attractive,
> but it doesn't appeal to me as much.  I like the idea that the evolver
> would understand that some parameters are for very low-level mutations
> and others are only to be used when you crank up the mutation
> control.

Yep, I don't like the 'cosmic ray' method quite so much either. Though,
likewise, I admire it's simplicity. There's already some dichotomy
between the continuous variables and the descrete ones that will fit
nicely into the mutation level idea, definately one to go with, thanks!
I can forsee vast flamewars about which parameters are more radical
though :-)

>   At any rate, those are my thoughts on the idea.

Very welcome ones too! any comments on the above?


Cheers,
     Robin.

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: robin bussell <[e-mail]>
Subject: Re: (fractdev) quadtree based zoom/pan
Date: 18 Aug 1997 01:24:53 +0100

Rich Thomson wrote:
>
> Something occurred to me last night.  It would be cool to use the disk
> as a database for an "infinitely zoomable/pannable" rendering of the
> M-set.  .. A program can
> then use the multiresolution properties of quadtrees with efficient
> disk access algorithms (they already exist in published form)

I've not come across quadtrees.. any pointers to info... I guess it's
like the octrees that are used to store world data in ray tracing? (NO!!
don't look into that, we'll loose you like Tim fears :-) )

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: fractals.. alive yet?
Date: 19 Aug 1997 15:48:26 -0600


In article <[e-mail]> ,
    robin bussell <[e-mail]>  writes:
> Rich Thomson wrote:
> > [...]  A "mutation level" control should let you
> > restrict the mutation to one of the classes listed above.
>
> That's a good idea! [...]
> But as it stands the evolver doesn't just do random mutations...

Perhaps it would be good for me and others if you gaven an overview
of how your evolver currently works?

> The evolver does the same but also has a 'field mapping' mode [...]

Yes, that would be handy for exploring a single parameter that
is two dimensional (complex or real number coordinate).

> At the moment random mutation is implemented as a random walk variation
> mode that does what it suggests :-) any parameter can be selected to
> wanders about between images. Between generations the (global) scale
> factor of the walk (maximum delta per parm between images) can be
> reduced automatically thus allowing the mutations to become more subtle
> as the exploration continues (though it can easily be blasted back up
> again with a few keystroke if things get stagnant).

This sounds like it could be worked into the "mutation level" control
I mentioned above.  I am thinking there might be a "mutation control
panel" for those of us who are intensely interested in the mutation
process, but that the visual browsing we've talked about is what
most people will use.

> intial perturbation in Msets. Other parms like inside value or bailout
> test that take integer values and differ wildly in effect from one to
> the next  need different treatment, possibly trying to bias any random
> variations towards them in some way.... tricky one this!

Yes, some of the enumerated parameters need some tweaking to fit
into the continuously variable model of the collection of gene "bits".

> I'm not fully sure what you're getting at here.. what sort of range of
> values do you envision for the mutation level?

The mutation level control just takes on integer values with ranges
chosen arbitrary based on the internals of the implementation.  Its
actual value isn't important.  What is important is how this control
setting relates to the hard-coded thresholds for each parameter.

> do you mean a mutation
> threshold for each parameter in each child image?

Each parameter has a single, fixed threshold.  If the mutation control
value is above this threshold, then this parameter is a candidate for
mutation in the next generation.  Otherwise, this parameter remains
fixed from parent to child.

> This scheme is good in
> that it wouldn't mutate every parameter in each image, mine at present
> has possibly everything changing though not necessarily by much.

If we look at mutation as a continuum, I envision something like this:

    Mutation
    Control    Effect
    --------    ------
    minimum    Child images are identical to the parent
        "clones"
    a        Child images are almost identical to parent,
        with coloring/palette variations only
        "family group"
    b        Child images are very similar to parent,
        varying only one parameter (or multiple parameters
        by a small amount)
        "same species"
    c        Child images are same type as parent,
        with wide varietion over a single parameter (or
        multiple parameters by small and/or large amounts)
        "same genus"
    d        Child images bear almost no relation to the parent,
        changing fractal type, parameters and coloring methods
        all at once.
        "same order" (fractals)
    maximum    Child images are completely random

For this little table, it is assumed that:

    minimum < a < b < c < d < maximum

This "mutation level control" is just some integer number between
0 (minimum) and N, an implementation maximum.  The actual value of
the number isn't so important (from the point of view of the user)
since it is just used to guage how much mutation takes place in each
generation.

From an implementation point of view, it might be helpful to assign
a, b, c, and d certain "magic" values that ease determination of
the parameter values changed between parent and child.  You also
might insert more "stages" to the mutation than I have outlined above.

> [...] have you thought about the possibility of building in some neural
> net analysis of all the parms and the images chosen to maybe allow
> unnatended production of images that it's statistically fairly certain
> the user who trained it would like! (way beyond my programming ability
> but a nice pipe dream :-) )

I'm afraid I know only rudimentary things about neural nets so its
beyond my ability as well :)

                        -- Rich
--
  ``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) quadtree based zoom/pan
Date: 19 Aug 1997 15:52:50 -0600


Let me elaborate a little more on what I was talking about.  I think
this is something that might best be experimented with outside the
boundaries of fractint code.

Rendering M is similar to rendering MIP-mapped textures, where the
texture is computed on-the-fly.  (Did I lose you yet? :)  A quadtree
is just one data structure that could be used to hold all the
iterations computed for M at various levels of detail.  The quadtree
stores all your iteration computations as you zoom and pan.  Its
actually a collection of quadtrees.  At any given magnification factor
you are computing iterations on a sample grid aligned to the next
highest resolution quadtree than is required to refresh your screen.

Screen refresh happens from the quad tree, either copying or
interpolating iteration counts from the quadtree to color the screen.

The more you pan and zoom, the more you "fill out" the quadtree data
structure.  After a time, panning and zooming can be done quickly
completely from the quadtree, which by this time has become a
multi-resolution cache for the iteration count of M.

Is any of this making any sense yet? :)
--
  ``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:  <[e-mail]>
Subject: Re: (fractdev) Re: fractals.. a-life yet?
Date: 21 Aug 1997 10:02:11 -0600


On Tuesday, August 19, 1997 15:48:26 you wrote:


>
>Perhaps it would be good for me and others if you gaven an overview
>of how your evolver currently works?
>

Ok, it's usually good for me too! here goes:

The evolver is basically a loop within fractint that encompasses the normal image drawing
routine and a routine to vary the parameters between iterations. Viewwindow mode is used and
the offsets of the start of the view window are also changed each time round the loop to
tile the images across the screen. Each image has a corresponding co-ordinate in the grid
onscreen held in variables px and py... these represent the co-ords in a sort of 2d
parameter space of each image.
pseudocode fragment:

   for (py=0;py<gridsize;py++)
      for(px=0;px<gridsize;px++) {
          mutate_parms();
          imagexoffset = px*(screenwidth/gridsize); /* gridsize = no of images per side of
                                                         screen */
          imageyoffset = py*(screenheight/gridsize);
          draw_fractal();
       }


The parameter mutation routines are all designed to give reproducable mutations based on px,
py and a random number seed used at the start of each screenfull ('generation').

When the user selects a particular image the appropriate px and py are fed into the mutation
routines to set all paramters to those used to generate that image. The user can then either
switch off evolution to get a fullscreen version of the image or use it as the basis of the
next generation.

The control interface consists of a list of parameters for which the user can select a
mutation style. Available styles include no,x,y and random walk.

no: the parameter stays the same for all images.

x: the parameter is varied linearly as the px value increases.

y: the parameter is varied linearly as the py value increases.

random-walk: the parameter has a random number from -fiddlefactor to +fiddlefactor added to
it after each image is calculated. fiddlefactor is user choosable and can be set to be
decreased automatically by a certain amount between generations.


sample mutation routine:

void varydouble(int how_to_mutate)
{
     switch(how_to_mutate) {
        case 0: /* no variation */
             break;
        case 1: /*x*/
             parm=pxoffs+px*(parmrangex/gridsize);
             break;
          .
          .
          .
        case 5: /*random walk*/
             parm = parm + rand(fiddlefactor);


     }
}

except that it's all done with pointers so that one routine is needed per type of variable.
pxoffs is the parameter value given to the left hand image, parmrangex is the variation
across the screen.
These ranges and offsets are changed between generations to make sure that the chosen image
ends up in the middle of the screen and to allow zooming in parameter space.

Each variable has an entry in a gene[] array of these structures:

 struct base {
              void * address; /* pointer to the parameter in question */
              char [] name;  /* name of parmameter, used in menus */
              void * varyfunc(); /* pointer to function used to mutate this parm*/
              }

and the main mutation routine (called once per image ) just marches through this array
calling appropriate functions by reference to the varyfunc pointer.

To implement the mutation level idea we could add:

              int threshold; /* how serious a mustation this parm represents */

to the base structure and stick a test for it in each varyfunc, nice and simple :-)

And that's it really.. the user i/f consists of an outline box that's moved around the grid
to select the next image.

>  I am thinking there might be a "mutation control
>panel" for those of us who are intensely interested in the mutation
>process, but that the visual browsing we've talked about is what
>most people will use.

As it stands the control panel is fairly easy to use but I've also thrown in some 'randomise
everything' keys and sensible defaults to enable a fast start so the non techie user can
just switch on evolver mode, hit go and then just browse amonst the images.

Right that's quite enough typing for now! Hopefully the above should give you a good idea of
what's going on, the mutation level control should be easy enough to fit in, I'll give it a
go once I'm over the memory allocation hassles I'm getting at the moment (yeah I know.. get
a decent OS :-) )


Cheers,
     Robin.


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: fractals.. a-life yet?
Date: 21 Aug 1997 10:58:23 -0600


In article <[e-mail]> ,
    <[e-mail]>  writes:
> To implement the mutation level idea we could add:
>
>   int threshold; /* how serious a mustation this parm represents */
>
> to the base structure and stick a test for it in each varyfunc, nice
> and simple :-)

Why not just put each parameter's threshold in the base structure and
do the test before calling the function to vary the parameter?  Then
the main loop just tests each base structure against the threshold and
doens't bother calling the function unless its under the threshold.

Otherwise, looks pretty cool.
--
  ``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: Lee Skinner <[e-mail]>
Subject: (fractdev) Re: fractals.
Date: 21 Aug 1997 16:23:17 -0400

Robin,

>   int threshold; /* how serious a mustation this parm represents */

Just curious.  Is a mustation a mutation that produces a mustache?

Lee Skinner

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) Hi
Date: 21 Aug 1997 18:57:04 -0600

Had a good trip, now to catch up on the mail!

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: robin bussell <[e-mail]>
Subject: Re: (fractdev) Re: fractals.. a-life yet?
Date: 22 Aug 1997 01:04:53 +0100

Rich Thomson wrote:
> Why not just put each parameter's threshold in the base structure and
> do the test before calling the function to vary the parameter?  Then
> the main loop just tests each base structure against the threshold and
> doens't bother calling the function unless its under the threshold.

True, that would be better, there was some legacy reason for doing it
the other way but it's not valid any more so that would be fine (it's my
excuse and I'm sticking to it :-) ) .... to do with making sure the
pseudo random numbers used are replayed in correct sequence when
regenerating the parameters for a selected image, I've got round it now
by generating them in the main loop and passing a random value to the
mutation functions to use if needed, so as long as the call to rand() is
outside the threshold test then all will be ok (otherwise things would
go awry if the user changed it between generations )

>
> Otherwise, looks pretty cool.

jolly good :-) Have you read Kellys book, 'out of control, the new
biology of machines'? it's what introduced me to the idea by telling of
the work done by Karl Sims at Thinking Machines with evolutionary art.
He'd set up a lot of monitors in a gallery run by a connection machine
and let visitors breed the images by means of simple controls. Im not
sure about the underlying mechanisms but it looks a bit like some sort
of LISP expression evolution.
Then there's lparser by Laurens Lapre which can mutate 3D L-systems,
I've not played with  it but the example images I've seen look
wonderful.

BTW tell me more about 3D-paint, what's the interface like?

Cheers,
     Robin.

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: robin bussell <[e-mail]>
Subject: Re: (fractdev) Re: fractals.
Date: 22 Aug 1997 01:05:09 +0100

Lee Skinner wrote:

> Just curious.  Is a mustation a mutation that produces a mustache?
>

:-})

Quite poshibly!



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

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


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

From: "Tim Wegner" <[e-mail]>
Subject: (fractdev) SOI
Date: 24 Aug 1997 17:12:21 -0600

I've been looking into SOI. My first thought was that it would be
interesting to try the SOI algorithm with arbitrary fractal types.
But as I thought about it more, I realized that SOI is only useful
for very deep zooms, and hence is only of real interest with
arbitrary precision. At present, only a very few fractal types have
been ported to arbitrary precision. Therefore I conclude that support
for mandelbrot with all the various coloring options is the top
priority. SOI support for the small number of additional fractal
types that use arbitrary precision is the next priority.

The StandardFractal() routine needs to be modified so that it can
support continuing iteration of an orbit that has already been
started. I may move all the code prior to the iteration while loop to
a separate routine.

I have also updated Xfract to the latest patch, including the
evolver. I still need to make a new patch with the required changes,
which I'll do in the next few days.

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: fractals.. a-life yet?
Date: 25 Aug 1997 10:21:37 -0600


In article <[e-mail]> ,
    robin bussell <[e-mail]>  writes:
> jolly good :-) Have you read Kellys book, 'out of control, the new
> biology of machines'? it's what introduced me to the idea by telling of
> the work done by Karl Sims at Thinking Machines with evolutionary art.

I'm familiar with Sims' work (nice stuff), but not that book in
particular.  I've read brief technical sketches of what Sims' was
doing at TM and yeah, I think it involved mutating LISP expressions
which were then interpreted graphically.  I'm not any more familiar
with it than that, but Sims has published some papers in SIGGRAPH or
other journals, I think.

> Then there's lparser by Laurens Lapre which can mutate 3D L-systems,
> I've not played with  it but the example images I've seen look
> wonderful.

Haven't heard anything about this, it sounds kinda cool!
--
  ``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:  <[e-mail]>
Subject: Re: (fractdev) Re: fractals.. a-life yet
Date: 26 Aug 1997 10:19:57 -0600


>
>> Then there's lparser by Laurens Lapre which can mutate 3D L-systems,
>> I've not played with  it but the example images I've seen look
>> wonderful.
>
>Haven't heard anything about this, it sounds kinda cool!
>--


It is, especially with the VRML output option which means that you can have a text editor,
lparser, and vrml browser all runing in different windows for a quick development cycle.

For more see:
http://www.xs4all.nl/~ljlapre/

Even if you don't like lysytems any fractal fan will like this rather nicely laid out set of
pages... take a look!

  Cheers,
        Robin.


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) cellular automata
Date: 26 Aug 1997 10:54:46 -0600

fractint's support for cellular automata seems rather limited.  There
are many kinds of cellular automata, fractint only implements the
1D kr type of CA.  Are there any plans to support other types of CA
in fractint?
--
  ``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: (fractdev) Opening fractdev
Date: 26 Aug 1997 21:29:20 -0600

Things are going well managing these two lists. I've got it to the
point where the daily tasks aren't too time consuming. We need to
think about opening up this list, which so far has not been
publicized.

I'm debating in my own mind whther to throw this open to the world or
to just invite people, or to make all subscriptions go through me.
The issue is I don't have time to introduce too many people to the
mysteries of fractint development, but on the other hand we do need
help, and I'm willing to help people who look like they can really
contribute.

Even if we keep participation limited, a few enterprising souls have
already discovered the publically accessible archives, and have
thereby discovered the TW01.ZIP executable at my FTP site. So if we
are concerned about developer versions getting out, this list is not
secure.

Here is my current thinking.

1. Throw this list open the same way fractint was opened. I made one
announcement in fractal-art, one in sci.fractals, and Noel Giffin
publicizes it at spanky.triumf.ca.

2. Post diff files and synching sources at my FTP site. These would
be marked saying they may be downloaded, but not re-uploaded
anywhere.

3. If we're brave we could also post executables at my site with the
same don't distribute prohibition.

If this doesn't work OK, we could stop making developer's versions
so public. Having many developer versions out in the public makes
for support difficulties. Over the years we have pretty much kept
developer versions private. I'm not aware of any instance when
developer versions got spread around.

Any opinions on this?

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) cellular automata
Date: 26 Aug 1997 21:29:20 -0600

>>Are there any plans to support other types of CA
> in fractint?

Be my guest <g!>

Ken Shirriff, the Xfract author, did CA originally. He hasn't been
active for a while, so the correct answer to your question is that no
one is planning this.

I'm taking my time updating Xfract to the latest patch. Right now I'm
working on getting the byte order right for data saved to disk. This
is only an issue for GIFs shared between machines with different byte
order. The main fractalspecific structure is already handled, but
some of the newer xtension blocks aren't.

If you have any need for an up-to-date Xfract, let me know. I don't
have to finish this job before sharing it.

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

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) Opening fractdev
Date: 27 Aug 1997 08:11:38 -0600


On Tuesday, August 26, 1997 21:29:20 you wrote:


>Here is my current thinking.
>
>1. Throw this list open the same way fractint was opened.

Definately the best way to trawl for contributions but I'd say that an
emphasis on *NO WISHLISTS* **THIS IS NOT A FRACTINT WISHLIST LIST**  along
with a plug for the fractint list as the place for questions would be
a Good Thing.
You could also announce in comp.sys.programming.C (or whatever it is)and the generalised
graphics groups too.

On the subject of wishlists I was thinking of putting up a fractint wishlist
page, along the lines of a guest book (exactly the same actually :-) ) whereby
visitors could peruse the previous entries and add their own if they have anything
to add. It would of course be heavily flagged "no promises, information survey only"
Good idea or far too much to do already? Of course the same page would invite any
that feel they can contribute one of the suggestions to get in touch.

>2. Post diff files and synching sources at my FTP site. These would
>be marked saying they may be downloaded, but not re-uploaded

Also a very good idea, you can use search engines to check for unofficial
mirrors :-) Explain why not to upload along the lines of needing to keep
an official synch so that any marvellous features that the reader adds can be
patched in properly... not the case if it's a weird unofficial source that they've
been working with... Then again coming down too heavily is just the way to spawn
a PhR4Ct1Nt Cr3\/\/ version!

>
>3. If we're brave we could also post executables at my site with the
>same don't distribute prohibition.
>
>If this doesn't work OK, we could stop making developer's versions
>so public.

A bit more hairy this one... I think that  visible patches, along
with their descriptions would keep interest up and show that things are still
lively, and those that needed an exe could compile their own. Whereas the thought
of lots of developers versions slowly propagating around the net with the same old bug
reports flooding back in their wake is a bit frightening!


Cheers,
     Robin.








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: (fractdev) wishlist
Date: 27 Aug 1997 10:41:28 -0600

Further to my previous message I've knocked up a quick wish list page here:


http://web.ukonline.co.uk/members/robin.b2/olig/fracwish.htm

have a look and see what you think, If you like it I'll publicise it and link to it and
we'll see what happens :-)

Cheers,
      Robin.



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) cellular automata
Date: 27 Aug 1997 11:12:32 -0600


In article <[e-mail]> ,
    "Tim Wegner" <[e-mail]>  writes:
> >>Are there any plans to support other types of CA
> > in fractint?
>
> Be my guest <g!>

OK, CA are relatively easy to code up, so I will add them to my list
of things I would like to see in fractint :)

> I'm taking my time updating Xfract to the latest patch. [...]

The latest and greatest version fo xfract isn't so important to me
right now.  I posted a large list of "projects" to this list earlier,
but I didn't give any indication of what I would be working on, and in
what order I would work on them.  So here is what I'm planning on
contributing to fractint:

1. better X support for visually rich environments.

    Currently xfract assumes that the default visual is 8bit
    pseudoclor.  This is a no-no in the world of X programming :).  You
    can think of each visual type on a machine as being the rough
    equivalent of a "video mode" on the PC, so I would like to overhaul
    xfract to treat the different visuals in X as different "video
    modes".  This should also allow hooks for using OpenGL under X for
    the graphics rendering in the future.

2. Portability

    getting fractint to compile under IRIX meant modifying some stuff
    in the headers to eliminate compile errors/headers.  Some of
    fractint's DOS heritage is showing here.  I would like to see
    fractint start using GNU autoconf to configure itself for various
    systems.  I am not sure if autoconf runs under DOS, but the
    default configuration packed in the source could be a DOS
    configuration so that people don't have to run autoconf on DOS
    boxes.  At any rate, there are some weird things fractint does
    with ANSI reserved symbols (symbols beginning with _) and various
    #ifdef hacks to try and accomodate the needs of different
    compilers and systems.  The problem with this kind of approach is
    that it is difficult to get fractint to compile on a new system.
    Autoconf elimnates these difficulties.

3. separation of the computation engine from the OS/UI

    Many of my longer term "wishes" for fractint would be more readily
    accomplished if the computation engines for the various fractals
    could be treated as a library.  This would allow one to experiment
    with a variety of algorithms for screen rendering and decomposition
    and so-on without carrying along all of fractint for the ride.  You
    could just link against the computation engine library and call
    into it to get work done.  At this point I'm not yet familiar
    enough with all of fractint's code layout to know if this is
    feasible or not.

    A first pass here would be to identify the places where fractint's
    computation engine is calling into the UI or the OS and document
    exactly what fractint's OS/UI needs are.  Then an abstract layer
    can be built for these needs.  The DOS version of fractint would
    do exactly what it does now, but with this layer in place it
    should be much easier to make a full-featured
    windows/X/BeOS/Amiga/Mac port of fractint that looks and feels
    like our familiar friend.

(Aside: are there any BeOS fans out there?  Now that they've announced
Intel support coming soon I am getting very interested.  See <URL:
http://www.be.com> if you don't know what BeOS is :)
--
  ``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: (fractdev) release schedule, major/minor revision numbers
Date: 27 Aug 1997 14:14:00 -0600

Is there any release schedule for the next version of fractint?

By "schedule" I don't mean something that people can be beaten about
the head with <g>.  Rather I mean is there an envisioned time frame
for the next release of fractint.

Also, who/what decides if the next release will be 19.7 or 20.0?
--
  ``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: [e-mail]
Date: 27 Aug 1997 17:34:09 -0600

This looks like it's from me but it's really from Rich. It bounced
because Rich used the evil word "subscribe" :-)
Sender: [e-mail]
Precedence: bulk
Reply-To: fractdev

> In article
<[e-mail]> ,    "Tim Wegner"
<[e-mail]>  writes:
> I'm debating in my own mind whther to throw this open to the world or
> to just invite people, or to make all subscriptions go through me.

I would choose one of the latter.  Many people won't understand that
this is a developer's oriented list with a much more finely focused
charter than the general fractint list.  They will subscribe to both,
and just use fractdev as a place for their 'wish lists' and requests
without actually doing any development.

> The issue is I don't have time to introduce too many people to the
> mysteries of fractint development, but on the other hand we do need
> help, and I'm willing to help people who look like they can really
> contribute.

To "introduce peoplt to the mysteries of fractint development", I
would write a single document that becomes part of the "welcome to
fractdev" message.  (Existing subscribers can always fetch this
document when it is updated by using the intro command to majordomo.)
That way you only have to write it once and when new developers join
the list, they get the introduction ASAP.

> Even if we keep participation limited, a few enterprising souls have
> already discovered the publically accessible archives, and have
> thereby discovered the TW01.ZIP executable at my FTP site. So if we
> are concerned about developer versions getting out, this list is not
> secure.

Yes, the list archives are publically accessible by FTP on xmission.
If you wish to keep distributions and whatnot secret, then I suggest
one of the following:

    1) place them in a password protected space on a web server.  Then
    release the username/password pair in private email only (i.e.
    don't post it to the list).

    2) place them in a hidden FTP directory and then release the
    directory location in private email only

> 1. Throw this list open the same way fractint was opened. I made one
> announcement in fractal-art, one in sci.fractals, and Noel Giffin
> publicizes it at spanky.triumf.ca.

I think this would be fine IF you limit the subscription process to
people who are genuinely developers and not users.  I'm not trying to
be elitist, but it can be difficult to get the few active developers
focused on a task and completing it when the mailing list is full of
chatter and noise from a bunch of other people who are not developing.
Its a matter of focus.

> 2. Post diff files and synching sources at my FTP site. These would
> be marked saying they may be downloaded, but not re-uploaded
> anywhere.

I generally use CVS for all modifications so I was just going to
contribute my diffs back to Tim for incorporation into the source
base.

> 3. If we're brave we could also post executables at my site with the
> same don't distribute prohibition.

I think executables should be protected by some mechanism and not
publically accessible.  Source code, sure, since most people are not
going to download source code and compile it anyway.  I think binaries
should be controlled a little more because you don't want too many
fractint 19.6b7 executables floating around; you want to maintain a
little more control over the release of new binaries.
--
  ``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) release schedule, major/minor revision numbers
Date: 27 Aug 1997 18:33:54 -0600


> Is there any release schedule for the next version of fractint?

No. We generally release when there are enough significant features
to warrant it. This is is a matter of consensus. Right now, I'd
say Robin's evolver warrants a release. Jonathan and Robin are still
working on it. The earliest time to release would be when the evolver
is stable. It doesn't have to have all the features Robin would like
it to have, but it would need to be at a good pausing place, so that
subsequent improvements would not require changing the current
feature set awkwardly.

> Also, who/what decides if the next release will be 19.7 or 20.0?

Consensus. I guess as the fearless leader I'll listen to discussion
and suggest the consensus, then see if anybody feels strongly that
I'm wrong <g!> Generally we have had no problem with this sort of
decision. You are welcome to offer your ideas. "Consensus" doesn't
have to mean agreement by everyone, but it usually does work that
way.

My personal opinion is that we have had too many .1 version
increments, and the next version should be 20.0 no matter what, even
without any blockbuster new features besides the evolver. If you
compare version 19.6 with 19.0, it's a BIG change.

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) (Fwd) Mail delivery failed: returning message to sender
Date: 27 Aug 1997 18:42:04 -0600

In-Reply-To: Your message of Tue, 26 Aug 1997 21:29:20 -0600.
             <[e-mail]>
Reply-To: [e-mail]
Organization: Design Software Group, Parametric Technology Corporation


In article <[e-mail]> ,
    "Tim Wegner" <[e-mail]>  writes:
> I'm debating in my own mind whther to throw this open to the world or
> to just invite people, or to make all subscriptions go through me.

I would choose one of the latter.  Many people won't understand that
this is a developer's oriented list with a much more finely focused
charter than the general fractint list.  They will subscribe to both,
and just use fractdev as a place for their 'wish lists' and requests
without actually doing any development.

> The issue is I don't have time to introduce too many people to the
> mysteries of fractint development, but on the other hand we do need
> help, and I'm willing to help people who look like they can really
> contribute.

To "introduce peoplt to the mysteries of fractint development", I
would write a single document that becomes part of the "welcome to
fractdev" message.  (Existing subscribers can always fetch this
document when it is updated by using the intro command to majordomo.)
That way you only have to write it once and when new developers join
the list, they get the introduction ASAP.

> Even if we keep participation limited, a few enterprising souls have
> already discovered the publically accessible archives, and have
> thereby discovered the TW01.ZIP executable at my FTP site. So if we
> are concerned about developer versions getting out, this list is not
> secure.

Yes, the list archives are publically accessible by FTP on xmission.
If you wish to keep distributions and whatnot secret, then I suggest
one of the following:

    1) place them in a password protected space on a web server.  Then
    release the username/password pair in private email only (i.e.
    don't post it to the list).

    2) place them in a hidden FTP directory and then release the
    directory location in private email only

> 1. Throw this list open the same way fractint was opened. I made one
> announcement in fractal-art, one in sci.fractals, and Noel Giffin
> publicizes it at spanky.triumf.ca.

I think this would be fine IF you limit the subscription process to
people who are genuinely developers and not users.  I'm not trying to
be elitist, but it can be difficult to get the few active developers
focused on a task and completing it when the mailing list is full of
chatter and noise from a bunch of other people who are not developing.
Its a matter of focus.

> 2. Post diff files and synching sources at my FTP site. These would
> be marked saying they may be downloaded, but not re-uploaded
> anywhere.

I generally use CVS for all modifications so I was just going to
contribute my diffs back to Tim for incorporation into the source
base.

> 3. If we're brave we could also post executables at my site with the
> same don't distribute prohibition.

I think executables should be protected by some mechanism and not
publically accessible.  Source code, sure, since most people are not
going to download source code and compile it anyway.  I think binaries
should be controlled a little more because you don't want too many
fractint 19.6b7 executables floating around; you want to maintain a
little more control over the release of new binaries.
--
  ``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: (fractdev) Opening fractdev
Date: 27 Aug 1997 18:53:07 -0600

I like the gist of Rich's comments. Let's make this a by invitation
list. I've already invited a couple of people. If you want to invite
someone, let me know.

I'm not worried about security for the moment. I'll keep diffs posted
at my FTP site. There are some artists here who can get executables
from compuserve. If there is anyone else here who needs executables
for testing, let me know and we'll figure something out.

I'm not worried about sources in the form of diffs getting out, or
even synching sources.

I like Rich's comments about wish lists. This mailing list is just
not the place for wish lists. It is the right place to expound on
things you intend to implement, or comment on things other people are
implementing. Let's check out Robin's wish list page. That could be a
good way to capture ideas.

Actually, I don't need any more suggestions from people not in a
position to help to add truecolor or port from platform A to B or add
a GUI <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) Opening fractdev
Date: 27 Aug 1997 18:00:35 -0600


In article <[e-mail]> ,
    "Tim Wegner" <[e-mail]>  writes:
> Actually, I don't need any more suggestions from people not in a
> position to help to add truecolor or port from platform A to B or add
> a GUI <grin!>

I think if we lay a little groundwork for porting, we can not only add
GUI support in X/Windows/BeOS/MacOS easily, but we can also make some
of the text screens in fractint work a little better.
--
  ``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) Opening fractdev
Date: 27 Aug 1997 20:03:18 -0600


> I think if we lay a little groundwork for porting, we can not only add
> GUI support in X/Windows/BeOS/MacOS easily, but we can also make some
> of the text screens in fractint work a little better.

I agree. My point is that kind of statement sounds better coming from
someone like yourself who proposes helping than from someone who
thinks it's a good idea <g!>

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: (fractdev) wishlist page
Date: 29 Aug 1997 09:54:22 -0600

So what do you think? should I go ahead and open up the fractint
wishlist page?

http://web.ukonline.co.uk/members/robin.b2/olig/fracwish.htm

Style ok?

is it OK to include your email address as a link, Tim?

Cheers,
     Robin.



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) wishlist page
Date: 29 Aug 1997 14:58:25 -0600


In article <[e-mail]> ,
    <[e-mail]>  writes:
> So what do you think? should I go ahead and open up the fractint
> wishlist page?

Looks OK, but at some point you're going to want to edit out most of
those wishes to pare it down to a useful list :)
--
  ``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: Lee Skinner <[e-mail]>
Subject: (fractdev) wishlist page
Date: 29 Aug 1997 17:14:59 -0400

Robin and Rich,

>>Looks OK, but at some point you're going to want to edit out most of
those wishes to pare it down to a useful list :)<<

Or how about prioritizing them?

Lee

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) Greetings
Date: 29 Aug 1997 17:26:50 -0400

Hello,

Tim showed me the way to this mailing list.  I've already introduced myself
on the FractInt list (which I'm assuming everyone here reads) so I won't do
that here.  But I will say what my interest in FractInt is.

I want a Win95/NT version of FractInt.  I want it pretty bad.  So bad, in
fact, that I'm actually likely to *do* something about it. :-)  My
experience is in DOS, Win3, and Win95 programming, in C, C++, and assembly.
 I have the tools for all three, and my preferred development target
(despite its warts!) is Win95--because it is popular, comes on virtually
every new PC, and because it provides a reasonable degree of hardware
independence.

As I've been discussing with Tim, there are a few technical obstacles to a
Win95 port of FractInt.  The biggest is the switch from a program that
totally controls the machine to one that must be event-driven.  Also, the
32-bit environment will require considerable work on the assembly code, I
suspect.  The good news is that the end result could well be faster than
DOS FractInt on newer processors, which run 32-bit code *much* better than
16-bit stuff.  Losing all that DOS architecture would be another plus.

I think it's a good idea to separate the fractal generator code as
completely as possible from the UI and OS portions.  This would make the
generator code completely portable (or at least make that an achievable
goal).  I personally do not feel that portability in the user interface is
truly possible; almost all the cross-platform UI libraries I've seen have
either serious problems or serious limitations.  But, this is just my opinion.

BTW, how do you (all) feel about moving FractInt to a C++ base, rather than
C?  Most of the speed-critical things would remain in assembly (for the PC
version) so the issue of "C++ inefficiency" should be non-existent.  I
think that modularizing the FractInt code this way (more so than it already
is) will make expansion easier in the future.  And yes, I realize this is
just as much work as porting it to a new platform.  I propose to attempt
the two at the same time. :)

Well, that's my spiel.  Y'all will almost certainly let me know I'm off my
rocker here. :)  As if my company name didn't say it all...

Damien M. Jones  /  temporary sanity designs  /  http://www.emi.net/~dmj/
   [e-mail]  /  my gallery: http://www.geocities.com/SoHo/Lofts/2605/


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) Greetings
Date: 29 Aug 1997 15:40:01 -0600


In article <[e-mail]> ,
    "Damien M. Jones" <[e-mail]>  writes:
> I personally do not feel that portability in the user interface is
> truly possible; almost all the cross-platform UI libraries I've seen have
> either serious problems or serious limitations.  But, this is just my opinion

I wasn't thinking of a "cross platform library".  But lets back up a
second and take a look at what fractint needs in the terms of a UI.
It needs some file browsing/selection capability, some timer
capability, and the ability to put up dialogs with the following types
of interface items:

    enumeration fields (yes/no, etc.)
    integer value fields
    floating point value fields
    arbitrary precision value fields
    text fields
    scrolling list boxes (for large numbers of items like fractal
    types, IFS names, parameter names, etc.)

Remember that just because you want to cook up an interface that works
well on Win32/X/BeOS/MacOS doesn't mean that you have to write an
interface toolkit that is as complicated as all the features of the
target platforms.  Fractint doesn't really have a complex interface
and providing a few composable basic items for the UI will make it
portable.  Then all the rest of your UI code is completely divorced
from the underlying window system -- be it BeOS, MacOS, Win32 or X.

> BTW, how do you (all) feel about moving FractInt to a C++ base, rather than
> C?

I think this might be a good idea in the long-run, but I don't see any
benefit to doing that AND a window system/UI overhaul at the same
time.  Too much changing too fast.  There is no need to rush off to
C++ just because C++ is all the current rage.
--
  ``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) wishlist page
Date: 29 Aug 1997 18:28:56 -0600

Rich said:

> Looks OK, but at some point you're going to want to edit out most of
> those wishes to pare it down to a useful list :)

Actually, I'd rather capture wishlists on a wb page than via email. I
think this is a good idea. We'd only have to read it from time to
time and extract good ideas to work on.

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) Greetings
Date: 29 Aug 1997 18:28:56 -0600

Rich said:

> I think this might be a good idea in the long-run, but I don't see any
> benefit to doing that AND a window system/UI overhaul at the same
> time.  Too much changing too fast.  There is no need to rush off to
> C++ just because C++ is all the current rage.

There's a lot of disillusionment with C++ here at NASA. Some very
ambitious C++ projects were cancelled. While I'm not sure the heat
C++ has taken in this situation is totally justified (the reality is
usually more complex than simplistic explanations), this did give me
pause for thought.

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) Greetings
Date: 29 Aug 1997 18:28:56 -0600

Damien,

> I want a Win95/NT version of FractInt.  I want it pretty bad.  So bad, in
> fact, that I'm actually likely to *do* something about it. :-)

Great <g!>

> As I've been discussing with Tim, there are a few technical obstacles to a
> Win95 port of FractInt.  The biggest is the switch from a program that
> totally controls the machine to one that must be event-driven.

Bert Tyler already showed that that is not a problem with his early
Windows SDK Winfract. His approach was this. Fractint has a
ubiquitous routine called keypressed() that checks for keystrokes.
Bert put his check for events inside this routine. This worked very
well. Winfract and Fractint shared a great deal of code
effortlessly. Not saying we have to use this strategy, but for
starters it's not bad, and it DID work well for Bert.

> Also, the
> 32-bit environment will require considerable work on the assembly code, I
> suspect.  The good news is that the end result could well be faster than
> DOS FractInt on newer processors, which run 32-bit code *much* better than
> 16-bit stuff.  Losing all that DOS architecture would be another plus.

This is the biggy. Users will *not* accept a slower program, and the
port *will* be slower without the assembler. I'd vote for forgetting
the integer math, since floating point has comparable speed these
days, but giving high priority to incorporating the floating point
assembler, especially the fast parser.

As far as saying goodby to segmented memory models, I won't shed a
tear. The thing is, we're not really free until the program works
well enough that the DOS version is no longer needed. Perhaps we need
to simultaneously port Fractint to djgpp, the DOS extender GNU gcc
environment. This port effort has the same assembler issue. But could
get us to a flat memory model quicker.

> I personally do not feel that portability in the user interface is
> truly possible; almost all the cross-platform UI libraries I've seen have
> either serious problems or serious limitations.  But, this is just my opinion.

Let's not rush to judgement on this. The TK toolkit has been used to
Port Python to a variety of GUI environments, including Windows. I
don't have first hand knowledge of this, but at work there are a
number of Python gurus, and they recommended TK.

Having said this, it may be true that we don't want a portable GUI. I
don't have enough direct experience to say for sure.

I do agree with Rich that our interface needs are relatively modest.

One thing I'm sure of. Sharing code across versions is critical.
Xfract may be a horrible kludge from one port of view, but because it
shares code (however laboriously) with the DOS fractint, it has been
kept up. Many enhancements from Xfract programmers have
enhanced the DOS version, and vice versa. XMFract (Motif port), by
contrast, is an orphan. In this project you can't predict the
continuity of people, so it is important to keep things unified.

> BTW, how do you (all) feel about moving FractInt to a C++ base, rather than
> C?

I'd be very cautious about this. There are places where Fractint
could use C++ (same code used for different data types, such as
arbitrary precision). But there's not necessarily value in porting a
non object oriented program to C++ unless the program is totally
redesigned. Such a redesign would be a "good thing" but we'd never
finish it. Unless an army of new programmers emerges from the
woodwork, I don't favor a massive redesign. I do believe more
incremental restructuring is possible and desirable.

I suggest (not to strongly, just an idea) that a Windows port be done
by first putting the DOS interface in a window a la Xfractint and
Winfract (Bert did this the other way around, he wrote the Windows
interface, then realized he could easily do the text screens in a
window!!!) The a new interface could be built and added.

I plan on getting a compiler and following along with whomever works
on Windows, but at present I know nothing about it. I also maintain
Xfract at present.

My near term development priorities are

1. Synchronous orbits
2. PNG
3. Truecolor

Actually, PNG would be *much* easier in a 32 bit environment. It may
not even be possible with the DOS Fractint unless overlays save us
once again.

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) wishlist page
Date: 29 Aug 1997 18:28:56 -0600


> So what do you think? should I go ahead and open up the fractint
> wishlist page?

Let's think about this a little more. It's a great idea and a great
start, and I appreciate your taking the initiative.

1. We need some quidance about what a "wish" is. I already get a lot
of mail from people with long lists of what they'd like, usually
vague and general. Let me think of something and suggest it to you.
The idea is not to discourage suggestions, but to encourage better,
more specific ones.

2. You added a great personal humorous touch to the page. The one
aspect of that I'd suggest modiying would be to cut the "how folks
are feeling" field in order to keep the page focussed. The reason is
that a diverse lot of folks will access the page; some will
appreciate the humor and some won't. Humor is very tricky in the Web
page and email environments. I've learned to tone my humor down
after reading many redlines from editors :-) If you compare the
fractint docs with my books you'll see a different style.

Let's not do a link to my email from the page yet. The whole idea of
the page is to capture ideas without generating a lot of email.
Perhaps you should say on the page that folks should leave their
wishlist ideas on the page, then join the list <g!>

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: 32bit version of fractint
Date: 29 Aug 1997 17:54:41 -0600


[I'm replying to fractdev, but the original message was on fractint.]

In article <[e-mail]> ,
    "Tim Wegner" <[e-mail]>  writes:
> Perhaps a better solution would be to port to djgpp, the free
> extended DOS GNU compiler. Such a port would still be a DOS
> application, but would have 32 bit memory access.

If this is workable (I know nothing about 16-bit DOS programming and
nearly nothing about djgpp), I'd think this would be a very good first
step while we define the abstract UI/graphics needs of fractint.  I
know lots of you out there are only thinking in terms of Win32/Win95,
but I would like to encourage you to look a little farther out on the
landscape.  I have a very heterogenous environment available to me
both at home and at work and I really, really would like a nice port
of fractint on all of the machines available to me.  I'm obviously
willing to help work on those ports, but my efforts will be stymied if
we program fractint into a Win95/Win32 corner.
--
  ``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) Greetings
Date: 29 Aug 1997 17:44:36 -0600


In article <[e-mail]> ,
    "Tim Wegner" <[e-mail]>  writes:
> I do agree with Rich that our interface needs are relatively modest.

Yes, that's why I think it should be relatively easy to restructure
the code so that supporting a new UI environment shouldn't be that
hard.  You would implement the base UI items that all of fractint's
screens use and then you should be done.  The biggest holdout for the
UI portability is how pixels are written to the screen.  This is
probably the hardest part to get right without compromising fractint's
drawing performance.  On a system like X, for instance, you don't want
to be doing the equivalent of DrawPixel for every single point in the
image.  You probably want to bundle them up and do a bit-blt like
transfer of pixels as an aggregate.  Especially if you want fractint
to be useful with X's inherint networking capabilities.  I'd hope that
we could get a chance to review the existing code and how its
organized and have a discussion of how to evolve that code base to
better support windowing environments before someone just goes off and
hacks something for Win32 without thinking about other systems.  I'm
getting really interested in BeOS now that they have announce a wintel
version coming and I'd hate to have to go an redo all that UI/pixel
drawing code because it was initially done in a shortsighted manner.

I agree with Tim that sharing computation code is a major win, and
xfractint is good in this regard.  However, xfractint is horrible in
the way it has been cobbled together to work under X.  (In fact its
doing all its character display stuff with curses and all its pixel
I/O with X, which leads to an ugly program that is neither a curses
program nor an X program, but hey.... it IS free :).  I think if we
just take a little time and carefully think out fractint's UI and
pixel I/O needs, we should be able to come up with a framework that
can be easily ported to other systems without being too slow.  I
suspected what Tim said in his message about the keypressed()
function.  Yes, checking for events inside there would be a good start
towards making fractint event driven, but it would probably be a good
idea to transform all those routines that are calling keypressed()
into "background work procedures".  The DOS version would then use its
own little "mini event system" to deliver key and mouse events (the
mouse has limited support in fractint) to the appropriate routines,
starting, suspending and aborting "background work procedures"
accordingly.  The implied event loop of fractint is something like
this:

    while (1)
    {
    if (input)
    {
        dispatch_input;
    }
    else if (work_proc)
    {
        work_proc;
    }
    }

However, I don't know how hard it is to put that abstraction into the
existing fractint source base.
--
  ``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) Greetings
Date: 29 Aug 1997 20:58:03 -0400

Rich,

 - I wasn't thinking of a "cross platform library".  But lets back up a
 - second and take a look at what fractint needs in the terms of a UI.
 - It needs some file browsing/selection capability, some timer
 - capability, and the ability to put up dialogs with the following types
 - of interface items:
 -
 -     enumeration fields (yes/no, etc.)
 -     integer value fields
 -     floating point value fields
 -     arbitrary precision value fields
 -     text fields
 -     scrolling list boxes (for large numbers of items like fractal
 -     types, IFS names, parameter names, etc.)

Let's not forget the palette editor.  In general, yes, the FractInt
interface as it is now is not very demanding.  The items you list above are
readily available in just about all GUIs and thus the general UI itself
would port easily, even if the UI code would not.

Part of my background in programming is in making, shall I say, *unusual*
interfaces.  My main concern would be not to restrict the development of
the interface simply to conform to a small set of features that can be
easily programmed on other platforms.  Yes, cross-platform development is
an issue and it needs to be kept in mind.  I would just hate for someone to
tell me a feature/tweak is not appropriate because it can't be ported to
one of the other supported platforms.

Isolating the generation routines from the interface would allow a lot more
flexibility in how the interface was programmed.  I think just about
everyone agrees this particular step is important, regardless of the other
interface issues at hand.

 - > BTW, how do you (all) feel about moving FractInt to a C++ base, rather
 - > than C?
 -
 - I think this might be a good idea in the long-run, but I don't see any
 - benefit to doing that AND a window system/UI overhaul at the same
 - time.  Too much changing too fast.  There is no need to rush off to
 - C++ just because C++ is all the current rage.

My suggestion of C++ has nothing to do with it being all the current rage.
(If I were inclined in that direction, I might have suggested C++ Builder,
Delphi, or Java.)  C++ is hardly new, relative to the speed at which
computer technology evolves.  I think there are plenty of valid reasons to
use C++, mainly because (when used properly) it helps isolate separate
components of a large program and to cleanly re-use portions of code within
a program.  It is not a cure-all, certainly, but I think it would be a big
help.  That is my opinion.  I know it has helped in my own work to organize
and encapsulate code more cleanly.

As to why to do them at the same time, mainly it's because I hate to do
things half-assed.  It just seems self-defeating to me to kludge the 16-bit
C code into a 32-bit environment just to "get it done" and then come back
and alter it again later.  Granted, this would get an initial version out
the door faster, but I know myself enough to know that I would burn out
knowing I had another huge step even after "finishing" the first stage.
Maybe I won't, but maybe I will.

Then again, maybe it isn't such a bad idea.  See my next message to Tim...

Damien M. Jones  /  temporary sanity designs  /  http://www.emi.net/~dmj/
   [e-mail]  /  my gallery: http://www.geocities.com/SoHo/Lofts/2605/


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) Greetings
Date: 29 Aug 1997 21:01:07 -0400

Tim,

 - Bert Tyler already showed that that is not a problem with his early
 - Windows SDK Winfract. His approach was this. Fractint has a
 - ubiquitous routine called keypressed() that checks for keystrokes.
 - Bert put his check for events inside this routine. This worked very
 - well. Winfract and Fractint shared a great deal of code
 - effortlessly. Not saying we have to use this strategy, but for
 - starters it's not bad, and it DID work well for Bert.

Care must be taken not to call the OS too frequently.  Calling the Windows
API isn't exactly the fastest thing in the world.

 - This is the biggy. Users will *not* accept a slower program, and the
 - port *will* be slower without the assembler. I'd vote for forgetting
 - the integer math, since floating point has comparable speed these
 - days, but giving high priority to incorporating the floating point
 - assembler, especially the fast parser.

I'll agree with you here.  It's one reason I have stayed with FractInt,
even though it doesn't always have the features I want.  It's fast.

The M-set and J-set calculations are easy.  I already have assembly
versions of those used in JuliaSaver, which running under Win95 just barely
edge out FractInt running in a DOS box on the same machine, as tested on my
6x86P120+.  FractInt, running in a straight DOS environment (not a DOS
box), on a PPro-200, is not quite twice as fast as FractInt in the DOS box
on the 6x86... but running JuliaSaver's routine in Win95 it wasn't twice as
fast, it was *ten times* as fast.  32-bit code is very, very fast on PPros.
:)  I think I posted this observation a while back in Fractal-Art.

Converting the parser to 32-bit code is another big step.  It may not
require a lot of adjustment, but then again it might.  It all depends.  I
haven't examined the code with a Win32 port in mind.

 - As far as saying goodby to segmented memory models, I won't shed a
 - tear. The thing is, we're not really free until the program works
 - well enough that the DOS version is no longer needed. Perhaps we need
 - to simultaneously port Fractint to djgpp, the DOS extender GNU gcc
 - environment. This port effort has the same assembler issue. But could
 - get us to a flat memory model quicker.

A djgpp port would be the same amount of work on the calculation code as a
Win32 port, but it would not require any real changes to the interface.  I
agree this would be a good step should someone want to take it.  I'd rather
be working on a Win32 interface while somebody does that, though, if
someone is going to do it.

 - Let's not rush to judgement on this. The TK toolkit has been used to
 - Port Python to a variety of GUI environments, including Windows. I
 - don't have first hand knowledge of this, but at work there are a
 - number of Python gurus, and they recommended TK.
 -
 - Having said this, it may be true that we don't want a portable GUI. I
 - don't have enough direct experience to say for sure.

Well, my personal feeling is that other than general UI direction, I'd just
as soon not have the interface programming restricted to a particular
portable GUI library.  No doubt there are some who swear by them.  That is
their option.  I don't particularly care for them.

 - I do agree with Rich that our interface needs are relatively modest.

Yes and no.  They are modest as the interface now stands.

 - One thing I'm sure of. Sharing code across versions is critical.

Absolutely, I totally agree.  The core of FractInt--the calculation code,
the numerous fractal types, parser, etc.--has to be portable or it's
unmaintainable.  As much as possible, the interface should be too, but I'm
not sure restricting the interface to keep it largely portable is a good idea.

 - > BTW, how do you (all) feel about moving FractInt to a C++ base, rather
 - > than C?
 -
 - I'd be very cautious about this. There are places where Fractint
 - could use C++ (same code used for different data types, such as
 - arbitrary precision). But there's not necessarily value in porting a
 - non object oriented program to C++ unless the program is totally
 - redesigned. Such a redesign would be a "good thing" but we'd never
 - finish it. Unless an army of new programmers emerges from the
 - woodwork, I don't favor a massive redesign. I do believe more
 - incremental restructuring is possible and desirable.

Ah.

 - I suggest (not to strongly, just an idea) that a Windows port be done
 - by first putting the DOS interface in a window a la Xfractint and
 - Winfract (Bert did this the other way around, he wrote the Windows
 - interface, then realized he could easily do the text screens in a
 - window!!!) The a new interface could be built and added.

Well, some of the biggest reasons I wanted a Windows version had to do with
the interface. :)  Still, I see your point.  It would actually be pretty
easy to set up a simple graphical window for FractInt to run in, and write
a "driver" that treated that bitmap like a video screen.  Get all the core
code ported and functioning, and then write a new interface that was more
like a Windows program than a DOS program.

I would not want to release the program without the new interface, but I
might change my mind later. :)

 - I plan on getting a compiler and following along with whomever works
 - on Windows, but at present I know nothing about it. I also maintain
 - Xfract at present.

If you've never messed with Windows development, well, it's a huge chunk of
stuff to learn.  If you already know C++, then it's easier if you learn to
do it with MFC (Microsoft Foundation Classes), but knowing the API behind
MFC is kinda important or you'll get stuck in a hurry.

 - My near term development priorities are
 -
 - 1. Synchronous orbits
 - 2. PNG
 - 3. Truecolor

Then I suggest you not worry about the Windows development too much.

 - Actually, PNG would be *much* easier in a 32 bit environment. It may
 - not even be possible with the DOS Fractint unless overlays save us
 - once again.

PNG is one of the formats I have not examined in detail (nor written code
for).  I can see how it would be easier in a 32-bit environment, though.

Damien M. Jones  /  temporary sanity designs  /  http://www.emi.net/~dmj/
   [e-mail]  /  my gallery: http://www.geocities.com/SoHo/Lofts/2605/


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) Greetings
Date: 29 Aug 1997 23:43:20 -0600

Damien said:

> Converting the parser to 32-bit code is another big step.  It may not
> require a lot of adjustment, but then again it might.  It all depends.  I
> haven't examined the code with a Win32 port in mind.

IMHO the parser is the future of fractint. Many of the built-in types
aren't needed.

Unfortunately, the fast parser assembler uses the old MASM style,
and doesn't use the newer high-level directives. This will make it
harder to port to Windows. Maybe we should dive in and try to get
the fast parser assembler to use more current MASM directives.

> If you've never messed with Windows development, well, it's a huge chunk of
> stuff to learn.

Yeah but I want to learn it <g!> Unfortunately, I have yet to
maneuver my career so I did this at work. We shall see if I really do
this, it's hard to tell.

I'd be interested to see what your interface ideas are using Windows.

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) Greetings
Date: 30 Aug 1997 13:30:39 -0400

Tim,

 - IMHO the parser is the future of fractint. Many of the built-in types
 - aren't needed.

If the parser's optimizing compiler were good enough, most of the internal
escape-time types could probably be written as simple formula expressions.
Only in *very* simple types, where hand-optimization in assembly would be a
real benefit, would remain hard-coded.

Also, having most of the types run through the formula parser would make it
easier to add arbitrary-precision support to all these fractals.

 - Unfortunately, the fast parser assembler uses the old MASM style,
 - and doesn't use the newer high-level directives. This will make it
 - harder to port to Windows. Maybe we should dive in and try to get
 - the fast parser assembler to use more current MASM directives.

Um.  Just about all Windows compilers support a pretty complete inline
assembler.  Is it necessary to keep all the assembly in separate .asm files?

 - > If you've never messed with Windows development, well, it's a huge chunk
 - > of stuff to learn.
 -
 - Yeah but I want to learn it <g!> Unfortunately, I have yet to
 - maneuver my career so I did this at work. We shall see if I really do
 - this, it's hard to tell.

Well, a talented programmer can pick up on most of Windows and MFC in a
couple of months.  And it won't take that long to produce a working
program.  A few years back, when I was learning C, I was learning Windows
at the same time... took me about one month to produce a working program.
(Not a good program by today's standards, but it did work.)

 - I'd be interested to see what your interface ideas are using Windows.

I think you've already seen most of them. :)

But first things first.  Today I'm going to try to finish off the image and
image-window classes to handle the graphics display.  I have an older
version which functions, but the newer class is better organized and is
almost done.  Then I'll have to see what I can do about emulating the text
screens.

Damien M. Jones  /  temporary sanity designs  /  http://www.emi.net/~dmj/
   [e-mail]  /  my gallery: http://www.geocities.com/SoHo/Lofts/2605/


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: robin bussell <[e-mail]>
Subject: (fractdev) wishlist page II
Date: 29 Aug 1997 21:05:56 +0100

Hi Tim,

On Friday, August 29, 1997 18:28:56 you wrote:


>
>1. We need some quidance about what a "wish" is. I already get a lot
>of mail from people with long lists of what they'd like, usually
>vague and general.

You're right there, it would be best to emphasise the need for quality
suggestions, a good thing would be to seed the list with some good stuff
to start with... Lee has some, Lee? fancy a job :-)
I'll also point out that the place for *discussions* is the list.


>
>2. You added a great personal humorous touch to the page. The one
>aspect of that I'd suggest modiying would be to cut the "how folks
>are feeling" field in order to keep the page focussed. The reason is
>that a diverse lot of folks will access the page; some will
>appreciate the humor and some won't.

That was just a spur of the moment thing, subverting the 'location'
field used in the guestbook CGI script provided by my ISP, I'll shift it
if you want    ... though part of me wants to tell those who don't
appreciate it to put up with it, it is a free service after all :-)


>Let's not do a link to my email from the page yet. The whole idea of
>the page is to capture ideas without generating a lot of email.

Yep, good point, I'll take that out, those who need to get in touch can
find out
easily enough without my making it *really* easy to pester us :-)

Look out for the MK II version in a day or so, feel free to mail me any
copy you want put up as regards wish definition.

Cheers,
     Robin.

P.S. developers can use the rather handy (and free!) "URL minder" at
www.netmind.com to automatically keep an eye on the list, it will look
at the page every week or so and send an email to those who are
registerd to be informed when it changes.

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) Greetings
Date: 30 Aug 1997 17:45:01 -0600

Damien,

> If the parser's optimizing compiler were good enough, most of the internal
> escape-time types could probably be written as simple formula expressions.

Exactly. I think there's a formula file someone did that has many of
the buily-in types already. Does anyone remember this?

The fast parser has a pretty good optimizer. George Martin and I are
just starting to understand it. Very possibly some of the
optimizations could be done in C also.

> Also, having most of the types run through the formula parser would make it
> easier to add arbitrary-precision support to all these fractals.

Having the parser support arbitrary precision would be a great goal.
Right now we support arbitrary precision with only a few built-in
types, basically generalized classic mandelbrot and julia. However
I'm going to attempt porting synchronous to arbitrary precision first
(right away as a matter of fact). SO is a natural for arbitrary
precision, since it becomes effective only at very high
magnifications. I can't wait to see how SOI will do at magnifications
like 10^500!!

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) wishlist page II
Date: 30 Aug 1997 17:45:01 -0600

>... though part of me wants to tell those who don't
> appreciate it to put up with it, it is a free service after all :-)

I don't want to dampen your enthusiasm. If you want to keep the "how
you are feeling" field, then I suggest you call the page the "Robin
Bussell Fantastic Fractint Wish List Page" or something similar,
because that whimsical touch is part and parcel your unique (and
appreciated) style. But if you are anonymous, and it's a Stone
Soup Page, then I think it would be better to leave that field off.

In either case if this is a permanent page we can refer to it in
Fractint and ask Noel to add a link to it from spanky.triumf.ca.

> Look out for the MK II version in a day or so, feel free to mail me any
> copy you want put up as regards wish definition.

Looking forward to it, and thanks again!

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) Greetings
Date: 30 Aug 1997 19:17:38 EDT

Tim,

>
Exactly. I think there's a formula file someone did that has many of
the buily-in types already. Does anyone remember this?
<

There were collected in files with the names builtn.frm, builtn01.frm, and
builtn2.frm. All are included in the Orgform files.

You can reconstruct (sort of) a formula file that is included in the compilation
by using the /r switch. For example

    orgform builtn.frm /r

will produce a file called reconstr.frm which will have all the formulas in the
compilation that identify builtn.frm as the source file. This, unfortunately,
may not include all of the formulas in the original file, because some formulas
may have been skipped if they were included in the compilation earlier from
another source.

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: "Tim Wegner" <[e-mail]>
Subject: (fractdev) array initializations
Date: 31 Aug 1997 14:30:29 -0600

In prompts2.c, there's the declaration

static char *calcmodes[] = {"1","2", ... };

If the "static" is removed, this still works OK under Microsoft C and
Linux's gcc. Is this type of array initialization legal under ANSI C?

I realize there are manny non-ANSi compilers out there. However, I
don't think we should worry about pre-ANSI compilers. Changing that
declaration saves some precious near memory in the DOS version.

Anyone know what the ANSI C standard says about array initialization
of local variables? (I've got the ANSI K&R at work and will look, but
at homew I have the earliewr K&R.)

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"