Hi Skunky, I have been using the PNG format in MANPWin for a while but have a problem with saving 16 bit iteration count. I am happy to progress this investigation with you. I have been trying to port FRACTINT to 32 bit windows with limited success but my own cut down program, manpwin, does work true colour and 32 bit windows. The main blocker is saving the iteration count for each pixel. this is 2 * xdots * ydots in size and needs to be compressed and loaded into the fRAc chunk. I am using the tEXt chunk for the fractal parameters. Let me know if you want to work together on development of a PNG approach. 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 ---------------------------------------------------------- ----- Original Message ----- From: Tim Wegner <twegner@swbell.net> Date: Friday, November 8, 2002 3:29 pm Subject: Re: [Fractdev] introduction and questions

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

_______________________________________________ Fractdev mailing list Fractdev@mailman.xmission.com http://mailman.xmission.com/cgi-bin/mailman/listinfo/fractdev