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

Internet Message Format | 1999-04-28 | 43KB

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


fractdev-digest        Thursday, April 29 1999        Volume 01 : Number 020




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

Date: Thu, 11 Mar 1999 13:39:07 -0500
From: Robert Hailman <[e-mail]>
Subject: Re: (fractdev) Re the path to 32 bits

Sweet...

I haven't gotten around to upgrading to 5.2, I have had no need for it yet.

At 10:22 AM 11/03/99 -0600, Damien M. Jones wrote:
>Robert,
>
> - My copy of RedHat 4.2 came with an extra Cd, of contributed files, and
> - amonst otherthings was an old version of Xfractint
>
>(laugh) Well, you can tell I don't use RedHat as a desktop OS, can't you?
>:) All the server apps I wanted were on the first CD, so I never got around
>to looking at the second one. (RedHat 5.2 comes with *three* CDs, believe
>it or not.)
>
> - =CFCQ: 166848=20
>
>Da-hurn! What an uncommonly low number.
>
Oops, it's actually 1668484... still pretty low, I've been on since August=
=20
'97. Thanks for pointing that out.

>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"
>
>
Robert H=E4lman=20
=CFCQ: 1668484=20
[e-mail]
- -----
P=EBs, luv =E3nd eksesiv drug =FCs.
"=CF'm st=E3rting a v=F6r f=F6r p=EBs."

=C3=C4=CB=CF=D5=D6=DC=E3=E4=EB=EF=F5=F6=FC=D1=F1

- --------------------------------------------------------------
Thanks for using 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, 28 Apr 1999 14:12:52 -0600
From: Phil McRevis <[e-mail]>
Subject: (fractdev) xfractint 19.61 pl66 fixes

OK, I compiled the 19.61pl66 version of xfractint and found some minor
bugs which I worked around.

I also added support for default visuals that aren't pseudocolor (i.e.
truecolor, directcolor etc.) to xfractint.  One step closer to
rendering in any visual.

Also, I've been looking at xfractint's guts to determine how one could
separate out the O/S & graphics dependencies.  It doesn't look too bad
actually.  More on that later.

Tim, do I send diffs to you?  I tried sending to fractdev, but I guess
it was bounced because the diffs made the message too large.
- --
<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
          <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: Wed, 28 Apr 1999 17:16:26 -0600
From: "Tim Wegner" <[e-mail]>
Subject: Re: (fractdev) xfractint 19.61 pl66 fixes

"Phil" wrote:

> Tim, do I send diffs to you?  I tried sending to fractdev, but I guess
> it was bounced because the diffs made the message too large.

Yes send them to me, but since I administrate the list, I already
have them because your too-large message bounced to me <g!>

I'll look at it right away. Thanks very much. Interest on our end in
Xfractint has increased a lot. Jonathan and I both have Linux.

I'll merge your changes along with some of our own and re-upload
the Xfractint source file.

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, 28 Apr 1999 16:25:13 -0600
From: Phil McRevis <[e-mail]>
Subject: Re: (fractdev) xfractint 19.61 pl66 fixes

In article <[e-mail]>,
    "Tim Wegner" <[e-mail]>  writes:

> Yes send them to me, but since I administrate the list, I already
> have them because your too-large message bounced to me <g!>

OK, inspect that diff carefully.  I think some stuff that was supplied
in the patch ended up in my diff because of my poor attempt at
branching the source in my VCS.  (I'm trying to maintina a "pristine"
branch of blessed code as the trunk with my changes on a concurrent
branch.  Somehow I've got the two mixed up and things aren't working
right for me yet.)

> I'll look at it right away. Thanks very much. Interest on our end in
> Xfractint has increased a lot. Jonathan and I both have Linux.

If you get my diffs in there and it compiled OK for you, I'd really
like to know how well fractint behaves when the default visual is
truecolor or directcolor.  (Or StaticGray, StaticColor, and GrayScale
for that matter.)

I'm finally digging into the entire fractint source base and getting
up to speed in how the routines interact.  The bad news is that there's
a LOT of code and a fairly good amount of programming crumbs have been
left laying around as each coder does battle with the program!  The
good news is that I'm finally starting to see how everything is linked
together in fractint and I feel much more optimistic about the
flat-model port and a move to a GUI environment.
- --
<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: Wed, 28 Apr 1999 16:45:31 -0600
From: Phil McRevis <[e-mail]>
Subject: (fractdev) DOS support via allegro?

I know we've talked about this before, but now I'm digging into the
code and looking to get really specific about stuff.  Taking Tim's
suggestion of using the xfractint code base as a start, the question
becomes "how to provide a DOS driver through that code base?".

In the past, we've talked about fancy GUI toolkits (i.e. gimp toolkit)
and so-on.  But what I'm faced with right now is this question: "What's
the smallest code delta that makes the xfractint code compile and work
under a DOS protected-mode extender environment like djgpp?".  In
other words: first get it right, then get it tight.  Assembly is the
tool you use for getting it "tight" after you've gotten it right.
Fractint currently interacts with the keyboard, mouse and display
through 16-bit assembly routines:

    general.asm
    handles keyboard, audio and mouse support
        keypressed(), getakey(),
        buzzer(), delay(), tone(), snd(), nosnd()
    video.asm
    video display support
        setvideomode(), setvideotext(), getcolor(), putcolor()
        out_line(), drawbox(), home(), movecursor(), keycursor()
        putstring(), setattr(), scrollup(), scrolldown()
        putstr(), loaddac(), spindac(), adapter_init, adapter_detect
        setnullvideo
            setfortext(), setforgraphics(), setclear(), findfont()

Allegro, the gaming library for DJGPP, lists the kinds of monitors it
supports.  I'm not up to speed on all the specifics of these monitors
and so-on.  Can someone out there provide guidance to say "yes,
Allegro covers a suficient portion of the existing fractint users, so
you can provide DOS driver support through allegro" or
"no, fractint provides much more extensive video support with its
assembly, so you should port the assembly"

Thanks in advance.

from the readme.txt in the allegro distribution:

   Supports VGA mode 13h, mode-X (twenty three tweaked VGA resolutions plus
   unchained 640x400 Xtended mode), and SVGA modes with 8, 15, 16, 24, and
   32 bit color depths, taking full advantage of VBE 2.0 linear framebuffers
   and the VBE/AF hardware accelerator API if they are available. Additional
   video hardware support is available from the FreeBE/AF project
   (http://www.talula.demon.co.uk/freebe/).

   Drawing functions including putpixel, getpixel, lines, rectangles, flat
   shaded, gouraud shaded, and texture mapped polygons, circles, floodfill,
   bezier splines, patterned fills, masked, run length encoded, and compiled
   sprites, blitting, bitmap scaling and rotation, translucency/lighting,
   and text output with proportional fonts. Supports clipping, and can draw
   directly to the screen or to memory bitmaps of any size.

   Hardware scrolling, mode-X split screens, and palette manipulation.

    [...]

   Plays background MIDI music and up to 64 simultaneous sound effects, and
   can record sample waveforms and MIDI input. Samples can be looped
   (forwards, backwards, or bidirectionally), and the volume, pan, pitch,
   etc, can be adjusted while they are playing. The MIDI player responds to
   note on, note off, main volume, pan, pitch bend, and program change
   messages, using the General MIDI patch set and drum mappings. Currently
   supports Adlib, SB, SB Pro, SB16, AWE32, MPU-401, ESS AudioDrive, Ensoniq
   Soundscape, and software wavetable MIDI.

   Easy access to the mouse, keyboard, joystick, and high resolution timer
   interrupts, including a vertical retrace interrupt simulator.

    [...]

   Math functions including fixed point arithmetic, lookup table trig, and
   3d vector/matrix manipulation.
- --
<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
          <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: Wed, 28 Apr 1999 16:48:56 -0600
From: Phil McRevis <[e-mail]>
Subject: (fractdev) FCODE

Am I correct in assuming all this FCODE business is to exploit the
code segment for string storage to avoid memory-model ceilings?
- --
<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
          <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: Wed, 28 Apr 1999 22:44:50 -0600
From: "Tim Wegner" <[e-mail]>
Subject: Re: (fractdev) DOS support via allegro?

Rich wrote:

> In the past, we've talked about fancy GUI toolkits (i.e. gimp toolkit)
> and so-on.  But what I'm faced with right now is this question: "What's
> the smallest code delta that makes the xfractint code compile and work
> under a DOS protected-mode extender environment like djgpp?".

1. You have to undo any specifically X code and
2. You have to implement video modes and graphics read write.

Also note that the text writing in Xfractint uses curses. However I
believe there are djgpp versions of curses if we want to go that
route.

While #2 is easily done with SVGA lib, it isn't worth the effort. You
have to solve all over again the problems with DOS video modes we
have long since solved.

I suggest the following. In Xfractint's -disk mode, no screen
graphics is done. In this mode Xfractint doesn't do any X stuff and
is probably close to being portable to djgpp. The one warning is
that Xfractint doesn't use Fractint's diskvideo code which has it's
own cache. I don't know if diskvideo should use the DOS code or
the XFractrint code. Apparently the caching isn't needed in Linux.
In DOS it is essential since some of the passes options cause
writing all over the file, and it is horribly slow. That's the reason for
the cache.

Try building a video-less version first.

Tim


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

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

Date: Wed, 28 Apr 1999 22:44:50 -0600
From: "Tim Wegner" <[e-mail]>
Subject: Re: (fractdev) FCODE

> Am I correct in assuming all this FCODE business is to exploit the
> code segment for string storage to avoid memory-model ceilings?

The FCODE typedef allows data to be placed in overlays. This
means that data does not eat into Fractint's limited supply of near
memory, since in the medium memory model the is a total of 64K
of near memory, and data not explicitly declared far is in the near
data segment.

Since the FCODE data is in an overlay, it can't be changed, and
least not for long. Once that overlay is reloaded, the data reverts to
its permananent value. This is ideal for things like menu prompts.

It is the use of tricks like this that has allowed Fractint to survive so
long and well with a really restrictive memory model.

For Xfractint or any other 32 bit memory model purpose, FCODE is
just a normal type. There are versions of it for char, int, etc.

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, 28 Apr 1999 22:44:50 -0600
From: "Tim Wegner" <[e-mail]>
Subject: Re: (fractdev) xfractint 19.61 pl66 fixes

> OK, inspect that diff carefully.  I think some stuff that was supplied
> in the patch ended up in my diff because of my poor attempt at
> branching the source in my VCS.

I have no way of dealing with the diff you sent except to implement
it by hand (which I could do). It is nearly a context diff, but "nearly"
scores only in horseshoes :-) I need either a true context diff (diff -c
old new > changes.dif) or just sent a zipped version of the
complete changed files. I like emails to be encapsulated in zips;
I'm never sure when my mailer is going to wrap lines and mess
things up.

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, 29 Apr 1999 01:54:21 -0600
From: Phil McRevis <[e-mail]>
Subject: Re: (fractdev) DOS support via allegro?

In article <[e-mail]>,
    "Tim Wegner" <[e-mail]>  writes:

> 1. You have to undo any specifically X code and
> 2. You have to implement video modes and graphics read write.

These are actually one and the same.  As I say, going through the code
has reduced a job of Everest proportions to one of less than Whitney
proportions.  (Mt. Whitney is the highest point in the continental 48
states, its in California.)

> Also note that the text writing in Xfractint uses curses. However I
> believe there are djgpp versions of curses if we want to go that
> route.

Yeah, personally I consider the curses thing a bug.  It should just
open up a separate X window and do X text in that window, or it should
do X text in the graphic window, similar to XaoS' "ugly interface".
And yes, there are oodles of open source curses implementations.  GNU
has one, in fact (ncurses-4.2).

However, replacing the text interface (which currently calls curses
functions) with a function that does X11 text instead of curses
shouldn't be very hard.  Fractint calls only a handful of curses
functions.  Some of the existing text mode support that could be
handled by curses is #ifdef'd out in the patch 66 snapshot.  You still
need an ability to run "text only" when doing disk video, so you'll
still want the curses support, I believe.  Just that you won't be
putting the main menu up with curses unless you're using disk video or
"curses video" if we implement a XaoS-style text-only mode.  (I don't
see why not.)

In this respect, XaoS and fractint actually have that in common: the
number of functions you must change in order to add a new driver is
not that many.  Reading/writing a pixel, switching to "text" mode and
back, reading the keyboard/mouse, getting an 8x8 font bitmap,
positioning the text cursor and drawing characters with text
attributes.  That's about all you need to do.

I've been studying the XaoS source code since they have dealth with
the same problem.  They did what I was thinking fractint should do:
they built a structure with attributes of the driver (data members)
and function pointers to the driver's functions that implement the
interface (member functions).  Fractint just needs the structure that
groups the related information about a driver together along with a
slight adjustment to its control logic.  At that point, every "#ifdef
XFRACT" that is there for reasons of X11 and not unix-vs-dos will
disappear.  Only one "#ifdef XFRACT" will remain which is wrapped
around the X11 initializer in the list of drivers (which is static
at compile time).

When I looked at the places where "unix" code was substituted for
"dos" code, what I found was that some of the "unix" code was really
just X11 code, not specific to unix.  (You can compile X11 clients for
DOS and Win32, X11 is just a protocol built on TCP/IP, so anything
that can talk TCP/IP can talk X11.)  Other times the XFRACT was
isolating some difference between unix and dos.

Tim, I think we talked earlier about autoconf; I've successfully
switched over one open-source program to autoconf and I think I've got
a handle on it.  We could do xfractint over to autoconf, but I'd
definately need to consult with some other fractint code gurus to
understand how the different #define's interact.  There's no reason
why a good configure script couldn't enable/disable long double
support when a long double is distinct from a double.  This isn't so
much an x86 vs. other CPU argument either, xmission's sparc solaris
reports sizeof(long double) as 16 and sizeof(double) as 8.

However, autoconf is a bit ahead of my current position on things, but
with a little more practice on autoconf for my other projects, that
will carry over to xfractint.  And also I believe that autoconf is
getting improved DOS support to support building code on DOS as well
as unix portably.  The makefile templates now include the ability to
specify an alternate to the usual unix executable, object and library
filename extensions (i.e. use 'exe', 'obj', 'lib' instead of '', '.o',
'.a').

> While #2 is easily done with SVGA lib, it isn't worth the effort. You
> have to solve all over again the problems with DOS video modes we
> have long since solved.

Right, but I have to get something up on the screen.  Yes, I could
start with a "videoless" fractint.  But here's what I'm seeing now
that I look into the code: changing the X-specific code once to
support a "videoless" fractint is epsilon easier than changing the
X-specific code to support a driver harness.  With the driver harness
I'm thinking of, disk "video" is always present regardless of anything
else with the code.

Next is to add a driver instance that encapsulates the existing X11
interface.  This is like a 15 minute job, once the harness is in
place.  Next is what's needed for some minimal DOS display support,
which is nothing harder than a handful of functions now that I'm
seeing it more clearly.

> I suggest the following. In Xfractint's -disk mode, no screen
> graphics is done. In this mode Xfractint doesn't do any X stuff and
> is probably close to being portable to djgpp.

Actually where I'm starting is to get a working harness + X11 driver
instance going on the X side and then take it over to a disk video
only version with djgpp.

> own cache. I don't know if diskvideo should use the DOS code or
> the XFractrint code.

The disk video caching is an O/S issue, not a graphics issue.  There
are a few little things that need to be factored out because of O/S
platform differences, not because of differences in the graphics
environment.  Memory management, timers, date and time manipulation,
file system I/O are some examples, there are probaly some more.  These
also need to be factored out into an "OS" module, with the configure
(manual or otherwise) picking one of them to compile.

> Apparently the caching isn't needed in Linux.

In linux, you have the virtual memory system of the O/S to deal with
it, so you don't need to write it yourself.  You can just mmap() the
file and use it like a char *.

> In DOS it is essential since some of the passes options cause
> writing all over the file, and it is horribly slow. That's the reason for
> the cache.

The code could still be retained.  You'd just be managing the cache in
a flat memory model rather than in a segmented straightjacket.
- --
<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: Thu, 29 Apr 1999 01:55:29 -0600
From: Phil McRevis <[e-mail]>
Subject: Re: (fractdev) FCODE

Err... I'll take that as a yes. :)
- --
<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: Thu, 29 Apr 1999 02:00:25 -0600
From: Phil McRevis <[e-mail]>
Subject: Re: (fractdev) xfractint 19.61 pl66 fixes

In article <[e-mail]>,
    "Tim Wegner" <[e-mail]>  writes:

> I have no way of dealing with the diff you sent except to implement
> it by hand (which I could do).

Really?  Did your patch utility give you an error or what?  If you're
using an old version of patch that doesn't ignore leading/trailing
garbage outside of a context diff, you should get a newer version.
GNU patch doesn't suffer from any such deficiencies.

> I need either a true context diff (diff -c
> old new > changes.dif) or just sent a zipped version of the

What problem exactly are you having?  The problem with zipping up
source code is the end-of-line convention gets stored binary in the
file and you end up having to constantly convert back and forth
between unix and DOS line conventions.

We could setup a CVS server here on xmission and people could just
update/checkin/checkout to that directly without you having to process
the diffs manually.  Just a thought.
- --
<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: Thu, 29 Apr 1999 16:41:31 -0600
From: Phil McRevis <[e-mail]>
Subject: (fractdev) portability thoughts

Lets separate graphic driver (anything to do with mouse/display) issues
from operating system issues.  Here are the operating system issues as
I see them at my current level of understanding of the source:

    file system I/O
    max. filename path len
    path element separator
    directory reading/scanning

The path separator thing becomes painful under unix.  Fractint uses
'/' to separate the parameter name from a parameter file, for
isntance.  It happens to look for a '/', and if it sees one, it
assumes that the argument is ``@parfile/entry'', but if one naively
specified a full-path of a parfile under xfractint, you'd have a '/'
as part of the parfile name and xfractint will become confused.  A
workaround is to always have parfiles specified in this manner in the
current directory.  Either fractint's syntax will have to be adjusted
slightly, or some quoting mechanism must be installed to allow a full
pathname for a unix file to be specified in these instances.

The filename length is rather standard; stdio.h defines FILENAME_MAX.

The directory scanning/reading issue is one of differences between
unices.  Some use readdir that returns a DIRENT, some return a DIR.
Autoconf has all the ability to isolate the differences and provide a
snippet of code that always works.

    memory allocation
    memory "models"
    virtual memory: mmap vs. home-brew file I/O cache

Memory models disappear completely when dealing with a DPMI extender
port.

Fractint has elaborate strategies for coping with limited amounts of
memory for various situations.  Would a flat-model port eliminate the
need for this parsimony?  Do the DPMI's provide virtual memory?  If
so, then I'd suggest ditching the parsimonious behavior in favor of
the VM from the DPMI.  If the flat-model only eliminates near/far/huge
business but still leaves the need for being parsimonious, then the
disk caching logic and so-on should remain.

    time and date / timers

Fractint uses the PC's timer -- I believe it only uses it in a
stopwatch manner, not to control I/O polling.  (Keyboard polling is
controlled by an internal counter which is adjusted by various
computation routines.  When the counter reaches zero, the keyboard is
checked for input.)  Providing an interface to a system stopwatch is
relatively straightforward.  This would be needed even under a Win32
port since fractint's idea of accessing the timer relies on a DOS
model, which accesses the timer directly (or does it use BIOS?).

    signals

There are differences between unices.  Some signal handlers return
void, some return int.  Autoconf can handle this.

    compilation issues / portability / assembler
    autoconf
        probably lots of include files to sort out.
        driver options
        autodiscover drivers?
        libraries: math library, gmp?
        building help compiler to build help file
        building help file with help compiler
        data files: frmfiles, ifsfiles, lfiles, mapfiles, parfiles
        wipe out default .l.o rule;
        .l files here aren't lex files, they're lsys files
        documentation rule: fractint.doc

The stuff under autoconf -- if you're not familiar with autoconf, see
bwlo(*) -- is a list of things that need to be done to use autoconf
for fractint.

    trig constants
        why use homebrew PI, etc.?  use M_PI, M_PI_2, etc. instead

I'm not sure why fractint defines its own value for PI.  Maybe because
when fractint was first compiled, there weren't any good math.h's for
the PC?  At any rate, I think M_PI and friends from math.h should be
preferred unless there is a significant reason not to.  Again, autconf
can detect the absence of a defined M_PI and define one for that case.

    void * != int

Lots of places in the code there are implicit assumptions about
sizeof(int) == sizeof(void *).  This isn't good for portability in
general, and in the L-system code I think it actually causes a crash
in xfractint that shouldn't be there.

    data type support: int, long, long long, float, double, long double

Autoconf can detect the sizes of all these data types and distinguish
which ones embody more precision.  Conditional compilation of long
double support could be added through the code as a function of the
compiler rather than a "DOS/XFRACT" switch as is currently done.

    arbitrary precision arithmetic
    gmp only provides integers, rationals, fixed.  Doesn't provide
    trig functions.  Contribute complex, trig implementations back
    to FSF.

The arbitrary precision arithmetic routines used by fractint aren't
portable to non-x86 platforms.  However, the gmp (GNU multiple
precision) library *is* portable to a large number of platforms -- it
has assembly for the inner loops for a variety of CPUs:  a29k, alpha,
arm, clipper, cray, hppa, i960, m68k, m88k, mips2, mips3, ns32k,
powerpc32, powerpc64, pyr, sh, sparc32, sparc64, vax, x86 (includes
pentium support), z8000, and z8000x.  I think fractint should adopt
gmp, but this will mean a fair bit of work.

gmp provides arbitrary precision integer, rational and floating point
representations.  It does not provide a complex representation
(although making one is straightforward), nor does it provide
trigonometric functions for any of the data types.  Fractint's bignum
implementation provides both of these.  If it were up to me, I'd take
the complex and trig support impemented in fractint, port that onto
the gmp library and contribute it back as GPL'ed source to the gmp
maintainers.  Then I'd move fractint to using gmp completely.

Given the other items on the portability menu, I'd rank this as a
rather low-priority item.  (On the other hand, if you deseperately
want xfractint calculating arbitrary precision M-sets on a cray, you
might prioritize it higher. :-)

(*) ==== About autoconf

There are lots of minor nagging differences between unix
implementations.  This was what vendors did to "add value" during the
pre-POSIX days.  Now people realize that consistency of an interface is
more valuable than any value "added" by deviating in a non-portable
manner.  At any rate, we're now stuck with how to resolve all these
niggling little differences between unix boxes.  Autoconf was invented
to solve this problem as open source software evolved and was ported to
more and more platforms.

Rather than try and identify the feature sets provided by all possible
OS and hardware combinations ahead of time, autoconf builds a
configuration script based on knowledge of the source code's
requirements.  The configure script knows what the source code needs
(or what alternatives the source code implements) and probes the
system at compile time to see if the system provides facilities
sufficient for the compilation of the package.  It identifies
alternatives available in the system and marks them in a configuration
header file.  The header file is included by the source code to select
between alternatives or conditionally compile snippets of code based
on the configuration.

Mechanically, it works like this:

    configure.in is a file you edit that specifies your software's
    feature requirements (include files, typedefs, functions,
    libraries, etc.)

    Makefile.in, config.h.in, etc.
    Remaining *.in files are templates containing autoconf
    variables.  When the source code is configured, the configure
    script will process the template files and expand the autoconf
    macros to the appropriate values for the system.

    autoconf generates a configure script from configure.in, since
    a configure script is a big hairy /bin/sh script that is too
    cumbersome to write by hand.  Configure.in serves as a
    template that is macro expanded through m4 to obtain
    configure.

    configure is run on the target system, identifying available
    features for the software. *.in template files are processed
    and autoconf variables are substituted by their appropriate
    values in the templates.  This step usually creates your
    Makefile and config.h

    now you're ready to run make and install the target.

The end user (the person compiling your source distribution) isn't
required to have "autoconf" installed unless they want to change the
source code's configuration process.  One generally distributes source
after you've run autoconf so that a configure script comes with the
source code.  An end-user obtains the source, runs configure, types
"make" and then "make install" to install the software.  No more
editing of include files and/or Makefiles to configure your package!

There is an additional GNU tool called "automake" that simplifies the
details of writing a makefile compliant with the GNU coding standards.
(This provides standard targets for actions like "install",
"uninstall", conventions for locations of binary files, installed
header files, installed libraries, and so-on.) Automake works in
conjuction with autoconf, but autoconf doesn't require automake.

- --------------------------------------------------------------
Thanks for using 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, 29 Apr 1999 17:00:17 -0600
From: Phil McRevis <[e-mail]>
Subject: (fractdev) C++ templates and generic programming and fractint! :)

Just an observation... fractint already embodies the concept of
"generic programming with template classes" as closely as C can deal
with it.

Think about it... fractint has different code blocks implementing the
mathematics of long (integer), double, long double, bignum and bigfloat
number representations.  Fractint evolved in C what one would do in
C++ with a template class: provide different implementations of the
same set of operations for different underlying representations.o

As I'm scanning through the fractint source code, I'm looking at
things that go like this alot:

    if (integer math)
    do some setup calculation using an integer representation
    else if (floating point math)
    do some setup calculation using a double representation
#ifndef XFRACT
    else if (extended precision fp math)
    do some setup calculation using a long double representation
#endif
    else if (bignum math)
    do some setup calculation using a bignum representation
    else if (bigfloat math)
    do some setup calculation using a bigfloat representation

Variables also exist in multiple representations like the complex-plane
coordinates identifying the current zoom box.  What fractint is really
doing is using an arbitrary precision datatype that adapts its
computation based on the amount of precision required.  Based on the
zoom box, fractint decides how many decimals of precision it needs and
swaps the representation as needed while zooming if the pixel's inner
loop can handle it.

If at some point fractint evolves into using C++, I think this would be
the strongest argument for such a move.  The template classes of C++
allow for a much cleaner representation of this idea.  It would also be
much less error-prone when making modifications to the code.  Consider
the setup calculation example above.  With a template implementation,
we would have a single expression for the setup calculation.  If this
calculation needed to change, only one expression would need to be
edited and tested.  With the existing method, all the expressions have
to be edited and tested separately.

Adding a new fractal type would imply that the formula would be
implemented for *all* supported representations with a single template
function.  (This is the power of generic programming using templates.)
Each new fractal type would get arbitrary precision arithmetic "for
free".

- --
<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
          <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: Thu, 29 Apr 1999 18:01:30 -0500
From: "Damien M. Jones" <[e-mail]>
Subject: Re: (fractdev) C++ templates and generic programming and fractint! :)

Rich,

 - If at some point fractint evolves into using C++, I think this would
 - be the strongest argument for such a move.  The template classes of
 - C++ allow for a much cleaner representation of this idea.

(laughing) I seem to recall this topic being brought up some time ago. I'm
glad to see it raised again. It's also the model I used for JuliaSaver,
which implements a base class with all the guessing logic and a good chunk
of the setup code, and the individual fractal type classes just override
the actual iteration routines and any other setup routines they need to
modify. (In case there was any question about the efficiency of C++.)

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: Thu, 29 Apr 1999 17:17:00 -0600
From: Phil McRevis <[e-mail]>
Subject: Re: (fractdev) C++ templates and generic programming and fractint! :)

In article <[e-mail]>,
    "Damien M. Jones" <[e-mail]>  writes:
> (laughing) I seem to recall this topic being brought up some time ago.

I must have missed that, or perhaps it appeared on another list.  I
rank contributions to fractdev of higher importance than the other
fractal lists :-).

But its nice to see someone's reading all this stuff I've been sending
out.  Sometimes its nice to hear back an "echo". :-)

> I'm
> glad to see it raised again. It's also the model I used for JuliaSaver,
> which implements a base class with all the guessing logic and a good chunk
> of the setup code, and the individual fractal type classes just override
> the actual iteration routines and any other setup routines they need to
> modify. (In case there was any question about the efficiency of C++.)

Ah, but here you're using the inheritence/OOness of C++ to exploit
reuse.  The generic programming/template model, as embodied by the STL
for example, is really quite a different kind of reuse than that
provided by class hierarchies.  If anyone out there reading this
hasn't read Stroustrop's "C++ Programming Language", 3rd ed., section
on the STL, go out and get it and read it!  After you've read it the
first time and thought about it for a few months, go back and read it
again!

Despite all the different programming languages and circumstances in
which I've exercised my skill, the concepts embodied by the STL really
changed the way I looked at certain programming problems.  STL is
written in C++, but it isn't "object oriented".  There is a minor use
of class inheritance to exhibit some reuse, but this is rare and only
in places where it makes sense for the problem.  STL has some aspects
of "functional" programming languages, especially adaptors, binders,
unary_function, binary_function, and so-on.

The model of the STL is powerful, richly expressive, composable and
adaptable all while being efficient!  Provided of course you have a
decent STL implementation, but the open source SGI implementation is
pretty good at this point if you happen to be stuck with a sucky STL.
You will need a good template-aware C++ compiler or you'll be hosed.

Somewhere buzzing around my brain is the zygotal code of a
template-based library that exploits generic programming techniques to
deal with the explosion of concrete types (bitmap, grayscale,
luminance + alpha, rgb, rgb15, rgb16, rgb24, rgba, abgr, bgr,
rrr....bbb...ggg..., etc., images) in imaging and graphics.
- --
<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 #20
*****************************