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

Internet Message Format | 1998-12-20 | 162KB

From: "Tim Wegner" <[e-mail]>
Subject: (fractdev) Welcome Humberto
Date: 01 Dec 1998 22:16:08 -0600

Welcome to Humberto Baptista! I see you joined the list.

I haven't been able to run my version compiled with Borland 5
(complains about not enough memory) although I believe earlier
Borland compilers work. I'll have to reinstall my old Borland 3.1.
Microsoft C/C++ 7 works the best.

I will be uploading the developer's source for the DOS and Linux
versions of Fractint to my FTP site in a few days. No need to
check site, I'll alert folks first.

We may begin releasing some developer version executable to the
public, but we have to decide details first. We could discuss this
here if you like. One concern would be to include a readme stating
that the package could only be posted in a few designated places
(e.g. spanky). The reason for this is that developer's versions last
about a week typically (though we likely wouldn't release every tiny
change to the public) and we don't want Fractint put places where
it won't be updated.

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: Humberto Rossetti Baptista <[e-mail]>
Subject: Re: (fractdev) Welcome Humberto
Date: 02 Dec 1998 13:08:31 -0200 (EDT)

On Tue, 1 Dec 1998, Tim Wegner wrote:

> Welcome to Humberto Baptista! I see you joined the list.

    Hello all in the list

> I haven't been able to run my version compiled with Borland 5
> (complains about not enough memory) although I believe earlier
> Borland compilers work. I'll have to reinstall my old Borland 3.1.
> Microsoft C/C++ 7 works the best.

    I'm compiling fine with BC 3.1 (or 3.0) although after some patching and
modifing I noticed that the arbitray precision code locks up the machine. I
guess it is some overlay pushed (or pulled) beyond som bounday. As I do not know
the overlay scheme used very well now I cannot say for sure.

> I will be uploading the developer's source for the DOS and Linux
> versions of Fractint to my FTP site in a few days. No need to
> check site, I'll alert folks first.

    OK, what would be best to post the patches or to send them directly to
[e-mail]?

> We may begin releasing some developer version executable to the
> public, but we have to decide details first. We could discuss this
> here if you like. One concern would be to include a readme stating

    Yes I would like to discuss it and my tow inital cents are: place it in
one or two sites (like spanky and some friendly mirros) and allow the
download via HTTP only. A prety clear statement that it is beta code would
surely be better understood if on the download page that in some README that is
not alway read.

> change to the public) and we don't want Fractint put places where
> it won't be updated.

    Agreed.

    []'s

    Humberto R. Baptista
    [e-mail]

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


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


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

From: [e-mail]
Subject: RE: (fractdev) Welcome Humberto
Date: 02 Dec 1998 17:46 0000

Hi Tim & Humberto,

>We may begin releasing some developer version executable to the
>public, but we have to decide details first. We could discuss this
>here if you like.

I'm gane! How about tentatively suggesting a christmas or new year
rrelease for public beta code? seems like a handy date in the not too
near, not too distant future.


>One concern would be to include a readme stating
>that the package could only be posted in a few designated places
>(e.g. spanky).

I can host stuff at ukonline as usual for the european side of things.

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: "Damien M. Jones" <[e-mail]>
Subject: RE: (fractdev) Welcome Humberto
Date: 02 Dec 1998 12:42:26 -0600

 - >One concern would be to include a readme stating
 - >that the package could only be posted in a few designated places
 - >(e.g. spanky).
 -
 - I can host stuff at ukonline as usual for the european side of things.

ftp.fractalus.com is also available, if you want me to include the files
there.

Damien M. Jones   \\
[e-mail]  \\  Fractalus Galleries & Info:
                    \\  http://www.fractalus.com/

Please do not post my e-mail address on a web site or
in a newsgroup.  Thank you.

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: Humberto Rossetti Baptista <[e-mail]>
Subject: (fractdev) Idea of beta release date and way tomirror betas (was: RE: Welcome
Date: 02 Dec 1998 17:31:21 -0200 (EDT)

On Wed, 2 Dec 1998 [e-mail] wrote:

> I'm gane! How about tentatively suggesting a christmas or new year
> rrelease for public beta code? seems like a handy date in the not too
> near, not too distant future.

    That's a very nice idea, most of the usersI talk to are feeling
"abandoned" by the development of Fractint.

> I can host stuff at ukonline as usual for the european side of things.

    I can also host it here for Latin America/Brasil access.

    []'s

    Humberto R. Baptista
    [e-mail]

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


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


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

From: Humberto Rossetti Baptista <[e-mail]>
Subject: (fractdev) Worklist and future directions
Date: 02 Dec 1998 17:35:33 -0200 (EDT)


    Hi,

    As I'm new I would like to ask the list about what are the current
worklines (to avoid doing things twice and messing with others work).

    Other thing that I have been thinking for some time now. Should we think
of a 32 bit version of fractint?

    Yes i know lot of people like to use fractint on 16 bit machines, but
the root of fractint were speed, speed and speed :-) and although we have LOTS
of stuff there it still is _very_ fast. I keep wondering if the development wete
on a flat memory space and 32 bit mode things could go a lot faster and less
troublesome.

    Any ideas/experiences/thoughts?

    []'s

    Humberto R. Baptista
    [e-mail]

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


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


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

From: Tim Gilman <[e-mail]>
Subject: Re: (fractdev) Worklist and future directions
Date: 02 Dec 1998 12:03:03 -0800

Hello there!

I'll pipe up and describe what I'm up to, as I'm sort of working in
isolation.  I'm working on a Mac port of Fractint.  It's coming together
slowly; I've got fractals drawing to the screen, most of the built-in
fractal types display correctly, zooming works, option-screens in the
form of dialogs, etc.  The biggies left for me are file-parsing (PARs
FRMs MAPs), palette editing, and general UI cleanup.  I'm currently
working on getting color-cycling to work in-a-window with monitor-depths
set to greater than 8 bit.

I say I'm working in isolation 'cause I've been mangling the xfract
source base to get most the scaffolding work done.  That, and I'm mostly
writing Mac-specific code which doesn't really affect the underlying
engine.  There's some places where I've had to do some minor surgery, but
merging those parts back into the xfract base won't be too much of a
chore (I'll eat those words!).

Future directions?  I vote for a cleaner layer of abstraction seperating
Fractint from platform/gui.  POV-Ray is my inspiration!

2 cents in the Soup,
Tim Gilman
[e-mail]
http://www.scruz.net/~tgilman/tim/macfract/


>    Hi,
>
>    As I'm new I would like to ask the list about what are the current
>worklines (to avoid doing things twice and messing with others work).
>
>    Other thing that I have been thinking for some time now. Should we think
>of a 32 bit version of fractint?
>
>    Yes i know lot of people like to use fractint on 16 bit machines, but
>the root of fractint were speed, speed and speed :-) and although we have
>LOTS
>of stuff there it still is _very_ fast. I keep wondering if the
>development wete
>on a flat memory space and 32 bit mode things could go a lot faster and less
>troublesome.
>
>    Any ideas/experiences/thoughts?
>
>    []'s
>
>    Humberto R. Baptista
>    [e-mail]
>
>---------------------------------------------------------------------------
>Insite - Solucoes Internet                         http://www.insite.com.br
>
>
>--------------------------------------------------------------

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


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

From: [e-mail] (Kragen)
Subject: Re: (fractdev) Worklist and future directions
Date: 02 Dec 1998 17:00:38 -0500 (EST)

On Wed, 2 Dec 1998, Humberto Rossetti Baptista wrote:
>     Other thing that I have been thinking for some time now. Should we think
> of a 32 bit version of fractint?

xfractint is 32-bit on 32-bit machines, and 64-bit on 64-bit machines.

--
<[e-mail]>       Kragen Sitaker     <http://www.pobox.com/~kragen/>
It frightens the daylights out of me whenever I hear people proclaim that
the less knowledge our children have access to, the better.
-- Duane Lindstrom, at <URL:http://www.examiner.com/skink/skinkmail.html>


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: Humberto Rossetti Baptista <[e-mail]>
Subject: Re: (fractdev) Worklist and future directions
Date: 02 Dec 1998 20:17:14 -0200 (EDT)

On Wed, 2 Dec 1998, Kragen wrote:

> On Wed, 2 Dec 1998, Humberto Rossetti Baptista wrote:
> >     Other thing that I have been thinking for some time now. Should we think
> > of a 32 bit version of fractint?
>
> xfractint is 32-bit on 32-bit machines, and 64-bit on 64-bit machines.

    I meant to have a common base on the DOS version that is 32 bit without
the memory constraints and optimized to take advantage of the operations in 32
bits. The source in the DOS version is somewhat far from this, but seeing the
work done on xfract maybe not so far.

    []'s

    Humberto R. Baptista
    [e-mail]

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


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


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

From: [e-mail]
Subject: RE: (fractdev) Worklist and future directions
Date: 02 Dec 1998 22:35 0000

Hi Humberto,


>    As I'm new I would like to ask the list about what are the current
>worklines (to avoid doing things twice and messing with others work).

I'm currently puttng better sound support in, and generally fiddle about
with uncomplicated interface issues :-)

>    Other thing that I have been thinking for some time now. Should
>we think
>of a 32 bit version of fractint?

Definately, though first would come the interface/ calculation engine
abstraction.... in fact we should really be aiming for 'portable' rather
than '32 bit' IMHO
It would be really nice to adopt one of the open devlopment platforms
available these days.

.... not that I lay any claim to knowing how to go about it of course  :-)

>on a flat memory space and 32 bit mode things could go a lot faster
>and less
>troublesome.

Flat memory space would be soooooo nice!

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: "Tim Wegner" <[e-mail]>
Subject: Re: (fractdev) Worklist and future directions
Date: 03 Dec 1998 00:31:24 -0600

Kragen wrote:

> xfractint is 32-bit on 32-bit machines, and 64-bit on 64-bit machines.

Yes, but because Fractint and Xfractint share sources, Fractint
holds Xfractint back. Once Fractint itself is 32 bits, then we can
start taking advantage of it in both programs.

Tim


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


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

From: "Tim Wegner" <[e-mail]>
Subject: RE: (fractdev) Welcome Humberto
Date: 03 Dec 1998 00:31:24 -0600

Hi Robin! I see you have a new identity!

> I'm gane! How about tentatively suggesting a christmas or new year
> rrelease for public beta code? seems like a handy date in the not too
> near, not too distant future.

It just depends on the team being ready. But I have many fewer
reservations about publishing the public *source*, it is a bigger deal
to publisg the beta *executable*. I have had beta source at my FTP
site for a long time, but I hadn't kept it up because no one here in
fracvtdev asked for it.

> I can host stuff at ukonline as usual for the european side of things.

If we post a beta executable, I think spanky and your site would be
sufficient.

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) Worklist and future directions
Date: 03 Dec 1998 00:31:24 -0600

Tim Gilman wrote:

> Future directions?  I vote for a cleaner layer of abstraction seperating
> Fractint from platform/gui.

You are welcome to propose changes. But it will be hard if you
have had to change the code to extensively. What made the
Xfractint port work was that much of  the code sources are exactly
shared. But I am not telling you that is what you should do
because you have different goals.

When we finally get people working seriously in 32 bit
environments the first order of business will be separating out the
platform sprecific code. Then the platform independent part of the
code could evolve faster because more people could contribute.

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) Worklist and future directions
Date: 03 Dec 1998 00:31:24 -0600

>     As I'm new I would like to ask the list about what are the current
> worklines (to avoid doing things twice and messing with others work).

When you see the beta source you will see. Robin Bussell has
added an "evolver" feature that perturbs parameters as well as
sound (we need the sound ported to Linux!). George Martin has
been overhauling the parser. Chuck Ebbert has been speeding up
the parser. Jonathan Osuch has been facilitating all the above and
done more changes than I can remember. The "what's new" gives
the whole patch by patch history. I have added synchronous orbits,
but feel like it is fairly worthless unless ported to 32 bits. Which
brings us to ...

>     Other thing that I have been thinking for some time now. Should we think
> of a 32 bit version of fractint?

We've been *thinking* a whole lot. You need to understand that
some of the developers have intgense professional lives, and
speaking for myself, I'm not expanding my programming  skill at
work because I do mostly project management (seniority has its
pitfalls). I have few hours outside of work and a daunting learning
curve. There are dozens of routes to porting to 32 bits, we've
discussed them a lot. I'm tired of discussing it, because words are
cheap. What is needed are skilled people with the proper expertise
willing to put in several thousand hours, not people who write on
Robin's wish list "port to 32 bits please" <grin!>

I have bought Visual C/C++ 5 and Borland C++ Builder 3. But I
have a big learning curve ahead of me before I can be productive,
and limited outside of worktime. We could also port to djgpp. Any
approach we take will take a huge performance hit until we port at
least some of the assembler. But we could get something up and
running based on the Xfractint ciode, which I have been keeping up.
I also have been maintaing a version withg the integer math taken
out.

>> I keep wondering if the development wete
> on a flat memory space and 32 bit mode things could go a lot faster and less
> troublesome.

A flat memory model is an absolute necessity. But don't expect
speed at first.

Tim


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


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

From: "Tim Wegner" <[e-mail]>
Subject: Re: (fractdev) Welcome Humberto
Date: 03 Dec 1998 00:31:24 -0600

Humberto asked:

> OK, what would be best to post the patches or to send
>them directly to
> [e-mail]?

I'd rather get them directly. But it would be better to wait until you
get the latest version which I will upload shortly (by Saturday). We
are up to 19.61 patch 58! I could probably merge your patches
relative to an older version but I'd much prefer if you are working off
the same version we are.

>     Yes I would like to discuss it and my tow inital cents are: place it in
> one or two sites (like spanky and some friendly mirros) and allow the
> download via HTTP only. A prety clear statement that it is beta code would
> surely be better understood if on the download page that in some README that is
> not alway read.

Good suggestion. Also, it is very good to hear from  you, it has
been a few years!

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] (F.J. Slijkerman)
Subject: Re: (fractdev) Worklist and future directions
Date: 03 Dec 1998 14:46:37 +0100 (MET)

Tim,

> I have bought Visual C/C++ 5 and Borland C++ Builder 3. But I
> have a big learning curve ahead of me before I can be productive,
> and limited outside of worktime.

Sorry for the intrusion, but maybe you'll appreciate some of my
thoughts about this. If you feel you have little time and lots of
work to do, I would recommend C++ Builder because it's much easier
to use than Visual C, and it's cheaper so more developers can buy
their copy (at least the Standard version!). I don't know about
its portability though.

If you are going to create a true 32-bit Windows version, you
more or less have to make the fractal engine an "object" so you
can create more than one instance of the engine. This is necessary
for MDI and probably multi-threading. Also, it helps a lot to keep
the code clean and easy to understand.

Since the current Fractint code is 16-bit and single-document-based
(iow: uses lots of global variables), I'd recommend you to dump it
(well, as a matter of speaking) and starting from scratch. You can
of course probably use large chunks of code from the old Fractint,
but you'll have to abandon the structure of the code, I think, and
use a modern object-oriented approach (which C++ Builder almost
demands).

It may seem silly or a waste of time to start again, but as a
project manager you will know that developing new projects from
scratch is much easier than poking around in old code and rewriting
it -- and in the end it takes much less time, too. Plus you have
the ability to separate the GUI code and the fractal engine.

Just my $0.02...

Best regards,
Frederik.

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: Humberto Rossetti Baptista <[e-mail]>
Subject: Re: (fractdev) Worklist and future directions
Date: 03 Dec 1998 12:21:30 -0200 (EDT)

On Thu, 3 Dec 1998, Tim Wegner wrote:

> When you see the beta source you will see. Robin Bussell has
> added an "evolver" feature that perturbs parameters as well as

    Great, if I it is what I imagine, one less item on my personal worklist
:-))))

> sound (we need the sound ported to Linux!). George Martin has

    Sound and linux, hm.

> been overhauling the parser. Chuck Ebbert has been speeding up
> the parser.

    Anybody thinking in extending the parser to deal with orbit-like
fractals? If not I'll get the hang of what's going on around the parser and will
do something on this direction soon.

> Jonathan Osuch has been facilitating all the above and
> done more changes than I can remember. The "what's new" gives
> the whole patch by patch history.

    My saturday seems SO far :-)))

> I have added synchronous orbits,

    ? What are these ?

> >     Other thing that I have been thinking for some time now. Should we think
> > of a 32 bit version of fractint?
>
> We've been *thinking* a whole lot. You need to understand that
> some of the developers have intgense professional lives, and

    I never underestimated this (I run a little consulting firm myself
working quite a lot, and unfortunatedly my development time is rather short
also). Please if i sounded like demanding it was due to my "not-so-good"
english. I love the work you've been doing in Fractint and do not want to see
such a nice thing interfere negatively with anybody's live.

> speaking for myself, I'm not expanding my programming  skill at
> work because I do mostly project management (seniority has its
> pitfalls).

    I bet you're not the only one :-)))

> I have few hours outside of work and a daunting learning
> curve. There are dozens of routes to porting to 32 bits, we've
> discussed them a lot. I'm tired of discussing it, because words are
> cheap.

    Sorry to have brought this again, as I'm a newbie to the dev I prefer to
be more annoying in the star to understand the work and the blend in without
getting us all to "old" and "worn" points.

> What is needed are skilled people with the proper expertise
> willing to put in several thousand hours, not people who write on
> Robin's wish list "port to 32 bits please" <grin!>

    Agreed, I may be able to find one or two good coders to help with this
(some students that have made arcade games both in DOS and Linux with gcc and
djgcc) Does the list have a archive that can be searched? Or better does anyone
have a list of the main dificulties involved on 32 bit ports or maybe a djgcc
port?

> I have bought Visual C/C++ 5 and Borland C++ Builder 3. But I
> have a big learning curve ahead of me before I can be productive,
> and limited outside of worktime.

    :-( Me too.

> We could also port to djgpp. Any
> approach we take will take a huge performance hit until we port at
> least some of the assembler.

    yes. I guess that will be the worst part.

> But we could get something up and
> running based on the Xfractint ciode, which I have been keeping up.

    Yes.

> >> I keep wondering if the development wete
> > on a flat memory space and 32 bit mode things could go a lot faster and less
> > troublesome.
>
> A flat memory model is an absolute necessity. But don't expect
> speed at first.

    Yes. I was thinking only in terms of facilitating other people to put
their peebles in the soup :-) That is why i like so much of the suggetion made
previously in the list to use opens source tools to the job.

    []'s

    Humberto R. Baptista
    [e-mail]

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


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


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

From: Humberto Rossetti Baptista <[e-mail]>
Subject: Re: (fractdev) Welcome Humberto
Date: 03 Dec 1998 12:25:28 -0200 (EDT)

On Thu, 3 Dec 1998, Tim Wegner wrote:

> I'd rather get them directly. But it would be better to wait until you
> get the latest version which I will upload shortly (by Saturday). We
> are up to 19.61 patch 58!

    No problem (just holding my anxiety :-))))))

> Good suggestion. Also, it is very good to hear from  you, it has
> been a few years!

    Glad you remembered. Ah, BTW I've been doing a kind of HOWTO to help me
to create new built in formulas and I hope to produce some other documents like
this, I know it is not the main trend with such a fast parser ;-> but we could
have a little library of short tutorials to help newcommers code in faster.

    I'll post it to the list sometime in these days (they're not long).

    []'s

    Humberto R. Baptista
    [e-mail]

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


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


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

From: Humberto Rossetti Baptista <[e-mail]>
Subject: Re: (fractdev) Worklist and future directions
Date: 03 Dec 1998 12:29:43 -0200 (EDT)


    Getting the drift of Frederik and Robin I'd like to ask if the
abstraction/port to C++ / isolation of platform specific features have been
discussed here a lot or not?

    I kept thinking on OO structures reading the code, and I REALLY would
like to create a arithmetic class to deal w/ all the numeric engines FRINT
has:-)))

    more 2c (is this a stone soup or a cent soup :>>>> )

    []'s


    Humberto R. Baptista
    [e-mail]

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



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


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

From: [e-mail] (F.J. Slijkerman)
Subject: Re: (fractdev) Worklist and future directions
Date: 03 Dec 1998 15:45:57 +0100 (MET)

Humberto,

>
>     Getting the drift of Frederik and Robin I'd like to ask if the
> abstraction/port to C++ / isolation of platform specific features have been
> discussed here a lot or not?
>

I believe the general attitude of the Fractint development
team so far has been to port the code in its current form
instead of rewriting it using OOP technology.

Best regards,
Frederik.

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: Re: (fractdev) Welcome Humberto
Date: 03 Dec 1998 21:23 0000

>    Glad you remembered. Ah, BTW I've been doing a kind of
>HOWTO to help me
>to create new built in formulas and I hope to produce some other
>documents like
>this

Good idea! it's the initial getting used to the layout  of things that is the
worst every time I get back to fractint after a break of a few weeks or
more.

Cheers,
         Robinn





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) Beta
Date: 03 Dec 1998 20:12 0000



>Hi Robin! I see you have a new identity!

Oh yes, sorry, I forgot to mention that, they closed my account at
Lucent without warning (fair enough as I don't work there at the
moment)  and I think I've tied off all loose ends so far :-)
I still have [e-mail] too, but that's for other mailing
lists.

> I have many fewer
>reservations about publishing the public *source*, it is a bigger deal
>to publisg the beta *executable*.

It might ease the support burden if I set up another list lke the wishlist
for bug reports, that way there should a lot less duplication of reports,
and no one get's deluged with mail!
It would also be easy to provide a standardised form for bug reports so
that details such as machine type, video card, cpu, OS,  and all the other
things that are usually needed.

I've got some time off work next week so I'll knuckle down and get my
stuff more finished with docs etc.

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: RE: Re: (fractdev) Worklist and future directions
Date: 03 Dec 1998 20:52 0000


>> When you see the beta source you will see. Robin Bussell has
>> added an "evolver" feature that perturbs parameters as well as

>    Great, if I it is what I imagine, one less item on my personal
>worklist
>:-))))

Glad you like the sound of that! I'd be interested to hear how your
vision of a fractal evolver differs from my implimentation.... so that the
best  bits can be incorporated of course :-)



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: RE: Re: (fractdev) Worklist and future directions
Date: 03 Dec 1998 20:52 0000


>> When you see the beta source you will see. Robin Bussell has
>> added an "evolver" feature that perturbs parameters as well as

>    Great, if I it is what I imagine, one less item on my personal
>worklist
>:-))))

Glad you like the sound of that! I'd be interested to hear how your
vision of a fractal evolver differs from my implimentation.... so that the
best  bits can be incorporated of course :-)



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: Phil McRevis <[e-mail]>
Subject: Re: (fractdev) Worklist and future directions
Date: 03 Dec 1998 16:26:26 -0700


In article <[e-mail]>,
    Tim Gilman <[e-mail]>  writes:
> Future directions?  I vote for a cleaner layer of abstraction seperating
> Fractint from platform/gui.  POV-Ray is my inspiration!

What's POV-Ray's abstraction?  Looking though the fractint code, as
well as the xfractint code, I suggested earlier division along the
lines of some simple routines to handle dialogs from some new
structures, some simple text scrolling window routines for the help
file browsing and a graphics window I/O set for setpixel, etc.  These
are all easy to add to the existing code.  The big chore in separating
the last bit of UI from the code is to move to an event-oriented model
of input rather than polling.  Currently polling of the keyboard to
abort an operation in progress is sprinkled liberally throughout the
code.  I think xfractint has a hack to get around this and process the
message queue, but its just a hack.  The code should be reorganized to
handle the message-queue input model.

On the subject of 32-bitness, I beliee Tim was working on an
incremental change to use a DOS 32-bit extender and eliminate the
16-bit specific assembly.  I'm not sure what the status of that is
right now.  Tim?

I'm currently spending my free time working on other programming
projects, but I did manage to put together a "to do" list for
fractint's growth.  There is also a web page maintained by a list
member (I'm sorry, I've forgotten who!) that contains a "wish list" of
items from users.  Periodically that wish list is culled down to
a reasonable list of "demands" :) and posted here to this list.

                    -- Rich

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: Phil McRevis <[e-mail]>
Subject: (fractdev) project list
Date: 03 Dec 1998 16:27:42 -0700

This file attempts to list the works "in progress" at the time of the
current fractint release (19.6) and the people working on them.  It is
hoped that this file will help developers coordinate their efforts and
eliminate any duplicate effort.

This file last updated January 29th, 1998

Project(s)                              Developer & Status
PNG support                             TW
24-bit support                          RBa, TW, others? (just starting)
SIMPLGIF improvements                   TW (encoder done, decoder needed)
GIF encoder fix                         TW (done)
Relaxing 2K image sizelimit             TW (nearly done)
float-only version                      TW (mostly done)
synchronous orbits                      TW (under way)
Formula parser improvements:
  C optimizer                           GM (under way)
xfractint visual selection              RT
Parameter Evolver                       RBu, JO (mostly done)
Memory use overhaul                     JO
Pentium M-set assembly optimization     DJ (approx. 1/2 done)

Current Developers:
-------------------
RBa     Ron Barnett <[e-mail]>
        Win95/DOS (MS VC++ 1.52, MASM 6.0, MS VC++ 5.0)
RBu     Robin Bussell <[e-mail]>
DJ      Damien M. Jones <[e-mail]>
GM      George Martin <[e-mail]>
        Win95/DOS (Borland 3.1)
JO      Jonathan Osuch <[e-mail]>
RT      Rich Thomson <[e-mail]>
        Win95/DOS (Borland C++ Builder 1.0, 3.0), Solaris (unix/gcc)
TW      Tim Wegner <[e-mail]>
        Win95/DOS (MSC 7.0, MASM 6.1, djgpp), linux (gcc)

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: Phil McRevis <[e-mail]>
Subject: (fractdev) to do list
Date: 03 Dec 1998 16:28:18 -0700

This file contains a list of things that are on the "To Do" list of
the fractint development team, practiced in the true Stone Soup
tradition.  Any item on this list is up for grabs and you are
encouraged to use this as a starting point for your fractint
contributions!

This document is arranged by the functional area within fractint.  The
functional areas are listed in alphabetical order with each idea
that's been suggested for improving the various sections.

This file last updated March 20th, 1998

3D Support
----------
- Provide a way to plug-in a 3D driver by name; platform support
  determines what drivers are available.  Fractint "native" 3D support
  available on all platforms.
- Add arcball for iteractive manipulation of 3D viewing parameters
  (interactively manipulate viewed object by its bounding box)

Arbitrary Precision
-------------------
- Extend arbitrary precision arithmetic to other fractal types, most
  notably formula types
- Allow arbitrary precision values to be entered into text field boxes
  and PAR files

Deep Color Support
------------------
- 24-bit color modes
- 32-bit color modes (RGB plus alpha)
- PNG 24/32-bit output/input
- Coloring pixels by formulas
- Texture mapping (probably best integrated into formula coloring)

Formula Parser
--------------
- Add type information for expressions and variables
- Add remainder (modulus) operator/function
- Make C versions of corresponding assembly functions more efficient
  (reduce function call overhead, apply optimizations)
- Provide a way to perform user-defined computations once per-image
- Provide a way to define and call named user functions like regular
  functions

Fractal Types
-------------
- Add 2D cellular automata
- Add continuously valued automata, a la CAPOW
- Various 3D fractal types that could be added
- Volume rendered fractal types (3D projection of quaternion julia set)

Fractal Types: Cellular
-------------
- Extend 1D cellular automata types beyond existing totalistic automata

Help Files
----------
- Add formula tutorial
- Add formula coloring methods tutorial
- Add color editor tutorial
- Add support to the help compiler for generating postscript / PDF /
  HTML output.
- Add support for inlined images in help browser (initially present
  only in PS/PDF/HTML versions)

Image Computation
-----------------
- Provide anti-aliasing support directly (requires deep color)
- Synchronous Orbits Iteration

Image I/O
---------
- Provide PNG support for both 8-bit and deeper video modes; handle
  gamma correction properly on output

Platform Support
----------------
- Create "fractint GUI API" that abstracts out fractint's ideas of
  dialogs, text boxes, number boxes, keyboard navigation of dialogs,
  etc., so that ports to other windowing systems are more readily
  accomplished from the same body of source code a la xfractint/fractint
  as opposed to the completely native port of winfract (which lags);
  this will abstract out the interface from the computation engine,
  which enhances portablity (something fractint sorely lacks) to other
  platforms and also makes it easy to reuse fractint's compute engine.
- Support for generalizing the assembly code to other architectures
  such as 68k, MIPS, etc., by segregating assembly code into
  architecture specific directories and integrating xfractint C
  emulation of assembly routines for all other architectures.
- Support "video modes" by name/number/capability rather than by
  function key assignment.  Since video modes vary by platform, and
  even on the same platform they can vary from user to user, a way of
  specifying the video mode in terms of its capability is needed.
  Something like video=x-res/y-res/depth, i.e. video=640/480/8.  In a
  windowed environment, the video "mode" is used to guide window size,
  palette emulation, etc.

Platform Support: DOS
---------------------
- Eliminate overlays / move to 32-bit flat address space DOS protected
  mode app (gives up 286 support)
- Option for displaying dialogs and text screens in graphics video
  mode with image save/restore; eliminates switching back and forth
  from text mode to graphics mode, saving wear and tear on monitors
- port code to DOS version of "fractint GUI API"
- Improve performance of native DOS 3D driver
- Compute an image larger than the screen resolution and allow panning
  through the larger image by the screen.

Platform Support: Win95/NT
--------------------------
- Win32 port
- long filename problems?
- DirectX support?
- 3D drivers: Direct3D / OpenGL
- animation support? (AVI, MPEG, etc.)

Platform Support: unix/X
------------------------
- Visual selection assumed root is 8-bit psuedocolor; improve to
  select appropriate visual for requested video mode (could be 24-bit
  with deep color support)
- Eliminate use of curses and xterm in favor of native X-based text
  windows
- Fix function key support (probably a free side-effect of previous item)
- Use Xt for interface components of "fractint GUI API"
- 3D drivers: OpenGL, PEX, native X
- Generate /bin/sh scripts instead of MS-DOS bat files for "b" command
- long filename problems?

Platform Support: Mac/Amiga/BeOS/NeXT/other
- Someone needs to do the port! :)

Zoom Box
--------
- Use XaoS like techniques to speedup the zoom box and/or initialize
  the screen from the zoomed section.


Delivery-Date: Mon, 16 Mar 1998 15:43:22 -0700
Received: from dbank (dbank.ptc.com [199.6.17.9]) by woody (950413.SGI.8.6.12/950213.SGI.AUTOCF) via SMTP id PAA27065 for <rthomson@woody>; Mon, 16 Mar 1998 15:43:21 -0700
Received: from poster (poster.ptc.com) by dbank (5.x/SMI-SVR4)
    id AA13391; Mon, 16 Mar 1998 15:43:09 -0700
Received: from Erich.Triumf.CA by poster (5.x/SMI-SVR4-NN)
    id AA28994; Mon, 16 Mar 1998 17:43:06 -0500
Received: by triumf.ca (MX V4.0-1 VAX) id 187; Mon, 16 Mar 1998 14:34:51 PST
Message-Id: <[e-mail]>

Hi Rich,
You wrote:

> Noel, one of the things I've been considering adding to fractint is
> support for HTML output directly from fractint's "help compiler".  I
> suspected that you manually created the HTML (probably with the help
> of some simple text processing scripts) from fractint's help files or
> the fractint text documentation.  I like the no-nonsense style of your
> web version of the fractint docs.  If you have any suggestions or
> know of any 'gotchas' you learned while converting the docs to HTML,
> I'd be happy to hear them.  Unlike many fractint 'developer projects',
> this is one I could actually do rather quickly since the help compiler
> is a rather small program and doesn't suffer from all the overlay and
> memory contortions of fractint.


    I've certainly had some thoughts about what I would have done
differently had I been starting fresh.

    The first thing I would do is establish some sort of perl
script or similar text processor to parse the complete document
and substitute any angle brackets, quote characters, ampersands etc,
with the accepted strings. Anything that means something in html
should be replaced. Do that before you break anything into small files
or add any real html code.

    Then I would come up with a mechanism to parse for internal
page references and translate them into an internal url. This would
imply that you have some sort of algorithm established for a file
naming convention. This is also a very good idea on its own. I
broke all the docs up into small files to take the load off the
server, but I named all the docfiles somewhat arbitrarily, so
consiquently I have to make all the links by hand. I don't know
what you should use as a criteria for file breaks. Chapter headings
is to coarse.

    I've also set a convention that equations and formulae
get displayed in a different text. I use the <pre> </pre> html
for this. I think it is very useful. I don't know how you could
set up a parser to know what is a formula or an equation unless
you inserted some invisible tag in the docs.

    Maybe there is a way with a cgi-script to do all this on the
fly and create an html file from sections of the main document.
Then you could allow the cgi to do searches as well and produce an
index on the search results and allow the user to select a page
from the search results, pass it back to the cgi-script and build
the requested page.

    I'm sure that there are a lot more things that I haven't
thought about, and I'll pass them along to you as they occur to me.
I think your idea for fractint to create it's own web docs is a good
idea. Use any images you want off my pages if you think they are
worth adding. Perhaps the little thumbnails of all the fractint
fractal types could be inserted.

    Cheers,
    Noel

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: Phil McRevis <[e-mail]>
Subject: (fractdev) Re: source code
Date: 03 Dec 1998 16:30:47 -0700

Tim,

Is the source being kept in a version control system like RCS or CVS?
I would think this would be almost mandatory for some of the changes
recently brought up again (UI/platform portability, 32-bitness).
--
<http://www.xmission.com/~legalize/>    Legalize Adulthood!
    ``Ain't it funny that they all fire the pistol,
      at the wrong end of the race?''--PDBT
[e-mail]    <http://www.eden.com/~thewho>

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


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

From: Phil McRevis <[e-mail]>
Subject: Re: (fractdev) C++ builder
Date: 03 Dec 1998 16:34:48 -0700

I have C++ Builder too, and while it is a great product, I would not
recommend attempting to rewrite all of fractint using Builder's object
model.  The problem is that Builder's object and GUI model is not
portable to other compilers, much less other operating systems like
unix/linux/Mac.  This is why it is important to separate out the GUI
from the computation.  The GUI is going to be Xt/Xlib on linux/unix
and Mac Toolbox on the Mac (or whatever their favorite new app
interface is), homebrew on DOS, and Win32 on Win95/Win98/NT.

Aside from some form of pixel abstraction for image rendering, fractint's
GUI needs are relatively modest for a straight port/rewrite.
--
<http://www.xmission.com/~legalize/>    Legalize Adulthood!
    ``Ain't it funny that they all fire the pistol,
      at the wrong end of the race?''--PDBT
[e-mail]    <http://www.eden.com/~thewho>

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


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

From: "Tim Wegner" <[e-mail]>
Subject: (fractdev) Synchronous Orbits
Date: 03 Dec 1998 21:14:41 -0600

Humberto asked:

> > I have added synchronous orbits,
>
>     ? What are these ?

A few years ago a program was distributed called Fractal
Witchcraft that claimed to be many times faster than Fractint for
deep zooms. It turned out that the claims were legitimate.

Our implementation is based on AlmondBread by Michael R.
Ganss. See http://www.cs.tu-berlin.de/~rms/AlmondBread
If this isn't current try searching for AlmondBread.

The idea is to "fly" four points by generating their orbits in parallel.
For some regions of a deep zoom, neighboring points create orbits
that stay syhchronous (parallel) for many iterations. When the
orbits start to go on separate paths, the algorithm interpolates
between the points, creating estimated orbit values for that iteration
for the in-between points, and continues. So the computational
effort for all the iterations up to that point for the values in the
interior of the region bounded by the original four points is saved.

The results can be amazing - an order of magnitude faster in some
cases. However there are several disadvantages.

1. The algorithm is not completely general, and needs tuning for
different formulas.

2, The algorithm only starts being effective near the limit of double
precision, so zooming can only be done for a limited range.

3. The algoritm is recursive, which puts a big strain on the limited
stack of our medium memory model. I was able to overcome this,
but had to hack up the code a bit. Another reason to go to a flat
memory model.

What obviously needs to happen is to move the SOI (Synchronous
Orbits) code to arbitrary precision. This marriage has potential
because of course arbitrary precision is free of zoom depth
limitations, and is very slow, so could really use the speedup. I
contemplated this, but it too needs to await rehosting Fractint to a
better environment. At present the developer's version has two
versions of SOI in fractint, neither one too well integrated (most
options don't work). One uses double and one uses long double.

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) Platforms
Date: 03 Dec 1998 21:14:42 -0600

Frederick wrote:

> Sorry for the intrusion, but maybe you'll appreciate some of my
> thoughts about this.

I've followed your work and value your comments. Methinks we
have discussed this before <g!>

> If you feel you have little time and lots of
> work to do, I would recommend C++ Builder because it's much easier
> to use than Visual C, and it's cheaper so more developers can buy
> their copy (at least the Standard version!). I don't know about
> its portability though.

You put your finger on the problem. You are right that C++ Builder
would take less time to learn, but it would tie us to Borland. The
most likely scenario is that if we clean up and restructure the
underlying engine, lots of front ends will develop. Getting started is
the hard part. I hate to start a project that I can't finish in a short
period of time these days :-(.

BTW VIsual C/C++ does not have a long double. I'm not sure about
Borland.

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) Bouncing messages
Date: 03 Dec 1998 21:14:41 -0600

When this list came back to life, several of you attempted to post
messages that bounced because you sent the messages from a
different email address than the one you are subscribed under.
(This is a good idea - I see, but you don't, all the SPAM that get's
sent to the list but doesn't make it!)

I can post the bounced messages by hand, but I'd won't unless you
explicitly ask me because there are a few of them. I'll help anyone
who after some effort still can't post messages.

Tim




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


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

From: "Tim Wegner" <[e-mail]>
Subject: Re: (fractdev) Re: source code
Date: 03 Dec 1998 21:23:52 -0600

Rich asked:

> Is the source being kept in a version control system like RCS or CVS?
> I would think this would be almost mandatory for some of the changes
> recently brought up again (UI/platform portability, 32-bitness).

We keep changes as context diffs in a linear sequence. This is
very simple, non-automated but effective. The only tools are diff and
patch. It works really well for us, and makes merging changes
easy, but I probably will put the source in some kind of version
control system especially if we start having multiple versions. I
already maintain

1. Fractint
2. Xfractint (based on 1.)
3. Non-integer Fractint

Tim


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


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

From: George Martin <[e-mail]>
Subject: (fractdev) project list
Date: 04 Dec 1998 03:21:59 -0500

Correction to the list:

Current Developers:
-------------------
.
.
.
GM      George Martin <[e-mail]>
        Win95/DOS (Borland 3.1)
        ^^^^^

should read Win3.1

George

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


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

From: Humberto Rossetti Baptista <[e-mail]>
Subject: Evolver (was: RE: Re: (fractdev) Worklist and future directions)
Date: 04 Dec 1998 11:34:40 -0200 (EDT)

On Thu, 3 Dec 1998 [e-mail] wrote:

> >> When you see the beta source you will see. Robin Bussell has
> >> added an "evolver" feature that perturbs parameters as well as
> >    Great, if I it is what I imagine, one less item on my personal
> >worklist
> >:-))))
>
> Glad you like the sound of that! I'd be interested to hear how your
> vision of a fractal evolver differs from my implimentation.... so that the
> best  bits can be incorporated of course :-)

    Sure, I was thinking of udoing something along the lines Richard
Dawkinks (I guess, the author of "The Blind Watchmaker") has done: to put the
original fractal in the center of a, say, 3 x 3 matix (on screen reduced by the
"V" algorithm) and variations in two parameters aolong the axes x and y: like
this:

    V x-1 y-1    V y-1        V x+1 y-1
    V x-1         Orig. V        V x+1
    V x-1 y+1    V y+1        V x+1 y+1

    (I also think that Protoshop in some recent version has something like
this)

    The "x" and "y" above are parameters, byt I was yet trying to figure out
a clean way to represent changes in all possible/interesting numerical
parameters avaliable in Fractint (opposed to only changing the fractal type
parameters, but only this would be very nice).

    []'sx

    Humberto R. Baptista
    [e-mail]

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


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


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

From: "Ron Barnett" <[e-mail]>
Subject: RE: (fractdev) project list
Date: 04 Dec 1998 08:39:05 -0500

My email address is now
Ron Barnett <[e-mail]>.

I started a new job as a senior project manager for a startup software
company about 7 months ago, and I have been on the road about 90% of the
time, so I haven't been able to devote much time to 24 bit color support.
Hopefully that will change in January when I become the development site
manager and will be mostly working out of an office in Albany, NY.

To my knowledge there is only one general algorithm which works for all
fractals and gives a result which looks similar to the normal iteration
escape-base coloring. (I haven't tested them all :-), but none have failed
so far. I call the method exponential smoothing, which I discovered in 1997.
I have a beta program available on my web site to demonstrate some 24 bit
coloring techniques. The help file contains a description of exponential
smoothing. The site is http://www.hiddendimension.com I will post some
details on the method soon. I have tried to maintain compatibility with the
256 color fractint maps because I feel this is one of the strengths of
fractint. 24 bit color is provided by smooth interpolation using either RGB
or HSI color spaces. There are numerous examples of fractals generated this
way on my web site, including some conversions for fractint formulae. The
test  program can utilize fractint FRM files after minor modifications to
the files.

RBa

> -----Original Message-----
> From: [e-mail]
> [mailto:[e-mail]]On Behalf Of Phil McRevis
> Sent: Thursday, December 03, 1998 6:28 PM
> To: [e-mail]
> Subject: (fractdev) project list
>
>
> This file attempts to list the works "in progress" at the time of the
> current fractint release (19.6) and the people working on them.  It is
> hoped that this file will help developers coordinate their efforts and
> eliminate any duplicate effort.
>
> This file last updated January 29th, 1998
>
> Project(s)                              Developer & Status
> --------------------------------------
> --------------------------------------
> PNG support                             TW
> 24-bit support                          RBa, TW, others? (just starting)
> SIMPLGIF improvements                   TW (encoder done, decoder needed)
> GIF encoder fix                         TW (done)
> Relaxing 2K image sizelimit             TW (nearly done)
> float-only version                      TW (mostly done)
> synchronous orbits                      TW (under way)
> Formula parser improvements:
>   C optimizer                           GM (under way)
> xfractint visual selection              RT
> Parameter Evolver                       RBu, JO (mostly done)
> Memory use overhaul                     JO
> Pentium M-set assembly optimization     DJ (approx. 1/2 done)
>
> Current Developers:
> -------------------
> RBa     Ron Barnett <[e-mail]>
>         Win95/DOS (MS VC++ 1.52, MASM 6.0, MS VC++ 5.0)
> RBu     Robin Bussell <[e-mail]>
> DJ      Damien M. Jones <[e-mail]>
> GM      George Martin <[e-mail]>
>         Win95/DOS (Borland 3.1)
> JO      Jonathan Osuch <[e-mail]>
> RT      Rich Thomson <[e-mail]>
>         Win95/DOS (Borland C++ Builder 1.0, 3.0), Solaris (unix/gcc)
> TW      Tim Wegner <[e-mail]>
>         Win95/DOS (MSC 7.0, MASM 6.1, djgpp), linux (gcc)
>
> --------------------------------------------------------------
> 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: Humberto Rossetti Baptista <[e-mail]>
Subject: Re: (fractdev) Worklist and future directions
Date: 04 Dec 1998 11:56:26 -0200 (EDT)

On Thu, 3 Dec 1998, Phil McRevis wrote:

[...]
> of input rather than polling.  Currently polling of the keyboard to
> abort an operation in progress is sprinkled liberally throughout the
> code.  I think xfractint has a hack to get around this and process the
> message queue, but its just a hack.  The code should be reorganized to
> handle the message-queue input model.

    The fact that we're dealing with a single-{process/thread} makes things
a little bit more complicated, but I guess we can limit the amount of polling
and implement a real message queue on the code.

> On the subject of 32-bitness, I beliee Tim was working on an
> incremental change to use a DOS 32-bit extender and eliminate the
> 16-bit specific assembly.  I'm not sure what the status of that is
> right now.  Tim?

    Hm. I've listed a few items that have appeared here and that I
remembered being an issue to port a 16bit DOS app to 32-bit flat model
(optionally in a djgcc compatible fashion), specifficaly in the case o Fractint:

    - Assembly code (treatment of sements, direct access to mem. etc.)(gcc:
any way to use Intel's syntax on gcc??) (optimizations to 32 bit processors
(pentium class and above)?)
    - Video access: direct mem access, VESA is a real mode API isn't it?
That would mean switching evey video access? I have read this in some list
asking why Linux did not use VESA. There is an article on September Linux Jounal
(page 54, if i remebember it) talking a little of this and making some paralels
on SVGAlib (on linux) and Video access on DOS.
    - Overlays (is it hard??)
    - Compiler specific code (havent' seen _much_ of it except in regard to
the points above)
    - Linker (may be aproblem together with the assembly issue)
    - Variable size/alignment (hm.. the first means new bugs, the second
less speed unless optimized)

    (anything else?)

> I'm currently spending my free time working on other programming
> projects, but I did manage to put together a "to do" list for
> fractint's growth.  There is also a web page maintained by a list
> member (I'm sorry, I've forgotten who!) that contains a "wish list" of
> items from users.  Periodically that wish list is culled down to
> a reasonable list of "demands" :) and posted here to this list.

    Robin, on http://web.ukonline.co.uk/members/robin.b2/olig/fracwish.htm ?

    []'s

    Humberto R. Baptista
    [e-mail]

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


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


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

From: Humberto Rossetti Baptista <[e-mail]>
Subject: Re: (fractdev) project list
Date: 04 Dec 1998 12:06:20 -0200 (EDT)

On Thu, 3 Dec 1998, Phil McRevis wrote:

> This file attempts to list the works "in progress" at the time of the
> current fractint release (19.6) and the people working on them.  It is
> hoped that this file will help developers coordinate their efforts and
> eliminate any duplicate effort.
>
> This file last updated January 29th, 1998
[snip]

    January? ups. Are the "mostly done" done then? :-)))))

    OK, my peebles:

    new fractal types:

    * Generalized julia popcorn with functions and complex parameters (the
          images are sooo col. :-))

    * Latoocarfians - new orbit like fractal based on Pickovers' book.

    * New drawing method, suggested name: diffusion. Based on an aticle I
wrote for Computer & Graphics (supposed to be printed on issue 24(3)): this
method draws the poing evenly ditribuited over the screen. Two options: a block
filling option, that resemples solid guessing and a non filling option
(fillcolor==0) that "sprays the points over (kind of a "fade in" from the bk
color).

    All are done and docs ready, have debugged the first two and the last is
being debugged (some problems in save/restore).

    The patches will be with tim by the weekend.

    BTW: the latoocarfians are the first, nad I promissed to myself, the
last orbit-like fractal I do (unless in VERY special cases). I plan to use the
parser to implement a "roll-your-own"  orbit fractal in the next round :-)

    []'s

    Humberto R. Baptista
    [e-mail]

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


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


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

From: Humberto Rossetti Baptista <[e-mail]>
Subject: Re: (fractdev) project list
Date: 04 Dec 1998 12:06:20 -0200 (EDT)

On Thu, 3 Dec 1998, Phil McRevis wrote:

> This file attempts to list the works "in progress" at the time of the
> current fractint release (19.6) and the people working on them.  It is
> hoped that this file will help developers coordinate their efforts and
> eliminate any duplicate effort.
>
> This file last updated January 29th, 1998
[snip]

    January? ups. Are the "mostly done" done then? :-)))))

    OK, my peebles:

    new fractal types:

    * Generalized julia popcorn with functions and complex parameters (the
          images are sooo col. :-))

    * Latoocarfians - new orbit like fractal based on Pickovers' book.

    * New drawing method, suggested name: diffusion. Based on an aticle I
wrote for Computer & Graphics (supposed to be printed on issue 24(3)): this
method draws the poing evenly ditribuited over the screen. Two options: a block
filling option, that resemples solid guessing and a non filling option
(fillcolor==0) that "sprays the points over (kind of a "fade in" from the bk
color).

    All are done and docs ready, have debugged the first two and the last is
being debugged (some problems in save/restore).

    The patches will be with tim by the weekend.

    BTW: the latoocarfians are the first, nad I promissed to myself, the
last orbit-like fractal I do (unless in VERY special cases). I plan to use the
parser to implement a "roll-your-own"  orbit fractal in the next round :-)

    []'s

    Humberto R. Baptista
    [e-mail]

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


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


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

From: Humberto Rossetti Baptista <[e-mail]>
Subject: Re: (fractdev) C++ builder
Date: 04 Dec 1998 12:30:01 -0200 (EDT)

On Thu, 3 Dec 1998, Phil McRevis wrote:

[...]
> unix/linux/Mac.  This is why it is important to separate out the GUI
> from the computation.  The GUI is going to be Xt/Xlib on linux/unix
> and Mac Toolbox on the Mac (or whatever their favorite new app
> interface is), homebrew on DOS, and Win32 on Win95/Win98/NT.

    Agreed, I woudn't be good to compromise with specific
compiler/application frameworks or classes in Fractint.

> Aside from some form of pixel abstraction for image rendering, fractint's
> GUI needs are relatively modest for a straight port/rewrite.

    Is it? I guess i do not know the code enought. I would like to see (or
do if time permits) the abtraction with linkd to some items in the todo list
and, for instance, fast (possibly hw linked) {blok,area}-filling routines etc.

    []'s

    Humberto R. Baptista
    [e-mail]

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


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


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

From: Humberto Rossetti Baptista <[e-mail]>
Subject: Re: (fractdev) Synchronous Orbits
Date: 04 Dec 1998 13:11:53 -0200 (EDT)


    Hm. This sound great, and by what yo've written I gues that is what the
other program does.

    BTW: i war discussing fractint with some friends from a Parallel
Computing Lab and they've asked what kind of support/hook it has beccause
fractals are _so_ easy to distribute among processores, pipelines, vector
registers, machines etc.

    I am (for some time now) thinking about a _very_ simple way to put
several machines working on a same images autommatically (work distribution) ans
via network, but I keep wondering if we can come up with a code
organization/API/abstratcion that can suppor multiprocessors, pipelining and
vector computing.

    This is very similar to the syncronous orbit, except fro the
interpolation part, I mean: if we did the work by chunks some "magic trick"
could come up to split the work and/or to make similar operations "pipeline"
friendly and/or to alocare chunks to vector machines.

    Have you discussed along this lines? Any ideas?

    []'s

    Humberto R. Baptista
    [e-mail]

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


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


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

From: Humberto Rossetti Baptista <[e-mail]>
Subject: Re: (fractdev) Re: source code
Date: 04 Dec 1998 13:14:47 -0200 (EDT)

On Thu, 3 Dec 1998, Tim Wegner wrote:

[...]
> already maintain
>
> 1. Fractint
> 2. Xfractint (based on 1.)
> 3. Non-integer Fractint

    I haven't  looked to the Xfractint nor the non-integer, but aren't they
"mergeable" with the original DOS? Except for a bunch of ptatform specific stuff
in separate file of course. I keep thinking of the linux kernel tree. It is
really something to be able to compile and prepare kernel in such a number of
patforms and yu always get ALL the code to all platforms.

    []'s

    Humberto R. Baptista
    [e-mail]

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


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


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

From: Humberto Rossetti Baptista <[e-mail]>
Subject: RE: (fractdev) project list
Date: 04 Dec 1998 13:20:55 -0200 (EDT)

On Fri, 4 Dec 1998, Ron Barnett wrote:

> To my knowledge there is only one general algorithm which works for all
> fractals and gives a result which looks similar to the normal iteration
> escape-base coloring. (I haven't tested them all :-), but none have failed
> so far. I call the method exponential smoothing, which I discovered in 1997.

    Hm. Moving average exponential smoothing? Or exponential smoothing over
all points? how does it maps from iterations -> color?

> I have a beta program available on my web site to demonstrate some 24 bit
> coloring techniques. The help file contains a description of exponential
> smoothing. The site is http://www.hiddendimension.com I will post some
> details on the method soon. I have tried to maintain compatibility with the
> 256 color fractint maps because I feel this is one of the strengths of
> fractint. 24 bit color is provided by smooth interpolation using either RGB
> or HSI color spaces. There are numerous examples of fractals generated this
> way on my web site, including some conversions for fractint formulae. The
> test  program can utilize fractint FRM files after minor modifications to
> the files.

    Would it help to have a HLS/HSI/HSB mode on the pallet editor? I could
do this in a short time if it is helpful.

    And what do you (list?) think about other means of mapping from
Iterations -> colors? Formulas? Tranpareny controls over multiple methods?

    Ah, I forgot to mention:my diffusion drawing scheme can be used to
interpolate a image and help with the anti-alias regardless of the original
drawing method.

    []'s

    Humberto R. Baptista
    [e-mail]

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


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


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

From: "Damien M. Jones" <[e-mail]>
Subject: Re: (fractdev) Platforms
Date: 04 Dec 1998 09:57:38 -0600

Tim,

 - BTW VIsual C/C++ does not have a long double. I'm not sure about
 - Borland.

I knew VC++ 4 didn't have it, but I thought it had been restored in later
versions.  I will be very sorry to hear it has not.

 - (This is a good idea - I see, but you don't, all the SPAM that get's
 - sent to the list but doesn't make it!)

Well, I may not see it for FractDev, but I see it for Fractal-Art and
UltraFractal... makes me glad I'm using a similar option, else those lists
would be spammed regularly.

Damien M. Jones   \\
[e-mail]  \\  Fractalus Galleries & Info:
                    \\  http://www.fractalus.com/

Please do not post my e-mail address on a web site or
in a newsgroup.  Thank you.

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) Parallel Processing
Date: 04 Dec 1998 10:12:09 -0600

Humberto,

I once wrote a fractal generator for a dual-processor system, where the
processors were not quite equal in speed.  The naive approach is to assume
you have N processors, so the image should be divided into N portions and
assigned to each processor.  Even if all the processors are equal in speed,
this assumes it takes the same amount of time to render each piece, which
is of course not true for most fractal images.

What I did was a little different.  I kept a single variable common to all
processors that indicated the "next" line that needed to be drawn.  When a
processor is looking for a line to be drawn, it atomically fetches and
increments this counter, and then begins drawing the line.

For the system I was programming, using a shared memory location like this
was cheap, and I needed real-time performance.  In other environments,
communication may be more expensive, but real-time performance is not
required.  I would suggest increasing the "unit size" from a single line to
four or eight lines.  This would also allow guessing logic to be applied
easily to the strip assigned to each processor.

Damien M. Jones   \\
[e-mail]  \\  Fractalus Galleries & Info:
                    \\  http://www.fractalus.com/

Please do not post my e-mail address on a web site or
in a newsgroup.  Thank you.

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) RE: Evolver
Date: 04 Dec 1998 17:54 0000

>"V" algorithm) and variations in two parameters aolong the axes x and
>y: like
>this:
>
>    V x-1 y-1 V y-1          V x+1 y-1
>    V x-1          Orig. V        V x+1
>    V x-1 y+1 V y+1          V x+1 y+1

>    The "x" and "y" above are parameters,

Great minds think alike apparantly :-)  This is the present setup of the
evolver, the matrix can be any odd number in size and fractal type is
about the only thing it doesn't change! Random parameter scrambling is
also available, I'm still mulling over various possibilities for 'breeding'
images, though these all require storing complete parameter sets for the
images and would eat too much ram at present I suspect.

I like the sound of your diffusion plotting method, I had a go at
something similar recently using modulo arithmetic and a pair of magic
numbers.... I couldn't get it to work at all resoutions  due to me
borrowing somebody elses algorithm without compreheding it fully :-)

Have you tested the diffusion method with small amounts of image
panning? this causes very radical aspect ratio image segments  to be
calculated and broke my attempt at a new plotting method quite
thoroughly!

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: RE: RE: (fractdev) project list
Date: 04 Dec 1998 18:07 0000

Hi Ron,

>I haven't been able to devote much time to 24 bit color support.
>Hopefully that will change in January

I was hoping to put  in some hooks for 24bit colour testing soon,
basically by having variables for red,green,and blue which could be
assigned values in the formula parser and then used to colour the pixel
after the formula has bailed out. But I need to comprehend the parser
properly first! the rest is allready there thanks to Bert Tyler.
Addressing the CLUT from within the parser should be pretty straight
forward too.....maybe!


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: RE: RE: (fractdev) project list
Date: 04 Dec 1998 18:30 0000

>    And what do you (list?) think about other means of mapping
>from iterations -> colors? Formulas? Tranpareny controls over
>multiple methods?

Formulae, definately. The Parser's already there, keep the pallette as
well but different methods can do different things with it. Don't forget
that people are managing to do amazing things with all sorts of  orbit
behavior checking, not just iterations!

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: RE: Re: (fractdev) Synchronous Orbits
Date: 04 Dec 1998 18:24 0000


>    I am (for some time now) thinking about a _very_ simple way to
>put
>several machines working on a same images autommatically (work

Hi Humberto,

I've been wanting this to happen to fractint for year now! I had thought
along the lines of just using disk video mode, a shared file, and a
slightly modified single pass mode (just check the leftmost pixel in each
row, if it's color 0 then set it to grab the row, cmpute a row of pixels,
write them back and so on... not optimal but possibly very easy, just
ignore the odd occasion when two cpus grab the same row )

Once the calculation engine is serperated from the UI then I suppose it
gets much easier, just replace the user with a segmenter/dispatcher
routine.

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: Phil McRevis <[e-mail]>
Subject: Re: (fractdev) Re: source code
Date: 04 Dec 1998 14:09:54 -0700


In article <[e-mail]>,
    "Tim Wegner" <[e-mail]>  writes:
> [manual versioning via diff/patch...] I probably will put the source in
> some kind of version
> control system especially if we start having multiple versions. I
> already maintain

If it helps, I can offer a public CVS repository.  (What's CVS?  See
below)  What's nice about this is that you can control access by
assigning usernames and passwords (including a published user/password
pair for read-only access to the source) and giving active developers
the power to update/checking their code remotely at any time.  It also
automates the versioning.  To make a "release" you just tag all the
code, then the "release" is whatever version was tagged.  They are
using it for the GPL licensed Harvest code and it works well.  RCS and
CVS are available for DOS/Win32 and for unix with source under GPL as
well.
                    -- Rich

CVS/RCS - What is it?

RCS is a version control system that managed file versions as a
collection of context diffs against the most recent version.  RCS lets
you branch versions so that multiple versions of the same file can
exist concurrently in the version control system.  Each revision entered
into the system has a timestamp, userid of the person making the
change, and an optional freeform log message.  RCS deals exclusively
with individual files and their revision histories, it has no concept
of a group of related files or a hierarchical group of related
directories containing source files.

CVS is a layer of source code management built on top of RCS,
ultimately invoking RCS commands on the revision trails and source
files.  CVS deals with entire directories and related groups of files
however.  CVS also provides the ability to check out source code over
a network by converting to a CVS server on the internet.  The transfer
of source code is accomplished by compressing the source streams
before transfer and also handles end-of-line differences between the
server machine and the client machine.  This means that when you
checkout unix source code remotely from a CVS server onto a local DOS
(or Win32) box, all the source files have the DOS EOL convention.
When you checkin a file from your DOS box, the EOL is switched back to
whatever is native for the original source file.
--
<http://www.xmission.com/~legalize/>    Legalize Adulthood!
    ``Ain't it funny that they all fire the pistol,
      at the wrong end of the race?''--PDBT
[e-mail]    <http://www.eden.com/~thewho>

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


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

From: Phil McRevis <[e-mail]>
Subject: Re: (fractdev) C++ builder
Date: 04 Dec 1998 14:30:42 -0700


In article <[e-mail]>,
    Humberto Rossetti Baptista <[e-mail]>  writes:
> > Aside from some form of pixel abstraction for image rendering, fractint's
> > GUI needs are relatively modest for a straight port/rewrite.
>
>     Is it?

I've browsed the code some, but mostly I have just been thinking of
how fractint deals with everything input-wise.  It either does some
modest screen/mouse graphics, or it uses a text-only mechanism.

As usual, its sloth not technology that holds us back :)
--
<http://www.xmission.com/~legalize/>    Legalize Adulthood!
    ``Ain't it funny that they all fire the pistol,
      at the wrong end of the race?''--PDBT
[e-mail]    <http://www.eden.com/~thewho>

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


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

From: "Tim Wegner" <[e-mail]>
Subject: Re: (fractdev) Re: source code
Date: 04 Dec 1998 19:25:45 -0600

Humberto asked:

>     I haven't  looked to the Xfractint nor the non-integer, but aren't they
> "mergeable" with the original DOS? Except for a bunch of ptatform specific stuff
> in separate file of course. I keep thinking of the linux kernel tree. It is
> really something to be able to compile and prepare kernel in such a number of
> patforms and yu always get ALL the code to all platforms.

I didn't say quite enough. Fractint and Xfractint absolutely share
source with NO changes. You can copy the fractint source on top
of the Xfractint source and compile it. Some fractint files are not
used (for example, NONE of the assembler is used) and Xfractint
has some additional files. There is code of the form

#ifdef XFRACT
...
#else
...
#endif

to allow for places in the source where Xfractint must be different
from the DOS version. We could probably clean up a lot of those.
The ugliest thing is that Fractint naively saves parameters by
writing the binary values to disk. Xfractint has some code that
translates the byte order and converts numbers to IEEE. When we
finally abandon DOS I intend also to abandon GIF and use PNG,
and redo the method of saving parameters in ASCII or other
portable scheme (something like imbedding the PAR entry in the
image instead of a binary image of the fractal info structure. I have
even reserved a PNG chunk name (fRAc) for this purpose.

This source compatability between Xfractint and Fractint has had
several tremendous advantages. For a time we received code
updates from the Xfractint folks that Fractint immediately inherited,
and vice versa. It is an easy matter to keep of Xfractint. The Motif
Fractint port suffered death by neglect because it differed
sufficiently from Fractint (dramatically in fact) that we couldn't
maintain it.

The down side is that the Xfractint interface is very idiosyncratic
and un-X-like. Because it is the fractint interface, except that the
graphics and text screens are in different windows.

The non-integer version came about because I was trying to save
resources to use in adding PNG support. Plus it is clear to me
integer math has no future, first because it is no longer faster than
floating point, and second because integer math will almost
certainly not survive any port to a flat memory model because the
guts are in assembler. (Having said that, if someone cared, the
assemble could be ported, at least to Intel platforms.)

Sofar, though, the team has not agreed to give up integer math yet,
although I believe that everyone agrees that we will abandon it at
the ame time we abandon the medium memory model.

The non-integer version has many code differences from the regular
version, and is not really mergeable. But it is not too hard to
maintain. I patch in every diff, and simple deal with all the failed
hunks. Not to bad for small changes.

I truly believe that once we are cut loose from DOS we will be able
to do a major reorganization of the architecture in a short order. I
don't think of this as abandoning Fractint and starting over as
Frederick suggested, but my view is not so different than his. In
early years Bert Tyler and I took turns making serious global
restructurings. We could, for example, get rid of the global
vatriables in a few weekends of work if we had already abandoned
the assembler.

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) Parallel processing (was Synchronous Orbits)
Date: 04 Dec 1998 19:25:45 -0600


>     I am (for some time now) thinking about a _very_ simple way to put
> several machines working on a same images autommatically (work distribution) ans
> via network, but I keep wondering if we can come up with a code
> organization/API/abstratcion that can suppor multiprocessors, pipelining and
> vector computing.

This is very easy to do, although what I have in mind is less
sophisticated than you have in mind. The "divide and conquor"
mechanism in the <b> command generates a batch file that builds
images piecewise. All you need is a shell script that can cause
fractint (Xfractint) to execute remotely, each piece on a separate
processor, and return the GIF file. This doesn't require any changes
to fractint itself. Thge logic to divide up, process, and recombine
the pieces is already there.

The value of this approach is that the method of starting processes
on different processors is machine dependent, so not a good
candidate to put *inside* fractint, hench the shell script approach.

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) C++ builder
Date: 04 Dec 1998 19:25:45 -0600

Rich wrote:

> I've browsed the code some, but mostly I have just been thinking of
> how fractint deals with everything input-wise.  It either does some
> modest screen/mouse graphics, or it uses a text-only mechanism.
>
> As usual, its sloth not technology that holds us back :)

Actually, I've found your  comments encouraging. It probably would
not be hard to make a simple fractint GUI interface, and also would
not be hard to port the whole source as long as it was a single
document with no multi-threading. I may have talked myself out
something I could do.

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) Worklist and future directions
Date: 04 Dec 1998 19:25:46 -0600


>     The fact that we're dealing with a single-{process/thread} makes things
> a little bit more complicated, but I guess we can limit the amount of polling
> and implement a real message queue on the code.

When Bert Tyler wrote Winfract (The WIndows 3.1 port, now
hopelessly obsolete) he found that we have enough checks for
keypresses that he could check for events inside the keypress
check routine. This actually worked really well, though it probably
makes real Windows programmers shudder <g!> Winfract actually
shared most of Fractint's code.

>     Hm. I've listed a few items that have appeared here and that I
> remembered being an issue to port a 16bit DOS app to 32-bit flat model
> (optionally in a djgcc compatible fashion), specifficaly in the case o Fractint:
>
>     - Assembly code (treatment of sements, direct access to mem. etc.)(gcc:
> any way to use Intel's syntax on gcc??) (optimizations to 32 bit processors
> (pentium class and above)?)

Assembly code needs to be rewritten or else Fractint will be
slower. But all the integer code can go, and the floating point code
may not be hard to port. Plus we can do this later and start with
the Xfractint C.

>     - Video access: direct mem access, VESA is a real mode API isn't it?
> That would mean switching evey video access? I have read this in some list
> asking why Linux did not use VESA. There is an article on September Linux Jounal
> (page 54, if i remebember it) talking a little of this and making some paralels
> on SVGAlib (on linux) and Video access on DOS.

The easiest possible port would be to djgpp. To do this:

1. Merge the non-integer code with Xfractint
.
2. Cut out all the Xwindows stuff, and add video support via the
Linux SVGA lib. (Did you know that Xfractint does not need
Xwindows? Invoke Xfractint -disk and the program works in 100%
character mode.)

3. Port the the Linux version to djgpp, using the SVGALIB.

I don't think we should reinvent the well. If we want a DOS version,
we should use existing SVGA libraries. Of course for all GUI ports
we write to a virtual screen.

I believe it is possible to add assembler back in that would be
portable between Linux and DOS.

Some people might think this is a waste a time, but once Fractint
was ported to 32 bits flat memory, even though DOS or non-X
Linux, we could then get rid of all the memory saving junk like re-
used arrays, get rid of global variables, etc. etc., and evolve a
decent underlying engine.

>     - Overlays (is it hard??)

Non issue! Flat memory models allow big footprints! No 640K limit.
Just make one big executable that would eat 2 mb or so.

>     - Compiler specific code (havent' seen _much_ of it except in regard to
> the points above)

This is already identified and #ifdef'ed out in Xfractint.

>     - Linker (may be aproblem together with the assembly issue)
????

>     - Variable size/alignment (hm.. the first means new bugs, the second
> less speed unless optimized)

The main issue is the way parameters are written inside GIFs,
which I have addressed elsewhere.

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: "Dean-Christian Strik" <[e-mail]>
Subject: Re: (fractdev) Welcome Humberto
Date: 03 Dec 1998 19:41:17 +0100

I'm sorry to say, but I think it's getting all to private for a 'public'
beta... I don't think it's right to almost keep it's existence a secret...

--

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

The nice thing of standards is that there are so many to choose from.
-- Andrew S. Tanenbaum

-----Original Message-----


Humberto asked:

> OK, what would be best to post the patches or to send
>them directly to
> [e-mail]?

I'd rather get them directly. But it would be better to wait until you
get the latest version which I will upload shortly (by Saturday). We
are up to 19.61 patch 58! I could probably merge your patches
relative to an older version but I'd much prefer if you are working off
the same version we are.

> Yes I would like to discuss it and my tow inital cents are: place it in
> one or two sites (like spanky and some friendly mirros) and allow the
> download via HTTP only. A prety clear statement that it is beta code would
> surely be better understood if on the download page that in some README
that is
> not alway read.

Good suggestion. Also, it is very good to hear from  you, it has
been a few years!

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"




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: "Dean-Christian Strik" <[e-mail]>
Subject: Re: (fractdev) Worklist and future directions
Date: 03 Dec 1998 19:28:38 +0100


Problem's just most people haven't converted to unices yet... :)

--

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

The nice thing of standards is that there are so many to choose from.
-- Andrew S. Tanenbaum

-----Original Message-----


>On Wed, 2 Dec 1998, Humberto Rossetti Baptista wrote:
>> Other thing that I have been thinking for some time now. Should we think
>> of a 32 bit version of fractint?
>
>xfractint is 32-bit on 32-bit machines, and 64-bit on 64-bit machines.
>
>--
><[e-mail]>       Kragen Sitaker     <http://www.pobox.com/~kragen/>
>It frightens the daylights out of me whenever I hear people proclaim that
>the less knowledge our children have access to, the better.
>-- Duane Lindstrom, at <URL:http://www.examiner.com/skink/skinkmail.html>
>
>
>--------------------------------------------------------------
>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: "Dean-Christian Strik" <[e-mail]>
Subject: Re: (fractdev) Welcome Humberto
Date: 03 Dec 1998 19:35:40 +0100

Tim W. wrote:

> Hi Robin! I see you have a new identity!

Seems more like an internet overload ;-)

>> I'm gane! How about tentatively suggesting a christmas or new year
>> rrelease for public beta code? seems like a handy date in the not too
>> near, not too distant future.
>
> It just depends on the team being ready. But I have many fewer
> reservations about publishing the public *source*, it is a bigger deal
> to publisg the beta *executable*. I have had beta source at my FTP
> site for a long time, but I hadn't kept it up because no one here in
> fracvtdev asked for it.

I don't see the problem with beta executables, really. I know some beta
testers who don't even know how to write a dos batch file.... executables are
a lot more attractive to many people. Is it just that it's because of the
beta?

--

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

The nice thing of standards is that there are so many to choose from.
-- Andrew S. Tanenbaum





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: "Dean-Christian Strik" <[e-mail]>
Subject: Re: (fractdev) Worklist and future directions
Date: 03 Dec 1998 19:27:54 +0100

Hi,

>form of dialogs, etc.  The biggies left for me are file-parsing (PARs
>FRMs MAPs), palette editing, and general UI cleanup.  I'm currently


There can hardly be real mac-specific code for par-parsing, can there? I hope
I'm not showing too much of my ignorance here ;-)

>Future directions?  I vote for a cleaner layer of abstraction seperating
>Fractint from platform/gui.  POV-Ray is my inspiration!

I hope I'm parsing this right...

You write you're writing mac-specific code. This separation you're proposing
is, however, contrary to that. Too bad really.

--

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

The nice thing of standards is that there are so many to choose from.
-- Andrew S. Tanenbaum





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: Phil McRevis <[e-mail]>
Subject: Re: (fractdev) Parallel processing (was Synchronous Orbits)
Date: 04 Dec 1998 20:46:52 -0700


In article <[e-mail]>,
    "Tim Wegner" <[e-mail]>  writes:
> This is very easy to do, although what I have in mind is less
> sophisticated than you have in mind. The "divide and conquor"
> mechanism in the <b> command generates a batch file that builds
> images piecewise. All you need is a shell script that can cause
> fractint (Xfractint) to execute remotely, each piece on a separate
> processor, and return the GIF file. This doesn't require any changes
> to fractint itself. Thge logic to divide up, process, and recombine
> the pieces is already there.

Another alternative is to write a "fractal daemon" that listens on a
socket for work requests.  It processes its work and sends the result
back over a socket.  You have to define the communications protocol
that is used over the socket (don't forget byte-ordering and
machine-dependent floating point issues of you're transporting more
than image data), but that is not too hard.  The nice thing about the
proliferation of the internet is that it makes TCP/IP and sockets
available on pretty much every machine these days, becoming the
defacto networking API between heterogeneous hosts (amazing, considering
that is the point of TCP/IP in the first place :).

Parallel processing becomes just a matter of network socket I/O.  Of
course, you have network bandwidth and latency to deal with, which can
often be more costly than doing some kind of architecture specific SMP
type thing.  On the other hand, its very portable to a machine with
sockets, which is most machines these days.
--
<http://www.xmission.com/~legalize/>    Legalize Adulthood!
    ``Ain't it funny that they all fire the pistol,
      at the wrong end of the race?''--PDBT
[e-mail]    <http://www.eden.com/~thewho>

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


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

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

Does anyone have Borland 4.5? I bought Borland 5.01, and
understand that the tlink.exe does not properly support overlays,
so I need the tlink.exe from Borland C 4.5x. Fractint runs with the
message "too big to fit in memory".

Tim


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


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

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

I have posted the source synch for 1961p58.zip in a new form. You
should download

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

If you have MSC but not MASM, the object code is in o1961p58.zip.

If you don't have patch.exe, download diffpat.zip. These versions of
diff and patch are pretty old. I have newer GNU versions of diff and
patch that perhaps I could upload if anyone needs them.

The idea is that you make a clean directory, copy the public
source for 19.6 into the directory, then unzip the s1961p58.zip file
in the same directory. Then run the batch file synch.bat, which
applies all the patches. Make sure the standard UNIX-clone patch
utility is the one accessible first in your PATH - Borland and others
have different patch programs with the same name.

If this is causing problems, let me know. My reason for doing it this
way is:

1. the file is smaller

2. diff/patch is the way we distribute changes, so from my point of
view (maybe not yours!) it is a Good Thing for you to use diff and
patch :-)

3. This approach gives you not only the current patch but ALL the
versions. It is a simple matter to reconstruct any version by just
editing synch.bat so it stops at the desired point. My number one
debugging method is to discover in what version a bug appears.
Then I look in the context diff for that version and can usually see
the error right away.

Having said this, I am willing to upload a zip archive with all the
files if it is needed.

I will upload an Xwindows source file for 1961p58 later this
weekend. I wouldn't advise anyone to try to reconstruct it from the
patches for the DOS version. I will also upload the non-integer
source.

Borland 3.1 users can compile using the bcfract.bat batch method.
The Borland IDE project files probably don't work. Microsoft users
need a 16 bit compiler that was distributed as MSC 7.0 or the
earlier Visual C/C++ distributions. Microsoft no longer distributes
16 bit compilers with their Visual C/C++.

SOI doesn't work with the Borland compile. Probably needs to be
compiled with increased stack, but I'm not positive what the
problem is. Use the help (F1) to see what's new. Look for the
evolver, sound, browser improvements, and who knows what all. I
think 58 patches is some kind of a record, even though we have
been working more slowly than in the past.

At this point I don't want to distribute the executable compiled from
this code, please honor this and don't upload it anywhere. However,
we will probably decide to release some of these beta versions
fairly soon.

If you want to send us patches, use the -c option on diff and run diff
in a directory with the current version (1961p58). Name your dif file
something OTHER than 1961p59.dif and send it to me zipped up
(not in an email message where the formatting might get messed
up). The less work we have to do the more likely we are to make
your patch official, so edit the help?.src files also.

If any questions please ask!

Tim



Tim

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


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

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

It occurs to be that if you have a version based on a recent synch,
you can try to patch in the recent patches. This might work with no
problems. For example, if Humberto added some features to patch
44, he could patch in 1961p45.dif through 1961p58.dif (in a clean
directory of course).

It is always possible that our changes clash with yours, but usually
this results in failed hunks that can easily be implemented by
hand. If the changes don't clash you are home free.

Tim


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


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

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

On Fri, 4 Dec 1998, Tim Wegner wrote:
> The non-integer version came about because I was trying to save
> resources to use in adding PNG support. Plus it is clear to me
> integer math has no future, first because it is no longer faster than
> floating point,

It's still faster than FP on non-Intel machines (or Intel StrongARMs)
and on old machines.  Sometime next year I plan to get an
eight-processor StrongARM machine if I can dig up the money for it.

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

> The non-integer version has many code differences from the regular
> version, and is not really mergeable. But it is not too hard to
> maintain. I patch in every diff, and simple deal with all the failed
> hunks. Not to bad for small changes.

I guess I should probably look at the code, because I don't understand
what you're saying here.  The FP versions of the
{IFS,escape-time,Lsystem,orbital,bifurcation} fractal engines are
separate from the integer versions, but similar enough that you can
usually apply the same diff to the integer and FP code?!

--
<[e-mail]>       Kragen Sitaker     <http://www.pobox.com/~kragen/>
This radically anti-cynical approach to life is not just a shared
disposition but also an act of conscious dissent.  -- Alan Bershaw, on the
attitude of Jewel fans ("everyday angels")


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


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

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

As one of those people who are patiently awaiting the next iteration of
Fractint (or whatever it'll be called), I'd like to thank and wish many
happy thoughts to those working more or less dilegently on it.  Keep it
up!

Smiles,

Jiho


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


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

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


In article <[e-mail]>,
    [e-mail] (Kragen)  writes:
> I am slightly puzzled what FP fractal calculation has to do with PNG
> support.

Like everything else in the 16-bit code, it has to do with memory.
Adding the PNG code meant something else had to go, or more overlay
shuffling had to take place.  The 16-bit code is chafing against the
16-bit memory model big time.

> [...]  The FP versions of the
> {IFS,escape-time,Lsystem,orbital,bifurcation} fractal engines are
> separate from the integer versions, but similar enough that you can
> usually apply the same diff to the integer and FP code?!

I think what Tim meant was that he has a version of fractint with the
integer code and a version of fractint without the integer code.
Patches to other parts of fractint can be applied relatively easily to
these two 'branches' of development.  (CVS would keep all this
straight much easier, ya know :)
--
<http://www.xmission.com/~legalize/>    Legalize Adulthood!
    ``Ain't it funny that they all fire the pistol,
      at the wrong end of the race?''--PDBT
[e-mail]    <http://www.eden.com/~thewho>

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


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

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

Kragen wrote:

>It's still faster than FP on non-Intel machines (or Intel StrongARMs)
>and on old machines.  Sometime next year I plan to get an
>eight-processor StrongARM machine if I can dig up the money for it.


<silence>

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


Nothing. Who said so?

--

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

The nice thing of standards is that there are so many to choose from.
-- Andrew S. Tanenbaum


>> The non-integer version has many code differences from the regular
>> version, and is not really mergeable. But it is not too hard to
>> maintain. I patch in every diff, and simple deal with all the failed
>> hunks. Not to bad for small changes.
>
>I guess I should probably look at the code, because I don't understand
>what you're saying here.  The FP versions of the
>{IFS,escape-time,Lsystem,orbital,bifurcation} fractal engines are
>separate from the integer versions, but similar enough that you can
>usually apply the same diff to the integer and FP code?!
>
>--
><[e-mail]>       Kragen Sitaker     <http://www.pobox.com/~kragen/>
>This radically anti-cynical approach to life is not just a shared
>disposition but also an act of conscious dissent.  -- Alan Bershaw, on the
>attitude of Jewel fans ("everyday angels")
>
>
>--------------------------------------------------------------
>Thanks for using Fractdev, The Fractint Developer's Discussion List
>Post Message:   [e-mail]
>Get Commands:   [e-mail] "help"
>Administrator:  [e-mail]
>Unsubscribe:    [e-mail] "unsubscribe fractdev"
>



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


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

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

Dean-Christian wrote:

> >I am slightly puzzled what FP fractal calculation has to do with PNG
> >support.
>
>
> Nothing. Who said so?

I took the integer math out of a version of fractint hoping to free up
memory resources to give me room for PNG, which needs much
more memory than GIF. That is the connection. I concluded that a
medium memory model Fractint will never directly support PNG. I
do believe it is possible to shell out to a protected mode program to
implement PNG, but I don't think this is work the effort, which
should be directed to getting Fractrint moved to a flat memory
model. After that adding PNG would be easy.

Tim




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


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

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


    Hi Robin,

On Fri, 4 Dec 1998 [e-mail] wrote:

> Great minds think alike apparantly :-)  This is the present setup of the

    Gues I could say that too :->>>

> evolver, the matrix can be any odd number in size and fractal type is
> about the only thing it doesn't change! Random parameter scrambling is
> also available, I'm still mulling over various possibilities for 'breeding'
> images, though these all require storing complete parameter sets for the
> images and would eat too much ram at present I suspect.

    I've managed to put everything up from Tim's patches (from
ftp.phoenix.net) and the evolver was VERY much what I had in mind. BTW I
couldn't play around enough, but some things came up about the patch 58
implementation:
- we cannot vary th eiteration number (it may do some difference
  in certain kinds of fractals).
- the restriction on orbit/infinite-running seems a bit too restrictive.
- there could be a keyboard shortcut to switch back and forth to the
  evolver (Yes, i know that's a big problem :-) ).
- I do not know the amount of work/logic involved bu on deterministic
  arrays (the ones we use x, y, x+y etc) I should be possible (in theory) to
  simply copy the part of the array around the new chosen image to avoid
  recalculation. What do you think?
- No pallete loading from the evolver :''-(

> I like the sound of your diffusion plotting method, I had a go at
[snip]

    Then bug Tim to pass the patch around :-)

    As I invented (at least as fas as I know) this method I was able to
handle the extreme cases (like creating a image 1 x n or n x 1 etc.) And I spent
a reasonable time (on what's avaliable) to enhance its' speed.

    If you like the method we can work together to make a "paralell" evolver
that plots all images at the same time :-)))

    []'s

    Humberto R. Baptista
    [e-mail]

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


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


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

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

On Fri, 4 Dec 1998 [e-mail] wrote:

> I've been wanting this to happen to fractint for year now! I had thought
> along the lines of just using disk video mode, a shared file, and a
> slightly modified single pass mode (just check the leftmost pixel in each
> row, if it's color 0 then set it to grab the row, cmpute a row of pixels,
> write them back and so on... not optimal but possibly very easy, just
> ignore the odd occasion when two cpus grab the same row )

    I've been thinking about this for some time too (mind parallelism again
:-) but discussing this with some friends that do program very well in other
environments like Unix I was "convinced" no to rely on shared fies and such. I
was thinking of a subset of the HTTP protocol end to make the "master" fractint
just wait for the others (slaves ;-) It would be easy and not too disruptive to
a non multithreaded app. The choice of HTTP is interesting because it is very
portable and there are lots of GNU/free libraries around.

> Once the calculation engine is serperated from the UI then I suppose it
> gets much easier, just replace the user with a segmenter/dispatcher
> routine.

    Agreed.

    []'s

    Humberto R. Baptista
    [e-mail]

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


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


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

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

On Fri, 4 Dec 1998, Tim Wegner wrote:
> I didn't say quite enough. Fractint and Xfractint absolutely share
> source with NO changes. You can copy the fractint source on top
[...]

    I haven't browsed enought :-)

[...]
> image instead of a binary image of the fractal info structure. I have
> even reserved a PNG chunk name (fRAc) for this purpose.

    This idea is VERY interesting and allows a great deal of things by
manipulating the PNGs and running Fractint from simple scripts (in perl for
instance)

> The non-integer version came about because I was trying to save
> resources to use in adding PNG support. Plus it is clear to me
> integer math has no future, first because it is no longer faster than
> floating point, and second because integer math will almost
> certainly not survive any port to a flat memory model because the
> guts are in assembler. (Having said that, if someone cared, the
> assemble could be ported, at least to Intel platforms.)

    Hm. I also favor the platform independence, but I do not know if a good
recoding in assmbly optimized for 586 class machines (using perhaps even MMX and
such) wouldn't give some speedup.

    Tim, do you thing it would be possible to coordinate the non-integer and
the current versions? I ask because if we could have, say, some platform
specific directories with hand optimized assmbly language it could make a HUGE
difference in some platforms. As we're thinking about this we could consider the
possibility of compiling fractint on _very_ alien machines :-))

[...]
> restructurings. We could, for example, get rid of the global
> vatriables in a few weekends of work if we had already abandoned
> the assembler.

    A few more weekends to port it all to C++ :->>> (kidding)

    []'s

    Humberto R. Baptista
    [e-mail]

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


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


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

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

Humberto,

>> - No pallete loading from the evolver :''-( <<

That's easy enough to fix.  I'll add it back in with my next patch.

Jonathan

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


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

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

On Fri, 4 Dec 1998, Tim Wegner wrote:

> This is very easy to do, although what I have in mind is less
> sophisticated than you have in mind. The "divide and conquor"
> mechanism in the <b> command generates a batch file that builds
> images piecewise. All you need is a shell script that can cause
> fractint (Xfractint) to execute remotely, each piece on a separate
> processor, and return the GIF file. This doesn't require any changes
> to fractint itself. Thge logic to divide up, process, and recombine
> the pieces is already there.

    And how can we assemble back the pieces? If that means using the actual
code and extending it no problem.

> The value of this approach is that the method of starting processes
> on different processors is machine dependent, so not a good
> candidate to put *inside* fractint, hench the shell script approach.

    Yes i agree. My idea was to come up with something simple enought to
make fractint "network aware" and then communicate the chunks around.

    []'s

    Humberto R. Baptista
    [e-mail]

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


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


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

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

On Fri, 4 Dec 1998, Tim Wegner wrote:

> 1. Merge the non-integer code with Xfractint

    Is the non-integer source avaliable anywhere? I could try to catch up
with mu Unix programming skills and make the port to SVGAlib

> 2. Cut out all the Xwindows stuff, and add video support via the
> Linux SVGA lib. (Did you know that Xfractint does not need
> Xwindows? Invoke Xfractint -disk and the program works in 100%
> character mode.)

    Yep. I used this a lot i Unix statiosn to generate animations :-)

> 3. Port the the Linux version to djgpp, using the SVGALIB.
>
> I don't think we should reinvent the well. If we want a DOS version,
> we should use existing SVGA libraries. Of course for all GUI ports
> we write to a virtual screen.

    Hm I am not sure but I do not know if there is a port of the SVGAlib to
DOS. Is it?

> I believe it is possible to add assembler back in that would be
> portable between Linux and DOS.

    I'll only add the this should be done in a fashion that allows COMPLETE
independence of the assembly (I have said more before)

> Some people might think this is a waste a time, but once Fractint
> was ported to 32 bits flat memory, even though DOS or non-X
> Linux, we could then get rid of all the memory saving junk like re-
> used arrays, get rid of global variables, etc. etc., and evolve a
> decent underlying engine.

    Waste of time???!! No comments.

    We could then start to experiment in new directiosn the REALLY use up
memory :-) (I have just thought of saving all x,y,iteration values up to play
with coloring techiniques, etc.)

> >     - Variable size/alignment (hm.. the first means new bugs, the second
> > less speed unless optimized)
>
> The main issue is the way parameters are written inside GIFs,
> which I have addressed elsewhere.

    Also on a major cleanup without the memory concerns we can align avery
variable to where it's going to be better fetched.

    []'s

    Humberto R. Baptista
    [e-mail]

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


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


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

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

On Fri, 4 Dec 1998, Tim Wegner wrote:

> Does anyone have Borland 4.5? I bought Borland 5.01, and
> understand that the tlink.exe does not properly support overlays,
> so I need the tlink.exe from Borland C 4.5x. Fractint runs with the
> message "too big to fit in memory".


    Does the tlink from BC 3.1 work? I have it here.

    []'s

    Humberto R. Baptista
    [e-mail]

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


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


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

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

On Sat, 5 Dec 1998, Tim Wegner wrote:

> Borland 3.1 users can compile using the bcfract.bat batch method.
> The Borland IDE project files probably don't work. Microsoft users

    Hi, I'm sending tim the fractint.prj corrected to the newest additions.

> SOI doesn't work with the Borland compile. Probably needs to be
> compiled with increased stack, but I'm not positive what the

I'm having problems with the switch to arbitrary precision I'll look at this
later.


> If you want to send us patches, use the -c option on diff and run diff

    IMHO use: diff . .. -c2 -o -b > yourdif.dif

    the -c2 gives 2 lines of context, the -o ignores the files only in one
directory and the -b ignores the changes in whitespace/tabs so common among
differente text editors.

    []'s

    Humberto R. Baptista
    [e-mail]

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


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


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

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


    Hi,

    I've sent Tim my recent contributions to fractint:

    - A new orbit type: the Latoocarfians (From Pickover's book)
    - A new map type: a generalization from PopCornJul
    - A new drawing technique: the diffusion Scan.

    The last one has worked very well with the original 19.6 and the current
version 19.61p58 and allow for the ingremental generation of images without the
introduction of image artifacts like in solig guessing teseral and boundary
tracing. As it is not magic, it takes longer than these because it calculates
ALL points, but I have added a "resolution enhancer"(1) that allows the user to
preview the image ahead of any other method.

    (1) in reality it is a technique inspired by the blocks solid guessing
uses to refine the image.

    When tim publishes the code send you comments!

    I'll mess around with the pallet editor and the evolver next ;-))))

    (i think :->>> )

    []'s

    Humberto R. Baptista
    [e-mail]

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


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


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

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

hi all,

> Our implementation is based on AlmondBread by Michael R.
> Ganss. See http://www.cs.tu-berlin.de/~rms/AlmondBread
> If this isn't current try searching for AlmondBread.

the URL is still valid, although I haven't updated the pages in over a
year. "professional responsibilities" currently do not allow me to
further develop AlmondBread nor participate in the development of
Fractint. I had originally planned a port of AlmondBread to Windows,
but got very frustrated with Visual C++ (it took me ages to get a
simple hello world to work), so I gave that up. However, I'm still
very interested in the development of Fractint.

Regarding SOI, I think what Tim said is true insofar as it would
benefit tremendously from being integrated with arbitrary
precision. ap, IMHO, is a prime candidate for an object-oriented
implementation (i.e., C++), so before that's done, I don't recommend
hacking up the SOI code further, since it's a little terse already.

One thing I was always very interested in was cardioid checking for
cardioids of arbitrary degree. Jay Hill has done some great work in
this area. I wonder if there has been development in this area lately.

--
Michael R. Ganss        Didi: Wat seh ick da ick gloob ick spinn
[e-mail]              Stulle der hat einen drin.

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


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

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

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

What exactly does this mean?

--
<[e-mail]>       Kragen Sitaker     <http://www.pobox.com/~kragen/>
This radically anti-cynical approach to life is not just a shared
disposition but also an act of conscious dissent.  -- Alan Bershaw, on the
attitude of Jewel fans ("everyday angels")


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


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

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

On Mon, 7 Dec 1998, Humberto Rossetti Baptista wrote:
> The choice of HTTP is interesting because it is very
> portable and there are lots of GNU/free libraries around.

If we want to use GNU GPL libraries in Fractint, we'd have to change the
licensing of Fractint (which currently prohibits selling Fractint for
money).  Which means, I think, that we'd have to get consent from
everyone whose code is currently in Fractint.  Which is probably
infeasible.

I don't think this is likely to come up for HTTP, anyway.

--
<[e-mail]>       Kragen Sitaker     <http://www.pobox.com/~kragen/>
This radically anti-cynical approach to life is not just a shared
disposition but also an act of conscious dissent.  -- Alan Bershaw, on the
attitude of Jewel fans ("everyday angels")


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


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

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

    // I took the integer math out of a version of fractint hoping
    // to free up
    // memory resources to give me room for PNG, which needs much
    // more memory than GIF. That is the connection. I concluded that a
    // medium memory model Fractint will never directly support PNG. I
    // do believe it is possible to shell out to a protected mode
    // program to
    // implement PNG, but I don't think this is work the effort, which
    // should be directed to getting Fractrint moved to a flat memory
    // model. After that adding PNG would be easy.

I've thought about this a few times, and figured DJGPP would be best for
this, especially considering that 1) it supports 32-bit, and (even better=
)
2) it's free.  Unfortunately, the assembly code would have to be re-writt=
en,
but that shouldn't be too much of a problem...  I'm just beginning to lea=
rn
asm, otherwise I would've taken a crack at it myself :)

Pete

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


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


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

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

On Mon, 7 Dec 1998, Kragen wrote:

> If we want to use GNU GPL libraries in Fractint, we'd have to change the
> licensing of Fractint (which currently prohibits selling Fractint for
> money).  Which means, I think, that we'd have to get consent from
> everyone whose code is currently in Fractint.  Which is probably
> infeasible.

    I'm not quite sure I understand what you meant, but there are a number
of implementations around that use less restrictive licences (Artistic, FreeBSD
like etc.) and several good libraries use LGPL wich does not force fractint to
become GPL itself.

> I don't think this is likely to come up for HTTP, anyway.

    Why?

    Humberto R. Baptista
    [e-mail]

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


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


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

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


    Hi,

    I told Tim recently that I've encountered some problems with arbitrary
precision when compiling the sources under BC 3.1 (no I haven't tried MSC).

    I  found Fractint in an infinite loop that was not suposed to happen in
floattobn (bignum.c). As I could figure port.h does _not_ define
USE_BIGNUM_C_CODE as it should (all the #defines are inside specific #if's) I
then tried to acivate a #define USE_BIGNUM_C_CODE that was commented out and the
infinite loop went away.

    Unfortunatedly fractint the started to print several messages (in the
"red" text messages, like errors) like if it was debugging and I could not make
it work, any ideas?

    The users of Borland BC 3.1 in the list have any clue?

    []'s

    Humberto R. Baptista
    [e-mail]

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


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


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

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


    Hi,

    Ive found a strange behaviour of the outside=atan in the unity fractal.
It seems that the one evaluation of atan and/or unity leaves something for the
next and we can see that easily changing the drawing method (for instance solig
guessing, 1 pass and teseral produce VERY different results). Is it something to
do with atan or unity? Is is a feature or a bug? :-)

    []'s

    Humberto R. Baptista
    [e-mail]

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


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


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

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

Humberto,

>> Ive found a strange behaviour of the outside=3Datan in the unity
fractal.It seems that the one evaluation of atan and/or unity leaves
something for the next and we can see that easily changing the drawing
method (for instance solid guessing, 1 pass and teseral produce VERY
different results). Is it something to do with atan or unity? <<

I went back to version 17.2 and the Unity type gives strange results in
that version also.  You can see similar problems with any of the outside=3D=

options except iter, so it isn't exclusively an outside=3Datan problem.

Jonathan

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


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

From: "Tim Wegner" <[e-mail]>
Subject: Re: (fractdev) Worklist and future directions
Date: 08 Dec 1998 17:57:45 -0600

Humberto asked:

>     Is the non-integer source avaliable anywhere? I could try to catch up
> with mu Unix programming skills and make the port to SVGAlib
>

I''ll upload it in a few days. However I should point out that you don't
need to wait for me - the XFRACT defines effectively eliminate
integer math anyway.

>     Hm I am not sure but I do not know if there is a port of the SVGAlib to
> DOS. Is it?

I believe that the SVGALIB for djgpp is essentially the same as the
UNIX version.

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: Humberto Rossetti Baptista <[e-mail]>
Subject: (fractdev) SVGALib and BC compiling.
Date: 09 Dec 1998 16:54:39 -0200 (EDT)

On Tue, 8 Dec 1998, Tim Wegner wrote:

> I believe that the SVGALIB for djgpp is essentially the same as the
> UNIX version.

    That sounds intresting I'll look into it this weekend (time permitting).

    About bugs in BC compiling:

    One i've already mention: the macro USE_BIGNUM_C_CODE was commented in
port.h. Uncommenting it avoided an infinite loop (mentioned in the comments). A
bug persisted and digging deeper I found some problems with the overlay options
in BC compile files/project files: FRACTALB.C cannot be overlaid because the
addresses of the routines bn/bfMODbailout are assigned to bignumbailout (I guess
in CMDFILES.C or somethign like it). In the ,LNK (link conf) user in BC the
FRACTALB.C was overlaid as a whole (different than MSC that overlays chunks
acording to directives on the code). Well summing up:

#define USE_BIGNUM_C_CODE must be ucomented (this could be problem in MSC as well)

FRACTALB.C must not be overlaid in BC (I'll send the new .LNK and .PRJ files to
Tim later today).

    []'s

    Humberto R. Baptista
    [e-mail]

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



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


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

From: "Tim Wegner" <[e-mail]>
Subject: (fractdev) function variable presets
Date: 12 Dec 1998 11:53:04 -0600

I have a question for users about the function variables in Fractint.
These are the variables fn1, fn2, etc. that are used in some built-in
fractal types and can also be used in formula types.


Currently there are no preset values for these that are fractal-type-
specific. For example, if fn1 = sin and fn2 = tanh, these values are
remembered when you change fractal types even though the
function variables probably have completely different meaning for
the new type.


<color><param>0100,0100,0100</param>I have two related issues, both relating to some code contributed
by Humberto Baptista.


<color><param>0000,0000,0000</param>1. Humberto has added a new type (another from the prolific Cliff
Pickover) that generates just a naked blue dot with the default
values of the function variables. This fractal type is begging for
some different default function variable values, but I'm not sure what
 the logic would be. Change to the defaults only when the fractal
type changes? But if you played with this fractal, moved to a
different type, then came back, would the function variables be
reset? Or should Fractint remember the function variable values,
and have separate defaults, for each fractal that uses them?


2. Humberto has also added a generalized popcornjul fractal. I
dislike adding new types unncessesarily, and would prefer to
merge the generalized type with the limited one. This, however,
requires making the function variables default to the values that
make the generalized popcornjul the same as the ungeneralized
one, so the issue of preset values for function variables comes up
again.


Does anyone object to giving all fractals that use function variables
preset values that are reset to the defaults whenever the fractal
type is changed to that type?


<color><param>0100,0100,0100</param>Tim





<nofill>

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: Phil McRevis <[e-mail]>
Subject: Re: (fractdev) function variable presets
Date: 12 Dec 1998 13:37:07 -0700


In article <[e-mail]>,
    "Tim Wegner" <[e-mail]>  writes:
> <color><param>0100,0100,0100</param>I have two related issues [...]

Umm..... Tim, what's that? ^^^^^^^^^^^

> Does anyone object to giving all fractals that use function variables
> preset values that are reset to the defaults whenever the fractal
> type is changed to that type?

Let me restate it to see if I understand it correctly:

    When you switch to a fractal type that uses the fn variables, they will
    be set to default values?

Sounds fine.  I would expect all fractal "state" to be initialized
when I switch fractal types.  I think there are some other little bits
of state that I have noticed didn't get reset, but I can't remember
what they are right now.
                    -- Rich

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: Humberto Rossetti Baptista <[e-mail]>
Subject: Re: (fractdev) function variable presets
Date: 13 Dec 1998 22:23:23 -0200 (EDT)

On Sat, 12 Dec 1998, Tim Wegner wrote:

> Does anyone object to giving all fractals that use function variables
> preset values that are reset to the defaults whenever the fractal
> type is changed to that type?

    Since this is the behaviour when it comes to numerica and bailout
options I guess it would beconsistente right now to make the same with preset
funcions. If sometime later fractint remembers all the other parameters then we
can extend (or build for) it to care for the functions.

    []'s

    Humberto R. Baptista
    [e-mail]

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


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


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

From: "Tim Wegner" <[e-mail]>
Subject: Re: (fractdev) function variable presets
Date: 13 Dec 1998 20:20:48 -0600

Humberto wrote:
>     Since this is the behaviour when it comes to numerica and bailout
> options I guess it would beconsistente right now to make the same with preset
> funcions. If sometime later fractint remembers all the other parameters then we
> can extend (or build for) it to care for the functions.

Jonathan Osuch pointed out to me that the generalized bifurcation
types already have function variable faults, so I'll just follow what he
did. The defaults get reset whenever you set that fractal type, but
you can change the settings as long as you don't change to a
different default. I've already done this for latoocartofian in my
version.

BTW Humberto, what country do you live in? I knew once but I
have forgotten. Not that it matters :-)

Tim

>
>     []'s
>
>     Humberto R. Baptista
>     [e-mail]
>
> ---------------------------------------------------------------------------
> Insite - Solucoes Internet                         http://www.insite.com.br
>
>
> --------------------------------------------------------------
> Thanks for using Fractdev, The Fractint Developer's Discussion List
> Post Message:   [e-mail]
> Get Commands:   [e-mail] "help"
> Administrator:  [e-mail]
> Unsubscribe:    [e-mail] "unsubscribe fractdev"
>



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: Humberto Rossetti Baptista <[e-mail]>
Subject: Re: (fractdev) function variable presets
Date: 14 Dec 1998 01:05:57 -0200 (EDT)

On Sun, 13 Dec 1998, Tim Wegner wrote:

> Jonathan Osuch pointed out to me that the generalized bifurcation
> types already have function variable faults, so I'll just follow what he
> did. The defaults get reset whenever you set that fractal type, but
> you can change the settings as long as you don't change to a
> different default. I've already done this for latoocartofian in my
> version.

    hmpf. I haven't dug enought :-))))

    Since you're in to it what about setting the default in the popcornjulfn
to sin/tan/sin/tan as in the original?

> BTW Humberto, what country do you live in? I knew once but I
> have forgotten. Not that it matters :-)

    At least my accent didn't gave me out :-)))) I live in Brasil, and it
matters when we are making fractint development statistics ("Developped in more
than nnn countries ...") and when it's time to return home ;->>>

    []'s

    Humberto R. Baptista
    [e-mail]

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


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


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

From: Ron Barnett <[e-mail]>
Subject: (fractdev) Exponential Smoothing
Date: 21 Dec 1998 18:59:28 -0500

Kerry Mitchell's ghost formulae provide a good platform to illustrate the
exponential smoothing method to provide smooth 24 bit coloring.  In his
formulae he applied the Vepstas log method which works well only for power
functions. With the formulae and pars presented here I apply exponential
smoothing to the mandelbrot set (to give a result very similar to Kerry's
application of the Vepstas formula), a more complex function using trig
functions, and a complex newton.

For non-convergent functions (e.g. the Mandelbrot function), use the
formula

iterexp = 0 (initialize)
iterexp = iterexp + exp(-cabs(z))

at each iteration. Then use iterexp to color rather than the iteration
number.

For convergent functions (e.g. any of the Newton methods), use the formula

iterexp = 0 (initialize)
oldz = 0 (initialize)
iterexp = iterexp + exp(-1/cabs(oldz-z))
oldz = z

The following are the formulae to use:
========================================================================
========

MandExpGhost = { ; Ron Barnett, 1998  - modified from Kerry Mitchell
        ;
        ; colors Mandelbrot set by combining the smoothed iteration
        ; with a background of rays from the center
        ;
        ; use decomp=256
        ; real(p1) = bailout
        ; imag(p1) = "ghost" adjustment: set to 0 for only
        ;   background rays, try 2
        ; calculation performed on variable zc, z used for coloring
        ;
        maxr = real(p1), scale = imag(p1)*pi/128
        iterexp = 0, iter = 1, zc = 0, c = pixel, background = pixel:
        iterexp = iterexp + exp(-cabs(zc)), iter = iter + 1, zc = sqr(zc)+c
        ;
        ; bailout
        ;   compute smoothed iteration as "angle"
        ;   multiply angle by background to get final z
        ;   set z to background for interior points
        ;   set "iteration done" flag (iter=-1)
        ;
        IF ((|zc| > maxr) || (iter == maxit))
          smooth = iterexp*scale
          ang = cos(smooth)+flip(sin(smooth))
          z = background*ang
          IF (iter == maxit)
            z = background
          ENDIF
          iter = -1
        ENDIF
        iter > 0
        }


JMaskghost = { ; Ron Barnett, 1998
        ; use decomp=256
        ; real(p1) = bailout
        ; imag(p1) = "ghost" adjustment:
        maxr = real(p1), scale = imag(p1)*pi/128
        iterexp = 0, iter = 1, zc = fn1(pixel), background = pixel:
        iterexp = iterexp + exp(-cabs(zc)), iter = iter + 1
        zc = P2*fn2(zc)^2 + P3
        IF ((cabs(zc) > maxr) || (iter == maxit))
          smooth = iterexp*scale
          ang = cos(smooth)+flip(sin(smooth))
          z = background*ang
          IF (iter == maxit)
            z = background
          ENDIF
          iter = -1
        ENDIF
        iter > 0
        }

CmplxNewtghost = { ; Ron Barnett, 1998
        ; use decomp=256
        ; real(p1) = bailout
        ; imag(p1) = "ghost" adjustment:
        ; p2 = complex power
        ; p3 = complex root
        maxr = real(p1), scale = imag(p1)*pi/128
        oldz = 0
        iterexp = 0, iter = 1, zc = pixel, background = pixel:
        iterexp = iterexp + exp(-1/cabs(oldz - zc)), iter = iter + 1
        oldz = zc
        z1 = (p2-1)*zc^p2 + p3
        z2 = p2*zc^(p2-1)
        zc = z1/z2
        IF ((0.000001 > cabs(oldz-zc)) || (iter == maxit))
          smooth = iterexp*scale
          ang = cos(smooth)+flip(sin(smooth))
          z = background*ang
          IF (iter == maxit)
            z = background
          ENDIF
          iter = -1
        ENDIF
        iter > 0
        }

==============================================================

Here are the actual pars:

MandExpGhost       { ; .                                     t=  0:01:02.12
                     ; Ron Barnett, Dec 1998
                     ; On a Toshiba Pentium II at 800 x 600
  reset=1960 type=formula formulafile=rebexp01.frm
  formulaname=mandexpghost passes=1 corners=-2.5/1.5/-1.5/1.5
  params=1000000/10 float=y maxiter=100 inside=0 decomp=256
  periodicity=0
  colors=e0W<42>10W00W00W00V<65>W0GW0GW1H<63>WxyWyzWzzWzz<50>z1Wz0Wz0W<20>\
  f0W cyclerange=0/255
  }

calipers           { ; .                                     t=  0:02:49.38
                     ; Copyright Ron Barnett, Dec 1998
                     ; On a Toshiba Pentium II at 800 x 600
  reset=1960 type=formula formulafile=rebexp01.frm
  formulaname=JMaskghost function=acos/cosh
  center-mag=-2.22045e-016/0/0.6666667/1/-90
  params=100/50/1/0/-0.766/0 float=y maxiter=1000 inside=0 decomp=256
  periodicity=0
  colors=mJ9<32>zVFzVGzWGzWGyVG<32>X1GW0GW0GW0G<80>zy0zz0zy0<48>W10W00W00<\
  47>mI9 cyclerange=0/255
  }

dirty_spiral       { ; .                                     t=  0:24:03.94
                     ; Copyright Ron Barnett, Dec 98
                     ; On a Toshiba Pentium II at 800 x 600
  reset=1960 type=formula formulafile=rebexp01.frm
  formulaname=jmaskghost function=atan/sin
  center-mag=-0.138173/0.415693/6.666667
  params=1000/5/1/0/0/0.5932500000000001 float=y maxiter=5000 inside=0
  decomp=256 periodicity=0
  colors=vSG<29>X1GW0GW0GW0G<80>zy0zz0zy0<48>W10W00W00<46>mI9mI9mJ9mJ9nK9<\
  28>yUFzVFzVFzVGzWGzWG<2>wTG cyclerange=0/255
  }

Complex Spiral     { ; .                                     t=  0:05:34.61
                     ; Copyright Ron Barnett, Dec 1998
                     ; On a Cyrix 6x86(P200+) at 800 x 600
  reset=1960 type=formula formulafile=rebexp01.frm
  formulaname=CmplxNewtghost passes=1
  center-mag=0.238245/0.19598/1.718213 params=1000000/4/1/4/1/3
  float=y maxiter=256 inside=0 decomp=256 periodicity=0
  colors=WWW<50>lD6lC6lD6<79>zy0zz0zz0zz0<64>XH0WG0WG0WG0<50>WWW
  cyclerange=0/255
  }

========================================================================
======

Ron Barnett

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