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

Internet Message Format | 1999-05-24 | 41KB

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


fractdev-digest         Tuesday, May 25 1999         Volume 01 : Number 024




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

Date: Thu, 13 May 1999 16:40:32 -0600
From: Phil McRevis <[e-mail]>
Subject: Re: (fractdev) Patches 65 through 73

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

> This file has both DOS and UNIX diffs. The UNIX diffs end in X - e.g.
> 1961p73x.dif

There aren't unix versions of all the diffs, how are the unix diffs
supposed to be applied?

Archive:  ../patches_65_through_73.zip
 Length    Date    Time    Name
 ------    ----    ----    ----
  28943  02-09-99  19:01   1961P65.DIF
   4416  02-09-99  19:01   1961P65X.DIF
  14589  03-06-99  13:36   1961P66.DIF
  49292  03-22-99  22:59   1961P67.DIF        <= no unix patch 67
   7259  05-04-99  19:47   GENERAL.OBJ
  17429  04-05-99  19:47   1961P68.DIF
   2707  04-02-99  19:45   1961P68X.DIF
   4947  04-06-99  20:46   1961P69.DIF        <= no unix patch 69
  42684  04-26-99  21:05   1961P70.DIF
   2168  04-26-99  21:06   1961P70X.DIF
   3340  05-02-99  17:16   MUSICV20.PAR
  19730  04-30-99  20:15   1961P71.DIF        <= no unix patch 71
  46618  05-09-99  12:45   1961P72.DIF        <= no unix patch 72
  13784  05-09-99  17:16   1961P73.DIF
   1051  05-09-99  18:49   1961P73X.DIF
 ------                    -------
 258957                    15 files

- --
<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, 13 May 1999 16:44:49 -0600
From: Phil McRevis <[e-mail]>
Subject: Re: (fractdev) evolution of fractint source code as a package

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

> I know little about what this entails, but for starters I have no
> objections.

There several things that the GNU folks have as conventions:

1) the GNU project has a coding standard (not that all the GPL'ed code
follows it, but it is recommended practice for the GNU project, not
necessarily all GPL'ed code).  The GNU project is specifically the
unix replacement project, not necessarily any code that is maintained
or provided by FSF.  I think they call it the "GNU Hurd" or something
like that now.

2) makefile contentions.  This is stuff like standard targets for
"clean", "all", "dist" (makes a source code distribution), etc.  If
you use autoconf/automake, you get all this for free.

3) other conventions.  Things like your source code should be stored
in an archive file named package-major.minor.patch, so xfractint would
be distributed as xfractint-19.61.73.tar.gz when you use automake's
default.

Since fractint's code base targets DOS, there are obviously some of
the GNU conventions you can't follow because they assume the
availability of long filenames.
- --
<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, 13 May 1999 19:01:47 -0400 (EDT)
From: [e-mail] (Kragen Sitaker)
Subject: Re: (fractdev) evolution of fractint source code as a package

Rich writes:
> 1) the GNU project has a coding standard

It should probably be discussed among the folks who will be writing
code whether the GNU coding standard is a good coding standard.
Presumably the idea that there should be *some* consistent standard
will not be too controversial, but it might be a good idea to find one
that will entail minimal changes to the currently-existing code.

> (not that all the GPL'ed code
> follows it, but it is recommended practice for the GNU project, not
> necessarily all GPL'ed code).  The GNU project is specifically the
> unix replacement project, not necessarily any code that is maintained
> or provided by FSF.  I think they call it the "GNU Hurd" or something
> like that now.

The Hurd is the kernel -- intended to replace the Linux kernel for
example.  GNU is the whole OS -- the compiler, the C library, X, and
the user programs.

Please don't become offended at this post.

- --
<[e-mail]>       Kragen Sitaker     <http://www.pobox.com/~kragen/>
TurboLinux is outselling NT in Japan's retail software market 10 to 1,
so I hear.
- -- http://www.performancecomputing.com/opinions/unixriot/981218.shtml


- --------------------------------------------------------------
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, 13 May 1999 17:03:17 -0600
From: Phil McRevis <[e-mail]>
Subject: (fractdev) unix patch 70

This patch replaces SignalHandler (which is a portability typedef in
unix.h) with __sighandler_t, which is an implementation dependent
signal.  This symbol isn't even defined on Solaris.  Why was this
change made?  In unix.h, SignalHandler is defined as:

    typedef void (*SignalHandler)(int);

If there is some problem with that prototype for a signal handler on a
unix system (i.e. signal handler returns int, not void), then an
#ifdef should be added in unix.h factoring out this problem, rather
than sprinkling __sighandler_t over unixscr.c.

This is an example of the kinds of differences between unix boxes that
configure can handle.  Unfortunately there isn't "one unix API"; which
is why configure probes the target system to determine what set of
options are provided.
- --
<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, 13 May 1999 17:04:39 -0600
From: Phil McRevis <[e-mail]>
Subject: Re: (fractdev) evolution of fractint source code as a package

In article <[e-mail]>,
    [e-mail] (Kragen Sitaker)  writes:

> but it might be a good idea to find one
> that will entail minimal changes to the currently-existing code.

LOL.  The existing code has a haphazard collection of styles and
practices, none of which are consistent.
- --
<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, 13 May 1999 21:03:48 -0400
From: Jonathan Osuch <[e-mail]>
Subject: Re: (fractdev) unix patch 70

Rich wrote:

>> This patch replaces SignalHandler (which is a portability typedef in
unix.h) with __sighandler_t, which is an implementation dependent
signal.  This symbol isn't even defined on Solaris.  Why was this
change made? <<

Because SignalHandler works fine with what is provided with Slakware Linu=
x,
but is not provided with the version of Red Hat Linux (5.1) that I have. =

This obviously may change in the future.  I do intend to get Red Hat
version 6.0 in the next month.

>> This is an example of the kinds of differences between unix boxes that=

configure can handle. <<

Go for it.

>> There aren't unix versions of all the diffs, how are the unix diffs
supposed to be applied? <<

Both diffs need to be applied to Xfractint.  The diffs with the x contain=

changes that do not apply to the DOS version.

Jonathan

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

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

Date: Fri, 14 May 1999 14:15:47 -0300 (EST)
From: Humberto Rossetti Baptista <[e-mail]>
Subject: (fractdev) Drivers API :-)

    Hi Rich:

    I've checked your driver API :-) and it looked very nice, resembles from
a distance the XaoS one but I guess it's a bit cleaner.

    Let me add what I feel about the API (i'll comment the routine bellow my
coments for those who have not read the driver.h you sent):

    - Hm besides driver_name there should be a driverversion variable or are
you planning to put thisn in the name string?

    - the window, resize and redraw routines recieve no parameters, so I
suppose the set_video_mode function sets the size and attributes of the windows,
but this can be a little messy on multiwindows environments. How are you seeing
this?

    - the read_picel shoudn't return an int, what about a user defined type?
Like pixel (could go from RGB+al, RGB to Byte etc.)

    - the same applies to the put_pixel function (the color argument
shoudn't be int);

    - besides read and write_span (functions that write a row of pixels)
there should be something like write_block and read_blovk to deal with
rectangular areas. And maybe we could come up with something to allow the use of
hw optimizations avaliable on the hw beneath.

    - set_line_mode: why "line" mode? Shoudn't it be "draw" mode?
    (this routine sets whether to copy or t xor the line w/ the bckgrnd)

    - set_video_mode recieves four parameters: ax,bx,cx,dx what do they do?

    - the same obs regarding color on the put_string  routine.

    - what the find_font routine does?

    I have not seen the mouse routines in the API!

    The sound routines do not seem to help in the case of the new
developments in the sound area (i'm not sure which routines should be added).

    Uf. Its a lot of things, but I rather make this in the beguinning of the
process that later on :-)

    []'s

    Humberto R. Baptista
    [e-mail]

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

- -----BEGIN GEEK CODE BLOCK-----
Version: 3.1
GB/C/CA/CM/CS/CC/ED/FA/H/IT/L/M/MU/P/S d?>dpu s:- a->!@ C++++$ USL+++$ P+++@
L+++@ !E W++@ N++(+)@ o+>++++$ K? w>---$ O-@$ M--@ V-- PS@ PE@ Y+>+++$ PGP+@
t+++ 5+@ X+ R>+++$ tv@ b+>++++$ DI++$ D++>++++$ G e+++>++++ h(---)>*$ r+++
y+++*
- ------END GEEK CODE BLOCK------



- --------------------------------------------------------------
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, 14 May 1999 11:35:13 -0600
From: Phil McRevis <[e-mail]>
Subject: Re: (fractdev) unix patch 70

In article <[e-mail]>,
    Jonathan Osuch <[e-mail]>  writes:

> Because SignalHandler works fine with what is provided with Slakware Linux
> but is not provided with the version of Red Hat Linux (5.1) that I have.

Then put an #ifdef in unix.h to redefine the typedef for SignalHandler
instead of changing everything to a redhat specific type.
- --
<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, 14 May 1999 11:45:40 -0600
From: Phil McRevis <[e-mail]>
Subject: Re: (fractdev) Drivers API :-)

In article <[e-mail]>,
    Humberto Rossetti Baptista <[e-mail]>  writes:

>     I've checked your driver API :-) [...]

In all fairness, its not really a designed API.  Its just taking the
existing routines in fractint and forcing them through a level of
indirection.  The indirection is what supports the idea of multiple
drivers coexisting.

> - Hm besides driver_name there should be a driverversion variable or ar
e
> you planning to put thisn in the name string?

A driver can report its version, but since drivers don't change unless
a release of fractint changes, I don't see much point in that.  In
other words, fractint 21.0 will always have whatever drivers were
compiled with fractint 21.0, so there's no need for a driver version
number as I see it.  It could be added, but I'd rather not add extra
confusion to the equation about "driver versions" when in fact all
that matters is the fractint version.

>     - the window, resize and redraw routines recieve no parameters, so I
> suppose the set_video_mode function sets the size and attributes of the windo
ws,
> but this can be a little messy on multiwindows environments. How are you seei
ng
> this?

As I said, its not a designed API, its just taking the existing
fractint code and adding a level of indirection.  Fractint just has a
zillion global variables and many of the functions communicate
information through these global variables.  I am eliminating any
variables that are internal to drivers and encapsulating them inside a
state structure that is created and maintained by the driver.

Eventually most if not all of fractint's globals will have to go a
similar route if we want multithreading, reentrancy and distributed
processing of the SMP variety.

>     - the read_picel shoudn't return an int, what about a user defined type

Read pixel returns an int because to fractint an int is a pixel since
a pixel is only considered an index into a LUT.  Again, this API is
not designed, its just an evolution of fractint's existing code, so
fractint's assumptions (i.e. the world is a LUT-based frame buffer) go
along with it.

> [read_span, write_span, set_line_mode, set_video_mode, etc.]

All your questions are answered by looking at the existing fractint
source.  I'm *not* trying to rewrite fracint from scratch!  The job of
inserting the driver indirection is big enough!  Trying to change too
much at once just gets you into a quicksand of changes.

Regarding the sound routines, its difficult to say what's needed
exactly because the xfractint version of the code didn't have the
necessary routines until the latest round of patches.

Whereas X11 does provide device-independent graphics, it doesn't
provide device-independent sound beyond a few little functions to make
the keyboard beep at different hertz.  Sound has to be programmed
differently on the SGI, on the Sun, on Linux, etc.  Under DirectX, you
have a higher-level interface to sound on the PCs, but otherwise
you're stuck with win32's idea of sound, which isn't all that great, I
gather.
- --
<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, 14 May 1999 15:00:53 -0300 (EST)
From: Humberto Rossetti Baptista <[e-mail]>
Subject: Re: (fractdev) Drivers API :-)

On Fri, 14 May 1999, Phil McRevis wrote:

> In all fairness, its not really a designed API.  Its just taking the
[... explanations about taking the existing routines ...]

    OK, I get it, this was just a suggestion to things to add (eve if non
functional right now). But there is one point that I stll have no seen in this:
the mouse.

    []'s

    Humberto R. Baptista
    [e-mail]

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

- -----BEGIN GEEK CODE BLOCK-----
Version: 3.1
GB/C/CA/CM/CS/CC/ED/FA/H/IT/L/M/MU/P/S d?>dpu s:- a->!@ C++++$ USL+++$ P+++@
L+++@ !E W++@ N++(+)@ o+>++++$ K? w>---$ O-@$ M--@ V-- PS@ PE@ Y+>+++$ PGP+@
t+++ 5+@ X+ R>+++$ tv@ b+>++++$ DI++$ D++>++++$ G e+++>++++ h(---)>*$ r+++
y+++*
- ------END GEEK CODE BLOCK------



- --------------------------------------------------------------
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, 14 May 1999 12:07:48 -0600
From: Phil McRevis <[e-mail]>
Subject: Re: (fractdev) Drivers API :-)

In article <[e-mail]>,
    Humberto Rossetti Baptista <[e-mail]>  writes:

>     OK, I get it, this was just a suggestion to things to add (eve if non
> functional right now). But there is one point that I stll have no seen in thi
s:
> the mouse.

Well it turns out it really is there, you just don't know it. :-)

Fractint's mouse support was added by diddling the keyboard routine!

Why was it done this way?  Because fractint has a polling input model.
All over the code places "check the keyboard" to see if there is any
input waiting.  So the place that checks for mouse code is squirreled
away inside the keyboard routine.  This is also how the X version
manages to read the event queue: its hidden inside the keyboard input
routine.

The next big thing I'd like to do to fractint regarding its overall
structure is to convert the polling I/O to event-oriented I/O, but
that's a benefit for programmers, not users.  I don't think it will be
that hard, but as I say, I'd rather not try to do too many things at
once.
- --
<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, 14 May 1999 17:56:49 -0400
From: Jonathan Osuch <[e-mail]>
Subject: Re: (fractdev) unix patch 70

Rich wrote:

>> Then put an #ifdef in unix.h to redefine the typedef for SignalHandler=

instead of changing everything to a redhat specific type. <<

Of course.  I tried that (not in unix.h, however) and it didn't work when=
 I
went back to the Slackware Linux.  I got a redefinition error.  I'll try =
it
again in unix.h, and see what happens.

Jonathan

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

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

Date: Fri, 14 May 1999 21:43:17 -0600
From: Phil McRevis <[e-mail]>
Subject: Re: (fractdev) unix patch 70

In article <[e-mail]>,
    Jonathan Osuch <[e-mail]>  writes:

> > I tried that (not in unix.h, however) and it didn't work when >  I >
> went back to the Slackware Linux.  I got a redefinition error.  I'll
> try = > it > again in unix.h, and see what happens.

What is the exact problem with the existing prototype of
SignalHandler?  What problem did you originally have that caused you
to change SignalHandler to __sighandler_t?
- --
<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: Sat, 15 May 1999 08:55:37 -0400
From: Jonathan Osuch <[e-mail]>
Subject: Re: (fractdev) unix patch 70

Rich wrote:

>> What is the exact problem with the existing prototype of
SignalHandler?  What problem did you originally have that caused you
to change SignalHandler to __sighandler_t? <<

In Redhat Linux, the SignalHandler prototype doesn't exist in any of the
signal.h files.  I see that we have a define for it in unix.h.  Which isn=
't
used if LINUX is defined.  Defining REDHAT and using a copy of the
SignalHandler prototype works fine.

What concerns me is that the signal.h files with the Redhat Linux are new=
er
than the ones which came with the Slakware Linux.  When Slakware updates
its gcc compiler will it then have the same problem?  I'm guessing, yes.

Jonathan

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

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

Date: Sat, 15 May 1999 18:10:53 -0600
From: Phil McRevis <[e-mail]>
Subject: Re: (fractdev) unix patch 70

So your signal handler prototype is a pointer to function taking int
returning void, correct?

What I'm trying to learn is: what's the prototype for the signal
handler you need, and why isn't the one defined in unix.h working.
- --
<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: Sun, 16 May 1999 17:42:03 -0400
From: Jonathan Osuch <[e-mail]>
Subject: Re: (fractdev) unix patch 70

Rich wrote:

>> What I'm trying to learn is: what's the prototype for the signal
handler you need, and why isn't the one defined in unix.h working. <<

The one in unix.h works fine.  But, notice that it is just after an
"#ifndef LINUX", which is what I'm running on.  I have two Linux systems,=

one that requires the prototype in unix.h and one that doesn't.

As you said earlier, this is an excellent example for why we need to star=
t
using configure.

Jonathan

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

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

Date: Fri, 21 May 1999 01:37:11 -0600
From: Phil McRevis <[e-mail]>
Subject: Re: (fractdev) "todo" and "progress" files updated

Tim, I hope you don't mind me sharing a little bit of your mail to me
with the fractdev list.

In article <[e-mail]>,
    tgilman <[e-mail]>  writes:

> [...] I'll be pointing my head at getting some of the
> flow-control of fractint away from all the menuing to a more
> abstraction-friendly engine.

After having studied the code, I've come to the conclusion that it
shouldn't be too hard to get fractint away from the polling I/O model
and move it to an event-driven model.  There are several main points:

1) computations check for "has a key been pressed?" in order to
prematurely terminate or interrupt some computation.  This can be
replaced by code that checks some termination condition other than
"key pressed".  The check is the easy part; the harder part is
massaging that check into the surrounding control logic.  A little
tedious, but definately doable.

2) handling of keystrokes for menus, parameter screens and so-on.  This
is already abstracted out in fractint (see the fullscreen_choice
routine in realdos.c) so it shouldn't be hard to convert from polling.
The key is to change a control structure that looks like this:

    ...setup calculations...
    while 1
    get a key press
    switch on key
        case ESC
        /* handle ESC */
        case F1
        /* handle help (F1) */
        ...etc...
    ...final calculations...

This is what in Xt parlance one would call an "action table" -- it maps
events to application action procedures.  In fractint, the mapping is
embedded in the switch statement and the surrounding control logic,
and the "action procedures" aren't necessarily C procedures/functions,
they are usually just a block of code in the case statement.  In
order to turn this into an event driven situation, you want to build a
table associating keys with actions to be taken when those keys are
pressed.  The surrounding control logic is converted into a state
machine, so that the setup calculations are done once (not on every key
stroke).  Usually the setup calculations are things like initialization
of variables used in the keystroke handling and writing the menu to the
text screen.

3) handling of the zoom box; this is a little tricky since the mouse
and the keyboard are used to navigate the zoom box.  However, the same
mechanism holds -- the zoom box is manipulated in response to specific
keys on the keyboard.  This is another event/action table, where mouse
events are also mapped to application actions.

4) handling of the palette editor; the mouse handling is more involved
than the zoom box, but the same principle applies.

There might be a few other hidden places where the control flow has to
be considered.  Certain portions of the fractint code become easier
under this event/action table model when you consider the timer as
just another source of events.

Under an event/action table paradigm, think of fractint's interface
like this: at any given moment there is an action table in effect.  An
event is received from the system and the action table is searched for
a match.  If no match is found, the event is discarded.  If a match is
found, the associated action procedure is called with the event.  The
action procedure processes the event and takes the appropriate action,
returning to the event dispatcher.  The dispatcher then looks for
another event from the system.

Of course, if you have something computing in the background (the user
pressed F1 during image generation, and then pressed escape, for
instance), the main event loop can always use a non-blocking method of
checking for events so that background processing can continue when
there are no events to process.  In X11, this means using something
like select() or XPending() to check to see if the connection to the
X server has anything waiting.  If not, you perform another quantum
of background processing before checking for events again.

Under this model, a keystroke that results in a menu or parameter
field screen works by pushing its action table onto a stack, replacing
the current action table with its menu/screen specific table.
Eventually the user will do something that causes the menu/screen to
be replaced with the graphic image (pressing ESC or RETURN, for
instance) at which point the action table stack is popped and we
return to the original event processing context from which we invoked
the menu/screen in the first place.  Am I making sense?

If we followed this sort of abstraction, its a relatively small code
delta from what fractint currently has.  It does touch lots of files
and change lots of control logic in the code, however.  Its a
reasonable change to make, but it is a rather significant change.  The
current X11 port essentially polls the X server socket connection
(almost) every time the keyboard would have been polled under DOS.
This results in frequent checking of the X11 event queue, and there is
currently a fudge factor that prevents this check from happening too
often.  X11 wasn't meant to be used in a polling fashion, so its not
efficient when used in that manner -- which is why we have the fudge
factor in the xfractint code.

I think a change to an event-driven model is a good thing because the
window system ports all want to use an event-driven I/O model.  Only
DOS uses the polling model, and there isn't any reason why the DOS
version couldn't use an event-driven model.  Its just that fractint
grew up as a DOS program, and was architected with polling instead of
event dispatching.

Moving to an event-driven system would be a good thing, but I think it
should be deferred until after we get rid of the memory model stuff
and move to the driver interface.
- --
<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: Tue, 25 May 1999 11:28:28 -0600
From: Phil McRevis <[e-mail]>
Subject: (fractdev) Re: (fractint) Re: last bug report

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

> [bfdigits=20]
> The trouble with this sort of fix is one has no idea whether it
> disguises the real problem or fixes it. I will say, though, that I am
> not happy with fractint's caalculation of the needed precision,
> especially for rotated or skewed fractals. The bfdigits command
> lets you set whatever you want, for arbitrary precision at least.

This leads me to talk about a feature I've been wanting to add to
fractint, but one which definately requires the flat memory model
first because it trades space for time.

An iterated complex plane fractal as actually a special case of a
procedural texture.  If one approaches rendering a procedural texture
by computing a MIP-map approximation to the texture and using polygon
texturing techniques to handle the rotation/skew issue, the problem
becomes more interesting.  The resolution of the computation is
directly related to the depth of the mipmap level, symmetry (even for
rotated and skewed fractals) can be exploited to reduce memory
consumption.  Even better, refining the mipmap in memory as a source
for screen rendering results in caching of computation that increases
panning, zooming and rotating the texture.  XaoS exploits some of
these cases, but throws away data while zooming in, such that it must
recompute it when you zoom out.  A mipmap approach wouldn't suffer
this limitation unless you set a space ceiling on the amount of
already computed data it remembered.  Of course, even that could be
extended quite significantly with secondary storage paging.
- --
<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: Tue, 25 May 1999 16:01:18 -0300 (EST)
From: Humberto Rossetti Baptista <[e-mail]>
Subject: Re: (fractdev) Re: (fractint) Re: last bug report

On Tue, 25 May 1999, Phil McRevis wrote:

> In article <[e-mail]>,
>     "Tim Wegner" <[e-mail]>  writes:
> > [bfdigits=20]
[...]

    Have we lost this posting?

> An iterated complex plane fractal as actually a special case of a
> procedural texture.  If one approaches rendering a procedural texture
> by computing a MIP-map approximation to the texture and using polygon

    What is a MIP-map? (be technical) And where i can read more about it? I
tseems verry interesting to deal with.

    PS: one thing that would be very easy to do with memory avaliable is to
store the final outcome of the iteratiosn (the complex or pair of reals resulkt
and the iteration) of all points in the screen allowing for quick
experimentation with different colloring methods.

    []'s

    Humberto R. Baptista
    [e-mail]

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

- -----BEGIN GEEK CODE BLOCK-----
Version: 3.1
GB/C/CA/CM/CS/CC/ED/FA/H/IT/L/M/MU/P/S d?>pu s:- a->!@ C++++$ USL+++$ P+++@
L+++@ !E W++@ N++(+)@ o+>++++$ K? w>---$ O-@$ M--@ V-- PS@ PE@ Y+>+++$ PGP+@
t+++ 5+@ X+ R>+++$ tv@ b+>++++$ DI++$ D++>++++$ G e+++>+++++$ h(---)>*$ r+++
y+++*
- ------END GEEK CODE BLOCK------



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

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

Date: Tue, 25 May 1999 13:31:01 -0600
From: Phil McRevis <[e-mail]>
Subject: Re: (fractdev) Re: (fractint) Re: last bug report

In article <[e-mail]>,
    Humberto Rossetti Baptista <[e-mail]>  writes:

>     Have we lost this posting?

No, it was a whine on the fractint list, which reminded me of that
idea that I wanted to disseminate to fractdev.

>     What is a MIP-map? (be technical) And where i can read more about it? I
> tseems verry interesting to deal with.

A "mipmap" is a data structure used to represent textures in a
rendering system that supports textured polygons.  As a polygon
changes its orientation relative to the camera, the texture associated
with the polygon's surface becomes compressed and expanded.  This can
introduce aliasing in the textured surface.  The eliminate the
aliasing, one must implement a convolution over the texture to sum up
a weighted average of all the texels (texture map pixels) contributing
to a screen pixel to determine the appropriate texture contribution to
the screen pixel.  This texture contribution may then be passed
through lighting, depth cueueing, fog, etc., before becoming the final
pixel on the screen.

The mipmap datastructure is an approximation to the true convolution --
since doing the true convolution is quite expensive.  A mipmap contains
prefiltered versions of the texture at various levels of decimation.
For instance a 256x256 texture would be filtered to produce decimated
versions at resolutions 128x128, 64x64, 32x32, 16x16, 8x8, 4x4, 2x2
and 1x1.  The collection of decimated images plus the original texture
image is referred to as a "mipmap".  When rendering instead of
performing the full convolution, it is approximated by interpolating
both within a single level of a mipmap and between two adjacent levels
in a mipmap.  This is called bilinear and trilinear filtering,
respectively.

The way fractint works, the problem is somewhat easier, since we don't
allow the user to float above the fractal in perspective.  The view of
the fractal is equivalent to an orthographic view, which simplifies
things by eliminating a per-pixel divide in order to obtain correct
interpolation in a perspective view.

With a procedural texture, consider the mipmap as an infinite pyramid,
with the 1x1 version at the apex and finer and finer renderings of the
procedural texture appearing as the pyramid gets wider and wider.

> PS: one thing that would be very easy to do with memory avaliable is to
> store the final outcome of the iteratiosn (the complex or pair of reals resul
kt
> and the iteration) of all points in the screen allowing for quick
> experimentation with different colloring methods.

Yes, a mipmap like data structure would facilitate this -- instead of
storing pixels you store the last iterate in the orbit.  There is the
small wrinkle of storing more bits per iterate as you zoom deeper, but
its not hard to deal with.

Another advantage a mipmap like storage technique would get you
(besides avoiding recomputation of orbits, regardless of the
orientation of the viewport) is that anti-aliasing comes "for free"
and getting an anti-aliased image doesn't imply the loss of any data.
Thus you could swith coloring methods after the anti-aliased view is
finished and get an anti-aliased view with the new method without
recomputing any orbits.

The definitive reference for "mipmaps" and its application to computer
graphics and anti-aliasing can be found in this paper:

    Lance Williams
    Pyramidal Parametrics
    Computer Graphics, 17(3), pp. 1-11, July 1983.

This is the SIGGRAPH conference proceedings from 1983.  The technique
is popular enough now (for instance consumer gaming cards use
mipmapping to accelerate texture mapped games; direct3d has
mipmapping, OpenGL has mipmapping, etc.) that you can also find it
described in many computer graphics texts, but the paper cited above
was the first to describe the term "mipmap" and how it applies to
computer 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 #24
*****************************