Dragon sprite

[pixelmind]

Thanks for being honest.

I didn't expect this to get into the mainline in the first place. As you said it doesn't fit well to the rest of the game.
I'm not really averse to pixel art, but for the dragon I couldn't achive a proper "pixel-feeling" ( As I'm a absolute beginner to the world of Pixelart ).
For now I'll finish the animations and leave the repixeling to someone better than me, or come back to It when I reworked my drawing method.

Anyway, I wouldn't have left If you told me this ealier.
I'm glad to receive honest and constructive critique.


BTW, I really like the new Drakes


EDIT:
I couldn't resist to try if I can translate the dragon to proper pixelart.

[Jetrel]

I couldn't resist to try if I can translate the dragon to proper pixelart.

The feet are a dramatic improvement in terms of shading. They have the general 'feel' that we want to see in pixel-art.

However, the big defining feature of pixel-art is the use of an extremely small number of colors. I mean this specifically in that you use an "indexed-color" image format, and you have somewhere between 2-60 unique RGB colors.

In terms of the final appearance, it's not strictly mandatory (as you've just demonstrated here, and as a number of our elf sprites are good examples of, you can pretty much look like pixel art whilst having a high color count. However, there are a number of maintainability benefits and code-based image-modification-tricks that are only possible if something's actually pixel art. These benefits include:
- you can shift the colors of parts of the unit with code; we already do this for our team-color.
- you can use specific colors as a mask for any sort of effect, be it making a color partly transparent, shfiting the color, making the color brighter, using it for some other visual effect (like a glow map). In other games, this could even be used to do collision testing.
- you can apply some staggering compression, versus images with a larger color count. Usually high-color-count images only losslessly compress to about half their size. Super-low color count images can compress 40:1 (I kid you not; we're literally getting those results over at another sprite-based project of mine, called frogatto - we're able to compress a full 1 megabyte image down to 24kb). The problem is that this degrades very quickly with additional colors, and worse, with noise.
- you can do global edits to whole sprites, or to whole unit trees, based on color.

- probably the biggest thing for us is that it enforces consistency; because people limit themselves to colors already used, it keeps colors the same, and keeps them from shifting as you paint - most people paint with an eyedropper tool to snag palette samples, and digital paintings with a brush tool will create tons of new luminosity values; especially if there are multiple hues, you might find your highlight and shadow colors migrating as you keep working. In pixel art, colors don't get mixed by the process of placing brushtrokes so your colors don't do this. This is important for visual consistency, and also important for maintaining all those procedural tricks I mentioned above (like team-coloration).

- last but not least, it really enforces 'the look' we're shooting for, because that look is quite natural to sprite art. It keeps most 'visual noise' out of stuff unless we deliberately intend for it to be there.


Anyways, a key reason pixel art doesn't go obsolete is that at this scale, the myriad of luminosity values you used aren't necessary for smooth shading. This is a quick photoshop reprocess of your image, and you can see from looking at it that the visual appearance of it has barely changed at all. However, it only uses 16 colors, where yours used more than 256 (probably a few thousand).

[Sangel]

As an aside, I notice that the dragon went from 26.14KB in thousands of colours to 3.87KB in a 16-colour palette. While we can probably afford the extra size for such a large and important unit as the Fire Dragon, Wesnoth definitely benefits by keeping the number of colours low for the majority of units, as those kind of savings really add up when you have thousands upon thousands of frames in the game.

The dragon is looking spectacular, by the way. Really great work.

[AI]

Converting jetrel's gif to png (with imagmagick's convert) dropped it from 3965 bytes to 3793. Optipng managed to squeeze out an additional 64 bytes, to 3729.

These aren't nearly as stellar savings as simply dropping the number of colours did, but it does serve to illustrate the following:

Code: Select all

dragon.png PNG 154x127 154x127+0+0 PseudoClass 16c 8-bit 3.64062kb

Code: Select all

154*127*1        # 8 bit bitmap
19558
154*127*4        # 8 bits per channel RGBA
78232
154*127*4 / 3729 # savings from bitmap
20
26766 / 3729     # savings from original dragon
7

[Aethaeryn]

The dragon looks amazing. It's really worth whatever effort is necessary to optimize it. I'm really glad it's revived.

[pixelmind]

Forgot to adjust the palette. Thanks for pointing this out.
It's quite amazing how far one can optimize images.

But you have to remember that we also need a alpha channel for the shadow and as far as I know indexed images only support masks instead of true transparency ( correct me if I'm wrong )
Or can this be done ingame by picking the right color ?

[thespaceinvader]

The shadow is 60 % opacity of a very specific purple colour.

[zookeeper]

Forgot to adjust the palette. Thanks for pointing this out.
It's quite amazing how far one can optimize images.

But you have to remember that we also need a alpha channel for the shadow and as far as I know indexed images only support masks instead of true transparency ( correct me if I'm wrong )
Or can this be done ingame by picking the right color ?

The image files themselves remain RGB and have an alpha channel as usual, it's just that png compresses better the fewer colours there are. So you don't have to worry about any technical limitations of a limited palette, you can keep the images as regular 8-bit RGBA and the png compression algorithms will take care that your small palette will get taken advantage of.

[Jetrel]

But you have to remember that we also need a alpha channel for the shadow and as far as I know indexed images only support masks instead of true transparency ( correct me if I'm wrong )
Or can this be done ingame by picking the right color ?

Any image, alphaed or indexed, can have a specific color made partially transparent by the code as it blits. Over on that other project I mentioned, "frogatto", we have support for alpha channels, but we basically don't use them at all. We are able to make parts of the sprites transparent just by making them a certain color; we coded our engine to treat that color as a mask.

Why?

Because it's much more maintainable not to use them. 99.9% of the time, we only want binary transparency. Wesnoth constantly has problems with stray pixels and noise; we're constantly hunting around finding and fixing these - it's a huge waste of time. It matters on one hand because algorithms get fouled up by these; for one example, the algorithm that places the unit image in the sidebar automatically centers it, and if a unit has stray pixels that aren't completely transparent, it's confused by them and the unit is placed radically off-center. This isn't the only example, but the point is that it creates tons and tons of useless busywork. It's especially egregious because we don't actually -need- that feature. We need some pixels to be transparent, some to be shadows, and everything else to be completely opaque. We don't need 256 levels of transparency, and we pay a lot of time-cost to have that feature active on sprites, even though it does no good for us.

Wouldn't it be nice if we had a code feature that would magically guarantee that all sprites had the correct transparencies? This (and stripping the alpha channels) is that solution. (Obviously this doesn't apply to, nor would be used on non-sprites, like portraits.) But something like this is a silver bullet - it magically eliminates an entire category of work.

[thespaceinvader]

One thing that confuses me about this system: how does it prevent stray pixels? Surely you just wind up with stray pixels of the wrong colour in the masked area, rather than stray pixels of opaque in the transparent...

[pixelmind]

A good way of preventing these stray pixels is to apply a "stroke" effekt in the layer style ( photoshop ), so you can easily see where these nearly invisible pixels are hiding and simply erase them.

[Jetrel]

One thing that confuses me about this system: how does it prevent stray pixels? Surely you just wind up with stray pixels of the wrong colour in the masked area, rather than stray pixels of opaque in the transparent...

It prevents by making them extremely visible, because they're always completely opaque. Under our current system, something with the slightly hint of opacity is exactly that - almost completely transparent. This is why we miss them so often. This alternative makes them considerably more "in your face".

In theory, yes, it's not a ton more insulation, but in practice, we haven't had a single problem thus far. I'm pretty impressed.

[pixelmind]

Was a bit lazy the past few days
Here is a quick and dirty animation draft.Does it indicate enough force for the impact attack ?

[melinath]

I am not a master of animation, alas! But I feel like it could be more powerful: more windup/more followthrough, perhaps? It does 24 damage and is only one strike, so it can probably be way overdone.

[thespaceinvader]

Melinath is correct. I would say that motion is the correct one, but you've finished the strike about a quarter to halfway from where you should have. Make it really, really BIG. Straighten the arm right out, probably bring it up parallel to the body - I'm not quite sure where it ought to finish, but I know it ought to go a good deal further.

Nice blocking, by the way =)