Random individual Unit Recolor

[turin]

This may be possible to pull off well, but the examples given in this thread have not proven this to me. It seems to me that for it to look good, it will have to be very subtle, and if it is too subtle, it won't make a difference anyway.


Personally, I'm not going to invest any energy into this, though other people will do as they please.


I also agree with zookeeper when he says that this will make making new animations considerably more difficult. It will also make spriting itself more difficult.

[irrevenant]

A thought, feel free to shoot it down:

As we're looking at more and more sophisticated graphical individualisation, TColour seems to be an increasingly cumbersome way to do it.

Might it be better to introduce some sort of primitive(?) graphical 'layers' system to handle this sort of thing?

[Darth Fool]

A thought, feel free to shoot it down:

As we're looking at more and more sophisticated graphical individualisation, TColour seems to be an increasingly cumbersome way to do it.

Might it be better to introduce some sort of primitive(?) graphical 'layers' system to handle this sort of thing?

I am not sure that it would be more cumbersome than layers when you have many animation frames. On the one hand, you need to use a restricted palette for those things that you want to be able to recolor, on the other hand, you need to define the recolored layers for each animation frame, and you need to make sure that you update these images whenever you update the base image. Probably, which is easier depends on the specific images. Personally, I like keeping everything in one file, it is easier to keep track of what needs to change.

That said, I have actually thought about adding two new image path functions that could be combined to do the whole layer thing.

The first would allow you to overlay one image(including IPFs) on top of another image. The second new function would be a modification of the recolor function that would recolor all of an image and therefore would only have one parameter, the new color range.

While I'm straying a little off topic, another IPF I can imagine being useful would be a crop function which would allow you to crop a larger image. Then (if the artists desire it) you could have all of a units images in a single file.

[irrevenant]

A thought, feel free to shoot it down:
As we're looking at more and more sophisticated graphical individualisation, TColour seems to be an increasingly cumbersome way to do it.
Might it be better to introduce some sort of primitive(?) graphical 'layers' system to handle this sort of thing?

I am not sure that it would be more cumbersome than layers when you have many animation frames. On the one hand, you need to use a restricted palette for those things that you want to be able to recolor, on the other hand, you need to define the recolored layers for each animation frame, and you need to make sure that you update these images whenever you update the base image.

Unfortunately either approach requires tweaking the picture for each frame of animation.

Probably, which is easier depends on the specific images. Personally, I like keeping everything in one file, it is easier to keep track of what needs to change.

Oh, very much agreed. My ideal would be to directly use .xcf files as sprites, or (almost certainly) barring that, to be able to do all the layers, TColour and stuff in a .xcf, then have a program/script that automates turning all that into Wesnoth format...

[EDIT]
Hey, thought: is it possible to add extra channels ala the Alpha channel to keep track of TColouresque information? That would effectively integrate additional layers into the one file.

[Eleazar]

Probably, which is easier depends on the specific images. Personally, I like keeping everything in one file, it is easier to keep track of what needs to change.

Oh, very much agreed. My ideal would be to directly use .xcf files as sprites, or (almost certainly) barring that, to be able to do all the layers, TColour and stuff in a .xcf, then have a program/script that automates turning all that into Wesnoth format...

[EDIT]
Hey, thought: is it possible to add extra channels ala the Alpha channel to keep track of TColouresque information? That would effectively integrate additional layers into the one file.

Ick. As several of our most prolific artists *ehem* don't want to use the GIMP, that would be a counterproductive idea. Besides, i believe we are better off keeping image content as easily accessible to as many people as possible, especially when the advantages are questionable. I believe the health of our artistic community is due in large part to the ease of access to our graphics. Even ignoring the inconvenience, i'm not sure there would be a great advantage to working with layers.

It may be possible to save PNGs with extra channels, but many programs won't recognize any beyond the alpha.

Besides the palette swapping solution was a common one in commercial games before 3D. It's probably the best sprite solution.

[irrevenant]

Surely Photoshop can open and save to .XCF?

Go with whatever you think's a fair thing, but turning down GIMP format on grounds of inaccessibility seems entirely backwards to me...

[Jetrel]

Surely Photoshop can open and save to .XCF?

No, it can't. Believe it or not, I think there isn't an xcf importer for photoshop; I couldn't find one in a google search, and found a few people yammering about how writing one would be insanely hard.

Go with whatever you think's a fair thing, but turning down GIMP format on grounds of inaccessibility seems entirely backwards to me...

Surprisingly, even the guys at the Gimp don't recommend using their file format as an open standard; it's apparently rather poorly designed, internally.

Someone needs to come up with a good program that corrects the faults of both of these.

While I'm straying a little off topic, another IPF I can imagine being useful would be a crop function which would allow you to crop a larger image. Then (if the artists desire it) you could have all of a units images in a single file.

Zookeeper had talked about this, and actually this appears to be a rather good feature to have, as much as it would make editing animations absolute hell for me. We might do it only for terrain, or for packaged binaries.

Apparently, it provides a colossal reduction in our image footprint - we're talking a 60-70% reduction in the size of our images. I concatenated and compressed all the drake images into a single .PNG, and where the well-compressed individual images took up 2.3 or so MB, the final single image was about 300kb. Totally not what I expected.

[EELuminatus]

Actually on further examination, the troll line seems to be the place to start.
The mainline units seem to be made from about 7 individual colors. There should be very little sprite editing necessary to make this work.

*nods* Woses also have relatively few colors, although I shudder to think how many colors might be in their death frames.

I tried to use mainly those colors already existent in the base frame. Might be that in the earlier attempts I "invented" some colors, though.

[Boucman]

I don't know if OGL will help with that particular problem...

I had discussion with sirp because TC is still done using SDL in the current OGL branch, and it sounded rather hard to implement...

[Dave]

Surely Photoshop can open and save to .XCF?

Go with whatever you think's a fair thing, but turning down GIMP format on grounds of inaccessibility seems entirely backwards to me...

I'm not sure if Photoshop can save to .XCF and even if it can, there are other programs our artists use to do art which can't save to .XCF. Some good artists use Microsoft Paint, for instance.

David