David,

...

The latest developer's version should have this fixed. If it isn't, let me know.

I installed the most recent binary package I found on the XFractint site 20.02.4. Is that the latest developer's version? If so, it doesn't seem to be working.

The latest version is 20.03.2. The binaries aren't up to date.

Hmm, I don't even get the pallette editor to come up. But there are other keys that don't seem to work as the program indicates, so maybe running it under a Debian distribution or something about my xterm settings is messing that up.

Same as above. Jonathan

David,

So it sounds like I get to figure out how to compile from source.

Download xfract20.3.02.tar.gz, put it in your home directory, and untar it with the command "tar -xzf xfract20.3.02.tar.gz". This will create the directory xfractint-20.03p02 containing the source. You might change the directory name to xfractint for convenience. You will need to have gcc and ncurses installed. You also need the XFree86-libs package installed for the X11 libraries. This package should already be installed, but if it isn't and your distribution doesn't have it, then you need the XFree86-devel package. The Makefile is set up for my convenience, so if you want to put files in different directories, you will need to change the SRCDIR setting. Otherwise, just run make from the source directory and it should compile. Run ./xfractint to start it up. Let me know how this works and I'll put it into a readme file. Jonathan

I got this to compile ok, and it runs fine with no options. When I give it a geometry option, the fractal window is huge. I think it's using characters instead of pixels. The window is the right size (640x480) with no geometry option (but geometry=80x70). geometry=0x0 corresponds to 320x200. When I compile it with unixscr.c from v20.02.04, it draws the right size. Example: geometry 4x3 -> 336x212 pixels Good job on the file loading interface ('..', subdirectories, etc.). Much better! jpkotta On Fri, 15 Oct 2004 07:31:40 -0500, Jonathan Osuch <osuchj@avalon.net> wrote:

David,

...

So it sounds like I get to figure out how to compile from source.

Download xfract20.3.02.tar.gz, put it in your home directory, and untar it with the command "tar -xzf xfract20.3.02.tar.gz". This will create the directory xfractint-20.03p02 containing the source. You might change the directory name to xfractint for convenience.

You will need to have gcc and ncurses installed. You also need the XFree86-libs package installed for the X11 libraries. This package should already be installed, but if it isn't and your distribution doesn't have it, then you need the XFree86-devel package.

The Makefile is set up for my convenience, so if you want to put files in different directories, you will need to change the SRCDIR setting. Otherwise, just run make from the source directory and it should compile. Run ./xfractint to start it up.

Let me know how this works and I'll put it into a readme file.

Jonathan

_______________________________________________ Fractint mailing list Fractint@mailman.xmission.com http://mailman.xmission.com/cgi-bin/mailman/listinfo/fractint

On Friday 22 October 2004 6:53 am, Jonathan Osuch wrote:

...

I got this to compile ok, and it runs fine with no options. When I give it a geometry option, the fractal window is huge. I think it's using characters instead of pixels. The window is the right size (640x480) with no geometry option (but geometry=80x70). geometry=0x0 corresponds to 320x200. When I compile it with unixscr.c from v20.02.04, it draws the right size.

Yikes! I'll look into fixing that.

Fixed it. It will be in my next patch, due out real soon now. Jonathan

On Fri, 22 Oct 2004, david wrote:

Thanks. Can an updated binary be available to for us compiler-challenged Linux users?

Linux isn't that unified. To start with, there seems to be Gnu and SysV variants on where things like locks are stored. Mandrake went with SysV, I think. I might want to inspect a recent Berkley Standard Distribution to see if Mandrake isn't more of a thorn in UNIX than it must be. Understanding linux *requires* these commands performed as root: tar -zxvf XFracTint make XFracTint man XFracTint And, as I said, you'll get a slightly speedier XFracTint if you compile it than in a binary, because a binary is compiled for the lowest common denominator, which would be a 386 in the case of a Linux and perhaps an 8086 in the case of DOS. If you can knock Mandrake for anything, it's compiling for the Pentium two, and seeming to claim that THIS is the first processor to support four gigabytes of virtual memory, when it was the 386, although the ISA bus that those things typically ran on would force you to dedicate half of your addressable RAM (16MB) for nothing but the address translation table if you put four gigabytes of virtual memory on a 386. _______ Television is for people with no life of their own to live, so I bar it from my living room, where it would contradict the purpose of the room.

Hello, <snip>

I downloaded xfract20.3.02.tar.gz and untarred it as root.

...

make XFracTint

Trying that reports:

make: *** No rule to make target `XFracTint'. Stop.

I'm probably doing something wrong somewhere ... using Mepis Linux, a Debian distro.

Try: make xfractint i.e. everything lower case. I think simply: make Should work as well... Iain. --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.782 / Virus Database: 528 - Release Date: 22/10/2004

On Saturday 23 October 2004 3:41 pm, david wrote:

OK, I just entered "make" and it compiled away until it hit this:

gcc -I. -DXFRACT -DNOBSTRING -g -DBIG_ANSI_C -DLINUX -Os -fno-builtin -c -o realdos.o realdos.c realdos.c:10:20: curses.h: No such file or directory

According to Synaptic, I have an assortment of ncurses packages installed, and one called "termcap-compat" that describes itself as a compatibility package for old terminals.

It looks like the header file may be provided with ncurses-devel. Jonathan

David,

Thanks, installing libncurses5-dev got the file, it compiled. Moved my files over from the old XFracTint directory and it happily opens them! Hurrah!

Great!

Was able to get into map editing mode, but didn't seem to be able to change any colors.

Exactly. That is because I haven't figured out how to change the color palette without redrawing the image. If you load a new color map from the editor (press <l> for load), and then exit the editor, you'll notice that the part of the image behind the editor has changed to the new color map. The solution may be to double buffer the image and then blit the buffer to the screen after changing palette entries.

BTW, installing and running DOSEMU was a lot easier! ;-)

Yes. Although, my mouse doesn't work very well and it is *much* slower than using Xfractint. It does allow me to test Fractint without rebooting. Still can't compile under DOSEMU, however. Jonathan

On Wednesday 27 October 2004 2:07 pm, SherLok Merfy wrote:

<a href="http://www.starlink.rl.ac.uk/star/docs/sun239.htx/node19.html"

...

LUTTWEAK - Tweaks a colour table of an image-display device </a>

Unless you can rewrite a jeneralized subroutine like the above for your own purposes or use it from a library.

Yes, that would be the best approach. However, the code is essentially already in place. It just doesn't work. The problem could be any one of: 1. The detected visual class is incorrect for changing the palette because the palette is read-only in that visual class. It should be possible to change the visual class to one that allows read-write palettes 2. The colors may be allocated read-only. This is different from #1 because the colors could be allocated read-write or read-only with a visual class that allows read-write. 3. Forcing an expose event that tells the xwindow server to redraw (repaint not recalculate) the window may not be sent to the server correctly and may not be handled correctly by the Xfractint code (in unixscr.c). I've obviously missed something. Any help you can provide would be appreciated. Jonathan

On Thu, 28 Oct 2004, Jonathan Osuch wrote:

On Wednesday 27 October 2004 2:07 pm, SherLok Merfy wrote:

...

<a href="http://www.starlink.rl.ac.uk/star/docs/sun239.htx/node19.html"

...

LUTTWEAK - Tweaks a colour table of an image-display device </a>

Unless you can rewrite a jeneralized subroutine like the above for your own purposes or use it from a library.

Yes, that would be the best approach. However, the code is essentially already in place. It just doesn't work. The problem could be any one of:

1. The detected visual class is incorrect for changing the palette because the palette is read-only in that visual class. It should be possible to change the visual class to one that allows read-write palettes

I think that what you describe would cause a fault and _could_ raise a fault handler. LUTTWEAK is relevant to the National Centre for Supercomputing Applications, BTW, so you might find some really nifty tools among their pages. NCSA is Al Gore, taken at face value when he said he invented PPPd, Telnetd, FTPd, and HTTPd, among about thirty other utilities that are lies in the mouth of a politician.

2. The colors may be allocated read-only. This is different from #1 because the colors could be allocated read-write or read-only with a visual class that allows read-write.

If the address works out to be within memory that is read-only (in the local or global descriptor tables), then there should be a way to diagnose the problem with a fault handler for the XFractint task.

3. Forcing an expose event that tells the xwindow server to redraw (repaint not recalculate) the window may not be sent to the server correctly and may not be handled correctly by the Xfractint code (in unixscr.c).

I've obviously missed something. Any help you can provide would be appreciated.

You're welcome to ask questions that I might be able to provide keywords for in your requests to a search enjin. You have perhaps run accross the likelihood that source that compiles cleanly with -Wall is likely to run nicely, too (to some point of complexity, anyway). _______ fault handler diagnostic xwindows

Jonathan Osuch wrote:

David,

...

So it sounds like I get to figure out how to compile from source.

Download xfract20.3.02.tar.gz, put it in your home directory, and untar it with the command "tar -xzf xfract20.3.02.tar.gz". This will create the directory xfractint-20.03p02 containing the source. You might change the directory name to xfractint for convenience.

You will need to have gcc and ncurses installed. You also need the XFree86-libs package installed for the X11 libraries. This package should already be installed, but if it isn't and your distribution doesn't have it, then you need the XFree86-devel package.

Just used Synaptic to look for devel packages, and installed the X developer metapackage, make still tells me it can't find curses.h. -- David gnome@hawaii.rr.com

On Wed, 13 Oct 2004, Jonathan Osuch wrote:

The palette editor will come up, but I haven't figured out how to update the screen image without redrawing the fractal.

My guess is that you'll be forced to make a copy of the image. Redrawing the fractal is multiples faster than recalculating it. I wonder where that other Linux programmer went. You know, the one who was reinventing the wheel and putting it under "freshmeat". I think it was gnofract.