ftp.xmission.com/2014.06.ftp.xmission.com.tar/ftp.xmission.com/pub/lists/fractdev/archive/fractdev.199905

Internet Message Format | 1999-05-26 | 120KB

From: "Tim Wegner" <[e-mail]>
Subject: Re: (fractdev) GPL clarification
Date: 01 May 1999 10:31:21 -0600

Kragen wrote:

> The response to my email to [e-mail]:
>
> If GMP is under the GPL, then Fractint would have to be
> GPLed to use GMP code.  Under the GPL you can have
> commercial sale, although license fees are illegal of
> course.
>
> --
>                                    Brian Youmans
>                                    FSF Office Staff


Folks if you want to kill the idea of Fractint's using somebody's
code, quote some bureaucrat who uses unintelligible  acronyms
who is trying to tell us what to do.

As Rich said, arbitrary precision is very low on our list of priorities.
We have working portable code written by ourselves. At some
future time we might rework it.

FWIW, Fractint has the policy of not using any libraries that we
can't provide in source form. We do have a need to redo our license
agreement, which is very badly written. However this interchange
has not warmed me up to  FSF (Free Software Foundation???).

Tim Wegner




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"


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

From: Phil McRevis <[e-mail]>
Subject: Re: (fractdev) GPL clarification
Date: 02 May 1999 19:26:30 -0600

Don't worry about what Brian Youmans said.  He hasn't read the license
file that comes with GMP.  That file really is the last word on this
subject.  <ftp://mirrors.xmission.com/gnu/gmp/gmp-2.0.2.tar.gz>
--
<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"


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

From: Phil McRevis <[e-mail]>
Subject: (fractdev) device extraction -- 2nd try
Date: 03 May 1999 08:08:40 -0600

------- =_aaaaaaaaaa0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <[e-mail]>

Looks like my first try was too long again, here we go...

Well I've made the first pass through the code and ripped out the
XFRACT specific parts and separated the code into two and a half
drivers: "disk", "x11", and "fractint".  Its only two and a half
drivers because the "fractint" driver hasn't had its guts (i.e. the
existing video drivers written in assembly) ported to a 32bit DPMI
environment, which is the target of this effort.

"disk" uses curses for text I/O, uses a piece of memory as a
framebuffer for graphical output and uses the diskvideo code already in
fractint.

"x11" has the X11 graphical output code, but none of the curses text
I/O code.  Next for X11 will be to have its text I/O implemented with
X text.

"fractint" won't work completely in this flat-memory model port (i.e.
djgpp) until the assembly code is ported for the video drivers.  Where
there was a routine that was only partially #ifdef'ed on XFRACT, the
non-XFACT version of the routine went into the fractint driver.  This
code has not been compiled, but would serve a useful scaffold to
whoever wanted to port the assembly. ;-)

I've only gone so far as to make the edits to the code (quite a lot)
and verify that everything compiles like it should.  I ran the curses
version and it came up like it should, although it didn't save a proper
GIF correctly when I typed 's'.

FYI Attachments: driver header file
--
<http://www.xmission.com/~legalize/>    Legalize Adulthood!
    ``Ain't it funny that they all fire the pistol,
      at the wrong end of the race?''--PDBT
          <http://www.eden.com/~thewho>

------- =_aaaaaaaaaa0
Content-Type: text/plain; name="drivers.h"; charset="us-ascii"
Content-ID: <[e-mail]>

#if !defined(DRIVERS_H)
#define DRIVERS_H

/*------------------------------------------------------------
 * Driver Methods:
 *
 * init
 * Initialize the driver and return non-zero on success.
 *
 * terminate
 * flush
 * schedule_alarm
 * start_video
 * end_video

 * window
 * Do whatever is necessary to open up a window after the screen size
 * has been set.  In a windowed environment, the window may provide
 * scroll bars to pan a cropped view across the screen.
 *
 * resize
 * redraw
 * read_palette, write_palette
 * read_pixel, write_pixel
 * read_span, write_span
 * set_line_mode
 * draw_line
 * get_key
 * shell
 * set_video_mode
 * put_string
 * set_for_text, set_for_graphics, set_clear
 * find_font
 * move_cursor
 * hide_text_cursor
 * set_attr
 * scroll_up
 * stack_screen, unstack_screen, discard_screen
 */
struct tagDriver {
  const char *name;            /* name of driver */
  int (*init)(int *argc, char **argv);  /* init the driver */
  void (*terminate)(void);        /* shutdown the driver */
  void (*flush)(void);            /* flush pending updates */
  void (*schedule_alarm)(int secs);    /* refresh alarm */

  int (*start_video)(void);
  int (*end_video)(void);

  void (*window)(void);            /* creates a window */
  int (*resize)(void);            /* handles window resize.  */
  void (*redraw)(void);            /* redraws the screen */

  int (*read_palette)(void);        /* reads palette into dacbox */
  int (*write_palette)(void);        /* writes dacbox into palette */

  int (*read_pixel)(int x, int y);
  void (*write_pixel)(int x, int y, int color);
                    /* reads a line of pixels */
  void (*read_span)(int y, int x, int lastx, BYTE *pixels);
                    /* writes a line of pixels */
  void (*write_span)(int y, int x, int lastx, BYTE *pixels);

  void (*set_line_mode)(int mode);    /* set copy/xor line */
  void (*draw_line)(int x1, int y1, int x2, int y2); /* draw line */

  int (*get_key)(int block);        /* poll or block for a key */
  void (*shell)(void);            /* invoke a command shell */
  void (*set_video_mode)(int ax, int bx, int cx, int dx);
  void (*put_string)(int row, int col, int attr, const char *msg);

  void (*set_for_text)(void);        /* set for text mode & save gfx */
  void (*set_for_graphics)(void);    /* restores graphics and data */
  void (*set_clear)(void);        /* clears text screen */

  BYTE *(*find_font)(int parm);        /* for palette editor */

  /* text screen functions */
  void (*move_cursor)(int row, int col);
  void (*hide_text_cursor)(void);
  void (*set_attr)(int row, int col, int attr, int count);
  void (*scroll_up)(int top, int bot);
  void (*stack_screen)(void);
  void (*unstack_screen)(void);
  void (*discard_screen)(void);

  /* sound routines */
  int (*init_fm)(void);
  void (*buzzer)(int kind);
  void (*sound_on)(int frequency);
  void (*sound_off)(void);

};
typedef struct tagDriver Driver;

#define STD_DRIVER_STRUCT(name_) \
  { \
    "##name_##", \
    name_##_init, \
    name_##_terminate, \
    name_##_flush, \
    name_##_schedule_alarm, \
    name_##_start_video, \
    name_##_end_video, \
    name_##_window, \
    name_##_resize, \
    name_##_redraw, \
    name_##_read_palette, \
    name_##_write_palette, \
    name_##_read_pixel, \
    name_##_write_pixel, \
    name_##_read_span, \
    name_##_write_span, \
    name_##_set_line_mode, \
    name_##_draw_line, \
    name_##_get_key, \
    name_##_shell, \
    name_##_set_video_mode, \
    name_##_put_string, \
    name_##_set_for_text, \
    name_##_set_for_graphics, \
    name_##_set_clear, \
    name_##_find_font, \
    name_##_move_cursor, \
    name_##_hide_text_cursor, \
    name_##_set_attr, \
    name_##_scroll_up, \
    name_##_stack_screen, \
    name_##_unstack_screen, \
    name_##_discard_screen, \
    name_##_init_fm, \
    name_##_buzzer, \
    name_##_sound_on, \
    name_##_sound_off \
  }

#define HAVE_X11_DRIVER 1
#define HAVE_DISK_DRIVER 1

extern int init_drivers(int *argc, char **argv);
extern void close_drivers(void);

#define USE_DRIVER_FUNCTIONS 1

#if defined(USE_DRIVER_FUNCTIONS)

extern void driver_terminate(void);
extern void driver_flush(void);
extern void driver_schedule_alarm(int secs);
extern int driver_start_video(void);
extern int driver_end_video(void);
extern void driver_window(void);
extern int driver_resize(void);
extern void driver_redraw(void);
extern int driver_read_palette(void);
extern int driver_write_palette(void);
extern int driver_read_pixel(int x, int y);
extern void driver_write_pixel(int x, int y, int color);
extern void driver_read_span(int y, int x, int lastx, BYTE *pixels);
extern void driver_write_span(int y, int x, int lastx, BYTE *pixels);
extern void driver_set_line_mode(int mode);
extern void driver_draw_line(int x1, int y1, int x2, int y2);
extern int driver_get_key(int block);
extern void driver_shell(void);
extern void driver_set_video_mode(int ax, int bx, int cx, int dx);
extern void driver_put_string(int row, int col, int attr, const char *msg);
extern void driver_set_for_text(void);
extern void driver_set_for_graphics(void);
extern void driver_set_clear(void);
extern BYTE *driver_find_font(int parm);
extern void driver_move_cursor(int row, int col);
extern void driver_hide_text_cursor(void);
extern void driver_set_attr(int row, int col, int attr, int count);
extern void driver_scroll_up(int top, int bot);
extern void driver_stack_screen(void);
extern void driver_unstack_screen(void);
extern void driver_discard_screen(void);
extern int driver_init_fm(void);
extern void driver_buzzer(int kind);
extern void driver_sound_on(int frequency);
extern void driver_sound_off(void);

#else

extern Driver *display;
#define driver_terminate()        (*display->terminate)()
#define driver_flush()            (*display->flush)()
#define void driver_schedule_alarm(_secs) \
    (*display->schedule_alarm)(_secs)
#define driver_start_video()        (*display->start_video)()
#define driver_end_video()        (*display->end_video)()
#define driver_window()            (*display->window)()
#define driver_resize()            (*display->resize)()
#define driver_redraw()            (*display->redraw)()
#define driver_read_palette()        (*display->read_palette)()
#define driver_write_palette()        (*display->write_palette)()
#define driver_read_pixel(_x, _y)    (*display->read_pixel)(_x, _y)
#define driver_write_pixel(_x, _y, _color) \
    (*display->write_pixel)(_x, _y, _color)
#define driver_read_span(_y, _x, _lastx, _pixels) \
    (*display->read_span(_y, _x, _lastx, _pixels)
#define driver_write_span(_y, _x, _lastx, _pixels) \
    (*display->write_span)(_y, _x, _lastx, _pixels)
#define driver_set_line_mode(_m)    (*display->set_line_mode)(_m)
#define driver_draw_line(x1_, y1_, x2_, y2_) \
    (*display->draw_line)(x1_, y1_, x1_, y2_)
#define driver_get_key(_block)        (*display->get_key)(_block)
#define driver_shell()            (*display->shell)()
#define driver_set_video_mode(_ax, _bx, _cx, _dx) \
    (*display->set_video_mode)(_ax, _bx, _cx, _dx)
#define driver_put_string(_row, _col, _attr, _msg) \
    (*display->put_string)(_row, _col, _attr, _msg)
#define driver_set_for_text()        (*display->set_for_text)()
#define driver_set_for_graphics()    (*display->set_for_graphics)()
#define driver_set_clear()        (*display->set_clear)()
#define driver_find_font(_parm)        (*display->find_font)(_parm)
#define driver_move_cursor(_row, _col)    (*display->move_cursor)(_row, _col)
#define driver_hide_text_cursor()    (*display->hide_text_cursor)()
#define driver_set_attr(_row, _col, _attr, _count) \
    (*display->set_attr)(_row, _col, _attr, _count)
#define driver_scroll_up(_top, _bot) \
    (*display->scroll_up)(_top, _bot)
#define driver_stack_screen()        (*display->stack_screen)()
#define driver_unstack_screen()        (*display->unstack_screen)()
#define driver_discard_screen()        (*display->discard_screen)()
#define driver_init_fm()        (*display->init_fm)()
#define driver_buzzer(_kind)        (*display->buzzer)(_kind)()
#define driver_sound_on(_freq)        (*display->sound)(_freq)
#define driver_sound_off()        (*display->sound_off)()

#endif

#endif /* DRIVERS_H */

------- =_aaaaaaaaaa0--

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"


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

From: "Tim Wegner" <[e-mail]>
Subject: (fractdev) Patch 71
Date: 03 May 1999 17:56:18 -0600

We're up to patch 71 with the fractint source.

I have incorporated all the patches to my no-integer-math version. I
also tried dropping the DOS no-integer source into Xfractint, and it
works fine. I'll package this up and upload in the next day or so.

I have looked at the changes proposed by Rich. The changes that
affect the X source are fine, but most of the changes that affect the
shared source are not right. This is not a big deal - I just need to
work this out with Rich.

I haven't looked at Rich's new changes yet, but will do so ASAP.

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"


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

From: Phil McRevis <[e-mail]>
Subject: Re: (fractdev) Patch 71
Date: 03 May 1999 17:02:09 -0600


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

> I haven't looked at Rich's new changes yet, but will do so ASAP.

That's because I haven't sent you any real changes yet. :-).  I tried
to include a summary of changes from CVS, but it went over the message
lenght limit.
--
<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"


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

From: Phil McRevis <[e-mail]>
Subject: (fractdev) gamma correction
Date: 04 May 1999 11:59:43 -0600

Is anyone working on making fractint smarter in its dealings with
gamma correction, or should I add that to the projects.txt file I was
maintaining?  Speaking of that file.... Tim, I thought the idea was to
include it in the fractint sources to help developers coordinate?  The
source that I've downloaded from your FTP area didn't contain the
file.
--
<http://www.xmission.com/~legalize/>    Legalize Adulthood!
    ``Ain't it funny that they all fire the pistol,
      at the wrong end of the race?''--PDBT
          <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"


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

From: Humberto Rossetti Baptista <[e-mail]>
Subject: Re: (fractdev) gamma correction
Date: 04 May 1999 22:12:09 -0300 (EST)

On Tue, 4 May 1999, Phil McRevis wrote:

> Is anyone working on making fractint smarter in its dealings with
> gamma correction, or should I add that to the projects.txt file I was
> maintaining?  Speaking of that file.... Tim, I thought the idea was to
> include it in the fractint sources to help developers coordinate?  The
> source that I've downloaded from your FTP area didn't contain the
> file.

    Yes. I have this in my todos.txt file too :-) Along with other color
models for Fractint, but the main point here is your comment: what about a
general todo list (with all sorts of tasks, with authors working or just waiting
for someone to take them up) it would be a moderated an refined list not much
like http://web.ukonline.co.uk/members/robin.b2/olig/fracwish.htm the "Official
Wish List" bu can feedback one on another.

    If you all think this is a good idea I can set up something like this in
one of my servers and someone would have to volunteer to trim and modetate all
the tasks  (i volunteer for the first round ;-) This way we could all summ up
our projects.txt todos.txt etc. in one place.

    []'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"


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

From: Phil McRevis <[e-mail]>
Subject: Re: (fractdev) gamma correction
Date: 04 May 1999 19:22:43 -0600

------- =_aaaaaaaaaa0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <[e-mail]>

Humberto, I think you joined this list after I created such files last
year.... I'm attaching the "todo" and "progress" files here.  You can
get at them on the web in my "fractdev" area
<http://www.xmission.com/~legalize/fractals/fractdev/>.  I admit the
"progress" file is a tiny bit stale in that it doesn't include
anything I've been doing with respect to these drivers.

-- Rich


------- =_aaaaaaaaaa0
Content-Type: text/plain; name="progress.txt"; charset="us-ascii"
Content-ID: <[e-mail]>

This file attempts to list the works "in progress" at the time of the
current fractint release (19.6) and the people working on them.  It is
hoped that this file will help developers coordinate their efforts and
eliminate any duplicate effort.

This file last updated January 29th, 1998

Project(s)                              Developer & Status
PNG support                             TW
24-bit support                          RBa, TW, others? (just starting)
SIMPLGIF improvements                   TW (encoder done, decoder needed)
GIF encoder fix                         TW (done)
Relaxing 2K image sizelimit             TW (nearly done)
float-only version                      TW (mostly done)
synchronous orbits                      TW (under way)
Formula parser improvements:
  C optimizer                           GM (under way)
xfractint visual selection              RT
Parameter Evolver                       RBu, JO (mostly done)
Memory use overhaul                     JO
Pentium M-set assembly optimization     DJ (approx. 1/2 done)

Current Developers:
-------------------
RBa     Ron Barnett <[e-mail]>
        Win95/DOS (MS VC++ 1.52, MASM 6.0, MS VC++ 5.0)
RBu     Robin Bussell <[e-mail]>
DJ      Damien M. Jones <[e-mail]>
GM      George Martin <[e-mail]>
        Win3.1/DOS (Borland 3.1)
JO      Jonathan Osuch <[e-mail]>
RT      Rich Thomson <[e-mail]>
        Win95/DOS (Borland C++ Builder 1.0, 3.0), Solaris (unix/gcc)
TW      Tim Wegner <[e-mail]>
        Win95/DOS (MSC 7.0, MASM 6.1, djgpp), linux (gcc)

------- =_aaaaaaaaaa0
Content-Type: text/plain; name="todo.txt"; charset="us-ascii"
Content-ID: <[e-mail]>

This file contains a list of things that are on the "To Do" list of
the fractint development team, practiced in the true Stone Soup
tradition.  Any item on this list is up for grabs and you are
encouraged to use this as a starting point for your fractint
contributions!

This document is arranged by the functional area within fractint.  The
functional areas are listed in alphabetical order with each idea
that's been suggested for improving the various sections.

This file last updated May 4th, 1999

3D Support
----------
- Provide a way to plug-in a 3D driver by name; platform support
  determines what drivers are available.  Fractint "native" 3D support
  available on all platforms.
- Add arcball for iteractive manipulation of 3D viewing parameters
  (interactively manipulate viewed object by its bounding box)

Arbitrary Precision
-------------------
- Extend arbitrary precision arithmetic to other fractal types, most
  notably formula types
- Allow arbitrary precision values to be entered into text field boxes
  and PAR files

Deep Color Support
------------------
- 24-bit color modes
- 32-bit color modes (RGB plus alpha)
- PNG 24/32-bit output/input
- Coloring pixels by formulas
- Texture mapping (probably best integrated into formula coloring)

Formula Parser
--------------
- Add type information for expressions and variables
- Add remainder (modulus) operator/function
- Make C versions of corresponding assembly functions more efficient
  (reduce function call overhead, apply optimizations)
- Provide a way to perform user-defined computations once per-image
- Provide a way to define and call named user functions like regular
  functions

Fractal Types
-------------
- Add 2D cellular automata
- Add continuously valued automata, a la CAPOW
- Various 3D fractal types that could be added
- Volume rendered fractal types (3D projection of quaternion julia set)

Fractal Types: Cellular
-------------
- Extend 1D cellular automata types beyond existing totalistic automata

Help Files
----------
- Add formula tutorial
- Add formula coloring methods tutorial
- Add color editor tutorial
- Add support to the help compiler for generating postscript / PDF /
  HTML output.
- Add support for inlined images in help browser (initially present
  only in PS/PDF/HTML versions)

Image Computation
-----------------
- Provide anti-aliasing support directly (requires deep color)
- Synchronous Orbits Iteration
- Gamma correction

Map Files
---------
- Gamma correction

Image I/O
---------
- Provide PNG support for both 8-bit and deeper video modes; handle
  gamma correction properly on output

Platform Support
----------------
- Create "fractint GUI API" that abstracts out fractint's ideas of
  dialogs, text boxes, number boxes, keyboard navigation of dialogs,
  etc., so that ports to other windowing systems are more readily
  accomplished from the same body of source code a la xfractint/fractint
  as opposed to the completely native port of winfract (which lags);
  this will abstract out the interface from the computation engine,
  which enhances portablity (something fractint sorely lacks) to other
  platforms and also makes it easy to reuse fractint's compute engine.
- Support for generalizing the assembly code to other architectures
  such as 68k, MIPS, etc., by segregating assembly code into
  architecture specific directories and integrating xfractint C
  emulation of assembly routines for all other architectures.
- Support "video modes" by name/number/capability rather than by
  function key assignment.  Since video modes vary by platform, and
  even on the same platform they can vary from user to user, a way of
  specifying the video mode in terms of its capability is needed.
  Something like video=x-res/y-res/depth, i.e. video=640/480/8.  In a
  windowed environment, the video "mode" is used to guide window size,
  palette emulation, etc.

Platform Support: DOS
---------------------
- Eliminate overlays / move to 32-bit flat address space DOS protected
  mode app (gives up 286 support)
- Option for displaying dialogs and text screens in graphics video
  mode with image save/restore; eliminates switching back and forth
  from text mode to graphics mode, saving wear and tear on monitors
- port code to DOS version of "fractint GUI API"
- Improve performance of native DOS 3D driver
- Compute an image larger than the screen resolution and allow panning
  through the larger image by the screen.

Platform Support: Win95/NT
--------------------------
- Win32 port
- long filename problems?
- DirectX support?
- 3D drivers: Direct3D / OpenGL
- animation support? (AVI, MPEG, etc.)

Platform Support: unix/X
------------------------
- Visual selection assumed root is 8-bit psuedocolor; improve to
  select appropriate visual for requested video mode (could be 24-bit
  with deep color support)
- Eliminate use of curses and xterm in favor of native X-based text
  windows
- Fix function key support (probably a free side-effect of previous item)
- Use Xt for interface components of "fractint GUI API"
- 3D drivers: OpenGL, PEX, native X
- Generate /bin/sh scripts instead of MS-DOS bat files for "b" command
- long filename problems?

Platform Support: Mac/Amiga/BeOS/NeXT/other
- Someone needs to do the port! :)

Zoom Box
--------
- Use XaoS like techniques to speedup the zoom box and/or initialize
  the screen from the zoomed section.

------- =_aaaaaaaaaa0--

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"


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

From: "Tim Wegner" <[e-mail]>
Subject: (fractdev) Unix timer
Date: 04 May 1999 22:55:58 -0600

I'm improving the timer sleepms(). It looks like the same primitive
timer is used by both Xfract and the DOS version.

Is the best way to get a portable microsecond timer under UNIX
gettimeofday()? I don't actually need microseconds, 100's of
microseconds (tenths of millisecs) is good enough.

I haven't had time yet to respond to all Rich's mail and upload
patch 71 source, but I probably will on Thursday night.

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"


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

From: Phil McRevis <[e-mail]>
Subject: Re: (fractdev) Unix timer
Date: 04 May 1999 22:53:13 -0600


How about getitimer?  I'm not sure how portable it is.  This is one of
those things where the standard library was extended after bell labs
unix, so vendors went in different directions.  Try to see if posix
has anything on usec timers.
--
<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"


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

From: [e-mail] (Kragen Sitaker)
Subject: Re: (fractdev) Unix timer
Date: 05 May 1999 09:35:52 -0400 (EDT)

Tim Wegner writes:
> Is the best way to get a portable microsecond timer under UNIX
> gettimeofday()? I don't actually need microseconds, 100's of
> microseconds (tenths of millisecs) is good enough.

Is this to report computation time on the <Tab> information screen?
times() might be more like what you want, since it doesn't report time
spent running other processes, but I haven't yet figured out how to
portably figure out what units it reports time in.  (On Linux, it's
HZ.)

gettimeofday() is available at least on Linux, Solaris, and *BSD.  I'm
fairly sure some of the old System Vs don't have it, but they are
mostly dead languages now; the main remaining holdout would be SCO,
which until recently (maybe even still?) was based on SVR3.  It might
even be the case that more recent SysVs don't have it, like IRIX; I
haven't used one of them since 1995, though, so I don't know.

--
<[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"


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

From: Humberto Rossetti Baptista <[e-mail]>
Subject: Re: (fractdev) gamma correction
Date: 05 May 1999 17:41:36 -0300 (EST)

On Tue, 4 May 1999, Phil McRevis wrote:

> Humberto, I think you joined this list after I created such files last
> year.... I'm attaching the "todo" and "progress" files here.  You can
> get at them on the web in my "fractdev" area
> <http://www.xmission.com/~legalize/fractals/fractdev/>.  I admit the
> "progress" file is a tiny bit stale in that it doesn't include
> anything I've been doing with respect to these drivers.

    Hm. Almost like what I've proposed, but done by hand :-)

    BTW, there isa crucial thing missing :-) a form so send you new items on
the list (proposed and on work). The currente projects list is very outdated
(more than one year).

    []'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"


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

From: Phil McRevis <[e-mail]>
Subject: Re: (fractdev) gamma correction
Date: 05 May 1999 17:28:41 -0600


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

> BTW, there isa crucial thing missing :-) a form so send you new items on
> the list (proposed and on work). The currente projects list is very outdated
> (more than one year).

Feel free to send any updates to this list.  I've sent the projects
file to this list several times and only received minor corrections,
so I figured that people were still working on what they said they
were working on before :-).

That web page isn't for general consumption, its just an area I put up
for sharing things relevant to this list.
--
<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"


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

From: "Tim Wegner" <[e-mail]>
Subject: Re: (fractdev) Unix timer
Date: 05 May 1999 22:50:44 -0600

Kragen asked:

> Is this to report computation time on the <Tab> information screen?

No, the current way of recording elapsed time works find, and
certainly doesn't need mictrosecond precision.

The sleepms() function inserts delays between orbits, mostly for
sound purposes. The trouble with this is that even if the delay is
device independent, the orbit execution ir roughly proportional to
CPU speed, so the over all result is an effect that runs faster on
faster machines.

On the PC I have found source for a microsecond timer. I have
used it to write a wait_until() function. The idea is that at each call,
a future time is recorded. On the next call, if the time hasn't been
reached, the function waits. As long as the wait time is greater
than the execution time, the result is reasonably device
independent.

The gettimeofday function returns two values, one with seconds,
the other with microseconds. I have tested it, and it works fine. So
if it is reasonably portable, this will take care of the Unix/Linux end.

Bill Jemison and some of the other artists have created some
terrific music with Fractint. Robin Bussell has written a driver for a
SOund Blaster (I don't know the details, I haven't followed too
closely.) Eventually we'll need to port the driver to Linux. I know
there is a lot of Linux sound code available.

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"


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

From: Phil McRevis <[e-mail]>
Subject: Re: (fractdev) Unix timer
Date: 06 May 1999 12:00:18 -0600


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

> Bill Jemison and some of the other artists have created some
> terrific music with Fractint. Robin Bussell has written a driver for a
> SOund Blaster (I don't know the details, I haven't followed too
> closely.) Eventually we'll need to port the driver to Linux. I know
> there is a lot of Linux sound code available.

Has anyone thought about sound under X/linux?  I don't know what linux
supports; X has minimal sound features intended only to reproduce the
fidelity of your typical PC keyboard speaker.
--
<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"


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

From: [e-mail]
Subject: RE: Re: (fractdev) Unix timer
Date: 06 May 1999 23:41 0000

Hi Rich,
Welcome to the soup kitchen :-)
I see you've been dropping in some good ingredients, nice one!

>Has anyone thought about sound under X/linux?

Well the drivers I've put in write directly to the OPL3 chip so the O/S
might not matter if the hardware's there. I'm not sure about the matter of
cpu  mode though, maybe the code won't have access to the I/O bus,
anyone know better?

It's all set up with wrapper functions anyway so adding on appropriate
ifdefs or whatever shoukd present no problems.

Cheers,
         Robin.






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


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

From: Humberto Rossetti Baptista <[e-mail]>
Subject: Re: (fractdev) gamma correction
Date: 06 May 1999 23:30:22 -0300 (EST)

On Wed, 5 May 1999, Phil McRevis wrote:

> Feel free to send any updates to this list.  I've sent the projects

    Not only me: list anyone? What are we working on now?

> so I figured that people were still working on what they said they
> were working on before :-).

    One or another new stuff came in. ;-)

    OK: I (HB) have generalized the Pickover Popcorn Julia and implemented a
new drawing methos (diffusion). and some more stuff I'll work as time permits,
but should be listed in the "future work" list if anyone wants to get them first
:-)

- Generalize the functions (user-defined) defaults and incorporate this in the
formula parser and related areas.

- Extend the parser support to deal w/ orbits (orbit-like fractals)

- Retouch epsilon cross method to support more colloring schemes

- Space mappings (maybe using the parser also) like generalizations to inversion
but allowing any distortion/mapping to be applied.

- Support to plot grids, axes, scales, color scales, legends etc. to illustrate
the images onscreen

- Support fot HSB/HLS color models.

- Network distribution of work.

- dL-systems (need more research first)

- HIFS (Hierachical IFS) seems easy.

    Other stuff that I'm intending to steal, aham, get inspiration from
other programs, like XaoS and Ultra Fractal (the first being very interesting
since it is free and the second is commecial but presents all algorithms to
almost everything in configuration files, seem very flexible).

    Of cours i'll not be able to cope with this list so soon, and the order
is not the one I wish to follow, but all these points seem worth some work form
me. :-))

    []'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"


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

From: "Tim Wegner" <[e-mail]>
Subject: (fractdev) Patches 65 through 73
Date: 09 May 1999 23:19:28 -0600

I have uploaded the latest patches to

ftp.phoenix.net/pub/USERS/twegner/patches_65_through_73.zip

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

The probably have CR/LF in them, so I suggest unzipping with the
freeware unzip using the -a option.

Now I need to wade through Rich's changes ...

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"


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

From: Phil McRevis <[e-mail]>
Subject: Re: (fractdev) Patches 65 through 73
Date: 10 May 1999 17:08:51 -0600

Tim, how important is it that I try to sync up my device-driver fork
with this patch?

I'm touching almost every file in the distribution...
--
<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"


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

From: Phil McRevis <[e-mail]>
Subject: (fractdev) "todo" and "progress" files updated
Date: 10 May 1999 17:18:04 -0600

I've incorporated Humberto's suggestions from his last email and added
him to the list of current fractint developers.  The updated files can
be fetched from <http://www.xmission.com/~legalize/fractals/fractdev/>
--
<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"


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

From: Humberto Rossetti Baptista <[e-mail]>
Subject: Re: (fractdev) "todo" and "progress" files updated
Date: 12 May 1999 10:21:12 -0300 (EST)

On Mon, 10 May 1999, Phil McRevis wrote:

> I've incorporated Humberto's suggestions from his last email and added
> him to the list of current fractint developers.  The updated files can
> be fetched from <http://www.xmission.com/~legalize/fractals/fractdev/>

    Hi Rich

    Cool, just to help:
Generalized popcorn julia sets          HB (done)
Diffusion drawing method                HB (done)
                                           ^^^^^^=Status

    And other stuff: (i'm not shure this is big enoughtto get in the list,
but anyway):

Latoocarfians                           HB (done)
New Epsilon Cross coloring              HB (patch submited)


    I guess this was my idea on the "project to be done list":
- Retouch epsilon cross method to support more colloring schemes
    :-)

    OK, lets check the rest:  havent seen RB (Robin) on the list isn't he
working on the sound routines?
    Is anybody else out?

    And you? Where is YOUR entry? I wnat to see the line "Flat model/32 bit
porting " on the list and a nice <done>  status following ;-))))))))))) An
<under way> wold by nice also :-)

    PS: have you got the time to try djgpp? or are you on gcc/linux. Have
you (all) seen thar egcs will become the new gcc?

    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"


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

From: Phil McRevis <[e-mail]>
Subject: Re: (fractdev) "todo" and "progress" files updated
Date: 12 May 1999 11:55:16 -0600


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

>     Cool, just to help:
> Generalized popcorn julia sets          HB (done)
> Diffusion drawing method                HB (done)
>                                            ^^^^^^=Status

OK, if they're done then we take them off the "progress" file, because
that's for stuff that's in progress :-)

I will also add my current project to the progress list (thanks for
the reminder).

>     PS: have you got the time to try djgpp? or are you on gcc/linux. Have
> you (all) seen thar egcs will become the new gcc?

Currently I'm working on unix.  When I have the native X text working
on unix, then I'll bring the code over to my PC and compile with djgpp
and GNU curses to verify disk video is working on the PC.  Then I'll
begin removing all the MK_FP()'s and so-on that's associated with the
medium memory model tricks.
--
<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"


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

From: Humberto Rossetti Baptista <[e-mail]>
Subject: Re: (fractdev) "todo" and "progress" files updated
Date: 12 May 1999 15:28:18 -0300 (EST)

On Wed, 12 May 1999, Phil McRevis wrote:

> OK, if they're done then we take them off the "progress" file, because
> that's for stuff that's in progress :-)

    For me its ok, I just assumed you're keeping things around until the
final release and then flushing the list.

> I will also add my current project to the progress list (thanks for
> the reminder).

    :-)))))

    []'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"


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

From: Phil McRevis <[e-mail]>
Subject: (fractdev) evolution of fractint source code as a package
Date: 13 May 1999 16:08:51 -0600

I'm curious how others feel about adopting the GNU conventions for
the fractint source.  Use of autoconf/automake, conventions for
Makefile targets, conventions for making source code distributions
from the makefile, etc.
--
<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"


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

From: "Tim Wegner" <[e-mail]>
Subject: Re: (fractdev) Patches 65 through 73
Date: 13 May 1999 17:29:25 -0600



> Tim, how important is it that I try to sync up my device-driver fork
> with this patch?

It's a pain now or later. Either method works <g!>

If it's a problem, we can get synched later. Then it is very important
to keep the sources you started from.

If your changes are compatible with our DOS version, we could
merge whenever your version is self-consistent.

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"


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

From: "Tim Wegner" <[e-mail]>
Subject: Re: (fractdev) evolution of fractint source code as a package
Date: 13 May 1999 17:31:53 -0600


> I'm curious how others feel about adopting the GNU conventions for
> the fractint source.  Use of autoconf/automake, conventions for
> Makefile targets, conventions for making source code distributions
> from the makefile, etc.

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

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"


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

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


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

> It's a pain now or later. Either method works <g!>

OK, I'll work my device-driver/memory model changes on a branch of
patch level 66.  I will keep an updated trunk for xfractint with the
patch level.  Then I will be able to make a merged diff when we're
ready to reintegrate the branch.

> If your changes are compatible with our DOS version, we could
> merge whenever your version is self-consistent.

The plan is that all versions will join in the end, and the DOS
version will be djgpp with DPMI.  There will be one source; but only
relevant drivers will be compiled on different systems.

I have replaced the #ifdef'ed code with code that calls into the
currently active driver.  Each driver provides an implementation of a
set of functions, which are called throughout the source.  The set of
drivers available is based on what you compiled.  So DOS versions
compile drivers that work in DOS, win32 versions compile the drivers
that work there (gdi, directx, OpenGL, etc.) and unix versions compile the
drivers that work there (i.e. X11, OpenGL, etc.).  Fractint's "text
screens" still exist in a graphics environment like X11 or win32, just
that the keystrokes cause window-system text to be drawn instead of
curses-based text.  This unifies the existing ports of fractint into
one source-code and execution model: windows, unix, and DOS.

Each driver is implemented in a file called d_<driver>.c, so my
existing code has d_disk.c, d_fract.c (routines that would call into
ported versions of fractint's 16-bit DOS video assembly code), and
d_x11.c.  Working from one of those as an example, it shouldn't be
hard to create a d_win.c and d_mac.c, bringing the mac and the windows
port also into the same code base.
--
<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"


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

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


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"


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

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


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"


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

From: [e-mail] (Kragen Sitaker)
Subject: Re: (fractdev) evolution of fractint source code as a package
Date: 13 May 1999 19:01:47 -0400 (EDT)

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"


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

From: Phil McRevis <[e-mail]>
Subject: (fractdev) unix patch 70
Date: 13 May 1999 17:03:17 -0600

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"


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

From: Phil McRevis <[e-mail]>
Subject: Re: (fractdev) evolution of fractint source code as a package
Date: 13 May 1999 17:04:39 -0600


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"


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

From: Jonathan Osuch <[e-mail]>
Subject: Re: (fractdev) unix patch 70
Date: 13 May 1999 21:03:48 -0400

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"


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

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


    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"


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

From: Phil McRevis <[e-mail]>
Subject: Re: (fractdev) unix patch 70
Date: 14 May 1999 11:35:13 -0600


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"


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

From: Phil McRevis <[e-mail]>
Subject: Re: (fractdev) Drivers API :-)
Date: 14 May 1999 11:45:40 -0600


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"


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

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

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"


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

From: Phil McRevis <[e-mail]>
Subject: Re: (fractdev) Drivers API :-)
Date: 14 May 1999 12:07:48 -0600


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"


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

From: Jonathan Osuch <[e-mail]>
Subject: Re: (fractdev) unix patch 70
Date: 14 May 1999 17:56:49 -0400

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"


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

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


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"


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

From: Jonathan Osuch <[e-mail]>
Subject: Re: (fractdev) unix patch 70
Date: 15 May 1999 08:55:37 -0400

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"


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

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


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"


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

From: Jonathan Osuch <[e-mail]>
Subject: Re: (fractdev) unix patch 70
Date: 16 May 1999 17:42:03 -0400

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"


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

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


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"


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

From: Phil McRevis <[e-mail]>
Subject: (fractdev) Re: (fractint) Re: last bug report
Date: 25 May 1999 11:28:28 -0600


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"


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

From: Humberto Rossetti Baptista <[e-mail]>
Subject: Re: (fractdev) Re: (fractint) Re: last bug report
Date: 25 May 1999 16:01:18 -0300 (EST)

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"


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

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


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"


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

From: Humberto Rossetti Baptista <[e-mail]>
Subject: Re: (fractdev) Re: (fractint) Re: last bug report
Date: 25 May 1999 16:59:21 -0300 (EST)

On Tue, 25 May 1999, Phil McRevis wrote:

> 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 structure os a MIP map reminds me of two things: the wavlet
transform and my dithereing drawing method. :-) In this last I effectively start
with a 1x1 pixel and go down to the full resolution of the image.

[...]
> 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.

    Even more like my method.


[...]
> 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.

    Hm. or I could make the dithering method go 1 level deeper (with some
easy adjustments to avoid over calculation of points) and derive anti aliasing
from there.
>
> The definitive reference for "mipmaps" and its application to computer
> graphics and anti-aliasing can be found in this paper:
[...]

    Thanks, rich.

    BTW: how're things with the flat memory model?

    []'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"


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

From: Phil McRevis <[e-mail]>
Subject: Re: (fractdev) Re: (fractint) Re: last bug report
Date: 26 May 1999 08:50:16 -0600


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

>     The structure os a MIP map reminds me of two things: the wavlet
> transform and my dithereing drawing method.

I don't know what your dithering drawing method is, but its only
relation to the wavelet transform is that they both have recursive
elements to their structure.  But then again, so does counting to 100
by tail recursion.

>  Hm. or I could make the dithering method go 1 level deeper (with some
> easy adjustments to avoid over calculation of points) and derive anti
> aliasing from there.

Dithering != anti-aliasing; either we are not using the same terms
consistently, or we have some confusion on what "anti-aliasing" and
"dithering" really do.  One would typically apply anti-aliasing to a
full 24-bit RGB image and then dither it to the resolution of the
device (i.e. 16-bit color, or 8-bit LUT).  The two techniques are
often useful at the same time, but you definately do not want to try
and "anti-alias" a dithered image if you expect to get quality
results.

>     BTW: how're things with the flat memory model?

Clunking along.  I am trying to get my own business off the ground
before I run out of $$, so I can't work on the flat memory model
24/7.
--
<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"


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

From: Humberto Rossetti Baptista <[e-mail]>
Subject: Re: (fractdev) Re: (fractint) Re: last bug report
Date: 26 May 1999 12:16:57 -0300 (EST)

On Wed, 26 May 1999, Phil McRevis wrote:

>
> In article <[e-mail]>,
>     Humberto Rossetti Baptista <[e-mail]>  writes:
>
> >     The structure os a MIP map reminds me of two things: the wavlet
> > transform and my dithereing drawing method.
>
> I don't know what your dithering drawing method is, but its only
> relation to the wavelet transform is that they both have recursive
> elements to their structure.  But then again, so does counting to 100
> by tail recursion.

    Ups, old terminology: i meant diffusion method (i changed the name some
time ago to avoid confusion, but I keep forgetting :-)

> >  Hm. or I could make the dithering method go 1 level deeper (with some
> > easy adjustments to avoid over calculation of points) and derive anti
> > aliasing from there.
[... mess I made ...]

    What I meant is that the diffusion drawing method uses a spcial
recursive subdivision method that is very economic in memory and is similar to
the structure you descibed to the mip maps.

    Por instance we can star with a 1x1 pixel image (the pixel covers the
whole screen) then to a 2x2, then a 4x4 and so on until the 2^nx2^n you want.
Right now my method stops in the screen resolution, but there is nothing that
stop us to go further, that is calculate all points between the screen points,
this could help anti-aliasin. This also could be done w/ images generated with
other drawing method (i can start my method in any point).

    Since we're on the subject let's check some things that are not clear
for me.

    I do not see how we can do anti-aliasing without reducing the resolution
of the final image. But:

    *   *  < pixels in the maximum resolution evaluate
      #    < interpolated pixel calculated on a 2x resolution than above

    What could the interpolated pixels help on the anti-alias calculation?

    I think I miss somenthing here as I see little advantage on the use of
anti-alias on our fractal drawing work.

> >     BTW: how're things with the flat memory model?
>
> Clunking along.  I am trying to get my own business off the ground
> before I run out of $$, so I can't work on the flat memory model
> 24/7.

    Right. I never expected anyone to get full 24/7 on this (though it would
be nice to earn a livin like this :-)))) But the scheme you presented was so
simple (to the sense that it interferes little with the existent code) that I
was curious to know.

    I have to come back to my bussiness now too :-)) Gook luck.

    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"


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

From: Phil McRevis <[e-mail]>
Subject: Re: (fractdev) Re: (fractint) Re: last bug report
Date: 26 May 1999 09:37:46 -0600


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

>     Ups, old terminology: i meant diffusion method (i changed the name some
> time ago to avoid confusion, but I keep forgetting :-)

Ah... OK, that makes much more sense.

>  I do not see how we can do anti-aliasing without reducing the resolution
> of the final image.

In the context of fractals, it is impossible to construct a bandwidth
limited version of the fractal that you then sample.  Because you are
always sampling a "thing" which has frequency components higher than
the highest representable frequency component on the screen, you
always have aliasing.  If you could bandwidth limit the fractal before
sampling it, then the samples would reproduce the frequencies exactly
and no anti-aliasing would be needed.

So, we're stuck with aliasing and the best we can do is try to
minimize the aliasing by applying anti-aliasing techniques.  This
generally implies supersampling the fractal and filtering the
supersampled fractal to the final resolution.  In order to support
anti-aliasing, fractint would need to devote memory storage (either
incrementally on a scanline-by-scanline basis, or in toto) to the
supersampled image.  The screen displays the result of the
anti-aliased filter.

>     *   *  < pixels in the maximum resolution evaluate
>       #    < interpolated pixel calculated on a 2x resolution than above
>
>     What could the interpolated pixels help on the anti-alias calculation?

Decimation and interpolation are opposites.  Decimation (usually
combined with filtering; decimation without filtering just throws away
pixels and/or scanlines) decreases the number of pixels in an image
and interpolation increases the number of pixels in an image.  When
you are approximating a fractal with a few samples, then you
interpolate.  If you have more samples than your final resolution, you
decimate -- hopefully with a nice anti-aliasing filter so that you
don't introduce aliasing in the decimation process.

>     I think I miss somenthing here as I see little advantage on the use of
> anti-alias on our fractal drawing work.

Damien has a wonderful set of images on his web area that exaplains the
advantage of anti-aliasing for fractals.

> [...] the scheme you presented was so
> simple (to the sense that it interferes little with the existent code) that I
> was curious to know.

As it stands right now, the X11 "driver" appears to be working OK for
the code that I migrated from unixscr.c into d_x11.c; what is missing
is native X11 text output (so that an xterm window + curses isn't
required for X11 text output).  My plans are:

    o add native X11 text output
    o integrate driver into the video mode selection logic, similar to
    the ASCII mockup I posted earlier
    o massage curses driver for "graphic" output a la XaoS
    o massage disk driver for diskvideo output

Then what remains is to go through the use of memory to remove the
overlay and wacky memory buffers that fractint uses.  Things like
MK_FP() will go away, but since a single chunk of memory is aliased
(like a fortrash common block) by different routines, that will take
some careful work.  Finally, all the "far/huge/near" qualifiers on
memory can be removed (FCODE too).  At that point, I'll take the code
over to the DJGPP -- I'm currently developing everything on unix since
the tools and debuggers are more familiar to me -- and get disk and
curses video drivers working on DOS.  The final thing will be to get
the assembly code working for graphics output on DOS.  This may be
more trouble than its worth for me, and instead I may just implement
a graphics driver based on allegro and leave the assembly code to some
other motivated individual :-).
--
<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"


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

From: Phil McRevis <[e-mail]>
Subject: Re: (fractdev) Re: (fractint) Re: last bug report
Date: 26 May 1999 08:50:16 -0600


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

>     The structure os a MIP map reminds me of two things: the wavlet
> transform and my dithereing drawing method.

I don't know what your dithering drawing method is, but its only
relation to the wavelet transform is that they both have recursive
elements to their structure.  But then again, so does counting to 100
by tail recursion.

>  Hm. or I could make the dithering method go 1 level deeper (with some
> easy adjustments to avoid over calculation of points) and derive anti
> aliasing from there.

Dithering != anti-aliasing; either we are not using the same terms
consistently, or we have some confusion on what "anti-aliasing" and
"dithering" really do.  One would typically apply anti-aliasing to a
full 24-bit RGB image and then dither it to the resolution of the
device (i.e. 16-bit color, or 8-bit LUT).  The two techniques are
often useful at the same time, but you definately do not want to try
and "anti-alias" a dithered image if you expect to get quality
results.

>     BTW: how're things with the flat memory model?

Clunking along.  I am trying to get my own business off the ground
before I run out of $$, so I can't work on the flat memory model
24/7.
--
<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"

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"


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

From: Humberto Rossetti Baptista <[e-mail]>
Subject: Re: (fractdev) Re: (fractint) Re: last bug report
Date: 27 May 1999 14:57:38 -0300 (EST)

On Wed, 26 May 1999, Phil McRevis wrote:

>
> In article <[e-mail]>,
>     Humberto Rossetti Baptista <[e-mail]>  writes:
>
> >     Ups, old terminology: i meant diffusion method (i changed the name some
> > time ago to avoid confusion, but I keep forgetting :-)
>
> Ah... OK, that makes much more sense.
>
> >  I do not see how we can do anti-aliasing without reducing the resolution
> > of the final image.
>
> In the context of fractals, it is impossible to construct a bandwidth
> limited version of the fractal that you then sample.  Because you are
> always sampling a "thing" which has frequency components higher than
> the highest representable frequency component on the screen, you
> always have aliasing.  If you could bandwidth limit the fractal before
> sampling it, then the samples would reproduce the frequencies exactly
> and no anti-aliasing would be needed.
>
> So, we're stuck with aliasing and the best we can do is try to
> minimize the aliasing by applying anti-aliasing techniques.  This
> generally implies supersampling the fractal and filtering the
> supersampled fractal to the final resolution.  In order to support
> anti-aliasing, fractint would need to devote memory storage (either
> incrementally on a scanline-by-scanline basis, or in toto) to the
> supersampled image.  The screen displays the result of the
> anti-aliased filter.
>
> >     *   *  < pixels in the maximum resolution evaluate
> >       #    < interpolated pixel calculated on a 2x resolution than above
> >
> >     What could the interpolated pixels help on the anti-alias calculation?
>
> Decimation and interpolation are opposites.  Decimation (usually
> combined with filtering; decimation without filtering just throws away
> pixels and/or scanlines) decreases the number of pixels in an image
> and interpolation increases the number of pixels in an image.  When
> you are approximating a fractal with a few samples, then you
> interpolate.  If you have more samples than your final resolution, you
> decimate -- hopefully with a nice anti-aliasing filter so that you
> don't introduce aliasing in the decimation process.
>
> >     I think I miss somenthing here as I see little advantage on the use of
> > anti-alias on our fractal drawing work.
>
> Damien has a wonderful set of images on his web area that exaplains the
> advantage of anti-aliasing for fractals.
>
> > [...] the scheme you presented was so
> > simple (to the sense that it interferes little with the existent code) that I
> > was curious to know.
>
> As it stands right now, the X11 "driver" appears to be working OK for
> the code that I migrated from unixscr.c into d_x11.c; what is missing
> is native X11 text output (so that an xterm window + curses isn't
> required for X11 text output).  My plans are:
>
>     o add native X11 text output
>     o integrate driver into the video mode selection logic, similar to
>     the ASCII mockup I posted earlier
>     o massage curses driver for "graphic" output a la XaoS
>     o massage disk driver for diskvideo output
>
> Then what remains is to go through the use of memory to remove the
> overlay and wacky memory buffers that fractint uses.  Things like
> MK_FP() will go away, but since a single chunk of memory is aliased
> (like a fortrash common block) by different routines, that will take
> some careful work.  Finally, all the "far/huge/near" qualifiers on
> memory can be removed (FCODE too).  At that point, I'll take the code
> over to the DJGPP -- I'm currently developing everything on unix since
> the tools and debuggers are more familiar to me -- and get disk and
> curses video drivers working on DOS.  The final thing will be to get
> the assembly code working for graphics output on DOS.  This may be
> more trouble than its worth for me, and instead I may just implement
> a graphics driver based on allegro and leave the assembly code to some
> other motivated individual :-).
> --
> <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"
>

    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"


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

From: Humberto Rossetti Baptista <[e-mail]>
Subject: Re: (fractdev) Re: (fractint) Re: last bug report
Date: 27 May 1999 16:00:48 -0300 (EST)


    Sorry last one went without the actual reply.

On Wed, 26 May 1999, Phil McRevis wrote:
>
> So, we're stuck with aliasing and the best we can do is try to
> minimize the aliasing by applying anti-aliasing techniques.  This
> generally implies supersampling the fractal and filtering the
> supersampled fractal to the final resolution.  In order to support
> anti-aliasing, fractint would need to devote memory storage (either
> incrementally on a scanline-by-scanline basis, or in toto) to the
> supersampled image.  The screen displays the result of the
> anti-aliased filter.


    Right, now I'm seeing the point.

>
> >     *   *  < pixels in the maximum resolution evaluate
> >       #    < interpolated pixel calculated on a 2x resolution than above
> >
> >     What could the interpolated pixels help on the anti-alias calculation?

> Decimation and interpolation are opposites.  Decimation (usually
[...]

    Hm. But if we go calculating an over sampled image then we use the pixes
of higher frequency to influence the cnormal frequency ones and with this (an
the appropriate filter) generete the anti-alias effect.

> Damien has a wonderful set of images on his web area that exaplains the
> advantage of anti-aliasing for fractals.

    I'll check.

[...]
> the assembly code working for graphics output on DOS.  This may be
> more trouble than its worth for me, and instead I may just implement
> a graphics driver based on allegro and leave the assembly code to some
> other motivated individual :-).

    Great, it seems very interesting and motivating. If you need any help at
any point (for instance on the setup of DJGPP w/ the appropriate tools) let me
know. Th idea of linking against allegro seem like a good one for me. I'll allow
the proliferation of colaboration on the flat model version.

    []'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"


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

From: Phil McRevis <[e-mail]>
Subject: Re: (fractdev) Re: (fractint) Re: last bug report
Date: 27 May 1999 15:42:55 -0600


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

> Hm. But if we go calculating an over sampled image then we use the pixes
> of higher frequency to influence the cnormal frequency ones and with this (an
> the appropriate filter) generete the anti-alias effect.

With the supersampling anti-aliasing method, what you are doing is
attempting to integrate the signal (i.e. the fractal) over the 'area'
of the pixel and come up with an appropriate average value.  This is
what makes highly dense chaotic regions fade to a uniform shade as the
characteristic length of the chaotic region approaches the dimensions
of a pixel.  In a strict mathematical and signal processing sense, you
still have an aliased image, but the aliasing is at a higher frequency
component which isn't as perceptible.

In this sense, "anti-aliasing" is a bit of a misnomer, because it
attenuates the effect of aliasing but doesn't eliminate it.  The only
way to truly eliminate aliasing is to limit the bandwidth of the
signal before it is sampled.  For real-world signals like audio, they
can be bandwidth limited before sampling so that aliasing isn't a
problem.  For synthetic signals like fractal renderings or ray-traced
scenes, it is difficult if not impossible to limit the bandwidth of
the signal before sampling.  Theoretically, one could analytically
limit the bandwidth of a raytraced scene, but in practice it is so
computationally intractable that supersampling is a more realistic
solution.
--
<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"


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

From: [e-mail] (Kragen Sitaker)
Subject: (fractdev) Re: antialiasing
Date: 27 May 1999 18:23:49 -0400 (EDT)

Rich writes:
> Theoretically, one could analytically
> limit the bandwidth of a raytraced scene, but in practice it is so
> computationally intractable that supersampling is a more realistic
> solution.

Hmm, that's an interesting thought.

Have people actually analyzed the computational complexity of doing
this?  Clearly it would require significantly more complex *programs*,
but they might not necessarily run slower.

It is not obvious to me how to do it at all, either for raytraced
scenes or for Mandelbrots.

--
<[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"


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

From: Phil McRevis <[e-mail]>
Subject: Re: (fractdev) Re: antialiasing
Date: 27 May 1999 16:29:16 -0600


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

> Have people actually analyzed the computational complexity of doing
> this?  Clearly it would require significantly more complex *programs*,
> but they might not necessarily run slower.

<shrug>  The only reason I believe it theoretically plausible for
ray-tracers is that one can obtain a description of the scene in
closed form.  You may have to restrict your scene a little bit in
order to maintain a closed form -- i.e. no procedural mandelbrot
textures.

Since you can't get a fractal into a closed form, that is what
prevents you from analytically limiting its bandwidth in the scene.
--
<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"