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

Internet Message Format | 2000-05-30 | 17KB

From: Tim Wegner <[e-mail]>
Subject: Re: (fractint) 3d transform doesn't work in float only version
Date: 13 May 2000 16:22:10 -0600

Rupert wrote:

> I thought about putting this on the buglist but I think it's a fundamental
> problem with float-only:
>
> In the float-only version of Fractint 3d transforms don't work.

Thanks, I'll fix this. There are some integer math dependencies in
3D which won't pose any difficulty to fix.

Couple of news items.

1. My wife Susan and I had an enjoyable evening with Scott Boyd
and his wife Sarah in Galveston.

2. Jonathan had some problems with his laptop, but has recovered
and has merged the float-only version with Xfractint, and is working
on merging 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: Tim Wegner <[e-mail]>
Subject: Re: (fractint) 3d transform doesn't work in float only version
Date: 14 May 2000 17:27:29 -0600

I updated the FTP area so all the patch 11 files are now there. Let
me know if any problem. I also did chmod 664 for all the files, but I
couldn't change the files that Jonathan owns. It would probably be
good if either Jonathan or Damien changed the permissions to 664
so anyone in the group can delete or update the files. Not a big
deal though.

As part of his project, Jonathan merged the float-only version with
Xfractint, but didn't save the result of this before he started merging
in Rich's changes. I'll probably reconstruct this. Our "official"
Xfractint might as well be based on the float-only version since
Xfractint doesn't support integer math anyway.

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: "Damien M. Jones" <[e-mail]>
Subject: Re: (fractint) 3d transform doesn't work in float only
Date: 15 May 2000 00:23:15 -0400

Tim,

 - I also did chmod 664 for all the files, but I couldn't change
 - the files that Jonathan owns. It would probably be good if
 - either Jonathan or Damien changed the permissions to 664
 - so anyone in the group can delete or update the files.

Done.

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"


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

From: "Jonathan Osuch" <[e-mail]>
Subject: Re: (fractint) 3d transform doesn't work in float only version
Date: 15 May 2000 20:51:28 -0500

Tim wrote,

> As part of his project, Jonathan merged the float-only version with
> Xfractint, but didn't save the result of this before he started merging
> in Rich's changes. I'll probably reconstruct this. Our "official"
> Xfractint might as well be based on the float-only version since
> Xfractint doesn't support integer math anyway.

I could probably do that tomorrow.  One problem is that we won't be able to
make a diff to it.  I've removed 7 or 8 files that had no use in Xfractint.
Until we get ported back to Windows/DOS, this leaves us with two radically
different sets of source code.  But, you knew that.   8-))

I've finished incorporating Rich's modifications and although it compiles,
it doesn't exactly run.  I get a graphics window but no image.  All text,
when it can be made to appear, is not formatted.  I will try to get the
Allegro package tied in and then worry about getting it to run.  I'm afraid
I might be missing the big picture about how this is supposed to work.
Rich, can you add some insight?

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: (fractint) 3d transform doesn't work in float only version
Date: 16 May 2000 10:29:51 -0600


In article <001301bfbed9$567a4ea0$0100a8c0@bananasenior>,
    "Jonathan Osuch" <[e-mail]>  writes:

> I've finished incorporating Rich's modifications and although it compiles,
> it doesn't exactly run.  I get a graphics window but no image.

The code base I had drew graphics but no text.  This was because the
text was previously done through curses, which is definately the wrong
way to do it.  Text should be done through Xlib or something else
layered on Xlib, not hacked up through curses in an xterm window.

> I'm afraid
> I might be missing the big picture about how this is supposed to work.
> Rich, can you add some insight?

Its just an interface for abstracting the graphics and text output
with a current "driver" selected.  A driver is essentially a structure
of function pointers that perform the operations in the interface.  A
new interface was not designed, rather the existing output functions
were made part of the driver interface.  So instead of calling
DoSomething(), you call driver->DoSomething() where the driver pointer
is initialized to the appropriate structure when you select a video
mode, etc.

The initialization code picks an initial driver depending on your
operating environment (i.e. an Xlib driver if you're running under
unix, a Win32 driver if you're running under Windows, etc.).

The "select video mode" code obviously has to be rewritten to
incorporate this idea.
--
<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: Allegro package Xfractint
Date: 25 May 2000 20:08:10 -0500

Folks,

I have incorporated the Allegro package into a float only version of Rich's
"driver" source.  It's up and running.  I have graphics and text in the same
window, but no mouse or text cursor movement.  Since just about everything
is broken, I won't provide a to-do list.  8-))

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 package Xfractint
Date: 26 May 2000 10:19:16 -0600


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

> It's up and running.

Cool!

> I have graphics and text in the same
> window, but no mouse or text cursor movement.

If you have the energy for it, we should revamp the input towards an
event-based system.  For DOS you can always invent your own "message
pump".  (Can't you get DOS to invoke an interrupt routine when a key
is pressed or mouse is moved that queues the input data for later
processing?  I never really programmed in DOS.)  This would make the
porting to window systems much, much easier.  Currently xfractint
hacks this in by having the polling I/O routines examine the event
queue.  Fractint polls often enough that events don't lag too far
behind, but its really awkward.

Surprisingly this polling only happens in a handful of places around
the fractint source because things are fairly well abstracted, i.e.
there is a routine for presenting the text-based "dialogs" that
fractint uses for parameters and so-on and this is pretty much reused
everwhere that such a thing is needed, so its not like you have to
modify one routine for each dialog to make the dialogs event-based.
--
<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 package Xfractint
Date: 26 May 2000 20:26:49 -0500

Rich,

> If you have the energy for it, we should revamp the input towards an
> event-based system.  For DOS you can always invent your own "message
> pump".  (Can't you get DOS to invoke an interrupt routine when a key
 > is pressed or mouse is moved that queues the input data for later
> processing?  I never really programmed in DOS.)

The Allegro package has a djgpp implementation.  So, in theory, it should be
set up for DOS once we get the Unix version running.  Can you give me a
brief explanation on how to implement an event-based system?  With so much
of the code currently broken, now would be a great time to make that change.

As for the energy, I've been doing this at work, since I currently don't
have anything else to do.  That is supposed to change next Tuesday.  I hope
it does, I don't really want to get laid off at this point in time.

Something I haven't started on, but have been thinking about is that the
Allegro package has routines for making menu's.  This would provide a
slicker package, but I'm not sure how easy that would be while maintaining
the "driver" interface.  OTOH, since the interface is not really defined
yet, we can change it to make it work.

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 package Xfractint
Date: 27 May 2000 17:39:10 -0600


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

> The Allegro package has a djgpp implementation.  So, in theory, it should be
> set up for DOS once we get the Unix version running.  Can you give me a
> brief explanation on how to implement an event-based system?

If you are doing input in a polling style you find a convenient place
to periodically check for keyboard input and then abort your current
computation to go handle the keyboard input.  So you have code that is
roughly structured like this:

    done = false;
    while (!done) {
    do_something();
    key = getakey();
    if (key == ESC)
        break;
    do_something_else();
    if (finished())
        done = true;
    }
    if (!done) // ESC broke us out
    handle_esc();
    else
    final_stuff();

and so-on.  Basically the getakey() polls the input buffer to check to
see if there is anything.  If so, then the input is handled somehow.
Some places in fractint handle keys immediately and then continue with
the work, whereas others (like pressing ESC) cause the control flow to
be altered by aborting the current calculation, or going into a menu
display or something.

Basically the fictitious routines do_something(), do_something_else(),
finished() and final_stuff() I've written above are the "idle" loop
that is executed when you don't have any input waiting for you to
handle.  It is essentially a state machine (starts with done=false and
proceeds doing incremental batches of work until done=true) that is
interleaved with checking for input whenever a state transition could
be made.

The event-loop style of handling this is to separate the idle
processing state machine from the input handling like so:

    quit = false;
    while (!quit) {
    if (peek_event()) {
        event = get_event();
        handle_event(event);
    } else {
        do_idle_routine();
    }
    }

where the routines peek_event(), get_event(), and handle_event() do
the input processing.  When no events are available for processing,
the code executes the idle input state machine code.  Obviously the
routine do_idle_processing() shouldn't take a long time because the
program isn't going to respond to input while doing the idle
processing.  However, fractint is already structured this way because
of the frequent calls to getakey() which aborts or suspends any idle
processing based on the key pressed.

Eventually some piece of input (or completion of the idle processing
in batch mode) will signal that quit should be set to true, thus
causing the program to terminate.  The above is the structure of every
Win32 application, as well as every X Window System application.  They
process events until the program receives an event (or a condition is
triggered) that causes the program to terminate.

I certainly hope you don't get laid off!  I don't know if you're
willing to relocate, but if you know Windows programming (especially
COM), there are two full-time positions open where I work in Salt Lake
City.  Give me a hollar if you are interested in exploring that
possibility.

As for the allegro menu system, right now I would concentrate on just
getting a bare-bones interface to work using whatever is most
convenient.  For the "big picture", the differences between
Mac/Win32/X are small enough that the driver interface should be able
to handle them all.  We can always get fancier with the interface
later after we get something basic working, even if the basics are
initially ugly.
--
<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: "Scott D. Boyd" <[e-mail]>
Subject: Xfractint dev. question
Date: 30 May 2000 01:20:42 -0500

Hi all,

I know it's not in the source, but is fractint.cfg used for *any reason* by
Xfractint? Or is it a moot point (or moot file) since X takes care of the
graphics window?

Scott Boyd

--
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: Xfractint dev. question
Date: 30 May 2000 19:56:13 -0500

Scott,

> I know it's not in the source, but is fractint.cfg used for *any reason*
by
> Xfractint? Or is it a moot point (or moot file) since X takes care of the
> graphics window?

It is not used for anything and is one of many files that will be
disappearing.  There is a lot of legacy code that will need to be removed
once the integration of the Allegro graphics package is complete.

The status of the Allegro integration:  Basic graphics and text windows
work.  No zooming or text cursor.  The help screens and certain other text
screens crash.  The 8, 15, 16, 24, and 32 bpp graphics modes work.  There is
still lots to do.

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"