ftp.xmission.com/2014.06.ftp.xmission.com.tar/ftp.xmission.com/pub/lists/fractdev/archive/v01.n005

Internet Message Format | 1998-03-18 | 43KB

From: [e-mail] (fractdev-digest)
To: [e-mail]
Subject: fractdev-digest V1 #5
Reply-To: fractdev-digest
Sender: [e-mail]
Errors-To: [e-mail]
Precedence: bulk


fractdev-digest       Wednesday, March 18 1998       Volume 01 : Number 005




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

Date: Mon, 02 Feb 1998 15:50:26 -0700
From: Rich Thomson <[e-mail]>
Subject: Re: (fractdev) Re: progress.txt

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

Oops, you're right. Sorry :)
- --
                                               Rich Thomson
                                               [e-mail]

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

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

Date: Mon, 02 Feb 1998 16:07:34 -0700
From: Rich Thomson <[e-mail]>
Subject: Re: (fractdev) modulus function and image precalc

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

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

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

You know what, I thought that was available, but not according to the
documentation...looks like there might be other stuff that should be
available in the environment as well.
- --
                                               Rich Thomson
                                               [e-mail]

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

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

Date: Mon, 02 Feb 1998 17:21:31 -0600
From: "Damien M. Jones" <[e-mail]>
Subject: Re: (fractdev) modulus function and image precalc

Rich,

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

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

Damien M. Jones   \\
[e-mail]  \\  http://www.icd.com/tsd/  (temporary sanity designs)
                    \\  http://www.fractalus.com/ (fractals are my hobby)


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

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

Date: Mon, 02 Feb 1998 17:19:54 -0600
From: "Damien M. Jones" <[e-mail]>
Subject: Re: (fractdev) Notion: coloring formulae

Rich,

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

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

Damien M. Jones   \\
[e-mail]  \\  http://www.icd.com/tsd/  (temporary sanity designs)
                    \\  http://www.fractalus.com/ (fractals are my hobby)


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

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

Date: Mon, 02 Feb 1998 16:41:19 -0700
From: Rich Thomson <[e-mail]>
Subject: Re: (fractdev) Notion: coloring formulae

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

I wondered why noone commented at all on that message when I sent it
to fractint.  There was a deafening silence in response :).  Then
again, with so many messages, I shouldn't be surprised it got lost in
the noise.  However, you did add one extra thing that I didn't include
in my proposal which is adding the color-iteration bailout condition.
For most standard colorings, this is just 1 (exception: epsilon-cross,
etc., methods).
- --
                                               Rich Thomson
                                               [e-mail]

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

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

Date: Mon, 2 Feb 1998 16:05:43 -0800
From: "Jay Hill"<[e-mail]>
Subject: Re: (fractdev) modulus function and image precalc

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

Jay




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

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

Date: Mon, 2 Feb 1998 18:19:03 -0600
From: "Tim Wegner" <[e-mail]>
Subject: Re: (fractdev) progress.txt

Rich wrote:

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

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

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

Whatever works is OK by me.

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

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

Tim


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

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

Date: Mon, 2 Feb 1998 18:19:03 -0600
From: "Tim Wegner" <[e-mail]>
Subject: Re: (fractdev) Welcome to Jonathan

Rich asked:

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

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

Tim


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

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

Date: Mon, 2 Feb 1998 18:19:03 -0600
From: "Tim Wegner" <[e-mail]>
Subject: Re: (fractdev) Notion: coloring formulae

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

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

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

Tim


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

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

Date: Mon, 02 Feb 1998 17:53:32 -0700
From: Rich Thomson <[e-mail]>
Subject: Re: (fractdev) progress.txt

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

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

Broken software should not be excused or tolerated; it should be fixed
or replaced.  If I "owned" fractint, I would say "hey, all you people
with broken MIME mailers, get your software fixed", but I don't, so I
can't and we have 500 message threads about "3D disease".
- --
                                               Rich Thomson
                                               [e-mail]

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

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

Date: Mon, 02 Feb 1998 17:54:35 -0700
From: Rich Thomson <[e-mail]>
Subject: Re: (fractdev) Welcome to Jonathan

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

OK, I've added this stuff to the "progress.txt" file.
- --
                                               Rich Thomson
                                               [e-mail]

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

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

Date: Mon, 02 Feb 1998 17:55:14 -0700
From: Rich Thomson <[e-mail]>
Subject: Re: (fractdev) Notion: coloring formulae

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

I don't claim to be the first to think of it (most good ideas have
already been thought of before), but considering my post to fractint
on the exact same subject, it was funny :)
- --
                                               Rich Thomson
                                               [e-mail]

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

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

Date: Mon, 2 Feb 1998 21:29:05 -0500
From: Jonathan Osuch <[e-mail]>
Subject: Re: (fractdev) Welcome to Jonathan

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

Rich,

[e-mail]

Jonathan

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

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

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

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

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

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

Let me know if you have any problems.

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

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

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

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

Tim




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

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

Date: Tue, 3 Feb 1998 09:28:28 EST
From: [e-mail]
Subject: Re: (fractdev) Developer's Version 1961p28

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

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

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

 Tim
  >>

Tim,
Is MASM 6.0 satisfactory?
Ron

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

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

Date: Tue, 3 Feb 1998 10:33:11 -0500
From: George Martin <[e-mail]>
Subject: (fractdev) image precalc

Tim,

>precalc (the once per image)

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

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

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

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

George


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

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

Date: Tue, 03 Feb 1998 10:40:19 -0600
From: "Damien M. Jones" <[e-mail]>
Subject: Re: (fractdev) image precalc

George,

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

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

Damien M. Jones   \\
[e-mail]  \\  http://www.icd.com/tsd/  (temporary sanity designs)
                    \\  http://www.fractalus.com/ (fractals are my hobby)


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

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

Date: Tue, 03 Feb 1998 10:12:16 -0700
From: Rich Thomson <[e-mail]>
Subject: Re: (fractdev) image precalc

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

Does scrnpix start at zero with a view window?
- --
                                               Rich Thomson
                                               [e-mail]

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

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

Date: Tue, 3 Feb 1998 20:31:00 -0600
From: "Tim Wegner" <[e-mail]>
Subject: Re: (fractdev) Developer's Version 1961p28

> Tim,
> Is MASM 6.0 satisfactory?

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

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

Tim


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

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

Date: Fri, 6 Feb 1998 13:23:21 EST
From: [e-mail]
Subject: Re: (fractdev) Developer's Version 1961p28

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

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

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

 Tim
  >>

No problem!

My time has been at a real premium lately. My company is doing a spin off,
followed by a major downsizing. Right now I am just trying to keep my head
above water.
Ron

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

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

Date: Sun, 8 Feb 1998 16:01:17 -0600
From: "Tim Wegner" <[e-mail]>
Subject: (fractdev) Simplgif source

I have uploaded the simplgif source to

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

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

Tim




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

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

Date: Tue, 24 Feb 1998 16:31:07 -0600
From: "Justin A. Kolodziej" <[e-mail]>
Subject: (fractdev) test

This is a test-please ignore.

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

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

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

Date: Tue, 24 Feb 1998 23:50:08 -0600
From: "Tim Wegner" <[e-mail]>
Subject: (fractdev) simplgif

I have uploaded a massively revised simplgif program to

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

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

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

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

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

Tim


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

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

Date: Fri, 27 Feb 1998 10:41:18 -0700
From: Rich Thomson <[e-mail]>
Subject: (fractdev) Re: Mac Port of FracInt?

I'm replying to fractdev...

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

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

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

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

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

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

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

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

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

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

One thing I'd like to suggest before you start modifying code is that
you set yourself up with a source code revision system on your Mac.  I
am not sure what's available for the Mac, but I've had good experience
with RCS and CVS.  CVS is better, it builds on top of the foundation
provided by RCS.  However, you can do source file management with RCS
itself.  The reason I suggest this is that it makes it much easier to
share code changes since you can use the 'diff' and 'patch' tools to
generate deltas between source files from one developer's tree, use
email to communicate the delta and then another developer can use
patch to incorporate your delta into their source tree.  Works really
great.
- --
                                               Rich Thomson
                                               [e-mail]

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

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

Date: Fri, 27 Feb 1998 10:45:01 -0700
From: Rich Thomson <[e-mail]>
Subject: (fractdev) Re: (fractint) Mac Port of FracInt?

I'm replying to fractdev...

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

I wouldn't worry about speed just yet :).
"First make it right, then make it tight."
- --
                                               Rich Thomson
                                               [e-mail]

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

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

Date: Fri, 27 Feb 1998 19:44:17 -0600
From: "Tim Wegner" <[e-mail]>
Subject: Re: (fractdev) Re: Mac Port of FracInt?

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

The important things to preserve are

short = 16 bits
long = 32 bits

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

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

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

Rich wrote:

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

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

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

Tim


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

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

Date: Mon, 02 Mar 1998 12:34:22 -0700
From: Rich Thomson <[e-mail]>
Subject: Re: (fractdev) Re: Mac Port of FracInt?

In article <[e-mail]> ,
    "Tim Wegner" <[e-mail]>  writes:
> It is sufficient to have the diff and patch programs.

Yep, but you're going to wish you had a revision control system the
first time you accidentally delete your changes :)

But you're right, diff and patch alone can get you easily exchanging
source changes without a revision control system.  But a revision
control system makes so many things in code development easier.
- --
                                               Rich Thomson
                                               [e-mail]

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

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

Date: Mon, 16 Mar 1998 00:51:19 -0500
From: DeRobertis <[e-mail]>
Subject: (fractdev) DiskVid.c vs. The Prototypes File

For XFRACT, DiskVid.c and the file with all the prototypes do not agree
with each other.

The specific problem is whether the int's are signed or not. I know the
Boreland does not care about this, but the MPW ones do. ANSI probably also
cares.

Anyway, the followign changes seem to fix it (at least it compiles):

File #1: DISKVID-OLD.C
File #2: DISKVID-NEW.C

Nonmatching lines (File "MPW:GM:MPW:My_Projects:DISKVID-OLD.C"; Line 372;
File "DISKVID.C"; Line 372:376)
 372    int readdisk(unsigned int col, unsigned int row)

 372    #ifndef XFRACT /* Added during Mac port */
 373    int readdisk(unsigned int col, unsigned int row)
 374    #else
 375    int readdisk(int col, int row)
 376    #endif


Nonmatching lines (File "MPW:GM:MPW:My_Projects:DISKVID-OLD.C"; Line 424;
File "DISKVID.C"; Line 428:432)
 424    void writedisk(unsigned int col, unsigned int row, unsigned int color)

 428    #ifndef XFRACT /* Added during Mac Port */
 429    void writedisk(unsigned int col, unsigned int row, unsigned int color)
 430    #else
 431    void writedisk(int col,int row, int color)
 432    #endif


*** EOF on both files at the same time ***



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

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

Date: Tue, 17 Mar 1998 23:31:04 -0600
From: "Tim Wegner" <[e-mail]>
Subject: Re: (fractdev) DiskVid.c vs. The Prototypes File

DeRobertis wrote:

> For XFRACT, DiskVid.c and the file with all the prototypes do not agree
> with each other.

Thanks, I'll have a look at the changes.

There's a possibility that we'll release in April, since Jonathan and
Robin are winding up evolver. If so, we should seriously look at how
well our developer version ports to Xfractint. There are likely to be
some more changes. In the next few days I'll make the developer
source available to folks here again. I'd really like to have some
Linux/Unix folks get involved with the development.

Paul Lee has offerred to have a look at the documentation. I'll make
the current help compiler and the *.src files available also.

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"

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

Date: Wed, 18 Mar 1998 00:26:53 -0600
From: "Paul N. Lee" <[e-mail]>
Subject: (fractdev) Documentation and Help files....

Tim Wegner wrote:
>
> Paul Lee has offerred to have a look at the documentation.
> I'll make the current help compiler and the *.src files
> available also.
>

I have several Help Compilers (versions/levels/types):
    HC.EXE     (165,334 bytes) Sunday, November 10, 1991 22:00:00
    HCP.EXE    (236,288 bytes) Tuesday, September 07, 1993 16:29:34
    HC30.EXE   (133,835 bytes) Friday, September 16, 1994 14:00:00
    HC31.EXE   (236,304 bytes) Wednesday, April 28, 1993
    HC31.EXE   (174,439 bytes) Friday, September 16, 1994 14:00:00
    HCRTF.EXE  (333,312 bytes) Tuesday, October 03, 1995 20:58:32
    HCW.EXE    (496,640 bytes) Tuesday, October 03, 1995 20:58:34
    VH.EXE     (327,714 bytes) Sunday, September 19, 1993 14:43:52
    etc....
If you have a particular one that you wish used, then let me know.  It's
been many months since I've created help documents, but it shouldn't
take more than an hour to get back into the swing of things.

No problem with any of it (merging, updating, editting, etc.).  Just
give the details and files.

Later,
P.N.L.

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

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

Date: Wed, 18 Mar 1998 10:59:58 -0600
From: Justin A Kolodziej <[e-mail]>
Subject: Re: (fractdev) DiskVid.c vs. The Prototypes File

Tim Wegner wrote:
>
> DeRobertis wrote:
>
> > For XFRACT, DiskVid.c and the file with all the prototypes do not agree
> > with each other.
>
> Thanks, I'll have a look at the changes.
>
> There's a possibility that we'll release in April, since Jonathan and
> Robin are winding up evolver.

I hope so.  Release after the first week of May, and there's a
possibility I won't get it until September when I go back to college.

> If so, we should seriously look at how
> well our developer version ports to Xfractint. There are likely to be
> some more changes. In the next few days I'll make the developer
> source available to folks here again. I'd really like to have some
> Linux/Unix folks get involved with the development.

Cool.  I'll alpha test it to make sure it compiles OK on FreeBSD or
possibly OpenBSD if I decide to switch, because the current source for
XFractint has a few problems with defines and such.  Specifically:


1.  As it stands now, __386BSD__, BIG_ANSI_C, and FPUERR have to be
defined, and the elif changed to else as described in the Makefile, or
else some symbols go AWOL.

2.  FreeBSD complains about the use of malloc.h, saying to instead use
stdlib.h.  Also, sys/dir.h is supposed to be a big no-no.  That's
probably also a problem with defines.

3.  atanl et al.  doesn't work.  In fact, it appears that FreeBSD
doesn't implement any long double math functions. :-(

I'll have to take a look at the new source, but a simple #ifdef
"__FREEBSD__" could quite possibly fix all these problems.

A couple of other general bugs:

4.  Hypercomplex should default to no symmetry.  It only has symmetry
for sure when all parameters equal zero, and possibly if you change only
the real variable.  Otherwise the julia sets don't match the Mandelbrot
set in the lower half of the screen.
5.  Quats and Quat julias, and hypercomplexes and hypercomplex Julias,
in Julibrot mode are identical.


> Paul Lee has offerred to have a look at the documentation. I'll make
> the current help compiler and the *.src files available also.
>
> 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"

- --
I sense a great disturbance in the Source.
Justin A. Kolodziej
[e-mail]
Marquette University is http://www.mu.edu

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

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

Date: Wed, 18 Mar 1998 18:55:16 -0600
From: "Tim Wegner" <[e-mail]>
Subject: Re: (fractdev) Documentation and Help files....

> If you have a particular one that you wish used, then let me know.  It's
> been many months since I've created help documents, but it shouldn't
> take more than an hour to get back into the swing of things.

Ahh, I see the confusion! We're talking about two different things.
You are talking about Windows help. I'm talking about help with
Fractint's own on-line docs.

The help compiler I'm talking about is hc.exe, Fractint's own help
compiler. It is distributed in source form with the fractint
source. I could post a compiled version. The help?.src files are
compiled by hc.exe into fractint.hlp. Fractint can use the separate
fractint.hlp file, but under DOS it works to append fractint.hlp to
the fractint executable. An additional function of hc.exe is to
delete or add docs to fractint.exe. (hc.c compiles under UNIX or
LINUX also, but the appending help to the executable is a DOS-ism.)

Someone like yourself without a C compiler who wants to help edit
docs only needs hc.exe and the help?.src files. As long as you don't
change the hotlinks, you are fine. You can use a text editor to
delete text, add text, massage where online or in-file page breaks
come, etc. Don't worry to much about lines wrapping - the help
reader wraps lines. If you want to create new links, or delete links,
you need a C compiler.

You would need to learn about the various help viewer commands that
you can embed in the *.src files, but this isn't too bad, between the
hc docs and seeing examples.

Are you still interested? What we could use is someone with the right
knowledge of fractals and good writing skill who could improve the
documentation.

Generally we ask developers to edit docs to reflect new features, but
we're too busy these days to edit the older docs. In the past people
took on big rewrites. I'd favor a more delimited effort where a topic
is rewritten.

Someone experienced in designing hypertext links might see ways to
make the jumps more logical.

A related but different subject:

Offline some of us are discussing searchable docs. I'd love
fractint's online docs to be searchable. Fractint's help compiler
and viewer were written by Ethan nagel way before html was
invented. Today it would more sense to use html then invent a new
language, but we'd not want to give up Fractint's context sensitive
help. I know little about html, but I suspect an html file could be
read with an html viewer in fractint in such a way that the viewer
was context sensitive.

I wonder if this is a worthwhile project. Does anyone know of
freeware or public domain html-reading code in C?

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"

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

End of fractdev-digest V1 #5
****************************