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

Internet Message Format | 1997-09-28 | 176KB

From: "Tim Wegner" <[e-mail]>
Subject: (fractdev) Latest sources
Date: 01 Sep 1997 21:35:42 -0600

We're up to 19.61 patch 12. The Xfract sources are in

ftp.phoenix.net/pub/USERS/twegner/tw05.zip

and a complete set of diff's (for the DOS version) is in

ftp.phoenix.net/pub/USERS/twegner/tw03.zip.

This version has the evolver and a temporary version of synchronous
orbits.

I deleted tw01.zip, which was the DOS executable for an earlier
patch. If anyone needs this and does not have access to CompuServe,
let me know. We've decided not to leave the executable in a public
place.

The last patch fixes some pretty bad xfractint bugs. Makes me wonder
if any serious users play with xfractint, because I had no reports!

I upped the length of directory buffers from 80 to 256. This is
because Xfractint hung when attempting to change to a new *.frm file.
I want to investigate this more because I'm afraid I have glossed
over a bug rather than fixed it. If anyone is setup to compile
Xfractint and is good at debugging, let me know and I'll tell you how
to attempt to duplicate the problem.

I still need to update the conversion of the binary data in GIF files
for some of the newer features.

Tim

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


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

From: Rich Thomson <[e-mail]>
Subject: Re: (fractdev) array initializations
Date: 02 Sep 1997 15:04:04 -0600


In article <[e-mail]> ,
    "Tim Wegner" <[e-mail]>  writes:
> static char *calcmodes[] = {"1","2", ... };
>
> If the "static" is removed, this still works OK under Microsoft C and
> Linux's gcc. Is this type of array initialization legal under ANSI C?

The 'static' is an (optional) storage class specifier.  The
declaration should be legal with or without the static.  However, some
code uses static variables within a function as a sort of "secret
global" to the function and removing the static may break code that is
depending on this.  However, I don't suspect that to be the case here.

> Anyone know what the ANSI C standard says about array initialization
> of local variables?

I'm not an ANSI expert, but I believe that arrays can be initialized
anywhere.  Were you looking for something more specific than that?
--
  ``Between stimulus and response is the will to choose.''  -- Steven Covey
 =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
     3D Paint: The Power to Create in 3D;        Rich Thomson
     email me for more info                [e-mail]

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


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

From: Rich Thomson <[e-mail]>
Subject: Re: (fractdev) Greetings
Date: 02 Sep 1997 17:08:21 -0600


In article <[e-mail]> ,
    "Tim Wegner" <[e-mail]>  writes:
> This is the biggy. Users will *not* accept a slower program, and the
> port *will* be slower without the assembler. I'd vote for forgetting
> the integer math, since floating point has comparable speed these
> days, but giving high priority to incorporating the floating point
> assembler, especially the fast parser.

Which brings up a question: what is the "target platform" for
fractint?  Is it 486s running DOS, or P90s running Win95?

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

I'm a little battle-shy of Tk having spent a lot of time trying to get
other Tcl/Tk based tools to work in unix environments without any
success.  Perhaps its gotten better since I last tried, but I would
argue against a Tk-based approach because: a) fractint doesn't need
scriptable dialogs and so-on which is what Tk is apparently good at.
As I outlined previously, fractint has relatively modest requests of
the windowing system when it comes to its UI.  (That may be because
the UI grew out of DOS where supporting the mouse in a meaningful way
was a pain in the ass.)  All window systems are pretty much the same.
Writing simple UI components (if you make them C++ classes, fine, just
don't expose the OS/Window System in your class interface, make it
abstract) should make fractint's UI portable to other environments.

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

As was pointed out, this could change... but building in a portable
non-OS/WindowSystem specific in NOW will save huge amounts of grief
later.

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

Yes, I'd favor a complete redesign if we were to move in this
direction.  Right now I'm not sure that porting to C++ is a win.
I understand the benefits of C++, I program it all day long at
work, I'm just not sure that its worth the effort.  I can see how
writing an "Iterates" class could be helpful as it would automatically
shift from fixed point to floating point to arbitrary precision based
on the zoom level and this could be reused for all fractal types.
But is this a big enough win to warrant the effort?
--
  ``Between stimulus and response is the will to choose.''  -- Steven Covey
 =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
     3D Paint: The Power to Create in 3D;        Rich Thomson
     email me for more info                [e-mail]

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


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

From: Rich Thomson <[e-mail]>
Subject: Re: (fractdev) Greetings
Date: 02 Sep 1997 16:22:11 -0600


In article <[e-mail]> ,
    "Tim Wegner" <[e-mail]>  writes:
> The fast parser has a pretty good optimizer. George Martin and I are
> just starting to understand it. Very possibly some of the
> optimizations could be done in C also.

I've seen people posting tutorials about how to factor out
sub-expressions that don't vary per-pixel and constant expressions and
so-on.  Is the optimizer good enough to recognize these?  Also, does
it replace z*z with sqr(z), those sorts of things?  The kinds of
suggestions that people make about optimizing formulas for speed are
the kinds of things an optimizer should be able to accomplish with a
modicum of effort.
--
  ``Between stimulus and response is the will to choose.''  -- Steven Covey
 =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
     3D Paint: The Power to Create in 3D;        Rich Thomson
     email me for more info                [e-mail]


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


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

From: "Tim Wegner" <[e-mail]>
Subject: Re: (fractdev) Greetings
Date: 03 Sep 1997 17:14:57 -0600


> Tim, you didn't mention anything about that fractint source code URL I
> mailed you.  Did you miss that mail?  There has been a lot of
> discussion lately! <g>

I did see it, didn't answer, my apologies. It looks useful, I suggest
you share the URL. Your tool does better with C than assembler <g!>

Tim


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


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

From: Rich Thomson <[e-mail]>
Subject: Re: (fractdev) Greetings
Date: 03 Sep 1997 16:31:25 -0600


In article <[e-mail]> ,
    "Tim Wegner" <[e-mail]>  writes:
> I did see it, didn't answer, my apologies. It looks useful, I suggest
> you share the URL. Your tool does better with C than assembler <g!>

OK, take a look at <URL:
http://www.xmission.com/~legalize/fractint/src/index.html>.

My "tool" is simply a perl script :).

Emacs comes with something called "etags" that extracts tags from
source files (assembly, C, fortrash, pascal, etc.) and records them in
a file called TAGS.  Emacs uses this TAGS database to let you browse
through the source code.  I wrote a perl script that takes the TAGS
database and generates a collection of web pages from the items found
by etags and cross-links them together.  Each source file is annotated
with the line number on the left hand side as well.  That way we can
say "look at lines 50-60 of frobnicate.c and you'll see...." when we
are talking about specific items in the fractint source.  I can
regenerate the web pages automatically any time the source code
changes.
--
  ``Between stimulus and response is the will to choose.''  -- Steven Covey
 =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
     3D Paint: The Power to Create in 3D;        Rich Thomson
     email me for more info                [e-mail]

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


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

From: Rich Thomson <[e-mail]>
Subject: (fractdev) free, portable GUI framework
Date: 03 Sep 1997 16:32:39 -0600

I don't know if this is something we want to use or not.  Its C++, not
C.  However, the source code is available and it looks like it works
well on X as well as Win95.  I haven't used it, only learned about it
today :)

<URL: http://www.cs.unm.edu/~wampler/vgui/vgui.html>
--
  ``Between stimulus and response is the will to choose.''  -- Steven Covey
 =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
     3D Paint: The Power to Create in 3D;        Rich Thomson
     email me for more info                [e-mail]

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


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

From: robin bussell <[e-mail]>
Subject: (fractdev) Wishlist MK II
Date: 04 Sep 1997 21:14:37 -0600

Okay folks I've put up a new version of the fractint wishlist, see what
you think. I've included some suggestions from Lee to seed things and
get off on a good footing.
here's the address:

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

Do we make this official?

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) Wishlist MK II
Date: 04 Sep 1997 22:25:32 -0600


> Do we make this official?

I don't know what "official" means, but I have no problem with your
publicizing the URL. Thanks for taking the initiative.

Tim


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


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

From: Rich Thomson <[e-mail]>
Subject: (fractdev) XaoS
Date: 08 Sep 1997 16:45:14 -0600

What do the people on this list think of the XaoS program?
<URL: http://www.paru.cas.cz/~hubicka/XaoS/>
--
  ``Between stimulus and response is the will to choose.''  -- Steven Covey
 =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
     3D Paint: The Power to Create in 3D;        Rich Thomson
     email me for more info                [e-mail]

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


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

From: "Tim Wegner" <[e-mail]>
Subject: (Fwd) Re: (fractdev) XaoS
Date: 09 Sep 1997 23:16:02 -0600

> What do the people on this list think of the XaoS program?

I looked at it briefly (there's a DOS version, I'll try the X also)
and it looks very interesting, amd the source is public!

Tim


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


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

From: "Damien M. Jones" <[e-mail]>
Subject: Re: (fractdev) XaoS
Date: 10 Sep 1997 00:58:25 -0400

Rich,

 - What do the people on this list think of the XaoS program?

XaoS is interesting, but it's a different approach to fractals than
FractInt.  XaoS emphasizes speed and sacrifices rendering quality to
achieve it.  (Yes, you can stop it and do a full render, but that sort of
defeats the purpose of the program, IMO.)  It's neat to be able to "zoom"
is real-time, even if you have to keep the resolution pretty low to have a
decent frame rate. :)

I don't think it's the sort of thing FractInt needs to be doing, but hey,
that's just my opinion. :)  Adding that kind of capability would involve a
full-screen blit every time the screen is redrawn, which means having a
copy of the screen in system RAM, which can get big in a hurry.  Maybe in a
32-bit DOS version this would be practical, but... ick.  And if FractInt's
video drivers don't have full-screen blit support, forget about
performance... or write blit routines for all the drivers so you can have
performance (big chore).

Of course, it's late and I really ought to know better than to offer
technical commentary when I'm not in full command of my mental faculties.
I'm liable to get something wrong.  So if I'm off base in the blather
above, please feel free to correct me.  :)

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


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


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

From: "Damien M. Jones" <[e-mail]>
Subject: Re: (fractdev) XaoS
Date: 10 Sep 1997 00:58:25 -0400

Rich,

 - What do the people on this list think of the XaoS program?

XaoS is interesting, but it's a different approach to fractals than
FractInt.  XaoS emphasizes speed and sacrifices rendering quality to
achieve it.  (Yes, you can stop it and do a full render, but that sort of
defeats the purpose of the program, IMO.)  It's neat to be able to "zoom"
is real-time, even if you have to keep the resolution pretty low to have a
decent frame rate. :)

I don't think it's the sort of thing FractInt needs to be doing, but hey,
that's just my opinion. :)  Adding that kind of capability would involve a
full-screen blit every time the screen is redrawn, which means having a
copy of the screen in system RAM, which can get big in a hurry.  Maybe in a
32-bit DOS version this would be practical, but... ick.  And if FractInt's
video drivers don't have full-screen blit support, forget about
performance... or write blit routines for all the drivers so you can have
performance (big chore).

Of course, it's late and I really ought to know better than to offer
technical commentary when I'm not in full command of my mental faculties.
I'm liable to get something wrong.  So if I'm off base in the blather
above, please feel free to correct me.  :)

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


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


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

From: "Damien M. Jones" <[e-mail]>
Subject: (fractdev) Coloring algorithms
Date: 10 Sep 1997 01:16:06 -0400

--=====================_873882966==_
Content-Type: text/plain; charset="us-ascii"

Hey folks,

Tim asked me to send my coloring algorithm FRMs when I "finished" them and
weeded out the boring ones.  So I've attached the FRM file to this message.
 It's ZIPped, because the ZIP is 7K, and the unpacked FRM itself is 170K...

Most of the coloring techniques are of the "orbit trap" variety.  However,
they are not like the average orbit trap.  Usually, when an orbit point
enters the trap, it bails out and is colored immediately.  The method I use
is to simply track which point comes closest to the trap, and when the
point finally bails out through the normal method, color based on that
point.  Since points are merely "tagged" and not trapped, I probably
shouldn't call them "trap" types...

The trap shapes included in this FRM file are points, rings, hyperbolae,
rectangles, crosses, and spirals.  Each trap shape has a version that
returns the distance to the trap, the angle between the tagged point and
the trap, the angle between the tagged point and the origin, and the
iteration number of the tagged point.  Each of these combinations includes
a version that plots inside points with the same method; and each
combination is available for Mandelbrot and NovaM fractals.  (Yes, this
means there are about 100 formulae in the file.)

I have also included a formula for Linas Vepstas' continuous coloring
algorithm, in three flavors; also, Kerry Mitchell's triangle inequality
coloring algorithm, from which I removed all banding.  There are also two
customized flavors of Kerry's "average theta" algorithm, again with no
banding.

The reason I'm posting this here is that I'd like anyone here with an
interest to test the formulae and see if they work for them. :)  I'd like
to release the file so people can play.  I've been meaning to post some
pictures generated with these techniques, but I've been so busy lately I
haven't had a chance.  (Haven't had much time to work on a 32-bit Windows
FractInt, either.)  Any feedback would be appreciated.

--=====================_873882966==_
Content-Type: application/zip; name="dmj-pub.zip";
 x-mac-type="705A4950"; x-mac-creator="705A4950"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="dmj-pub.zip"

UEsDBBQACAAIAOEFKiOzdsUDQh4AAESnAgALAAAAZG1qLXB1Yi5mcm3tnWtz2zbWx1+7M/0OWL9o
JceSLbreNk7b2dRONt5tmoyTPk27052hREjihiIVkrIjb/a7P+fgQpGUbIuKL5T990ximcLl4ODg
hwPgCHoivNF/WuNJt92PR19+8UQ8j91eehym4nkUjyaBK577gRTdqThyR74Mxcu2+EcUyuTLL778
4kS6XuulbD334yQV/32SL0t02ruiJd7IcSpHXRmLx9ui8/jxt19+sfFEvOnFURAILzoLRePw7cnP
raNXv/3SFGkkEimFS+9FfZEO/USk8mPa5kwq41t+1DeS9VmyXhSmrh9mT6U4i/00JUkXyUxFNM6G
0UhMo4nouaHO3kvFqe8K2Rq5fiDclNvxN7/ntXvRqJmvXCZyVs84jk59T4pQnlExQRT74YBEH9CL
dDhKuDHpUIqXbujJoBtHqSqkz/p1A3H+r/BR50/xA7/489+OeCR6glKK1+4kEEcy7k6ToR/LrxPx
S3TqvhTpdCxVAYWMpOGGKmCv1WmKHdHY08U1ubyZ5L9Ta8980moopceCTbghQeSmJHNrHPnU3yM3
HYpGFCqh34mxO5BNypQOVQlZl7AKWJakLcRxX+nRi8Kv0231UlUykKGMKcOUXqXCVfmTKPC9llIT
SeCPqHRxNvR7Q0EdGlPVZCHeJAioVN1eo6eEak4iVUQsP0xII2IsY9+Len465ZZ0SZxJHFKhr54/
F41xLJNEDLZn+trk9JHnc4Yfdjdz/fnq5Kfjt+LtydPX4uWzty9eHb1Rj0Vm+qE7ksqwRBR3/VSk
sTvWjRcuCTLwT8m43MTkYuN/9+5d6/fff2/98ccf/2od/zmri9440NbLNk0atnbAxbVNCWwq1KNv
Y9fzUz8K6e2Z9dDISG1CVhElVL9etuwbuqt//71YkRZ9k2Xf1LUJ8Zp7PKGOEyEVTIJMuLtM4fTT
5XEQTVLqIqkMYqoazGWMpbc9e5L4ozH1c+oOBtKb5WeVBW4qYyvwazIwEljVS/X/xj0vT6nPlRFT
qXHk0pNE9IIokQQT6tlxh5owK5N/yGw9yn7kJ6kb9jg5DWGyAI8eRHFKRkCDvjd0wwGPxbHjF7Mb
w9+UQeCPU7/nBpsqK5cliCEp8YytvOfHPer/eLuYnXuHOsLlenhgUAVZA19Mx9xA+kVDNwrcZRvp
fpSlNnqxe8Y6j6PJYKiVMN9u1v1IuskkzqudfzaHRgRuXjDd3KahR6UR1DZ5/OjmpptirE2AaVYs
wOZ32VB+JXVRK1lS3XJlUix0TkKrg0M/Zh3Qr14gl1ZAsXYN0ZRK3RY8DCaJGO/52zkl/FTsYSqj
1Evi1A0mZPeKKdTyUHSIa7HYbW5r6ZOxJOITdPzIMG2BDMay3ICsmE2eO59zK9shreQNoZg9ZxWH
sTPTyL8dkl6NzDOXejAUMo5JrF4sdUFDns5G7nuufU4mXcSMQNuiS8OTBjbp1JuwSVB3kqQJE13z
tWRXDcnt9hWXlfVya44kTXHjKFG4Ecmk2+LCm9mwJf7ysA0myS0a9FyXsqS2CvejnzwpWoCadFRH
qZSbuoM358Z+3z1llIdSFSKiU5NBWQpJ85TNeuROud9N9xbLKA/6k56i2gnVRuIsb/PLkK2kED1n
uDFPwFoJlyt528yuxozL2GJzLhaQvJdnuqZL1WRL8K0O3ox91gH9oil/aSMRiUpfFKEnlQl7evzn
zIQcL5OBHwbRwFUult9rFwt46w+GacgOgB7WuUzs57HPmdOBHtMl/oz80B9NRiKcKKeVyvFJJkYF
uZhqAPX9WRmZFk7IatgS3OnyKojdabFuchzJppVPZlSgqlGmpTptppGnVtBiCQulNiZwsfBHJ0r4
I3ICqrVg7PpxqQl9blZyaVMSa4D8+1Hnu91iEQsaeVm7Sla8uJEqEflkRc/ID3n2U6XpGZJdUWm8
yX5MqwQFHuPazyrKfHyrwKfUSlLgU8MANlfdacYMjd+k51ya1yT5RuQ7LuQcp93OS2JmYa9Aah6g
kzTh5ccPpemP+CEKXrxaVQ2jM9Jd1uOyp3o8X+bVgpdmyVkrjJ/JXb5A9BKoLmzHJaKXLGTWjkQB
2FLTNCFz6Ra1IuvYkup5Yp3X+kw4mqWDOeFKxldU8nGq3KFja7FGusyCF4tXBns1gS7WlnrYOj7g
RVtqBgGZvHJpQs/K0s+tfLatj8hjIyvzLJoEHi0baOCwJ0Fg2STPmUTa1PMwTzZUoOJ45mYkVFxW
QjZ8yBPTE7ZplHVKqam8YH3565u3am2X5cyt5Ejgvlpm6E2CiOSK37MzRGmC6azFr92Y6iaVJwcb
/GOUciT7tM5OD0zRxKeD/BpPz0SmR3bEPyaB74rexkZjd3u3afM48YGeV6kvyexDMu1BLGWyrZRJ
xVB1u1li/6DoeDaGpIRz3n0IDgi0ajXSzHJ2bL49qkQRSCSUgHGqvFtuyrf7WSIqnJdsvGLbEfIj
FUEGYRpOKTvOd/S8M1v4vn3x7KS05n0q+vLMzPGUbxh52gfh5Tc1rhdMPOpReteMMrJFettkZnPx
8gtgtfgVvOpdtN7d5p4PaJRmDpbbJTeDMrSOSZN9wat4yaj0Q+pu8lzYvVV2r6ZyvYnAkl2y7s22
ZHRrMn9lFFEj2QZaWXJXuQd+OIkmid6jyDGefG/jbBbHlbbIvVibfSBTtQGi3VAGAS22eu95bUyy
jF16P5ULCgiiaMwG/8zlrRCyugFlnyGiy9OkqmDonsoLBFAScyFv46kWIGyPyIr1FEgJEqkmbGd/
v72wCN/qzBjRNpmyGh9sj2Q8VHTjJ5cmZeLNggI4pxp+lPpnmvUT8X9yTAhO2s2C0l+/OMwp3XKB
bUG/r9c0NPnTm2eRbtaC6nggUJLGzIvwm+qFWgEFkhSlSh8tWJtl8rIsns/WfpGJvHPyJpL4Iz9w
1UI4a4yWVyH8EnFjMh4SSHUi7z4kkocmraTHUawdGcPei42k0VcbrEM36NNyniZQaiz/ka3T3sa+
nretxNokqD91p4l/0lpzKl76KTlxQfA16cfkWFCbH8oP5AoyZLVeRIPbmahmk0HPxkpzkTkdZrRS
o5VtrztlM3ySMUr9nbmfBJPU/S03IsvCq0U7MZKnuMw9odlnQeXsrlpHxuTg9bbkhQEVZrdCFJBY
p4uanw2+XjTR0x+txKKE960axyEvKfQ+k9LpggKsljPr1w10bruBgXsb7VMJDl88/eXvx7/8XdDE
Ip6/Onn5689Pn5msimzWr+DBpJapkmATRL33iWmMtnAaGSmJRQ1Lci4aLQJSnwzyvOA25dwIGg59
Gl5q5yO07LKTY+YA2IWkHj+mKnN4oApU26B2olpct8JMpsBGGg0kM6Rpd3YM17hwU4DqDvLK2GtS
vtE4cHt6oa02MeT8brCSM8vux4uE7U6C91YT84cP9MiTT2wR0Zkbe4l19fRG/Uwi3mEoSWPH6fFz
UwRrTDvsvtryj9WhR15o4pFZH9MDk3+Wmadus2xr88ERPU+JR4ucWVaiquPrWKrH7GRGdpuT9c8Q
dY1TxNNc4L/nwwzq5ama9uhxl1ykhP9QlU2pgrH/UQZbDp+X7G23nPY3zW0+t+C6d7f1SMi9dPg1
5VSrkm7SYDka06Y6puG9NfW6uSDBXi7BHh/CyAWJGq39Zi4d/5lPKsWW6OzyT/agxYc1UdyQOzQb
N7fYn3sk9hx635uMRty+syGZZfKBnpyz7Aeq4fzynFKy52ebqH/rZ8fPhRVKfC9au+1v9rlRtEij
hJ+mrCz1cJv+391vflLvcSZP/Cjo0a6zL776ilJ/z385jsktxBNP9CaxclgIAD+/eWaeG423OvqN
X47Ywug1JykI8wNL4zSzCotvfGPr4bcaRo8sEktj/2SZOk3x6ZPIpeBSi4lanMqWx5IrwbtunJhn
OfHLDciaYFop5hS6l69sUfWUZKY08pmC90vpjF4tUtusOH6c1aKUtrs/L0tejwW5O6w3+4T72lGK
zD3hwvL1FpQ4Ui35fA0qs7N6yNvkbtEml7NKFiyQ/TSNxtUlm5OCmryqEDHP1tWlKHf9XEf/qPph
QZ/yG/vlHvtr0R4uM00S+j+eOsCuqLWidGxY+8vLl699NjQq15+v5JsF5mQJ16nckf+ZQW4VW5oT
bm6A7s2xyslXT+5AsJoNsQXNXqrmcp4faerQFfCc0jDqyQZbk2cmUgJNH/nHKkM2b5oXNMNslO3U
pslqIX/WzG/qrYKIOfky2b784n88XzxpXdsPh7zwGXsg1Rk7e56Zl8L7Gfxe63WYtnir8b/iScln
Ocg2xLNNR7Vjzoc8avNIbX4r1+U3tRrvsF55F2mb1q32dbYhl18TK0cs6v9112x9qEIyVy8aaw9U
fuzJsToI5BV4YsVjh/RYbWir/RuzetWOV6RjTA7dmN4KaS24+dOk26Ul9aYNRjAmoQxv7DR1h21Q
3uPwlHxhz5yw8vZbfk+rrfrPNqvDPo0ybyqCM7+ZdJPUTycpu292g0GV1M51dzYoxnuXVjzbFJOm
3j2q99t961hR9mqV2lyXVWoc21yF3FByybKmUq3LVmot5wfRkY/2vtvgKg/tKac5ceEFXd9VB47a
nkg2lVBFUugFAJlYr5StbQfND8JRyY+Liz4dmBFnHfVvq3OnufN4l5twGI3GLL/d4KSR0UujuJ35
lewqW7/6gKvIRaoUF01tkyP5EDfOVWDSRik9dSLHW5jEM9nVLwYJpz/iP/jfiFYDs0WYKl2Z3Hlr
3GFCxSr5q37fbHvRmJtFbmTJVXvPVaBUP/DHuvv57y1h7b5Jw/1IR5YYO1d65Ynj3Pmk+8uoKRv9
ur5G8mHi0ppFbZDoyeR720nNrJ9NdMI4lqd+NElmFiKE7exzVcsbl49ZuKPVc51kZj5ePpFcaAx5
Q/90/olmF2vuzZk1MUuklxSt3PRc2rDis4bt+GzpLnoiTtQphRmUtAZX6zm1aiUTPdclZbOSFpc6
hxZtA3XiHMU9qSIiPurTikXsN/pWe0+S14hq3cwl8I5KINUo+d8ibreOr5ncy+C6eG64Eq4tqvUW
C3ANXAPXDx3XvAy3SBy5hMsmLQQW81vsGBTdD5BzkEUR4zqU4GC2ZW5VeRHIS6EGOliZQxhckQS8
Jg+mZBr9voxlmGYAb88izw3zdYX5AAgVBAkOg8PgMNxmS1stTYtaxoktWU01OZHujKdzjjGICqKC
qCBqXTzbCq5tvWHLAbe1Re0sehfIBXKBXDixZSd2o6ZMrbMDC6qCqqAqHNmVHNlaApc/0LToIC1c
BrSVDtE6qx2igbPgLDhbD86yBooUncXN64/z3tl+rBYt42vhA5l1gu0FcQvALXAL3AK3d4nba9qs
rT2JX0zHV0b+WgRnFydZDF8PpGZGp6Y5kOr6SbWx/qjyzGfMcnSy4Mq3fXY5WEai+7FNaUuci2na
qGtMk0HLFcGpgAvgArjc7m7d8n7MelJnhUjKOfxUit8BpAApQOrBRhsa5lQ/rAV1QB1QZz1do3rj
aIV4vOowWhQBAigBSoDSg4xZM9y5DTcI5AF5QJ7auUO1RFKlqC5sQwMuDxAu5dP1O9/kWYuD84oh
TGAL2AK21Hgrp/bQOfTjpaN1Zl80tvZhjDdMOKUp/V1sJcoVGAfIPYB4RkZkj//jDC2RN7pMc2wu
9V/V8RS9cS8DiwwFlwwsAgfBQXDwQXPwgYVAMR9XCIHKg/JB3F4EnAKnwOkNuZX1DY8weKx+TAlA
ApAAJAB5s/5mvcG5QlxZJWzep0uFgE/gE/i8Sf9yo6aIvGHfEpAEJAFJ+Jj3LFiP4VkpWA9HO8Ag
MFh3DN5o/E/V7ci1CPGpGFcIDAKDwOBDx+ADiYCMHURAgos3xEWtAsO5wscWDg3epFGTMPcagqYz
mjb4MkhmqVbRhSTN6w6xk3fCT8ROgqAgKAiKqMtrJSuiLgFigBggRrzm9YMV8ZpAK9AKtCLS85Z2
CRDpCfACvAAvYkRvBK6IEQVegVfgFdGlt4ddRJcCoAAoAIq41FXxibhUABQABUAR0Xpt34UeJEtH
tPbiKEmAVFxb/GCvLVa9/dyPSYP5wHzPMeksRLcyZKph3Iuo1LlIfofA5zXNSC8k0cOVMWiwwC3U
/fNrwi1i3qTS9cqmiS8ZvhN6LhnPCn6Cn+An+InvUV4KrCuEsxYIi6ArcBgcBofxVdFlrFY//AdY
AVaAFWDFt2GvskNQPZa1Gm8RbQXugrvg7sP6wm+D1pt2ZgFXwBVwBVzxneYZdSsFsuLUC/wEP+8j
P/G17SvCs0oYK/AJfAKfwCe+mf4Srp700uXvZaWholf5gCqgCqheC1R/vASq1Jk0ghHKWu+IK4PQ
Za9mBUQBUUAUEEU869J0XeV61jJmEXoFGAPGgDGCWufYusKNVqAr6Aq6gq6IbF11w2CFW1orQxcB
WIAv4Av4PrDwVsPX23BrQVgQFoQFYRHjOkNvtctacRwGiAKi9xWiCHRdkaCV7msFQ8FQMBQMRbTr
FXB9M/aXjnZNxn7sBiWk2gF2GV9SfzBMQ5kkOZ52ilhzKmINQL09oNaVjOfmLKNERYvCzk6jx5hj
EmbhPU5TMXEwoRIzgDX88FTGqfSa5fnDM0PqwllDC+JkeD4p0pjKb+SRvGOZqy7ALsuRjbF2/Vfq
X31l6Fi40vvehbIaPi4ZygpCgpAg5EMl5DKIXORUvpqkf1lzRK4Qj1pkZaVwKRAVRAVR4XMu5XPW
N+rJgLP6qTzQCXQCnUDnjTuj9WbnChGjFcm5KJgJBAVBQVA4n8s7nxs1heeNO57AJ/AJfMIB/UwH
tJb8rBTTiXMhkBAkXAcS3k5o0WdtZK5FTFHFgE0AEoAEIB8wIK91u7L+hBxFUTpsvHv67vhNcyEl
E5UiJ7oijh8O1LJ7vBcf5BhEj2mIst1Qv5qxTnV3qDRqpBxIxkboJU2T2T/IQlcL6YkiJfiuQsHO
mkHwakr5gZpWdoJo0HDamVAyTqSgZ8IRDRoyDB41yoMxpea0/C9TgsplntoGNIsZa0jD1T5b0jDF
O1ukui3SR0uoF0Ynmp3NZg6eWZjLnY7I1y8OVxmNzkWjsbPUeHT8C7I71z2cnYrD+Rq8qWU+crO4
4s/7xA0wst4Y4RxnQyok+aA/dfI0oAJD8oASIZVb+mHixsZeVqWOU6DOs5/fPFuxuMzK88UZw7g7
nL1zVqCZ+iMRu62O860gDQu33yefVHqiO53jWz4HDZyWs79/VR4HzAQzwcw1ZmYuO3X8VqNxvrXb
3t399ruOs88ETONJ2Cs8bF4XX1eomlXtfFci8rlZ4ysRWmJfrxZH0aksYHFyd0vEt7GvDlQvWySm
Jg2ZpqSeDfx0KmjBHbsDqTCnz17dQFAmV31YlKQdkU2KfhyNxM9t8U8Zx1Px0k97QxkEKtMo8vy+
Lz29vRallL2nJefiieck4rZ43Pqu9fjba1gtrt2eWTIZmS0wtplJGPLko/SU2/LqXEw0lwGjjFtR
Ron8tJtEAderZY76mkBFRN0WCvvW0CnlL2TgMU2s1AY2o6w9U5nmqKmErUROV21uEd1mu0TunA76
6qPLVOdoBdgG0VmXlG4/E80VtoTbUx8CN2lZbWfsGKh0bCjUt+2si/n/R8JyiHLbIptiR3CBj6gr
c08pozEKFkN0ZXomZahLT9o5IlSbAljyalNAX3yvhkL26e/UH0nqdaKWn4pBJNyBq0IyFEu5u69C
MMtKhS2wBFtKFHgzre1kO3DZ/p/Bkr5WIbelrGeFjfznyllaMXZJ7kLLhFhUwdN8ufkm9aktTtuA
Xz8yMlKf0q+W/osnl77ggUQtGkfKKowV2ImmP79JoaaMbH/Rti23W1ppxphNTNc7d7SOMXlg8sDk
gclj7koLfYDSUkdWmE0wm1w6mwxl6v62cA45k3z8TrjXkaNR4qsBfr3TiK6EQcm5L5lUHt/9pHI5
33VLMsIfTuJY0tDTj5ebAD6H4zxp1QThFXmsDqzzx8HWEeZxPaLiR6T3EkX08Xlr7JRP8R39fp7T
lx2mb5leYxMYiclYxzmbeJOsR82LLbHbNpsJ3oTG5axry4NxlX0g7sCNNVgAXDurLYL3HjSCLwio
AoQBYUD4NiE8F4nU6lwRvwkq31sqO4Dybex8gLnXztwtwuQV3F0EXHiyYObnMhOuLKgJasL1BEYr
YfRJ69p+qDAarqfuS8E0oH5L2hbU/Lj1OkyvvBg6+3SJ/RiX/gDG/bhz35LjlkLoOGKJfzoP6dJ9
g/ZOeTLQhrlgHtABbF42HfCz3qSrnmRvbolzfk7Dn5+aOs5bDZ2SgLnT2NuyqZuPelmFt3xfv0pu
Z42Cj8B/bxU+G3pEQy2KUzNS7IfAPp07nwofI8t/3ovqa9hG1vN+FeqhFk1s34u8Y3TFR0uo39OG
bcICbtfwltQ8T6+4SPpyolKlv/npkHtWM6O5TTXPbmBJXJouXf26G/X/umu+l6AY4B2N1SBssIrH
ygE4i+L3iZWp2SafQQVDuwERI/FHfuByMAe5TxPtTh+6Mb0Vfp2IzZ8m3S55OJsinY5lG9AH9AF9
QL8S9Bd8rrfCN62s83ywwq3Z5flglpUXpOLMDwIx4Ou3XJEEvM8RTMk++n2pDrnsPNCueGsscA6c
A+fA+TX58LW8VjZP5eo3I4LL4DK4DC7fVze73she4Sbw2wP2oltwAW6AG+AGuK/Tod6oKZnr7EyD
zWAz2Aw236FTXUtsV7rd/LPOKDurnVGC1qA1aH1faF2+VDh/C1M4GXVlfKf71HW+TziP7Co3rgPa
gDagDWivF7SvZxO79jx/MR1fGXxtQT6cjmXcjQJ34bdnrNWtSg+SdxsPG3j2jqUc47IP0uT0Zq3c
72U8uz/bt7bUuei1jbpGrxlAXRHNDEQBUUDUfd/FXE96rRB7O4exSrFagB1gB9ghPvU6yFX9SB3s
ArvAroftqNUbayvEcFaH2qJ4H8ANcAPcEOf4ufS6DacM/AK/wC/EAt4m2irFAmKrH5ACpK4hmqIW
G2BrEShRMfANhAKhQKhaE+qBRHkd+vHSUV6xuq/4XlysecOkVJqKXc+fJKXv7CtQEphEHO2lcbQM
WX3dscMBDXmDzbTOprYmq9SZr3Af49EMSpeMRwNMAVPAFDD9fJgu8FStnd6ngDnG6woBc3nOPoh7
zUBj0Bg0rrNrW98YGMPY6qfIoCwoC8qCsrX2eevN3RViDytR9z5dMwb6gr6gb+193I2acvaG/VuQ
FqQFaUHaO/Vza8neSmGcOCEDRUHR+0zRm4/mWmVbdi1itioGnIKlYClYCpbe/eZr/ekaO4iIBVZv
CKtaBQaSM3WrL7TWhJNGTcJQEDC+Hhg3+FJaRrFW74UgzusdsbR3C2HE0gLDwDAwjCjcOoEZUbjg
ODgOjj9Ud7rGcWSazojfBZ/BZ/AZfvZaEBuRv+A2uA1uw6+uZdyaJjRihsFoMBqMhm+9HtHGRG1E
G4O/4C/46yFO+S4ZjDhlUBgUBoUR4VwTLr8OkqUjnHtxlCQgMq5Hx4dHVr4eXdnLcz8m7ec/7eE5
Jp0l8VbGXQWCXkSlzn08xCFOeU3DikISPeCZpQYs3ELdt78m3CImVipdr2zc+PL6O2PwkgHOoDAo
DAqDwvX6ZrH7GN/MXF4hvrkAaATQAePAODC+zl9wW8tgOQPn6qEYwDPwDDwDz/fTy643sFeIbq6G
a4TOAdvANrC9Bl71Rk0BfdMeNRANRAPRQPRaeta1hHal2GYcHwK/wC/wezdRdStsPa9FCF3F0GZA
GBAGhAHhu4Xw/Y5sPumly9/dTGNM71SAyWAymFwTJv94CZPJEIgBCG+ufxidAfGy9zcDxUAxUAwU
I8b5tuC8yh3OZUojkA4sB8vBcgQ63xChV7hzDowGo8FoMBrRzne06bHCXc6VmY1wOrAb7Aa7EfK8
OqVvw7cGp8FpcBqcRtzztZG72p3OOFcEg8FgMBjBzzfA4Ur3OoPEIDFIDBIjAvpm2fxm7C8dAZ2M
/dgNSkS2I/MyPKX+YJiGMklyOO4UqehUpCJ4fNs8vo9gPTfnQiWoWpJ2dho9piSDNIvXcpoKqYMJ
lZjxr+GHpzJOScTy1OWZQXnhhKUFcTK6nxRhTuU38kTfschWt+2X5chGaXtNdhu++srAtfAlAvcu
vtlgdsn4ZoAWoAVoAdpVQbs0aRe5tq8m6V/WnLQrBCsXkVspCg5gBpgBZoD5Nj3g+ga1Gf5WD5cA
gUFgEBgEXhfXuN4IXiGuuCKAFwWrAcQAMUAMEN+6K7xRUwbfuBsMCoPCoDAoXA93uJYYrhQCjKM3
ABVAfRhAvcUYss/a5F2LILKKAb7gLDgLzoKztdrKrSdo/x9QSwcIs3bFA0IeAABEpwIAUEsBAhQL
FAAKAAgA4QUqI7N2xQNCHgAARKcCAAsAAAAAAAAAAQAgAAAAAAAAAGRtai1wdWIuZnJtUEsFBgAA
AAABAAEAOQAAAHseAAAAAA==
--=====================_873882966==_
Content-Type: text/plain; charset="us-ascii"


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

--=====================_873882966==_--


Thanks for using Fractdev, 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: Part 2 of (fractdev) Coloring algorithms
Date: 10 Sep 1997 09:06:17 -0400

Damien,

    A few style thoughts on your very interesting dmj-pub.frm formulas.

    I like your technique of using empty lines to block the
formulas into logical sections. This has not been done by anyone before
to my knowledge, but blank lines in a formula are ignored by the parser
and are a perfectly acceptable technique to make formulas more readable.
Also, your brief comments on each line, left hand justified, are useful.
I hope other formula writers pick up on this and start doing the same.


     I note your care in making sure that the formula names do not exceed
18 characters; proposed new code for the next version of Fractint will
report an error and not run the formula if the name is more than the
maximum space allocated for a formula name, currently 18 characters.

     You are the first to write a real formula called "Read-me-first".
I suggest we rename it to dmj--Read-me-first (18 characters!). This will
assure that it is always the first formula listed in the file when
the alphabetical sort is on. Also, when we add these formulas to the
orgform compilation, the formula will be the lead formula in _d.frm
for all the dmj formulas; as you post more formulas, you can simply
update the dmj--read-me-first formula to add commentary on the new
formulas. Other formula writers who have used some variation of their
names or initials as the lead in to their formulas may want to consider
writing their own "read-me" formulas to the same effect.

     A technical point about some of your boolean expressions. In the
C language, && has precedence over ||, so an expression

a || b && c

will be compiled in C as

a || ( b && c).

The formula parser treats the two as equal in precedence, and evaluates
left to right, so the same expression becomes

(a || b) && c.

This leads to a different result in some cases (as when a is true and
c is false).

An expression in the form a && b || c evaluates the same in C and
the parser, and I did see some of those in your formulas. For safety, I
think it's a good idea for formula writers using multiple ANDs and ORs
in a single expression to use parentheses to assure that the
expression is being evaluated as they intend.

Regards,

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: Lee Skinner <[e-mail]>
Subject: (fractdev) Coloring algo
Date: 10 Sep 1997 11:04:23 -0400

Damien,

  Does the formula file you just released replace any of the formulas you=

posted earlier or are they in addition to them:

Color01 { ; New coloring technique #1 (bof60 outside) Color01 { ; New
coloring technique #1 (bof60 outside) Color01 { ; New coloring technique =
#1
(bof60 outside) Color05i { ; New coloring technique #5 (angle of closest
approach) Color11 { ; New coloring technique #11 (ring trap) Color12 { ;
New coloring technique #12 (absolute decomposition) Color13(XAXIS) { ; Ne=
w
coloring technique #13 (continuous color) Color13phc { ; New coloring
technique #13 (continuous color, PHC)

Lee Skinner

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


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

From: Lee Skinner <[e-mail]>
Subject: (fractdev) Coloring algo
Date: 10 Sep 1997 12:06:13 -0400

Damien,

  Does the formula file you just released replace any of the formulas
you posted earlier or are they in addition to them:

Color01 { ; New coloring technique #1 (bof60 outside)
Color01 { ; New coloring technique #1 (bof60 outside)
Color01 { ; New coloring technique #1 (bof60 outside)
Color05i { ; New coloring technique #5 (angle of closest approach)
Color11 { ; New coloring technique #11 (ring trap)
Color12 { ; New coloring technique #12 (absolute decomposition)
Color13(XAXIS) { ; New coloring technique #13 (continuous color)
Color13phc { ; New coloring technique #13 (continuous color, PHC)

Lee Skinner

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


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

From: Rich Thomson <[e-mail]>
Subject: Re: (fractdev) XaoS
Date: 10 Sep 1997 11:00:45 -0600


This is quite a long message... it touches upon some things I've been
thinking about recently and goes back to some concepts I've touched on
before (anti-aliasing, quadtrees, interpolation/extrapolation for
zooming.)  I hope its not too long ;)

In article <[e-mail]> ,
    "Tim Wegner" <[e-mail]>  writes:
> I looked at it briefly (there's a DOS version, I'll try the X also)
> and it looks very interesting, amd the source is public!

I bring up XaoS (darn, that's hard to type that way :) because it
relates to a couple things I've mentioned on the fractint list before:

- interpolation/extrapolation of the zoom area to initialize the screen
- quadtree representations of fractals vs. image/par representations

I haven't looked too carefully at the source yet, but I have run it
on my home P90 system, my 250 MHz SGI at work and my friend's
UltraSparc at his office.  The sparc with the 8-bit frame buffer
seemed to do the best going full screen :).  It did compile rather
easily on the different boxen I tried it on.

Damien wrote:
> XaoS is interesting, but it's a different approach to fractals than
> FractInt.  XaoS emphasizes speed and sacrifices rendering quality to
> achieve it.  (Yes, you can stop it and do a full render, but that sort of
> defeats the purpose of the program, IMO.)  It's neat to be able to "zoom"
> is real-time, even if you have to keep the resolution pretty low to have a
> decent frame rate. :)

If you think about it, fractint does something very similar to what
XaoS is doing.  Suppose you're using solid-guessing and the fractal
takes a long time to compute; you press PageUp and zoom in before the
fractal is done computing and when you press return, it starts zooming
in on the selected area.  XaoS uses solid guessing as well.  However,
the actual algorithm used (what fractint calles "passes" on the X
screen) doesn't really affect the underlying techniques that XaoS uses
to get its speed.

> Adding that kind of capability would involve a
> full-screen blit every time the screen is redrawn,

Odd, I didn't think it was doing a full screen draws, but examining
the source code I see that it is.  It is using a graphics library that
works with the djgpp code environment for DOS.  On X it uses shared
memory transport and does a PutImage.  As fractint moves to a flat
memory model and/or djgpp, it could use the same library under DOS.

Even if you have to implement your own full-screen blit, its not that
hard to write.  Sometimes you're bitten by the third rule of
programming.  (The rules are: 1. Don't do it; 2. Don't do it again;
3. Sometimes you are forced to break rule 1.)

However, I see XaoS' rendering technique as basically the same as that
of fractint, only taken a little farther.  Fractint has ways that it
takes a coarse representation of the fractal and refines it.  I would
like to see fractint incorporate:

a) frame coherency
    This is when you are zooming in/out of an image already computed
    on the screen.  You figure out how the pixels you computed on the
    current image map to the pixels in the new image.

    When zooming in, this means you take a subregion of the screen and
    interpolate this to the full-screen size before you begin your
    compute cycle.  When zooming out, you take the screen and
    subsample it to a portion of the screen.

    I think this can be integrated into fractint although the
    temporary storage requirements might mean you need extended memory
    or whatever its called in order to pull it off under DOS.

    This is most of what XaoS does to get its performance.  Most of
    the time the screen has been filled by an interpolated image with
    the image being refined over time.

b) progressive refinement
    XaoS uses this technique, along with a prioritizing scheme, to
    trade off resolution for browsing (pan and zoom) speed.  Personally
    I would _LOVE_ to be able to browse through the image space of the
    fractint fractals at the XaoS speed and I see no reason why we
    shouldn't steal all of XaoS' good ideas and incorporate them :)

  i) computation model vs. display model
    This also touches on an issue that has come up before, which is a
    distinction between the display model and the computation model.
    Let me digress... fractint currently is implemented with an
    iteration-based computation model.  Images are never rendered as
    24-bit color.  They are always rendered as a 2d grid of indices
    (the iteration count, as tweaked by fractint's various algorithms)
    along with a color palette.  It also has an index-based display
    model (<= 8-bit colormapped pixels).

    However, there is nothing precluding fractint from having a 24-bit
    computation model and an 8-bit colormapped display model at the
    same time.  (Palette rotation doesn't have the same effect as it
    did before though!)  Naturally fractint would have to quantize the
    24-bit pixels to 256 colors before it could display the pixel.  (A
    standard 3/3/2 color cube could be used with Floyd-Steinberg
    dithering and so on.)

  ii) anti-aliasing as refinement
    For those of us who want anti-aliased fractals, currently what we
    have to do is tell fractint to create a PAR file with the current
    screen coordinates tiled into a larger grid of images, which we
    then render with fractint and assemble together the quilt work and
    then filter the final collage to get the anti-aliased effect.

    But what is anti-aliasing for a fractal?  Without programming in
    detailed knowledge about the structure of each fractal, the best
    general technique is to supersample the fractal and filter the
    result.  So antia-aliasing could be treated as another refinement
    pass to be done on the fractal after the current "image" is
    finished at screen resolution.

c) multiresolution image cache
    Anti-aliasing via supersampling (and there are methods to
    supersample IFS and 3d orbit fractal types as well as C-plane
    fractal types; I can talk more about that if anyone would like)
    requires the computation of many pixels, lots of which will be
    thrown away before we have a chance to use them for a frame
    coherent zoom as described above.  Take a look at this crude
    picture:

        increasing X pixel coordinate
        +----------------------------------------------->
            0        1        2    ...
    Current
    Screen        X        X        X
    Pixels

    Supersample        X    X    X    X    X    X
    Points

    Underlying
    Fractal
    Shape        ....,,./]\,,..,,,..,,.,,.,.,//[[]]\\..,,.,


    Now if we zoomed in exactly by a factor of 2, we would already
    have the next screen computed in our anti-aliasing process.  So if
    there was some way that we could keep around the anti-aliased
    samples and reuse them in our frame-coherent process, we'd be
    saving a lot of work.  By careful arrangment of the point sampling
    of the underlying fractal, we can reduce the number of samples
    by another 25% for each doubling of the resolution from the
    current screen.

    Let's take a closer look at what fractint does on the screen for
    C-plane fractals.  Each pixel is a point sample of the complex
    plane at the location of the pixel.  While a pixel has area, a
    point sample does not.  So the point sample is chosen as a
    representative for the area of the C-plane covered by the pixel.
    This means that the point sample can be located anywhere within
    the area of C covered by the pixel.


    +---------------+    +-------+-------+
    |        |    |    |       |
    |        |    |   2   |   2   |
    |        |    |       |       |
    |    1       |       +-------+-------+
    |        |    |       |       |
    |        |    |   2   |   2   |
    |        |    |    |       |
    +---------------+    +-------+-------+

    Fig. A            Fig. B

    Typically the point sample is placed at the center of the pixel's
    area (Fig. A).  This means that when you go to super-sample at
    twice the resolution (Fig. B) you can't reuse the point sample
    from the previous resolution because it isn't coincident with
    any of the sample points at the higher resolution.

    1---------------+       1---3---2---3---+
    |        |    |       |       |
    |            |    3   3   3   3   |
    |        |    |       |       |
    |        |    2---3---2---3---+
    |        |    |       |       |
    |        |    3   3   3   3   |
    |        |    |       |       |
    +---------------+    +-------+-------+

    Fig. A            Fig. B

    If we position the point sample at the upper-left corner of the
    pixel's area (Fig. A, location 1), then we can reuse that point
    sample in computing the next higher resolution image and save
    25% of the work in computing the pixels at location 2 in Fig. B.
    Similarly, the pixels at location 2 save 25% of the work in
    computing the point samples at location 3.

    This amounts to a hierarchical decomposition of the C-plane by
    a series of images at various sampling levels.  This kind of
    regular decomposition data structure is generally called a
    quadtree in 2D and an octree in 3D.

    A fractal has infinite content, whereas our displays are finite
    in the detail they can represent.  Obviously our computed images
    are only approximations to the underlying fractal shape.  A
    multiresolution data structure as described here approximates
    the fractal in a sequence of increasing resolution images.

    As we zoom in and out of the fractal, the spacing of the point
    samples represented by the screen pixels changes.  Generally it
    will not be an exact power of two spacing as it is in our multi-
    resolution data structure.  Instead, it will be some floating point
    fraction between the spacings we have computed.    (At this point
    the problem looks just like MIP-mapped texture mapping.)

    The integer portion of the spacing can be used to pick a level
    from our multiresolution data structure.  The fractional portion
    is then used to select pixels from the particular level.  In
    texture mapping, you have the further tweaks of point sampling the
    nearest level, doing bilinear interpolation between samples on the
    nearest level, or doing "trilinear interpolation", where you do
    bilinear interpolation on the two nearest levels and then
    interpolating linearly between those two samples.  These three
    methods are used to control the aliasing of textures.  Point
    sampling is the fastest and least accurate; trilinear interpolation
    is the slowest and most accurate.

    Now I know you're thinking that this is a huge amount of storage.
    Perhaps, but there are already some memory pigs in fractint,
    things like disk video mode at 2048x2048.  Fractint does what any
    program does in that environment: uses available memory if
    possible, then spills over to disk when that is exhausted.  Such a
    multiresolution technique (obviously you could turn it off for
    the same kind of browsing you have now) would be using the same
    thing.  There are efficient ways to turn store the multiresolution
    image on disk in a sparse fashion.

    Now that fractint has arbitrary zooming, I think it needs to adopt
    some new techniques for facilitating interactive exploration at
    those very very deep zoom levels.  For these arbitrary precision
    deep zooms, computing each pixels is extremely expensive.  Reusing
    as many point samples of the fractal as possible (even though what
    I've discussed here is complex) is a major win.

    By using a multiresolution image cache combined with progressive
    refinement and prioritizing techniques, I don't see any reason why
    we shouldn't be able to pan and zoom interactively in very, very
    deep zooms.  Naturally you'd still have to wait a while for the
    image to compute to full resolution, but interactive exploration
    for interesting areas would be enhanced.

                        -- Rich
--
  ``Between stimulus and response is the will to choose.''  -- Steven Covey
 =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
     3D Paint: The Power to Create in 3D;        Rich Thomson
     email me for more info                [e-mail]

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


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

From: "Damien M. Jones" <[e-mail]>
Subject: Re: Part 2 of (fractdev) Coloring algorithms
Date: 10 Sep 1997 13:04:39 -0400

George,

 -     I like your technique of using empty lines to block the
 - formulas into logical sections. This has not been done by anyone before
 - to my knowledge, but blank lines in a formula are ignored by the parser
 - and are a perfectly acceptable technique to make formulas more readable.
 - Also, your brief comments on each line, left hand justified, are useful.

Well, this is style I picked up while writing assembly code years back.
I'm allergic to uncommented, unreadable code. :-)

 -      I note your care in making sure that the formula names do not exceed
 - 18 characters;

Too many names would have been identical otherwise.

 -      You are the first to write a real formula called "Read-me-first".

Uhhh... just a whim, really. :)

 - I suggest we rename it to dmj--Read-me-first (18 characters!).

EXCELLENT notion.  I like.  Will do.

 -      A technical point about some of your boolean expressions. In the
 - C language, && has precedence over ||, so an expression
 - ...
 - An expression in the form a && b || c evaluates the same in C and
 - the parser, and I did see some of those in your formulas. For safety, I
 - think it's a good idea for formula writers using multiple ANDs and ORs
 - in a single expression to use parentheses to assure that the
 - expression is being evaluated as they intend.

I thought I had used parentheses to enforce exactly the order I wanted.  I
just double-checked the file for all occurrences of &&, and whenever it's
used in the same expression as ||, parentheses establish the order of
operation.  I think this is not only helpful to those unfamiliar with the
nuances of operator precedence, it also clarifies for the human reader
exactly what is intended.

Thanks for your feedback.

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


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


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

From: "Damien M. Jones" <[e-mail]>
Subject: Re: (fractdev) Coloring algo
Date: 10 Sep 1997 13:13:22 -0400

Lee,

 -   Does the formula file you just released replace any of the formulas you
 - posted earlier or are they in addition to them:

No, they replace them.  Sorry to have not mentioned this (temporary brain
lapse).  Here are the equivalents:

Color01    = dmj-Mand-Pnt-Dst
Color05    = dmj-Mand-Pnt-Ang
Color11    = dmj-Mand-Cr2-Dec
Color13    = dmj-Mand-Smooth
Color13phc = dmj-Mand-SmoothPHC

I rearranged the parameters a bit, too, to make them consistent across all
the different variations.  The idea is, if you want to switch the coloring
technique of one of the images, you can just change the type and leave the
actual parameters (pretty much) alone.  But it means if you've generated
images with the ColorXXX formulae, you will want to keep them around or
convert the PARs to the new arrangement.

The Color12 formula I posted is not in this FRM file, because it doesn't
work the way it's supposed to.  I was asking for help when I posted it, to
see if anyone could help me understand why it didn't produce the same
results as Peitgen, Jurgens, and Saupe get in their book, _Chaos and
Fractals: New Frontiers of Science_.  As soon as I can get this figured
out, there are a *lot* of new techniques I'd like to implement that require
it (like spiral palette-wrapping, a la KPT Fractal Explorer).

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


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


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

From: George Martin <[e-mail]>
Subject: Re: Part 2 of (fractdev) Coloring algorithms
Date: 10 Sep 1997 15:20:50 -0400

Damien,

>
I thought I had used parentheses to enforce exactly the order I wanted.  I
just double-checked the file for all occurrences of &&, and whenever it's
used in the same expression as ||, parentheses establish the order of
operation.
<

Yep, you're right. Sorry to imply otherwise; I would reiterate the point,
however, that precedence in the formula parser is not the same as for C,
and there may be traps for the unwary. Best to use parentheses, as you did.
While I'm thinking about it, the parser does not do well with assignment
expressions in any form but a=b (or a=b=c etc.). Attempts to integrate
assignment expressions into other expressions (e.g. sin(x=2*y)), which are
permitted and even encouraged in C, will yield unexpected results in the
parser. The parser is very sparing in its warnings about such matters;
improved error reporting in the parser is on my wish list for Fractint.

>
Well, this is style I picked up while writing assembly code years back.
I'm allergic to uncommented, unreadable code. :-)
<

This just reinforces my feeling that the parser has evolved over the last
18 months or so from an "equation" parser to a "program" interpreter. I
wonder if this is going to affect people's attitude about copyright
protection for formulas; until now, most have regarded formulas as public
domain, on the theory, I imagine, that a simple  mathematical expression is
not a proper object for copyright protection. Also, people may be waiting
for B. Mandelbrot to copyright z = z*z + c before they venture to do the
same with their formulas. :) But with the analogy to programs becoming
stronger, this practice may change.

George

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


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

From: "Damien M. Jones" <[e-mail]>
Subject: Re: (fractdev) XaoS
Date: 10 Sep 1997 17:50:55 -0400

Rich,

 - Odd, I didn't think it was doing a full screen draws, but examining
 - the source code I see that it is.

The only way NOT to do full-screen blits is to access the blitter on the
graphics card and rearrange the bitmap in video RAM to make room for new
lines.  This gets REALLY messy when you want to support more than one
chipset, and it's very hardware-dependent.  I think it would offer a
noticeable speed improvement, though (but I don't recommend this approach).

 - Even if you have to implement your own full-screen blit, its not that
 - hard to write.

For one card, no.  For dozens, it's a pain.  Not too bad if you're only
interested in supporting VESA modes, but VESA modes aren't exactly
blazingly fast (well, VESA 1.2; VESA 2.0-compliant cards offer faster
accesses like linear frame buffers).

The biggest problem (as far as FractInt is concerned) isn't the full-screen
blit, it's dealing with the memory consumption.  This would largely take
care of itself in a 32-bit mode, of course.

 - However, I see XaoS' rendering technique as basically the same as that
 - of fractint, only taken a little farther.

Yes and no.  The biggest problem I have with XaoS is that while it's neat
to look at, I find it pretty unusable as a primary fractal explorer.  This
is because where I spend most of my time exploring, the computer simply
*cannot* keep up a real-time display.  Personally, even if such a feature
were embedded in FractInt, I doubt I'd use it.  Once the *minimum*
iteration passes 1000, real-time performance becomes fairly impossible.
Add to that the fact that while I generally don't let an image fully render
while I'm exploring, I may not always wait the same amount of time before
zooming in further.  Sometimes only one refinement pass goes by; other
times I may need a lot more, just to identify the structures I was looking
for.

My gut feeling is that while XaoS is neat, real-time slow-motion zooming
isn't that important.  But it really does depend on what you're using a
fractal program for, so I'm not saying other people shouldn't think it's
important. :)

 - a) frame coherency

Sure, this is a good idea.  However, I would not want to re-use points
unless they landed *exactly* on the new sampling grid.  Otherwise you can
get subtle discontinuities that just don't look "right".

 -     I would _LOVE_ to be able to browse through the image space of the
 -     fractint fractals at the XaoS speed and I see no reason why we
 -     shouldn't steal all of XaoS' good ideas and incorporate them :)

In general I would agree with you, but I don't think the benefits are worth
the hassle at this point.  (Good thing I don't make decisions regarding
FractInt development, huh? :)

 -   i) computation model vs. display model

I fully agree that the image generated by FractInt should be separated from
the method FractInt uses to display that image.  That gives
resolution-independence as well as color-depth independence.

 -   Naturally fractint would have to quantize the 24-bit pixels to 256
 -   colors before it could display the pixel.  (A standard 3/3/2 color
 -   cube could be used with Floyd-Steinberg dithering and so on.)

Allow me to insert some technical observations at this point.  First of
all, using an 8x8x4 color cube gives horrible results for grey scale,
although for photographic or rich color images it produces moderate
results.  Second, if the code needs to be ported quickly to a windowed
environment, you should be aware that the OS generally will want to reserve
some colors for itself, and won't like an application redefining the entire
hardware palette.  (If it even lets the app get to the hardware palette.)
This is absolutely the case in Windows, and what little Mac programming
I've been exposed to leads me to believe a similar situation occurs there.

For this reason I would suggest (just suggest) that instead a 6x6x6 color
cube be used.  This uses up 216 colors, and provides six true greys
(including black and white).  Twenty-five more greys can be inserted at
equal spacings between the greys in the color cube, giving a total of 31
greys--just about as good grey-scale representation as you get in a 16-bit
color mode.  If you dither the greys, you get an excellent grey-scale
display, without sacrificing the color display very much.  And you've still
only used 241 colors--eight of which (black, white, red, green, blue,
yellow, magenta, and cyan) are typically represented already in the
system's palette.  This neatly slips you in at 233 colors, which is just
under the 236 colors Windows apps allow applications to modify.

Well, it was just a thought. :)  It's also possible to separate the entire
quantization code from the rest of the interface code, so the actual
palette used is immaterial to the main workings of the program.

Using a Floyd-Steinberg (or Burkes, which may be faster and arguably
better) dither produces better results than an ordered Bayer dither, but
it's generally slower.  In FractInt's case, where images are typically not
regenerated all that quickly anyway, this shouldn't be a problem, but in
any case where the images change rapidly and real-time performance is an
issue a faster dither should be considered.  If real-time zooming is
important, keep in mind that the full 24-bit image should be re-converted
to 8-bit color for each frame, or you will end up with irregularities in
the dither as some lines are doubled and others not.  This looks REALLY
messy.  (Oh yeah: blit performance in 24-bit modes can be pretty
horrendous...)

 -  ii) anti-aliasing as refinement

Well, if you've separated your rendering from your displaying, it's a piece
of cake to simply do one more refinement pass.  Doing it in the fractal
program also allows you to make it adaptive--you subsample only those
pixels which have significant change from their neighbors, much like an
extra guessing pass.  The exact filter you use (box, triangle, whatever) is
of course up in the air, but changeable without affecting much of the
controlling code.

Keep in mind, though, that there are plenty of reasons to cache an
"iteration count" or other similar pre-color version of a fractal image.
Because at the moment FractInt runs in a paletted mode, and maps iteration
levels to colors in a one-to-one fashion, it is easy to change the palette
and thus affect the entire screen.  However, if you're rendering a 24-bit
image, adjacent iteration values may have equivalent, indistinguishable RGB
values.  In a paletted system this is not a problem, because you can use a
different color index with the same color definition; the pixels are
distinguished by the color index, even though visually they are the same.
A 24-bit image doesn't have this advantage.  You'd want to keep the
original iteration count around so that the palette can be changed without
recalculating the entire image.

Once you've got the original iteration data handy, you might as well allow
the user to arbitrarily scale the palette, loop it X number of times of the
entire range of iterations, using a logarithmic or parabolic mapping
(preferably with tweakable curves!), and so forth.

 -     Anti-aliasing via supersampling (and there are methods to
 -     supersample IFS and 3d orbit fractal types as well as C-plane
 -     fractal types; I can talk more about that if anyone would like)

I for one am aware of the general techniques, although I've never written
any code to handle it...

 -     requires the computation of many pixels, lots of which will be
 -     thrown away before we have a chance to use them for a frame
 -     coherent zoom as described above.

Not a bad idea.  Keep the pixels used during anti-aliasing for the next
zoom.  As long as your next zoom lines up with your sub-sampled grid, as I
mentioned before.

 -     A fractal has infinite content, whereas our displays are finite
 -     in the detail they can represent.  Obviously our computed images
 -     are only approximations to the underlying fractal shape.  A
 -     multiresolution data structure as described here approximates
 -     the fractal in a sequence of increasing resolution images.

Interestingly enough, it's the same sort of technique that Fractal eXtreme
uses to do zoom movies.  I've seen similar zoom movies in PC demos
(Triton's Crystal Dreams II) and I wrote a program myself to do the
zooming.  The images along the way are pre-generated, rather than real-time
generated, but by only storing each 2:1 zoom, fairly impressive compression
"ratios" can be achieved.  (My crude experimentation demo got 75:1.)

As long as you're not doing a "final" render, I think caching the image
data would be pretty cool, even if you're not trying to do real-time
zooming.  I've often wondered what it would be like to have a CD-ROM of the
Mandelbrot set, pre-generated to respectable resolution, and stored in a
quadtree to optimize retrieval. :)

 -     The integer portion of the spacing can be used to pick a level
 -     from our multiresolution data structure.  The fractional portion
 -     is then used to select pixels from the particular level.
 -     ...point sampling... bilinear... trilinear...

Sure, these are all great if you're trying to keep up a real-time display.
Newer 3D cards will even help you out with the trilinear MIP mapping. :)
(Pretty sure the Voodoo chipset does trilinear.  Maybe it just does
bilinear.  But by the time FractInt's ready for it, chips that do trilinear
would be out.)

 -     Now I know you're thinking that this is a huge amount of storage.
 -     Perhaps, but there are already some memory pigs in fractint,
 -     things like disk video mode at 2048x2048.

Yeah, but as it stands that's not the fastest storage in the world.  When
FractInt's a 32-bit program, storage becomes much less of an issue.  In a
nice environment, the system handles the virtual memory for you.

 -     Now that fractint has arbitrary zooming, I think it needs to adopt
 -     some new techniques for facilitating interactive exploration at
 -     those very very deep zoom levels.  For these arbitrary precision
 -     deep zooms, computing each pixels is extremely expensive.  Reusing
 -     as many point samples of the fractal as possible (even though what
 -     I've discussed here is complex) is a major win.

Except that, as I pointed out, unless your new sampling grid exactly
coincides with your existing sampling grid, you will produce
discontinuities in your image which are visually distracting.  Think I'm
kidding?  Generate an image at 1024x768, especially one with smooth
gradients in it.  Then display it in an 800x600 window, such that the
entire image is shrunk to fit.  Just about any graphics app will let you do
this.  You will see the irregularity of the sampling grid and it won't look
very nice.

It may be okay for real-time use, but what you're talking about here are
deepzooms, which aren't even close to real-time anyway.  I'd rather have
the quality.

Just my thoughts.  I'm not trying to tear you down, Rich, just explain why
I think that XaoS isn't the right direction for FractInt (or any other
"serious" fractal app) to go.  I'm feeling quite amicable as I write this. :)

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


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


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

From: Rich Thomson <[e-mail]>
Subject: Re: (fractdev) XaoS
Date: 10 Sep 1997 16:58:17 -0600


Damien, first thanks for your obviously thoughtful reply.

Now onto the nits I'd like to pick... :)

In article <[e-mail]> ,
    "Damien M. Jones" <[e-mail]>  writes:
> [...]  This gets REALLY messy when you want to support more than one
> chipset, and it's very hardware-dependent.  [...]

> [full screen blit] For one card, no.  For dozens, it's a pain. [...]

I guess my workstation centricity is showing here.  I don't know a lot
about writing code for PCs that accesses the video memory directly,
but I agree that such an approach would be very hardware dependent and
a huge pain.  I guess I was under the (apparently wrong) assumption
that there was some sort of standard kind of API that would allow you
to get the performance from the card you want without having to write
all these card-specific drivers and so on.  The XaoS code seems to use
an SVGA library in order to avoid that problem -- I was thinking
something similar would be used for fractint.

> The biggest problem (as far as FractInt is concerned) isn't the full-screen
> blit, it's dealing with the memory consumption.  This would largely take
> care of itself in a 32-bit mode, of course.

Well memory consumption is a problem with fractint in general at this
point.  I think there needs to be a point at which the line is drawn
and the 640K memory model is killed and the code converted to a flat
address space.  Then all this hemming and hawing about memory would go
away?

> Yes and no.  The biggest problem I have with XaoS is that while it's neat
> to look at, I find it pretty unusable as a primary fractal explorer.  This
> is because where I spend most of my time exploring, the computer simply
> *cannot* keep up a real-time display.

Yes, arbitrarily complex objects (like fractals) take an arbitrary
amount of time to render, but XaoS uses several speedup mechanisms
that I feel would make exploring in fractint faster, even for very
expensive, complex fractals.  Even if you leave fractint's compute
engine alone and just carve the screen up into 16x16 blocks of pixels
and then use a prioritizing scheme to arrange the order of the
computation of the blocks would increase its usability for interactive
exploration.

> [...]  Once the *minimum*
> iteration passes 1000, real-time performance becomes fairly impossible.

Perhaps I wasn't so clear... while its obvious that XaoS' goals are to
achieve real-time performance first and other things second, that
isn't exactly what I had in mind for fractint.  I think fractint
should keep accuracy of the rendering first and speed second.  For
instance, there are fractal types where it is known that boundary
tracing and solid guessing have problems.  For these types, they set
the default rendering mode to some other technique.

> Add to that the fact that while I generally don't let an image fully render
> while I'm exploring, I may not always wait the same amount of time before
> zooming in further.  Sometimes only one refinement pass goes by; other
> times I may need a lot more, just to identify the structures I was looking
> for.

This would still be the case under what I am proposing.  I am
proposing alternate methods for improving the progressive refinement
of the image, which at low magnifications/maxiter counts means that
you should be able to pan and zoom at the same speed as XaoS.
Obviously if you are at 10^100 magnification with a maxiter of 100,000
it doesn't matter how many tricks you employ, you aren't going to get
real-time rendering on a PC :)  (Where's my Personal Connection Machine?)

>  - a) frame coherency
>
> Sure, this is a good idea.  However, I would not want to re-use points
> unless they landed *exactly* on the new sampling grid.  Otherwise you can
> get subtle discontinuities that just don't look "right".

I agree completely, which is why I suggested my progressive refinement
technique where existing samples are _by definition_ exactly twice as
far apart as the samples you are going to take at the next level of
refinement.

>  -   i) computation model vs. display model
>
> I fully agree that the image generated by FractInt should be separated from
> the method FractInt uses to display that image.  That gives
> resolution-independence as well as color-depth independence.

Yes, yes, yes!  Not only would that benefit come from this separation,
but it would enable people with 8-bit video cards to explore 24-bit
fractal types.

>  -   Naturally fractint would have to quantize the 24-bit pixels to 256
>  -   colors before it could display the pixel.  (A standard 3/3/2 color
>  -   cube could be used with Floyd-Steinberg dithering and so on.)
>
> Allow me to insert some technical observations at this point.  First of
> all, using an 8x8x4 color cube gives horrible results for grey scale,
> although for photographic or rich color images it produces moderate
> results.

True, but if you're using a gray-scale palette, then you don't need a
24-bit video mode anyway.  Just stick with 8-bit pseudocolor and load
the grayscale ramp into the DAC.

> Second, if the code needs to be ported quickly to a windowed
> environment, you should be aware that the OS generally will want to reserve
> some colors for itself, and won't like an application redefining the entire
> hardware palette.  (If it even lets the app get to the hardware palette.)
> This is absolutely the case in Windows, and what little Mac programming
> I've been exposed to leads me to believe a similar situation occurs there.

When that is the case, then a reduced color cube could be used, as you
suggest.  I see no problem with that.  This can also be the case under
X where you have a single hardware colormap and you don't want
fractint to use a private colormap (to avoid colormap flashing), so
although fractint has an 8-bit pseudocolor visual available to it, it
doesn't have 256 colors to work with.  Usually something like 236 end
up being available.

> [details of 6x6x6 color cube]
> Well, it was just a thought. :)  It's also possible to separate the entire
> quantization code from the rest of the interface code, so the actual
> palette used is immaterial to the main workings of the program.

Yes, this is what I was thinking.

> Using a Floyd-Steinberg (or Burkes, which may be faster and arguably
> better) dither produces better results than an ordered Bayer dither, but
> it's generally slower.

Yes, and it also requires a little more knowledge of the pixel
neighbourhood than just a simple ordered dither.  (BTW, this is why
OpenGL specifies ordered dither as the dithering algorithm -- it can
be implemented cheaply in hardware and each pixel can be dithered
independently of all other pixels which means you can dither pixels as
you render them.)

> [zooming in 24-bit, dithering, performance of 24-bit blit/dither]
> (Oh yeah: blit performance in 24-bit modes can be pretty
> horrendous...)

Well with 24-bit you've trebled the data load on the code, so its no
surprise :).  Add an alpha channel (which I think should be done when
truecolor support is added) and you've quadrupled the data load, uh oh
Batman... :)

>  -  ii) anti-aliasing as refinement
>
> Well, if you've separated your rendering from your displaying, it's a piece
> of cake to simply do one more refinement pass.

Yep, yep, yep.  I am glad that my message came across so clear :).
Sometimes its hard to tell at what "level" you should speak to an
audience until you get to know the audience better :).

> [...]  The exact filter you use (box, triangle, whatever) is
> of course up in the air, but changeable without affecting much of the
> controlling code.

I like the Mitchell filter myself.  I have a PD library of filters
implemented all in integer arithmetic with a data window buffer to
avoid recomputation.  It implements 2D separable filters and produces
excellent quality results.  The best I have gotten out of any of the
image rescaling type code out there on the net (pbmplus, Utah Raster
Toolkit, etc.).  I can point you at source code if you're interested.

> Keep in mind, though, that there are plenty of reasons to cache an
> "iteration count" or other similar pre-color version of a fractal image.

Yes, with my progressive refinement approach to rendering C-plane
fractals, my thoughts were that each point sample in the data
structure would store the iteration count and the value of the orbit
just before escape.  This gives you quick changing of the image based
on colormap changes as well as truecolor capability using the Z value
to change the color.  Thus the progressive refinement of the fractal
keeps the necessary information to distinguish it as an "image", but
the display portion involves applying the colormap to the "image" to
turn it into a colored collection of pixels.

> Once you've got the original iteration data handy, you might as well allow
> the user to arbitrarily scale the palette, loop it X number of times of the
> entire range of iterations, using a logarithmic or parabolic mapping
> (preferably with tweakable curves!), and so forth.

Exactly :)

>  -     Anti-aliasing via supersampling (and there are methods to
>  -     supersample IFS and 3d orbit fractal types as well as C-plane
>  -     fractal types; I can talk more about that if anyone would like)
>
> I for one am aware of the general techniques, although I've never written
> any code to handle it...

The basic idea is to use sub-pixel positioning when you plot the
points and vertices of line segments.  This sub-pixel positioning is
used to accumulate anti-aliased representations in the frame buffer.
For IFS you precalculate "anti-aliased" dots by treating the dot as a
Gaussian bump (or some other kind of bump, like a bump with the shape
of the Mitchell filter I mentioned above) in either a 2x2 or 3x3 pixel
pattern.  The sub-pixel positioning of the vertices is used to blend
these filtered representations of the dots into the frame buffer.  The
end result is as if you had rendered the IFS traditionally (where each
point is essentially in the shape of a box covering an entire pixel)
with lots of points and then downsampled the image.  For anti-aliased
lines, the technique is the same, but the rendering of the lines is
more complicated but doable.

> Not a bad idea.  Keep the pixels used during anti-aliasing for the next
> zoom.  As long as your next zoom lines up with your sub-sampled grid, as I
> mentioned before.

There is one phase of the process I might have not made clear in my
last message.  The fractal itself is kept in this multi-resolution
data structure, where the sample grids are guaranteed to be aligned
due to the nature of the data structure.  (You can orient the data
structure so that for fractals with symmetry, you don't even store the
symmetric parts of the data structure, but simply flip around the
indices when you fetch out the data.)

However, just because the sampling grids in the multi-resolution data
structure are aligned in this regular fashion doesn't mean that the
screen is aligned in the same fashion.  In fractint, you can rotate,
translate and scale the zoom box around in some very weird ways (even
introducing a skew transform).  However, none of these methods are
projective (leaving aside plane inversion for now), so they are all
subsumed by a single 3x3 transformation matrix defining a coordinate
transformation from the screen space into the compute space (i.e. the
C plane).

So to recap slightly:

    for each pixel on the screen
    find appropriate sample(s) in multi-resolution data structure
    copy to the screen

This keeps your data structure compute grids aligned properly so that
their mathematical properties are preserved, but lets the screen space
be mapped into the compute space however the user wishes.

Now, getting back to inversions, I'm not sure how one should handle
that.  I think the only reasonable way to do it with this sort of data
structure is to store the samples into the datastructure, after you
have inverted the C-plane.  This means that you should be recording
the C value of each sample in the data structure along with its
associated iteration count and penultimate escape Z value.  Otherwise
the data structure would be very sparsely populated and its overhead
would cancel any benefit obtained from it.

Note also that this datastructure must be completely flushed whenever
you changed things that effect how the iteration counts are computed:
fractal type, etc.

> As long as you're not doing a "final" render,

What stage are you attributing to the "final" render?  Are you
thinking of the "final" rendering as the process of mapping
iteration/orbit information into color?

> I think caching the image
> data would be pretty cool, even if you're not trying to do real-time
> zooming.  I've often wondered what it would be like to have a CD-ROM of the
> Mandelbrot set, pre-generated to respectable resolution, and stored in a
> quadtree to optimize retrieval. :)

Oh stop it, you're making me drool :)

> Yeah, but as it stands that's not the fastest storage in the world.  When
> FractInt's a 32-bit program, storage becomes much less of an issue.  In a
> nice environment, the system handles the virtual memory for you.

Yes, I can see we're really thinking alike here :)

> Except that, as I pointed out, unless your new sampling grid exactly
> coincides with your existing sampling grid, you will produce
> discontinuities in your image which are visually distracting.  Think I'm
> kidding?

No, I'm keenly aware of it, in fact!  I see artifacts in the way that
XaoS generates its images, because it doesn't use sub-pixel
positioning for its samples.  Using the multi-resolution approach,
each sample point is very well defined and very regular.  These
samples are then combined appropriately to render the image to the
screen.  One interesting aspect of this is that once you compute a
level at a resolution finer than the screen, lets call it level N,
then the zooms come for "free" until you zoom the image up to the
point where pixels need to be computed at level N+1.

> Generate an image at 1024x768, especially one with smooth
> gradients in it.  Then display it in an 800x600 window, such that the
> entire image is shrunk to fit.  Just about any graphics app will let you do
> this.  You will see the irregularity of the sampling grid and it won't look
> very nice.

Presumably you are talking about the effects of taking a 1024x768
image and point sampling it to 800x600?  Yes, the effects would be
annoying.  However, I would think the image would look fine at 800x600
if you used an anti-aliasing filter to change the resolutions.

> It may be okay for real-time use, but what you're talking about here are
> deepzooms, which aren't even close to real-time anyway.  I'd rather have
> the quality.

Hmm... what I am proposing keeps the quality, and since it provides a
clean framework for anti-aliasing it can increase the quality.
Perhaps there is some portion of this that's in my head that I haven't
effectively communicated yet?  If we separate the computation of the
samples from the display of the samples (as discussed above), then the
integrity of the samples isn't compromised by how we display them.  We
can use approximate display techniques (for instance, quantizing
24-bit fractals to a limited palette), but still keep the richness of
the underlying samples.  Naturally this has a larger memory appetite
than what fractint is using right now.  There ain't no such thing as a
free lunch :).

I'm developing an X-based prototype for exploring this concept
(fractint is just too messy for me to understand yet, so my
explorations are in my own little sandbox for now :).  Maybe a "proof
of concept" program would allay your fears?  Or I'll just keep
explaining until we both understand and then maybe we'll agree or just
agree to disagree :)

> Just my thoughts.  I'm not trying to tear you down, Rich, just explain why
> I think that XaoS isn't the right direction for FractInt (or any other
> "serious" fractal app) to go.  I'm feeling quite amicable as I write this. :)

Oh, I'm not feeling tore down at all :).  I can see that you're
understanding what I'm saying, so having a back and forth not only
helps me explain it to you, but forces me to be more exact and
concrete about some of this hand-waiving I like to do :).

I'd like to steal some ideas from XaoS, but not make fractint a XaoS
replacement.  I think of XaoS as kind of like a "Doom" for fractals.
Its fast and whizz-bang, but it obviously trades off some image quality
in order to achieve this.
--
  ``Between stimulus and response is the will to choose.''  -- Steven Covey
 =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
     3D Paint: The Power to Create in 3D;        Rich Thomson
     email me for more info                [e-mail]

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


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

From: "Damien M. Jones" <[e-mail]>
Subject: Re: (fractdev) XaoS
Date: 11 Sep 1997 13:25:04 -0400

Rich,

 - Now onto the nits I'd like to pick... :)

Have at it! :)

 - I guess I was under the (apparently wrong) assumption that there was
 - some sort of standard kind of API that would allow you to get the
 - performance from the card you want without having to write all these
 - card-specific drivers and so on.  The XaoS code seems to use an SVGA
 - library in order to avoid that problem -- I was thinking something
 - similar would be used for fractint.

Well, there is and there isn't.  There's VESA, which is a standardized way
of inquiring what modes are supported, switching to those modes, and then
accessing video RAM in those modes.  Problems: (a) a lot of cards only
support VESA 1.2, rather than the newer 2.0 (although software VESA drivers
for DOS can be loaded); (b) with VESA 1.2, your screen access is limited to
64K at a time--not a major problem, but a nuisance; (c) you don't have any
access to the hardware blitter.

If all you're doing is full-screen (or fairly large) blitting, these are
not prime issues, as most of the time is spent actually moving data into
video RAM and not messing with overhead.  VESA 2.0 typically allows (from a
protected mode) full linear access to video memory with no 64K limits,
which improves performance quite a bit.  It's the single-point get/set type
of access that will kill performance, and FractInt appears to deal with
screens in that fashion.  (Someone who's looked at the video driver code in
FractInt, please correct me if I err!)

In Windows, the situation is a little different.  Windows 95 generally
doesn't like for apps to go messing with the hardware; NT will stop such a
rogue app dead in its tracks.  DirectDraw (a component of DirectX) provides
a standardized high-speed way of accessing video RAM and the graphics card
blitter, but it isn't without its problems.  (Compatibility troubles with
DirectX can bring an otherwise functioning system to its knees.)

I guess you can tell that my experience lately has been PCs and hardware.
:)  Before I started working on PCs, I worked on Atari computers and
Atari's ill-fated Jaguar game console.  I'm *used* to being able to bang on
the metal, and it stinks not being able to do it on the PC. :(  But banging
on the metal is only practical when the metal only comes in one atomic
weight... :)

 - Well memory consumption is a problem with fractint in general at this
 - point.  I think there needs to be a point at which the line is drawn
 - and the 640K memory model is killed and the code converted to a flat
 - address space.  Then all this hemming and hawing about memory would go
 - away?

Sure would.  I don't think there's anyone here that disagrees; it's just
that moving such a large code base to a 32-bit environment--especially all
the assembly--is no small undertaking.  I guess it's the sort of thing that
everyone would want to put off as long as possible--not because there
aren't obvious advantages, but because it means while the code is being
ported, not much other work can be done.

 - Even if you leave fractint's compute engine alone and just carve the
 - screen up into 16x16 blocks of pixels and then use a prioritizing scheme
 - to arrange the order of the computation of the blocks would increase its
 - usability for interactive exploration.

Perhaps.  A while back I downloaded a program called "DFrac", written by a
hotshot Electronic Arts programmer who was spouting ridiculous things about
DirectX being the future of gaming and other nonsense.  Anyway, DFrac used
essentially a tesseral generation method with a prioritizing scheme.  The
prioritizing scheme sucked.  It did the "easiest" blocks first, which meant
90% of the picture was typically rendered in 10% of the time.  Which sounds
great, until you realize that the 10% left is typically the 10% you wanted
to see so as to know where to zoom in next.  So in practice, you ended up
waiting for the whole image to finish anyway.

How you prioritize is key.  Otherwise, this is a great idea.  You could do
a first guessing pass, then fill in the blocks based on priority.  (The
first guessing pass would get you the data you need to establish a priority.)

 - Perhaps I wasn't so clear... while its obvious that XaoS' goals are to
 - achieve real-time performance first and other things second, that
 - isn't exactly what I had in mind for fractint.  I think fractint
 - should keep accuracy of the rendering first and speed second.

That's what I wanted to hear.

 - This would still be the case under what I am proposing.  I am
 - proposing alternate methods for improving the progressive refinement
 - of the image, which at low magnifications/maxiter counts means that
 - you should be able to pan and zoom at the same speed as XaoS.

OK, I think I see where you're headed now.

 - True, but if you're using a gray-scale palette, then you don't need a
 - 24-bit video mode anyway.  Just stick with 8-bit pseudocolor and load
 - the grayscale ramp into the DAC.

Mmmm.  Yes, FractInt is a single-document interface anyway, not a windowed
environment.  Two images won't be competing with each other for palette
space (which they were when I designed the 6x6x6+31 scheme for Windows).
Now if FractInt suddenly sprouted a multiple-document interface with a
windowed scheme, things would get hairy. :)

 - [F-S vs. Burkes vs. ordered dither]
 - Yes, and it also requires a little more knowledge of the pixel
 - neighbourhood than just a simple ordered dither.

Yes, an ordered dither simply requires knowledge of a pixel's location.
The real-time ditherer I wrote for Windows uses it.

 - [24-bit blit performance sucks]
 - Well with 24-bit you've trebled the data load on the code, so its no
 - surprise :).

Yeah, but not just that.  On some cards it's simply worse in general.

 - Sometimes its hard to tell at what "level" you should speak to an
 - audience until you get to know the audience better :).

Oh, you have that problem too? :-)

 - [anti-aliasing filters]
 - I like the Mitchell filter myself.

Funny you should mention that.  A while back I wrote a filtered image
rescaling routine based on the technique described in Graphics Gems III.
(The one in the book has a slight flaw.)  It uses a Mitchell filter, and
I've found it produces superior results to most graphics programs.  I'm
rather fond of the filter, myself. :)

 - [multi-resolution sampling grid]
 - However, just because the sampling grids in the multi-resolution data
 - structure are aligned in this regular fashion doesn't mean that the
 - screen is aligned in the same fashion.  In fractint, you can rotate,
 - translate and scale the zoom box around in some very weird ways (even
 - introducing a skew transform).  However, none of these methods are
 - projective (leaving aside plane inversion for now), so they are all
 - subsumed by a single 3x3 transformation matrix defining a coordinate
 - transformation from the screen space into the compute space (i.e. the
 - C plane).

3x3 if you're including the translation; the actual axis conversion only
requires a 2x2 matrix.  (Unless I've gone brain-dead again.)

It makes sense to only store pixels based on the results of the actual
complex -> complex mapping used.  Inversion is one such mapping, but there
are others.  Such non-linear transformations would really screw up the
multi-resolution technique, if you used the "real" c value to determine
where to store the pixel's data in the MRSG.  So you would separate your
non-linear transformations from how you're actually storing data in the
MRSG... it probably doesn't sound like it, but I'm agreeing with you here. :)

 - > As long as you're not doing a "final" render,
 -
 - What stage are you attributing to the "final" render?  Are you
 - thinking of the "final" rendering as the process of mapping
 - iteration/orbit information into color?

Ah, let me clarify.  There is a difference between "browsing" and
"rendering", in my mind.  I typically explore with solid guessing on,
periodicity on, and one of a few different palettes that highlight
structure.  (This is the point at which most people would also use the
preview window, but I don't.)  When I find a point that I think will turn
out well, I'll often turn solid guessing off (as a lot of my newer images
have thin strangs that solid guessing misses).  This is what I would call a
"final" render, the point at which I'd probably turn anti-aliasing on.  I
might also render it at 1600x1200 or larger, rather than my normal working
resolution of 1024x768.  (Although generally I do that so I can reduce it
down and get the anti-aliasing I want.)

"Final" render is a user decision, not a software decision.  It's the point
at which the user has enough confidence in the image that they want the
computer to take the time to make sure it gets it right.  This is the point
where I'd want to switch from a "preview"-style MSRG image to a rigidly
accurate, fixed on exactly the size I want sampling grid.

 - [quadtree M-set on CD]
 - Oh stop it, you're making me drool :)

Well, I've got a CD-R if you've got the computer to generate the data... :)

 - Presumably you are talking about the effects of taking a 1024x768
 - image and point sampling it to 800x600?

Yah, those effects.

 - I would think the image would look fine at 800x600 if you used an anti-
 - aliasing filter to change the resolutions.

Generally, yes, that helps, although such small changes in resolution still
cause problems.

 - Hmm... what I am proposing keeps the quality, and since it provides a
 - clean framework for anti-aliasing it can increase the quality.
 - Perhaps there is some portion of this that's in my head that I haven't
 - effectively communicated yet?

Perhaps.  Part of the problem is that I wouldn't want to be restricted to
only 2:1 zooms.  I prefer to be able to precisely frame exactly what I want
in an image.

 - I'm developing an X-based prototype for exploring this concept
 - (fractint is just too messy for me to understand yet, so my
 - explorations are in my own little sandbox for now :).  Maybe a "proof
 - of concept" program would allay your fears?

Well, I don't run X.  (Haven't had a spare PC to dedicate to it, although
it's on my wish list.  Right behind a dual Pentium-II 300MHz machine. :)

I understand the sandbox, though.  It's a lot easier than wading into
FractInt, which is a *huge* project.

 - Or I'll just keep explaining until we both understand and then maybe
 - we'll agree or just agree to disagree :)

We may yet end up at that point.

 - I'd like to steal some ideas from XaoS, but not make fractint a XaoS
 - replacement.  I think of XaoS as kind of like a "Doom" for fractals.

Interesting analogy.

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


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


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

From: "Damien M. Jones" <[e-mail]>
Subject: (fractdev) Re: Part 2 of Coloring algorithms
Date: 11 Sep 1997 14:52:23 -0400

George,

 - Yep, you're right. Sorry to imply otherwise; I would reiterate the point,
 - however, that precedence in the formula parser is not the same as for C,
 - and there may be traps for the unwary. Best to use parentheses, as you did.

Caveat noted.

 - Attempts to integrate assignment expressions into other expressions
 - (e.g. sin(x=2*y)), which are permitted and even encouraged in C, will
 - yield unexpected results in the parser.

Well, I'd debate whether or not they're "encouraged" in C. :)  Personally,
I think they obfuscate the programmer's intent and generally lead to
hard-to-find errors, but that's just my opinion.

That they don't work reliably in FractInt's parser is no great loss.

 - This just reinforces my feeling that the parser has evolved over the last
 - 18 months or so from an "equation" parser to a "program" interpreter.

I'd like to see it continue along those lines.  It would allow more
programming-like expansion of FractInt without actually requiring the user
to install, configure, and learn a full-blown C compiler and assembler.

 - I wonder if this is going to affect people's attitude about copyright
 - protection for formulas; until now, most have regarded formulas as public
 - domain, on the theory, I imagine, that a simple  mathematical expression is
 - not a proper object for copyright protection. Also, people may be waiting
 - for B. Mandelbrot to copyright z = z*z + c before they venture to do the
 - same with their formulas. :) But with the analogy to programs becoming
 - stronger, this practice may change.

Interesting point.  I deliberately omitted a copyright notice in the file I
posted, even though in general I'm a pretty strong proponent for
copyrights. :)  As you said, I'm not sure a mathematical formula is
copyrightable.  Where you draw the line becomes a difficult issue.

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


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


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

From: Rich Thomson <[e-mail]>
Subject: Re: (fractdev) Re: Part 2 of Coloring algorithms
Date: 11 Sep 1997 14:37:38 -0600


In article <[e-mail]> ,
    "Damien M. Jones" <[e-mail]>  writes:
> As you said, I'm not sure a mathematical formula is
> copyrightable.  Where you draw the line becomes a difficult issue.

I would think it works the same way it does for math books.  If you
rip off the text of a book, whether its a book on calculus or
Shakespeare, then you are in violation of the copyright.  However, one
can still use all the calculus and given formulas without being in
violation of the copyright.  You're not copyrighting the formula
itself, you are copyrighting your authored work.  If I took your
formula file and included it on a CD-ROM and started selling it, I'd
be in violation of your copyright.  If I took your formula and made
some renderings with it and then sold the renderings, I wouldn't be in
violation of your copyright.
--
  ``Between stimulus and response is the will to choose.''  -- Steven Covey
 =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
     3D Paint: The Power to Create in 3D;        Rich Thomson
     email me for more info                [e-mail]

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


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

From: Rich Thomson <[e-mail]>
Subject: Re: (fractdev) XaoS
Date: 12 Sep 1997 11:01:06 -0600


In article <[e-mail]> ,
    "Damien M. Jones" <[e-mail]>  writes:
[PC video details]
> I guess you can tell that my experience lately has been PCs and hardware.
> :)  Before I started working on PCs, I worked on Atari computers and
> Atari's ill-fated Jaguar game console.  I'm *used* to being able to bang on
> the metal, and it stinks not being able to do it on the PC. :(  But banging
> on the metal is only practical when the metal only comes in one atomic
> weight... :)

Ah... I guess I come from the other end of the graphics spectrum in my
experience.  I'm used to high-level APIs that let me focus on the
problem instead of having to think about the hardware.  But then
again, the hardware is powerful enough and fast enough that you don't
NEED to worry about the hardware to get the performance you want. :)
Its like switching from a Cadillac to a Volkswagen!  Suddenly you need
to pay attention to things like momentum of the vehicle and the timing
of gear shifts :).

> that moving such a large code base to a 32-bit environment--especially all
> the assembly--is no small undertaking.

I haven't compiled code in the PC environment before; is it something
like switching a few compile directives and then just fixing all the
compile errors, or does it mean that things like the assembly must be
rewritten from scratch?

[prioritizing screen blocks]
> Perhaps.  A while back I downloaded a program called "DFrac", [that used]
> essentially a tesseral generation method with a prioritizing scheme.  The
> prioritizing scheme sucked.  It did the "easiest" blocks first, which meant
> 90% of the picture was typically rendered in 10% of the time.  Which sounds
> great, until you realize that the 10% left is typically the 10% you wanted
> to see so as to know where to zoom in next.  So in practice, you ended up
> waiting for the whole image to finish anyway.

When I had this in mind for a small delta to fractint (currently I'm
working on improving its X support), I thought the user would be able
to specify the priority scheme as one of:

    min        Blocks with the smallest iteration total are done
        first (as you describe above)
    max        Blocks with the largest iteration count are done first
    >N        Blocks with count > N are done first
    <N        Blocks with count < N are done first

Moreover, the blocks would all be refined to the same level before any
of them was refined to the next level, if a multi-level refinement
scheme is currently under use.  In other words, if you've got 1-pass
sampling on, then its going to select a 16x16 block and do all 256
pixels there.  However, if you have 3-pass sampling selected, then all
the blocks matching your prioritization scheme will be refined over
their 2nd pass first.  (Remember that we did the first pass over the
whole screen to come up with counts to prioritize.)  Then these same
blocks would be refined to their third and final pass.  At this point
the blocks that didn't match the prioritizing criteria would be
refined for their 2nd and 3rd passes.

The thing about prioritizing schemes is that they are largely
heuristic in a situation like this.  For instance, another
prioritizing scheme would use the initial pass to estimate the time it
will take to compute the entire 16x16 block (which was only sampled at
say 2x2 or 4x4 resolution for the initial guess).  This estimated
computation time could then be used to schedule the blocks such that a
certain target update rate could be achieved.

A program like XaoS has real-time concerns that make such a
prioritizing scheme interesting.  However, a program which spawned
computation workers across a distributed network might want to have
the worker processes communicate partial results at fixed time
intervals in order to more effectively utilize the network bandwidth
available rather than having all the worker processes finish at the
same time only to get logjammed on the network between them and the
coordinating gather process that will display the resulting montage.

Yet another possibility for fractint is to introduce a prioritizing
formula that operates on the 16x16 block to return a priority.  A sort
order is also specified for the priority list.  But that's quite a bit
more work, I don't know how well the existing formula parser can be
adopted to other uses.

> space (which they were when I designed the 6x6x6+31 scheme for Windows).
> Now if FractInt suddenly sprouted a multiple-document interface with a
> windowed scheme, things would get hairy. :)

BTW, did you ever publish anything about this color cube?  It seemed
familiar to me when I was reading your description of it.

> Ah, let me clarify.  There is a difference between "browsing" and
> "rendering", in my mind.  [...]

Ah, I see what you mean.  OK, I can see that.  Naturally in the true
fractint tradition, it could be enabled or disabled.  I have a
question though.  Do you think that if a fractal is supsersampled that
you can see the difference between slightly different alignments of
the sampling grid?  I would think that if this were true, it would
mean that you didn't sufficiently supersample the original in the
first place.

> "Final" render is a user decision, not a software decision.  It's the point
> at which the user has enough confidence in the image that they want the
> computer to take the time to make sure it gets it right.  This is the point
> where I'd want to switch from a "preview"-style MSRG image to a rigidly
> accurate, fixed on exactly the size I want sampling grid.

> Well, I've got a CD-R if you've got the computer to generate the data... :)

Funny you should mention that, my ESV workstation is coming on-line
soon and will be accesible over the net.  Its goal in life is to die
computing fractals and 3D graphics :)

> Perhaps.  Part of the problem is that I wouldn't want to be restricted to
> only 2:1 zooms.  I prefer to be able to precisely frame exactly what I want
> in an image.

Ah, I see the missing piece now.  Think of texture mapping -- there
you see the texture in a continuous change in level of detail, as you
orient the textured polygon's vertices in different relationships to
the camera, you are changing the image level from which the texture is
being fetched.  You don't see the change at all because of the way the
image levels are blended.

Similarly, for the scheme I'm proposing, you have this multi-
resolution data structure built in memory of your fractal samples.
You use the current magnification and orientation of the screen to
select samples from the data structure to create the best screen view
that you can.  The data structure accelerates panning and zooming (if
you've browsed there before).  It can also be used to achieve a level
of anti-aliasing, but for 8-bit video modes I suspect it would be
better used for panning and zooming acceleration, rather than trying
to achieve anti-aliasing without taking control of the palette.
--
  ``Between stimulus and response is the will to choose.''  -- Steven Covey
 =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
     3D Paint: The Power to Create in 3D;        Rich Thomson
     email me for more info                [e-mail]

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


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

From: "Damien M. Jones" <[e-mail]>
Subject: (fractdev) Coloring Options page
Date: 13 Sep 1997 13:15:53 -0400

Here's a thought.

I know this is not a wish-list for FractInt, so what I'm asking is not a
whiny "can someone do this", but more of a reasoned "is this a good idea".
The idea is to take some of the coloring techniques I put in a FRM file,
and instead build them into FractInt.  Of course, there's not really room
in the interface for options to control coloring methods like I have; so,
how about making a new options page, tied to the "w" key?  This would allow
plenty of room for selecting "trap" points or other methods, and setting
locations, rotations, aspects, and so on.

Well, it was just a thought.

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


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


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

From: "Damien M. Jones" <[e-mail]>
Subject: Re: (fractdev) XaoS
Date: 13 Sep 1997 13:13:04 -0400

Rich,

 - Ah... I guess I come from the other end of the graphics spectrum in my
 - experience.  I'm used to high-level APIs that let me focus on the
 - problem instead of having to think about the hardware.  But then
 - again, the hardware is powerful enough and fast enough that you don't
 - NEED to worry about the hardware to get the performance you want. :)

Hmmm, well, that's nice if you can work in such an environment, but I've
never worked in a situation where performance wasn't an issue.  Having
performance as an issue, but NOT being able to bang on the hardware is a
REAL challenge.

 - [16- to 32-bit porting]
 - I haven't compiled code in the PC environment before; is it something
 - like switching a few compile directives and then just fixing all the
 - compile errors, or does it mean that things like the assembly must be
 - rewritten from scratch?

You hope it's the former.  Generally I've found it easier to port the other
direction, but I haven't exactly done a *lot* of it that way.

The biggest problems you have is that in 16-bit code, you need to worry
about near, far, and huge pointer/data types.  Near means in the same 64K
chunk, and can be represented in a 16-bit pointer.  Far means in a
different 64K chunk, and can be represented with a 16-bit segment prefix
and a 16-bit offset into that segment.  (In protected mode, the segment
prefixes are "handles" into a table that gives the real address; in DOS,
they're actual physical addresses, shifted four bits left.  Go figure.)
Huge means in a different 64K chunk, but the data referred to is larger
than 64K, so the offset can be 32-bit.  And every time you cross a 64K
boundary with a huge object, you have to fudge your segment prefix, because
the processor (in 16-bit modes) can really only deal with 16-bit offsets.

It's a mess.  The nice thing is, in 32-bit mode, all that mucking around
with near, far, and huge disappears.  Win32 uses a different means of
managing memory that doesn't require the program (or the programmer) to
modify or even be aware of segment and 64K nerdiness.  It's much more like
writing code in a UNIX environment.  (More like than Win16, that is; it's
still pretty far off. :)  For this reason I suspect a lot of the code will
already be portable, since it's designed to be portable to UNIX anyway.

The kicker is all that assembly code.  Some of the rules of assembly code
change when you're in a 32-bit environment.  Not many, but some.
Particularly, though, all that segment nonsense is "in your face" in the
assembly code, because it has to be.  So all of the assembly code must be
examined.  A good portion of it will probably need to be rewritten.  Some
stuff can likely be left alone.  But all of it will need to be checked, and
that's a LOT of assembly code. :)

 - When I had this in mind for a small delta to fractint (currently I'm
 - working on improving its X support), I thought the user would be able
 - to specify the priority scheme as one of:
 - [details snipped]

This is a good idea--that was my main concern, was that a prioritizing
heuristic wouldn't fit all circumstances or all users.  Making it a user
choice would be great.

 - Moreover, the blocks would all be refined to the same level before any
 - of them was refined to the next level, if a multi-level refinement
 - scheme is currently under use.

I'd make this an option, too.  Sometimes I'd rather see the full detail, if
the prioritizing scheme is right.

 - [6x6x6+31 color cube]
 - BTW, did you ever publish anything about this color cube?  It seemed
 - familiar to me when I was reading your description of it.

Me?  Publish?  Surely you jest.  I wouldn't even know where to go...

No, I never published anything about it.  I never read anything about it,
either, but it's entirely likely that someone else came up with a similar
solution.  It seemed pretty obvious to me.  The ditherer I wrote for my
display code chooses between the RGB cube and the grey ramp on a
pixel-by-pixel basis, so if you have a single image with color AND grey
portions, you still get great greyscale representation in those portions of
the image.

Some might argue that it's better to devote those extra greys to expanding
the color cube.  The problem is, 6x6x6 is the largest cube that fits into
256 (7x7x7 is 343) so if you change the color scaling any other way, you
lose your greys completely.  (In my view, this is Bad.)  You can get your
greys back by using a 5x9x5 cube, which is 225 colors and emphasizes the
green resolution, but this drops your red and blue resolution even further.
 I think the 6x6x6+31 is an optimal solution for the Windows environment.
For the record, Netscape and Internet Explorer both use a 6x6x6 color cube,
but the +31 is my own little twist. :)

 - Do you think that if a fractal is supsersampled that you can see the
 - difference between slightly different alignments of the sampling grid?
 - I would think that if this were true, it would mean that you didn't
 - sufficiently supersample the original in the first place.

That is exactly the case.  As you increase your supersampling, you almost
by definition reduce the variance in your sampling grid and approach a
precisely aligned grid anyway.  I regularly take 1600x1200 images and
reduce them to 640x480, which is certainly not a precise alignment.  At
this scale, slight differences in the 1600x1200 grid relative to the
640x480 grid are unimportant.

The same is not true of lesser changes.  Even with an anti-aliasing scaling
routine, reducing a 1024x768 image to 800x600 is not always satisfactory,
and I think it's because the differences between the sampling grid are more
obvious.

 - Funny you should mention that, my ESV workstation is coming on-line
 - soon and will be accesible over the net.  Its goal in life is to die
 - computing fractals and 3D graphics :)

Hmmm, interesting notion.  Very interesting...

 - Ah, I see the missing piece now.  Think of texture mapping -- there
 - you see the texture in a continuous change in level of detail, as you
 - orient the textured polygon's vertices in different relationships to
 - the camera, you are changing the image level from which the texture is
 - being fetched.  You don't see the change at all because of the way the
 - image levels are blended.

I would point out here that the lower-resolution textures used in such a
technique are not simply point-sampled from the higher-resolution versions,
but are in fact filtered in some fashion to remove the high-frequency
content from them.  Otherwise the technique would be next to worthless.
For your multi-resolution fractal technique, though, your lower-resolution
image data IS point-sampled (from the original infinitely resolute
fractal).  This is why I'm not as convinced as you are that mip-mapping is
going to be that great. :)

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


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


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

From: Rich Thomson <[e-mail]>
Subject: Re: (fractdev) XaoS
Date: 15 Sep 1997 09:52:51 -0600


In article <[e-mail]> ,
    "Damien M. Jones" <[e-mail]>  writes:
> Hmmm, well, that's nice if you can work in such an environment, but I've
> never worked in a situation where performance wasn't an issue.  Having
> performance as an issue, but NOT being able to bang on the hardware is a
> REAL challenge.

Agreed.  In those cases, I think the focus is to first deal with the
hardware and create yourself a layer of routines that implement the
(hopefully few) operations for which you need performance.  Then you
have an abstraction that functions at the desired performance and you
can focus on the problem to be solved rather than the details of the
implementation.  This is exactly what a higher-level 3D graphics API
does for you.  If you have an optimized implementaiton of the API,
then you can leave the performance fiddling to the API and you can
focus on your application.  However, its only recently that 3D APIs
have started to leak into the PC world.  In the workstation world,
we've had high performance 3D APIs for quite some time.

> The kicker is all that assembly code. [...]

Given that there are C equivalents for all the assembly code (used by
the unix port), I would think the natural progression for a flat
address space port of fractint would be:

    o port the C code to the flat address model
    o one-by-one reintegrate the assembly routines back into the code,
      replacing the C code

> This is a good idea--that was my main concern, was that a prioritizing
> heuristic wouldn't fit all circumstances or all users.  Making it a user
> choice would be great.

Yes, since its a heuristic, you basically have two choices: a one-size
fits all solution (sounds like this is what you encountered in that
other pgoram); or giving the user a choice from a few options so that
they can select the appropriate heuristic (or turn it off entirely).

[color cube]
> Me?  Publish?  Surely you jest.  I wouldn't even know where to go...

Ah, well I'm pretty sure I've seen an article on the 6x6x6 color cube
somewhere, and it was targeted at creating a good color cube for
windows like environments where you have to share the palette with
other programs.

BTW, one of the big differences between the windows/mac environment
and your typical X environment is that under X different windows can
have different pixel formats.  In other words, one window on the
screen can be 24-bit truecolor and another on the screen is 8-bit
pseudocolor.  Under windows/mac, the entire screen is a single video
"mode" and you can't have different application windows in different
video modes, AFAIK.

> That is exactly the case.  As you increase your supersampling, you almost
> by definition reduce the variance in your sampling grid and approach a
> precisely aligned grid anyway.  I regularly take 1600x1200 images and
> reduce them to 640x480, which is certainly not a precise alignment.  At
> this scale, slight differences in the 1600x1200 grid relative to the
> 640x480 grid are unimportant.

You do understand that what I'm proposing as a datastructure does not
attempt to filter itself to the size of the screen, right?  The
datastructure would most often have a finer granularity than the
screen, but that's due the fact that we want to scale arbitrarily in
screen space, but the datastructure only has a series of discrete
magnifications.  Ultimately, your observation about point sampling
applies and since I have no idea how to apply a band-limiting filter
to a fractal, the best you can hope to do for anti-aliasing is
supersampling.  The other thing about supersampling for AA is that I
have no idea how you could do this in 8-bit pseudocolor without doing
it all in 24-bit mode first and then doing a standard color
quantization step on the resulting image.  I suppose if you use the
6x6x6+31 color cube, you can quantize and dither on-the-fly, but then
you color cycling gets weird!  Also, I think if you use the
quadtree for sampling, you would have to sample even farther into the
fractal to get good AA.  John Hart has published some papers on how to
AA fractals, (IFS and L-system types), but I don't think they apply to
escape-time fractals like the M-set.  Everywhere I've seen those
rendered nicely, it was always done with supersampling.
--
  ``Between stimulus and response is the will to choose.''  -- Steven Covey
 =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
     3D Paint: The Power to Create in 3D;        Rich Thomson
     email me for more info                [e-mail]

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


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

From: "Tim Wegner" <[e-mail]>
Subject: Re: (fractdev) XaoS
Date: 15 Sep 1997 23:06:01 -0600

Rich asked:

> Just to clarify -- djgpp is the freeware/shareware C compiler with flat
> 32-bit memory model for DOS apps, right?

Yes. It's a port of the GNU C compiler to an extended DOS 32 bit flat
memory model.

> Can you compile windows code
> with it,

No. However there is a similar project that ports GNU C to Windows. I
don't think it is as mature yet as djgpp. For the future it is a
possibility. See

http://www.cygnus.com/misc/gnu-win32/


> or do you have to buy a MS compiler to accomplish that
> reliably?

Many commercial compilers will work with Windows - Microsoft,
Borland, Watcom, etc.

> Can you elaborate on the details of the two assembly styles?  I'm not
> sure what 'AT&T notation' vs. MASM notation.

I don't know the details. Suffice it to say they are different enough
it would be real tough to port our NMASM assembler. For xample, MASm
instructions are target, source, and AT&T is the reverse.

See
http://www.castle.net/~avly/djasm.html


>If its a matter of
> syntax, I could probably write a perl script toconvert the assembly
> code from one format to another.

I don't think it is necessary, as I saidf I belive there is a
MASM-style assembler available for Linux and djgpp.

Tim


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


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

From: Rich Thomson <[e-mail]>
Subject: Re: (fractdev) XaoS
Date: 16 Sep 1997 15:04:52 -0600


In article <[e-mail]> ,
    "Tim Wegner" <[e-mail]>  writes:
> LINUX and djgpp use AT&T notation assembler, which would be a pain
> to port. However, I understand that there is a MASM-like freeware
> assembler. I presume that with Win95 we can use masm itself.

I looked at the djgpp web page that discusses the assembler syntax.
Writing a perl script to convert back and forth from one to another is
doable and probably worthwhile if you have a large amount of assembly.
However, given that you also want to move from the 16-bit real-mode
assembly to 32-bit protected mode assembly, I'd say its probably
better to use the C code initially for the 32-bit port and
incrementally fold in the assembly as its converted.
--
  ``Between stimulus and response is the will to choose.''  -- Steven Covey
 =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
     3D Paint: The Power to Create in 3D;        Rich Thomson
     email me for more info                [e-mail]

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


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

From: "Damien M. Jones" <[e-mail]>
Subject: (fractdev) 24-bit color: cycling, anti-aliasing, displaying
Date: 17 Sep 1997 14:34:42 -0400

Rich,

 - However, its only recently that 3D APIs have started to leak into the
 - PC world.  In the workstation world, we've had high performance 3D APIs
 - for quite some time.

<envy>  Yeah, having good optimized versions of things like OpenGL must be
nice.  PC implementations are still buggy, and unless you have good (read:
expensive) hardware, performance is lousy anyway.  (Quick note: the
cheapest decent GL performance on a PC can be had with the Voodoo chip from
3Dfx.)

 - Given that there are C equivalents for all the assembly code (used by
 - the unix port), I would think the natural progression for a flat
 - address space port of fractint would be:
 -
 -     o port the C code to the flat address model
 -     o one-by-one reintegrate the assembly routines back into the code,
 -       replacing the C code

Obviously.  But as Tim pointed out a while back, users will not tolerate a
slower version of FractInt, generally.  Thus virtually all of the assembly
code would need to be ported before it is releasable.

 - Ah, well I'm pretty sure I've seen an article on the 6x6x6 color cube
 - somewhere, and it was targeted at creating a good color cube for
 - windows like environments where you have to share the palette with
 - other programs.

Yeah, I think I saw one a few years ago about it.  I never claimed to be
original.  I just added my own twist--the enhanced greyscale representation.

 - BTW, one of the big differences between the windows/mac environment
 - and your typical X environment is that under X different windows can
 - have different pixel formats.  In other words, one window on the
 - screen can be 24-bit truecolor and another on the screen is 8-bit
 - pseudocolor.  Under windows/mac, the entire screen is a single video
 - "mode" and you can't have different application windows in different
 - video modes, AFAIK.

Yes and no.  A graphics card itself is incapable of switching display modes
on a window-by-window basis; thus if you want one window in 24-bit color,
and another in 8-bit color, the hardware itself must be set for 24-bit
color, and the display driver automatically translates writes to the 8-bit
window into 24-bit color actually used for display.  The application
dealing with the 8-bit window doesn't know or care that such translation is
being done.

In Windows, when you create a window, it isn't a "bitmap" that you can just
write to.  If you want to draw anything in that window, you have to go
through the GDI to do it.  If you want a bitmap to represent the window,
then you have to create the bitmap yourself, do what you want to the
bitmap, and then when Windows wants you to redraw the window, you just do a
simple blit using the bitmap you've already created.  The blit stage is
where the driver steps in and does the conversion.  You can easily create
an 8-bit bitmap, draw in it like an 8-bit display mode, and then blit it to
the screen--and if your programming is running in a 16-bit or 24-bit color
mode, your Windows app doesn't care, because the driver does all the dirty
work of handling the conversion.

The trick is, it doesn't work too well going in the other direction.  If
you have a 24-bit bitmap, and you use the same blit command
(SetDIBitsToDevice) to transfer it to an 8-bit screen, the driver is once
again responsible for doing the conversion.  All display drivers that I
have personally seen do a simplest conversion job they can--they convert
each pixel to its nearest color in the current palette.  This of course
produces *horrible* banding and is totally unacceptable.  That's why if you
plan on using 24-bit color, you have to address rendering it to an 8-bit
display.  All other conversions can be ignored (although if you write code
for them, you may be able to do a better job than the driver).

Hope this clears things up a tad.

 - You do understand that what I'm proposing as a datastructure does not
 - attempt to filter itself to the size of the screen, right?

Yes, I understand that.

 - Ultimately, your observation about point sampling applies and since I
 - have no idea how to apply a band-limiting filter to a fractal, the
 - best you can hope to do for anti-aliasing is supersampling.  The other
 - thing about supersampling for AA is that I have no idea how you could
 - do this in 8-bit pseudocolor without doing it all in 24-bit mode first
 - and then doing a standard color quantization step on the resulting
 - image.  I suppose if you use the 6x6x6+31 color cube, you can quantize
 - and dither on-the-fly, but then you color cycling gets weird!  Also, I
 - think if you use the quadtree for sampling, you would have to sample
 - even farther into the fractal to get good AA.

OK, first, you *must* anti-alias in color space, in 24-bit color.
(Discussions about AA a while back in Fractal-Art show that you can't AA in
iteration space or any other space in which discontinuities occur.)  An AA
image, by nature, will not simply contain the colors of the palette, but
also blends between several possibly very dissimilar colors, not easily
represented by any color in the palette.

Second, for 8-bit display purposes, you would want to quantize and dither
on the fly, for the user's convenience.  However, in no way should you
*attempt* to color cycle such an image; it is the height of lunacy to cycle
an 8-bit palette which has no bearing on the intended cycling.

This brings up bigger points: how do you color-cycle a 24-bit image, and
how do you color-cycle an anti-aliased image?  Color-cycling a 24-bit image
generally means remapping the entire image to the same palette, but rotated
slightly.  This can involve a fair amount of calculation, especially if the
palette is being interpolated smoothly (as will typically be the case with
a 24-bit image).  It also involves a full-screen blit, which means
performance will suffer on top of the actual calculation time.  To speed
things up, an intermediate stage between source data for color mapping and
final RGB value could be used--the intermediate stage would be the actual
offset into the palette, including interpolated position.  This
intermediate stage could be retained (or regenerated just before cycling is
started) and then the mapping of source data (interpolated iteration or
whatever, with log/sqr/linear mapping, arbitrary cycle length, etc.) would
not need to be recalculated for each cycled frame.  Interpolation would
still be necessary, though.  To help that, a pseudo-palette of perhaps 64K
colors might be created (enough to help hide banding), and the intermediate
stage only stores a 16-bit value for each pixel that is an index to that
palette.  Then for each frame, a pixel only needs to be fetched, an offset
added, and its result looked up in the table.  This drastically reduces the
time required to generate each cycled frame, reducing it to basically a
double-blit.  Not as fast as hardware cycling, but perhaps as fast as it
gets for 24-bit color.  (A further optimization would be to special-case
16-bit and 8-bit display modes, where the "blit to screen" step involves
considerably more work.)

We're still left with the question of what to do to color-cycle AA images.
With the technique above, it's just not possible, because the color used to
generate a particular pixel will be the combination of several (possibly
wildly) varying inputs.  The above technique works in parameter space, not
color space, and assumes every pixel lands somewhere exactly on the
palette.  Imagine the palette as a crooked line weaving through 3D color
space; to cycle colors, all that is being done is to propogate points along
the line, in an orderly fashion.  With AA, you have pixels that do not land
on the line; how do you move them along the line, then?  You can't.  What
you really want to do is color-cycle the image data BEFORE you anti-alias,
but that of course is pretty impractical.  I would suggest not even
attempting to color-cycle anti-aliased images.

Unless... :)  You can adopt a totally different color-cycling view for
24-bit fractals.  Steve Ferguson has been experimenting with alternate
techniques in his own programs.  The basic technique is to cycle red,
green, and blue independently of each other.  Since each primary is
independent, let us consider it to be cycling three grey-scale images.
Imagine each grey value (0-255) is an index to a triangular wave, 512 units
long, ramping from 0 to 255 and then back down to zero.  Initially, all
pixels will be in the first half of the cycle.  As the cycle progresses,
each point is offset farther and farther along the triangle wave, until
eventually it loops; each point follows the same path along the wave, but
offset (by its initial value) differently from its neighbors.  Now, put it
back together: red, green, and blue all cycle at the same time, but not
necessarily at the same rate!  The result is not at all like traditional
color-cycling, but it's just as hypnotic.  And the advantage is, it works
with *any* 24-bit image, including anti-aliased fractals or even
photographs, because it works in RGB space and not parameter space.

Eh, well, food for thought.

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


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


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

From: "Damien M. Jones" <[e-mail]>
Subject: Re: (fractdev) XaoS
Date: 17 Sep 1997 14:40:35 -0400

Tim,

 - LINUX and djgpp use AT&T notation assembler, which would be a pain
 - to port. However, I understand that there is a MASM-like freeware
 - assembler. I presume that with Win95 we can use masm itself.

With Win95, I'd almost rather use inline assembly. :)  Mainly because I
don't actually *have* MASM; all of my assembly coding in Win95 has been as
inline assembly in C++ code.  It works very well.  Both MS Visual C++ and
Borland C++ have comprehensive inline assemblers; what they're missing is
usually all the extra stuff you need in .asm files about sharing variables,
declaring procedures, and so on--stuff you can do more easily with C,
anyway. :)

Regarding AT&T notation: this is probably because djgpp is based on a
portable compiler.  The alternative on the PC isn't really "MASM" format,
but Intel's own format for assembly language.  Anyone interested in
programming assembly for PCs should have on hand Intel's Pentium
Programmer's Reference, available in PDF format.  It's a big download, but
thoroughly essential as it's the last processor reference where Intel
actually shows clock counts.  (PPro documents do not.)  I don't have the
exact link to the file, as Intel occasionally moves these things, but you
can probably find a current link to it from http://www.x86.org .

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


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


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

From: "Damien M. Jones" <[e-mail]>
Subject: Re: (fractdev) XaoS
Date: 17 Sep 1997 14:47:15 -0400

Tim,

 - [djgpp does Windows?]
 - No. However there is a similar project that ports GNU C to Windows. I
 - don't think it is as mature yet as djgpp. For the future it is a
 - possibility.

For the record... writing Win32 code without using a class library (like
Microsoft's MFC or Borland's OWL) is a Royal Pain In The Ass.  It can be
done, and I imagine some people even prefer it, but class libraries do take
care of a lot of the repetitive nitty-gritty message handling crap that
Windows requires your app to take care of.  So there is more to making a
good Win32 compiler than just hooking to the API; you either need to write
a class library or license somebody else's.  Theoretically, you can use MFC
with any compiler, but I have not tried this.  (The MFC.DLL avoids the
name-decoration issue by exporting all its functions by number, rather than
by name.)

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


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


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

From: Rich Thomson <[e-mail]>
Subject: Re: (fractdev) 24-bit color: cycling, anti-aliasing, displaying
Date: 17 Sep 1997 16:02:57 -0600


In article <[e-mail]> ,
    "Damien M. Jones" <[e-mail]>  writes:
> <envy>  Yeah, having good optimized versions of things like OpenGL must be
> nice.  PC implementations are still buggy, and unless you have good (read:
> expensive) hardware, performance is lousy anyway.  (Quick note: the
> cheapest decent GL performance on a PC can be had with the Voodoo chip from
> 3Dfx.)

Yes, we at PTC are keeping an eye on OpenGL performance under WinNT,
and the voodoo chip set does look nice.  I'm not keeping too close an
eye on all this stuff because it is changing too quickly.  I'm paying
attention as much as I can afford too, though :)

> Obviously.  But as Tim pointed out a while back, users will not tolerate a
> slower version of FractInt, generally.  Thus virtually all of the assembly
> code would need to be ported before it is releasable.

Well, they could just suffer in the meantime :)  How much can they
bitch considering the software is free!  Some people have no gratitude
:)

> Yes and no.
[drivers converting to display format from application format]

Ah... I wasn't aware of those kinds of machinations under Windows.  I
suppose it makes sense.  Lots of people bitch about the complexity of
handling different visual types under X (8-bit pseudocolor vs. 24-bit
truecolor).  Lots of applications (even commercial ones) STILL get
this wrong, which amazes me considering how long X has been around.
Many applications simply assume that the visuals present in their
development environment will be the same as the visuals present in the
customer's environment, including which visual will be the default
visual.  Fractint's X port suffers from this same flaw, but I'm
working on fixing it :).

> OK, first, you *must* anti-alias in color space, in 24-bit color.
> (Discussions about AA a while back in Fractal-Art show that you can't AA in
> iteration space or any other space in which discontinuities occur.)

If your iteration space is confined to integers, then I agree with
you; however if you use a fractional iteration count, as in Linus'
algorithm for computing a continuous iteration count, then I don't see
a problem with AA in iteration space, but in general I agree with your
analysis above.

> Second, for 8-bit display purposes, you would want to quantize and dither
> on the fly, for the user's convenience.  However, in no way should you
> *attempt* to color cycle such an image; it is the height of lunacy to cycle
> an 8-bit palette which has no bearing on the intended cycling.

Oh, I think people could be allowed to color cycle an image, it just
won't do anything useful :)

> This brings up bigger points: how do you color-cycle a 24-bit image, and
> how do you color-cycle an anti-aliased image?

I think the general answer is that you don't color cycle anything
other than 8-bit pseudocolor images.  At least in the way fractint
treats color cycling currently.  What you are really doing is changing
the color lookup table that maps iterations to pixels.  So if you want
to "color cycle" a 24-bit or AA image, then you have to recompute the
entire screen in order to get the effect.  Fractint users are
accustomed to color cycling by manipulating the video palette in the
hardware.  You're essentially using the CLUT in the video card to
handle the mapping of iterations to pixels.  You're storing the
iterations directly in the frame buffer and the CLUT performs the
index -> RGB mapping.  When creating AA renderings or 24-bit
renderings, this mapping is done in software.  Obviously we could
"color cycle" a 24-bit image, but the time it takes to remap all the
iterations to pixels for the entire screen wouldn't be anywhere near
as fast as manipulating the DAC.  One could do it, but when its that
slow, my inclination is to shrug my shoulders and say "what's the
point?"

[24-bit color cycling scheme]
> Not as fast as hardware cycling, but perhaps as fast as it
> gets for 24-bit color.

Yeah, I'm not sure its worth all the effort.  I think most people would
be willing to give up color cycling for the ability to generate 24-bit
AA fractals.

> Unless... :)  You can adopt a totally different color-cycling view for
> 24-bit fractals.  Steve Ferguson has been experimenting with alternate
> techniques in his own programs.  The basic technique is to cycle red,
> green, and blue independently of each other. [...]

In 24-bit modes under X there is the possibility of using the hardware
colormap to "cycle" in just this manner.  I don't know if Windows
provides a colormap that is used in 24-bit mode though.  In
workstations, this colormap is typically used to allow the application
finer control over the gamma correction process.  (For instance, I can
write my own gamma map into the CLUT and use this in conjunction with
certain AA line/dot algorithms that depend on a proper treatment of
gamma in order to avoid "ropiness" and other artifacts in the
lines/dots.)
--
  ``Between stimulus and response is the will to choose.''  -- Steven Covey
 =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
     3D Paint: The Power to Create in 3D;        Rich Thomson
     email me for more info                [e-mail]

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


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

From: Rich Thomson <[e-mail]>
Subject: Re: (fractdev) XaoS
Date: 17 Sep 1997 16:07:25 -0600


In article <[e-mail]> ,
    "Damien M. Jones" <[e-mail]>  writes:
> For the record... writing Win32 code without using a class library (like
> Microsoft's MFC or Borland's OWL) is a Royal Pain In The Ass. [...]

Yes, that is my basic impression.  I have some books on the Windows
API that I bought a while back.  I bought them so I would have some
reasonable familiarity with Windows in order to keep my job skills
current :).  I came to the conclusion that Windows wasn't really any
different from the windowing APIs with which I was already familiar.
Naturally there are particular differences in how graphics is handled
and so on, but the basic event-driven model of an application remains.
What I did notice was that a Windows application has to handle more
than your typical X application just due to the architecture of PC
windowed environments (no window manager, for one thing).  I also came
to the conclusion that without a good class library, or at least a
very well fleshed out skeleton program that took care of the
repetitive details that programming in such environments is a pain.
I've seen the amount of code it takes to write a simple "hello world"
Mac application in Lightspeed C/Pascal and its a huge mess.  (This is
for a "hello world" application that completely adheres to and
conforms to the guidelines and suggestions in the Mac interface
guidelines.)

I just saw a Borland C++ Win 95/NT compiler environment at an auction
preview.  If I could pick it up for a song, would it be worth buying?
--
  ``Between stimulus and response is the will to choose.''  -- Steven Covey
 =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
     3D Paint: The Power to Create in 3D;        Rich Thomson
     email me for more info                [e-mail]

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


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

From: Rich Thomson <[e-mail]>
Subject: Re: (fractdev) XaoS
Date: 17 Sep 1997 16:19:13 -0600


In article <[e-mail]> ,
    "Damien M. Jones" <[e-mail]>  writes:
> Anyone interested in
> programming assembly for PCs should have on hand Intel's Pentium
> Programmer's Reference, available in PDF format.  It's a big download, but
> thoroughly essential as it's the last processor reference where Intel
> actually shows clock counts.  (PPro documents do not.)  I don't have the
> exact link to the file, as Intel occasionally moves these things, but you
> can probably find a current link to it from http://www.x86.org .

I found this page that has links to the above docs.
<URL: http://www.x86.org/intel.doc/IntelDocs.html>
--
  ``Between stimulus and response is the will to choose.''  -- Steven Covey
 =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
     3D Paint: The Power to Create in 3D;        Rich Thomson
     email me for more info                [e-mail]

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


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

From: "Tim Wegner" <[e-mail]>
Subject: Re: (fractdev) XaoS
Date: 17 Sep 1997 21:38:24 -0600

Rich asked:

> I just saw a Borland C++ Win 95/NT compiler environment at an auction
> preview.  If I could pick it up for a song, would it be worth buying?

What version? You could actually use it to compile the DOS fractint,
though our Borland support is spotty.

I believe 3.1 or later works for DOS. I think they are up to version
5 or maybe 4. George Martin might know better, he uses Borland, but
not a current 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: George Martin <[e-mail]>
Subject: Re: (fractdev) XaoS
Date: 18 Sep 1997 00:45:02 -0400

Tim,

Regarding Borland, you wrote:

>
I believe 3.1 or later works for DOS. I think they are up to version
5 or maybe 4. George Martin might know better, he uses Borland, but
not a current version.
<

     After a year or so of neglect, we got the Borland compile working
again with 19.4. I use 3.1, and the .prj files distributed with the 19.6
source code should work. I have not fine tuned the overlays yet; the
executable which I produce with 3.1 uses way too much memory, and some
features are lost (e.g. the ability to shell to DOS) as a result. Any
experienced Borland users who want to take on the overlay structure are
welcome to do so! I am interested primarily in getting a good compile so I
can test and debug code that I write, and the current .prj files are
sufficient for my purposes. I have 4.5 in the box, but not the related
TASM, which needs to be purchased separately beginning with the 4.x
versions. Borland is at least into 5.x, but I am not familiar with it.

George

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


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

From: "Damien M. Jones" <[e-mail]>
Subject: Re: (fractdev) 24-bit color: cycling, anti-aliasing,
Date: 18 Sep 1997 13:04:34 -0400

Rich,

 - [slower WinFract w/o assembly]
 - Well, they could just suffer in the meantime :)  How much can they
 - bitch considering the software is free!  Some people have no gratitude
 - :)

It has been my experience that people generally expect a lot from software,
even if they haven't paid for it.  Some of the most demanding people are
those who are in no position to contribute.

I assume you don't want to get into a philosophical discussion about why
free software is written in the first place. :)

 - [drivers converting to display format from application format]
 -
 - Ah... I wasn't aware of those kinds of machinations under Windows.  I
 - suppose it makes sense.  Lots of people bitch about the complexity of
 - handling different visual types under X (8-bit pseudocolor vs. 24-bit
 - truecolor).

I doubt it's much different than Windows, really.  BTW, I forgot to point
out something yesterday.  I mentioned that in Windows, if you want a window
to represent a bitmap, you must construct the bitmap, and write a handler
for the redraw message that blits the bitmap onto the screen.  One of the
primary reasons I wrote image libraries for Windows was to take care of
this.  With a few lines of setup code, I can set up such a window and
basically never have to worry about it again.  Ah, the wonder of class
libraries... :)

 - [anti-aliasing in parameter space]
 - If your iteration space is confined to integers, then I agree with
 - you; however if you use a fractional iteration count, as in Linus'
 - algorithm for computing a continuous iteration count, then I don't see
 - a problem with AA in iteration space, but in general I agree with your
 - analysis above.

Oh, it's easy enough to see why anti-aliasing in color space is necessary.
Even with continuous potential coloring, there is a discontinuity--a place
where potential becomes meaningless.  And that is all inside points.  Any
pixel which contains inside and outside points throws off your
anti-aliasing in parameter space (in this case, the parameter is
potential).  Also, the more I think about it, what you're trying to
accomplish with AA is to filter an object (fractal) with infinite frequency
content so that frequencies that can't be represented by your sampling grid
aren't aliased down to lower frequencies.  Now, think back to the winding
line through 3D space that is the user's palette.  If you AA in parameter
space, you still always end up with points along that line--but to me it
just seems like if you're really attentuating higher frequencies, you need
to replace them with a kind of "average"--you need to do what the human eye
does when it's not focusing on the detail of a texture, and that is to
simply note the overall color.  Such colors will most always NOT be on the
palette line.

 - [color-cycling an 8-bit "system" palette]
 - Oh, I think people could be allowed to color cycle an image, it just
 - won't do anything useful :)

OK, point taken.  I just don't think the results are worth bothering with. :)

 - I think the general answer is that you don't color cycle anything
 - other than 8-bit pseudocolor images.  At least in the way fractint
 - treats color cycling currently.

Well, as you say, FractInt uses the hardware to do the cycling.  If the
winding line through 3D color space is the palette, FractInt's palette is
simply 256 sample points along that line.  FractInt's doing exactly what I
suggested, and that is propogating points along that line, just with fixed
steps, and because it only needs to to change 768 hardware registers, it
can be done quickly.

 - So if you want to "color cycle" a 24-bit or AA image, then you have to
 - recompute the entire screen in order to get the effect.

Exactly.  I was describing ways this might be optimized.  I'm not terribly
sure it's important.

 - Fractint users are accustomed to color cycling by manipulating the video
 - palette in the hardware.

99% of FractInt users probably aren't really aware of how it's done, they
just like the effect. :)

 - Obviously we could "color cycle" a 24-bit image, but the time it takes to
 - remap all the iterations to pixels for the entire screen wouldn't be
 - anywhere near as fast as manipulating the DAC.  One could do it, but when
 - its that slow, my inclination is to shrug my shoulders and say "what's the
 - point?"

Well, it depends how slow you consider too slow.  I find color cycling at
high speeds to be somewhat disorienting for most pictures, so the frame
rate I usually end up with is between 15 and 30 anyway.  On a modern PC,
these speeds are not unreachable, given the optimization techniques I
described yesterday, although for AA color they *might* be too slow.
Non-AA should at least be acceptable.

 - Yeah, I'm not sure its worth all the effort.  I think most people would
 - be willing to give up color cycling for the ability to generate 24-bit
 - AA fractals.

Funny you should mention that.  I know at least one person who uses Steve
Ferguson's Flarium24 program, and the feature they miss most is
color-cycling.  This person has *some* programming background, but
definitely not in hardware, and they don't completely understand why
color-cycling in 24-bit color is so hard.  When Steve showed her a 24-bit
cycler of the second variation I described (the triangle-wave thing) she
was *escstatic*.

If I get time today, maybe I'll do a "proof of concept" on the cycler. :)

 - In 24-bit modes under X there is the possibility of using the hardware
 - colormap to "cycle" in just this manner.  I don't know if Windows
 - provides a colormap that is used in 24-bit mode though.  In
 - workstations, this colormap is typically used to allow the application
 - finer control over the gamma correction process.

The Windows API does not provide a standard way (yet) of accessing hardware
LUTs for 24-bit display, primarily because not all PC graphics cards
support them.  I know the Matrox Millenium does, because its control panel
allows the user to tweak it.  I think this is an invaluable feature, but my
own graphics card (based on the S3, a *very* popular chipset) does not
offer it.  Such a shame.

The Macintosh has supported this feature for quite a long time.  Up through
the last of the 68K Macs, it was even application-accessible, and this is
how the KPT Cyclone filter (in the KPT 2 package) worked--it cycled colors
pretty much in the new fashion I described yesterday.  However, on
PowerMacs this apparently doesn't work (probably because the table moved or
something, and KPT Cyclone was banging the table directly instead of using
an API) and thus this filter was dropped when KPT 3 was released.  No
attempt was made to convert the technique to a full-screen blit, once
access to the hardware was denied.  A pity.

 - (For instance, I can write my own gamma map into the CLUT and use this in
 - conjunction with certain AA line/dot algorithms that depend on a proper
 - treatment of gamma in order to avoid "ropiness" and other artifacts in
 - the lines/dots.)

Ah, nostalgia.  You've just reminded me of Spectrum 512, the only thing
close to a "true color" paint program for Atari STs.  (Those of you not
interested in my meanderings on this subject should skip the rest of this
message. :)

<nostalgia>
The Atari ST had a hardware palette of 512 colors--eight shades of each
primary.  However, the highest number of colors it could display was 16.
The horizontal blank could be set up to trigger an interrupt, so that at
the end of each scan line, the hardware palette could be changed and a new
set of 16 colors used on the next line.  (Ah, the tricks we had to resort
to back then!)  Atari flatly denied that more colors could be obtained from
the computer than this.

Well, some very clever programmers decided to stick it in Atari's eye.
They observed that the CPU was just fast enough to reprogram the palette
registers three times per scanline, plus a few instructions to spare for
setting up registers and such.  This gave 48 colors per scanline, although
for any given pixel only sixteen were possible.  The fact that colors were
changed dynamically as the monitor beam swept across the screen was also
pretty inconvenient when it came to deciding just how to allocate those
colors, but the point was, the technique worked.  It was stable.  And it
worked on all Atari STs of the day (which all had the same clock speed and
video circuitry).

These guys could have done something simple with the technique, like write
a picture converter for displaying GIFs.  (They did, eventually.)  Instead,
the first thing they did with it was write a *paint program*.  And they
didn't just write any old paint program; they figured, since they had true
color, they might as well let it do anti-aliased lines and circles, too.

When I first saw this program, knowing what I knew about the hardware of
the Atari ST, I just about crapped my pants.  And the anti-aliasing, well,
that was icing on the cake.  And why do I think of this?  Because with only
eight shades of each primary color, there isn't sufficient color resolution
to do anything about gamma, and that means the ropiness you describe is
exactly what I saw.  Better than no AA, but definitely NOT the best that AA
has to offer.
</nostalgia>

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


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


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

From: "Damien M. Jones" <[e-mail]>
Subject: Re: (fractdev) XaoS
Date: 18 Sep 1997 13:05:27 -0400

Rich,

 - I just saw a Borland C++ Win 95/NT compiler environment at an auction
 - preview.  If I could pick it up for a song, would it be worth buying?

Depends on the version.

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


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


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

From: Rich Thomson <[e-mail]>
Subject: Re: (fractdev) XaoS
Date: 18 Sep 1997 15:23:53 -0600


In article <[e-mail]> ,
    "Damien M. Jones" <[e-mail]>  writes:
>  - I just saw a Borland C++ Win 95/NT compiler environment at an auction
>  - preview.  If I could pick it up for a song, would it be worth buying?
>
> Depends on the version.

Well I just bought it for $20.  I figure even if its a newer version
without the bundled assembler, it was a good deal.  There might be one
missing manual, but for $20 I can live with that.  The CD was still
sealed in its little envelope and the manuals had a copyright date
inside them of 1997.  So it seems that its pretty new.  I did scan
around quickly at the auction house to see if I could find a version
number but it wasn't obvious.  Right now its in my car and I won't
look at it in detail until I get home tonight.  I also bought a Visual
J++ Professional Version (java) development environment, shrink-wrapped,
brand new for $30.  I considered both of them to be a good deal!
--
  ``Between stimulus and response is the will to choose.''  -- Steven Covey
 =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
     3D Paint: The Power to Create in 3D;        Rich Thomson
     email me for more info                [e-mail]

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


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

From: "Tim Wegner" <[e-mail]>
Subject: (fractdev) Wishlist page
Date: 18 Sep 1997 22:16:24 -0600

There are already ideas on Robin's wish list page. A wish list page
is a better idea than I realized. Some of the ideas would be easy to
implement. I suggest folks give the page a quick look from time to
time.

Perhaps there should be an author's feedback section, though I guess
it is unnecessary, we could just enter feedback as a wish on the
list.

Tim

The page is:

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


Thanks for using Fractdev, 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) truecolor
Date: 23 Sep 1997 20:44:04 -0600

Mark Sargent sent us a patch to add a continuous potential truecolor
algorithm as a test fractal type to Fractint.

I've studied Mike Sargent's patch, and while the effect is very nice
(and we owe him a lot for nudging us toward truecolor), the
implementation leaves a lot to be desired. It uses two passes (very
wasteful). We might use his inside BOF algorithm.

I'd prefer to use Linas Vepstas' algorithm. It is:

      int iter_count = 0;
      float escape_radius = 20.0;
      complex Z, C;
      loop (forever) {
         Z = Z*Z +C;
         iter_count ++;
         float modulus = sqrt (ReZ*ReZ + ImZ*ImZ);
         if (modulus > escape_radius) goto stop;
         if (iter_count > maxiter) goto stop;
      }

   stop:
      float mu = iter_count - (log (log (modulus)))/ log (2.0);
      color_value = colormap_lookup (mu);
      draw_pixel;

For more info, see

http://linas.org/art-gallery/escape/escape.html

Both Linas's and Mike's approach have the virtue that they can be used
with 256-color palettes. They both smoothly transition the colors
between bands. This means that artists can design colors in 256 color
modes using the existing palette editor.

Thanks to Lee Skinner for persisting in emailing truecolor discussion.
Linas's web page summarizes the situation nicely.

The 2.0 in Linas's formula should actually be the effective degree of
the fractal formula. It is a parameter that can be tuned with
different algorithms.

I should be working on synchronous orbits, but I find I
am distracted by truecolor <g!>

In my musings in the last few days I have wondered if we should add
an addition section to a formula that could be used to calculate
colors. For starters I'm just planning a screen that allows selecting
various parametrized truecolor algorithms.

It won't take long to get truecolor up and running, but there are
many details that will have to be adjusted for truecolor before this
is releasable.

Tim

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


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

From: "Damien M. Jones" <[e-mail]>
Subject: Re: (fractdev) truecolor
Date: 23 Sep 1997 23:12:10 -0400

Tim,

 - I'd prefer to use Linas Vepstas' algorithm. It is:

I'd lean in this direction too, even if I hadn't already written a .FRM for
it. :)  (Er, that's dmj-Mand-Smooth, dmj-Mand-SmoothPHC, and
dmj-Mand-SmoothX2.)

 - In my musings in the last few days I have wondered if we should add
 - an addition section to a formula that could be used to calculate
 - colors. For starters I'm just planning a screen that allows selecting
 - various parametrized truecolor algorithms.

Um, hopefully some of the color schemes I barfed up will make their way
there... but I definitely like the thought of having another screenful of
coloring options to play with.  Making true-color algorithms simply produce
output in the range 0-1 and then mapping that range onto a palette
(smoothly interpolated between the 256 colors present in it) would leverage
the existing palette library of many FractInt users while letting them
benefit from the new smooth coloring.

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


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


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

From: "Tim Wegner" <[e-mail]>
Subject: (fractdev) What's up
Date: 28 Sep 1997 10:19:19 -0600

Since things are quiet, I thought I'd better say what I'm doing.
Several other developers are also at work. For most of us
professional life limits our Fractint time these days. We work, but
breakthrough's come slowly.

I was working on synchronous orbits, and still intend to finish this,
however the "customers" seem more interested in truecolor. I have an
experimental patch by Mike Sargent that implements a continuous
potentional truecolor algorithm. It looks nice, but I prefer Linas
Vepstas's approach. I have taken some time to think through how to
implement truecolor, and it doesn't look too bad, especially if we
usurp all the putcolor() function pointers yet again.

Thinking about truecolor led me to PNG. No point having truecolor
if you can't save the image. Of course we could implement saving as a
Targa easily (the code is already there). The next few paragraphs may
be unintelligible to those who have not wrestled with PC programming
:-)

I have worked with the PNG team long and hard to make the data types
model independent, using the far keyword. Thank goodness, or using
LibPNG with Fractint would be impossible. However I found other
medium model problems.

1. The code is littered with string literals for error messages that
gobble up near memory.

2. Libpng uses setjmp and longjmp which prevent saving memory with
overlays. You can't longjmp across to another overlay. Actually, you
CAN, but the compiler keeps both in memory at the same time,
defeating the purpose of the overlay.

I am not giving up. Both of these problems can possibly be cleared up
with careful use of macros that won't mess up the Libpng and Zlib
code much at all. I'd LOVE to have truecolor and PNG working in the
DOS fractint if it's possible.

You see the problem these days - looking at one issue takes one to
another issue. Truecolor leads to PNG which leads to a port to a
decent memory environment.

But if you look at Robin's wish list page, there are a number a pleas
not to abandon DOS (along with other suggestions to turn Fractint
into a DLL or a java class <g!>)

Tim



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


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

From: Darryl House <[e-mail]>
Subject: re: (fractdev) What's up
Date: 28 Sep 1997 10:57:42 -0700


Hi ... some of you will know me... others, well, it's nice to meet you :-)

A couple of years ago I developed a version of Fractint for X-Windows and
Motif, named xmfract. Tim and I and a few of the other developers have
been tossing around ideas for creating a file-compatible and
code-compatible version of Fractint capable of running and displaying
on U**x machines.

The main drawbacks to the current version of xmfract are that it is not
code-compatible with the current version of Fractint, making updates
tedious, and that it requires Motif, a commercial product. Another
annoyance is that the thing has a rather rudimentary GUI by today's
standards (I developed it as an exercise in Motif, intending to use it as
a training tool for Motif techniques). There are more... <g>.

Enough of the history lesson. I've been sporadically exploring techniques
for creating a platform-independent, code-compatible version of Fractint.
A huge task, as you can imagine. Anyway -- the results of that
exploration have indicated that a Tcl/Tk and/or Java framework for the GUI
is the most likely approach. One can never really develop a totally
device-independent project, imho -- at some point we must necessarily
write code for various platforms. This being said, one of the next hurdles
to cross is to decide if and how to approach separating the GUI code from
the core code. Doing that while still retaining DOS compatibility is
challenging. We'll probably need to branch the code with the preprocessor
to supplant some routines with others that incorporate disparate GUI
routines.

[Tim wrote:]
>For most of us professional life limits our Fractint time these days.
>We work, but breakthrough's come slowly.

Hear! Hear! <big ol' grin>

My professional life consumes an inordinate amount of time lately,
so I've only devoted a small amount of time to this. That situation will
continue for the foreseeable future. I can put a few hours in here and there,
and maybe someday we'll have a real plan <s!>.


Thanks for using Fractdev, 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) PNG
Date: 28 Sep 1997 21:47:41 -0600

I added save-to-PNG to Xfract. This was easily done. It's
just a simple prototype and doesn't yet save the fractal
data. However, this code will never run under the DOS fractint as
long as we are using conventional memory under the medium model -
there's not enough free memory. Inflate needs to be able to malloc()
a minimum of 256K.

PNG reading uses less memory and will probably work within the DOS
Fractint OK.

The good news is that I have stumbled on an easy kludge for PNG
support that should work fine. It turns out that even when
free conventional memory is very low, a system() call to a
djgpp-compiled program (GNU C with DOS extender) can access extended
memory fine. Sounds like a paradox, but with as little as 100K or so
free memory in Fractint, I can call system() and run an extended DOS
program that can malloc() 1000K of memory! So I'll implement save to
PNG by writing a temporary file and shelling to a stand-alone program
that converts the temporary file to PNG.

My priorities have now been re-arranged, They are:

1. PNG
2. Truecolor
3. Synchronous Orbits

I'll implement PNG simultaneously under both Xfract and DOS. I won't
use the DOS kludge under Xfract. So what I implement in Xfract can be
used for future versions.

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) What's up
Date: 28 Sep 1997 21:47:41 -0600

> Tim and I and a few of the other developers have
> been tossing around ideas for creating a file-compatible and
> code-compatible version of Fractint capable of running and displaying
> on U**x machines.

Others here are thinking along similar lines, although we also have
the dissenting opinion that GUI's shouldn't be portable. But every
one is in favor of making the underlying fractint engine independent
of the GUI as you suggest.

> One can never really develop a totally
> device-independent project, imho -- at some point we must necessarily
> write code for various platforms.

The Python fanatics at work say skip TK and TCL and go straight to
Python. All the GUI work and portability is done at a high level in
Python. Fractint's C code can be called directly from Python if it is
organized right. This sounds appealing, but I don't want to have to
distribute Python in order to distribute Fractint. However, the work
of organizing the fractint code is probably similar for this approach
as to others.

Tim



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


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

From: Rich Thomson <[e-mail]>
Subject: Re: (fractdev) What's up
Date: 28 Sep 1997 21:42:42 -0600


In article <[e-mail]> ,
    "Tim Wegner" <[e-mail]>  writes:
> The Python fanatics at work say skip TK and TCL and go straight to
> Python. [...]
> This sounds appealing, but I don't want to have to
> distribute Python in order to distribute Fractint.

This is why my inclination is to avoid python and Tcl/Tk altogether
and just abstract out the interface we have now and write the
necessary platform-specific routines for the interface bits.  This is
how xaos does its interface, and I think we could do the same.
My .02
--
  ``Between stimulus and response is the will to choose.''  -- Steven Covey
 =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
     3D Paint: The Power to Create in 3D;        Rich Thomson
     email me for more info                [e-mail]

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