(My 1000th post(what coincidence;)), time to announce the beta release of my "Dynamic Color Gradient Generator".)
I have waited a long time for the moment, i could finally write this:
dennis.coding_endurance++;
I played around with it. I like it alot. Just how do you make a new file to save too? I selected export as bmp, it then brings me to the file selection mode. I can't enter a new file name.
You can just enter a new file name in the top edit box.;) (It's the standard allegro file selector... maybe i should change the caption to say "Enter filename".)
Nice. I had some fun playing with it. 
How come I can't set the resolution higher than 800*600? If it could be set higher, the extra space could be used for an enlarged preview window.
Anyway, here are some ideas:
I have noticed the following bugs
But I like what I see so far. Nice work!
For some added fun, why not use an image generated by DCGG as the background for ChromaPlas.
AE.
Thanks for the extensive feedback Andrei.
Instant-preview mode:
It's already on my TODO list in the readme under implement missing features "auto recalculate option".;)
As well as the current method for inputting lines which is x,y,angle, it should also be possible to enter lines in the form y=mx+c
There will be the possibility to set position and angle(and some other values as well), by directly clicking in the preview area, in version 1.0, so i think it is unnecessary to have that extra way of entering lines(you can already enter it that way, using a polynomial with highest exponent 1 btw.;)).
Click deriving the various settings will be comfortable enough, i think.
As well as attractors only affecting the image in the RGB colour-space, it should also be possible to affect them in the HSV or HLS colour-spaces (bear in mind that hue is cyclic).
This is not planned and i don't know yet, if i will have the time and endurance to make another version after 1.0.(Making this generator has kind of grown into a full-time job the last two weeks and i also planned to do more work on the "Chickens" graphics, after 1.0 is done.)
My progress with things might be slow in general, but currently i really want to do DCGG 1.0 and after that, "Chickens" graphics will be the thing i want to do next, because that's been delayed already for so long now.
The ability to start with an image instead of a black canvas. Or perhaps even use the image as the attractor.
Also, already on my TODO list in the readme under "render over image".
there should be other modes such as multiply
That should be easy to implement, in fact it was planned from the start to add new modes later, only that so far no specific modes had manifested on my internal todo list.
The ability to move attractors up and down in the list (I'm not sure if this will be of much use if the only modes are add and subtract)
With add and subtract only, it will not influence the result at all. But yes, moving definitely is a must, if multiply comes in.
A Lisajous primitive. Although I'm not sure what should happen when the shape intercepts itself.
I don't know what that is and it sounds complicated.;D
Other attractors i have in mind(not for a 1.0 though) are polygones and point clouds(which could internally be represented with the same data set(i know i am lazy)).
other types of function such as sin/cos etc. should be allowed
Two much work for 1.0, because with arbitrary functions, there are a lot of extra things to keep in mind and writing a good arbitrary function parser/calculator will require an awful lot of extra work, which i currently absolutely don't feel having the energy to do it.
The number one reason for choosing polynomials was: They are mathematically "nice", because they don't have definition holes(x values for which there is no y defined) or any other "evil" properties.
In the image-dimensions dialog, sometimes an extra '1' appears if I clear a number-field.
That was intentional, whenever the field is cleared, because i don't want to allow zero, but i agree that it is annoying. I will change it so, that the clamping to whole numbers within [1,4096] will only occur, if the input field loses the focus.:)
1)If on loading/exiting without saving changes and the 'Ignore'-button pressed, the mouse-cursor remains by the 'Ignore'-button when the file-selector pops up.
2)In windowed-mode, if the mouse leaves the window, the Allegro mouse-cursor remaines inside (although this is a limitation of Allegro).
In the first case that is not allegro's fault and the "bug" is not serious, because it does not do any damage.
It is because most of my custom dialogs are running on a backbuffer and the mouse cursor is drawn in only just before the moment the backbuffer blits to the frontbuffer.
The "file_select_ex dialog" of allegro however, can't be run on a backbuffer, without doing an ugly timer hack, which would stress slow machines and probably even crash on some platforms.
So the standard allegro dialogs used, run directly on the frontbuffer, so behind them, what is still seen, is the last copy of my backbuffer. I thought it would look nicer to let it stay there, instead of cleaning it to black, before running a frontbuffer dialog.
As i said, it's not a serious "bug", but if it really disturbs users, i could fix that of course.
In the second case, it could be allegro's fault, not updating the internal mouse position anymore, after the cursor is out of the window(not sure about it though), but also this bug is not serious and does not do any damage.
But I like what I see so far. Nice work!
For some added fun, why not use an image generated by DCGG as the background for ChromaPlas.
Thanks a lot, and yes, i will try that.
Quote:
>As well as the current method for inputting lines which is x,y,angle, it should also be possible to enter lines in the form y=mx+c
[...]
(you can already enter it that way, using a polynomial with highest exponent 1 btw.;)).
Good point about using a 1st order polynomial to do the line.
This is not planned and i don't know yet, if i will have the time and endurance to make another version after 1.0.(Making this generator has kind of grown into a full-time job the last two weeks and i also planned to do more work on the "Chickens" graphics, after 1.0 is done.)
Ahem - good point. 
I should finally be finishing responding to my backlog of email so at last, I can get some real work done.
Quote:
>A Lisajous primitive.
I don't know what that is and it sounds complicated.
Argh! I mis-spelled Lissajous. See [url http://en.wikipedia.org/wiki/Lissajous_curve]
Quote:
>other types of function such as sin/cos etc. should be allowed
Two much work for 1.0, because with arbitrary functions, there are a lot of extra things to keep in mind and writing a good arbitrary function parser/calculator will require an awful lot of extra work, which i currently absolutely don't feel having the energy to do it.
The number one reason for choosing polynomials was: They are mathematically "nice", because they don't have definition holes(x values for which there is no y defined) or any other "evil" properties.
It does seem like a lot of work to implement. However, one nice thing about polynomials is that nearly all functions can be expanded by means of a Taylor Series into a polynomial eqasion. For example,
can be expanded as follows:
(the expansion goes on forever - here are just the first 5 terms).
Here is an expansion of several common functions.
Anyway, I have attatched a .dcgg file that demonstrates the use of polynomial expansions of
. The blue wave uses a 5-term expansion, the green curve uses a 4-term expansion, the red curve uses a 3-term expansion, and the yellow curve a 2-term expansion. With the blue-curve, it resembles a sine-wave of period 2 before the error becomes too great. I have also drawn a straight line in orange to demonstrate how the polynomial can be used to enter lines of form 
AE.
Argh! I mis-spelled Lissajous. See [url http://en.wikipedia.org/wiki/Lissajous_curve]
Ok that's not too complicated.
The problem is: Just plotting such a curve would be easy to compute, but useless for the purpose of this programme, because it needs to calculate the distance(shortest distance that is) from every pixel to the curve.
Let (x,y) be the current pixel.
The graph of the Lissajous curve is defined as the set of dots {(u,v)} with
and
.
The distance to that curve is
.
That needs to be derived with respect to t and then set equal to 0 and solve for t.(There is an unlimited number of solutions for t.)
Every(unlimited count) solution would have to be inserted into d(t) and then the minimum of those results would have to be taken as the distance to the Lissajous curve.
[append]
ChromaPlas rocked btw.:)
(and the new 'formula' mockup rocks too.)
Every(unlimited count) solution would have to be inserted into d(t) and then the minimum of those results would have to be taken as the distance to the Lissajous curve.
Actually, there's a much faster (but more complicated) way of doing it. The exact method involves some pretty complicated maths (multi-variable calculus) which is beyond my scope, so I'll just explain (warning - I am just showing off here) how it should be done.
One property of the shortest distance to a point for the path of a continuous function (where the gradient is continuous as well) is that the line from the point to the path is perpendicular to the gradient-vector (tangent) of the path where the line from the point intercepts.
If two lines
&
are perpendicular in 2D space, then 
If we let
be the point to find the shortest distance from,
the set of points where the line from
intercepts the path at right-angles, and
be the set of lines (vectors) from
to
, and
be the gradient-vector of the path at
, we must solve
for the equasion above.
The gradient of
is the derivative of the functions that plot the points
and
of the curve with paramater
(see previous post for the equasions to plot the set of points
and
). As this involves multi-variable calculus, I'll leave this bit out. Needless to say, the result will be the gradient of
. For now, assume
= gradient of
(gradient of tangent of Lissajous curve at point
).
We can replace
in
with
- giving us:

As L is the line from p to q,
is replaced by
giving us:

As we already know the forumas for calculating
(
) and
(
) from the lissajous curve for value
, we replace
with
and
with
giving us:

There is only one variable here -
. We just need to solve this equasion for
and use all solutions of
to calcualte all points that satisfy
. As the lisajous curve is cyclic, we only need to find values of
within the range of values that produce a single cycle of the lissajous curve.
For each solution of
, we must find the distance of
to
and take the minimum of those distances and use it to calculate the illuminstion of the point
caused by the lissajous curve. An alternative method of lighting involves the sum (or some other combination perhaps?) of the distances for all solutions of
so that all points of the curve where the tangent is perpendicular to the line from the curve to the point take part in the illumination.
(and the new 'formula' mockup rocks too.)
It sure does.
AE.
Combing through your post slowly, i can follow you and i think that in the end that method faces the same problem as the method mentioned before.
Another problem is that of actually finding the interval length for which the curve is cyclic.