Requst info on FRACTINT Variables for 8 bit to True colour conversion
Hi Guys, I notice that the existing code assumes that color (+dstack and others) are all BYTE. For true colour to have any use, I need to pass a minimum of 16 bits around (32K maxiter) and this is a substantial change to FRACTINT code. I have started using several #ifdef WIN32 but the code is starting to look messy. Should we all move to 16 bit colour variables? I notice that using my 16 bit put_line() does bizarre things to guessing and tessaral. I am making good progress and should have a true colour 32 bit windows version with about WINFRACT v18 functionality out there in a week or two. I will then add bignum stuff and finally bring th code up to today. Comments please. Thanks, Paul. ---------------------------------------------------------- Paul de Leeuw Computers Central Coast Australia Email: pdeleeuw@deleeuw.com.au www: <http://www.deleeuw.com.au> ABN 72 360 822 562 ----------------------------------------------------------
I notice that the existing code assumes that color (+dstack and others) are all BYTE. For true colour to have any use, I need to pass a minimum of 16 bits around (32K maxiter) and this is a substantial change to FRACTINT code.
My opinion is that you should not try to simultaneously port Fractint to Win32 and also add truecolor support. I suggest you first port to Win32. If we had a Win32 version of Fractint with good performance and everything working, then we could REALLY start making changes and improvements, because we wouldn't need the DOS version any more. Then adding truecolor could be done more gracefully. Of course you are free to disagree! Tim
On Thursday 18 April 2002 07:27 pm, PHD wrote:
I notice that the existing code assumes that color (+dstack and others) are all BYTE. For true colour to have any use, I need to pass a minimum of 16 bits around (32K maxiter) and this is a substantial change to FRACTINT code. I have started using several #ifdef WIN32 but the code is starting to look messy. Should we all move to 16 bit colour variables? I notice that using my 16 bit put_line() does bizarre things to guessing and tessaral.
So, define BYTE as 16 bits. Then see what breaks. However, consider that the iteration count (coloriter) is a long variable and what you may want to do is pass it back and forth. Or at least use it in the calculation to determine the truecolor values, since it is a global variable and hasn't been truncated as the color variable has. And, you may want to save the coloriter value to an array in memory. Yes, solid guessing and tessarel (and probably boundary tracing) have a problem with 16 bit colors. I ran into it with my Allegro port. Never solved it, however. It may be due to reading the color from the screen and not putting it on the screen. I had run into a similar problem when I was playing around with the true color modes in Fractint (yes, they are there, just no fancy coloring schemes). But, I can't recall how I fixed it, other than I'm pretty sure it was a problem with the getpixel routine. Jonathan
participants (3)
-
Jonathan Osuch -
pdeleeuw -
Tim Wegner