Cute Skunk wrote:

I've done a bunch of diffs between the xfractint-20.2.04 source and the regular DOS 20.2.4 source. The following files are exactly the same: ... These files are slightly different.. but they differ in the same sort of ways as DOS 20.0 differs from DOS 20.2..

3d.c cmdfiles.c encoder.c fractint.c fractsrc.doc loadfdos.c printer.c read.me zoom.c biginit.c cmplx.h evolve.c fractint.h helpdefs.h miscovl.c prompts2.c realdos.c

How's that?

These differ even more...

calcfrac.c fracsubr.c fractals.c framain2.c jb.c line3d.c lorenz.c lsys.h miscres.c mpmath_c.c prompts1.c externs.h fractalp.c fractype.h frasetup.c jiim.c loadfile.c lsys.c miscfrac.c mpmath.h parser.c prototyp.h

(Alot of it seems to be floating point stuff, and JuliBrot stuff)

Unless you got hold of the float only source, that shouldn't be the case. OTOH, I haven't been very reliable at preparing patches. Hmm, since I don't upload the DOS source (only patches)...

These files appear ONLY in the DOS version:

FRACTINT.LNK calmanfp.asm fr8514a.asm fractint.def lsysaf.asm parsera.asm tplus_a.asm big.inc calmanp5.asm frachelp.mak fractint.mak lyapunov.asm sound.c uclock.c bignuma.asm fpu087.asm fracsuba.asm general.asm makefrac.bat sschoice.asm uclock.h bigport.inc fpu387.asm fractint.cfg hgcfra.asm newton.asm tplus.dat video.asm

That would be correct.

And these files appear only in the XFractint version:

Makefile* default.map* fracsuba.c fractint.frm* if_else.txt* phctutor.frm* testfpu.par* video.c altern.map* demo.par* fract18.par* fractint.ifs* leebg.frm phctutor.txt* tiling.l* xfract_a.inc calcmand.c diskvidu.c fract19.par* fractint.l* leebg.par phoenix.par* tplus_a.c xfractint.man* calmanfp.c file_id.diz fract200.frm fractint.par* lyapunov.par* test.frm unix.c calmanfx.asm fpdebug.txt fract200.par general.c music.par* test.par unix.h cellular.par* fpu087.c fractint.doc* icons.par* penrose.l* testbug.par* unixscr.c

(some of them are in the regular DOS EXE distrib though)

Anyway, I was going to merge these two branches back together if no one minds. (There will be one code base and you just specify something at compile time to get one version or the other out)

If you want to do that, we should start with a synched source. That will ensure you aren't fixing things that aren't broke. Or, at least have a reason for being broke.

(I'm kinda thinking of seperating the actual math stuff from the UI stuff entirely as I said (like creating 'fractintlib.dll'?), but thinking about how to do it make me wonder about DOS compatability. Mostly with small memory models, and I don't think DOS can really multi-thread (The Linux version I'm working on now forks a sub proccess to handle signals and stuff (currently not needed for anything under dos though)) I think if I decouple the math stuff from the UI stuff then it will be possible to not have some fractal types be 'interupted' by going back to the menu, and even to allow computation to continue in the background while you have switched back into text mode for some reason (like hitting <TAB> or <ESC>) This will probabilly be a major code restructureing though.)

(oh and the file path/name handling code needs to be portable as well, Fractint won't have to know what's physically 'out there', so if you want to fetch/store stuff in a funky memory card on your cell phone, you only have to change one thing. I'm just going to write it for dos and linux for now, but I'm thinking maybe also treating .ZIP files as read-only directories, so you can use your 600 .PAR files while they're still archived. Useful if you run off floppys or something (which I used to do))

By the way, is there anyone 'officially' in charge of the 'official' version of fractint, like how Linus or Alan are in charge of the Linux kernel. I don't know if I would need to OK big changes in the structure of fractint's source code with anyone.

I like to think that Tim is 'officially' in charge. Jonathan

Jonathan wrote:

I like to think that Tim is 'officially' in charge.

I am willing to be the official dictator, but what Jonathan says has a lot of weight with me :-) Tim

On Tue, 5 Nov 2002, Tim Wegner wrote:

Files with the same name are identical in the same version of fractint and xfractint. What may be confusing is that we have both a traditional and a float only version (the latter with the integer math removed). While we haven't quite decided to stop maintaining the traditional version, the integer math clearly has no future.

Yes, that is it exactly. (And I was wondering that about the float-only version) The interger only code might still be useful for legacy systems (The DOS port and *nix on a 386 or 486SX and any other old platform that someone wants to port to) But it would be easiest for the core to be float-only, and then let indivuduals porting to legacy platforms put the integer code back in.

...

Anyway, I was going to merge these two branches back together if no one minds. (There will be one code base and you just specify something at compile time to get one version or the other out)

I'm not sure what you mean needs to be merged. There is no point in having an Xfractint version of the traditional code, since the integer mode doesn't work in Xfractint anyway, although we still have such a version.

Ok I wasn't aware of the foating point change (why the integer stuff was going away) when I wrote that last message; Or aware of all the changes between the two code branches, I diff'ed them to try to get an idea.

All future work should be based on the float-only version. If you look at www.fractint.org, you will find two versions of fractint and two versions of Xfractint at revision 20.2 patch 4. The corresponding versions (traditional or float only) share identical files. It would be possible to have the files for both fractint and xfractint in a single directory with different make files.

I only found frasrcfo20.2.04.zip and xfract20.2.04.zip, hence the confusion. I'll work off the floating point version from now on. Placeing the regular fractint and xfractint together and using different make files was what I was thinking of. In the future the windows/mac/beos/palm/whatever port would be handled in the same way.

There are a lot of issues you would need to understand in order to enable changes to backport to the current DOS version. At a certain point (the sooner the better) we want to cut free of the DOS limitations, but attempts to do so inevitably reduce the feature set.

This was my big worry, and why I didn't want to just start changing stuff. I want to try to maintain DOS compatability as it is now. But the easiest way I think to do this is a rewrite of the main loop that behaves from the user's point of view just like it does now, but internally it may be radically different. (This is mostly for developers' benifit) I think what I would do is have something like the startvideomode(), writevideo(), readvideopalette(), type of stuff that is there now, but.. moreso. There's still alot of "if (dotmode==11)" stuff scattered all over the place, which I want to package up into a generic video object so that the main code doesn't care what's physically going on. (This will also make it easier to write code to draw on multiple windows/screens at once or to scroll around a very large fractal) Oh I also want to seperate the sxdots,sydots from the video driver, so that you can change them independantly in the UI, but this will break DOS compatability. It will make it easier though to resize windows with no special exceptions. For the linux framebuffer version I'm pulling the video modes out of /etc/fb.modes, which can be almost anything (I have "352x240-158Hz" in mine for example), but it's always the same video driver. In the DOS version stuff is hard coded to certain specific drivers in the list, irregardless of sxdots,sydots, and colors.

We do welcome you. Let's hear more about what you want to do.

Once I have have fractint running on the Linux console (which it mostly does now except for some palette stuff and keyboard funkyness, the /cleanest/ way to fix this would probabily break DOS compatibilty which was why I was asking.) Then I'll start adding stuff, here's my TODO list: - rewriting x86 assembly from DOS version to assemble with as or nasm (Keeping the C source too of corse for non-x86 platforms) - MMX, 3DNow and SIMD assembly code (I can only use MMX and 3DNow with the proccesor I have now) - Maybe seeing if I can compile my framebuffer version for the ARM to run on my roomate's Sharp Zaurus - Browseing .zip files as directories. I've already written code to do this in Java, I just need to port it to C. (It's so cool, it's a recursive IO stream, so you can read zipfiles within zipfiles within zipfiles just like they were sitting in a normal directory) - PNG support, I might change the format for how the parameters get stored in the comments since this is a clean break from the GIF stuff. I'm not sure if anything should be done with the alpha channel yet or not. - Related to PNG... 24-bit color and reorganization of global variables.. this would bump up the version number. - PBM output for batchmode, maybe. New palette tricks (cycle R, G, B seperately), glancing at the wish list, someone mentioned the ability to produce animations natively. (Output as animated GIF or FLI?) Various other user bells and whistles. - um.. anything else I said yesterday.

The main legacy entanglements are these:

1. DOS-based video using the frame buffer, and exploiting a VGA characteristic that leaves most of video memory unchanged when changing between graphics and text modes. (Xfractint avoids this by making the graphics screen separate from the text screens.)

I've kinda been considering making the core of fractint just think that it's always using diskmode, and then having the device specific stuff just suck stuff out of diskmode memory.. but I'm worried that it'll break DOS compatability (with people who have no EMS/XMS or just 2M or RAM or somehting (like I used to)) Experimenting with something like this this morning it can be slow at times, but I think I can rewrite it to leave most of the stuff in the framebuffer memory. A side effect of doing this though is that if you do have enough memory, it would be possible to implement an undo feature by keeping around some of your old buffers. (You could just keep a table of all the old parameters too, but there's no recalc this way. (no more, arrg I just wiped out a pic that took 48 hours, etc. etc.)) There may be some kinda of effect you could do if you had more than one image to work with as well, etc. Insted of just storing the image in memory, you could actally store the iteration counts, and then have an engine which renders the picture off of that. That way you can turn log palettes on and off without needing to recalculate everything, maybe switch between real and imaginary for the outside points in realtime, etc. etc. (real and imag maybe not, but you could set some of the outside colors without needing to start over)

2. The medium memory programming model. Once we get off this we can drastically revise (and simplify) memory allocation.

I havn't looked in memory.c yet, I'm guessing that it's only /needed/ by DOS?

The assembler is no longer much of an entanglement since Xfractint solved that long ago, and recently Jonathan has ported some assembler to linux.

Yes, the Xfractint code made many things much more portable, most of the hard work for porting has already been done by the Xfractint maintainers.

For me preserving the feature set and targetting multiple platforms (primarily Windows, Linux/BSD and the Mac) are a high value to hold.

I think, Windows, *nix, and Mac maintainability/compatibility will be easier to achive between the three of them than between any one of them and DOS.

We need to begin migrating the files to another license, and there should be an understanding that all the sources and any new contributions will end up being licensed under GPL (or another open source license). We made need to make them LGPL at first until the whole program can be made GPL.

I was wondering about that too... and how the code would be migrated to a new license... Anyway, thanks for the info.

On Wed, 6 Nov 2002, Jonathan Osuch wrote:

Cute Skunk wrote:

...

I think what I would do is have something like the startvideomode(), writevideo(), readvideopalette(), type of stuff that is there now, but.. moreso. There's still alot of "if (dotmode==11)" stuff scattered all over the place, which I want to package up into a generic video object so that the main code doesn't care what's physically going on. (This will also make it easier to write code to draw on multiple windows/screens at once or to scroll around a very large fractal)

That's a good idea. We are running into just that problem with patch 5. We had to put in a bunch of instances of "if (dotmode==28)". Easier said than done, of course.

I'm considering going through and labeling all of the random constants in the code like this: #define VID_DISK 11 #define VID_CUSTOM 19 #define VID_VESA 27 #define VID_CGA 13 ... #define CALC_NONE -1 #define CALC_CHANGE 0 #define CALC_ACTIVE 1 #define CALC_RESUME 2 #define CALC_NORESUME 3 #define CALC_COMPLETE 4 ... And so on, and so on.. I'm also thinking of taking all of the global variables that are all over the place and sticking them into neat little structs, and probabily making them not even be global anymore. At the very least I want to put all of the math stuff all by itself so that a new UI core could be dropped onto it easilly without having to touch anything inside the fractal code. And people could write new fractal stuff without having to worry about what's happening to their globals elsewhere in the program.

I have most of the work done porting the formula paser to nasm. I prefer nasm because of its availability on various platforms.

Coolness.

...

- PNG support, I might change the format for how the parameters get stored in the comments since this is a clean break from the GIF stuff. I'm not sure if anything should be done with the alpha channel yet or not.

This can't be done with the medium memory model based C code used for the DOS Fractint.

I'm not /that/ familiar with the medium memory model. Is it that there isn't enough room for the PNG code itself, or enough memory for the encoder/decoder to work in? As I understand PNG it's basically just a zlib stream decoder with some chunks for palette and image resolutions. So should have low overhead. (tangent: The fractint stuff put into GIF comments now could be placed directly into a fINT (or apropreatly named) chunk)

Skunky asked:

I'm not /that/ familiar with the medium memory model. Is it that > there isn't enough room for the PNG code itself, or enough memory for the encoder/decoder to work in? As I understand PNG it's basically just a zlib stream decoder with some chunks for palette and image resolutions. So should have low overhead. (tangent: The fractint stuff put into GIF comments now could be placed directly into a fINT (or apropreatly named) chunk)

This is more than you are ever going to want to know about the medium memory model. In this model, addresses to functions are far, but addresses to data are near. That means that there is only 64K TOTAL (!) for data that can be addressed with normal (near) pointers. That's a SINGLE 64K segment. Code can fit into multiple 64K segments. However, memory can be allocated to pointers that are explicitly declared far. But most standard library functions work only with near pointers in the medium model (we have written far versions of some of these.) Fractint copes with this truly horrible limitation by the following means. 1. Overlays. A lot of code is swapped to disk. This has to be done carefully, because pointers pointing to data that is swapped to disk point to garbage when the relevant overlay is not resident. Fractint is WAY bigger than 640K, that fact that it runs at all, with almost unnoticeable performance degradation due to overlays, is a miracle. 2. Reusing fixed arrays. Fractint depends very little on dynamic memory allocation. Several large arrays (64K long) are created at startup and reused for many different purposes (e.g. - grep for "extraseg". 3. swapping information to extended/expanded memory. All this has been accomplished artfully and debugged thoroughly, and is very robust, but you have to be careful or the DOS version will break if you add anything major. But when we bust out of this prison, the very first thing we can do is get rid of the re-use of arrays and allocate memory dynamically. I am one of the original members of the PNG team, and in fact reserved a chunk for fractal data (fRAc). This has never been defined, and we can still use it when we are ready. You can imagine that if there were any way to add PNG support to Fractint we would have done it. Adding PNG support to Xfractint is very easy. I did it once in an afternoon. But adding PNG support to Fractint is utterly impossible, at least inside a monolithic program. Once I got as far as getting a Fractint executable to compile with PNG support, but it failed at runtime. The memory demands are far too great, much more than GIF. If you look at the GIF decoder and encoder, they just re-use a couple of the afore-mentioned arrays. There is one way we could add PNG support to Fractint, but I decided against it. We could write a separate program using djgpp and execl it from fractint. This would involve a kludge like writing out a big flat file (or even a GIF!!) then execl-ing a program that would read that file and write the PNG, conversely for reading. Bad, bad, bad. I am deeply committed to adding PNG support, but we can't do it until we are ready to leave DOS (or more accurately, the medium memory model) behind. (If we converted the DOS version over to djgpp and ran it in a console, we could add PNG easily.) I suggest we divide your various projects up and implement them in phases, doing the ones that can be backported to DOS first. I know you are enthgusiastic about PNG, but I believe things will work out better if it is added after we are free of the medium model. Consolidating the various global variables into some carefully designed structures is a good place to start. This should be possible to backport into the DOS version. BTW, there is a free Watcom compiler that still supports the medium memory model. Jonathan and I use the last DOS Microsoft compiler. It is probably possible to port Fractint to Watcom with little trouble, and then if you (and others) have a Windows or a DOS environment you could compiler Fractint yourself and test your changes. Of course it is also possible to fork the project and leave DOS behind immediately. Paul de Leeuw has done this with Manpwin. His development environment is any compiler that supports the Windows 32 bit API. But he never got any of us to help him (even though we support and approve of the effort) because we didn't have the windows skills and weren't interested in getting them. Paul had to drop a large amount of the Fractint feature set and was in the process of trying recover more of it. My bias (and I think Jonathan's also) is to be protective of the Fractint feature set, and not embark on a course which abandons a lot of functionality. What is so remarkable about Xfractint is that it shares sources with Fractint, and we could maintain it long after the original author left, and it preserves nearly the whole feature set. Ironically, one hope for not abandoning our DOS/Windows user base might be to backport Xfractint to djgpp! I know Jonathan has worked on this with some success. An alternative approach (which I suggest with some trepidation) would be this. Folks don't scream, last time I made a suggestion like this there was an alarmist reaction on the fractint list :-) This is a brainstorm idea not a decision!! 1. Consolidate the current version and make a LAST DOS fractint version. Which, of course, doesn't rule out continued maintinence at the glacial pace we have been maintaining it recently :-) 2. Starting with the Xfractint Float only version, begin a radical transformation that would be evolutionary in that at each step it would preserve the feature set. Do stuff like: a. relicense the code - which means re-write all the parts by people we can't contact. If there are no other proposals I suggest GPL. I think this is closer to the original fractint license than BSD - we wouldn't want people to take our code and make a closed-source program. The current license forbids using the code for a commercial fractal program. But I wouldn't care if someone made an open source commercial program out of Fractint. b. Undo all the array re-use and make the memory management something reasonable (I would favor writing our own malloc and free that would do bookkeepping to avoid memory leaks. This is fairly easy.) c. Separate the GUI from the underlying engine as Rich suggested a long time ago. But beware, some features, such as orbits and inverse julia windows, assume a frame buffer and will take some creative disentangling. d. Separate GUI projects could be done on different platforms. Maybe this could be merged in with manpwin on Windows. Or ... d'. Make a portable GUI using WxWindows. Then we could target many platforms with ONE source base. I am not opposed to option d., but I personally prefer d'. I am personally willing (even enthusiastic) about learning ONE GUI development environment, so without knowing anything about it, I prefer WxWindows. :-) e. Add the much delayed missing features. These are: True color support, PNG support, and a carefully designed fRAc chunk for storing fractal data. f. Of stuff on skunky's list. This steps don't have to be exactly ordered this way. The Windows world is well populated with fractal programs. But as far as know, there's room for a very full featured Linux-based fractal program. Tim

Rich wrote:

With the proper layer separating GUI from application code, there is no need to try and shoehorn every platform into a single GUI source base.

Exactly my point. If the GUI and underlying Fractal engine were separated, there could be a native Windows GUI. I meant no disrespect to you when I said *I* wasn't interested in programing a native Windows. I'm personally interested in WxWindows, but I didn't mean that you shouldn't have other interests. One of the source bases could be platform independent. Others could be platform specific. These are not mutually exclusive options. I don't think the demands Fractint places on the interface are too great. This might work in favor of writing native GUIs.

Each platform can have the GUI that works best for it -- on the Mac this means Toolbox, on Windows this means Win32 (and maybe even MFC), on X11 this means Motif, and on DOS it probably means Allegro with a 32-bit extender.

I'm not arguing with you here (though you might think I am.) WxWindows can be compiled to use Motif, GTK+, or Win32. My understanding that this works very well. However, the proof is in the pudding.

I know that if fractint gets ported to "WxWindows", the end result is that I'll probably never work on improving the Windows GUI or the X11 GUI in fractint. Learning WxWindows would be a dead-end for me; it has no market payoff and with my limited amount of time available for fractint coding, I would probably put the effort in elsewhere.

Rich, at present, neither you nor I are putting any time into fractint, so our votes don't count. :-) If fractint gets ported to WxWindows, that would not prevent you or Paul de Leeuw or anyone one else from making a Win32 GUI for fractint. There is no reason why there couldn't be more than one GUI front end, just as there's a X and a DOS front end now. I have my own personal reasons for what technology I am interested in for myself (and my interests can change). Learning a GUI platform not a career skill I will be using at work, so that limits me. I am still a software engineer, but doing scientific programming. The technology future versions of fractint use will depend in large part on skill, willingness to understand the program, and the willingness and ability to invest time. Tim

Hi Guys,

If fractint gets ported to WxWindows, that would not prevent you or Paul de Leeuw or anyone one else from making a Win32 GUI for fractint. There is no reason why there couldn't be more than one GUI front end, just as there's a X and a DOS front end now.

I guess that the main problem I have with FRACTINT is that the code is complex in structure. There are so many dependencies on optimisations for speed that go back to early versions of FRACTINT. It is very hard to use separate bits of the code in isolation. I would love to merge all of the FRACTINT functionality into MANPWIN but I find it difficult to pull out individual pieces of code to migrate across. There are so many variables which are globals and trying to find where they are initialised and exactly what they do is very difficult. This is why I have been floundering a bit. If the code could be more modularised (a horrendous task) porting would be simplified immensly. (Just my 2 cents worth :o) Regards, Paul. ---------------------------------------------------------- Paul de Leeuw Computers Central Coast Australia Email: pdeleeuw@deleeuw.com.au www: <http://www.deleeuw.com.au> ABN 72 360 822 562 ----------------------------------------------------------

On Thu, 7 Nov 2002, Tim Wegner wrote: [...]

Fractint copes with this truly horrible limitation by the following means. [...] All this has been accomplished artfully and debugged thoroughly, and is very robust, but you have to be careful or the DOS version will break if you add anything major. But when we bust out of this prison, [...] Adding PNG support to Xfractint is very easy. I did it once in an afternoon. But adding PNG support to Fractint is utterly impossible, at least inside a monolithic program. Once I got as far as getting a Fractint executable to compile with PNG support, but it failed at runtime. The memory demands are far too great, much more than GIF. If you look at the GIF decoder and encoder, they just re-use a couple of the afore-mentioned arrays.

I'm starting to look through the GIF code right now. I'll write a inflate/deflate routine that uses memory in the same way as the LZW stuff does now. (dstack and stuff or decoderline1? (I'll figure it out))

I am deeply committed to adding PNG support, but we can't do it until we are ready to leave DOS (or more accurately, the medium memory model) behind. (If we converted the DOS version over to djgpp and ran it in a console, we could add PNG easily.)

That would require the user to have at least a 386 I think.

I suggest we divide your various projects up and implement them in phases, doing the ones that can be backported to DOS first. I know you are enthgusiastic about PNG, but I believe things will work out better if it is added after we are free of the medium model.

(comments below)

Consolidating the various global variables into some carefully designed structures is a good place to start. This should be possible to backport into the DOS version.

For performance reasons I'd leave some variables global to reduce calling overhead, but alot of them arn't critical like that. I mostly go tinto this code clean-up mindset when I was tring to change the keyboard input handling a bit and wasn't sure if I should modify getakey(), xgetkey(1), getkey(), getkeyint(1), getkeyint(block), keypressed(), etc. etc. (xgetkey is the answer mostly) And just dropping the framebuffer code into where the Xlib stuff is now in xfractint gives you a fractint that goes into graphics mode once the first time, and then never goes back into text mode again until you exit. I had to write a kludgy redraw screen thing to switch back and forth. I'm not sure if there is a proper function that is being used for this already in the DOS version (because I know it does it there, but the setvideotext(), setforgraphics(), setfortext(), savecurses(), stackscreen(), etc. etc. don't seem to do what I think they do)

BTW, there is a free Watcom compiler that still supports the medium memory model. Jonathan and I use the last DOS Microsoft compiler. It is probably possible to port Fractint to Watcom with little trouble, and then if you (and others) have a Windows or a DOS environment you could compiler Fractint yourself and test your changes.

I think I'm going to have to setup a DOS development enviroment for the near future.

Of course it is also possible to fork the project and leave DOS behind immediately. Paul de Leeuw has done this with Manpwin. His [...] My bias (and I think Jonathan's also) is to be protective of the Fractint feature set, and not embark on a course which abandons a lot of functionality. What is so remarkable about Xfractint is that it shares sources with Fractint, and we could maintain it long after the original author left, and it preserves nearly the whole feature set.

Ironically, one hope for not abandoning our DOS/Windows user base might be to backport Xfractint to djgpp! I know Jonathan has worked on this with some success.

(see below)

An alternative approach (which I suggest with some trepidation) would be this. Folks don't scream, last time I made a suggestion like this there was an alarmist reaction on the fractint list :-) This is a brainstorm idea not a decision!!

1. Consolidate the current version and make a LAST DOS fractint version. Which, of course, doesn't rule out continued maintinence at the glacial pace we have been maintaining it recently :-)

Or perhaps, a last real-mode DOS version.

2. Starting with the Xfractint Float only version, begin a radical transformation that would be evolutionary in that at each step it would preserve the feature set.

Do stuff like:

a. relicense the code - which means re-write all the parts by people we can't contact. If there are no other proposals I suggest GPL. I think this is closer to the original fractint license than BSD - we wouldn't want people to take our code and make a closed-source program. The current license forbids using the code for a commercial fractal program. But I wouldn't care if someone made an open source commercial program out of Fractint.

Politics.. fun fun. GPL sounds good, but figuring out who has to ok what code to relicense will probabily be more work than reimplmenting stuff from scratch. I'm not that sure really what else would need to be done to relicense the code if we couldn't get OKs from everyone ever involved with it. The best time to do this would probabily be at the next radical change for fractint. (which is what you said so I don't know why I repeat it here) Also this brings to mind making a fractal library out of the math core of fractint, so that you can use it from GIMP or something. (Or easilly write a new UI for fractint)

b. Undo all the array re-use and make the memory management something reasonable (I would favor writing our own malloc and free that would do bookkeepping to avoid memory leaks. This is fairly easy.)

*nodnod*

c. Separate the GUI from the underlying engine as Rich suggested a long time ago. But beware, some features, such as orbits and inverse julia windows, assume a frame buffer and will take some creative disentangling.

Indeed. I'm still becoming familiar with the code currently.

d. Separate GUI projects could be done on different platforms. Maybe this could be merged in with manpwin on Windows. Or ...

d'. Make a portable GUI using WxWindows. Then we could target many platforms with ONE source base. I am not opposed to option d., but I personally prefer d'. I am personally willing (even enthusiastic) about learning ONE GUI development environment, so without knowing anything about it, I prefer WxWindows. :-)

Lately I've been thinking that what may be easiest for everyone involved might be to make a GPL fork from the current Fractint, port it to Windows/ *nix/MacOs, and then port it back to real-mode DOS. Or, try to keep as much code as possible the same between the two versions, so that core features could be easilly put into both at once. This second option may be more work (tring to keep the same code base).

e. Add the much delayed missing features. These are: True color support, PNG support, and a carefully designed fRAc chunk for storing fractal data.

I think these should be done before a complete fork, otherwise I fear that they won't make it back into a DOS version. Makeing parts of the current version into more of a self-contained black-box will also help greatly when the time comes to branch the code. (Unless we do a complete rewrite/translation) Ok so to summerize, furutre directions: (Ordered by priority) 1. Retain /all/ current features 2. Be GPL 3. Be multi-platform 4. real-mode DOS compatable (or should this be above 3.) 4. Then new features(?)

On Fri, 8 Nov 2002, Tim Wegner wrote:

...

Ok so to summerize, furutre directions:

(Ordered by priority)

Did you mean priority in imporatnace or in time?

By importance.

...

2. Be GPL

This can be done as we go. I can identify all the files that are already OK and those that need to be rewritten or the authors contacted. Maybe we need to make the files LGPL so the licenses can be mixed, then change to GPL when done.

I can see using the LGPL (lesser GPL) so that the GPL'ed code can be mixed with the non-GPL'ed code left over. But at the same time it could also allow a closed source commercial program to use Fractint, which is about the only explicit condition in Fractint's license now. ... or maybe not

...

3. Be multi-platform

Yes, but we can work on one platform first. There is, however, one huge advantage to multiplatform. More people can help. For example, Rich and Paul are interested in Windows. Jonathan and I can support either the DOS or X version.

If DOS Fractint was moved to a linear memory model, then you could have the exact same source for every platform including DOS. Portability and DOS (med mem) seem to be mutually exculusive at this point. Which one is more important?

...

4. real-mode DOS compatable (or should this be above 3.)

I think we start out making changes to Xfractint and Fractint in parallel. When we reach a dead end, we work in 32 bit version. However once there is a console version under Linux, how hard would it be to port that to a Windows console version?

Not very hard.. speaking of which.. I've rewritten the framebuffer code four times now and I still can't get it to switch back and forth between text and graphics mode in any predictable manner. Otherwise it works (well, Plasma broke again, which was weird because it used to work..) The way that the Xfractint version (that I'm building on) seems to work is that... it doesn't switch back and forth between text and graphics mode. I'm thinking I might have to resort to changing around some of the logic flow going through the menus for the console version. So far, I've only written stuff into unixscr.c, and at best I can get it to redraw when it should about 1/2 of the time. The three states currently are (text mode) "Press operation key, or blah...", (text mode) <blankness> and (graphics mode) <fractal> I can do some convoluted things to get this part to work, but then I can't switch back out of graphics mode, or something else unexpected happens. There's like several different paths through the code calling several different functions for whatever the current state should be, but they're all interdependant on each other. And I'm still not sure what I should call when switching VTs, because I really need something to redraw the screen baised on whether it was in text or graphics mode previously, but there isn't an easy way to tell. (The Xfract version doesn't do anything like this, and seems to have turned this sort of stuff off from the DOS version. I'm a little leary to start poking around all over the place turning DOS stuff back on because it might break the X version.) (but anyway..) A windows console version that looks and feels just like the X version would be easy to do, just drop the appropriate windows graphics calls into unixscr.c wherever something X related is, and it should work. (That's pretty much what the linux console version I wrote does.) You'd probably need ncurses, or equivalant, in your windows environment too. (Oh and there's the matter of path name seperators and such, but for Windows they're the same as for DOS)

One item not on your list would be to back port assembler into the 32 bit versions where a bottleneck can be identified. Thjis would be a lower priority.

I'm not sure how much faster hand optimizing the floating point code right now would be, compaired to the cc output. But, for things like using the MMX instructions to do 8 integer operations per clock cycle, that could be useful. I can see the KNI (or Streaming SIMD or whatever Intel calles it now) stuff being very useful too, although I don't have the hardware to work on it currently. Oh, and another thing... If this project is going to get big, do you think there should be a CVS server up somewhere. (Maybe a project on sourceforge.net?) And also I've been wondering.. if Fractint no longer has any interger math in it... then is it really still fractINT?

On Mon, 11 Nov 2002, Tim Wegner wrote:

...

Not very hard.. speaking of which.. I've rewritten the framebuffer code four times now and I still can't get it to switch back and forth between text and graphics mode in any predictable manner. Otherwise it works

I don't quite see the point of switching between text and graphics, since the two-window Xfractint version avoids the problem altogether. Have you seen Winfract work? It works like Xfractint, with separate text and graphics screens, but it also has a GUI interface.

Xfractint has two windows, which is why it never has to switch back and forth between them. On the console however I currently only have one window so to speak. Also I should explain, when Linux is using the framebuffer for the console, it is always in graphics mode, the 'text' terminals are drawn by the kernel with the video card set to your favorite graphic mode. If you've drawn something onto the framebuffer, and then the console prints some text, it will draw it ontop of your graphics. This isn't much of a problem as I can keep a copy of the graphics elsewhere in memory and copy it back to the screen, but in Xfractint there's no odvious function that signals *when* to do this. The flow is like this, Xfractint starts, calls UnixInit(), initUnixWindow(), setvideotext(), ..., startvideo(), setforgraphics()... and then doesn't call discardgraphics() and setvideotext() until you exit the program. So when you're at the "Press operation key..." prompt and you escape back to the menu... the menu gets drawn ontop of the graphics 'window' on the framebuffer, nothing was called except for maybe unstackscreen() and stackscreen(), when you select "return to image" it'll redraw the "Press operation key" prompt and /not/ signal in anyway that the graphics should infact be redrawn. The closest function I've found is resizeWindow(), but using that for redraws has quirks. Anyway, I just need to 1. redraw and not-redraw the image at the right time. 2. reset the pallette too when going back to the menus, and 3. clearing the screen at the right times, and not at the wrong times. I would think that setvideotext() would do that, but it never gets called in Xfractint until exit. Otherwise this version seems to work perfectly (read, identical to X11) I can probabily do a svgalib version as well once this is done just by replacing a few functions with their svgalib equivalants. With svgalib I might not even have the above problem as text and graphics don't live in the same memory, it's much closer to DOS and X11 in that respect.

If you really want a console version that cannot have two windows, why not do the simple, brute force thing and save the entire graphics image to large array in memory? This can be coded in a few min utes. Fractint's original tricks with video memory were due to severe memory constraints. Even fairly old machines no longer have limitations of memory that prevent saving the graphics screen.

This is was I had to resort to.

I am sure you are aware (don't mean to preach) that the rule about optimizing is only optimize if there is a demonstrable bottleneck.

...

From experience, I'd say we almost always saw significant benefit from carefully coding the inner fractal loop. The formula parser (a central feature of Fractint that must be preserved, and probably expanded) also benefited a lot from the assembler rewrite.

My philopsophy for where to optomize first: Code that gets called a few million times (math) => fast Code that gets called once or twice (like menus) => doesn't matter

In any case, we can optimize later. The second rule of optimizing is get the algorithm right, then optimize. The third rule is all rules have exceptions (except this one). :-)

(nodnodnod)

want to look into using subversion instead of CVS. CVS does not have the notion of a multi-file patch (same reason Linux doesn't use CVS).

I've been looking into bitkeeper and subversion. I'm leaning towards subversion, but I havn't had much experience with either yet.

...

And also I've been wondering.. if Fractint no longer has any interger math in it... then is it really still fractINT?

My initial response is that we want to keep the names Fractint and Xfractint for historical reasons, even when the integer math is gone.

It's like the ax, that you replace the blade, and then replace the handle... is it still the same ax as it was before? Over the last few years I've replaced each part of my computer. Do I still have the same computer which I had originally?

In article <3DCFEA27.22195.21ABDD@localhost>, Tim Wegner <twegner@swbell.net> writes:

[...] CVS does not have the notion of a multi-file patch (same reason Linux doesn't use CVS).

What is "multi-file patch"? I've yet to encounter a reason -not- to use CVS. -- Ask me about my upcoming book on Direct3D from Addison-Wesley! Direct3D Book <http://www.xmission.com/~legalize/book/> izfree: Open source tools for Windows Installer <http://izfree.sourceforge.net>

In article <3DD154D5.2081.8EEDB8@localhost>, Tim Wegner <twegner@swbell.net> writes:

CVS is fundamentally file oriented, not patch or release oriented.

A patch is just a diff. CVS can produce diffs easily. I'm not sure what you mean by "release oriented". A release is a snapshot of the evolving code base made at a point in time. Tags are used to identify the versions of the files in a release.

A typical patch involves several files. There might even be several different patches that affect the same file.

CVS has no problem generating a patch as a diff between two tags. (A tag is just a symbolic name associated with a particular file revision.)

We could recover "patchlevel" information using dates. CVS also has a tag feature that I haven't used.

You could use dates, but tags are easier.

CVS doesn't handle renaming files other than by deleting the old and creating the new (thereby losing the history).

When you delete a file in CVS, it isn't permanently deleted. It goes into the "Attic" and can be regenerated when you check out old versions before the file was deleted. The old file has its revision history intact. The new file starts out with a new revision history. Its true that CVS doesn't have a "rename" command that identifies this scenario. In practice, it hasn't been a problem for me on all the projects I've used CVS for revision control. The first checkin of the new file says something like "see old_file.c for revision history before this file was renamed to new_file.c", and then you look at old_file.c's revision history if you really need to see it. In practice, I found that we really didn't rename files that often and even when we did, we didn't need to look at the revision history of the old file. But it is there, if you need to look at it. You just need to understand how CVS operates to see it. If you really feel its important to have the revision history intact then there are ways you can diddle the Repository directly, but they have drawbacks -- basically they break attemps to check out old versions of the code.

CVS handles binary files poorly (so I have read).

CVS handles ibnary files just fine. What it doesn't know how to do is diff a binary file, so it stores a copy of the file every time you check it in, since it doesn't know how to make a diff. In practice, this wasn't a big problem for us. Things like word documents are binary files, and we simply stored the new version of the document. If you want diffs, then you should convert binary files to a text representation before checking in the file. XML is a nice metastandard for representing all kinds of things as text these days.

Subversion is a program that aims to remedy these defects.

OK, I looked at their home page. It seems interesting, but I don't know that fractint's needs aren't already served by CVS. My instinct is to stick with tools that I know are stable and work. I'm in no rush to adopt a replacement for CVS unless I have a reason. SVN does have a solution for the file rename problem that looks good, but I didn't see anything on their web site about binary diffs. Since fractint doesn't have any binary files (well, there are some .o files, but you don't actually expect that you'll be sending diffs of .o files, right? You diff the assembly that gneerated the .o and send a new .o), I don't think CVS would be cumbersome for fractint. The place where binary files comes up often is using CVS for web sites that have images. -- Ask me about my upcoming book on Direct3D from Addison-Wesley! Direct3D Book <http://www.xmission.com/~legalize/book/> izfree: Open source tools for Windows Installer <http://izfree.sourceforge.net>

Jonathan wrote:

My immediate goal is to get patch 5 fixed so it can be released.

Then we could make a new official version based on patch 5 and release it as an official version. This is long overdo anyway.

IMO, the source to start any future work from is the experimental Allegro source. It is Rich's source with the integer math removed. It's a fairly simple matter to switch it back to the X11 GUI he was working on. Once I'm finished with patch 5, I can work on making it run. I was working on that just after I had put patch 4 into the code.

I'm OK with using the allegro version as a base (with some reservations about the license, see below) if we can make two fully functional versions for DOS and X. It's important to that it is thoroughly tested with all features intact so it can be a strong baseline going forward. The advantage of this approach is that right at the getgo the medium model is gone so we can make a memory management overhaul an early priority. The Allegro license is a bit strange. It looks close to "public domain". It looks like we could abtract what we need and relicense it (with credit of course), but I'm not sure. How much of the API are we using? Isn't there a GNU svgalib? Is that an option? If we don't relicense allegro, I don't think we can use GPL. We might have to use a different license. It would be good to settle the license stuff at the begiing to avoid trouble later. Tim

Rich wrote:

Just to make it 'official'. Everything I've written for fractint can be put under LGPL or GPL. I don't know if any of the code I've contributed had that in it explicitly, so I'll state it now for the record.

Thanks. I think this will be sufficient, as long as we do use GPL. This looks good to me right now. Having just read the GNU home page, there are many licenses that the Free Foundation calls "free". But if I don't here an alternate suggestion from the team (with reasoning), I say our consensus is GPL. Each file needs to have a copyright notice to somebody. We'll figure this out as we go. Maybe the copyright should be Jonathan and myself, except for files that have some other clear author. I was looking at the Xaos source, and many files have copyrights to several people. Tim

Jonathan wrote:

Run the source through indent, and start developing using the float > only version.

I have struggled mightily with indent in the past. The problem is that there are many commenting styles in fractint. There is no one indent configuration that doesn't totally trash some of the comments extensively. I would LOVE, though, to have a consistent coding style. I guess what we have to do is decide a set of indent settings, determine what commenting style those settings support, and massage the comments as we touch files.

My intention was to dump the Allegro portion. Because it is so slow, it probably isn't good for much except as examples of how to set up the code.

OK. Now I am confused about what we propose to start with. Do you propose to convert your Allegro version (based on Rich's changes) back to X, and have that be our starting point? Does that have all the changes of the latest patch? If we are stopping work on the DOS version, I won't try to get the DOS version compiling with Watcom. Tim

Rich,

...

OK. Now I am confused about what we propose to start with. Do you propose to convert your Allegro version (based on Rich's changes) back to X, and have that be our starting point? Does that have all the changes of the latest patch?

I'm confused too -- I can't remember how the Allegro version fits into all of this. Jonathan, can you refresh us?

The Allegro version is your source (changed to float only) with an Allegro driver file added. It worked fairly well, except for speed which I attribute to problems with the Allegro code. All my work was done with their development code, so their latest stable code may be different. I haven't gotten things running with it, however. Jonathan

Rich,

...

The Allegro version is your source (changed to float only) with an Allegro driver file added.

Ah. OK, cool. Can you post a URL for this version?

The patch 3 version is on the developer's web site. http://www.fractint.org/ftp/experimental/ The file is: allegro_port_xfract_fo20.2.03.zip Jonathan

Rich & Tim,

I'm not worried about debates to determine a style. I have read so much code I'm easy on which style but I like consistency. Jonathan doesn't seem very argumentative either :-).

No, not argumentative. Other than we really should do it. My .indent.pro file contains -nut, which forces spaces instead of tabs. The default style is the gnu style (indent 2.2.7). I haven't seen any of the problems Tim talks about, but I haven't looked at every comment, either. Jonathan

Which file is the one that was so munged by indent?

It was a long time ago, but it doesn't matter. Once we decide on a style, we'll just have to bite the bullet and do tedious reformatting of comments that don't work. The trick is only to choose a commenting style that indent preserves. This is only a one-time hit. Once things are cleaned up, new comments will be indent-compatible and all is well. Tim

Rich wrote:

...

Hi, I've been using Fractint since version 16 or 17 I think. And just last night I finnaly got around to coding some stuff in it. So far I've written a new graphics driver for the Linux console framebuffer (It's alot faster than X) But going through the code I've been thinking of 'tidying up' a bit of the UI code.. basically putting all of the graphics routines and keyboard/mouse input behind one general API, that the main program would call. This will make porting fracting much much easier. The menus can be abstracted too as well. [...]

This sounds very much like what I did to xfractint a while back. Did that code ever get incorporated into the base, or is it orphaned on a branch?

Yes, it's orphaned. I never did get it working again. Jonathan