too..many..smilies..

Don't worry the C++ port, will be excellent.
Targetsystem stays Allegro, so the thing will be crossplatform.
The first release will include a GUI(using Allegro's GUI functions).
It will support different languages and the user will be able to make own translations by adding a language specific textfile.

There is really no need in giving me hints on how to do the class hierarchy(I even felt a little insulted when you pointed on those obvious things with virtual functions. Again don't worry about that. Each attractor class will have just one single function(and that is NOT the distance function;)) that is called by the render method of the gradient class and it will of course be virtual and by that every derived attractor will be free to add thousands of other functions to its' private scope and then act on the given pixel as weird or cool as it wants.)

Other features that i have planned:
-blending over images (can already easily be put into the C-version by getting initial color values from the target bitmap inside the render function, instead of setting them to 0(the fr,fg,fb values))
-arbitrary size rendering at arbitrary position (like calling with a starting point and a width and height attribute, so you can even render to bitmaps without covering their whole area)
-export gradient as code (I already wanted to have this on the first C version, but after seeing my first image i got so excited that i could not resist publishing it)
-saving and loading to and from textfiles (will even be hand-editable)
...this list will probably grow during the process of porting, as it will not just be a 1:1 port...

And now, please wait patiently for the port. It will take a lot longer than i originally thought, because there are so many NEW features i think of, that i want to have in it and also i won't release it until the GUI is done and everything is working. (Will take at least a week if not longer, because also i can't stop playing around with the old version sometimes.;D And thanks for offering but i don't want your help, because i want to code everything myself.(at least for the initial release))

Your polynomial tests are looking interesting, especially those where the polynomials are "dotted".:)
I also made another cool polynomial.(Watch out for the image of the day for tomorrow;))

The function will be cleverly choosen.;)
Your hopes will not be dissapointed. It will be even easier for the programmer than it is now. (And i did not say there would be no distance method at all, just in case you wondered about that.;))

I'm not saying that i will not add that. Also i'm not saying that i will add it. But if i add it, it would be done properly, so that the user can enter the function definition in a freeform string, just like if he'd write it down to paper. That would require writing an advanced string parser though and usage of clever operator and operands stacks and trees. Since the other features i planned will already be taking more time, it is more likely that it will not be in. But of course, i you still want to, you can later add it yourself.8-)

But i don't want to distract you from speedhack now, and as i already said the C++ port is not nearly done yet. (Some parts of it are still in the planning phase...;))

yes...>:( (don't take that too seriously;))

I looked at the pictures and i think you did not post your new algo.
By the way: Is it really necessary to have 3 look up tables. Would it not be sufficient to have one additional table where for each y it holds a list including multiple values for the missing x pixels?;) (or maybe the other way round, does not matter too much...except that the table will be easier to calculate if having an x table with lists for the missing y values)

I think i just found the best and fastest method of all(:)):
(look at the piccy then read the description)
http://homepages.compuserve.de/DennisTapier/allegroforum/distance.png
The Algo-Idea to that:
first: Compute distance to function value.
second: Simultaneously trace in whole pixel steps a line to the left and one to the right.
break conditions:
If one trace hits an y position where it is smallerOrEqual than "function value at that position plus the 'rise' value" or bigger than "function value at that position minus 'fall' value", you can stop tracing into the opposite direction and break the trace loop.
If traces in both directions hit the end of the lookup table without any result you can stop tracing as well.
result: if the trace did not find anything the calc from first is the distance.
if the trace did hit anything(there is always just one candidate for a smaller distance found from tracing, cause if one side is succesfull the other is automatically farther away!) take the smaller value of (trace distance,distance to function value).

Hope it gets clear, I was too lazy to give a more detailed explaination.:)

[edit] Because of the y rising downwards you have to switch some plus and minus and blah in the above description but the idea stays the same. The fun thing: NO squareroots are involved!!! ('cause the tracelength-count can directly be taken...;))[/edit]

[edit2]it can be optimized even more by just storing a 'high' and a 'low' for each x position(don't extra store 'rise' and 'fall') then for the trace position a simple low<=y<high(or high<=y<low for y rising downwards) will do sufficient for stopping the trace[/edit2]

[edit3]
Trace in either direction can also stop if that directions' tracelengthcount exceeds the 'range' of the polynomial or if that directions tracelengthcount exceeds the distance to the function value.[/edit3]

[EDIT4](too bad i spotted a flaw: For a pixel to the bottem right or left of the minimum in the above example, it would report a wrong distance...>:()[/edit4]

[edit5]
...ok but coming around that flaw is easy:). If the trace was unsuccesfull in both directions:
store the distance to the function value as current result
then calculate the distance to x-1's function value and the distance to x+1's function value (euclidean distance)
if both are bigger than the current result, stop
if one of them is smaller than the current result, store the smaller one as the current result and go on calculating the distance to subsequent function values but only in that direction where the distance was smaller
as soon as you find a distance that is bigger than the current result you can stop and return the current result!:)
If i don't overlook sth. this algo should now be absolutely flawless and very quick in most cases and still quick in cases where the trace was unsuccesfull.
Damn, i'm good!
[/edit5]

Yeah, i must say i'm really becoming obsessed about the thing.:D

Make sure you don't miss my edits above as they describe pitfalls you could encounter, if you were very tired already.;)

------------------
[edit](should have been an additional post)
I thought about portability again and i plan now, as you suggested, to keep the core functionality system independent.
But i will not use a virtual putpixel function. I found a better solution: The gradient generator class will be a template, in which the exchangable type will be a customized bitmap type, that the programmer has to supply(i will supply one for the allegro version).
That customized bitmap type will be required to have some specific methods then(like get_width, get_pixel, put_pixel...) but basically be kept simple.
By that, virtual function calls to pixel putting functions are avoided, because the platform specific code for the gradient generator is already generated at compile-time.
The attractors and the gradient generator classes will use an internally device-independent pixel format, which the customized bitmap will be responsible for to convert correctly.(Will be very easy to implement for the allegro specific bitmap type, because of makecol.:))
So far so good. The basic planning phase should be completed soon.(Playing around with the old version and writing so much around here and thinking of other things, kept me from making any major progress with the implementation.;D)

Well then here's the IOTD code:

col_att_list3 test;
  init_ca_list3(&test);
  add_to_ca_list3(&test,CA_POINT,CA_ABSORB,1.8,1.0,320,240,0,255,255,200,NULL);
  add_to_ca_list3(&test,CA_VBAR,CA_ATTRACT,1.8,0.33,320,0,255,255,100,320,NULL);
  add_to_ca_list3(&test,CA_HBAR,CA_ATTRACT,1.8,0.33,0,240,255,255,100,240,NULL);
  add_to_ca_list3(&test,CA_POLYNOMIAL,CA_ABSORB,1.8,0.39,0,0,100,100,0,200,
                  make_polynomial(5,100,320,240,-1.0,0.0,5.0,0.0,-4.0,0.0));
  add_to_ca_list3(&test,CA_POLYNOMIAL,CA_ATTRACT,1.8,0.39,0,0,50,150,255,200,
                  make_polynomial(5,100,320,240,-1.0,0.0,5.0,0.0,-4.0,0.0));
  render_col_grad_to_bitmap3(backb,&test); /* backb must be a valid 32bpp bitmap 640x480 in dimensions */
  save_tga("./polycool.tga",backb,NULL);
  kill_ca_list3(&test);

(you can make backb 1600x1200 but then you must also multiply all positions and ranges by 2.5)

I'll try to resist coming back for a whole week.:)

Hey, thanks a lot!:)

But i definitely need to cut back on my visits, or else nothing ever gets done.
Maybe i'll report my progress once a day or so.

(As everyone can see i could not even resist coming back for a few hours:P)

[edit sunday 14th]
Progress:
-implemented customRGB type meant for greater precision during color mixing
-implemented the GLOBAL attractor type as the base class from which all other attractor types will be derived from
(thats all for today as the lord said sth. like "Men shalt rest on the seventh day!";))

[edit Monday 15th]
Progress:
-implemented the HBAR and VBAR attractor classes
-the "it will be easier than it is now to write new attractor types"-feature fell victim to the polymorphic design and to my effort in making the maintenance and extendability of the gradient generator itself easier, but the good thing about it is, that writing new attractor types will be somewhat normed, not hacky and finally introducing the new types to the gradient generator will be easier

[edit Wednesday 17th]
Progress:
-implemented POINT, CIRCLE and FCIRCLE attractor classes
-made plans and calculations for a POINTE class(point attractor with an elliptic range)
-also played with the thought of a rotated ELLIPTIC attractor class and thought of making POINTE rotated as well

It is in fact easy and i already made all the calculations, generalized for rotated ellipse and point"e".
(I'll not write it down here, because it's just basic trigonometry combined with some simple IR^2-vector math and i hate writing math in ascii(and in english) and besides it would almost already look like the code itself, so it would be twice the work in half the time.;)(another reason **))
For the pointe the calculations are almost the same, just a little different, because the distance to the ellipse is in the case of the elliptic range around a point not of any matter.
In the pointe case, only the distance to the center of the ellipse matters and its' relative percentage of the length of the vector to the point "on the ellipse" at the same angle inside the ellipses' rotated system.(Sounds a little odd, but if you could see what i see in my (slightly messy)sketch it becomes obvious.)

I think you don't even need to dig in any geometry books for that. Just draw a sketch of a cartesian coordinate system(y grows downwards) then put a rotated(angle grows clockwise) ellipse somewhere with attributes "center(x0,y0)","width","height","angle(rotation around its center)", then start using your brain.:)

(**see the difference: ..I don't feed you every (annoying) detail, by that i give you the chance to find a way(which may turn out to be different from mine) yourself and i don't already lead your thoughts into any specific direction.)

Very wise of you to put that comment.(Kept me from exploding into 1000 pieces, but maybe it is just me who gets angry that easily.);)

[edit]
I hope your silence does not mean that you hate me now, because you might have misunderstood me. It is not that i would not appreciate your or anyone's help in general. It is just that i (for some weird reason i don't even know myself) get annoyed if i'm swamped with lot's of detailed help, which i did not explicitely ask for and especially if it is for a topic i (think i) perfectly know well enough myself. I don't know, there is probably no excuse for my harsh response to you.:-/

[progress Thursday 18th]
-implemented the POINTE (rotated elliptic range) color attractor type
-fixed lots of conceptual errors in all other types
(i have not yet tested a single attractor, because the gradient_gen class is not implemented yet. because of that, i decided that after implementing the polynomial type and the ellipse type i will put a "new attractor lock" onto me, and then write the gradient generator class first, so i can at least test, if the attractors so far are actually working, because coding without actually seeing something from time to time is starting to get boring:))

[progress Saturday 20th]
-implemented rotated ELLIPSE color attractor type
-decided to make a rotated BAR and a rotated POLYNOMIAL attractor(of course the rotated bar would already be included in the POLYNOMIAL but for a simple bar, distance calculations can be made less complicated and faster)
(rotations pivot will always be the center of the attractors themselves)

[progress Thursday 23rd]
-did not do anything since saturday, hoping to implement the POLYNOMIAL attractor today, if i can finally manage to stop playing "Bunkermaster":o