- Fractdev - mailman.xmission.com

Re: [Fractdev] gcc/mingw32/cygwin
by Charlie Chernohorsky 14 Nov '02

14 Nov '02

> Is anyone on here actively using this > as their Win32 development environment? well, i am using that.. why? but started just a month ago.. charlie ______________________________________________________________________ Reklama: Jake bude pocasi? http://pocasi.seznam.cz

1 2

Re: [Fractdev] gcc/mingw32/cygwin
by pdeleeuw 13 Nov '02

13 Nov '02

Hi Rich, I only use the Microsnot VC++v 4.0. I use vanilla windows API so my code remains portable into other windows environments such as Borland C++. Regards, Paul. ---------------------------------------------------------- Paul de Leeuw Computers Central Coast Australia Email: pdeleeuw(a)deleeuw.com.au www: http://www.deleeuw.com.au ABN 72 360 822 562 ---------------------------------------------------------- ----- Original Message ----- From: Rich <legalize(a)xmission.com> Date: Wednesday, November 13, 2002 4:29 pm Subject: [Fractdev] gcc/mingw32/cygwin > Is anyone on here actively using this as their Win32 development > environment? > -- > Ask me about my upcoming book on Direct3D from Addison-Wesley! > Direct3D Book <" target="l">http://www.xmission.com/~legalize/book/> > izfree: Open source tools for Windows Installer > <" target="l">http://izfree.sourceforge.net> > > _______________________________________________ > Fractdev mailing list > Fractdev(a)mailman.xmission.com > http://mailman.xmission.com/cgi-bin/mailman/listinfo/fractdev >

1 0

gcc/mingw32/cygwin
by Rich 13 Nov '02

13 Nov '02

Is anyone on here actively using this as their Win32 development environment? -- 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>

2 1

introduction and questions
by Cute Skunk 12 Nov '02

12 Nov '02

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. I want to have a console Linux version running that looks at feels exactly like the DOS version first. (Which is what I'm doing now) but if I do it right you can just drop in code for X11, or MacOS, or palm, or whatever and it'll at least work about the same. For X11 and Windows, etc. ports the possibility of a GUI comes up as well. (not that you couldn't do it anyway on everything else as we are doing our own graphics anyway) Anyway, my fear though is that I might break some of the old old DOS code for talking to a Oaktek card on an 80286 or something. I don't have the hardware at the moment to test any changes I make to make sure nothing broke. (It shouldn't as I'd just put generic wrappers around what's there now, but anyway...) I'm also going to write some new pallette stuff, and I've been thinking about writing in PNG support if that's ok with everyone.

5 42

Possible PNG memory solution
by Cute Skunk 11 Nov '02

11 Nov '02

[messages about PNG] Pasi Ojala (http://www.cs.tut.fi/~albert/Dev/) has written a version of gzip/pkzip/zip for the Commodore 64 in 6502 assembly. If the deflate methood (zlib) can be done in 16Kb then there is a way of doing it in fractint. I've written a huffman decoder before, so I don't think it would be that hard to rewrite the compression routines for what we need. I'll start working on it tonight. I think I might have a copy of MS C around here, I can setup a dos emulator and make sure that the code works in that environment. (What are DOS Fractint's minimum requirements right now? 640K and an 8086?)

4 12

License for fractint
by Tim Wegner 09 Nov '02

09 Nov '02

I did a little research, and it appears that there is no obstacle to making Fractint GPL and linking to Allegro. This subject is mindnumbingly complicated. I want to do this accurately without spending my life studying legalisms. Hopefully this is possible. :-) I have a pretty good idea which contributors gave us rights to their software. I'll try to contact others. The remaining code will have to be rewritten. While this isn't easy, neither is it a daunting impossibility. Tim

1 0

Re: [Fractdev] introduction and questions
by pdeleeuw 09 Nov '02

09 Nov '02

Hi Rich, > Yes, I understand, but an iteration count/pixel is just another > "image", with each pixel being a 16-bit value, right? This involves > taking a PNG image and storing the iteration count as another PNG > image inside a custom chunk. OK I understand. I see where you are coming from. Would we use the fRAc chunk for this? We need to define a few standards before we go in too deep. Any comments? Thanks, Paul. ---------------------------------------------------------- Paul de Leeuw Computers Central Coast Australia Email: pdeleeuw(a)deleeuw.com.au www: http://www.deleeuw.com.au ABN 72 360 822 562 ----------------------------------------------------------

4 6

Re: [Fractdev] introduction and questions
by pdeleeuw 08 Nov '02

08 Nov '02

Hi Rich, > > The main blocker is saving the iteration count for each pixel. > > I don't see why this can't be saved as a 16-bit/pixel image. I save the images as true colour which requires 24 bits / pixel. Regards, Paul. ---------------------------------------------------------- Paul de Leeuw Computers Central Coast Australia Email: pdeleeuw(a)deleeuw.com.au www: http://www.deleeuw.com.au ABN 72 360 822 562 ----------------------------------------------------------

2 1

Re: [Fractdev] introduction and questions
by pdeleeuw 07 Nov '02

07 Nov '02

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(a)deleeuw.com.au www: http://www.deleeuw.com.au ABN 72 360 822 562 ---------------------------------------------------------- ----- Original Message ----- From: Tim Wegner <twegner(a)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(a)mailman.xmission.com > http://mailman.xmission.com/cgi-bin/mailman/listinfo/fractdev >

2 1

Float-only followup
by Cute Skunk 06 Nov '02

06 Nov '02

Now having put my foot in my mouth, I compaired the float-only versions of fractint and xfractint and they are virtually identical. Only in xfractint: Makefile calcmand.c calmanfp.c calmanfx.asm default.map diskvidu.c fpu087.c fracsuba.c general.c sstools.ini tplus_a.c unix.c unix.h unixscr.c video.c xfract_a.inc Only in fractint: FRACTINT.LNK fractint.def fpu087.asm lyapunov.asm big.inc fractint.mak fpu387.asm makefrac.bat bignuma.asm general.asm fr8514a.asm newton.asm bigport.inc helpdefs.h frachelp.mak parsera.asm calmanfp.asm hgcfra.asm fracsuba.asm sschoice.asm calmanp5.asm lsysaf.asm fractint.cfg tplus.dat tplus_a.asm video.asm Everything else is exactly the same except for: debugfla.doc read.me

1 0