Is the WinFract code from the fractint module supposed to compile anymore? :-) -- "The Direct3D Graphics Pipeline" -- DirectX 9 draft available for download <http://www.xmission.com/~legalize/book/download/index.html> Legalize Adulthood! <http://blogs.xmission.com/legalize/>
Rich asked:
Is the WinFract code from the fractint module supposed to compile anymore? :-)
Winfract is compiled with a 16 bit compiler, in fact the same one that we use for the DOS fractint. Winfract has the same segmented medium memory model as the DOS version. That's why the code is mostly compatible. For a long time Winfract was frozen the way Bert Tyler left it, but not too long ago Jonathan began work to bring it up to date. He mostly suceeded, but there are still some things broken. There is no hope of compiling Winfract with a modern 32 bit compiler. You might compile it with the same old compiler you used for DOS. Tim
In article <456C6EA2.1589.F92F0@twegner.swbell.net>, "Tim Wegner" <twegner@swbell.net> writes:
There is no hope of compiling Winfract with a modern 32 bit compiler.
Ah, OK. Then I'll just steal its implementation where reasonable and write from-scratch Win32 code where its unreasonable. -- "The Direct3D Graphics Pipeline" -- DirectX 9 draft available for download <http://www.xmission.com/~legalize/book/download/index.html> Legalize Adulthood! <http://blogs.xmission.com/legalize/>
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 ---------------------------------------------------------- -----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 Richard Sent: Wednesday, 29 November 2006 10:23 AM To: Fractint developer's list Subject: Re: [Fractdev] WinFract compiling? In article <456C6EA2.1589.F92F0@twegner.swbell.net>, "Tim Wegner" <twegner@swbell.net> writes:
There is no hope of compiling Winfract with a modern 32 bit compiler.
Ah, OK. Then I'll just steal its implementation where reasonable and write from-scratch Win32 code where its unreasonable. -- "The Direct3D Graphics Pipeline" -- DirectX 9 draft available for download <http://www.xmission.com/~legalize/book/download/index.html> Legalize Adulthood! <http://blogs.xmission.com/legalize/> _______________________________________________ Fractdev mailing list Fractdev@mailman.xmission.com http://mailman.xmission.com/cgi-bin/mailman/listinfo/fractdev
In article <003001c71347$13e355e0$0301a8c0@Production>, "Paul" <pdeleeuw@deleeuw.com.au> writes:
There IS a beginning point to start with 32 bit code, but for some reason, nobody wants to look at it.
Well. I guess it depends on what you mean by "32 bit code". Currently the existing code is compiling just fine under a 32-bit memory model. When I say "Win32" I'm referring to all the business of creating an HWND and doing all the I/O. I'm happy to steal from what you have (hey, I'm lazy!) if you can post a URL to a ZIP or tarball or something. -- "The Direct3D Graphics Pipeline" -- DirectX 9 draft available for download <http://www.xmission.com/~legalize/book/download/index.html> Legalize Adulthood! <http://blogs.xmission.com/legalize/>
G'donya Richard, That's the spirit :) I have uploaded a zip file: http://home.exetel.com.au/paulians/download/ManpWINSrc.zip Have a play first to see what it does: http://www.deleeuw.com.au/download/SetupManpWIN.exe Please let me know if there are any missing files. 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 ----------------------------------------------------------
There IS a beginning point to start with 32 bit code, but for some reason, nobody wants to look at it.
Well. I guess it depends on what you mean by "32 bit code". Currently the existing code is compiling just fine under a 32-bit memory model. When I say "Win32" I'm referring to all the business of creating an HWND and doing all the I/O. I'm happy to steal from what you have (hey, I'm lazy!) if you can post a URL to a ZIP or tarball or something. --
In article <003c01c71349$c4bd9e50$0301a8c0@Production>, "Paul" <pdeleeuw@deleeuw.com.au> writes:
I have uploaded a zip file:
http://home.exetel.com.au/paulians/download/ManpWINSrc.zip
Have a play first to see what it does:
Ah, this name sounds familiar. I think I poked at it in the mid to late 90s! What version of FRACTINT/WinFract did you use as your starting point? If its too long ago, I may use it as "inspiration" and not a literal copy/paste :-). -- "The Direct3D Graphics Pipeline" -- DirectX 9 draft available for download <http://www.xmission.com/~legalize/book/download/index.html> Legalize Adulthood! <http://blogs.xmission.com/legalize/>
Hi Richard, It was the source of Winfract v18.2 a long time ago. Regards, 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 Richard Sent: Wednesday, 29 November 2006 11:45 AM To: Fractint developer's list Subject: Re: [Fractdev] WinFract compiling? In article <003c01c71349$c4bd9e50$0301a8c0@Production>, "Paul" <pdeleeuw@deleeuw.com.au> writes:
I have uploaded a zip file:
http://home.exetel.com.au/paulians/download/ManpWINSrc.zip
Have a play first to see what it does:
Ah, this name sounds familiar. I think I poked at it in the mid to late 90s! What version of FRACTINT/WinFract did you use as your starting point? If its too long ago, I may use it as "inspiration" and not a literal copy/paste :-). -- "The Direct3D Graphics Pipeline" -- DirectX 9 draft available for download <http://www.xmission.com/~legalize/book/download/index.html> Legalize Adulthood! <http://blogs.xmission.com/legalize/> _______________________________________________ Fractdev mailing list Fractdev@mailman.xmission.com http://mailman.xmission.com/cgi-bin/mailman/listinfo/fractdev
In article <003c01c71349$c4bd9e50$0301a8c0@Production>, "Paul" <pdeleeuw@deleeuw.com.au> writes:
I have uploaded a zip file:
OK, I looked at this and attempted to compile it. I get some compile errors in the bignum code (I'm using VS.NET 2003): Bignum.c(23) : error C2059: syntax error : 'type' Bignum.c(28) : error C2059: syntax error : 'type' Bignum.c(33) : error C2059: syntax error : 'type' Bignum.c(38) : error C2059: syntax error : 'type' Bignum.c(47) : error C2059: syntax error : 'type' Bignum.c(54) : error C2059: syntax error : 'type' Also, its going to be a *lot* harder to take advantage of this code because you've changed the names of almost all the source files so a simple "diff and merge" approach can't be used like I was able to do with my old fractint driver code from '99. This means that I will have to study your source code and assimilate its structure to understand how it can be leveraged against fractint. -- "The Direct3D Graphics Pipeline" -- DirectX 9 draft available for download <http://www.xmission.com/~legalize/book/download/index.html> Legalize Adulthood! <http://blogs.xmission.com/legalize/>
Hi Rich, I had to cut out a lot of code that was difficult to upgrade to 32 bit and didn't support my implementation of true colour. I wanted to use the fractint algorithms as much as possible, but found the same old problems that you are dealing with at the moment. So I cheated and just picked out the stuff I wanted. Fractint has so much wonderful code in it, but it lacks modularity. Hence, my code is a bowl of spaghetti as well :) We'll get there.. I'm sure. Thanks for your efforts. 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=telstra.com@mailman.xmission.com [mailto:fractdev-bounces+pdeleeuw=telstra.com@mailman.xmission.com] On Behalf Of Richard Sent: Thursday, 30 November 2006 12:18 PM To: Fractint developer's list Subject: Re: [Fractdev] WinFract compiling? Rich writes:
I have uploaded a zip file:
Also, its going to be a *lot* harder to take advantage of this code because you've changed the names of almost all the source files so a simple "diff and merge" approach can't be used like I was able to do with my old fractint driver code from '99. This means that I will have to study your source code and assimilate its structure to understand how it can be leveraged against fractint.
Paul wrote:
There IS a beginning point to start with 32 bit code, but for some > reason nobody wants to look at it.
In my case, I'm interested but don't have the skills. I apologise if you thought we weren't interested. Rich does have the skills, so I'm sure he can get ideas from what you have. Jonathan's windows skills have increased by hacking on Winfract, but he'd probably not admit to being a windows programmer. But then Bert wrote Winfract originally with no Windows skills at all, learning as he went. What Rich is doing is ambitious - he is attempting a full-featured port of the DOS version to 32 bit Windows by abstracting the GUI in a cleaner way.
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.
What you attemped is devilishly difficult because you have to understand, and basically re-implement, everything. As you have said yourself in the past, you were limited by your knowledge of the legacy code. A more literal port has it's own challenges, but has the advantage that it leverages the original code better, and if the effort succeeds with the new compile environment, then you have a working feature complete (albeit ugly) program that can be refactored incrementally. This isn't a debate, because the practical outcome determines if the porting approach works. Rich has yet to prove his port will work :-) Yours worked fine, but had a reduced feature set (plus some attractive new features - e.g. true color). We shall see. Tim
Hi Tim, Yes I understand where you are coming from and it would be ideal to have it work that way. The difficulty we all faced was the enormity of the task before any workable solution was reached. I guess I would rather have a working cut down version that full functionality in potential. The other thing that I have done a lot of work on is animation scripting. I have done a number of zooms and I am experimenting withy different paths around and across the Mandelbrot set to generate Julia set animations. This is fun. The code is not too difficult and maybe it can be ported to the code that Rich is producing. The idea that I had with using my case as a base is it is easier for task segmentation. A number of functions could be spread out amongst the team and each of us port a function or two into the WIN32 code and we all watch as the WinFractNew grows before our very eyes :) like the growth of the deep zooms before math coprocessors. Anyway, the interest that we all have in the final outcome should keep us going. Thanks guys, 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 ---------------------------------------------------------- What you attemped is devilishly difficult because you have to understand, and basically re-implement, everything. As you have said yourself in the past, you were limited by your knowledge of the legacy code. A more literal port has it's own challenges, but has the advantage that it leverages the original code better, and if the effort succeeds with the new compile environment, then you have a working feature complete (albeit ugly) program that can be refactored incrementally. This isn't a debate, because the practical outcome determines if the porting approach works. Rich has yet to prove his port will work :-) Yours worked fine, but had a reduced feature set (plus some attractive new features - e.g. true color). We shall see. Tim _______________________________________________ Fractdev mailing list Fractdev@mailman.xmission.com http://mailman.xmission.com/cgi-bin/mailman/listinfo/fractdev
In article <456C865C.17827.2E1983@twegner.swbell.net>, "Tim Wegner" <twegner@swbell.net> writes:
In my case, I'm interested but don't have the skills. I apologise if you thought we weren't interested. Rich does have the skills, so I'm sure he can get ideas from what you have. Jonathan's windows skills have increased by hacking on Winfract, but he'd probably not admit to being a windows programmer. But then Bert wrote Winfract originally with no Windows skills at all, learning as he went.
Oh man! The WinFract author learned Windows as they went?!? Well, that certainly explains some things :-). If you ever want to learn Windows and you're a sequental mass absorber of APIs like me, then give "Win32 Programming" by Rector and Newcomer a try. Not only will you understand everything about how Windows works as a GUI framework, but amazingly enough most of it translates directly to the .NET Framework classes as well. Which shouldn't be a big surprise as .NET is simple a cleaning up of Win32 :-). Win32 is object oriented programming C style -- handles and functions that take the handle as the first argument. Amazingly enough, this is exactly how the driver is implemented in my new fractint code :-). .NET takes all the same concepts but exposes them as real methods on real classes and not funky global functions that take a magic 'this' pointer style first argument.
What Rich is doing is ambitious - he is attempting a full-featured port of the DOS version to 32 bit Windows by abstracting the GUI in a cleaner way.
Honestly I was inspired by what Xfractint had been doing! Xfractint replaces a few low-level routines in order to implement the features it exposes. It stubs out a bunch of other routines for features it blows off :-). I gathered all of that together into one central location and changed all the source code to call into the central location functions instead of the original functions. On the fractint driver, the original functions become the implementation of the driver. Now that I think about it, I'm not sure the 16-bit code will *ever* compile and run properly again because I didn't pay any attention to overlays and crap like that when I added the driver implementation. That probably messed up the segment sizes for the overlays in a way
Rather than trying to hack the entire code (many have tried this),
I'm doing it! :-)
why not start from a known working base and port functions across, one at a time. I use MS Vis C++ version.
Umm... its more connected like a rat's nest communicating through global variables than it is a highly modular piece of code that can be brought over in chunks :-). There is a certain modularity to things, but due to the memory constraints there are a *lot* of really weird memory usage things going on with globals and variables defined in the assembly language for dog's sakes!
[...] A more literal port has it's own challenges, but has the advantage that it leverages the original code better, and if the effort succeeds with the new compile environment, then you have a working feature complete (albeit ugly) program that can be refactored incrementally.
Yes! This is exactly the idea. The kind of "refactoring" I've done so far has amounted to global search and replace of code fragments. Things like "change all calls to mute() to calls to driver_mute()." I don't need to understand what "mute()" does (although its name implies its function in this case) or even what the code is doing that is calling mute() -- I just need to systematically replace all the instances of calling mute() with driver_mute(). Then I implement driver_mute() in the fractint driver by calling mute(). In the Win32 driver, this would ultimately hook into DirectX at some point for sound support. Heck, on an SGI unix box you might have it hooked into the sound support for the SGI machines. (I don't think the X Window System ever incorporated a sound API, did it?) You'd definately want the sound support on an Amiga!
This isn't a debate, because the practical outcome determines if the porting approach works. Rich has yet to prove his port will work :-)
I'm confident that it will work. I am to the point now where I could run it in the debugger and I bet everything would start up just as if you started the DOS version and didn't hit a key. Of course hitting a key on this version doesn't do anything yet, so its not useful either :-). I found out about cygwin/X today, so I can get a nice X server to run on my Windows box and (amazingly!) compile the X11 client on xmission and display on my local box. I did this before when debugging on it, but the X server wasn't that great; I'm hoping the cygwin/X server will be better. At any rate, I'm first going to work on a simple GDI implementation before worrying about the X11 one. I'll be massaging the existing X11 implementation into the driver framework like I'm doing with the fractint code path. I'm not even sure the Amiga code path is really there, it seems to live on in a few #ifdef references in some header files, but doesn't really seem to have an implementation laying around. I'll try to write some kind of porting guide for future ports. -- "The Direct3D Graphics Pipeline" -- DirectX 9 draft available for download <http://www.xmission.com/~legalize/book/download/index.html> Legalize Adulthood! <http://blogs.xmission.com/legalize/>
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
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
In article <00ae01c713e2$51e8b3d0$0301a8c0@Production>, "Paul" <pdeleeuw@deleeuw.com.au> writes:
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.
In the new driver interface, the HWND would just be a member variable of the driver structure. This structure gets passed around to all the driver routines so you always have it available. This will be necessary if we get to the point where you can have multiple plot windows open simultaneously. You need a way to store all the per-window information. (Again, we're a long way from that, but its nice to keep the target in mind.)
[...] One other difference in my code is the ability to directly go to 3d transformations.
There is limited 3D code in fractint right now, but its pretty weak and only works with certain fractal types (i.e. not even all 3D fractal types share this IIRC).
Even if you don't use my program base, I would like true colour and animation algorithms put into the final production versions :)
This would be a good thing to merge in after this driver work is done.
Thanks guys, this activity is really exciting.
My hope is that the work I'm doing will make it easier for others to contribute to an ever-improving FractInt for Windows. -- "The Direct3D Graphics Pipeline" -- DirectX 9 draft available for download <http://www.xmission.com/~legalize/book/download/index.html> Legalize Adulthood! <http://blogs.xmission.com/legalize/>
Hi Rich, It may be worth looking at some of my dialogue boxes so that you don't have to create them all from scratch. It is easier to modify an existing one than to start all over. Just an idea :) Seeya, 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 Richard Sent: Thursday, 30 November 2006 9:53 AM To: Fractint developer's list Subject: Re: [Fractdev] RE: start fm a known working code base & portfunctionsone at a time In article <00ae01c713e2$51e8b3d0$0301a8c0@Production>, "Paul" <pdeleeuw@deleeuw.com.au> writes:
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.
In the new driver interface, the HWND would just be a member variable of the driver structure. This structure gets passed around to all the driver routines so you always have it available. This will be necessary if we get to the point where you can have multiple plot windows open simultaneously. You need a way to store all the per-window information. (Again, we're a long way from that, but its nice to keep the target in mind.)
[...] One other difference in my code is the ability to directly go to 3d transformations.
There is limited 3D code in fractint right now, but its pretty weak and only works with certain fractal types (i.e. not even all 3D fractal types share this IIRC).
Even if you don't use my program base, I would like true colour and animation algorithms put into the final production versions :)
This would be a good thing to merge in after this driver work is done.
Thanks guys, this activity is really exciting.
My hope is that the work I'm doing will make it easier for others to contribute to an ever-improving FractInt for Windows. -- "The Direct3D Graphics Pipeline" -- DirectX 9 draft available for download <http://www.xmission.com/~legalize/book/download/index.html> Legalize Adulthood! <http://blogs.xmission.com/legalize/> _______________________________________________ Fractdev mailing list Fractdev@mailman.xmission.com http://mailman.xmission.com/cgi-bin/mailman/listinfo/fractdev
In article <00ce01c71418$3ab660f0$0301a8c0@Production>, "Paul" <pdeleeuw@deleeuw.com.au> writes:
It may be worth looking at some of my dialogue boxes so that you don't have to create them all from scratch. It is easier to modify an existing one than to start all over. Just an idea :)
It is my full intention to steal as much as possible from other FractInt variants! As I said, I'm a "lazy" programmer in that I try to do things in the simplest form and cribbing source code from other FractInt variations is much simpler than writing it from scratch! -- "The Direct3D Graphics Pipeline" -- DirectX 9 draft available for download <http://www.xmission.com/~legalize/book/download/index.html> Legalize Adulthood! <http://blogs.xmission.com/legalize/>
Hi Rich, Goody, how soon can we have a "working" module to play with? I also hope that we don't include any 3rd party libraries apart from freeware such as the PNG libraries. Let's keep the code as generic as possible. I am not sure what Allegro is, but I have never seen it and don't understand its purpose. 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 ----------------------------------------------------------
It may be worth looking at some of my dialogue boxes so that you don't have to create them all from scratch. It is easier to modify an existing one than to start all over. Just an idea :)
It is my full intention to steal as much as possible from other FractInt variants! As I said, I'm a "lazy" programmer in that I try to do things in the simplest form and cribbing source code from other FractInt variations is much simpler than writing it from scratch! -- "The Direct3D Graphics Pipeline" -- DirectX 9 draft available for download <http://www.xmission.com/~legalize/book/download/index.html> Legalize Adulthood! <http://blogs.xmission.com/legalize/> _______________________________________________ Fractdev mailing list Fractdev@mailman.xmission.com http://mailman.xmission.com/cgi-bin/mailman/listinfo/fractdev
In article <00cf01c7141c$57ce34c0$0301a8c0@Production>, "Paul" <pdeleeuw@deleeuw.com.au> writes:
Goody, how soon can we have a "working" module to play with?
If you have access to the CVS repository, you can get it anytime :-). My next batch of concentrated time on this will come over the Christmas/New Year's holiday break.
I also hope that we don't include any 3rd party libraries apart from freeware such as the PNG libraries.
I'm not doing anything like that yet. Just trying to get the existing fractint code up and running in Win32.
I am not sure what Allegro is, but I have never seen it and don't understand its purpose.
Allegro is a game programming library that supports a number of platforms. Theoretically if you had a fractint allegro driver, then porting fractint to those other platforms is "just" a recompile. I say "just" because fractint has platform dependencies leaking all through it and the driver abstraction doesn't fix all those issues. More on Allegro: <http://www.talula.demon.co.uk/allegro/> -- "The Direct3D Graphics Pipeline" -- DirectX 9 draft available for download <http://www.xmission.com/~legalize/book/download/index.html> Legalize Adulthood! <http://blogs.xmission.com/legalize/>
Paul, Thanks for the links to the great animations! The only one that did not download was: http://home.exetel.com.au/paulians/images/Cubic03.gif I especially liked the smoothness of the movement of the point around which the zoom was being done. - 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: Wednesday, November 29, 2006 1:15 PM To: 'Fractint developer's list' Subject: RE: [Fractdev] RE: start fm a known working code base & portfunctionsone at a time
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
_______________________________________________ Fractdev mailing list Fractdev@mailman.xmission.com http://mailman.xmission.com/cgi-bin/mailman/listinfo/fractdev -- No virus found in this incoming message. Checked by AVG Free Edition. Version: 7.1.409 / Virus Database: 268.14.19/556 - Release Date: 11/28/06
-- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.409 / Virus Database: 268.15.2/559 - Release Date: 11/30/06
Thanks for the links to the great animations! The only one that did not download was:
http://home.exetel.com.au/paulians/images/Cubic03.gif Yep. I can't get it either. But the others from Paul are great! Lee
Dear Friends, Teeeheee it doesn't exist. Let me know if you want more info on how I did them. ManpWin is used in 360 * 255 pixel mode (Shift Z) and is freely available from my website www.deleeuw.com.au I then use blaze media pro to generate an uncompressed AVI file and Microsoft GIF animater to convert it to GIF. I also love doing Julia animations by plotting various paths across the M set. I want to develop this a lot futher. Many of my ideas come from the early Art Matrix video I got back in the '80s. 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 Lee H. Skinner Sent: Friday, 1 December 2006 5:07 AM To: Fractint developer's list Subject: Re: [Fractdev] RE: Thanks for the links to the great animations!
Thanks for the links to the great animations! The only one that did not download was:
http://home.exetel.com.au/paulians/images/Cubic03.gif Yep. I can't get it either. But the others from Paul are great! Lee _______________________________________________ Fractdev mailing list Fractdev@mailman.xmission.com http://mailman.xmission.com/cgi-bin/mailman/listinfo/fractdev
Hi Guys, I just added the ability for ManpWin to be controlled by external applications by use of the WM_COPYDATA message. This allows external applications to continuously control ManpWin for a series of fractal generations without closing the application. Eg for fractal image recognition and complex animation scripts. Let me know if anyone wants the updated source files. I canm also give the spec for a controlling application to create the WM_COPYDATA message structure. 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 ----------------------------------------------------------
Teeeheee it doesn't exist. Don't worry about the missing animation file. I just wanted to document the bad link.
Again; great videos!
Many of my ideas come from the early Art Matrix video I got back in the '80s.
I still have a couple of different fractal videos from Art Matrix (early version and final version, perhaps -- as well as some fractal Fortran code I bought from them. I might be able to eventually find the code if someone is interested in it -- but, I recently moved, so...) Believe it or not, I was sort of a distributor for Art Matrix's videos -- I sold a number of them to aficionados where I worked at the time... I always enjoyed talking with them (Homer Wilson Smith and Jane Elizabeth Staller) on the phone -- homer@lightlink.com or (607) 277-0959 is what is listed on the web site. The web site: http://www.artmatrix.com/ still exists! They have some very Fractint-like images in their gallery: http://www.artmatrix.com/cgi/gallery.cgi They were really dedicated to sharing fractals with as many people as they could. Their practical experience marketing fractal-based material (videos, post cards, etc.) eventually showed that it was difficult to be a sustainable 'mainstream' enterprise (e.g. repeating ads in Scientific American, etc.) - 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: Thursday, November 30, 2006 7:30 PM To: 'Fractint developer's list' Subject: RE: [Fractdev] RE: Thanks for the links to the great animations!
Dear Friends,
Teeeheee it doesn't exist.
Let me know if you want more info on how I did them. ManpWin is used in 360 * 255 pixel mode (Shift Z) and is freely available from my website www.deleeuw.com.au I then use blaze media pro to generate an uncompressed AVI file and Microsoft GIF animater to convert it to GIF.
I also love doing Julia animations by plotting various paths across the M set.
I want to develop this a lot futher. Many of my ideas come from the early Art Matrix video I got back in the '80s.
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.15.6/565 - Release Date: 12/2/06
Hi Hal, I still have all their fortran programs and have used them for creating a number of the fractals in ManpWin. It has been a lot of fun working with this stuff over the years. I have a box of slides and their video as well as a number of fractal post cards. Those were exciting days. I can still remember the first time I saw the Scientific American and the wonderful pictures and the monochrom code I wrote for the Apple 2+. It took an hour to plot simple zooms in interpreted basic. There was no symmetry, guessing or periodicity checking and it was terribly inefficient. Thanks for the memories :) 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: Monday, 4 December 2006 6:23 AM To: Fractint developer's list Subject: [Fractdev] Re: Many of my ideas come from the early Art Matrix video I still have a couple of different fractal videos from Art Matrix (early version and final version, perhaps -- as well as some fractal Fortran code I bought from them. I might be able to eventually find the code if someone is interested in it -- but, I recently moved, so...)
Sorry Guys, There isn't one. Would you like me to create it? This is what happens when one rushes too much :) Seeya, 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=telstra.com@mailman.xmission.com [mailto:fractdev-bounces+pdeleeuw=telstra.com@mailman.xmission.com] On Behalf Of Hal Lane Sent: Friday, 1 December 2006 2:28 AM To: Fractint developer's list Subject: [Fractdev] RE: Thanks for the links to the great animations! Paul, Thanks for the links to the great animations! The only one that did not download was: http://home.exetel.com.au/paulians/images/Cubic03.gif I especially liked the smoothness of the movement of the point around which the zoom was being done. - Hal Lane ######################### # hallane@earthlink.net <mailto:hallane@earthlink.net> # #########################
In article <MDBBJLBFBICIIEIHFBMECEHFCOAA.hallane@earthlink.net>, "Hal Lane" <hallane@earthlink.net> writes:
I have always used the concept of enhancing code by adding incrementally to a working base.
That's what I'm trying to do; its just that you have to re-implement a collection of "base" routines on which everything else builds. For instance, at the moment I'm not talking about turning the 'x' parameters screen into a genuine Win32 dialog. I just implement the underlying functionality of an 80x25 "text mode" window. The routines in the implementation of the 'x' screen call other routines that switch from graphics to text and put text strings on the screen at a certain location. So the 'x' screen code just gets a function renaming change which doesn't introduce any bugs in the 'x' screen. Once you get the underlying functions working, then the 'x' screen works again.
Also, regression tests become applicable [...]
That would be a first for fractint! :-). I'm not aware of any test suite. Basically you render an image and look at it to see if it looks 'right'. I think the most pounding it gets is when a version is released into the while and people start playing with it and give feedback on crashes or incorrect renderings/behavior.
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.
That's a good idea! We could at least use that to generate a suite of baseline images from the existing code and then generate the same set from the driver code base and do a quick image compare.
With enough resources [changing all the code at once] 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.
In this case, the bugs are all located in the driver implementation. We're not changing anything in the main code about how it does its work.
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? <---<<
They're all pretty much the same with minor differences. Ultimately it would be nice to see FractInt evolve into three distinct modules: a front end UI, a calculation engine, and a back-end exporter of images and/or 3D data. In a certain sense, the code is already like this in that the engine is relatively isolated from the UI code. The back end just saves GIF/PNG when you ask for an image to be saved, but ultimately it would be nice to save Lorenz plots as 3D models, etc. The front end could then be written in whatever way was 'native' to the platform. On X11 it would probably use Motif. On Win32 it would have real dialogs for parameter screens. On the Mac it would use the native toolbox. On the Amiga it would use Intuition. However, this is a long way from where we are right now, even if my driver abstraction was fully debugged. -- "The Direct3D Graphics Pipeline" -- DirectX 9 draft available for download <http://www.xmission.com/~legalize/book/download/index.html> Legalize Adulthood! <http://blogs.xmission.com/legalize/>
Richard wrote:
Hal Lane writes:
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.
That's a good idea! We could at least use that to generate a suite of baseline images from the existing code and then generate the same set from the driver code base and do a quick image compare.
Finally had a break in this week's very busy work schedule to read through the recent postings that have been made since Sunday evening. The above is a very good idea. But how many images would be needed to make sure that all fractal types were adequately covered for the testing between OLD and NEW ?? I am willing to make time and assist in generating as many of the images as I possibly can using the current 20.4.04 version of DOS FractInt. Just not sure what should be agreed upon as the size and types to "generate a suite of baseline images". Sincerely, P.N.L. ------------------------------------------------- http://home.att.net/~Paul.N.Lee/PNL_Fractals.html http://www.Nahee.com/Fractals/
In article <456F70C3.29C9@Worldnet.att.net>, "Paul N. Lee" <Paul.N.Lee@Worldnet.att.net> writes:
I am willing to make time and assist in generating as many of the images as I possibly can using the current 20.4.04 version of DOS FractInt. Just not sure what should be agreed upon as the size and types to "generate a suite of baseline images".
I would start by using only default parameter values, default video mode (320x200x256? I can't remember) and one image per fractal type. That's still a big pile of images though because of the large number of fractal types. Also 320x200 is probably too small to be of reasonable use, so we should use 640x480 or some such. -- "The Direct3D Graphics Pipeline" -- DirectX 9 draft available for download <http://www.xmission.com/~legalize/book/download/index.html> Legalize Adulthood! <http://blogs.xmission.com/legalize/>
participants (6)
-
Hal Lane -
Lee H. Skinner -
Paul -
Paul N. Lee -
Richard -
Tim Wegner