RE: [Fractdev] GDI output working! True colour?
Hi Richard, Oops, I got a message saying that email was too big. Yes I remember the old true colour mode and it was not much use as it only gave shades of blue as no translation was done to the iteration count. My true colour algorithm creates 3 sinusoidal values for each of the red, green and blue colour streams and makes a true colour palette. All that is required is the starting point in each sine wave and the frequency. I.e., 6 integers specify the true colour palette. These are spread out according to the max iteration count. The only problem is that it is not reversible like the 256 colour map, so a separate matrix of 16 bit integers needs to be kept for the solid guessing etc to work. Image deleted to reduce file size This was the colour control dialogue box. Here is how the palette is generated: WORD RedStartInt, GreenStartInt, BlueStartInt, RedIncInt, GreenIncInt, BlueIncInt; BYTE TRUE_PALETTE[MAXTHRESHOLD * 3]; // for maximum palette /************************************************************************** Initialise True Colour Palette **************************************************************************/ void InitTrueColourPalette(BYTE RandFlag) { long i, cycle, temp; DOUBLE RedStart, GreenStart, BlueStart, RedInc, GreenInc, BlueInc; float size; static WORD Randomise; if (RandFlag) { srand((unsigned)time(NULL) + Randomise);// Seed the random-number generator with current time so // that the numbers will be different every time we run. if (RandomColourFlag) { RedIncInt = rand() / RandomDivisor; GreenIncInt = rand() / RandomDivisor; BlueIncInt = rand() / RandomDivisor; RedStartInt = rand() / RandomDivisor; GreenStartInt = rand() / RandomDivisor; BlueStartInt = rand() / RandomDivisor; } Randomise = rand(); // to prevent the same value within the second!! } RedStart = (float)(RedStartInt) / 100.0; GreenStart = (float)(GreenStartInt) / 100.0; BlueStart = (float)(BlueStartInt) / 100.0; RedInc = (float)(RedIncInt) / 100.0; GreenInc = (float)(GreenIncInt) / 100.0; BlueInc = (float)(BlueIncInt) / 100.0; temp = ((long) StartColourCycling > threshold) ? threshold : StartColourCycling; for (i = 1L; i < threshold; ++i) { cycle = temp + i; if (cycle > threshold) cycle -= threshold; size = (float) cycle / (float) ((logval != 0) ? 256 : threshold); TRUE_PALETTE[i * 3 + 0] = (BYTE)(127.0 * sin(TWO_PI * (size + RedStart) * RedInc)) + 128; TRUE_PALETTE[i * 3 + 1] = (BYTE)(127.0 * sin(TWO_PI * (size + GreenStart) * GreenInc)) + 128; TRUE_PALETTE[i * 3 + 2] = (BYTE)(127.0 * sin(TWO_PI * (size + BlueStart) * BlueInc)) + 128; } *(TRUE_PALETTE + threshold * 3 + 0) = (BYTE)InsideBlue; *(TRUE_PALETTE + threshold * 3 + 1) = (BYTE)InsideGreen; *(TRUE_PALETTE + threshold * 3 + 2) = (BYTE)InsideRed; } Here is the basic plotting routine (cut down for simplicity): Note that BYTE *pixels is the array of rgb triplets for the image to screen and WORD *wpixels is the array of iteration counts (16 bit) /************************************************************************** Get values of r, g, b **************************************************************************/ BYTE *GetRGB(DWORD colour) { DWORD j; static BYTE rgb[3]; j = (TrueColourFlag) ? colour + colour + colour : (DWORD)((colour % 256L) * 3L); *(rgb + 0) = *(PalettePtr + j + 2); *(rgb + 1) = *(PalettePtr + j + 1); *(rgb + 2) = *(PalettePtr + j + 0); return (rgb); } /************************************************************************** Plot correct pixel according to count, i, j **************************************************************************/ void outpoint(WORD x, WORD y, DWORD colour) { long i; long local_width; if (colour > (DWORD)threshold) // don't write past end of palette { if (TrueColourFlag) colour = (DWORD)threshold; else if (colour >= 255L) colour = 255L; } // first do screen if (x < 0 || x >= width || y < 0 || y >= height) return; local_width = WIDTHBYTES((DWORD)width * (DWORD)bits_per_pixel); i = ((long) (height - 1 - y) * (long) (local_width + 3 - ((local_width - 1) % 4)) + (long)(x * 3)); if (colour == (DWORD)threshold) // handle inside colour { *(pixels + i + 0) = (BYTE)InsideBlue; *(pixels + i + 1) = (BYTE)InsideGreen; *(pixels + i + 2) = (BYTE)InsideRed; } // memcpy(pixels + i, VGA_PALETTE + inside_colour * 3, 3); else memcpy(pixels + i, GetRGB(colour), 3); // Now do reference i = ((long) (height - 2 - y) * (long) (width + 3 - ((width - 1) % 4))) + (long) x; if (x >= 0 && x < xdots - 1 && y >= 0 && y < ydots - 1) *(wpixels + i) = (WORD) colour; } /************************************************************************** Read pixel colour **************************************************************************/ DWORD ingetcolor(WORD x, WORD y) { long i; long local_width; if (x < 0 || x >= width || y < 0 || y >= height) return 0L; local_width = WIDTHBYTES((DWORD)width * (DWORD)bits_per_pixel); i = ((long) (height - 1 - y) * (long) (local_width + 3 - ((local_width - 1) % 4)) + (long)(x * 3));i = ((long) (ydots - 2 - y) * (long) (xdots + 3 - ((xdots - 1) % 4))) + (long) x; if (x >= 0 && x < xdots && y >= 0 && y < ydots - 1) return ((DWORD)((*(wpixels + i)) & 0xffff)); else return 0L; } Let me know what you think :) 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: Sunday, 14 January 2007 7:18 PM To: Fractint developer's list Subject: Re: [Fractdev] GDI output working! True colour? In article <009201c737b1$e6a831b0$0301a8c0@Production>, "Paul" <pdeleeuw@deleeuw.com.au> writes:
Once you get it working a bit more efficiently, I can start preparing some true colour code for it. [...]
There is some existing truecolor support, but I haven't studied that code yet. Take a look at the existing code here: <http://www.fractint.org/ftp/current/dos/fradev.zip> -- "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 <009c01c737ca$48e49590$0301a8c0@Production>, "Paul" <pdeleeuw@deleeuw.com.au> writes:
Yes I remember the old true colour mode and it was not much use as it only gave shades of blue as no translation was done to the iteration count. [...]
Is this what currently happens? I have a feeling you might not have tried the truecolor support that is currently there. At any rate, there's still quite a bit of work to be done before incorporating new features. As Jonathan points out, I still need to get the X11 driver working and all the existing features need to be heavily tested before we merge this into the HEAD. Additionally, I'd like to have the polling architecture exchanged for a true event architecture before we add new features. This would mean separating out the calculation code from the UI code. Currently the two are a little intermingled with the calculation code periodically asking "has a key been pressed?" and then deciding what to do about the keystroke. Once the UI and calculation engine have been separated out a little more, then I feel it would be time to start incorporating new features and fractal types. -- "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,
Yes I remember the old true colour mode and it was not much use as it only gave shades of blue as no translation was done to the iteration count. [...]
Is this what currently happens? I have a feeling you might not have tried the truecolor support that is currently there.
No. The truecolor support uses the currently loaded 256-color palette. With the Allegro driver, I put the iteration count in a separate memory space. The intent was to enable the getcolor() routine to return the actual iteration count instead of a number mapped to the 0 to 255 range. This would be needed to get truecolor to work with boundary tracing.
At any rate, there's still quite a bit of work to be done before incorporating new features. As Jonathan points out, I still need to get the X11 driver working and all the existing features need to be heavily tested before we merge this into the HEAD.
You may be surprised by what doesn't work. Look at solid-guessing and boundary tracing. I never did get them to work with the Allegro driver.
Additionally, I'd like to have the polling architecture exchanged for a true event architecture before we add new features. This would mean separating out the calculation code from the UI code. Currently the two are a little intermingled with the calculation code periodically asking "has a key been pressed?" and then deciding what to do about the keystroke. Once the UI and calculation engine have been separated out a little more, then I feel it would be time to start incorporating new features and fractal types.
Doesn't the WinFract code do this, after a fashion? Jonathan
In article <1168796213.3514.20.camel@linux.site>, Jonathan Osuch <osuchj@avalon.net> writes:
You may be surprised by what doesn't work. Look at solid-guessing and boundary tracing. I never did get them to work with the Allegro driver.
Solid guessing is 'g' on the x options screen right? Both 'g' and 'b' settings for passes work great on the GDI and disk drivers right now. -- "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 said:
Solid guessing is 'g' on the x options screen right?
Correct.
Both 'g' and 'b' settings for passes work great on the GDI and disk drivers right now.
Great! - Hal Lane ######################### # hallane@earthlink.net <mailto:hallane@earthlink.net> # ######################### -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.410 / Virus Database: 268.16.10/625 - Release Date: 1/13/07
In article <1168796213.3514.20.camel@linux.site>, Jonathan Osuch <osuchj@avalon.net> writes:
At any rate, there's still quite a bit of work to be done before incorporating new features. As Jonathan points out, I still need to get the X11 driver working and all the existing features need to be heavily tested before we merge this into the HEAD.
You may be surprised by what doesn't work. Look at solid-guessing and boundary tracing. I never did get them to work with the Allegro driver.
OK, good things to look at.
Additionally, I'd like to have the polling architecture exchanged for a true event architecture before we add new features. [...]
Doesn't the WinFract code do this, after a fashion?
It does it in the fashion I'm doing now: since they keyboard is polled frequently, you sneak the event loop into the keyboard processing. This restructure is a fairly big change in that it removes all the keypressed() and getkeypress() calls from all the fractal computation code and changes the organization of the main loop. Its an even more pervasive change than the current driver model; it completely rips out all UI processing from the computation code. At the moment, what I'm thinking is that the computation code will check some global state to see if it should return or keep going as it computes. This check is what would replace the keyboard polling in the image computation code. The global state also tells the compute engine things like "the UI changed the parameters, so restart the image generation" without the UI being directly invoked by the compute code. Moving in this direction lets you do things like put the image compute code in a separate thread from the UI, factor out the engine into its own code that can be invoked by *any* UI, create a distributed parallel processing engine, etc. By separting the UI from the compute engine entirely, you can get a nice native feeling UI on each platform and they all talk through the same interface to the compute engine which doesn't change. That way you don't try and shoehorn every platform into the same UI, which is what I'm doing now as an interim step. But, as we've said, there is lots to get working before taking on that restructuring. -- "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 (4)
-
Hal Lane -
Jonathan Osuch -
Paul -
Richard