Many thanks Richard, Does X11 have any connection with the Windows version or are you doing 2 parallel developments? 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, 31 January 2007 1:10 PM To: Fractint developer's list Subject: Re: [Fractdev] x11 update In article <00c901c744db$d1edd5e0$0301a8c0@Production>, "Paul" <pdeleeuw@deleeuw.com.au> writes:

This is another of my silly questions... What is X11?

Its the windowing system for most unix machines. <http://en.wikipedia.org/wiki/X11> -- "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

Hi Richard, Now that I have declared my ignorance :) I can continue toinvestigate what the team is doing and what the outcomes are expected to be.... So as I understand it, there are 4 streams: 1. Generic fractal code (hopefully machine independent and can make up a linkable library) 2. GUI stuff that is platform dependent such as X11, Windows or MAC 3. OS stuff like file systems, timers etc. 4. Drivers for screen, printers etc This is good as it helps to compartmentalise FRACTINT. It always seemed like an amorphous mass of globals and intertwined code and it was hard to separate out modules to work with. I hope that one day some generous soul can make up some documentation of the globals and what function they all perform. This is getting real 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 Richard Sent: Wednesday, 31 January 2007 5:46 PM To: Fractint developer's list Subject: Re: [Fractdev] x11 update Once I've done the X11 driver for unix, then I'll have a better idea of which parts of the driver are really OS/platform considerations and which are driver considerations. There will probably be a little bit of cleanup in separating out what is "os" and what is driver. For instance, anything to do with times and dates or anything to do with the file system is an OS/platform issue and not a driver issue. There aren't many routines of this nature and they don't need to be dynamically switched like an output driver, so you can just compile one set of routines for an OS and link it in to resolve the issue. So if you wanted to port this code to a new machine, like the Mac, you would need to supply one set of "os" routines and a driver.

Wow Richard, I am very pleased with your approach. This sort of separation and grouping will simplify the understanding of the code greatly. I have wanted to do the same in ManpWin, but just got overwhelmed by the extent of the work. Thanks for your sterling 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=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 2:32 AM To: Fractint developer's list Subject: Re: [Fractdev] x11 update As for globals... I want to package them into structures relating to the various components. So there would be one structure that holds all the "engine" variables and variables relating solely to graphics output would be in the driver structure, and so-on. They would still be globals, but at least you could have confidence when looking at the engine code that you're looking at all the relevant quantities. Currently, I'm getting most familiar with the UI code, since that's where all the changes are in what I'm doing. There is the occasional bumbling around in other code, mostly to eliminate far-isms and things like extraseg. -- "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

Hi Richard, Well soon ManpWin will be redundant because of the "new" FRACTINT :) But I would like to have a number of goodies added first once the group is ready to let me loose on the code :) G'donya matie, 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 4:48 AM To: Fractint developer's list Subject: Re: [Fractdev] x11 update In article <010a01c7455e$650afdd0$0301a8c0@Production>, "Paul" <pdeleeuw@deleeuw.com.au> writes:

Wow Richard,

I am very pleased with your approach. [...]

Thanks. Its not hard, just tedious and nearly impossible to do without Edit / Find in files... :-) -- "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

Hi Richard, Here is the list of goodies That I have added to ManpWin. Let me know which ones can be done now and which need to wait. 1. 24 bit colour 2. Colour modification (requires GUI) 3. PNG files for true colour 4. Animation script generation and running - Zooming in on most fractals - Julia animation - following linear, circle and cardioid (main bulk of mandelbrot set) paths 5. A couple of silly plotting modes - horizontal blinds - vertical blinds 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) 7. Clipboard support 8. Undo (revert back to previous image) 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. These all currently work in ManpWin. 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, 1 February 2007 5:05 AM To: Fractint developer's list Subject: Re: [Fractdev] x11 update In article <010b01c74561$af631900$0301a8c0@Production>, "Paul" <pdeleeuw@deleeuw.com.au> writes:

But I would like to have a number of goodies added first once the group is ready to let me loose on the code :)

I was wondering if you might be able to add the animation part, but with the restructuring coming soon, it might be more trouble than its worth to add now just to have it all changed around again. -- "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

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

Paul wrote:

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 working 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()

Could the original iteration values of pixels be recovered from a True Color Fractint fractal image file at a later time by appending the six values and maxiter that generated the color triplets in an extension block appended to the image file? This would allow a different coloring to be applied to a True Color Fractint fractal image file at a later time. Perhaps this could be done as a stand alone application, perhaps as a Fractint feature. If a True Color Fractint fractal image file contained the six values and maxiter along with the image could you: - use the six values and maxiter to re-generate the table of original RGB triplets; - step through the file's pixels and look up the pixel's RGB triplet (various look-up methods come to mind) and thus - find the original iteration count of that pixel from the triplet's location in the RGB triplet table. - then use a different six values and the original maxiter to generate a new set of RGB triplets; - then build a new output image of RGB triplet pixels in the same way that the original .png image was created; - write out the newly colored output image to a file. It appears that the six values and maxiter could to be added to a .png file: http://en.wikipedia.org/wiki/Png says 'ancillary chunks' can be stored in a .png image: "Other image attributes that can be stored in PNG files include gamma values, background color, and textual metadata information." "tEXt can store text that can be represented in ISO 8859-1, with one name=value pair for each chunk." Paul, How are the six values and maxiter used to create the RGB triplets? Do you happen to know how other true color fractal programs create/specify their RGB triplets? - 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.17.18/662 - Release Date: 1/31/07

Paul, why do you do just "color = sin(c * n + d)", instead of a full "color = a + b * sin (c * n + d)"? Hal Lane asked about retrieving iteration counts of an image by reconstructing it's original hi-color palette, based on those six palette parameters.. Rich suggested encoding iterations as a grayscale PNG image.. left aside that both of these solutions do have a problem with possible rgb triplets duplicities (as Paul already pointed out), you also loose the real iteration counts anyway, as everything is just wrapped at 2^16.. and still it's not the true true-color.. i know, i know, computing sines on the fly would be insane.. but you don't need to if.. if instead of all iterations per pixel you do all pixels per iteration - and all those that bail out get the same color.. if none does, you don't even need to know the color for such iteration count.. to be honest, this doesn't solve neither duplicit triplets, nor wrapping (happens at 2^31..) but you get it true true-color, you get an improved boundary-tracing-like image evolution and you get possibly infinite iterations.. at a cost of just a few MB of memory.. and those real iteration counts? why not to simply save them in a separate "raw" binary file? (gzipped..?) P.S.: Rich, please, stick somewhere in the roadmap an SVG and an HPGL support for L-systems and that infinite looping for escapetime fractals -- tell me which of these are blocked by your current development.. Thanks. /charlie/

In article <1575.2167-28109-1183218194-1170718611@seznam.cz>, =?us-ascii?Q?charlie=20chernohorsky?= <endlessoblivion@seznam.cz> writes:

and those real iteration counts? why not to simply save them in a separate "raw" binary file? (gzipped..?)

I think PNG would actually do better at compressing them than gzip. But yeah, it doesn't really matter *how* you store them since an extension chunk is just a blob of binary data.

P.S.: Rich, please, stick somewhere in the roadmap an SVG and an HPGL support for L-systems

Hrm. I just killed printer support, so HPGL doesn't really make sense. SVG would be a good 'save' option so you can convert to other vector formats from there.

and that infinite looping for escapetime fractals -- tell me which of these are blocked by your current development.. Thanks.

You lost me with "infinite looping for escapetime fractals". Can you elaborate? -- "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/>

In article <1584.2176-29302-820979663-1170721827@seznam.cz>, =?us-ascii?Q?charlie=20chernohorsky?= <endlessoblivion@seznam.cz> writes:

...

I think PNG would actually do better at compressing them than gzip. But yeah, it doesn't really matter *how* you store them since an extension chunk is just a blob of binary data.

well, isn't a regular grayscale up to a 16 bit depth? i thought you were talk ing about something like "phantom image" with usual api constraints.. while now it seems you meant some custom data being appended.. of course it's better when it's packed together with the visual representation.. anyway, a raw outp ut (a sort of a dump) would be also of a use for postprocessing..

There are two things here. The image and the iteration counts. Both PNG and GIF image formats have extension chunks (there's one registered for fractint, but its not been specced out according to Tim). I'm saying the iteration counts would compress well as a PNG image because PNG recognizes the spatial locality of pixels while zip does not. So you can encode the iteration counts as a PNG image and stick that in an extension block designed to hold iteration counts.

with infinite iterations (more comes bellow) it's easy to get over 2^32..

OK, I see what you mean now about infinite iterations and I'd already considered that as something that's desirable before. And yeah, with deep zooms (especially arbitrary precision zooms) you could easily get over 2^32. The question is -- is it worth having a multiple precision 'int' to store the iteration counts then? I think yes for parfiles, but its less clear if we're talking about saving them with the image.

...

Hrm. I just killed printer support, so HPGL doesn't really make sense. SVG would be a good 'save' option so you can convert to other vector formats from there.

SVG: or edit it in Inkscape SVG editor just or view it with a web browser.. HPGL: i consider it also a save option, it's a sort of non-XML-SVG, some vector editors are also able to load it, and you can send it to the printer manually..

When things stabilize (i.e. plumbing changes are done), adding new save formats should be easy. It would be pretty easy to add them right now, but I'm reluctant to divert my plumbing activity into new features until the plumbing is done. -- "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/>