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

Internet Message Format | 1999-04-29 | 44KB

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


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




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

Date: Thu, 29 Apr 1999 21:16:20 -0300 (EST)
From: Humberto Rossetti Baptista <[e-mail]>
Subject: Porting Fractint (was Re: (fractdev) DOS support via allegro?)

    Hi All,

    Good to the the list moving :-)

    "Phil" I've browsed in to the XaoS code (alnd I wrote the author for
more info but haven't got an answer yet). It uses a nice approach to isolate
OS-specifica prats from the main program, what makes porting easy if the C style
isn't plataform specific or makes assumptions on sizeof things etc.

    I have managed to compile hc (and it works) and fractint (it does not
work yet) qith DJGPP and I was writing a small quick intro to those that want to
experiment with DJGPP. I'll post it to the list as it is fairly small.

    If we can use a similar approach: an API to handel OS-specific stuff I
guess the rest of the problem would be clean the code from plataform assumtions
and we could have Fractint running in several platforms (like XaoS for
instance).

    []'s

    Humberto R. Baptista
    [e-mail]

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

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



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

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

Date: Thu, 29 Apr 1999 21:18:52 -0300 (EST)
From: Humberto Rossetti Baptista <[e-mail]>
Subject: (fractdev) Preliminar DJGPP howto :-))

HOWTO work with GCC in DOS - for the Fractint Devel Team

1. Getting the Tools

    Go to DJGPP (Delorie's GCC port to DOS)

    http://www.delorie.com/djgpp/

    And select the /Zip Picker/ there choose your preferred SimTel
mirror and pick (at least) the options:

    -Build and run programs with DJGPP
    -<your operating system>
    -<documentation if you do not use emacs/rhide>
    -C
    -RHide <recommended> or Emacs <for those used to it>
    -<gdb if not using RHide>
    -Allegro Toolkit
    -GRX

    And download the files.

2. Install

    From the result of /Zip Picker/:
"
You need to update your C:\AUTOEXEC.BAT to include the following lines:

set PATH=C:\DJGPP\BIN;%PATH%
set DJGPP=C:\DJGPP\DJGPP.ENV

Note that the PATH statement should follow any other PATH statements, or you may
edit an existing PATH
statement.

You'll need to restart your computer for these changes to take effect.
"

3. Build and test Allegro & GRX

    Go to the allegro directory:

    c:
        cd \DJGPP\ALLEGRO

    and make all files:

    make

    This should produce all binaries using your newlyn installed
DJGPP and all the examples too, do a CD EXAMPLES and experiment with all
the examples: ex*.exe Some of them will give good implementations ideas
besides showing what allegro can do.

    []'s

    HB


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

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

Date: Thu, 29 Apr 1999 18:19:38 -0600
From: Phil McRevis <[e-mail]>
Subject: Re: Porting Fractint (was Re: (fractdev) DOS support via allegro?)

Humberto, if you're also working on DJGPP issues, that would be great
to coordinate.  My primary development platform is Borland C++ tools
on the PC.  I have downloaded djgpp but haven't installed it from the
zips yet.

In article <[e-mail]>,
    Humberto Rossetti Baptista <[e-mail]>  writes:
> If we can use a similar approach: an API to handel OS-specific stuff I
> guess the rest of the problem would be clean the code from plataform
> assumtions
> and we could have Fractint running in several platforms (like XaoS for
> instance).

That's the idea exactly.  I've outlined what I see (so far) as the OS
specific issues in another message.
- --
<http://www.xmission.com/~legalize/>    Legalize Adulthood!
    ``Ain't it funny that they all fire the pistol,
      at the wrong end of the race?''--PDBT
[e-mail]    <http://www.eden.com/~thewho>

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

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

Date: Thu, 29 Apr 1999 21:29:55 -0300 (EST)
From: Humberto Rossetti Baptista <[e-mail]>
Subject: Re: (fractdev) portability thoughts

On Thu, 29 Apr 1999, Phil McRevis wrote:

>     memory allocation
>     memory "models"
>     virtual memory: mmap vs. home-brew file I/O cache
>
> Memory models disappear completely when dealing with a DPMI extender
> port.

    Yep.

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

    The "extender" used to put a app in flat mode (32 bit) in DOS and the
DPMI server should handle ALL memory stuff. Other platforms do this nicely
(linux for instance) so we shoud invest as little as possible in this. As the
DPMI + extender do this for uss let's not mess more with overlays, memory
models and disk caching strats.

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

    As of now fractint does not need to handle them except in specific
platforms (unix) so we could leave them to be dealt with later.

>     compilation issues / portability / assembler

    I was converned w/ the assembly part of fractint, but is easy to avoid
it completly as the Xfractint code already does. As tim pointed out this is the
way we should go: Make Xfractint more portable, maybe running in DOS and Linux
and then clean things up.

>     autoconf

    I've never dealt w/ autoconf in the developpers role, but I  am seing a
lot of stuff here that isn't essential to put things up and running in a
portable manner.

> The arbitrary precision arithmetic routines used by fractint aren't
> portable to non-x86 platforms.  However, the gmp (GNU multiple

    Why not? I havent checked this myself but if I recall right it has a
nice C version of everything that is MP related. Tim?

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

    Yesssss. And also I think gmp is C++ isnt' it?

    Humberto R. Baptista
    [e-mail]

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

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



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

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

Date: Thu, 29 Apr 1999 21:37:20 -0300 (EST)
From: Humberto Rossetti Baptista <[e-mail]>
Subject: (fractdev) Porting fractint strategies (32bit flat mem. model etc.)

    List,

    I wish to help a little with some simple suggestions to all that are
thinking/working with the portability issue:

    a) let's release a "last" 16 bit versino ASAP (Tim?) and feature freeze
it (just correct bugs).

    b) Let's concentrate in put up a version running in DJGPP/DOS (or
gcc/Linux, wichever has the larger number of developpers willing to help) with
the LEAST modiffications needed. I think this should be done in the api manner
XaoS does as "Phil" pointed, but without adding to much fuzz to the process and
then
    c) Hunt down all others platform-centric issues and remove historic code
(that wont'be used any more) together with:

    d) work on the low level drivers to several platforms (using the API) to
spread the Fractint development further more.

    The b) item seems like a bottleneck point to me, that's why i'm
insisting in the simplicity approach :-)

    After it is done we can work in paralell, cleaning code, porting, and
(of COURSE) coding new stuff for Fractint :->>>

    []'s

    Humberto R. Baptista
    [e-mail]

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

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



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

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

Date: Thu, 29 Apr 1999 21:46:19 -0300 (EST)
From: Humberto Rossetti Baptista <[e-mail]>
Subject: Re: Porting Fractint (was Re: (fractdev) DOS support via allegro?)

On Thu, 29 Apr 1999, Phil McRevis wrote:

> Humberto, if you're also working on DJGPP issues, that would be great
> to coordinate.  My primary development platform is Borland C++ tools
> on the PC.  I have downloaded djgpp but haven't installed it from the
> zips yet.

    Frankly I've been using Borland tools anlo and just recently downloaded
the djgpp (and Allegro and rhide a nice IDE for DJGPP, very similar to
borland's) and it is GREAT. Works very well.

    See if my draft of DJGPP howto helps! :-))))) (it's already posted).

> That's the idea exactly.  I've outlined what I see (so far) as the OS
> specific issues in another message.

    Speaking of "echo" :-)

    Right I've read it and I think I've being doing it wrong in not sharing
the experiences with the list, so all of you jus cope w/ me while I compensate
for that :-)

    XaoS approach to the platform-api is to put all variables and function
adresess specifict to that platform in a big struct and go for it. I am thinking
if we should do the same or if there would be any gain to slpit the api in
several areas (for instance graphics, sound, mice/keyboard, disk related etc.)
What do you think??

    []'s

    Humberto R. Baptista
    [e-mail]

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

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



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

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

Date: Thu, 29 Apr 1999 18:50:31 -0600
From: Phil McRevis <[e-mail]>
Subject: Re: (fractdev) portability thoughts

In article <[e-mail]>,
    Humberto Rossetti Baptista <[e-mail]>  writes:
>     I've never dealt w/ autoconf in the developpers role, but I  am seing a
> lot of stuff here that isn't essential to put things up and running in a
> portable manner.

What things are you seeing that aren't essential?  All the things I
listed are portability issues.

> > The arbitrary precision arithmetic routines used by fractint aren't
> > portable to non-x86 platforms.  However, the gmp (GNU multiple
>
>     Why not? I havent checked this myself but if I recall right it has a
> nice C version of everything that is MP related. Tim?

Some low-level stuff is written in assembly, see bigflta.asm and
bignuma.asm.  Poking around a little more, it looks like bigfltc.c
implements C versions of the assembly routines.  As I say, I consider
switching to gmp to be a very low-priority item, i.e. one of
optimization not one of correctness.  You want to do it eventually to
get fast MP support on more than just x86 DOS platforms.  (Even x86
linux can't take advantage of the x86 assembly for fractint's MP math
since the assembly is 16-bit!)

>     Yesssss. And also I think gmp is C++ isnt' it?

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

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

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

Date: Thu, 29 Apr 1999 18:53:51 -0600
From: Phil McRevis <[e-mail]>
Subject: Re: (fractdev) Porting fractint strategies (32bit flat mem. model etc.)

Humberto, what you propose is exactly inline with my thinking.  I'm
already signed up for the "driver harness" a la XaoS and adjusting the
existing xfract code to use the harness.  Then I'll remove all memory
model stuff.  That should serve as the starting point for whoever adds
display driver support back in for the DOS DJGPP side of things.
There are places where parallel developers can work without bumping
into each other (different display driver implementations), but its
probably best to have just one person overhaul the central control
logic and associated glue to the driver.  We've kinda talked about
this forever so I just got sick of talking about it and I'm doing it.
:-)
- --
<http://www.xmission.com/~legalize/>    Legalize Adulthood!
    ``Ain't it funny that they all fire the pistol,
      at the wrong end of the race?''--PDBT
[e-mail]    <http://www.eden.com/~thewho>

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

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

Date: Thu, 29 Apr 1999 19:03:41 -0600
From: Phil McRevis <[e-mail]>
Subject: Re: Porting Fractint (was Re: (fractdev) DOS support via allegro?)

In article <[e-mail]>,
    Humberto Rossetti Baptista <[e-mail]>  writes:
>     XaoS approach to the platform-api is to put all variables and function
> adresess specifict to that platform in a big struct and go for it. I am think
ing
> if we should do the same or if there would be any gain to slpit the api in
> several areas (for instance graphics, sound, mice/keyboard, disk related etc.
)
> What do you think??

I'm thinking that the driver keeps private any data that it needs only
to get its job done.  Under X11, that means things like pixel lookup
tables, dynamically allocated X resources (windows, pixmaps,
colormaps, GCs, etc.) and so-on.  These are visible only to the
driver.

Then there is a collection of stuff that is supplied to fractint for
handling the video driver support.  This is basically an array of
structures that define video mode characteristics.  Currently this
collection of settings is couched in very PC-centric terms, right down
to the interrupt call arguments!

That basic idea would remain the same with display drivers, however.
What changes is the control logic that initializes the table at
program startup-time (and possibly updating it during runtime).  Right
now the table is created from fractint.cfg as a fixed list.  Some of
the data currently stored in the table (like PC interrupt arguments)
becomes private data of the driver.  The rest remains relevant as a
result from a driver when its queried from fractint.
- --
<http://www.xmission.com/~legalize/>    Legalize Adulthood!
    ``Ain't it funny that they all fire the pistol,
      at the wrong end of the race?''--PDBT
[e-mail]    <http://www.eden.com/~thewho>

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

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

Date: Thu, 29 Apr 1999 22:06:12 -0300 (EST)
From: Humberto Rossetti Baptista <[e-mail]>
Subject: Re: (fractdev) Porting fractint strategies (32bit flat mem. model etc.)

On Thu, 29 Apr 1999, Phil McRevis wrote:

> Humberto, what you propose is exactly inline with my thinking.  I'm

    excelent.

> probably best to have just one person overhaul the central control
> logic and associated glue to the driver.  We've kinda talked about

    This is exatcly why i called this a bottleneck.

> this forever so I just got sick of talking about it and I'm doing it.
> :-)

    Cool. I do not have a lot of time spare right now, but if you need any
help just say so. PS: got the DJGPP howto?

    []'s

    Humberto R. Baptista
    [e-mail]

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

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



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

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

Date: Thu, 29 Apr 1999 22:18:19 -0300 (EST)
From: Humberto Rossetti Baptista <[e-mail]>
Subject: Re: (fractdev) portability thoughts

On Thu, 29 Apr 1999, Phil McRevis wrote:

> What things are you seeing that aren't essential?  All the things I
> listed are portability issues.

    Yes, but you have already pointed that some are less priority than
others :-)

    Also some things are not done properly but are done like the handling of
\ and / (i guess it is in port.h as several other stuff like data types are also
defined).

    []'s

    Humberto R. Baptista
    [e-mail]

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

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



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

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

Date: Thu, 29 Apr 1999 20:27:53 -0500
From: "Damien M. Jones" <[e-mail]>
Subject: Re: (fractdev) C++ templates and generic programming and fractint! :)

Rich,

 - Ah, but here you're using the inheritence/OOness of C++ to exploit
 - reuse.  The generic programming/template model, as embodied by the STL
 - for example, is really quite a different kind of reuse than that
 - provided by class hierarchies.

My mistake, I thought you were referring to inheritance with different
terminology, and not the STL. You're right, that IS different. And yes, I
was using inheritance to exploit reuse.

Damien M. Jones   \\
[e-mail]  \\  Fractalus Galleries & Info:
                    \\  http://www.fractalus.com/

Please do not post my e-mail address on a web site or
in a newsgroup.  Thank you.

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

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

Date: Thu, 29 Apr 1999 19:55:01 -0600
From: Phil McRevis <[e-mail]>
Subject: (fractdev) 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.

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

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

Date: Thu, 29 Apr 1999 23:44:47 -0300 (EST)
From: Humberto Rossetti Baptista <[e-mail]>
Subject: Re: (fractdev) driver characteristics

On Thu, 29 Apr 1999, Phil McRevis wrote:

[... description of select_video_mode]

    Just to clear things for me: are you taking for a staring point the
fractint or the xfractint code (the 2 are the same, but w/ different #defines )

[... harnessing the video mode]
> 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.

    That is very nice. Seems ok, but in one given platform there will be all
the drivers to all the platforms or just the ones concerning that one platform?

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

    That is also a nice idea.
[...]

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

    I guess this is aalib ?? It is not curses but i guess if could be seen
as though it is.

    Wouldn't it be interesting to abandon the text mode completly and user
the graphic mode for messages also? This could lead with work and time to an
uniform fractint gui look all across different platforms.

    []'s

    Humberto R. Baptista
    [e-mail]

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

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



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

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

Date: Thu, 29 Apr 1999 21:15:56 -0600
From: Phil McRevis <[e-mail]>
Subject: Re: (fractdev) driver characteristics

In article <[e-mail]>,
    Humberto Rossetti Baptista <[e-mail]>  writes:
>     Just to clear things for me: are you taking for a staring point the
> fractint or the xfractint code (the 2 are the same, but w/ different #defines
 )

The answer to your question is yes and no. :-)

I'm using xfractint 19.61 pl66 code.  The differences between xfractint
19.61 pl66 and fractint 19.61 pl66 are the inclusion of assembly files
on the fractint side, with corresponding .c files on the xfractint
side.  For instance, here's the source in my xfractint directory
(datafiles removed for clarity):

    3d.c          end1.c        hc*           lsys.h        rotate.c
                  evolve.c      hc.c          lsysf.c       slideshw.c
                  externs.h     hcmplx.c      makefile      soi.c
    ant.c         f16.c         help.c        memory.c      soi1.c
    big.h         file_id.diz   help.src      miscfrac.c    stereo.c
    bigflt.c      fpu087.c      help2.src     miscovl.c     targa.c
    biginit.c     frachelp.mak  help3.src     miscres.c     targa.h
    biginit.h     fracsuba.c    help4.src     mpmath.h      targa_lc.h
    bignum.c      fracsubr.c    help5.src     mpmath_c.c    testpt.c
    bignumc.c     fractalb.c    helpcom.h     parser.c      tgaview.c
    bigport.h     fractalp.c    helpdefs.h    parserfp.c    tplus.c
    calcfrac.c    fractals.c    intro.c       plot3d.c      tplus.h
    calcmand.c    fractint.c    jb.c          port.h        tplus_a.c
    calmanfp.c    fractint.h    jiim.c        port.new      tru.c
    cmdfiles.c    fractint.ifs  line3d.c      printer.c     unix.c
    cmplx.h       fractype.h    loadfdos.c    prompts1.c    unix.h
    decoder.c     framain2.c    loadfile.c    prompts2.c    unixscr.c
    diskvid.c     frasetup.c    loadmap.c     prototyp.h    video.c
    diskvidu.c                  lorenz.c      read.me       yourvid.c
    editpal.c     general.c     lsys.c        realdos.c     zoom.c
    encoder.c     gifview.c

And here's fractint 19.61 source:

    3d.c          calmanfp.asm  fractint.h    loadfile.c    port.h
                  cmdfiles.c    fractint.mak  loadmap.c     printer.c
    ant.c         cmplx.h       fractype.h    lorenz.c      prompts1.c
    bcauto.bat    decoder.c     framain2.c    lsys.c        prompts2.c
    bcfract.bat   diskvid.c     frasetup.c    lsys.h        prototyp.h
    bcfract.cfg   editpal.c     general.asm   lsysa.asm     realdos.c
    bcfract.mak   encoder.c     gifview.c     lsysaf.asm    rotate.c
    bcfract2.cfg  externs.h     hc.c          lsysf.c       slideshw.c
    bclinkf.bat   f16.c         hcmplx.c      lyapunov.asm  stereo.c
    bcmakall.bat  fmath.h       help.c        makefrac.bat  targa.c
    bigflt.c      fpu087.asm    help.src      miscfrac.c    targa.h
    bigflt.h      fpu387.asm    help2.src     miscovl.c     targa_lc.h
    bigflta.asm   fr8514a.asm   help3.src     miscres.c     testpt.c
    bigfltc.c     frachelp.mak  help4.src     mpmath.h      tgaview.c
    biginit.c     fracsuba.asm  help5.src     mpmath_a.asm  tplus.c
    biginit.h     fracsubr.c    helpcom.h     mpmath_c.c    tplus.dat
    bignum.c      fractalb.c    hgcfra.asm    newton.asm    tplus.h
    bignum.h      fractalp.c    intro.c       parser.c      tplus_a.asm
    bignuma.asm   fractals.c    jb.c          parsera.asm   video.asm
    bignumc.c     fractint.c    jiim.c        parserfp.c    yourvid.c
    calcfrac.c    fractint.cfg  line3d.c      plot3d.c      zoom.c
    calcmand.asm  fractint.def  loadfdos.c

I think the makefiles are also different; otherwise they share
all the same .h and .c source with #ifdef XFRACT in the few places
where it matters.

The driver harness goes in some of the places where XFRACT is
currently used.  Then fractint and xfractint will be using the same
source with even fewer #ifdef XFRACT's sprinkled around the code.

>That is very nice. Seems ok, but in one given platform there will be all
> the drivers to all the platforms or just the ones concerning that one
>platform?

Its identical to what XaoS does.  (XaoS uses autoconf)  The configure
script probes the compilation system to determine what features are
available.  configure determines what drivers will be available at
runtime.  Alternatively, you can set #defines in your build process to
attempt to compile support for a particular driver.  Of course,
someone will have to implement the driver before it can be compiled
:-).

> > 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.
>
>     I guess this is aalib ?? It is not curses but i guess if could be seen
> as though it is.

Umm... oh yeah, I think I looked at aalib, which is a full-blown 2D
graphics package that renders to text.  Kinda cool, but no its not
necessarily to use something that fancy for a curses driver.  Fractint
really doesn't need anything more fancy than getpixel and putpixel for
graphics it turns out.

Amazingly modular... I'm surprised more people didn't just assume they
could bcopy() indices straight onto the display.

>     Wouldn't it be interesting to abandon the text mode completly and user
> the graphic mode for messages also? This could lead with work and time to an
> uniform fractint gui look all across different platforms.

What I suggested for the window system drivers is that they do exactly
that.  Curses may or may not be available on the system (system
dependency).  But a window system driver has the capacity to draw text
into its window directly.  It doesn't need curses to draw text.  In
fake, it gets more complicated (to me anyway) to have curses doing
text and X11 doing 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"

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

Date: Thu, 29 Apr 1999 21:21:21 -0600
From: Phil McRevis <[e-mail]>
Subject: (fractdev) the credits screen

Tim, the credits screen just smacked me in the face like a conceptual
ton of bricks.  The stone soup tradition of fractint is more than just
a concept of open source software, its the cumulative non-violent
cooperative effort of all those *people* in the credits screen.

I know on some of the other fractal lists there's been heated debate
about fractint's open source tradition vs. the new kids on the block.
:-).  But I couldn't think of another program that starts up with a
credits screen, the way a good action movie blasts the credits up
quick in the beginning so that you can be on the edge of your seat for
the entire ride.  Sure, lots of programs have about boxes and thanks
lists and so on.  But of all the open source software I use, I
couldn't think of one that embodies the stone soup tradition of mutual
cooperation more than fractint.
- --
<http://www.xmission.com/~legalize/>    Legalize Adulthood!
    ``Ain't it funny that they all fire the pistol,
      at the wrong end of the race?''--PDBT
          <http://www.eden.com/~thewho>

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

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

Date: Thu, 29 Apr 1999 23:32:15 -0600
From: Phil McRevis <[e-mail]>
Subject: (fractdev) 'xfractint makedoc' segfaults around page 220

Has anyone else seen this?  It chunks away seemingly normally for about
222 pages in Appendix H when it crashes with a seg fault.

Program received signal SIGSEGV, Segmentation fault.
0x98294 in printerc (info=0xeffff0d8, c=12, n=0) at help.c:1113
(gdb) where
#0  0x98294 in printerc (info=0xeffff0d8, c=12, n=0) at help.c:1113
#1  0x98acc in print_doc_output (cmd=1, pd=0xeffff008, info=0xeffff0d8)
    at help.c:1254
#2  0x944c4 in process_document (get_info=0x9848c <print_doc_get_info>,
    output=0x98808 <print_doc_output>, info=0xeffff0d8) at helpcom.h:459
#3  0x99100 in print_document (
    outfname=0x756d6d61 <Address 0x756d6d61 out of bounds>,
    msg_func=0x7279206f <_end+42538935>, save_extraseg=1713391218)
    at help.c:1403
#4  0x52498 in cmdarg (curarg=Cannot access memory at address 0x230044.
) at cmdfiles.c:1158
Cannot access memory at address 0x230038.
(gdb) l help.c 1110
Junk at end of line specification.
(gdb) l "help.c":1110
No source file named "help.c".
(gdb) l help.c:1110
1105          {
1106          if (c==' ')
1107             ++info->spaces;
1108
1109          else if (c=='\n' || c=='\f')
1110             {
1111             info->start_of_line = 1;
1112             info->spaces = 0;   /* strip spaces before a new-line */
1113             putc(c, info->file);
1114             }
#1  0x98acc in print_doc_output (cmd=1, pd=0xeffff008, info=0xeffff0d8)
    at help.c:1254
(gdb) l
1249             return ( keep_going );
1250             }
1251
1252          case PD_FOOTING:
1253             info->margin = 0;
1254             printerc(info, '\f', 1);
1255             info->margin = PAGE_INDENT;
1256             return (1);
1257
1258          case PD_PRINT:
#2  0x944c4 in process_document (get_info=0x9848c <print_doc_get_info>,
    output=0x98808 <print_doc_output>, info=0xeffff0d8) at helpcom.h:459
(gdb) l
454          if ( !output(PD_START_SECTION, &pd, info) )
455             return (0);
456
457          if ( pd.new_page && pd.lnum != 0 )
458             {
459             if ( !output(PD_FOOTING, &pd, info) )
460                return (0);
461             ++pd.pnum;
462             pd.lnum = 0;
463             if ( !output(PD_HEADING, &pd, info) )
#3  0x99100 in print_document (
    outfname=0x756d6d61 <Address 0x756d6d61 out of bounds>,
    msg_func=0x7279206f <_end+42538935>, save_extraseg=1713391218)
    at help.c:1403
(gdb) l
1398
1399       info.margin = PAGE_INDENT;
1400       info.start_of_line = 1;
1401       info.spaces = 0;
1402
1403       success = process_document((PD_FUNC)print_doc_get_info,
1404                                  (PD_FUNC)print_doc_output,   &info);
1405       fclose(info.file);
1406
1407       if ( save_extraseg )
#4  0x52498 in cmdarg (curarg=Cannot access memory at address 0x230044.
) at cmdfiles.c:1158
(gdb) l
1153             escape_exit = yesnoval[0];
1154             return 3;
1155             }
1156
1157          if (far_strcmp(variable,s_makedoc) == 0) {
1158             print_document(*value ? value : "fractint.doc", makedoc_msg_func, 0);
1159    #ifndef WINFRACT
1160             goodbye();
1161    #endif
1162             }
(gdb) q
The program is running.  Quit anyway (and kill it)? (y or n) y

Debugger finished
- --
<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"

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

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