Star Wars Pixel Art

[Kafka]

[fatalcubez]

Wait a second.... that V isn't pixelated...

[Kafka]

sshhh   

[Kafka]

Finished the trilogy, although I'm not too keen on the last one.

[MysteryMeat]

Not much to critique here with it blown up like this besides how the numbers still aren't pixelart when they can be.

[Kafka]

I like the contrast between pixel art and non pixelated text. I did try it with pixelated text but it just didn't look right to me.


Am I posting the images too large?
is this any better?

[Capta1n_Henry]

It's easier to see what's wrong with stuff and make edits to it if you upload at 1:1 resolution. Please keep that in mind when you post on this site. As for the Episode 7 piece, I think there's a tad bit too much noise on Rey and the engines she's sitting on, but I'm pretty new to pixel art so take my opinion with a grain of salt. Also, I think your better off making the roman numerals pixel art as it looks weird with regular text to a pixel art backround.

[yrizoud]

In any case, the software (or method) that you're using to produce the large-scale one completely destroys your pixels. Zoom in a little, and you'll see that there are imprecise soft edges at the limits of the black circle, and considerable "static noise" in many colors.
Remember that GIF is a 256-color format. Even if your main picture is originally low-color (for example using only 20 colors + 120 for a sky  gradient), any non-pixel-perfect operation will create/need considerably more colors, for example :
- working with alpha brush, or tools with opacity < 100%
- anti-aliased text
- scaling by a non-integer factor
- smooth
- gradient
Saving as GIF forces your program to settle for only 256 colors, and use dither to mix them (it's a lossy transformation). Now if you re-open the same GIF image later and do more changes (which also need more colors) the dither patterns become worse and worse over time. I think it's what happened for the speeder animation. If you want to work on high-color-count images, be sure to use a "work format" which is loss-less. I don't think there is any standard one for animation, so you'll have to use the native format for your program (ex: PSD for Photoshop), and "Save a copy as ..." GIF to share the result.

[Kafka]

In any case, the software (or method) that you're using to produce the large-scale one completely destroys your pixels. Zoom in a little, and you'll see that there are imprecise soft edges at the limits of the black circle, and considerable "static noise" in many colors.
Remember that GIF is a 256-color format. Even if your main picture is originally low-color (for example using only 20 colors + 120 for a sky  gradient), any non-pixel-perfect operation will create/need considerably more colors, for example :
- working with alpha brush, or tools with opacity < 100%
- anti-aliased text
- scaling by a non-integer factor
- smooth
- gradient
Saving as GIF forces your program to settle for only 256 colors, and use dither to mix them (it's a lossy transformation). Now if you re-open the same GIF image later and do more changes (which also need more colors) the dither patterns become worse and worse over time. I think it's what happened for the speeder animation. If you want to work on high-color-count images, be sure to use a "work format" which is loss-less. I don't think there is any standard one for animation, so you'll have to use the native format for your program (ex: PSD for Photoshop), and "Save a copy as ..." GIF to share the result.

Hey, thanks that's really helpful. I'll keep working on it.