For reference, I'm a programmer and I created that 360 spaceship art.

I provided rotations of that spaceship because not all graphics libraries have a rotate function. E.g. I use SDL 1.2 for several projects (including Flare) and it does not have image rotation.

And rotating the 3D model inside a raytracer beforehand is always going to give crispier results than rotating a small 2D sprite at runtime (both pixel quality and speed).

@GameProgrammingSlave: Being a programmer too, I must disagree with you. Both methods (what you pointed out as right and wrong) are neither good or bad in themselves, but have advantages and disadvantages which make them more suitable for one kind of use rather than another.

The alpha channel is useful (and I personally prefer it) but creates some speed issues with alpha blending. Considering SDL (which is far easier to implement than OpenGL and so is used by projects which don't need a lot of graphic power), using alpha channel on big surfaces can significantly slow down the game. You can choose to use it where per-pixel transparency or semi-transparency is specifically needed, but you can avoid it and use a color key (the magic pink!) where you don't need any partial transparency (which is the case of the majority of pixel art, as far as I know).

Same thing applies to rotated images (and could apply to scaled ones too): procedurally generating them at runtime is slower and often causes visual artifacts, especially with pixel art pieces. Thus, you should go with that solution only if you specifically need a picture to point in all the possible directions (or have all the possible sizes) whereas you should draw them (or render them, which was the case of the spaceships of above) in all the needed directions if they're a finite number (take a look at FLARE assets - besides being a very good example of pre-rendered art, they're rendered only in the 8 directions needed by the game).

At last, neutral light could make some objects look too flat, which in a game where they are always moving in the same direction (a sidescroller game, a topdown space shooter, ...) would be a useless loss. Of course, if your game would need the spaceship (or anything else) to rotate in many directions, neutral lighting would be the way to go.

Each game/game engine has specific requirements, there's not only one way to go... I'd suggest you to take a look at the comments by Duion in this thread (and at the whole thread in general of course) - he says more or less the same (actually slightly better than me).

Using alpha transparency in places where you only need key transparency (such as the example you posted) is just wasteful of both storage and processing. Suggesting it should be used universally is just plain stupid.

SDL and Allegro don't support hardware accelerated alpha blending. They are "out-dated" but are much more widely ported than newer alternatives. Thus tend to be more supported on archaic open source operating systems (which is extremely important to many of us on Open Game Art). Some of us target unusual and hobbyist devices like linux handhelds where color-keying is a useful technique.

Anyway, a lot of people are uploading art they already created for a current game project. So if you see lots of pink backgrounds or pre-rotated sprites that's because people are actively using those techniques.

Don't want to be offensive, I swear. Though you sound a bit pretentious (is this the right word? maybe rude would fit best...)  saying that SDL is outdated, and that Allegro is outdated, and that all the people round here (and also in other places different from OGA) use magic pink backgrounds and color-keying, as well as programmers using the libraries of above (me included), are just oldies and/or stupid people.

Clearly not all programmers have the same opinion as you about art requirements for games. They may not conform to what you think all programmers should be doing but I think they are big enough to make their own minds up. A lot of the art submitted on here is originally created for a particular requirement in a specific game so is already meeting the requirements for some programmer. The great thing about this site is that all art is available under open licenses so anybody can alter it to the way they think it should be done and submit those alterations back to the site.

Even in OpenGL, hardware-accelerated alpha blending is noticeably SLOW. Which is why you have to enable it manually in the first place, and people often choose not to. Also, some programmers may develop games for retro platforms that don't support 32bpp at all.

Platforms such as J2ME and PyGame don't support image rotation natively, and doing it in real time during the game would be prohibitively slow. Besides, what's wrong with providing a little convenience?

Also, first you ask artists not to provide multiple rotations of a sprite, then you complain that you can't auto-rotate an image with a specific illumination pattern on it? Make up your mind.

As Buch points out, different games/platforms/programmers have different needs. I think your best bet is to ask nicely for a modified version of the specific art you'd like to use.

"But just because many people use a certain technique, it does not mean that it's still meaningful or the best possible technique."

People don't use color-keying because many people use color-keying.

I think you got quite many examples of how color keying can be a useful technique. And you've been explained more than once how providing pre-rendered rotated images can be useful.

You can see those techniques ARE still meaningful. And there is no best possible technique as an absolute idea - it depends again on who you are, what you can learn or cannot, what platforms you want your game to run on, what genre of game you're making...

"Use alpha channel instead of color-to-be-replaced

Example: http://opengameart.org/content/merchant-ship

Most of us are able to use GIMP (for example) to replace magenta with alpha. However, it's not only tedious, an alpha channel can do much more. E.g. parts of the spaceship could be made partially transparent."

1) A non-transparent background on pixel art is sometimes easier to deal with for later manipulation by another artist.

2) It can indeed be tedius, and I don't want to spend a lot of time providing different formats of the same sprites to make things extra-easy for every possible project.  If you want to use the assets, do it yourself.

"

Don't provide different rotations of the same image

Example: http://opengameart.org/content/spaceship-360

It's much more difficult for us to pick the correct sub-image at runtime than rotating the image on-the-fly. Programmers who don't know how to rotate an image are very beginners and still have much to learn. They should not learn how to pick the most fitting image. Loading a big texture consumes more memory and it still doesn't rotate that smoothly. We only need the image with the ship pointing to the right."

Dynamic rotation of pixel art assets is a very bad idea.  Rotations have to be manually cleaned up to avoid looking awful (just see Pokemon Black/White's animated pokemon; it's really jagged and bad).  In other cases it might be less of a big deal, but it's never going to look as good as it would be if it were pre-rendered.

"Light objects neutrally

Example: http://opengameart.org/content/night-raider

The example isn't actually so bad, but you get the idea. You can't rotate an image that has light coming in from the side. Imagine how it would look like if two such ships were adjacent to each other, but point in opposite directions. You should light your 2D objects from above, for example."

Sorry, but this is just silly.  While having light directly from above is convenient for some top-down shooters, in general it is poor practise.  Non-directional lighting doesn't do much to reveal forms and tends to be visually boring.

There are several issues with what you say. I definitely use alpha channel (even you can disable it on my engine). However, replacing color key can be done on any number of image using image magick. Also it wont be a task write an application to perform it.

As a programmer you should be able to discard extra/unnecessary data easily.

For the last one, I guess it would be hard or as redshrike said dull to use top down light. Only real alternative to that is having normal map and using a pixel shader to light the object. Good luck doing that or finding non-3D art with normal maps.

There ways the site or the submission could be improved however, none of them are these.

Unusual, outdated, ...

The PC on (and for) which I wrote my LPC game does not have 3D acceleration. Anything using OpenGL is prohibitively slow. Which I don't much mind, because I don't like most 3D stuff anyway. (Notable exception: kiki the nano bot. And that game isn't slow.)

I don't like looking at magenta colour keyed art either. But in recent versions of my LPC game I replaced the former alpha blitting by colour-key blitting for speed reasons. (The conversion is done at run-time, because, A I want to be ready to switch colour keys if the current one happens to be used in some art, and B I really don't like looking at magenta colour keyed art.)

I'd say that the problem of "Light objects neutrally" is why providing "different rotations of the same image" is a useful thing - because once you have lighting/shadows, creating the different orientations isn't as simple as just doing a rotation. (This doesn't apply to the spaceship example, which does seem to be a simple rotation, but I think it's a point worth mentioning in general.)

It's true that one can simplify things if objects are lit from above, but I think isometric games do look better with a shadow cast to the side.

If I was writing an Asteroids game, I would rotate at run-time as "orient in any direction" is a key part of a game - but for cases where the directions are more limited (e.g., 4 or 8), providing multiple images can give better quality.

On APIs, in an ideal world APIs like SDL would all be GPU optimised, but they're not, and rightly or wrongly, there are people with games and engines built on SDL (perhaps because it's the APIs they know and it works, or there's a big codebase that would need porting).

Plus I don't see why this is a problem for you anyway - if you only need one image because you can rotate at runtime, then simply take one image. At worst, the artist wasted his time, I don't see how it slows you down :)

I prefer to use an alpha channel rather than colour keys these days, and it's easier to work with (e.g., one can scale the image with anti-aliasing - if you do that to an image with a colour key, you'll get a "fringe" effect where the colour key is blended with adjacent pixels, and is no longer invisible as it's a slightly different colour). But again, I don't see it as a problem, it's easy enough to convert (e.g., the Grim Color Reaper plugin for Paint.NET). If you think it's easy to switch to a new API, then it should be easy for you to convert the image.

If we want to consider modern techniques, why bother with 2D images at all? Just render the 3D object directly, then you can decide on things like the lighting yourself. What are the advantages of using the 2D images?

What a heavy discussion about such a tiny topic. Ill add my 2 cents anyway:

Rotation: Don't complain. If the artists added rotated sprites, check if they are there for a reason (pixel art or angled shading), if not, feel free to cut out the only sprite you need!

Transparancy: Don't complain. In many cases a single color is indeed enough for the artist, and it is little work for a programmer to remove a background when it is one solid color, compared to making a whole graphics kit.

Lightning: Yep, agreed. But this is not the only issue with the ship you linked to. Perhaps everyone who uploads here should follow some kind of 'game art tutorial'. If there was a game art tutorial I would definitely include the lightning tip in the part about rotatable sprites. If you find work from more experienced people that was intended to be rotated, you'll figure that it's usually done correctly. But if you are asking for free stuff, don't expect it to be professional.

In the end, this is all made available for free!
Every different way of publishing will appeal to different programmers.
A programmer with knowledge of an image editor can correct the first two problems in seconds.
If you want to do zero work and quality art, feel free to pay us and we'll do it for you :)