Hi Hal, No, I avoided using MFC for 2 reasons. One is that it is a lot harder to understand for the novice and second, I wanted to port from the existing WinFract code as much as I could. One way around the HWND (window handle) problem (that I use in another program) is to make the handle a global. But in ManpWin, I just pass it everywhere. Yep, I do all the messy stuff. One problem with comparing the images from Fractint is that my output is PNG and not GIF as I want to maintain true colour in the images. I translate 16 bit iteration counts into 24 bit colour based on a palette derived from 3 sine waves of different frequency and phase. Therefore the palette only needs 6 numbers to define it. This is not reversible, like in Fractint, however as the same RGB value may exist a few times in the final palette. Work needs to be done in storing the iteration count as a separate chunk in the PNG file structure. I have not done this yet so a resume from a saved PNG image is not possible. One other difference in my code is the ability to directly go to 3d transformations. This is fun to watch and stops the tedious mucking around with intermediate files. Once I got the true colour stuff working, I spent all my effort on animation. This is fun. Take a look at some gif animations I have created: http://home.exetel.com.au/paulians/images/manp02.gif http://home.exetel.com.au/paulians/images/manp03.gif http://home.exetel.com.au/paulians/images/Manp04.gif http://home.exetel.com.au/paulians/images/Manp05.gif http://home.exetel.com.au/paulians/images/Manp06.gif http://home.exetel.com.au/paulians/images/manp07.gif http://home.exetel.com.au/paulians/images/manp08.gif http://home.exetel.com.au/paulians/images/Julia01.gif http://home.exetel.com.au/paulians/images/Julia02.gif http://home.exetel.com.au/paulians/images/Cubic01.gif http://home.exetel.com.au/paulians/images/Cubic02.gif http://home.exetel.com.au/paulians/images/Cubic03.gif http://home.exetel.com.au/paulians/images/RatMap01.gif http://home.exetel.com.au/paulians/images/MandelLambda01.gif http://home.exetel.com.au/paulians/images/Manp3d01.gif http://home.exetel.com.au/paulians/images/Newton01.gif http://home.exetel.com.au/paulians/images/Newton02.gif Even if you don't use my program base, I would like true colour and animation algorithms put into the final production versions :) Thanks guys, this activity is really exciting. Paul. ---------------------------------------------------------- Paul de Leeuw Computers NSW Central Coast, Australia Email: pdeleeuw@deleeuw.com.au www: < http://www.deleeuw.com.au> ABN 72 360 822 562 ---------------------------------------------------------- -----Original Message----- From: fractdev-bounces+pdeleeuw=deleeuw.com.au@mailman.xmission.com [mailto:fractdev-bounces+pdeleeuw=deleeuw.com.au@mailman.xmission.com] On Behalf Of Hal Lane Sent: Thursday, 30 November 2006 4:43 AM To: Fractint developer's list Subject: [Fractdev] RE: start fm a known working code base & port functionsone at a time
comments WOULD be appreciated
OK. But, the value of my comments is suspect as I am essentially a lurker... I have always used the concept of enhancing code by adding incrementally to a working base. This allows you to have a limited area of new code to look for the cause of a problem (except for the infrequent 'legitimate' incompatibility with existing working code.) Also, regression tests become applicable using this development method which show if the added code increment broke something previously working. Fractint's built-in demo capability might be able to be used to do the regression testing -- perhaps with saved images automatically compared to reference images using a script. I can see potential problems with a pixel or two changing in an image causing a test 'failure' when math routines are modified. But this effect should be limited to modifications of the math routines. However, I see that the lure of converting an entire system to a new environment all at once is that you get all the previously running code into the new environment in one fell swoop. With enough resources this can work. But, the locality of problems in the code in the new environment is not well characterized and this is what presents the greatest challenge. When working on a problem you have to keep dealing with 'everything' 'all the time' and this has not proven tractable to others in the past. I believe that the fact that Paul de Leeuw's working 32-bit version is in MS Vis C++ is a plus, since that is: 1) a very common development environment (allowing the possibility of more developers) -- me, for example. 2) the vast majority of machines that might run this 32-bit Fractint have a MS op sys Paul (de Leeuw), Does your 32-bit Fractint code base use MS MFC? <--- << If not, am I correct in assuming that it still uses "all the business of creating an HWND and doing all the I/O." (Richard's wording.) <---<< I don't have any understanding of how a MS GUI and event-driven Fractint would be compatible with any future UNIX GUI and event-driven versions. In other words, how close do MS windowing and event-driven paradigms map to X-Windows or other UNIX windowing systems? <---<< - Hal Lane ######################### # hallane@earthlink.net <mailto:hallane@earthlink.net> # #########################
-----Original Message----- From: fractdev-bounces+hallane=earthlink.net@mailman.xmission.com [mailto:fractdev-bounces+hallane=earthlink.net@mailman.xmission.com ]On Behalf Of Paul Sent: Tuesday, November 28, 2006 6:44 PM To: 'Fractint developer's list' Subject: RE: [Fractdev] WinFract compiling?
Hi Friends,
There IS a beginning point to start with 32 bit code, but for some reason, nobody wants to look at it. I have a 32 bit, true colour fractal generator that was based on the early WinFract program and would make a nice beginning. Rather than trying to hack the entire code (many have tried this), why not start from a known working base and port functions across, one at a time. I use MS Vis C++ version.
Your comments WOULD be appreciated as I got none last time I suggested this idea.
Many thanks,
Paul.
---------------------------------------------------------- Paul de Leeuw Computers NSW Central Coast, Australia Email: pdeleeuw@deleeuw.com.au www: < http://www.deleeuw.com.au> ABN 72 360 822 562 ----------------------------------------------------------
-- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.409 / Virus Database: 268.14.19/556 - Release Date: 11/28/06 _______________________________________________ Fractdev mailing list Fractdev@mailman.xmission.com http://mailman.xmission.com/cgi-bin/mailman/listinfo/fractdev