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

Internet Message Format | 1998-12-04 | 41KB

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


fractdev-digest        Friday, December 4 1998        Volume 01 : Number 015




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

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

On Thu, 3 Dec 1998, Phil McRevis wrote:

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

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

    OK, my peebles:

    new fractal types:

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

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

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

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

    The patches will be with tim by the weekend.

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

    []'s

    Humberto R. Baptista
    [e-mail]

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


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

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

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

On Thu, 3 Dec 1998, Phil McRevis wrote:

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

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

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

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

    []'s

    Humberto R. Baptista
    [e-mail]

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


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

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

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

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

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

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

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

    Have you discussed along this lines? Any ideas?

    []'s

    Humberto R. Baptista
    [e-mail]

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


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

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

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

On Thu, 3 Dec 1998, Tim Wegner wrote:

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

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

    []'s

    Humberto R. Baptista
    [e-mail]

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


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

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

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

On Fri, 4 Dec 1998, Ron Barnett wrote:

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

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

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

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

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

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

    []'s

    Humberto R. Baptista
    [e-mail]

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


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

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

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

Tim,

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

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

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

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

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

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

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

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

Date: Fri, 04 Dec 1998 10:12:09 -0600
From: "Damien M. Jones" <[e-mail]>
Subject: Re: (fractdev) Parallel Processing

Humberto,

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

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

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

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

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

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

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

Date: Fri, 4 Dec 1998 17:54 0000
From: [e-mail]
Subject: (fractdev) RE: Evolver

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

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

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

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

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

Cheers,
        Robin.








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

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

Date: Fri, 4 Dec 1998 18:07 0000
From: [e-mail]
Subject: RE: RE: (fractdev) project list

Hi Ron,

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

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


Cheers,
         Robin.





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

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

Date: Fri, 4 Dec 1998 18:30 0000
From: [e-mail]
Subject: RE: RE: (fractdev) project list

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

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

Robin.




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

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

Date: Fri, 4 Dec 1998 18:24 0000
From: [e-mail]
Subject: RE: Re: (fractdev) Synchronous Orbits

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

Hi Humberto,

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

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

Cheers,
         Robin.




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

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

Date: Fri, 04 Dec 1998 14:09:54 -0700
From: Phil McRevis <[e-mail]>
Subject: Re: (fractdev) Re: source code

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

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

CVS/RCS - What is it?

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

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

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

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

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

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

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

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

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

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

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

Humberto asked:

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

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

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

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

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

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

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

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

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

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

Tim



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

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

Date: Fri, 4 Dec 1998 19:25:46 -0600
From: "Tim Wegner" <[e-mail]>
Subject: Re: (fractdev) Worklist and future directions

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

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

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

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

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

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

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

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

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

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

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

>     - Overlays (is it hard??)

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

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

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

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

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

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

Tim



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

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

Date: Fri, 4 Dec 1998 19:25:45 -0600
From: "Tim Wegner" <[e-mail]>
Subject: Re: (fractdev) C++ builder

Rich wrote:

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

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

Tim


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

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

Date: Fri, 4 Dec 1998 19:25:45 -0600
From: "Tim Wegner" <[e-mail]>
Subject: (fractdev) Parallel processing (was Synchronous Orbits)

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

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

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

Tim


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

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

Date: Thu, 3 Dec 1998 19:41:17 +0100
From: "Dean-Christian Strik" <[e-mail]>
Subject: Re: (fractdev) Welcome Humberto

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

- --

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

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

- -----Original Message-----
From: Tim Wegner <[e-mail]>
To: [e-mail] <[e-mail]>
Date: donderdag 3 december 1998 07 31 Fluxen
Subject: Re: (fractdev) Welcome Humberto


Humberto asked:

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

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

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

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

Tim




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




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

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

Date: Thu, 3 Dec 1998 19:35:40 +0100
From: "Dean-Christian Strik" <[e-mail]>
Subject: Re: (fractdev) Welcome Humberto

Tim W. wrote:

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

Seems more like an internet overload ;-)

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

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

- --

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

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





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

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

Date: Thu, 3 Dec 1998 19:27:54 +0100
From: "Dean-Christian Strik" <[e-mail]>
Subject: Re: (fractdev) Worklist and future directions

Hi,

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


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

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

I hope I'm parsing this right...

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

- --

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

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





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

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

Date: Thu, 3 Dec 1998 19:28:38 +0100
From: "Dean-Christian Strik" <[e-mail]>
Subject: Re: (fractdev) Worklist and future directions

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

- --

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

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

- -----Original Message-----
From: Kragen <[e-mail]>
To: [e-mail] <[e-mail]>
Date: woensdag 2 december 1998 22 59 Fluxen
Subject: Re: (fractdev) Worklist and future directions


>On Wed, 2 Dec 1998, Humberto Rossetti Baptista wrote:
>> Other thing that I have been thinking for some time now. Should we think
>> of a 32 bit version of fractint?
>
>xfractint is 32-bit on 32-bit machines, and 64-bit on 64-bit machines.
>
>--
><[e-mail]>       Kragen Sitaker     <http://www.pobox.com/~kragen/>
>It frightens the daylights out of me whenever I hear people proclaim that
>the less knowledge our children have access to, the better.
>-- Duane Lindstrom, at <URL:http://www.examiner.com/skink/skinkmail.html>
>
>
>--------------------------------------------------------------
>Thanks for using Fractdev, The Fractint Developer's Discussion List
>Post Message:   [e-mail]
>Get Commands:   [e-mail] "help"
>Administrator:  [e-mail]
>Unsubscribe:    [e-mail] "unsubscribe fractdev"




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

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

Date: Fri, 04 Dec 1998 20:46:52 -0700
From: Phil McRevis <[e-mail]>
Subject: Re: (fractdev) Parallel processing (was Synchronous Orbits)

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

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

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

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

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

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