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

Internet Message Format | 1999-02-21 | 42KB

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


fractdev-digest       Monday, February 22 1999       Volume 01 : Number 017




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

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

Humberto asked:

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

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

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

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

Tim


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

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

Date: Wed, 9 Dec 1998 16:54:39 -0200 (EDT)
From: Humberto Rossetti Baptista <[e-mail]>
Subject: (fractdev) SVGALib and BC compiling.

On Tue, 8 Dec 1998, Tim Wegner wrote:

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

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

    About bugs in BC compiling:

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

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

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

    []'s

    Humberto R. Baptista
    [e-mail]

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



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

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

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

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


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


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


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


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


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


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





<nofill>

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

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

Date: Sat, 12 Dec 1998 13:37:07 -0700
From: Phil McRevis <[e-mail]>
Subject: Re: (fractdev) function variable presets

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

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

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

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

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

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

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

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

Date: Sun, 13 Dec 1998 22:23:23 -0200 (EDT)
From: Humberto Rossetti Baptista <[e-mail]>
Subject: Re: (fractdev) function variable presets

On Sat, 12 Dec 1998, Tim Wegner wrote:

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

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

    []'s

    Humberto R. Baptista
    [e-mail]

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


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

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

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

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

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

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

Tim

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



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

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

Date: Mon, 14 Dec 1998 01:05:57 -0200 (EDT)
From: Humberto Rossetti Baptista <[e-mail]>
Subject: Re: (fractdev) function variable presets

On Sun, 13 Dec 1998, Tim Wegner wrote:

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

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

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

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

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

    []'s

    Humberto R. Baptista
    [e-mail]

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


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

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

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

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

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

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

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

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

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

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

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


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

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

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

Here are the actual pars:

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

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

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

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

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

Ron Barnett

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

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

Date: Sun, 21 Feb 1999 22:00:14 -0700
From: Phil McRevis <[e-mail]>
Subject: (fractdev) flat-memory model port

OK, this last round of discussion about fractint and the limits of the
medium memory model has jostled me out of my sloth :-).

I am willing to make a pass through fractint's code to remove all the
overlay and "far ptr"isms of the medium memory model.  I have Borland
C++ Builder (which can compile regular C code just fine from the
command line), and I'm willing to download gcc/djgpp to make sure I'm
using any Borlandisms in the effort.

What I would like from Tim and other developers here is what exactly
do I need to do in order to do the port?

Here is what I had in mind:

    o remove all "near/far" isms with respect to pointers and data --
    as I understand it the "far" isn't needed in a flat memory model,
    because a pointer is a pointer is a pointer.

    o remove all overlay mechanisms -- these are just #pragmas in the
    source code, aren't they?

    o use C code from xfractint for the assembler portions -- in other
    words, I'm not attempting to rewrite the assembler code.  That may
    come later, but the primary thrust is to get to a flat memory
    model.

    o try to group data with its associated functions instead of
    having it lurking as a global.  Its my understanding that the
    reason there is so much of this in the fractint source is because
    of the memory model.

Now given that I'm going to remove the assembly and use C instead,
that leaves me with one hole: video I/O.  My inclination is to use the
same solution that XaoS uses -- dgjpp/Allegro.  See
<http://www.talula.demon.co.uk/allegro/readme.html> for information on
Allegro.  What's interesting about that (and I only just learned this
upon reading that URL :-) is that Allegro supports DOS, Win32 via
DirectX and the X Window System.  Rather than homebrewing our own GUI
layer, perhaps we could just write to Allegro and be done with it?  Of
course, that still leaves the Mac in the lurch, but perhaps someone is
already working on an Allegro port for the Mac.

Please respond soon, before I lose my nerve to tackle this project :)
- --
<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: Sun, 21 Feb 1999 22:05:13 -0700
From: Phil McRevis <[e-mail]>
Subject: Re: (fractdev) flat-memory model port

In article <[e-mail]>,
    Phil McRevis <[e-mail]>  writes:
> [...] I'm willing to download gcc/djgpp to make sure I'm
> using any Borlandisms in the effort.

That should be "make sure I'm *not* using any Borlandisms"... silly me
:)
- --
<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: Mon, 22 Feb 1999 00:19:23 -0500 (EST)
From: [e-mail] (Kragen Sitaker)
Subject: Re: (fractdev) flat-memory model port

On Sun, 21 Feb 1999, Phil McRevis wrote:
> Here is what I had in mind:
>
>     o remove all "near/far" isms with respect to pointers and data --
>     as I understand it the "far" isn't needed in a flat memory model,
>     because a pointer is a pointer is a pointer.

You could perhaps do this with #define.
#define near
#define far

>     o remove all overlay mechanisms -- these are just #pragmas in the
>     source code, aren't they?

If so, you don't need to remove them.

> Now given that I'm going to remove the assembly and use C instead,
> that leaves me with one hole: video I/O.  My inclination is to use the
> same solution that XaoS uses -- dgjpp/Allegro.  See
> <http://www.talula.demon.co.uk/allegro/readme.html> for information on
> Allegro.  What's interesting about that (and I only just learned this
> upon reading that URL :-) is that Allegro supports DOS, Win32 via
> DirectX and the X Window System.  Rather than homebrewing our own GUI
> layer, perhaps we could just write to Allegro and be done with it?  Of
> course, that still leaves the Mac in the lurch, but perhaps someone is
> already working on an Allegro port for the Mac.

I don't think you can use Allegro with C++Builder, but I do not know.

I think there are some licensing restrictions having to do with
building with djgpp; in particular, I think the C run-time library is
GPLed.  This is incompatible with Fractint's license, which prohibits
redistribution for profit.

I hope you can preserve the original DOS interface to some degree.
It's wonderful in DOS, but terribly painful in xfractint.  (I think
I've never used any program with as good a UI as DOS Fractint.)

> Please respond soon, before I lose my nerve to tackle this project :)

Thank you for your nerve :)

- --
<[e-mail]>       Kragen Sitaker     <http://www.pobox.com/~kragen/>
Computers are the tools of the devil. It is as simple as that. There is no
monotheism strong enough that it cannot be shaken by Unix or any Microsoft
product. The devil is real. He lives inside C programs. -- [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: Sun, 21 Feb 1999 22:50:31 -0700
From: Phil McRevis <[e-mail]>
Subject: Re: (fractdev) flat-memory model port

In article <[e-mail]>,
    [e-mail] (Kragen Sitaker)  writes:
> You could perhaps do this with #define.
> #define near
> #define far

Yes, the xfractint .h file already does this.  However, with emacs and
grep, its quite simple to remove all "far" and "near" qualifiers on
pointers.  (M-x grep, followed by M-x next-error is a wonderful thing
for large source base modifications.)  If we are giving up the medium
memory model, these qualifiers are just cruft that should be removed.

> If so, you don't need to remove them.

See above.  When stuff isn't used anymore, its best to remove it
rather than leave it laying around.  For instance, do you delete
unused code from your projects or do you just comment it out?  With
the latter approach, you end up with all this code that isn't relevant
anymore, but a new programmer can't tell that and will wonder why it
is commented out instead of deleted.  On a shared-body project like
fractint, this is even more important since you have no idea who
commented out the code and/or why its commented out.  I've worked on
commercial code where people developed this habit of #ifdef/commenting
out unused code and it quickly led to a maintenance nightmare.
Maintenance issues are even more critical for open-source software.

> I don't think you can use Allegro with C++Builder, but I do not know.

Me neither.  I just brought it up as a possbility for the video I/O.
Fractint needs _some_ kind of abstraction to remove itself from
platform dependencies with graphics I/O.  Rather than reinvent the
wheel, I figure we could use something like Allegro which handles
those details.  Especially since I don't have any desire to port the
assembly code.  (Although since I upgraded my C++Builder I now have
TASM so I can do assembly code.)

> I think there are some licensing restrictions having to do with
> building with djgpp; in particular, I think the C run-time library is
> GPLed.  This is incompatible with Fractint's license, which prohibits
> redistribution for profit.

Hmm... as I understand it, the GPL only says that you have to provide
the source code, which is completely compatible with fractint's
open-source model.

> I hope you can preserve the original DOS interface to some degree.

No changes to the interface are planned; with my C++Builder upgrade, I
did get a coupon to obtain Borland's 4.02 C++ compiler, which can
build 16bit applications.  I may just start seeing if I can build DOS
fractint with that, but then I'd have to obtain that compiler first (I
haven't used the coupon yet), which would mean waiting.
Alternatively, I can eliminate all the medium memory model stuff and
just use xfractint.

> It's wonderful in DOS, but terribly painful in xfractint.

Yes, well that is one reason why we have been saying fractint needs a
UI layer.  Under X, fractint's UI should be native (as well for the
Mac, Win32, BeOS, etc.).  But, first things first.  Every time we have
this discussion we come around to the conclusion "yes, but we need to
remove the memory model limitations first."

> (I think I've never used any program with as good a UI as DOS Fractint.)

Ahem.  I've used plenty of programs with a better UI than DOS fractint
:-).  Not to say that fractint's UI is poor; just that I find the video
mode switching very annoying and it suffers from the limitation of
trying to fit everything into 24x80 for some of its dialog screens.

Cut & paste into the text boxes is nearly impossible, or if it is
possible it is painful. If you think about it, almost every text screen
in fractint is what they call a "modal dialog" in UI terminology.
Given that fractint's dialogs are all originally implemented in a
text-only world, providing some simple functions to implement them in a
graphically rich environment shouldn't be hard.  Xfractint tries to do
it with curses, which is OK I guess, but you end up having an xterm
window and the graphics window, both of them trying to control the
application somewhat.  I never really liked it that much.
- --
<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: Mon, 22 Feb 1999 08:20:12 -0500 (EST)
From: [e-mail] (Kragen Sitaker)
Subject: Re: (fractdev) flat-memory model port

On Sun, 21 Feb 1999, Phil McRevis wrote:
> In article <[e-mail]>,
>     [e-mail] (Kragen Sitaker)  writes:
> > You could perhaps do this with #define.
> > #define near
> > #define far
>
> Yes, the xfractint .h file already does this.  However, with emacs and
> grep, its quite simple to remove all "far" and "near" qualifiers on
> pointers.  (M-x grep, followed by M-x next-error is a wonderful thing
> for large source base modifications.)  If we are giving up the medium
> memory model, these qualifiers are just cruft that should be removed.

I was just thinking that it might be useful to be able to compile
fractint either way.  Perhaps it's too much to ask.

> See above.  When stuff isn't used anymore, its best to remove it
> rather than leave it laying around.

Agreed.

> Maintenance issues are even more critical for open-source software.

Fractint is not open-source software.  Don't go around saying that, or
you'll get sued by the Open Source Initiative.

> > I don't think you can use Allegro with C++Builder, but I do not know.
>
> Me neither.  I just brought it up as a possbility for the video I/O.
> Fractint needs _some_ kind of abstraction to remove itself from
> platform dependencies with graphics I/O.  Rather than reinvent the
> wheel, I figure we could use something like Allegro which handles
> those details.

Fractint has such an abstraction already -- it's just that all the
video drivers are included in Fractint.  For PC video cards, the wheel
has already been reinvented.

> Especially since I don't have any desire to port the
> assembly code.

Heh :)  I don't blame you :)

> Hmm... as I understand it, the GPL only says that you have to provide
> the source code, which is completely compatible with fractint's
> open-source model.

It also says you can't impose any further restrictions, such as "no
commercial distribution".  Many pieces of open-source software (notably
BSD and Mozilla) are not allowed to use GPLed libraries because their
licenses conflict with the GPL.   Also, the Open Source Definition
requires that users be free to do commercial distribution of the
software; software licenses that do not allow this, such as the
Fractint license, are not in compliance with the OSD.  Open Source is a
registered trademark of the OSD, which was founded by the guy who
invented the term last March.

Now, I'm not saying Fractint should change its license; I'm just saying
that presently, it is not open source, and should not be advertised as such.

I *would* like to allow Fractint to be commercially distributed -- I
think a lot more people would use it if it came on the Red Hat CD --
but then again, I didn't write it, so who am I to say?  :)

> > It's wonderful in DOS, but terribly painful in xfractint.
>
> Yes, well that is one reason why we have been saying fractint needs a
> UI layer.  Under X, fractint's UI should be native (as well for the
> Mac, Win32, BeOS, etc.).

Ohhh, OK.  You weren't talking about an abstraction layer for drawing
graphics -- you were talking about an abstraction layer for the
commands, help, and settings parts of the UI.

> Ahem.  I've used plenty of programs with a better UI than DOS fractint
> :-).  Not to say that fractint's UI is poor; just that I find the video
> mode switching very annoying and it suffers from the limitation of
> trying to fit everything into 24x80 for some of its dialog screens.

The video mode switching is a little annoying.

> Cut & paste into the text boxes is nearly impossible, or if it is
> possible it is painful.

In MS-DOS it is simply impossible.  :)

> If you think about it, almost every text screen
> in fractint is what they call a "modal dialog" in UI terminology.

Modal dialogs are a blight on the world of UIs in a GUI context.  But
in a text context, they aren't nearly as bad.

> Given that fractint's dialogs are all originally implemented in a
> text-only world, providing some simple functions to implement them in a
> graphically rich environment shouldn't be hard.  Xfractint tries to do
> it with curses, which is OK I guess, but you end up having an xterm
> window and the graphics window, both of them trying to control the
> application somewhat.  I never really liked it that much.

Neither did I.  (But I like it in MS-DOS.)

What I like is that (a) it was easy for me to use early on -- unlike
the Unix command line -- and (b) it was fast for me to use later --
unlike most GUI programs.  And I could see what was happening most of
the time.

- --
<[e-mail]>       Kragen Sitaker     <http://www.pobox.com/~kragen/>
Computers are the tools of the devil. It is as simple as that. There is no
monotheism strong enough that it cannot be shaken by Unix or any Microsoft
product. The devil is real. He lives inside C programs. -- [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, 22 Feb 1999 09:25:38 -0700
From: Phil McRevis <[e-mail]>
Subject: Re: (fractdev) flat-memory model port

In article <[e-mail]>,
    [e-mail] (Kragen Sitaker)  writes:
> I was just thinking that it might be useful to be able to compile
> fractint either way.  Perhaps it's too much to ask.

If you want 16bit code, then you compile older versions of fractint
:-).

> Fractint is not open-source software.  Don't go around saying that, or
> you'll get sued by the Open Source Initiative.

What?  Of course fractint is open-source software.  What makes you
think otherwise?

> Fractint has such an abstraction already -- it's just that all the
> video drivers are included in Fractint.  For PC video cards, the wheel
> has already been reinvented.

Right, and those video drivers are coded in assembly.

> > Hmm... as I understand it, the GPL only says that you have to provide
> > the source code, which is completely compatible with fractint's
> > open-source model.
>
> It also says you can't impose any further restrictions, such as "no
> commercial distribution".  [...]

Well I'll let Tim call the shot on that one... Tim?

> Ohhh, OK.  You weren't talking about an abstraction layer for drawing
> graphics -- you were talking about an abstraction layer for the
> commands, help, and settings parts of the UI.

Well there are two issues here.  Handling the low-level graphics
(which is currently done in assembly), and the UI portability (which
currently is kludged :).  The low-level graphics can remain in
assembly for the purposes of a flat-memory model port, but then the
assembly will have to be ported.  Since I'd rather not do any assembly
work, I was hoping to plug something else in there.  I think the
assembly video drivers were coded in order to get the maximum speed
from the video card.  Nowadays, these low-level details are best left
to the OS if possible (i.e. DirectX), but that is a very long-term
wish for fractint.  The question is what to do *now* with respect to
the 16bit assembly code that does video I/O.

> Modal dialogs are a blight on the world of UIs in a GUI context.  But
> in a text context, they aren't nearly as bad.

Well, like any tool sometimes its misused.  I've seen every UI
component misused at one time or another.  When a GUI application
*must* have more information from the user in order to continue a
requested operation, just what do you propose it should do?  That's
the situation modal dialogs were invented for.
- --
<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: Mon, 22 Feb 1999 13:29:40 -0500 (EST)
From: [e-mail] (Kragen Sitaker)
Subject: Re: (fractdev) flat-memory model port

On Mon, 22 Feb 1999, Phil McRevis wrote:
> In article <[e-mail]>,
>     [e-mail] (Kragen Sitaker)  writes:
> > Fractint is not open-source software.  Don't go around saying that, or
> > you'll get sued by the Open Source Initiative.
>
> What?  Of course fractint is open-source software.  What makes you
> think otherwise?

I answered that down below; I assume you asked the above question
before you read that part of my reply.  Let me know if I was unclear.

- --
<[e-mail]>       Kragen Sitaker     <http://www.pobox.com/~kragen/>
Computers are the tools of the devil. It is as simple as that. There is no
monotheism strong enough that it cannot be shaken by Unix or any Microsoft
product. The devil is real. He lives inside C programs. -- [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, 22 Feb 1999 12:50:11 -0600
From: "Damien M. Jones" <[e-mail]>
Subject: Re: (fractdev) flat-memory model port

Kragen,

 - [snippage re: GPL, Open Source (R), BSD, and FractInt]

Thanks for the info. It is food for thought.

 - I *would* like to allow Fractint to be commercially distributed -- I
 - think a lot more people would use it if it came on the Red Hat CD --
 - but then again, I didn't write it, so who am I to say?  :)

Interesting notion.

 - > Cut & paste into the text boxes is nearly impossible, or if it is
 - > possible it is painful.
 -
 - In MS-DOS it is simply impossible.  :)

In a DOS box running inside Windows, though, it isn't; it's just highly
inconvenient.

 - Modal dialogs are a blight on the world of UIs in a GUI context.

I have heard this notion advanced from time to time. While it is true that
many programs use modal dialogs excessively, it is ALSO true that in many
cases, designing the software so that modeless dialogs make sense
contradicts the way users are expecting to use the program. And if you
require users to change their work habits to fit the needs of software,
aren't you missing the point? Software is a tool for people, not the other
way around. When confronted with software that doesn't work as they expect,
users either (a) find other software that works like they want, (b) become
unproductive with the software they have, or (c) go postal and waste the
sysadmins that forced such software on them. :-)

However, in support of your point, it's certainly possible for fractal
software (such as a future FractInt) to be primarily focused on a modeless
approach. One recent GUI-based fractal program makes extensive use of
modeless property dialogs and shows one way in which modality can be
reduced substantially. Prior to its release, I also examined another
fractal program in development which, while oriented towards modeless
dialogs, was inconvenient to use. Simply making dialogs modeless isn't in
and of itself enough.

I'm not sure I would call modal dialogs a "blight". For a lot of users, it
fits with their "one thing at a time" mentality. Just because you and I are
able to multitask more effectively doesn't mean everybody else can. :-)

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"

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

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