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