If you observe your pictures closely(don't know why i immediately spotted it), you will find that those "dark lines" are appearing along curves of other pixels that are not on the polynomial but for which there are always at least TWO points on the polynomial with EQUAL distance to the points on the "dark line".
Yes. I immediatly noticed that.
Don't know what is causing it though, but i suppose your algorithm could be reporting a wrong distance
I thought it was that at first, but I can't see where my algo would fail. It's behaving as expected in the other cases. Well, I know that's no proof , but I just think it works correctly. (I can't really explain)
It could also be caused by the inaccuracy
I somehow doubt it. I thought of it too, but I have difficulty to see why. And I'm quite sure there is a mathematical reason to this, which is perhaps visually accentuated by the algorithm and the inaccuracy of the lookup table.
Anyway, I have thought of an algorithm which will get rid of the inaccuracy of my current method when the slope of the polynomial is too high, but I'll have to drop the lookup tables. It will be reliable in all cases, and will have a custom precision. I'll code it and try it if I find enough time (damn... Speedhack is beginning tomorrow )
In fact, the inaccuracy problem appears above all when the range is small and the slope of the curve is big. Here are some pictures which show it quite nicely :
By the way, in a new version (I keep a backup before every major change) I changed the lookup table to floats, just to see. Of course we still have the same problem, but it smoothes things up . See:
Also, I tried to play with funky polynomials, which have lots of extrema (so necessarily of higher degree), so with several areas where 2 points have the smallest distance, and sometimes even 3. I thought it will be fun. And it was. See :
In the fourth picture, I played with the exp modifier so that we can see things better (I was still using the old modifier code, by the way). It caused some nice bug because of the lookup table and the accuracy of the distance calculation method, as you can see...
I also had some nice ideas about your C++ port, Dennis. Well, don't worry, normally this won't disturb your current development (otherwise I'll begin to feel guilty ).
First, your whole code isn't really specifically related to allegro. You only use a putpixel and a bitmap in the rendering function. So I think it would be nice to keep the core module (the one which handle the ca list, and has the rendering method) independent of allegro or any graphics API. You could have a 'virtual void plot(int x, int y, int r, int g, int b)' virtual method which will be called from by rendering method. Then all we have to do is to derive a new graphics API specific class from the core class, which will have the bitmap or the device context as a member and implement the plot method. That way the gradient generator can easily be used with allegro, wxwidgets, or any other graphics/GUI API.
According to that post, have a virtual plot function which will be called a lot of time will probably add much overhead and be slow. Well, there might be another way to achieve this, but won't be as elegant.
Then, for the polynomial thing, I think you should have a generic functional curve ca class, which will handle the distance calculation and the stuff, and have a virtual method to compute the coordinates of the points on the curve. That way we can easily have derived class for polynomials or any other kind of functions. We could have cool sine waves, or anything the user/programmer will think of. (easy to use since all the user has to do is derive a new class and implement the value calculation. It's just a few lines).
Also, since you want to keep different kinds of distance calculations for those functionnal curves, you'll probably want the distance calculation to be virtual, so that we can have different derived classes depending on the algorithm wanted, no ? :)
The more I think about your C++ port, the more I think it's going to be great. It will be really nice to use, it will be a true new API that programmers will be able to use. :) I don't know how you're going to handle it though. Do you think you'll make it a lib, or only header files and source modules the user will have to add to their project ? Well, perhaps a lib is a bit too much for it... I don't know.
:). I'm really enjoying playing with your code (the old C version ;)), and I'm really getting interested in this project. If you need help, I'd be really happy to contribute. If you want me to code some modules, such as the functionnal curves and other fancy maths object, I'd be glad to help you. :)