From: owner-fractdev-digest@lists.xmission.com (fractdev-digest) To: fractdev-digest@lists.xmission.com Subject: fractdev-digest V1 #20 Reply-To: fractdev-digest Sender: owner-fractdev-digest@lists.xmission.com Errors-To: owner-fractdev-digest@lists.xmission.com Precedence: bulk fractdev-digest Thursday, April 29 1999 Volume 01 : Number 020 ---------------------------------------------------------------------- Date: Thu, 11 Mar 1999 13:39:07 -0500 From: Robert Hailman Subject: Re: (fractdev) Re the path to 32 bits Sweet... I haven't gotten around to upgrading to 5.2, I have had no need for it yet. At 10:22 AM 11/03/99 -0600, Damien M. Jones wrote: >Robert, > > - My copy of RedHat 4.2 came with an extra Cd, of contributed files, and > - amonst otherthings was an old version of Xfractint > >(laugh) Well, you can tell I don't use RedHat as a desktop OS, can't you? >:) All the server apps I wanted were on the first CD, so I never got around >to looking at the second one. (RedHat 5.2 comes with *three* CDs, believe >it or not.) > > - =CFCQ: 166848=20 > >Da-hurn! What an uncommonly low number. > Oops, it's actually 1668484... still pretty low, I've been on since August= =20 '97. Thanks for pointing that out. >Damien M. Jones \\ >dmj@fractalus.com \\ 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: fractdev@lists.xmission.com >Get Commands: majordomo@lists.xmission.com "help" >Administrator: twegner@phoenix.net >Unsubscribe: majordomo@lists.xmission.com "unsubscribe fractdev" > > Robert H=E4lman=20 =CFCQ: 1668484=20 robert@apexwood.com - ----- P=EBs, luv =E3nd eksesiv drug =FCs. "=CF'm st=E3rting a v=F6r f=F6r p=EBs." =C3=C4=CB=CF=D5=D6=DC=E3=E4=EB=EF=F5=F6=FC=D1=F1 - -------------------------------------------------------------- Thanks for using Fractdev, The Fractint Developer's Discussion List Post Message: fractdev@lists.xmission.com Get Commands: majordomo@lists.xmission.com "help" Administrator: twegner@phoenix.net Unsubscribe: majordomo@lists.xmission.com "unsubscribe fractdev" ------------------------------ Date: Wed, 28 Apr 1999 14:12:52 -0600 From: Phil McRevis Subject: (fractdev) xfractint 19.61 pl66 fixes OK, I compiled the 19.61pl66 version of xfractint and found some minor bugs which I worked around. I also added support for default visuals that aren't pseudocolor (i.e. truecolor, directcolor etc.) to xfractint. One step closer to rendering in any visual. Also, I've been looking at xfractint's guts to determine how one could separate out the O/S & graphics dependencies. It doesn't look too bad actually. More on that later. Tim, do I send diffs to you? I tried sending to fractdev, but I guess it was bounced because the diffs made the message too large. - -- Legalize Adulthood! ``Ain't it funny that they all fire the pistol, at the wrong end of the race?''--PDBT - -------------------------------------------------------------- Thanks for using Fractdev, The Fractint Developer's Discussion List Post Message: fractdev@lists.xmission.com Get Commands: majordomo@lists.xmission.com "help" Administrator: twegner@phoenix.net Unsubscribe: majordomo@lists.xmission.com "unsubscribe fractdev" ------------------------------ Date: Wed, 28 Apr 1999 17:16:26 -0600 From: "Tim Wegner" Subject: Re: (fractdev) xfractint 19.61 pl66 fixes "Phil" wrote: > Tim, do I send diffs to you? I tried sending to fractdev, but I guess > it was bounced because the diffs made the message too large. Yes send them to me, but since I administrate the list, I already have them because your too-large message bounced to me I'll look at it right away. Thanks very much. Interest on our end in Xfractint has increased a lot. Jonathan and I both have Linux. I'll merge your changes along with some of our own and re-upload the Xfractint source file. Tim - -------------------------------------------------------------- Thanks for using Fractdev, The Fractint Developer's Discussion List Post Message: fractdev@lists.xmission.com Get Commands: majordomo@lists.xmission.com "help" Administrator: twegner@phoenix.net Unsubscribe: majordomo@lists.xmission.com "unsubscribe fractdev" ------------------------------ Date: Wed, 28 Apr 1999 16:25:13 -0600 From: Phil McRevis Subject: Re: (fractdev) xfractint 19.61 pl66 fixes In article <199904282216.RAA06509@voyager.c-com.net>, "Tim Wegner" writes: > Yes send them to me, but since I administrate the list, I already > have them because your too-large message bounced to me OK, inspect that diff carefully. I think some stuff that was supplied in the patch ended up in my diff because of my poor attempt at branching the source in my VCS. (I'm trying to maintina a "pristine" branch of blessed code as the trunk with my changes on a concurrent branch. Somehow I've got the two mixed up and things aren't working right for me yet.) > I'll look at it right away. Thanks very much. Interest on our end in > Xfractint has increased a lot. Jonathan and I both have Linux. If you get my diffs in there and it compiled OK for you, I'd really like to know how well fractint behaves when the default visual is truecolor or directcolor. (Or StaticGray, StaticColor, and GrayScale for that matter.) I'm finally digging into the entire fractint source base and getting up to speed in how the routines interact. The bad news is that there's a LOT of code and a fairly good amount of programming crumbs have been left laying around as each coder does battle with the program! The good news is that I'm finally starting to see how everything is linked together in fractint and I feel much more optimistic about the flat-model port and a move to a GUI environment. - -- Legalize Adulthood! ``Ain't it funny that they all fire the pistol, at the wrong end of the race?''--PDBT legalize@xmission.com - -------------------------------------------------------------- Thanks for using Fractdev, The Fractint Developer's Discussion List Post Message: fractdev@lists.xmission.com Get Commands: majordomo@lists.xmission.com "help" Administrator: twegner@phoenix.net Unsubscribe: majordomo@lists.xmission.com "unsubscribe fractdev" ------------------------------ Date: Wed, 28 Apr 1999 16:45:31 -0600 From: Phil McRevis Subject: (fractdev) DOS support via allegro? I know we've talked about this before, but now I'm digging into the code and looking to get really specific about stuff. Taking Tim's suggestion of using the xfractint code base as a start, the question becomes "how to provide a DOS driver through that code base?". In the past, we've talked about fancy GUI toolkits (i.e. gimp toolkit) and so-on. But what I'm faced with right now is this question: "What's the smallest code delta that makes the xfractint code compile and work under a DOS protected-mode extender environment like djgpp?". In other words: first get it right, then get it tight. Assembly is the tool you use for getting it "tight" after you've gotten it right. Fractint currently interacts with the keyboard, mouse and display through 16-bit assembly routines: general.asm handles keyboard, audio and mouse support keypressed(), getakey(), buzzer(), delay(), tone(), snd(), nosnd() video.asm video display support setvideomode(), setvideotext(), getcolor(), putcolor() out_line(), drawbox(), home(), movecursor(), keycursor() putstring(), setattr(), scrollup(), scrolldown() putstr(), loaddac(), spindac(), adapter_init, adapter_detect setnullvideo setfortext(), setforgraphics(), setclear(), findfont() Allegro, the gaming library for DJGPP, lists the kinds of monitors it supports. I'm not up to speed on all the specifics of these monitors and so-on. Can someone out there provide guidance to say "yes, Allegro covers a suficient portion of the existing fractint users, so you can provide DOS driver support through allegro" or "no, fractint provides much more extensive video support with its assembly, so you should port the assembly" Thanks in advance. from the readme.txt in the allegro distribution: Supports VGA mode 13h, mode-X (twenty three tweaked VGA resolutions plus unchained 640x400 Xtended mode), and SVGA modes with 8, 15, 16, 24, and 32 bit color depths, taking full advantage of VBE 2.0 linear framebuffers and the VBE/AF hardware accelerator API if they are available. Additional video hardware support is available from the FreeBE/AF project (http://www.talula.demon.co.uk/freebe/). Drawing functions including putpixel, getpixel, lines, rectangles, flat shaded, gouraud shaded, and texture mapped polygons, circles, floodfill, bezier splines, patterned fills, masked, run length encoded, and compiled sprites, blitting, bitmap scaling and rotation, translucency/lighting, and text output with proportional fonts. Supports clipping, and can draw directly to the screen or to memory bitmaps of any size. Hardware scrolling, mode-X split screens, and palette manipulation. [...] Plays background MIDI music and up to 64 simultaneous sound effects, and can record sample waveforms and MIDI input. Samples can be looped (forwards, backwards, or bidirectionally), and the volume, pan, pitch, etc, can be adjusted while they are playing. The MIDI player responds to note on, note off, main volume, pan, pitch bend, and program change messages, using the General MIDI patch set and drum mappings. Currently supports Adlib, SB, SB Pro, SB16, AWE32, MPU-401, ESS AudioDrive, Ensoniq Soundscape, and software wavetable MIDI. Easy access to the mouse, keyboard, joystick, and high resolution timer interrupts, including a vertical retrace interrupt simulator. [...] Math functions including fixed point arithmetic, lookup table trig, and 3d vector/matrix manipulation. - -- Legalize Adulthood! ``Ain't it funny that they all fire the pistol, at the wrong end of the race?''--PDBT - -------------------------------------------------------------- Thanks for using Fractdev, The Fractint Developer's Discussion List Post Message: fractdev@lists.xmission.com Get Commands: majordomo@lists.xmission.com "help" Administrator: twegner@phoenix.net Unsubscribe: majordomo@lists.xmission.com "unsubscribe fractdev" ------------------------------ Date: Wed, 28 Apr 1999 16:48:56 -0600 From: Phil McRevis Subject: (fractdev) FCODE Am I correct in assuming all this FCODE business is to exploit the code segment for string storage to avoid memory-model ceilings? - -- Legalize Adulthood! ``Ain't it funny that they all fire the pistol, at the wrong end of the race?''--PDBT - -------------------------------------------------------------- Thanks for using Fractdev, The Fractint Developer's Discussion List Post Message: fractdev@lists.xmission.com Get Commands: majordomo@lists.xmission.com "help" Administrator: twegner@phoenix.net Unsubscribe: majordomo@lists.xmission.com "unsubscribe fractdev" ------------------------------ Date: Wed, 28 Apr 1999 22:44:50 -0600 From: "Tim Wegner" Subject: Re: (fractdev) DOS support via allegro? Rich wrote: > In the past, we've talked about fancy GUI toolkits (i.e. gimp toolkit) > and so-on. But what I'm faced with right now is this question: "What's > the smallest code delta that makes the xfractint code compile and work > under a DOS protected-mode extender environment like djgpp?". 1. You have to undo any specifically X code and 2. You have to implement video modes and graphics read write. Also note that the text writing in Xfractint uses curses. However I believe there are djgpp versions of curses if we want to go that route. While #2 is easily done with SVGA lib, it isn't worth the effort. You have to solve all over again the problems with DOS video modes we have long since solved. I suggest the following. In Xfractint's -disk mode, no screen graphics is done. In this mode Xfractint doesn't do any X stuff and is probably close to being portable to djgpp. The one warning is that Xfractint doesn't use Fractint's diskvideo code which has it's own cache. I don't know if diskvideo should use the DOS code or the XFractrint code. Apparently the caching isn't needed in Linux. In DOS it is essential since some of the passes options cause writing all over the file, and it is horribly slow. That's the reason for the cache. Try building a video-less version first. Tim - -------------------------------------------------------------- Thanks for using Fractdev, The Fractint Developer's Discussion List Post Message: fractdev@lists.xmission.com Get Commands: majordomo@lists.xmission.com "help" Administrator: twegner@phoenix.net Unsubscribe: majordomo@lists.xmission.com "unsubscribe fractdev" ------------------------------ Date: Wed, 28 Apr 1999 22:44:50 -0600 From: "Tim Wegner" Subject: Re: (fractdev) FCODE > Am I correct in assuming all this FCODE business is to exploit the > code segment for string storage to avoid memory-model ceilings? The FCODE typedef allows data to be placed in overlays. This means that data does not eat into Fractint's limited supply of near memory, since in the medium memory model the is a total of 64K of near memory, and data not explicitly declared far is in the near data segment. Since the FCODE data is in an overlay, it can't be changed, and least not for long. Once that overlay is reloaded, the data reverts to its permananent value. This is ideal for things like menu prompts. It is the use of tricks like this that has allowed Fractint to survive so long and well with a really restrictive memory model. For Xfractint or any other 32 bit memory model purpose, FCODE is just a normal type. There are versions of it for char, int, etc. Tim - -------------------------------------------------------------- Thanks for using Fractdev, The Fractint Developer's Discussion List Post Message: fractdev@lists.xmission.com Get Commands: majordomo@lists.xmission.com "help" Administrator: twegner@phoenix.net Unsubscribe: majordomo@lists.xmission.com "unsubscribe fractdev" ------------------------------ Date: Wed, 28 Apr 1999 22:44:50 -0600 From: "Tim Wegner" Subject: Re: (fractdev) xfractint 19.61 pl66 fixes > OK, inspect that diff carefully. I think some stuff that was supplied > in the patch ended up in my diff because of my poor attempt at > branching the source in my VCS. I have no way of dealing with the diff you sent except to implement it by hand (which I could do). It is nearly a context diff, but "nearly" scores only in horseshoes :-) I need either a true context diff (diff -c old new > changes.dif) or just sent a zipped version of the complete changed files. I like emails to be encapsulated in zips; I'm never sure when my mailer is going to wrap lines and mess things up. Tim - -------------------------------------------------------------- Thanks for using Fractdev, The Fractint Developer's Discussion List Post Message: fractdev@lists.xmission.com Get Commands: majordomo@lists.xmission.com "help" Administrator: twegner@phoenix.net Unsubscribe: majordomo@lists.xmission.com "unsubscribe fractdev" ------------------------------ Date: Thu, 29 Apr 1999 01:54:21 -0600 From: Phil McRevis Subject: Re: (fractdev) DOS support via allegro? In article <199904290430.XAA26718@voyager.c-com.net>, "Tim Wegner" writes: > 1. You have to undo any specifically X code and > 2. You have to implement video modes and graphics read write. These are actually one and the same. As I say, going through the code has reduced a job of Everest proportions to one of less than Whitney proportions. (Mt. Whitney is the highest point in the continental 48 states, its in California.) > Also note that the text writing in Xfractint uses curses. However I > believe there are djgpp versions of curses if we want to go that > route. Yeah, personally I consider the curses thing a bug. It should just open up a separate X window and do X text in that window, or it should do X text in the graphic window, similar to XaoS' "ugly interface". And yes, there are oodles of open source curses implementations. GNU has one, in fact (ncurses-4.2). However, replacing the text interface (which currently calls curses functions) with a function that does X11 text instead of curses shouldn't be very hard. Fractint calls only a handful of curses functions. Some of the existing text mode support that could be handled by curses is #ifdef'd out in the patch 66 snapshot. You still need an ability to run "text only" when doing disk video, so you'll still want the curses support, I believe. Just that you won't be putting the main menu up with curses unless you're using disk video or "curses video" if we implement a XaoS-style text-only mode. (I don't see why not.) In this respect, XaoS and fractint actually have that in common: the number of functions you must change in order to add a new driver is not that many. Reading/writing a pixel, switching to "text" mode and back, reading the keyboard/mouse, getting an 8x8 font bitmap, positioning the text cursor and drawing characters with text attributes. That's about all you need to do. I've been studying the XaoS source code since they have dealth with the same problem. They did what I was thinking fractint should do: they built a structure with attributes of the driver (data members) and function pointers to the driver's functions that implement the interface (member functions). Fractint just needs the structure that groups the related information about a driver together along with a slight adjustment to its control logic. At that point, every "#ifdef XFRACT" that is there for reasons of X11 and not unix-vs-dos will disappear. Only one "#ifdef XFRACT" will remain which is wrapped around the X11 initializer in the list of drivers (which is static at compile time). When I looked at the places where "unix" code was substituted for "dos" code, what I found was that some of the "unix" code was really just X11 code, not specific to unix. (You can compile X11 clients for DOS and Win32, X11 is just a protocol built on TCP/IP, so anything that can talk TCP/IP can talk X11.) Other times the XFRACT was isolating some difference between unix and dos. Tim, I think we talked earlier about autoconf; I've successfully switched over one open-source program to autoconf and I think I've got a handle on it. We could do xfractint over to autoconf, but I'd definately need to consult with some other fractint code gurus to understand how the different #define's interact. There's no reason why a good configure script couldn't enable/disable long double support when a long double is distinct from a double. This isn't so much an x86 vs. other CPU argument either, xmission's sparc solaris reports sizeof(long double) as 16 and sizeof(double) as 8. However, autoconf is a bit ahead of my current position on things, but with a little more practice on autoconf for my other projects, that will carry over to xfractint. And also I believe that autoconf is getting improved DOS support to support building code on DOS as well as unix portably. The makefile templates now include the ability to specify an alternate to the usual unix executable, object and library filename extensions (i.e. use 'exe', 'obj', 'lib' instead of '', '.o', '.a'). > While #2 is easily done with SVGA lib, it isn't worth the effort. You > have to solve all over again the problems with DOS video modes we > have long since solved. Right, but I have to get something up on the screen. Yes, I could start with a "videoless" fractint. But here's what I'm seeing now that I look into the code: changing the X-specific code once to support a "videoless" fractint is epsilon easier than changing the X-specific code to support a driver harness. With the driver harness I'm thinking of, disk "video" is always present regardless of anything else with the code. Next is to add a driver instance that encapsulates the existing X11 interface. This is like a 15 minute job, once the harness is in place. Next is what's needed for some minimal DOS display support, which is nothing harder than a handful of functions now that I'm seeing it more clearly. > I suggest the following. In Xfractint's -disk mode, no screen > graphics is done. In this mode Xfractint doesn't do any X stuff and > is probably close to being portable to djgpp. Actually where I'm starting is to get a working harness + X11 driver instance going on the X side and then take it over to a disk video only version with djgpp. > own cache. I don't know if diskvideo should use the DOS code or > the XFractrint code. The disk video caching is an O/S issue, not a graphics issue. There are a few little things that need to be factored out because of O/S platform differences, not because of differences in the graphics environment. Memory management, timers, date and time manipulation, file system I/O are some examples, there are probaly some more. These also need to be factored out into an "OS" module, with the configure (manual or otherwise) picking one of them to compile. > Apparently the caching isn't needed in Linux. In linux, you have the virtual memory system of the O/S to deal with it, so you don't need to write it yourself. You can just mmap() the file and use it like a char *. > In DOS it is essential since some of the passes options cause > writing all over the file, and it is horribly slow. That's the reason for > the cache. The code could still be retained. You'd just be managing the cache in a flat memory model rather than in a segmented straightjacket. - -- Legalize Adulthood! ``Ain't it funny that they all fire the pistol, at the wrong end of the race?''--PDBT legalize@xmission.com - -------------------------------------------------------------- Thanks for using Fractdev, The Fractint Developer's Discussion List Post Message: fractdev@lists.xmission.com Get Commands: majordomo@lists.xmission.com "help" Administrator: twegner@phoenix.net Unsubscribe: majordomo@lists.xmission.com "unsubscribe fractdev" ------------------------------ Date: Thu, 29 Apr 1999 01:55:29 -0600 From: Phil McRevis Subject: Re: (fractdev) FCODE Err... I'll take that as a yes. :) - -- Legalize Adulthood! ``Ain't it funny that they all fire the pistol, at the wrong end of the race?''--PDBT legalize@xmission.com - -------------------------------------------------------------- Thanks for using Fractdev, The Fractint Developer's Discussion List Post Message: fractdev@lists.xmission.com Get Commands: majordomo@lists.xmission.com "help" Administrator: twegner@phoenix.net Unsubscribe: majordomo@lists.xmission.com "unsubscribe fractdev" ------------------------------ Date: Thu, 29 Apr 1999 02:00:25 -0600 From: Phil McRevis Subject: Re: (fractdev) xfractint 19.61 pl66 fixes In article <199904290430.XAA26730@voyager.c-com.net>, "Tim Wegner" writes: > I have no way of dealing with the diff you sent except to implement > it by hand (which I could do). Really? Did your patch utility give you an error or what? If you're using an old version of patch that doesn't ignore leading/trailing garbage outside of a context diff, you should get a newer version. GNU patch doesn't suffer from any such deficiencies. > I need either a true context diff (diff -c > old new > changes.dif) or just sent a zipped version of the What problem exactly are you having? The problem with zipping up source code is the end-of-line convention gets stored binary in the file and you end up having to constantly convert back and forth between unix and DOS line conventions. We could setup a CVS server here on xmission and people could just update/checkin/checkout to that directly without you having to process the diffs manually. Just a thought. - -- Legalize Adulthood! ``Ain't it funny that they all fire the pistol, at the wrong end of the race?''--PDBT legalize@xmission.com - -------------------------------------------------------------- Thanks for using Fractdev, The Fractint Developer's Discussion List Post Message: fractdev@lists.xmission.com Get Commands: majordomo@lists.xmission.com "help" Administrator: twegner@phoenix.net Unsubscribe: majordomo@lists.xmission.com "unsubscribe fractdev" ------------------------------ Date: Thu, 29 Apr 1999 16:41:31 -0600 From: Phil McRevis Subject: (fractdev) portability thoughts Lets separate graphic driver (anything to do with mouse/display) issues from operating system issues. Here are the operating system issues as I see them at my current level of understanding of the source: file system I/O max. filename path len path element separator directory reading/scanning The path separator thing becomes painful under unix. Fractint uses '/' to separate the parameter name from a parameter file, for isntance. It happens to look for a '/', and if it sees one, it assumes that the argument is ``@parfile/entry'', but if one naively specified a full-path of a parfile under xfractint, you'd have a '/' as part of the parfile name and xfractint will become confused. A workaround is to always have parfiles specified in this manner in the current directory. Either fractint's syntax will have to be adjusted slightly, or some quoting mechanism must be installed to allow a full pathname for a unix file to be specified in these instances. The filename length is rather standard; stdio.h defines FILENAME_MAX. The directory scanning/reading issue is one of differences between unices. Some use readdir that returns a DIRENT, some return a DIR. Autoconf has all the ability to isolate the differences and provide a snippet of code that always works. 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. 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. time and date / timers Fractint uses the PC's timer -- I believe it only uses it in a stopwatch manner, not to control I/O polling. (Keyboard polling is controlled by an internal counter which is adjusted by various computation routines. When the counter reaches zero, the keyboard is checked for input.) Providing an interface to a system stopwatch is relatively straightforward. This would be needed even under a Win32 port since fractint's idea of accessing the timer relies on a DOS model, which accesses the timer directly (or does it use BIOS?). signals There are differences between unices. Some signal handlers return void, some return int. Autoconf can handle this. compilation issues / portability / assembler autoconf probably lots of include files to sort out. driver options autodiscover drivers? libraries: math library, gmp? building help compiler to build help file building help file with help compiler data files: frmfiles, ifsfiles, lfiles, mapfiles, parfiles wipe out default .l.o rule; .l files here aren't lex files, they're lsys files documentation rule: fractint.doc The stuff under autoconf -- if you're not familiar with autoconf, see bwlo(*) -- is a list of things that need to be done to use autoconf for fractint. trig constants why use homebrew PI, etc.? use M_PI, M_PI_2, etc. instead I'm not sure why fractint defines its own value for PI. Maybe because when fractint was first compiled, there weren't any good math.h's for the PC? At any rate, I think M_PI and friends from math.h should be preferred unless there is a significant reason not to. Again, autconf can detect the absence of a defined M_PI and define one for that case. void * != int Lots of places in the code there are implicit assumptions about sizeof(int) == sizeof(void *). This isn't good for portability in general, and in the L-system code I think it actually causes a crash in xfractint that shouldn't be there. data type support: int, long, long long, float, double, long double Autoconf can detect the sizes of all these data types and distinguish which ones embody more precision. Conditional compilation of long double support could be added through the code as a function of the compiler rather than a "DOS/XFRACT" switch as is currently done. arbitrary precision arithmetic gmp only provides integers, rationals, fixed. Doesn't provide trig functions. Contribute complex, trig implementations back to FSF. The arbitrary precision arithmetic routines used by fractint aren't portable to non-x86 platforms. However, the gmp (GNU multiple precision) library *is* portable to a large number of platforms -- it has assembly for the inner loops for a variety of CPUs: a29k, alpha, arm, clipper, cray, hppa, i960, m68k, m88k, mips2, mips3, ns32k, powerpc32, powerpc64, pyr, sh, sparc32, sparc64, vax, x86 (includes pentium support), z8000, and z8000x. I think fractint should adopt gmp, but this will mean a fair bit of work. gmp provides arbitrary precision integer, rational and floating point representations. It does not provide a complex representation (although making one is straightforward), nor does it provide trigonometric functions for any of the data types. Fractint's bignum implementation provides both of these. If it were up to me, I'd take the complex and trig support impemented in fractint, port that onto the gmp library and contribute it back as GPL'ed source to the gmp maintainers. Then I'd move fractint to using gmp completely. 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. :-) (*) ==== About autoconf There are lots of minor nagging differences between unix implementations. This was what vendors did to "add value" during the pre-POSIX days. Now people realize that consistency of an interface is more valuable than any value "added" by deviating in a non-portable manner. At any rate, we're now stuck with how to resolve all these niggling little differences between unix boxes. Autoconf was invented to solve this problem as open source software evolved and was ported to more and more platforms. Rather than try and identify the feature sets provided by all possible OS and hardware combinations ahead of time, autoconf builds a configuration script based on knowledge of the source code's requirements. The configure script knows what the source code needs (or what alternatives the source code implements) and probes the system at compile time to see if the system provides facilities sufficient for the compilation of the package. It identifies alternatives available in the system and marks them in a configuration header file. The header file is included by the source code to select between alternatives or conditionally compile snippets of code based on the configuration. Mechanically, it works like this: configure.in is a file you edit that specifies your software's feature requirements (include files, typedefs, functions, libraries, etc.) Makefile.in, config.h.in, etc. Remaining *.in files are templates containing autoconf variables. When the source code is configured, the configure script will process the template files and expand the autoconf macros to the appropriate values for the system. autoconf generates a configure script from configure.in, since a configure script is a big hairy /bin/sh script that is too cumbersome to write by hand. Configure.in serves as a template that is macro expanded through m4 to obtain configure. configure is run on the target system, identifying available features for the software. *.in template files are processed and autoconf variables are substituted by their appropriate values in the templates. This step usually creates your Makefile and config.h now you're ready to run make and install the target. The end user (the person compiling your source distribution) isn't required to have "autoconf" installed unless they want to change the source code's configuration process. One generally distributes source after you've run autoconf so that a configure script comes with the source code. An end-user obtains the source, runs configure, types "make" and then "make install" to install the software. No more editing of include files and/or Makefiles to configure your package! There is an additional GNU tool called "automake" that simplifies the details of writing a makefile compliant with the GNU coding standards. (This provides standard targets for actions like "install", "uninstall", conventions for locations of binary files, installed header files, installed libraries, and so-on.) Automake works in conjuction with autoconf, but autoconf doesn't require automake. - -------------------------------------------------------------- Thanks for using Fractdev, The Fractint Developer's Discussion List Post Message: fractdev@lists.xmission.com Get Commands: majordomo@lists.xmission.com "help" Administrator: twegner@phoenix.net Unsubscribe: majordomo@lists.xmission.com "unsubscribe fractdev" ------------------------------ Date: Thu, 29 Apr 1999 17:00:17 -0600 From: Phil McRevis Subject: (fractdev) C++ templates and generic programming and fractint! :) Just an observation... fractint already embodies the concept of "generic programming with template classes" as closely as C can deal with it. Think about it... fractint has different code blocks implementing the mathematics of long (integer), double, long double, bignum and bigfloat number representations. Fractint evolved in C what one would do in C++ with a template class: provide different implementations of the same set of operations for different underlying representations.o As I'm scanning through the fractint source code, I'm looking at things that go like this alot: if (integer math) do some setup calculation using an integer representation else if (floating point math) do some setup calculation using a double representation #ifndef XFRACT else if (extended precision fp math) do some setup calculation using a long double representation #endif else if (bignum math) do some setup calculation using a bignum representation else if (bigfloat math) do some setup calculation using a bigfloat representation Variables also exist in multiple representations like the complex-plane coordinates identifying the current zoom box. What fractint is really doing is using an arbitrary precision datatype that adapts its computation based on the amount of precision required. Based on the zoom box, fractint decides how many decimals of precision it needs and swaps the representation as needed while zooming if the pixel's inner loop can handle it. If at some point fractint evolves into using C++, I think this would be the strongest argument for such a move. The template classes of C++ allow for a much cleaner representation of this idea. It would also be much less error-prone when making modifications to the code. Consider the setup calculation example above. With a template implementation, we would have a single expression for the setup calculation. If this calculation needed to change, only one expression would need to be edited and tested. With the existing method, all the expressions have to be edited and tested separately. Adding a new fractal type would imply that the formula would be implemented for *all* supported representations with a single template function. (This is the power of generic programming using templates.) Each new fractal type would get arbitrary precision arithmetic "for free". - -- Legalize Adulthood! ``Ain't it funny that they all fire the pistol, at the wrong end of the race?''--PDBT - -------------------------------------------------------------- Thanks for using Fractdev, The Fractint Developer's Discussion List Post Message: fractdev@lists.xmission.com Get Commands: majordomo@lists.xmission.com "help" Administrator: twegner@phoenix.net Unsubscribe: majordomo@lists.xmission.com "unsubscribe fractdev" ------------------------------ Date: Thu, 29 Apr 1999 18:01:30 -0500 From: "Damien M. Jones" Subject: Re: (fractdev) C++ templates and generic programming and fractint! :) Rich, - If at some point fractint evolves into using C++, I think this would - be the strongest argument for such a move. The template classes of - C++ allow for a much cleaner representation of this idea. (laughing) I seem to recall this topic being brought up some time ago. I'm glad to see it raised again. It's also the model I used for JuliaSaver, which implements a base class with all the guessing logic and a good chunk of the setup code, and the individual fractal type classes just override the actual iteration routines and any other setup routines they need to modify. (In case there was any question about the efficiency of C++.) Damien M. Jones \\ dmj@fractalus.com \\ 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: fractdev@lists.xmission.com Get Commands: majordomo@lists.xmission.com "help" Administrator: twegner@phoenix.net Unsubscribe: majordomo@lists.xmission.com "unsubscribe fractdev" ------------------------------ Date: Thu, 29 Apr 1999 17:17:00 -0600 From: Phil McRevis Subject: Re: (fractdev) C++ templates and generic programming and fractint! :) In article <3.0.5.32.19990429180130.0093c530@mail.icd.com>, "Damien M. Jones" writes: > (laughing) I seem to recall this topic being brought up some time ago. I must have missed that, or perhaps it appeared on another list. I rank contributions to fractdev of higher importance than the other fractal lists :-). But its nice to see someone's reading all this stuff I've been sending out. Sometimes its nice to hear back an "echo". :-) > I'm > glad to see it raised again. It's also the model I used for JuliaSaver, > which implements a base class with all the guessing logic and a good chunk > of the setup code, and the individual fractal type classes just override > the actual iteration routines and any other setup routines they need to > modify. (In case there was any question about the efficiency of C++.) 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. If anyone out there reading this hasn't read Stroustrop's "C++ Programming Language", 3rd ed., section on the STL, go out and get it and read it! After you've read it the first time and thought about it for a few months, go back and read it again! Despite all the different programming languages and circumstances in which I've exercised my skill, the concepts embodied by the STL really changed the way I looked at certain programming problems. STL is written in C++, but it isn't "object oriented". There is a minor use of class inheritance to exhibit some reuse, but this is rare and only in places where it makes sense for the problem. STL has some aspects of "functional" programming languages, especially adaptors, binders, unary_function, binary_function, and so-on. The model of the STL is powerful, richly expressive, composable and adaptable all while being efficient! Provided of course you have a decent STL implementation, but the open source SGI implementation is pretty good at this point if you happen to be stuck with a sucky STL. You will need a good template-aware C++ compiler or you'll be hosed. Somewhere buzzing around my brain is the zygotal code of a template-based library that exploits generic programming techniques to deal with the explosion of concrete types (bitmap, grayscale, luminance + alpha, rgb, rgb15, rgb16, rgb24, rgba, abgr, bgr, rrr....bbb...ggg..., etc., images) in imaging and graphics. - -- Legalize Adulthood! ``Ain't it funny that they all fire the pistol, at the wrong end of the race?''--PDBT legalize@xmission.com - -------------------------------------------------------------- Thanks for using Fractdev, The Fractint Developer's Discussion List Post Message: fractdev@lists.xmission.com Get Commands: majordomo@lists.xmission.com "help" Administrator: twegner@phoenix.net Unsubscribe: majordomo@lists.xmission.com "unsubscribe fractdev" ------------------------------ End of fractdev-digest V1 #20 *****************************