Allegro.cc - Online Community

Allegro.cc Forums » Game Design & Concepts » EasyToUse Dynamic Color Gradiant Generator

This thread is locked; no one can reply to it. rss feed Print
EasyToUse Dynamic Color Gradiant Generator
miran
Member #2,407
June 2002

Yes, probably. :)

--
sig used to be here

Dennis
Member #1,090
July 2003
avatar

Good(i hope i didn't cause too much trouble).:)

miran
Member #2,407
June 2002

Not at all. In fact version 1.05 is already up :)

Btw, you can now move attractors with the mouse too. Right mouse button changes range :)

--
sig used to be here

Neil Walker
Member #210
April 2000
avatar

How do you achieve smoother gradients? The only way I could achieve it was adding more of the same in the same place, but this has the effect of turning it towards white.

Neil.

Neil.
MAME Cabinet Blog / AXL LIBRARY (a games framework) / AXL Documentation and Tutorial

wii:0356-1384-6687-2022, kart:3308-4806-6002. XBOX:chucklepie

miran
Member #2,407
June 2002

Smoother? I always get very smooth gradients. Make sure you're running the program at 32bpp. This can be set in allegro.cfg...

EDIT: And one more (small) update. Version 1.06 is now uploaded :)

--
sig used to be here

Dennis
Member #1,090
July 2003
avatar

miran said:

Not at all. In fact version 1.05 is already up

Wow that was quick, maybe even a little too quick...Where did my p and exp go?:' (I wanted to play around with them, preferably in a way that they are also text input fields that take floats.(The formula "eff_mod=p*dist^exp" could be shown next to that fields to give the user a hint what they do.)
(Could you not just have used my version2? I don't think that it is that much a speed loss with it compared to lookup tables and also version1 is included so that loading of previously generated files would not be broken.)

How easy is your MASkinG to learn? Maybe i should look into it, so i could make the GUI myself. (You'd still be credited for GUI, of course.:))

Neil said:

How do you achieve smoother gradients?

I'm afraid that question can't be answered easily but it greatly helps if you understand how the RGB scheme works, because then it is possible to actually plan the result and place colors in a way that they will mix as you expect them to.

[edit]
version 1.06
That's cool miran you're spitting new versions like a highly active volcano;)...hope it does what i just posted...checking it.

miran
Member #2,407
June 2002

Quote:

Where did my p and exp go?

As I said, exp is in fact linearity. And p, I didn't think it was very useful. Or maybe I'm missing something? I'll do some more experiments :)

Quote:

Could you not just have used my version2? I don't think that it is that much a speed loss with it compared to lookup tables and also version1 is included so that loading of previously generated files would not be broken.

Well, calling the pow() function in a tight loop is always going to be very slow.

Quote:

How easy is your MASkinG to learn?

Hmm, it comes with full documentation, about 20 examples and a short tutorial. Whether it's easy or not depends on what you're used to, but I'd say it's not too difficult. Maybe it just requires a bit of time to get started, but then it's very easy...

--
sig used to be here

Dennis
Member #1,090
July 2003
avatar

miran said:

And p, I didn't think it was very useful.

I thought having a coefficient could be a nice thing to experiment with and i still want it.

miran said:

Well, calling the pow() function in a tight loop is always going to be very slow.

This might be true, but in fact i did not notice any hit in performance in my example.
I would still greatly prefer it if my version2 would be used, because it was done in a way that version1 was not touched.

What i wanted to achieve with this:

  • previously created files can be loaded and generated using the old functions and structs, thus not rendering older files useless

  • saving would always be done in version2

  • if a version1 file was loaded it could easily be resaved(without affecting the result) by setting the version2 modes of the attractors to CA_ATTRACT and putting 1.0 to p and exp(these values could even be changed on the fly during loading)

  • other light changes for future versions that only have new CA_MODEs would be "file compatible" to version2 and only the render...2 function would have to be changed

  • i had in mind that major changes to the CA_DESCx would always be made by having a new version of each of the functions, so that all versions would be downward compatible(could this not also easily be incorporated in your classes by just writing one load method for each version? saving would always be done to the latest version format, same goes for rendering)

I will start looking into your MASkinG, though it would be very helpful if you'd still be working on the GUI, because you're probably much faster on it than i could ever be.;)

miran
Member #2,407
June 2002

There's still full downwards compatibility. The last version still loads and properly renders all files that were saved with v1.00 and all other versions after that. Besides, there's virtually no difference between your v2 code my modified v1 code, except that mine is optimized with LUT (and I did notice a MAJOR performance hit; as in your code is like 20 times slower!) and I don't have p. I'll put that in too so you can play with it, it's not difficult. But as I said, it's not very useful either, at least from what I've seen...

EDIT: There, v1.07 has p in. It's called multiplier. I'll give you an award if you can do anything useful with it though. Btw in render_col_grad_to_bitmap() you can comment out the lines where d is calculated and uncomment the lines that call your code (that does exactly the same). If you can compile that, you'll see the difference in speed. My version is slow, but yours is painful...

--
sig used to be here

Dennis
Member #1,090
July 2003
avatar

miran said:

There's still full downwards compatibility.

That's good, i did not recognize it, because i wrote my post before examining your latest version.:P

miran said:

Besides, there's virtually no difference between your v2 code my modified v1 code, except that mine is optimized with LUT (and I did notice a MAJOR performance hit; as in your code is like 20 times slower!) and I don't have p.

Ok you're right about the speed then(i was just judging from one example without actually comparing any timings) but i still would like my effect_modifier in, because it allows for greater flexibility and experimenting, being able to enter just any float value for p and exp(even negative ones!). Your linearity allows only ranges from 0 to 2.0 as i see it. I want to also experiment with negative exp and p and values greater than 2.
(Also the effect modifier was done with future expansion in mind, so only that function needs to be adjusted and not every 'case'branch.)
It was not intended for realtime(as in high FPS) use and so i for my part would not care about the speed loss that much. (You could still use look up tables for values inside the range 0.0 to 2.0 and maybe just fall back to pow() for values outside of that range.)

miran said:

I'll put that in too so you can play with it, it's not difficult.

Great, i'm looking forward to the next version.:)
(Now i got to download "alfont" because i was unable to compile MASkinG.)

[edit]
What coincidence, you're always editing while i post!:D
[edit]

miran said:

It's called multiplier. I'll give you an award if you can do anything useful with it though.

I can already think of something: It can be used to quickly change the intensity value of a color, without the need to go into the color editor and sliding the intensity down(and that's not the same as changing your linearity). For my award i choose that you incorporate what i suggested above in this post;D.

miran
Member #2,407
June 2002

OK, I tested a bit now and for some reason the speed difference is hardly noticable. I swear it was much more before!

And you do have a point about that modifier function. It makes things more flexible. I think I'll do that in the next version. And I'll change those sliders into text boxes so you can type in anything you want :)

--
sig used to be here

da_flo
Member #1,907
February 2002
avatar

Quote:

Maybe your suggestions would be the same as having individual intensity(distance) functions for each attractor? I'm a little puzzled.

Quote:

(Maybe that's what da_flo was talkin about. I'm not good at this advanced maths stuff.)

Your linearity modifiers are nice. :D Using custom interpolation functions like this instead of linear interpolation is nice. I haven't thought about it :) (When I wrote my post, I was really tired, since I spent the whole previous night with friends, and was really stoned when I wrote it...)

But in fact that's not quite the same as what I was talking about.
Using distances defined from norms (as in my examples... every norm defines a distance, but not all distances are defined from norms), we still have the linearity. Mathematically, if N is a norm, for lamba a real number and u a vector we have :

N(lambda*u) = |lambda|*N(u)

In fact, a good way to visualize the differences between norms is to see the shape of a circle for those norms (a circle being of course defined as the set of points at a given distance of the center, according to the norm choosen). I've attached a picture of circles with a radius of 1, for N_1, N_2 and Ninfinity. For N_p, with p>2, you get a round square, which becomes sharper as p gets bigger. (in fact one can show that lim(p->infinity) N_p(u) = N_infinity(u). It doesn't matter if you don't get this though ;)).

So, I think I should try it, to see what kind of gradients we get with those new distances, because I can't say it without trying. And custom distances and linearity modifiers can be combined together, giving even more possibility ;)

However, since I still don't know how to compute the distance from a point to a line with non-euclidian distances, it can't be added to the program right now.

I hope you get it now. :) It was only a remark, I don't know if that's really useable.

Dennis
Member #1,090
July 2003
avatar

miran said:

OK, I tested a bit now and for some reason the speed difference is hardly noticable. I swear it was much more before!

Oh well, if that is the case then you might as well completely forget about the look up tables.(will also save a lot of memory;))

You're doing a great job on the GUI, just wanted to say that again as it can't be stressed enough!:D

[edit]

da_flo said:

However, since I still don't know how to compute the distance from a point to a line with non-euclidian distances, it can't be added to the program right now.
I hope you get it now. It was only a remark, I don't know if that's really useable.

All remarks and suggestions are highly welcome. Nothing beats several brains thinking in different directions. Maybe the problem with your thinking about the distance lies in the fact that there is no such thing as a "point" or a "line" in 'non-euclidean'-space?!(just a thought...) If it's not defined you'd have to invent that space yourself and write a function that transforms from there to cartesian coordinates...(no i don't really know what i'm talking about;D)

miran
Member #2,407
June 2002

OK, changed sliders to textboxes so you can type in any value you want and I switched to Dennis' code. Version 1.08 already uploaded :)

da_flo: I almost understand what you're talking about and I vaguely remember that from some math class I had some 3 or 4 years ago. But the memory is all blured :)

EDIT: About the speed issue. I figured it out. The speed of the pow() function depends on the parameters. If the exponent is a whole number, it's very fast, but if it's a fraction, it's very slow :(

--
sig used to be here

Dennis
Member #1,090
July 2003
avatar

Is that that thing with generic-"topologies" in arbitrary "vector"-algebras(<-can be anything, not necessarily analytical geometry vectors)?(my terms may be incorrect as i only know the german terms: "Allgemeine Vektorraumtheorie", "Topologien in allgemeinen Vektorräumen")

Will check Version 1.08 now...:)

da_flo
Member #1,907
February 2002
avatar

Quote:

Maybe the problem with your thinking about the distance lies in the fact that there is no such thing as a "point" or a "line" in 'non-euclidean'-space?!(just a thought...) If it's not defined you'd have to invent that space yourself and write a function that transforms from there to cartesian coordinates...(no i don't really know what i'm talking about

Be aware that I'm not really talking about non-euclidian geometry, such as hyperbolic geometry or other fancy stuff, where lines have an odd behaviour and all. Here I am still talking about basic space, with cartesian coordinates, but I'm trying to use some other kinds of distance. That's no geometry, only basic topology. The norms I've described (except N2) are called non-euclidian because they are not defined from a dot product.

Well, I'm getting a bit off-topic... Ahem. I will try to do some coding as soon as I get motivated enough.

Dennis
Member #1,090
July 2003
avatar

miran said:

About the speed issue. I figured it out. The speed of the pow() function depends on the parameters. If the exponent is a whole number, it's very fast, but if it's a fraction, it's very slow :(

Ok, fractions should only be used with great care then;) and the default values(i guess it's already that way) should always be 1.0.:)
[edit](so old versions and defaults will render at almost same speed as before and for other values(that are indeed new features) we can easily fake ms-mentality: new version==hardware requirements explode!)[/edit]

da_flo:
Then in theorie it would be easy: For every point on the line compute the distance(using whatever norm) between that point and the attractor, then choose the one that has the smallest result.(will probably be slow but should be right)

da_flo
Member #1,907
February 2002
avatar

Now that I think about it, if you look at the image I have attached (2 posts ago), you will notice that for hbar and vbar the distance is the same, whether we use the usual euclidian distance or a distance obtained from any N_p. Thus those norms can easily be implemented, and we can get gradients shaped differently that way. :)

It only becomes tricky if we use bars which are neither horizontal nor vertical.

Dennis
Member #1,090
July 2003
avatar

da_flo:
I will look into that, other bars than the ones already there will be put aside for now.

miran:
I noticed a BUG in my render function (It's also in yours because i already missed it on my very first release.).
The variables fr,fg,fb should be floats(that's why i put the f)! And on the calculations they should NOT be converted to (int). That conversion should only be done afterwards, where thos r=fr, g=fr... lines are placed. This should make things a little smoother.

Richard Phipps
Member #1,632
November 2001
avatar

There is too much math in this thread. My head hurts! :P

da_flo
Member #1,907
February 2002
avatar

Dennis, forget what I just said. I was still in the maths stuff, so I was assuming lines were infinite lines. :-X

With bars, which have 2 extremities, this becomes a bit more complicated. It might actually be quite simple, but I need to take a piece of paper and work on it.

[EDIT]
Sorry Richard. I am the one to be blamed for the maths hell. But I can't help it. I'm doing maths studies, and will probably become a maths teacher or do research... ;)

Dennis
Member #1,090
July 2003
avatar

These lines actually don't have two extremities... they are just either an x(vertical bar) or an y(horizontal bar) offset, so can they not already be treated as infinite ones?

da_flo
Member #1,907
February 2002
avatar

Oh okay Dennis. Then it works, no problem. :)

I'll dig into the maths issues anyway, for fun and to see if this can be used with fancier attractors/absorbers.

Dennis
Member #1,090
July 2003
avatar

Would be cool to have polynomial attractors/absorbers with an arbitray unit(given in pixels):-X or circular ones where range will be seen as range from every point on the circle:-X

However, i'll be experimenting with miran's v1.08 now... see y'all tomorrow.:)

miran
Member #2,407
June 2002

I've been experimenting with different distance functions. Attached is a picture of the default point with Norm p: Np(x,y) = (|x|^p + |y|^p)^(1/p) with p=0.3. Looks nice but is awefully slow without lookup tables :-/

Norm infinity looks similar but a bit more square. Norm 1 isn't much different either, except that it's rotated by 45 degrees, so it makes diamonds instead of squares...

--
sig used to be here



Go to: