Hi Richard, I'm not sure that it is all that difficult. 1. True colour: Instead of 256 colours, I generate a palette which stretches from 0 to maxiter which has calculated RGB triplets and these are plotted to memory instead of the normal palette. The palette only requires 6 integers to creat as opposed to 256 in a normal 256 colour palette. This part is real easy. I have it woking for 16 bit iteration values. So the iteration count is used to index through the rgb palette table as before. The only consequence is that it is not reversable and a set of RGB triplets may be duplicated in the table so an array of integers is needed for getpixel() I'm not sure what these "layers" are. 2. Colour modification (requires GUI) 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 GUI is required to modify these 6 integers. It can be done manually, but that would be a lot of rework when we go full GUI. 7. Clipboard support Edit -> copy or control C and the clipboard contains the image being displayed 9. Use of WM_COPYDATA message This is a piece of cake to implement. The message passes a pointer to a slab of RAM and the size of the data being sent. It can be in any format. I use it to send text, binary data or images. A structure is used to hold these pointers. I have even sent device contexts. The code for all these exist in ManpWin already so it only becomes a merge issue. 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, 1 February 2007 8:20 AM To: Fractint developer's list Subject: Re: [Fractdev] x11 update Paul, Here are my comments on what needs to happen to fractint before we introduce these: In article <011101c74570$a0ef27b0$0301a8c0@Production>, "Paul" <pdeleeuw@deleeuw.com.au> writes:
1. 24 bit colour
Oooh, big change here, I think. There is already some truecolor support in fractint, but I think its just supporting truecolor *modes* and doesn't get much deeper than that. I'm not 100% sure about that. What I always wanted to do for FractInt was extend the formula mechanism so that you write a formula that computes a color (RGB *plus* alpha) from the iteration count and other orbit information. The next natural thing is to have layers that blend together after you've got alpha flying around.
2. Colour modification (requires GUI)
Can you explain what this is a little more? Is it your truecolor ramps?
3. PNG files for true colour
This would be easy to add right now and wouldn't be affected by any of the big changes coming.
4. Animation script generation and running - Zooming in on most fractals - Julia animation - following linear, circle and cardioid (main bulk
of mandelbrot set) paths
This would be good to add after the code is re-structured and separated.
5. A couple of silly plotting modes - horizontal blinds - vertical blinds
:-) These might also be easy to add into the existing plotting code -- where solid guessing, boundary trace, etc., are done.
6. Real time 3d generation (this is not as good as FRACTINT, but it saves a lot of tedious mucking about in hyperspace with files)
For 3D, fractint needs OpenGL or Direct3D IMO. This is also a fairly big change. The current 3D code is doing all the rendering in software, which is OK, but won't ever take advantage of that hardware just itching to be used.
7. Clipboard support
Can you elaborate on this? We could probably accommodate this now as its just processing the appropriate window messages, I think.
8. Undo (revert back to previous image)
FractInt has this now in its history mechanism. (Ctrl+H or Ctrl+\, I can't remember offhand right now.)
9. Use of WM_COPYDATA message to allow other programs to send FRACTINT fractal data and to allow FRACTINT to send back an image etc (This allows for fractal processing without needing to restart FRACTINT every time). I have a client that uses this for fractal evolution. He sends me the fractal parameters and screen size etc and I return the image. He can scan through large populations fairly quickly.
IMO, this would be better implemented by separating the engine into a library or a COM object. Using windows messages for IPC is a kinda Windows 3.1 style, although it is easy to implement. COM, or even web services, would be a better mechanism for implementing this now. Once the engine is separated out, wrapping a COM object or a web service around it should be fairly easy. -- "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