Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[Erk]

Last and biggest in my "if I had Toady's godlike skill and could make DF my way" threads.

I used to do a lot of pixel art, so I have a pretty good idea where I'm coming from for this. I know graphic customisation is in the works, and I've been putting a lot of thought into how I think it could be handled in an ideal world, leaving tons of room for outside artists to come in and make DF truly a lovely thing. This is without regard to those that want isometrics and weird changes like that: I am just talking about making our current DF prettier.

When I get to my PC and have some time, I'll whip up some examples.

Part 1: Absolute basics
-Anything in 100% magenta (FF00FF) is transparent. Good ol' industry standards. If you want a magenta colour, use FE00FF or something similar.
-Anything in a shade of pure unadulterated green (00nn00) is converted to 'item colour' based on what an item's colour is listed as in the RAWs. Value (ie. brightness) is conserved based on how green the shade is. In other words, if I draw an all-green throne, it will get coloured to the RAW colour statement of whatever kind of rock the throne is made from.
-Anything in a shade of pure unadulterated red (nn0000) is converted to the secondary/background colour of the material, also taken from the RAWs as above.
-All other colours remain exactly as shown in the bmp.

Part 2: Basic Items
DF should have a hierarchical organisation of images. Rather than trying to explain that, I'll give an example. Note that the algorithm would probably do this in reverse from how I'm going to say it, but whatevs.

Let's say we have a -Pig tail left shoe-.
1) If there are no other options, the game uses a default graphic for the item type "shoe". This means any ungraphicked shoes have an icon, and no shoe will look like "[".
2) If there is a specific icon for a Pig Tail Shoe, the game will use that instead of the default.
3) If there is a specific icon for a Pig Tail Left Shoe, the game will use that instead of (2).
4) If there is a specific icon for a -Pig tail left shoe-, the game will use that intead of (3).
5) If there are multiple icons for a -Pig tail left shoe-, the game will randomly choose one (or will cycle through the list of icons as pig tail left shoes are generated. That icon will be stored as this particular item's icon and it will always look like that. For a -pig tail left shoe- this is probably not important, but it means we could have a dozen icons for artifact floodgates, so that each one would be a little unique looking.

This hierarchy would be supported for every single-tile item. It only becomes a problem for barrels and bins, which can branch too much because of their contents: if we want to show contents, we need layering.

Multitile items, specifically workshops and wagons, might need more work. Wagons I think are easy, but using hierarchy for a workshop gets interesting. I suppose it would work best for "Mason's Workshop" to be the top of the hierarchy, allowing specific graphics for, say, a mason's workshop made from iron bars or gabbro. For bridges and roads, "inner" tiles would be default and edge tiles would be lower on the hierarchy, so if no edge tiles had been drawn, the edge of the bridge/road would just look exactly like the inside. This is how roads currently work, after all. Having the inner graphics defined as multiple image files would allow users to draw multiple tiles, so that each tile of a paved road might not look identical. Smooth walls could work just like this: if the "corner" isn't defined,  the '+' is used instead. If that's not defined, 'O' is used, and so on.

I think that basically covers everything.

Part 3: Layering (barrels and bins)
Empty barrels and bins are handled using the hierarchy system. Once they get contents, though, a layer is added overtop displaying the contents. This layer has its own separate hierarchy. There is a default icon for weapon bins, but there might also be an icon for a weapon bin carrying only axes, or carrying axes and spears. if we want to get fancy we could allow multiple layers, so you could add a layer if a weapon bin contains at least one axe, and a second layer if it contains at least one spear, and a third if it contains at least one crossbow, and then another layer if someone chucks some armour in there. This would allow recognition at-a-glance of what's in a bin, at least roughly.

Wicked, eh? I'll try to add some graphics to illustrate my point here.

Part 4: Dwarves and other creatures
This will need layering and I'll need drawings. Basically I think dwarves should be multilayered graphics. Putting their arms on separate layers and keeping each dwarf icon in a similar pose would allow us to include the dwarf's specific clothing in a paper-doll style, as well as show what the dwarf is wielding and stuff. Having heads on a layer would allow random selection of a dwarf's appearance using multiple graphics files. Imagine every dwarf having his or her own look!

I'll get some demos of what I mean up if folks are interested.

[Derakon]

I admit that I didn't read all of this, but I see no reason to use color-keyed transparency when PNGs provide 8-bit blended transparency natively. You'd still need color-keys or some way of specifying palettes to do the palette-swapping of course (full-blown palettes would, naturally, let you do more colors).

For your heirarchy, what about decorated items? Should they get their own icons? That seems like a needless amount of repetition; instead I'd suggest making decorations a layering on top of the decorated item.

[Pie]

I agree that the transparency should just be the default PNG transparency and that the colour-keys for replacable colours is a good idea. Perhaps also a "shading" colour would be cool. I think that the hierarchy idea is good too, as it allows artists to initially just create generic stuff and then gradually add more and more specific shit. However, I don't think that decorations would work too well, as they would probably reduce the readability of the object. That same principal applies to boxes and bins. I reckon a screen coated with layered images of thousands of weapons over boxes and bins wouldn't really work.

Also, on the dwarf note, I think that the important parts that should be variable are:
Eye colour
Hair/Beard colour
Hair/Beard length
Headgear type
Headgear colour
Upper body type
Upper body colour
Left hand type
Left hand colour
Right hand type
Right hand colour
Lower body type
Lower body colour
Left foot type
Left foot colour
Right foot type
Right foot colour

And all of these should have three states - slightly injured, seriously injured and missing.
There should also be a variable which is the type and colour of the weapon/tool being carried.

[Erk]

PNG transparency would work too. It does add 25% more stuff for the game to think about per image file, but having an alpha channel is pretty nice.


Pie: good list. For injured/damaged, I think having a colour-replacer that changed pure black to brown, yellow, or red would be cool. All dwarf graphics could have a black outline, and that outline would change colour when the part was damaged. Then external body parts would also form the graphics outline.

Regarding decorations: I wasn't referring to something like *<-pig tail left shoe->*: it'd be neat if the engine supported there being a specific icon for that, but I doubt it's going to see use. For bins, I'll show you a picture of what I meant. It's not necessary for there to be individual weapon images per bin or whatever, but again it would be interesting to have the possibility. If it's just a matter of adding one more transparent png image overtop of the bin (that's all a layer is really), it's going to use less graphic processing power than having those same weapons scattered around outside of the bins anyway. Either way they are generating a graphics file call.

[chucks]

PNG transparency would work too. It does add 25% more stuff for the game to think about per image file, but having an alpha channel is pretty nice.

Yes, but what transparency algorithms would work best for the desired effects?

EDIT:  The following is a link to what I'm talking about.  It's for pyopengl, but the values and meaning are the same for C/C++ gl.h/glext.h stuff.

http://pyopengl.sourceforge.net/documentation/manual/glBlendFunc.3G.html

[Derakon]

The big win for alpha channels is for things like water, smoke, and miasma, which can be a semitransparent fog over the tile instead of a 100% opaque block. You can't achieve that effect very well with color-key alpha.

The second big win, of course, is not having to deal with color keys for alpha. But since you'd need them for other things, I don't know how much of a difference that makes in terms of implementation pain. Still, it's one less thing to worry about.