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

Internet Message Format | 2000-06-30 | 45KB

From: "Scott D. Boyd" <[e-mail]>
Subject: Bug fix in Xfractint 20.0.11
Date: 02 Jun 2000 22:40:18 -0500

I have found the bug that kept '#' and 'F3' from selecting 3D Overlay while
at the Main Menu in Xfractint. I removed lines 1294 - 1295 in unixscr.c.

This bug was present in both versions 20.0.7 and 20.0.11. '#' didn't work in
either xterm or KDE's konsole, and F3 didn't work in KDE's konsole. Now I have
'#' working from both xterm and konsole.

This fix has been tested and known to work in Xfractint 20.0.11 running in
xterm and KDE's konsole. (Well, that partly fixes the problem. At least the
key indicated in the Main Menu now works! So I guess you could call it a "quick
fix".)


--
email:  [e-mail]
http://www.fastlane.net/~sdboyd/
"Make it idiot-proof, and someone will make a better idiot."


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: Bug fix in Xfractint 20.0.11
Date: 04 Jun 2000 16:28:43 -0500

Scott,

> I have found the bug that kept '#' and 'F3' from selecting 3D Overlay
while
> at the Main Menu in Xfractint. I removed lines 1294 - 1295 in unixscr.c.

That is a routine I think I will change to be bypassed unless requested by a
command line option.  It catches the control-e used by the evolver, also.

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: "Jonathan Osuch" <[e-mail]>
Subject: Allegro port status
Date: 27 Jun 2000 20:40:23 -0500

Tim,

The latest set of source code available to you has all the menus working.
The temporary messages still need a little work.

We need to work on the interface we want to use for the various graphics
modes.  Currently, the built in Allegro function is used to provide a menu,
but we don't need (or want?) to use it.  We could set up the command line
such that something like: video=1024x768x24  would provide the resolution
and the color depth.  Backwards compatibility needs to be worked out also.
As does the results of pressing the function keys and what appears when the
delete key is pressed.  Also, we need to consider how setting the disk video
resolution will work.  We could have a menu like:

X Width           1078
Y Depth           768
Color Depth     24

I have a version where the palette editor (with 8 bit color) works to a
certain extent.  There are sections of code that will need to be changed to
get the alignment of the boxes and characters correct.

There is also a problem with displaying arrows (for which keys to use) on
the screen.  This is due to using the default key mapping from Allegro.  I
haven't tried to fix it yet.

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: Allegro port status
Date: 28 Jun 2000 13:48:33 -0600


In article <000d01bfe0a1$e329ff00$0100a8c0@bananasenior>,
    "Jonathan Osuch" <[e-mail]>  writes:

> but we don't need (or want?) to use it.  We could set up the command line
> such that something like: video=1024x768x24  would provide the resolution
> and the color depth.

Specifying the depth alone isn't enough to identify various video
modes of importance.  For instance, in 16-bit mode you have RGB 5:6:5
and xRGB 1:5:5:5 and RGBA 5:5:5:1.

> Backwards compatibility needs to be worked out also.

Fractint currently only remembers the video mode from the function key
definition.  This should be changed to specify the video mode
explicitly rather than relying on the indirection through the video
key mapping.

> As does the results of pressing the function keys and what appears when the
> delete key is pressed.  Also, we need to consider how setting the disk video
> resolution will work.

I envisioned that "disk video" mode would be just another device
selected through the interface.  It can have an arbitrary pixel format
for its output, since its all in software.  The larger vision was to
enable the possibility of having Win32 modes and DirectX modes living
side-by-side even though they are pretty different on the insides.

That's why the menuing, etc., code has to be in the driver interface
-- doing a menu under Win32 or DOS/Allegro is going to be very
different from doing it under DirectX or the Mac, or Xlib, 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
[e-mail]    <http://www.xmission.com/~legalize/who/>

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: Allegro port status
Date: 29 Jun 2000 16:26:01 -0500

Rich,

> Specifying the depth alone isn't enough to identify various video
> modes of importance.  For instance, in 16-bit mode you have RGB 5:6:5
> and xRGB 1:5:5:5 and RGBA 5:5:5:1.

We can certainly address this.  Since Allegro does this for us behind the
scenes, your input will be invaluable in setting this up.  I take it you are
suggesting something along the lines of: video=1024x768x5x6x5x0

Or, would it be cleaner to use a different command line, such as:
video=1024x768 depth=5:6:5:0

> Fractint currently only remembers the video mode from the function key
> definition.  This should be changed to specify the video mode
> explicitly rather than relying on the indirection through the video
> key mapping.

Yes, I agree.  But, in order to not break PAR's that use video=, we will
still need to map those function keys to video modes.  OTOH, we could just
ignore video= commands in PARs.  The problem that raises is that there are
some images that are resolution dependent.

> I envisioned that "disk video" mode would be just another device
> selected through the interface.  It can have an arbitrary pixel format
> for its output, since its all in software.

Currently that is crudely done by recompiling.  I haven't taken a close look
at how to switch from one device to another when both are memory resident.

It appears to me that the windows allowed by Allegro can also be arbitrarily
sized.  Although you can run into a problem with the text being too small or
off the edge of the window.

Jonathan

P.S.  If I don't respond to something you think is important it's probably
because it went zinging over my head.  Please feel free to reiterate.



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: Allegro port status
Date: 29 Jun 2000 17:54:22 -0600


In article <000901bfe210$aaca4500$0100a8c0@bananasenior>,
    "Jonathan Osuch" <[e-mail]>  writes:

> We can certainly address this.  Since Allegro does this for us behind the
> scenes, your input will be invaluable in setting this up.  I take it you are
> suggesting something along the lines of: video=1024x768x5x6x5x0
>
> Or, would it be cleaner to use a different command line, such as:
> video=1024x768 depth=5:6:5:0

I hadn't thought much about this recently.  On 29-Apr-1999, I wrote
the following (which can be had from the archives at
<ftp://ftp.xmission.com/pub/lists/fractdev/archive/>:

=====
    Date: Thu, 29 Apr 1999 19:55:01 -0600
      To: [e-mail]
    From: Phil McRevis <[e-mail]>
Reply-To: [e-mail]
   Organ: multi-cellular, biological
 Subject: driver characteristics
---------
Since Humberto brought up some specifics of drivers, I'll say a little
about how I'm implementing the driver harness.  Naturally we'll be
able to change the harness later.  The point is not to design some
end-all be-all graphics API.  The idea is just to get things going
incrementally.  Feel free to kibitz, if its a big issue, something can
be done now, but please consider this more of a 'status report' for
your information on what I'm doing, more than a design review where
I'm proposing the idea. :-)

Existing video mode glue logic in fractint is currently implemented in
select_video_mode().  It walks through the table stored in memory and
creates the scrollable display of available video modes.  When you
select a mode from the list (or by some other means like video=), then
the proper parameters are snatched out of the table and sent to the
assembly routine setvideomode (video.asm), which issues the
appropriate commands to the video card.

With the harness, select_video_mode() instead walks a list of drivers
and queries each driver about the modes supported by the driver.  It
then displays a scrolling list created from the driver responses.
When the user selects an item on the list, select_video_mode() calls
through the driver harness to set the video mode.

This means that when we get to the point of having all (or several) or
the drivers I list below, under win98 you could have the choice of
the same video modes supported by multiple drivers.  The video display
list might look like this:

key...driver...name.................xdot.ydot.color.comment.............
SF1   win32    GDI Surface          1024x768  5:6:5
SF2   directx  Windowed             1024x768  5:6:5
SF3   directx  Full Screen          1024x768  8     256 colors
SF4   directx  Full Screen          1024x768  5:6:5 16-bit RGB
SF5   directx  Full Screen          1024x768  5:5:5 15-bit RGB
SF6   opengl   Full Screen          1024x768  8     256 color indexed
SF7   opengl   Full Screen          1024x768  8:8:8 24-bit RGB

(This is an ASCII graphic mockup; not a screen dump.)

Xdot and ydot take on a subtle meaning in a windowed environment, but
window systemless drivers still need to be able to report device
dimensions.

The video parameter ('video=<key>') currently only specifies a function
key which is bound to a video mode.  It doesn't force a particular
video mode, just selects one from the key list.  If you want to write a
script or parameter file that uses a particular video mode, you have to
ensure the proper key assignment is setup first.  To set the function
key assignment you have to get into the fractint.cfg file.  Icky!

With the harness, the video parameter is updated to specify both the
driver and the desires video mode provided by the driver.  So you'd
say something like "video=directx/1024x768/8".  A new method for
binding the keys to video modes will have to be provided, as the old
method depended on fractint.cfg which is now specific to the fractint
driver.

But what about the stuff the fractint.cfg file did?  That's used by the
"fractint" driver (see blow) as input to decide what video modes it
lists when queried.

Some really random ideas:

should image and model formats (3D raytracing files, etc) be
    supported as compile-time modules like drivers?

should drivers be allowed to invoke the engine distinct from
    fractint's gui?  Is the engine a client of the driver, or is the
    driver a client of the engine?  Fractint is currently architected
    towards the latter.  Reversing the assumption would be difficult.

should 3D drivers subsume 2D functionality?
    Is there any reason you'd want to use ogl for 3D, but x11 for 2D?
    If not, then "x11" and "opengl" drivers will provide everything
    you need.  Select an "x11' driver video mode for 2D stuff and an
    "opengl" driver video mode for 3D stuff.  Fractint doesn't (yet)
    mix 2D and 3D rendering together.

Drivers
-------
display drivers I think should be done, in no particular order:
    "curses"
    possibly uses curses, but only has character I/O.
    Displays "pixels" using characters as similar to XaoS.
    Enumerate text vide modes (DOS) or screen sizes (curses?) to
        form "video modes" table.
    Works in DOS (pd curses) and unix (native curses).

    "fractint"
    port existing fractint assembly code to 32-bit flat model.
    Included is the native video and mouse support coded in
    assembly.

    "allegro"
    Uses Allegro library under DJGPP to enumerate video formats
    and provide video/mouse/sound support.

    "disk"
    Video modes contain list of standard image sizes and "custom",
    letting you set the size.

    "win32"
    text menus are displayed graphically somehow.
    graphics display native to GDI presented as video mode.
    Emulate other modes?  Only if someone desperate for it --
    directx would be the preferred solution!

    "directx"
    text menus are displayed using a regular win32 window on GDI
        surface, or as graphic text on graphics screen (driver
        option).
    graphics display is done through full-screen with DirectDraw.
    DirectDrawDevices enumerated by DDraw are the video modes.

    "direct3d"
    Same as directx, but uses D3D for 3D effects.

    "x11"
    Text menus are displayed graphically using X11.
    Available visuals on the screen are the video modes.

    "opengl"
    Same as X11, only OGL-capable visuals are video modes.
    Uses OGL for all pixel I/O and 3D.

like XaoS, more that one driver can be available, but only one driver
can be active at once in any given graphic window.
=====

So I think I was expecting that the old video mode specifications
would still be supported (they wouldn't contain /'s) and that the new
video specification would be a driver/resolution/depth argument, where
the depth would be stated to be sufficiently unique.  I think I prefer
R:G:B:A, with the letters replaced by the number of bits dedicated to
each color channel.  This disambiguates 5:5:5, 5:6:5, and 5:5:5:1
pixel formats for 16-bit depth, i.e. "video=allegro/1024x768/5:5:5".

> Yes, I agree.  But, in order to not break PAR's that use video=, we will
> still need to map those function keys to video modes.  OTOH, we could just
> ignore video= commands in PARs.  The problem that raises is that there are
> some images that are resolution dependent.

For the "video=SF5" case, we handle the existing mapping of function
keys to video modes but only via the default key mapping.  I never
liked the idea that someone else could customize their key mapping and
I'd get a different resolution image because I didn't have their map
of keys to video modes.  So just support the default key mapping for
backwards compatability and don't read the mapping file (or ignore the
mapping section of the fractint.cfg or wherever its stored, I forget).
This will give people who customized the mapping file an incentive to
use the new video format specification that isn't dependent on their
key mappings.

> Currently that is crudely done by recompiling.  I haven't taken a close look
> at how to switch from one device to another when both are memory resident.

I imagined that the total number of drivers available is decided at
compile time.  Since I started by working on the X11 driver, I didn't
get to the point where switching between drivers was something that I
tried.  However, I think the driver structure that I put together can
handle this.  In the code I wrote, you can see where I do a 'trick' of
having the first N bytes of the driver structures identical across all
drivers and drivers tack on their own private data at the end of this
structure.  This lets all code outside the driver treat the all
drivers the same, but inside each driver, a cast is used to make the
driver private data visible inside the driver-related code.

For X11 this is where things like the Display * pointer, and so-on get
stored.  I imagine that Allegro also has a few little bits of
configuration data that the driver needs -- opaque handles to
resources or whatnot.  The Allegro driver should follow a similar
pattern to the X11 code in how it stores this data.

To switch from one driver to another dynamically, you ask the existing
driver to shut itself down and clean up its private data.  (A
full-screen DirectX driver here would release the exclusive access to
the full-screen here, for instance.)  Then you ask the new driver to
initialize itself and allocate its private data.  The you set the
"current driver pointer" to point to the new driver's data block.

A driver can implement its driver+private data structure as a
statically allocated file-scope struct, provided it is careful about
how it uses the data block.  A driver could also implement things by
dynamically allocating the structure.  Everyone outside the driver
doesn't care because everything happens through a pointer no matter
how the block of data was allocated.


> It appears to me that the windows allowed by Allegro can also be arbitrarily
> sized.  Although you can run into a problem with the text being too small or
> off the edge of the window.

This could be useful.  I was wondering how to draw legible text in a
tiny video mode like 320x200.  Fractint deals with it by having a
hand-coded "font" bitmap that it copies into video memory, but when
you move to a framework, you have to wonder how the framework will
deal with these kinds of things.  Frankly I'm not too worried about
320x200 looking crappy :-)

> P.S.  If I don't respond to something you think is important it's probably
> because it went zinging over my head.  Please feel free to reiterate.

OK, well its probably best for you to ask me to repeat things you
don't understand, if any.  Otherwise if you don't comment on it I'll
assume you understood it all :-).  I don't mind re-explaining
something different or in more detail so don't be shy about asking.
--
<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.xmission.com/~legalize/who/>

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: Allegro port status
Date: 29 Jun 2000 17:54:22 -0600


In article <000901bfe210$aaca4500$0100a8c0@bananasenior>,
    "Jonathan Osuch" <[e-mail]>  writes:

> We can certainly address this.  Since Allegro does this for us behind the
> scenes, your input will be invaluable in setting this up.  I take it you are
> suggesting something along the lines of: video=1024x768x5x6x5x0
>
> Or, would it be cleaner to use a different command line, such as:
> video=1024x768 depth=5:6:5:0

I hadn't thought much about this recently.  On 29-Apr-1999, I wrote
the following (which can be had from the archives at
<ftp://ftp.xmission.com/pub/lists/fractdev/archive/>:

=====
    Date: Thu, 29 Apr 1999 19:55:01 -0600
      To: [e-mail]
    From: Phil McRevis <[e-mail]>
Reply-To: [e-mail]
   Organ: multi-cellular, biological
 Subject: driver characteristics
---------
Since Humberto brought up some specifics of drivers, I'll say a little
about how I'm implementing the driver harness.  Naturally we'll be
able to change the harness later.  The point is not to design some
end-all be-all graphics API.  The idea is just to get things going
incrementally.  Feel free to kibitz, if its a big issue, something can
be done now, but please consider this more of a 'status report' for
your information on what I'm doing, more than a design review where
I'm proposing the idea. :-)

Existing video mode glue logic in fractint is currently implemented in
select_video_mode().  It walks through the table stored in memory and
creates the scrollable display of available video modes.  When you
select a mode from the list (or by some other means like video=), then
the proper parameters are snatched out of the table and sent to the
assembly routine setvideomode (video.asm), which issues the
appropriate commands to the video card.

With the harness, select_video_mode() instead walks a list of drivers
and queries each driver about the modes supported by the driver.  It
then displays a scrolling list created from the driver responses.
When the user selects an item on the list, select_video_mode() calls
through the driver harness to set the video mode.

This means that when we get to the point of having all (or several) or
the drivers I list below, under win98 you could have the choice of
the same video modes supported by multiple drivers.  The video display
list might look like this:

key...driver...name.................xdot.ydot.color.comment.............
SF1   win32    GDI Surface          1024x768  5:6:5
SF2   directx  Windowed             1024x768  5:6:5
SF3   directx  Full Screen          1024x768  8     256 colors
SF4   directx  Full Screen          1024x768  5:6:5 16-bit RGB
SF5   directx  Full Screen          1024x768  5:5:5 15-bit RGB
SF6   opengl   Full Screen          1024x768  8     256 color indexed
SF7   opengl   Full Screen          1024x768  8:8:8 24-bit RGB

(This is an ASCII graphic mockup; not a screen dump.)

Xdot and ydot take on a subtle meaning in a windowed environment, but
window systemless drivers still need to be able to report device
dimensions.

The video parameter ('video=<key>') currently only specifies a function
key which is bound to a video mode.  It doesn't force a particular
video mode, just selects one from the key list.  If you want to write a
script or parameter file that uses a particular video mode, you have to
ensure the proper key assignment is setup first.  To set the function
key assignment you have to get into the fractint.cfg file.  Icky!

With the harness, the video parameter is updated to specify both the
driver and the desires video mode provided by the driver.  So you'd
say something like "video=directx/1024x768/8".  A new method for
binding the keys to video modes will have to be provided, as the old
method depended on fractint.cfg which is now specific to the fractint
driver.

But what about the stuff the fractint.cfg file did?  That's used by the
"fractint" driver (see blow) as input to decide what video modes it
lists when queried.

Some really random ideas:

should image and model formats (3D raytracing files, etc) be
    supported as compile-time modules like drivers?

should drivers be allowed to invoke the engine distinct from
    fractint's gui?  Is the engine a client of the driver, or is the
    driver a client of the engine?  Fractint is currently architected
    towards the latter.  Reversing the assumption would be difficult.

should 3D drivers subsume 2D functionality?
    Is there any reason you'd want to use ogl for 3D, but x11 for 2D?
    If not, then "x11" and "opengl" drivers will provide everything
    you need.  Select an "x11' driver video mode for 2D stuff and an
    "opengl" driver video mode for 3D stuff.  Fractint doesn't (yet)
    mix 2D and 3D rendering together.

Drivers
-------
display drivers I think should be done, in no particular order:
    "curses"
    possibly uses curses, but only has character I/O.
    Displays "pixels" using characters as similar to XaoS.
    Enumerate text vide modes (DOS) or screen sizes (curses?) to
        form "video modes" table.
    Works in DOS (pd curses) and unix (native curses).

    "fractint"
    port existing fractint assembly code to 32-bit flat model.
    Included is the native video and mouse support coded in
    assembly.

    "allegro"
    Uses Allegro library under DJGPP to enumerate video formats
    and provide video/mouse/sound support.

    "disk"
    Video modes contain list of standard image sizes and "custom",
    letting you set the size.

    "win32"
    text menus are displayed graphically somehow.
    graphics display native to GDI presented as video mode.
    Emulate other modes?  Only if someone desperate for it --
    directx would be the preferred solution!

    "directx"
    text menus are displayed using a regular win32 window on GDI
        surface, or as graphic text on graphics screen (driver
        option).
    graphics display is done through full-screen with DirectDraw.
    DirectDrawDevices enumerated by DDraw are the video modes.

    "direct3d"
    Same as directx, but uses D3D for 3D effects.

    "x11"
    Text menus are displayed graphically using X11.
    Available visuals on the screen are the video modes.

    "opengl"
    Same as X11, only OGL-capable visuals are video modes.
    Uses OGL for all pixel I/O and 3D.

like XaoS, more that one driver can be available, but only one driver
can be active at once in any given graphic window.
=====

So I think I was expecting that the old video mode specifications
would still be supported (they wouldn't contain /'s) and that the new
video specification would be a driver/resolution/depth argument, where
the depth would be stated to be sufficiently unique.  I think I prefer
R:G:B:A, with the letters replaced by the number of bits dedicated to
each color channel.  This disambiguates 5:5:5, 5:6:5, and 5:5:5:1
pixel formats for 16-bit depth, i.e. "video=allegro/1024x768/5:5:5".

> Yes, I agree.  But, in order to not break PAR's that use video=, we will
> still need to map those function keys to video modes.  OTOH, we could just
> ignore video= commands in PARs.  The problem that raises is that there are
> some images that are resolution dependent.

For the "video=SF5" case, we handle the existing mapping of function
keys to video modes but only via the default key mapping.  I never
liked the idea that someone else could customize their key mapping and
I'd get a different resolution image because I didn't have their map
of keys to video modes.  So just support the default key mapping for
backwards compatability and don't read the mapping file (or ignore the
mapping section of the fractint.cfg or wherever its stored, I forget).
This will give people who customized the mapping file an incentive to
use the new video format specification that isn't dependent on their
key mappings.

> Currently that is crudely done by recompiling.  I haven't taken a close look
> at how to switch from one device to another when both are memory resident.

I imagined that the total number of drivers available is decided at
compile time.  Since I started by working on the X11 driver, I didn't
get to the point where switching between drivers was something that I
tried.  However, I think the driver structure that I put together can
handle this.  In the code I wrote, you can see where I do a 'trick' of
having the first N bytes of the driver structures identical across all
drivers and drivers tack on their own private data at the end of this
structure.  This lets all code outside the driver treat the all
drivers the same, but inside each driver, a cast is used to make the
driver private data visible inside the driver-related code.

For X11 this is where things like the Display * pointer, and so-on get
stored.  I imagine that Allegro also has a few little bits of
configuration data that the driver needs -- opaque handles to
resources or whatnot.  The Allegro driver should follow a similar
pattern to the X11 code in how it stores this data.

To switch from one driver to another dynamically, you ask the existing
driver to shut itself down and clean up its private data.  (A
full-screen DirectX driver here would release the exclusive access to
the full-screen here, for instance.)  Then you ask the new driver to
initialize itself and allocate its private data.  The you set the
"current driver pointer" to point to the new driver's data block.

A driver can implement its driver+private data structure as a
statically allocated file-scope struct, provided it is careful about
how it uses the data block.  A driver could also implement things by
dynamically allocating the structure.  Everyone outside the driver
doesn't care because everything happens through a pointer no matter
how the block of data was allocated.


> It appears to me that the windows allowed by Allegro can also be arbitrarily
> sized.  Although you can run into a problem with the text being too small or
> off the edge of the window.

This could be useful.  I was wondering how to draw legible text in a
tiny video mode like 320x200.  Fractint deals with it by having a
hand-coded "font" bitmap that it copies into video memory, but when
you move to a framework, you have to wonder how the framework will
deal with these kinds of things.  Frankly I'm not too worried about
320x200 looking crappy :-)

> P.S.  If I don't respond to something you think is important it's probably
> because it went zinging over my head.  Please feel free to reiterate.

OK, well its probably best for you to ask me to repeat things you
don't understand, if any.  Otherwise if you don't comment on it I'll
assume you understood it all :-).  I don't mind re-explaining
something different or in more detail so don't be shy about asking.
--
<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.xmission.com/~legalize/who/>

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: Allegro port status
Date: 29 Jun 2000 20:37:31 -0500

Rich,

> The Allegro driver should follow a similar
> pattern to the X11 code in how it stores this data.

Yes, it does.  I started by copying your X11 file and then changed things
over to Allegro specific.  I still need to clean up the extra variables.  I
believe, in my version, the disk video and X11 drivers are broken.  I'll fix
them.

Now I see how we will switch between drivers.  However, what do we do on
initial startup, ie. no video= statement in sstools.ini?  The program flow
has been slightly altered in Xfractint because a video mode has to be
selected (window opened) before text can be displayed.  We need to use a
default driver to display the initial selection of drivers.  The disk video
mode would be appropriate, but is it going to change from Allegro to W32,
etc.?  Are we going to end up with multiple disk video drivers?

> OK, well its probably best for you to ask me to repeat things you
> don't understand, if any.  Otherwise if you don't comment on it I'll
> assume you understood it all :-).  I don't mind re-explaining
> something different or in more detail so don't be shy about asking.

Okay, here goes.  Your description of how to implement an event-driven
architecture has baffled me.  Not the basics, but how to use it in Fractint.
What I would like to do, but don't know how, is to start up the event
handler and then start the fractal engine and the plotting engine as
children.  The data would be sent from the fractal engine to the plotting
engine to be plotted on the screen.

Another thing that I'd like to know is the proper way to give time slices
back to the operating system when the calculation is done.  This isn't from
any of your comments, just something I'd like to know.

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: Allegro port status
Date: 30 Jun 2000 20:12:37 -0600


Did anyone else get two copies of my last message?  Sorry if I sent
two by mistake, I seem to have received two.

In article <001b01bfe237$86805820$0100a8c0@bananasenior>,
    "Jonathan Osuch" <[e-mail]>  writes:

> Now I see how we will switch between drivers.  However, what do we do on
> initial startup, ie. no video= statement in sstools.ini?

My thoughts on this were: it depends on the platform.  Each "platform
port" of fractint should select a lowest-common denominator video mode
that is the most likely to be present or even better guaranteed to
be present.  For X11 this means the default visual on the default
display; for Win32 it means a Win32 GDI window on the desktop; I am
not sure what Allegro would use for its default, but I'm betting that
you do.

> [...] the initial selection of drivers.  The disk video
> mode would be appropriate,

I was thinking that disk video mode would only be appropriate for the
DOS code.  Here, "DOS" would be a platform distinct from Win32.  So
the author of the "DOS" port would make the default driver the disk
video mode driver.

> [The disk video mode] but is it going to change from Allegro to W32,
> etc.?  Are we going to end up with multiple disk video drivers?

I think disk video mode should be platform and driver agnostic.  Disk
video should be a portable software interface to a memory buffer as the
video "device" and not depend on Win32 or any other driver or platform
specific code.  The existing disk video mode code can be drawn into
that driver.  (I think I did that for d_disk.c in the re-org of the
code I put up).

That brings up the question of what a disk video mode uses for text I/O
of menus and the like.  If you restrict yourself to the text I/O
currently in fractint with its menu routines then everything will boil
down to the few driver calls relating to text I/O.  From there the
driver can take the text and display it using whatever method is
appropriate for the platform.

I was thinking perhaps the most portable thing to do is to use curses.
Curses libraries for MS-DOS exist and should be pretty well debugged at
this point.  Curses is well supported for unix as well.  Is it on the
mac?  Frankly, I can't see the point of making a curses-based disk
video driver for the Mac; just use the Mac toolbox.  On the other
hand, nothing fancier than a DMI DOS application that just used
character I/O for status reporting could run on just about any old
computer DOS-wise as a "dumb render farm".  It wouldn't even need
VGA.

> Okay, here goes.  Your description of how to implement an event-driven
> architecture has baffled me.  Not the basics, but how to use it in Fractint.

OK, I'm looking at ant.c right now.  I'll restructure ant.c according
to the schema I advocated in an earlier message, that should make
things concrete.  I'll post it in a separate message.

> What I would like to do, but don't know how, is to start up the event
> handler and then start the fractal engine and the plotting engine as
> children.

I see two choices here: threads or idle processing.

With threads, you can start a separate thread of control executing
through the code which can simplify the implementation and readability
of the code.  On Win32 and *nix both have threads, and so does the Mac
I believe.  For threads, that leaves DOS as an unknown; I believe I've
seen "thread" implementation libraries for DOS, but I've never
investigated them in any great detail.  Perhaps someone else knows
about thread support for DOS.  A Win32 console program can use threads,
but that's not the same as a PMI DOS executable.

With idle processing, the program maintains a flag that it is doing
background processing while also receiving input from the system.  In
fractint currently, each local routine looking for input while doing
processing has its own copy of the logic to look for input interspersed
with doing bits of computation.  Each routine "polls" or checks the
state of the input buffer for mouse and keyboard events while in the
middle of a long processing loop.  (I think the mouse event code got
hidden inside the keyboard checking code!)

Idle processing keeps everything going by checking for input while
processing is occuring.  The processing continues so long as there is
no input available.  When input does become available, the idle
processing loop either stops (like when you press ESC) or switches to
an input processing loop like that contained in the text menu code.
Depending on the area of fractint, the idle processing may continue
after the text menu returns control back to its caller.

> The data would be sent from the fractal engine to the plotting
> engine to be plotted on the screen.

Or rather a pointer to the data, or an agreed upon global buffer.  No
need to copy around lots of data :-).

> Another thing that I'd like to know is the proper way to give time slices
> back to the operating system when the calculation is done.

With threads, the one or more computation threads go into a wait state,
waiting to be woken up and signalled that there is more work to do
(points to plot with the fractal function, pixels to draw).

With idle processing you simply toggle the flag that indicates work to
be done during idle states when the program would otherwise be blocked
waiting for a key press or mouse event.  Since there is no background
work to be done, the idle processing variation can just issue the
blocking I/O call since fractint's data processing is always driven by
input, whether from the keyboard or a file.

--
<http://www.xmission.com/~legalize/>    Legalize Adulthood!
    ``Ain't it funny that they all fire the pistol,
      at the wrong end of the race?''--PDBT
[e-mail]    <http://www.xmission.com/~legalize/who/>

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: ant.c example
Date: 30 Jun 2000 21:12:07 -0600

Existing ant.c routine TurkMite1 which does ant simulation processing
until ESC is pressed or the number of desired points are plotted.
TurkMite1 is called by ant(), which is called by the main input
processing loop in framain2.c. (look for case 1: /* ^a Ant */)

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

void
TurkMite1(int maxtur, int rule_len, char *ru, long maxpts, long wait)
{
   int color, ix, iy, idir, pixel, i;
   int kbdchar, step, antwrap;
   int x[MAX_ANTS + 1], y[MAX_ANTS + 1];
   int next_col[MAX_ANTS + 1], rule[MAX_ANTS + 1], dir[MAX_ANTS + 1];
   long count;

   /*-=-=-=-=- long block of setup code elided -=-=-=-=-*/

   maxpts = maxpts / (long) INNER_LOOP;
   for (count = 0; count < maxpts; count++)
   {
      /* check for a key only every inner_loop times */
      kbdchar = keypressed();
      if (kbdchar || step)
      {
         int done = 0;
         if (kbdchar == 0)
            kbdchar = getakey();
         switch (kbdchar)
         {
         case SPACE:
            step = 1 - step;
            break;
         case ESC:
            done = 1;
            break;
         case RIGHT_ARROW:    case UP_ARROW:
     case DOWN_ARROW:    case LEFT_ARROW:
     case RIGHT_ARROW_2:    case UP_ARROW_2:
         case DOWN_ARROW_2:    case LEFT_ARROW_2:
       setwait(&wait);
            break;
         default:
            done = 1;
            break;
         }
         if (done)
            goto exit_ant;
         if (keypressed())
            getakey();
      }
      for (i = INNER_LOOP; i; i--)
      {
    /* -=-=- inner loop of ant processing omitted; no I/O here -=-=- */
      }
   }
exit_ant:
   return;
}

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


so what we have here in pseudocode is:

big_while_loop():
initializes big while loop state
loops forever
    get input and call main_menu_switch()

    main_menu_switch():
    parses input and calls ant()

        ant():
        ant() calls TurkMite1()

        TurkMite1():
        initialize local ant state
        for each point to be plotted
            if key pressed
            if ESC pressed
                return
            else
                process input locally
            endif
            endif
            do increment of work using ant state
        endfor
done
cleanup

So what we have inside this "calculation" is some exit logic (if ESC
pressed), some input processing logic, and some incrmental work to be
done.

Every routine that handles keyboard input in fractint is like this,
except that some of them don't have incremental background processing
they could do while waiting for input, so they just block waiting for
input.  The text menu routines are an example of that kind of input
processing.

Most "background processing" routines continue working until a key is
pressed and then they return control to a menu or their caller (such
as what TurkMite1 does when you are running the ant simulation and
press ESC, returning control to the main fractal routine which
processes the ESC as a signal to throw up the main menu).

Under an event processing organization, you would localize all the
event processing to the main routine.  In Win32 this is the main
message pump loop implemented with the usual GetMessage() and
DispatchMessage().  In X11 its the event loop implemented around
XNextEvent() and XtNextEvent().  The Mac has its own event loop
processing routines as well.  In pseudocode, it looks more like this:

"idle processing style"
big_while_loop():
initializes
quit = false
while (!quit)
    if (event)
    get event
    if (quit event)
        quit = true
    else
        dispatch event to input sink:
        if (keymap[input key])
            call handler through (*keymap[input key])()

            handler for ^A on main menu (evolution of
            main_menu_switch):
            set idle routine to ant idle routine
            set idle state data to new ant idle state

        endif
    endif
    else if (idle routine)
    call idle routine with idle state data
    if (idle routine done processing)
        reset idle routine
        reset idle state data
    endif
    endif
done
cleanup

"threads style"

GUI thread:                    worker thread:

big_while_loop():                initialize
initializes                    while (!quit)
create worker thread                    obtain work item
                            do incremental work
quit = false                    done
while (!quit)                    cleanup
    if (event)
    get event
    if (quit event)
        quit = true
    else
        dispatch event to input sink
    endif
    endif
done
wait for worker threads
cleanup

The big difference between the two styles is that the single event
loop construction means you have to store intermediate data that is
communicated from one incremental work step to the next available
through a pointer or global variable.  So that means that the local
variables and local state initialized in TurkMite1() would have to be
stored in a piece of memory to be passed to each successive invocation
of the incremental work procedure that replaces TurkMite1 in the event
scheme.

By localizing the event mechanism to one place it becomes reasonable
to replace it with other event mechanisms such as event dispatching
under MFC, Win32 dialogs with their own message procs, Motif/Xt event
dispatching, and so-on.  This will allow fractint to eventually evolve
in the direction of a professional "Mac look and feel" interface
coexisting on the same code base as a professional "Win2000 look and
feel" interface.

This is my hope for fractint -- that it can evolve to having
professional looking interfaces native to the platform.  It may or may
not be possible.  Or it may be too much work and it may be easier to
evolve the current event processing in the keyboard code.  For now its
probably easier to just get the existing stuff working with the driver
interface rather than undertake so large a code change.  The driver
was a big enough change as it was and that already consumed my time
and passed on to someone else :-)
--
<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.xmission.com/~legalize/who/>

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"