Dfool of many colors

Production of artwork for the game by regular contributors takes place here.

Moderator: Forum Moderators

Post Reply
User avatar
Noyga
Inactive Developer
Posts: 1790
Joined: September 26th, 2005, 5:56 pm
Location: France

Post by Noyga »

Disto wrote:It's you but they do appear to be taller. Graphically the only size difference heightwise is the feather which is only a few pixels.
Nope, without the feather she is still 2 pixel taller (i just checked with an editor).
It's not a huge difference (5%), but it's still visible.
User avatar
Jetrel
Posts: 7242
Joined: February 23rd, 2004, 3:36 am
Location: Midwest US

Post by Jetrel »

Kestenvarn wrote:Very impressive!

I do have to add that the eyes in the latest versions aren't very clear - in the latest version they seem to go wayfarer-style. The female archer almost looks as if she has no eyes at all!

This one had good eyes:
I respectfully disagree. It's true that the method we're switching to for all units is much blurrier on CRTs, but on LCD screens, it looks much better. Since that's what many of the developers use, and what everyone will be switching to down the road, that's what I'm gearing towards.

The faces now are carefully anti-aliased, and look less like the pile of lego-bricks they looked like before - they looked fine on my old screen, before, but they really look awful on any modern screen, and screens are only going to get better pixel separation down the road. I really had a shock when I saw how bad my graphics look on an LCD - interestingly enough, wayfarer's actually look considerably better on an LCD as well, as do freim's, and Neo's (though the last is generally drawn with large enough features, consider our drakes, that it doesn't matter).

I quite often wish we had twice the resolution to work with - then this would all be moot.

Edit: In fact, I went and checked them on several school computers, and even on the newer CRTs, they look exactly the way I expected (minus one pixel on the archer's face which seems to blend in with the hair - that's dependent on gamma, but should be adjusted anyways).
autolycus
Posts: 481
Joined: July 5th, 2004, 2:58 am
Location: 1º16'N, 103º51'E
Contact:

Post by autolycus »

I am still trying to work out the implications of this thread.

Can you keep 0,0,0 constant as well as 255,255,255?

Is it the case that you are using something like a greyscale swatch and tinting it with various colours?

The reason I'm interested (and hence posting in this discussion - sorry!) is that I was one of the people who suggested ellipses long ago. I still think ellipses are useful (i.e., they should continue to be an available option) because they are easier to see. This is especially true for people with colour-deficient vision (not totaly colourblind) because the ellipses provide a larger colour area.
as kingfishers catch fire
so dragonflies draw flame
-GMH
User avatar
Eleazar
Retired Terrain Art Director
Posts: 2481
Joined: July 16th, 2004, 1:47 am
Location: US Midwest
Contact:

Post by Eleazar »

This Thread: "Help needed defining team rgb values for unit graphics" should probably be used to post and discuss actual graphics.
Feel free to PM me if you start a new terrain oriented thread. It's easy for me to miss them among all the other art threads.
-> What i might be working on
Attempting Lucidity
Darth Fool
Retired Developer
Posts: 2633
Joined: March 22nd, 2004, 11:22 pm
Location: An Earl's Roadstead

Post by Darth Fool »

autolycus wrote:I am still trying to work out the implications of this thread.

Can you keep 0,0,0 constant as well as 255,255,255?
I guess I don't get the context of this question?
Is it the case that you are using something like a greyscale swatch and tinting it with various colours?
Something like, but I don't actually use the greyscale value but a strict average (greyscale is a weighted average)
The reason I'm interested (and hence posting in this discussion - sorry!) is that I was one of the people who suggested ellipses long ago. I still think ellipses are useful (i.e., they should continue to be an available option) because they are easier to see. This is especially true for people with colour-deficient vision (not totaly colourblind) because the ellipses provide a larger colour area.[/quote]

I have no intention of removing the ellipses as an option. In fact, the ellipses now use the same recoloring method, so they will match whatever random color is used for teams without having to change the artwork. The old method had ~10 different pictures of the ellipses, one for each team. While I would like eventually the artwork and config files to reach the point where experienced players can recognize the team without the ellipse, but since this is your primary concern, I will say it again to make sure there is no misunderstanding: I intend to keep ellipses as an option.
User avatar
Eleazar
Retired Terrain Art Director
Posts: 2481
Joined: July 16th, 2004, 1:47 am
Location: US Midwest
Contact:

Post by Eleazar »

I'm very excited about this color shifting technology, but i have a few concerns as to how it actually works. The math that DFool uses to explain how this works is beyond me, but i can make some practical observations:
(i'm calling "Team Colors", "TColor")

• Color shifted colors (except for white) get a darker, sometimes a lot darker.
• It doesn't seem possible to create very pale pixels of TColor.

Now i understand that the value (or luminosity i.e. the lightness or darkness) of TColor will have to change somewhat with different TColors: a white TColor needs to be brighter (higher value) than a gray TColor, otherwise there is no difference. And a colorful yellow needs a higher value than an equally colorful blue.

But it would be a lot easier to do art if a unit TColored in White or Yellow got colorshifted to a higher value, colors like Green or Grey kept about the same value, and only a few TColors like blue were darker than their original. It's confusing when the ingame version is so much darker than what was shown in the graphics program.

But the ablility to produce highlights (bright, less saturated verions of the TColor) is even more important. Notice the Elves' headbands.
On the left, the elf's headbands has a bright white-ish stripe. (Those pixels aren't being TColored) The units should look something like the example on the Right, but it's not currently possible to produce the pale colors needed for such a highlight using TColor.
Attachments
TColorExample.jpg
TColorExample.jpg (233.37 KiB) Viewed 4615 times
headbands.jpg
headbands.jpg (83.18 KiB) Viewed 4614 times
Feel free to PM me if you start a new terrain oriented thread. It's easy for me to miss them among all the other art threads.
-> What i might be working on
Attempting Lucidity
User avatar
Jetrel
Posts: 7242
Joined: February 23rd, 2004, 3:36 am
Location: Midwest US

Post by Jetrel »

autolycus wrote:I am still trying to work out the implications of this thread.

Can you keep 0,0,0 constant as well as 255,255,255?

Is it the case that you are using something like a greyscale swatch and tinting it with various colours?
No, actually, we're using a "whatever-we-decide" swatch, potentially defined on a per-unit basis, to change unit colors. We've adopted a convention of using magenta, and we've defined a swatch of specific magenta colors which can optionally be called in a unit definition via a macro.

The end result is that whatever colors are in our swatch get their hue switched to that of the team color, along with some adjustments to luminosity.
autolycus wrote:The reason I'm interested (and hence posting in this discussion - sorry!) is that I was one of the people who suggested ellipses long ago. I still think ellipses are useful (i.e., they should continue to be an available option) because they are easier to see. This is especially true for people with colour-deficient vision (not totaly colourblind) because the ellipses provide a larger colour area.
The ellipses are not going away, don't worry. No way is that going to happen.

Team colors are being used not as an absolute indicator, as they would in Warcraft, but as a strong suggestion of what team the unit is on. We are also using this as an excuse to strip most unnecessary coloration from our units - the result will be that our units look much more uniform, in battle, as you can see from the previous post I made with the human archers in it.

Part of the general design change is that the average unit will have two sets of color - the factional/racial coloration, and the team color. The factional colorations will be mostly plain old, drab earth tones, leather, steel, grey cloth, and gold trim for more "bling" units. In certain cases, factions such as the elves will have a large amount of some other color, such as green. When coupled with the team color, this will look rather nice, and will generally not have any major color clashes.
Darth Fool
Retired Developer
Posts: 2633
Joined: March 22nd, 2004, 11:22 pm
Location: An Earl's Roadstead

Post by Darth Fool »

Eleazar wrote:I'm very excited about this color shifting technology, but i have a few concerns as to how it actually works. The math that DFool uses to explain how this works is beyond me, but i can make some practical observations:
(i'm calling "Team Colors", "TColor")

• Color shifted colors (except for white) get a darker, sometimes a lot darker.
• It doesn't seem possible to create very pale pixels of TColor.

Now i understand that the value (or luminosity i.e. the lightness or darkness) of TColor will have to change somewhat with different TColors: a white TColor needs to be brighter (higher value) than a gray TColor, otherwise there is no difference. And a colorful yellow needs a higher value than an equally colorful blue.

But it would be a lot easier to do art if a unit TColored in White or Yellow got colorshifted to a higher value, colors like Green or Grey kept about the same value, and only a few TColors like blue were darker than their original. It's confusing when the ingame version is so much darker than what was shown in the graphics program.

But the ablility to produce highlights (bright, less saturated verions of the TColor) is even more important. Notice the Elves' headbands.
On the left, the elf's headbands has a bright white-ish stripe. (Those pixels aren't being TColored) The units should look something like the example on the Right, but it's not currently possible to produce the pale colors needed for such a highlight using TColor.
So, if I get what you are saying, what is needed is a total color value that is used to map to the team color value that is definable in wml. Currently this is the maximum value that is used in the team_rgb variable, but what you want is to be able to specify something that is less than the max instead, and when a total_color that is to be replaced is > than this, the color is replaced by something that approaches white? If this is correct, I think that I can do this easily, although it will probably need testing to get it to look correct.
User avatar
Eleazar
Retired Terrain Art Director
Posts: 2481
Joined: July 16th, 2004, 1:47 am
Location: US Midwest
Contact:

Post by Eleazar »

Darth Fool wrote:So, if I get what you are saying, what is needed is a total color value that is used to map to the team color value that is definable in wml. Currently this is the maximum value that is used in the team_rgb variable, but what you want is to be able to specify something that is less than the max instead, and when a total_color that is to be replaced is > than this, the color is replaced by something that approaches white? If this is correct, I think that I can do this easily, although it will probably need testing to get it to look correct.
I appreciate your work on this Darth. It sounds like you might understand what i'm saying, But these kinds of concepts don't go into words easily. They don't even go into numbers easily. So i submit a diagram which hopefully will confirm that you understand what i'm trying to say:

"A" is what currently happens.
"B" is what would happen if the value(luminosity) of the original graphic were scrupulously preserved. Not much of (if any) improvement over "A".
"C" is a hacked together approximation of the ideal. The value is a compromise between the value of the original graphic and the value of the "Target Team Color" as defined wherever it is.

I wish i could say it with numbers. Is that clear(er)?
Attachments
color swatches.jpg
color swatches.jpg (52.12 KiB) Viewed 4564 times
Feel free to PM me if you start a new terrain oriented thread. It's easy for me to miss them among all the other art threads.
-> What i might be working on
Attempting Lucidity
Darth Fool
Retired Developer
Posts: 2633
Joined: March 22nd, 2004, 11:22 pm
Location: An Earl's Roadstead

Post by Darth Fool »

Eleazar wrote:
Darth Fool wrote:So, if I get what you are saying, what is needed is a total color value that is used to map to the team color value that is definable in wml. Currently this is the maximum value that is used in the team_rgb variable, but what you want is to be able to specify something that is less than the max instead, and when a total_color that is to be replaced is > than this, the color is replaced by something that approaches white? If this is correct, I think that I can do this easily, although it will probably need testing to get it to look correct.
I appreciate your work on this Darth. It sounds like you might understand what i'm saying, But these kinds of concepts don't go into words easily. They don't even go into numbers easily. So i submit a diagram which hopefully will confirm that you understand what i'm trying to say:

"A" is what currently happens.
"B" is what would happen if the value(luminosity) of the original graphic were scrupulously preserved. Not much of (if any) improvement over "A".
"C" is a hacked together approximation of the ideal. The value is a compromise between the value of the original graphic and the value of the "Target Team Color" as defined wherever it is.

I wish i could say it with numbers. Is that clear(er)?
Ok, I think I understand. I should mention that before I tried the current scheme, A, I had actually tried B, and found it unacceptable. I don't think C is the answer either, but I do believe that I understand what you are saying. I think that my proposed (although not well detailed) solution shoud solve this. Once I am back home I will test it and try to give a better explanation of my solution. It should hopefully only require an extra line of wml in units that need it.
User avatar
Jetrel
Posts: 7242
Joined: February 23rd, 2004, 3:36 am
Location: Midwest US

Post by Jetrel »

Added the following to the end of utils.cfg - this has been committed to SVN (trunk).
BTW, if anyone feels there is a better place for this macro - be my guest and move it.


All you have to do to use this is to put {MAGENTA_IS_THE_TEAM_COLOR} in your unit configuration file, right where we'd currently put the flag_rgb stuff. Then, the colors you use can be selected (presumably with an eyedropper tool) from the swatch I attached earlier in this thread.

Code: Select all

# a macro to define a common set of magenta color values which different
# units can be color shifted by using the team color system

#define MAGENTA_IS_THE_TEAM_COLOR
flag_rgb=63,0,22,85,0,42,105,0,57,123,0,69,140,0,81,158,0,93,177,0,105,195,0,116,214,0,127,236,0,140,238,61,150,239,91,161,241,114,172,242,135,182,244,154,193,246,173,205,248,193,217,250,213,229,253,233,241
#enddef
Boucman
Inactive Developer
Posts: 2119
Joined: March 31st, 2004, 1:04 pm

Post by Boucman »

Jetryl, you might want to add the color swatch to trunk... I'm not sure where, probably with the empty hex
Fight key loggers: write some perl using vim
User avatar
Eleazar
Retired Terrain Art Director
Posts: 2481
Joined: July 16th, 2004, 1:47 am
Location: US Midwest
Contact:

Post by Eleazar »

Well, this is trickier than i thought.
I pretty conscientiously TColored some units, and when i see it animate ingame, it reveals that i missed some pixels. However it's pretty hard to see which pixels are missed, since the animation is over so quickly
I can forsee this kind of thing happening all the time, as units are TColored.

Is there a way, (or could a method be made) to view individual frames in their TColored state? Yes i know i could change the unit's cfg to make any frame in question it's "main" frame, but as some units have dozen(s) of frames that would require dozen(s) hacks and restarts of Wesnoth.

Ideas?
Feel free to PM me if you start a new terrain oriented thread. It's easy for me to miss them among all the other art threads.
-> What i might be working on
Attempting Lucidity
yobbo
Art Contributor
Posts: 151
Joined: September 16th, 2005, 6:31 am
Location: New Zealand

Post by yobbo »

Eleazar wrote:I wish i could say it with numbers. Is that clear(er)?
*cough* - how about algebra?

Code: Select all

a mapping from unit png colour to modified team colour that is continuous at boundaries:

Href, Sref, Vref = Hue, Saturation, Value of colour in unit png (e.g. magenta)
Hteam, Steam, Vteam = HSV of team colour
Hout, Sout, Vout = replacement colour

case Vref >= Sref:
  Sout = Sref * Steam
  Vout = Vref - Sref * (1 - Vteam)

case Vref <= Sref:
  Sout = Sref - Vref * (1 - Steam)
  Vout = Vref * Vteam

Hout = Hteam
err, so that would give:
[*] almost white --> almost white
[*] almost black --> almost black
[*] 100% saturation and value --> exact team colour given
[*] everything else mapped linearly in between these 3 points.

HSV <-> RGB algorithms here

This may not be useful, but working it out was kinda fun ;).
Darth Fool
Retired Developer
Posts: 2633
Joined: March 22nd, 2004, 11:22 pm
Location: An Earl's Roadstead

Post by Darth Fool »

Well, just as a warning (specifically to jetryl) I am planning on making the following change:

Instead of changing the value with the maximum total into the team color, I will change the first color listed into the team color. Colors with rgb totals less then this one will be appropriately shaded towards black, while those that have higher totals will be shifted towards white. I haven't thought about this in terms of HSV values, but I may see if it makes sense to do so, or at least to explain it in terms of HSV. The net result is that either the current images that jetryl has made will need to have their colors changed (an easy, but tediuous task if there are a lot), or we will need to have two versions of the Macro, the one for jetryl's existing images, and one which enables highlights. Hopefully, the code for this will be done sometime this weekend.
Post Reply