It depends on the image editor and its configuration. The most common case I've seen is ARGB32 where alpha'ed pixels have a color already and retain it (the invisible becomes visible, essentially). If that color turns out to be something strange, you then have to fix it. Usually it's black, white, magenta, or some other stark background color that is easily replaced as necessary. The editor generally takes care of reversing pre-multiplied alpha, if the image is being stored like that. Many storage formats, including PNG, avoid premultiplied alpha by design because it can lose valuable information about the (potentially multiple) transparency masks.
That's a good point, capbros. I forgot to mention the possibility of alpha channels/transparency. Generally I go out of my way to remove an alpha channel from a sprite/tile sheet (if it had one to begin with). That way you get more obvious behaviors by default. Most editors have options that can be configured on the export or save menu/sub-dialog which will strip alpha (for formats like PNG or TGA that support it).
This project wasn't successful, I see. I think it's a good idea in principle, but the critical parts are all in the execution and software side. For people looking for something like this, have a look at these:
While a cool and interesting concept, I don't think any of these or similar works have been a big commercial success. Probably because everything they do can be done even easier through emulation or virtual consoles instead of custom hardware. The appeal is partly in the nostalgia or relative simplicity of the limited purpose device, but if you still need a PC to develop for it, will it really make your life any simpler ?
It's kind of hard to answer this with so little given details, but I'll give it a shot.
In general, no form of raster/bitmap graphics are designed for arbitrary scaling. (If that's what you're after, vector graphics are by far the preferred choice.) However, just because pixel art is raster graphics doesn't mean you *can't* scale it. It comes down to mostly to two factors: quality of the source and the algorithm chosen.
Source quality is not something you'll have control over with stock assets. You'd have to make or pay for something better. Note also that quality has two sides to it, the subjective/artistic side and the objective facts like the resolution and color depth. Both make an impact on scaling.
What can be controlled without getting new art is the scaling algorithm. I suspect that most people scale using Nearest Neighbor, which will give you basically the sharpest conceivable result with extremely blocky pixels. Personally, I find this a very crude result which gets worse and worse the higher you raise the scaling factor. (2x is not that odd, by 5x it's already ridiculous.) That's not to say nearest neighbor is useless. It's ideal for editing, at least, and it's the fastest performing algorithm known.
As an aside, anybody who thinks pixel art from the NES/GEN/SNES years was meant to have a sharp blocked look is mistaken. All that art was designed with full knowledge that it would be displayed through a low-bandwidth composite NTSC/PAL video signal connected to a CRT television. Both aspects blur the pixels substantially, smoothing out the otherwise obvious blocks. On top of that, the scanline effect caused by interlaced video modes darkens the image on alternating lines since only half the lines are actively drawn in the current field. People who grew up as CRTs were already on the way out don't seem to be aware of this, sadly.
Contrasting with nearest neighbor, you could make a decision in the opposite direction and use something like a bilinear or bicubic scaler. These are relatively simple and common algorithms, but they're mainly designed with photorealistic scenes in mind. They work poorly on pixel art because of its relatively low resolution and color depth, plus the simple reality that not every pixel should be treated identically. Pixel art is highly contextual.
Due to that issue, a huge variety of upscalers were developed for pixel art, mostly by the emulation community. Wikipedia lists a lot of them on this page: https://en.wikipedia.org/wiki/Image_scaling . I recommend the EPX/Scale2x, 2xSai, hqnx, or xBRZ algorithms depending on the input art, exact effect desired, and personal taste. (Though I doubt there is any scaler which will convince nearest neighbor diehards to stop staring at huge grids of flat squares on their 1080p+ displays.)
Performance isn't usually *too* much of an issue in scaling, but if it is, there's three different things that can be done about it. One, switch to a faster algorithm (or one with a better optimized implementation). Two, implement the scaler on the GPU instead of the CPU, where it will be drastically faster. Three, choose a fixed output/runtime resolution, stick to it, and prescale all your assets so that you can draw the result directly from storage instead of doing the computation later. The third option has the disadvantage of not being able to change resolution or scaler, but it's by far the fastest of this group.
You seem to have gotten largely complete answers (though probably not the ones you wanted to hear) in the other thread. However, I think it's worth leaving one comment here just to summarize and make it clear.
{1} No, there's no magic information sitting around somewhere that you're missing. Sprite sheet animation frames are generally arranged implicitly, not explicitly.
{2} There's typically more than one valid sequence of animations in many, if not most, of the more advanced sprite sheets. For those, it's impossible to determine in advance what the "correct" sequence is due to the multiple potential answers. Describing every potential answer can also get unwieldly due to the exponential growth of the combinations.
{3} For small-time work, it's normally an understood and expected responsibility of the developer/programmer, not the artist, to devise the method, structure, and sequence of the animations to be actually used in-game. At least, this isn't something that an unpaid artist is reasonably going to do for you.
{4} There are algorithmic methods of breaking semi-irregular (rectangular, but not necessarily equally sized) frame blocks apart into constituent frames, and then reassembling them in different orderings. However, the algorithm generally needs to be specialized at least slightly for each particular use case. It further relies on the construction of the sprite sheet following a few obvious rules, including the use of a consistent identifiable background color, a mandatory minimum spacing between frames/blocks, and some locality of reference/context (grouping related object frames closer together).
It's possible to save a substantial amount of time (hours, perhaps days) by writing or tweaking an algorithm that disassembles and reassembles the sprite sheet instead of manually moving/cut-pasting every last frame individually in an image editor. The amount of time saved really depends a lot on exactly what you're trying to do, though. The more animations that will be constructed from the same tile/frameset, the greater the savings can be. The better integrated the algorithm is with the final result required by the game engine, the more time saved. (And so on, for just about every factor imaginable.)
One last note is that a lot of games and game engines likely insert one or more intermediate formats and tools between the input stage (a loosely assembled sprite sheet or whatever the artists are generating) and the final output stage (which is interpreted by the game engine directly). By adding another format and manipulation tool in the middle, it's possible to delegate the work of animation construction to somebody who's neither artist nor programmer. This is talking serious company business, though; most indies and hobbyists aren't going to bother with any such formal abstractions since they don't have extra labor to throw at the problem anyway.
That is some fantastic (re)integration work there, Zabin. The cohesion of the various contributed tilesets is definitely an area needing this type of attention. I'd love to see more :)
"Air" is very smooth and flowing, just like the name suggests. It's there and gone in a breeze. "I Didn't Do It" is a grave high-tension cinematic track which moves the listener through a range of strong emotions. "Sweet Ice" is a playful song with bells over a bass groove.
This is great work, and pretty diverse, too. My personal favorites are "Ambient Jazz Rock", "Blast Off", "Civilized Villains", "Crystals", "Glass Globe", "Harps Introduce", "Horror Adventure (v2)", "Mica Resolve", "Reflection", "Say What You Will", "Startling Reveal", "Theme of the Defenders", and "Watch Out".
It depends on the image editor and its configuration. The most common case I've seen is ARGB32 where alpha'ed pixels have a color already and retain it (the invisible becomes visible, essentially). If that color turns out to be something strange, you then have to fix it. Usually it's black, white, magenta, or some other stark background color that is easily replaced as necessary. The editor generally takes care of reversing pre-multiplied alpha, if the image is being stored like that. Many storage formats, including PNG, avoid premultiplied alpha by design because it can lose valuable information about the (potentially multiple) transparency masks.
That's a good point, capbros. I forgot to mention the possibility of alpha channels/transparency. Generally I go out of my way to remove an alpha channel from a sprite/tile sheet (if it had one to begin with). That way you get more obvious behaviors by default. Most editors have options that can be configured on the export or save menu/sub-dialog which will strip alpha (for formats like PNG or TGA that support it).
This project wasn't successful, I see. I think it's a good idea in principle, but the critical parts are all in the execution and software side. For people looking for something like this, have a look at these:
Uzebox ( http://belogic.com/uzebox/index.asp )
Mist FPGA ( https://github.com/mist-devel/mist-board/wiki )
Game Duino ( http://excamera.com/sphinx/gameduino/ )
While a cool and interesting concept, I don't think any of these or similar works have been a big commercial success. Probably because everything they do can be done even easier through emulation or virtual consoles instead of custom hardware. The appeal is partly in the nostalgia or relative simplicity of the limited purpose device, but if you still need a PC to develop for it, will it really make your life any simpler ?
It's kind of hard to answer this with so little given details, but I'll give it a shot.
In general, no form of raster/bitmap graphics are designed for arbitrary scaling. (If that's what you're after, vector graphics are by far the preferred choice.) However, just because pixel art is raster graphics doesn't mean you *can't* scale it. It comes down to mostly to two factors: quality of the source and the algorithm chosen.
Source quality is not something you'll have control over with stock assets. You'd have to make or pay for something better. Note also that quality has two sides to it, the subjective/artistic side and the objective facts like the resolution and color depth. Both make an impact on scaling.
What can be controlled without getting new art is the scaling algorithm. I suspect that most people scale using Nearest Neighbor, which will give you basically the sharpest conceivable result with extremely blocky pixels. Personally, I find this a very crude result which gets worse and worse the higher you raise the scaling factor. (2x is not that odd, by 5x it's already ridiculous.) That's not to say nearest neighbor is useless. It's ideal for editing, at least, and it's the fastest performing algorithm known.
As an aside, anybody who thinks pixel art from the NES/GEN/SNES years was meant to have a sharp blocked look is mistaken. All that art was designed with full knowledge that it would be displayed through a low-bandwidth composite NTSC/PAL video signal connected to a CRT television. Both aspects blur the pixels substantially, smoothing out the otherwise obvious blocks. On top of that, the scanline effect caused by interlaced video modes darkens the image on alternating lines since only half the lines are actively drawn in the current field. People who grew up as CRTs were already on the way out don't seem to be aware of this, sadly.
Contrasting with nearest neighbor, you could make a decision in the opposite direction and use something like a bilinear or bicubic scaler. These are relatively simple and common algorithms, but they're mainly designed with photorealistic scenes in mind. They work poorly on pixel art because of its relatively low resolution and color depth, plus the simple reality that not every pixel should be treated identically. Pixel art is highly contextual.
Due to that issue, a huge variety of upscalers were developed for pixel art, mostly by the emulation community. Wikipedia lists a lot of them on this page: https://en.wikipedia.org/wiki/Image_scaling . I recommend the EPX/Scale2x, 2xSai, hqnx, or xBRZ algorithms depending on the input art, exact effect desired, and personal taste. (Though I doubt there is any scaler which will convince nearest neighbor diehards to stop staring at huge grids of flat squares on their 1080p+ displays.)
Performance isn't usually *too* much of an issue in scaling, but if it is, there's three different things that can be done about it. One, switch to a faster algorithm (or one with a better optimized implementation). Two, implement the scaler on the GPU instead of the CPU, where it will be drastically faster. Three, choose a fixed output/runtime resolution, stick to it, and prescale all your assets so that you can draw the result directly from storage instead of doing the computation later. The third option has the disadvantage of not being able to change resolution or scaler, but it's by far the fastest of this group.
You seem to have gotten largely complete answers (though probably not the ones you wanted to hear) in the other thread. However, I think it's worth leaving one comment here just to summarize and make it clear.
{1} No, there's no magic information sitting around somewhere that you're missing. Sprite sheet animation frames are generally arranged implicitly, not explicitly.
{2} There's typically more than one valid sequence of animations in many, if not most, of the more advanced sprite sheets. For those, it's impossible to determine in advance what the "correct" sequence is due to the multiple potential answers. Describing every potential answer can also get unwieldly due to the exponential growth of the combinations.
{3} For small-time work, it's normally an understood and expected responsibility of the developer/programmer, not the artist, to devise the method, structure, and sequence of the animations to be actually used in-game. At least, this isn't something that an unpaid artist is reasonably going to do for you.
{4} There are algorithmic methods of breaking semi-irregular (rectangular, but not necessarily equally sized) frame blocks apart into constituent frames, and then reassembling them in different orderings. However, the algorithm generally needs to be specialized at least slightly for each particular use case. It further relies on the construction of the sprite sheet following a few obvious rules, including the use of a consistent identifiable background color, a mandatory minimum spacing between frames/blocks, and some locality of reference/context (grouping related object frames closer together).
It's possible to save a substantial amount of time (hours, perhaps days) by writing or tweaking an algorithm that disassembles and reassembles the sprite sheet instead of manually moving/cut-pasting every last frame individually in an image editor. The amount of time saved really depends a lot on exactly what you're trying to do, though. The more animations that will be constructed from the same tile/frameset, the greater the savings can be. The better integrated the algorithm is with the final result required by the game engine, the more time saved. (And so on, for just about every factor imaginable.)
One last note is that a lot of games and game engines likely insert one or more intermediate formats and tools between the input stage (a loosely assembled sprite sheet or whatever the artists are generating) and the final output stage (which is interpreted by the game engine directly). By adding another format and manipulation tool in the middle, it's possible to delegate the work of animation construction to somebody who's neither artist nor programmer. This is talking serious company business, though; most indies and hobbyists aren't going to bother with any such formal abstractions since they don't have extra labor to throw at the problem anyway.
That is some fantastic (re)integration work there, Zabin. The cohesion of the various contributed tilesets is definitely an area needing this type of attention. I'd love to see more :)
"Air" is very smooth and flowing, just like the name suggests. It's there and gone in a breeze. "I Didn't Do It" is a grave high-tension cinematic track which moves the listener through a range of strong emotions. "Sweet Ice" is a playful song with bells over a bass groove.
Excellent work, Zhelanov.
This is great work, and pretty diverse, too. My personal favorites are "Ambient Jazz Rock", "Blast Off", "Civilized Villains", "Crystals", "Glass Globe", "Harps Introduce", "Horror Adventure (v2)", "Mica Resolve", "Reflection", "Say What You Will", "Startling Reveal", "Theme of the Defenders", and "Watch Out".
A strange title for a good song.
This is a catchy groove. Thanks for the contribution.
Pages