Dfool of many colors

[Xan]

I certainly support changing the macro so the team color is in the center. The first time I tried to team color a unit, I was suprised that this wasn't the case. It also makes it a lot easier to compare the relative brightness of the team colored parts near other colors.

[zookeeper]

Sorry if this goes in the wrong thread, and especially if this has been suggested before. I really didn't bother to read all posts, to be honest.

Wouldn't a very easy way to define team colours be to simply use some otherwise unused portion of the unit image to mark the team colour? Unit graphics are confined inside a hex, which leaves large portions of the square 72x72 image completely unused anyway. I'm unsure if it's illegal for unit graphics to flow over the hex borders, but even then the very top left corner of the image (for example) would still be practically never used.

Would there be any drawbacks to reading team colour values from the pixel 1,1...1,2...1,3...1,4 etc.? How many pixels "tall" the range could be would probably be 35 (after that you would fall inside the hex), with lightest value at the top and darkest at the bottom, but naturally such details don't really matter at this point. I think such a system would be a lot easier for artists, since they could just mark the team colours straight to the image (of course you could just paint in magenta, afaik, but still).

[Jetrel]

In particular, it seems that the team color should be defined as the central value in the color-swatch where as it now is about 3/4 across.

If we move to using the central value, and it turns out that your graphics need to be recolored, we can probably do so in an automated way using a modified version of the TeamColorizer.pl script I provided.

Not sure if I'm reading this right, but...
Basically, I set that value to be what it was deliberately - I tried it at the central value first, and that ended up making the units I had already colored look completely washed out.

There were two solutions to that problem - solution number one would be to use darker magenta colors, solution number two would be to set the team color to be at the value it's currently set to.


The reason I chose solution number two, was that using darker members of the color swatch (and I actually already use some of the darkest ones, which perhaps implies that I should have made a wider swatch) carries a visual difficulty for the artist. Namely, it starts becoming hard to tell that you're laying down magenta coloration rather than black - in fact, with the darkest colors in the swatch, it's already borderline hard. This isn't such a bad problem for folks like me, who use layered drawing programs, but it's a serious problem for people like neoriceisgood.


Fundamentally, I'm just concerned because we've gotten this thing working, now, and I'd rather not screw with it unless there's a good reason. By this, I mean that there is both a simple, clear method to create the team colors, and the results in-game look good.

I'd say - to test my hypothesis, try scaling down the magenta values to something that would make them suitable for use with a centralized value, and then send me the resulting images as they would be in a team-colored version. Please do not commit anything until I can verify that this change isn't going to mess up either the art workflow, or the resulting images themselves. A good unit image to test this with would be the master bowman I posted over in the art-development counterpart to this thread.

[Jetrel]

A place where team color is needed, and not currently applied - the advancement dialog.

[dtw]

Hello,

I'm sure I'm not the first to notice but the team color changes make several elven units virtually indistiguishable - has this been addressed? I don't have much net access so I am a bit behind

[Noyga]

Well AFAIK Jetryl is already working on that, but that kind of changes *takes time* ...
And rembember that 1.1 is a development version, so some things (like teams colors) may be still a little expermental and not perfectly polished, and if you use SVN trunk, even more exxperimental.

[dtw]

OK, mate, un-twist your pants - t'was merely a question and the answer "Jetryl's on it" would have sufficed

[jonadab]

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.

At this point, CRTs and LCDs have cost about the same for about a year, so I think most folks who had a real desire to move to LCDs have done so by now. CRTs will probably always be preferred by a lot of gamers because they handle resolution changes with more grace than LCDs, and a lot of games are picky about what resolution they want to use, or look/work better at certain resolutions, which vary from game to game. (Wesnoth actually handles this better than average, although it does change the resolution by default.) This really is neither here nor there, however, as CRTs are not the real casualty of subpixel rendering (although it is unnecessary for them and _can_ be noticeable if it's overdone or the user looks too close, especially in high-contrast situations like text rendering, but I think that's unlikely to be a problem in Wesnoth unit icons). I presume that if you're doing subpixel rendering in the images you're aware that some LCD displays use RBG order and others use RGB order for the subpixels? At least, it used to be that both were common. Something to at least be aware of.

The real long-term solution of course is to move entirely to vector formats and let the rendering engine (which ideally should be implemented in hardware, or at least in the lower levels of the GUI) sort out pixels at display time. But for obvious reasons it's not practical to move Wesnoth to that model at the moment and won't be for the forseeable future.

Nice work on the color-shifting stuff, BTW. I really like the idea of having semi-random minor changes in things like hair color happen at recruiting time, to help differentiate units.

[Jetrel]

CRTs will probably always be preferred by a lot of gamers

Until they have to lift the darn things to move to a different dorm. And besides the point, for the most part, we won't be using either in about 20 years. Much as we mostly do not use typewriters now, yet used them all the time in 1990.

The space, power, static, and weight were what moved me to LCDs, in spite of the resolution quibbles. Besides the point, newer 3D games work well in any resolution - look at WoW, or quake.

The real long-term solution of course is to move entirely to vector formats and let the rendering engine (which ideally should be implemented in hardware, or at least in the lower levels of the GUI) sort out pixels at display time. But for obvious reasons it's not practical to move Wesnoth to that model at the moment and won't be for the forseeable future.

Wesnoth, no. My next project, yes. Oh god yes. Drawing real sprites is an evil, and very hard-to-scale time hole. Animating them is orders of magnitude worse. After wesnoth, I will happily never draw sprites again. Why do it when I can teach a computer to do it for me?

And hey, while I'm at it, I'll attach some images for my handy-dandy upcoming Anti-Aliasing tutorial.

[jonadab]

And hey, while I'm at it, I'll attach some images for my handy-dandy upcoming Anti-Aliasing tutorial.

Oh, that's just standard anti-aliasing. When you said they looked better on LCDs particularly, I thought you were talking about sub-pixel rendering. Anti-aliasing like you show there is just as much an improvement on a (decent) CRT as it is on an LCD, and I would have assumed that all the graphics should be anti-aliased.