Generation 1 Format Sprite Resource

[knuxyl]

Generation 1 Format Sprite Resource
You can use all of these sprites excluding Sanqui's sheet and Gen6-7 without permission from the original author. Everything else is yours.

I have converted all pokemon sprites from every game into generation 1 format. This means they have been resized to 56x56 and recolored to use only 4 colors in greyscale.

I like watching the randomizer videos on youtube and the randomizer has sprites for pokemon 1-649. Some are good, some are bad, but a lot of people drew most of the new pokemon from scratch. I figured it would be easier to make these sprites if you already had a base image that you just need to fix up.

A lot of the newer generation sprites need fixing up to look good, but a lot of them don't. I just ran the sprites through a very complicated script so I could easily batch process the sprites.

By the way, this was not as simple as resizing them as someone has suggested. Each game takes about 30-45 minutes to process a DS game. It has to be greyscaled, interpolative resized to nearest, all colors in all sprites collaborated into one file, split that file into 4 parts (for the 4 output colors), then replaced each color in each file. Then it needs to have the palette remapped to the original for use with the original pokemon red. It may sound simple, but like I said, takes 30-45 minutes for ds games.

If you think you can create a better result with a script, please collaborate with me so we can make this as close to perfect as possible. Right now to process an entire games sprites, all you have to type in terminal is ./newgen.sh and let it run.

I tried messing with -black/white-theshold, levels, and gamma, but it would fix one sprite but break another. The resizing part deletes some pixels in the image, any other way creates dithering and artifacts, so this is as close to perfect as I could get. I tried a Lanczos filter but it still created artifacts. If you know a better way to resize without creating the "blur" please share and I'll see if it'll be better to use.

If I could somehow batch process the colors in each game into 4 colors without greyscaling, it would produce much better results, but when you get into DS it's much harder. I'm not sure how I would process it though...
For example, here is Charizard from Gen V

Each color section doesn't have a set number of colors like gen3 did. One has 5, one has 3, and one has 2 (with also the standard 3 colors greys). If they were split evenly, it would be so easy to work with and get the colors right.

I tried working with just the colors within each image and separating that, but that produced much worse results, with some of the backgrounds turning different shades of grey.

For now, we have all gen 2 pokemon in native resolution on gen 1 from g/s/c. The last montage is the custom work from Sanqui's randomizer (many different artists contributed), so with mixing and matching and probably just a little work, we have 649 good looking sprites for gen 1. I'm going to be converting gen 6 and gen 7 sprites to gen 1 today from the other resource threads here. I'll also be fixing Pokemon Ruby/Sapphire because the naming script messed it up. I also have to look into DPPt1 and 2 because it was missing some sprites somehow.
EDIT : Fixed Pokemon Ruby/Sapphire

Here is some newer things I've filtered from these two threads (these are custom sprites, even though ran through my filter and such, the authors are the ones who get the credit. DO NOT USE any of these gen6-7 sprites without permission from the authors at the links below)

Generation 6 https://www.pokecommunity.com/showthread.php?t=314422
Generation 7 https://www.pokecommunity.com/showthread.php?t=368703
Generation 6

Spoiler:

Generation 7

Spoiler:

Montages (which are also attached to post)

Spoiler:

Pokemon Red/Blue

Pokemon Green

Pokemon Yellow

Pokemon Silver

Pokemon Gold

Pokemon Crystal

Pokemon Ruby/Sapphire

Pokemon Emerald

Pokemon Fire Red

Pokemon Leaf Green

Pokemon Diamond/Pearl/Platinum (first sprite)

Pokemon Diamond/Pearl/Platinum (second sprite)

Pokemon Black/White

Pokemon Black/White 2

Pokemon HeartGold/SouldSilver

Sanqui Randomizer

I'm also working with my favorite sprites from all gens to make a complete set for gen 1. I've already picked 1-251 and I'm currently fixing them up. Here is some examples

If you want to take a look at the script, click the spoiler below.

Spoiler:

#!/bin/bash
game=blackwhite2
format=true
if [ ! -d "converted" ]; then
mkdir converted
fi
if [ ! -d "converted/${game}" ]; then
mkdir "converted/${game}"
fi
if [ ! -d "montage" ]; then
mkdir montage
fi
if [ ! -d "temp" ]; then
mkdir temp
mkdir temp/sprites_numbers
mkdir sprites_colors
else
rm -R temp
mkdir temp
mkdir temp/sprites_numbers
mkdir temp/sprites_colors
fi
if [ -f "zip/${game}.zip" ]; then
rm "zip/${game}.zip"
fi
cd "original/${game}/"
for f in *.png
do
convert "$f" +dither -background white -flatten -trim "../../temp/sprites_numbers/${f}"
cd ../../temp/sprites_numbers/
convert "${f}" +dither -colorspace gray -separate -average "${f}"
convert "${f}" +dither -interpolate Nearest -interpolative-resize 56x56\> "${f}"
convert "${f}" txt: | sed '1d' | cut -f 4 -d " " | sort -u > "../sprites_colors/${f%.png}".txt
cd ../../original/${game}
done
cd ../../temp/sprites_colors
cat *.txt | sort -u > ../colors.txt
cd ../
lines=$(wc -l < colors.txt)
((lpp = (lines + 4 - 1) / 4))
split --lines=${lpp} colors.txt
cd sprites_numbers
for f in *.png
do
cat ../xaa | while read i
do
convert "${f}" +dither -fuzz 0% -fill "#000000" -opaque "${i}" "${f}"
done

cat ../xab | while read i
do
convert "${f}" +dither -fuzz 0% -fill "#555555" -opaque "${i}" "${f}"
done

cat ../xac | while read i
do
convert "${f}" +dither -fuzz 0% -fill "#AAAAAA" -opaque "${i}" "${f}"
done
cat ../xad | while read i
do
convert "${f}" +dither -fuzz 0% -fill "#FFFFFF" -opaque "${i}" "${f}"
done
done
if [ "${format}" = true ]; then
for a in *.png
do
b=$(printf "%03d.png" ${a%.png})
if [ $a != $b ]; then
mv $a $b
fi
done
fi
for f in *.png
do
convert "${f}" +dither -gravity center -background white -extent 56x56 -remap ../../palettes/grey.png "${f}"
done
montage -geometry +0+0 -background none -tile 24x *.png ../"${game}".png
cd ../
cp -R sprites_numbers/*.png ../converted/"${game}"/
cp -R sprites_numbers sprites_names
cp "${game}".png ../montage/
cd ../
. ./rename.sh
cd ../
rm x*
rm colors.txt
rm -R sprites_colors
7za a -mx9 ../zip/"${game}".zip *

-------------------------------------------------------------------------------

 

[Nina]

I'm going to be honest, I have no idea what specifically is being done, but I am always interested in resources/conversions like these!

 

[Trev]

Okay, as impressive as it is that you managed to resize every sprite from every generation, there's a lot of errors in these sprites when you look at them up close. Unfixed/unfinished outline and incorrect proportioning (e.g. Pikachu's sprite is bigger than Ivysaur's sprite) are the two that stick out to me the most. It looks like you just resized sprites to fit into 56x56 and didn't do anything else. Majority of these wouldn't look great in-game.

 

[knuxyl]

I wish it was as simple as just resizing them, it was much much more than that. Without special parameters or options just resizing causes dithering. I had to use interpolative resizing with the setting to "nearest". The newer games had a significantly higher amount of colors then gen 1 did (4). Converting to greyscale still left some of them with like 12+ colors. I had to run a loop on every png to extract all the hex values of the colors used, put them all in a single text file, sort it and delete duplicates, then split it evenly into 4 txt files. Then I would run another loop on each file replacing all the colors in 1.txt to black, 2.txt to dark grey, 3.txt to light grey, and 4.txt to white. Then I had to remap the palette to the original sprite palette so they could be used within pokered disassembly without modifications.

Like I said in the first post, most of them aren't to be used as they are, they are bases for sprite makers to use. And the size difference with the pokemon should absolutely be ignored. We're working with 56x56 sprites. You need to look at generation 1 original sprites to see that size isn't something they worried about, they didn't start really doing that until gen 3 because of the limitations on the sprite sizes.

I don't have the patience for making sprites, but I am good with linux and programming, so I figured I would contribute the best I can.

I also noticed a problem happened during the renaming in Pokemon Ruby/Sapphire, I'll probably fix that today. /FIXED

Here is the script if you're curious. I wrote all of it, and it automates the entire process. There is a rename script being called that'll rename the number sprites to their respective names that's not included within this script.

Spoiler:

#!/bin/bash
game=blackwhite2
format=true
if [ ! -d "converted" ]; then
mkdir converted
fi
if [ ! -d "converted/${game}" ]; then
mkdir "converted/${game}"
fi
if [ ! -d "montage" ]; then
mkdir montage
fi
if [ ! -d "temp" ]; then
mkdir temp
mkdir temp/sprites_numbers
mkdir sprites_colors
else
rm -R temp
mkdir temp
mkdir temp/sprites_numbers
mkdir temp/sprites_colors
fi
if [ -f "zip/${game}.zip" ]; then
rm "zip/${game}.zip"
fi
cd "original/${game}/"
for f in *.png
do
convert "$f" +dither -background white -flatten -trim "../../temp/sprites_numbers/${f}"
cd ../../temp/sprites_numbers/
convert "${f}" +dither -colorspace gray -separate -average "${f}"
convert "${f}" +dither -interpolate Nearest -interpolative-resize 56x56\> "${f}"
convert "${f}" txt: | sed '1d' | cut -f 4 -d " " | sort -u > "../sprites_colors/${f%.png}".txt
cd ../../original/${game}
done
cd ../../temp/sprites_colors
cat *.txt | sort -u > ../colors.txt
cd ../
lines=$(wc -l < colors.txt)
((lpp = (lines + 4 - 1) / 4))
split --lines=${lpp} colors.txt
cd sprites_numbers
for f in *.png
do
cat ../xaa | while read i
do
convert "${f}" +dither -fuzz 0% -fill "#000000" -opaque "${i}" "${f}"
done

cat ../xab | while read i
do
convert "${f}" +dither -fuzz 0% -fill "#555555" -opaque "${i}" "${f}"
done

cat ../xac | while read i
do
convert "${f}" +dither -fuzz 0% -fill "#AAAAAA" -opaque "${i}" "${f}"
done
cat ../xad | while read i
do
convert "${f}" +dither -fuzz 0% -fill "#FFFFFF" -opaque "${i}" "${f}"
done
done
if [ "${format}" = true ]; then
for a in *.png
do
b=$(printf "%03d.png" ${a%.png})
if [ $a != $b ]; then
mv $a $b
fi
done
fi
for f in *.png
do
convert "${f}" +dither -gravity center -background white -extent 56x56 -remap ../../palettes/grey.png "${f}"
done
montage -geometry +0+0 -background none -tile 24x *.png ../"${game}".png
cd ../
cp -R sprites_numbers/*.png ../converted/"${game}"/
cp -R sprites_numbers sprites_names
cp "${game}".png ../montage/
cd ../
. ./rename.sh
cd ../
rm x*
rm colors.txt
rm -R sprites_colors
7za a -mx9 ../zip/"${game}".zip *

 

[knuxyl]

Here is a comparison between Black/White 2 sprites and Red/Blue sprites

Most of the sprites didn't come out so good, but some did perfect, like these.

These are more examples of how well some of the sprites did (from black/white 2)

These aren't just resizes, these are fully compatible with pokemon red disassembly.

 

[knuxyl]

Okay, as impressive as it is that you managed to resize every sprite from every generation, there's a lot of errors in these sprites when you look at them up close. Unfixed/unfinished outline and incorrect proportioning (e.g. Pikachu's sprite is bigger than Ivysaur's sprite) are the two that stick out to me the most. It looks like you just resized sprites to fit into 56x56 and didn't do anything else. Majority of these wouldn't look great in-game.

I don't even see which sheet you're looking at that shows pikachu bigger than ivysaur?

 

[Trev]

I really need to stop giving advice to people. It always turns into a process.

I didn't say every sprite was bad, no. There are many that are fine. But there are plenty more that definitely aren't. A lot of the sprites, namely the larger fully-evolved and legendaries, have serious outline issues and are proportionally smaller than several tiny Pok?mon. Here's just a quick analysis of HGSS, skipping many for time's sake:

Spoiler:

Venusaur, Charizard, and Blastoise are all proportionally smaller than their pre-evos. Raichu is ridiculously small compared to Pikachu (who also happens to be nearly the same size as Ivysaur, as I mentioned). Nidoking is proportionally smaller than both NidoranM and Nidorino, by a very noticeable margin. Kadabra and Alakazam are severely disproportionate to Abra. Machamp is smaller than Machoke. Graveller is both proportionally and actually smaller than Geodude. Rapidash is almost the exact same size as Ponyta. So are Kingler and Krabby. And Koffing and Weezing. Scyther is proportionally smaller than freaking Mr. Mime. Pinsir and Tauros are smaller than Magmar. Vaporen is 2/3rs the size of Jolteon and Flareon. Porygon and Omanyte are very similar in size. Kabutops and the legendary birds are almost similarly proportioned. Dratini and Dragonair are almost the same size as well. Mew's body is nearly the length of Mewtwo's. And that's just Kanto!

So if these are meant to be bases, many of them have a lot of problems and are going to require sizing anyway.

And also, no, we absolutely should not ignore proportion because GF never has. Although a few of the Gen I sprites are awful proportions-wise, nearly all of them do follow proportions. Pidgey and Squirtle lines' sprites are the best example - you can clearly see that the pre-evo is small, and the NFE is larger, and then the FE is even larger than that. Majority of your resized sprites break this because they have to resize the FE more than the previous two, which makes it disproportionate.

The only reason I'm saying this is because it's going to make the sprites look worse when they're disproportionate, and while it's great that this program you made can auto-resize the sprites, it didn't take proportions into account at all, so there are many instances, like I listed, in which pre-evos are, in one way or another, larger than their final stage. That's not going to look great. It's fine if you aren't a spriter and don't want to resize them, and believe me, this program does some cool stuff, but I don't think that a lot of these sprites are going to be usable in a Gen I game without some serious quality sacrifices.

Also, of your two proportion examples you gave, only Parasect was okay. Pikachu's BW sprite is significantly larger than its Gen I sprite, but the program looks like it didn't even resize the BW Pikachu at all. Just resizing to 56x56 isn't going to make the sprites look correct. There's more that needs to be done to make it look correct.

And that still doesn't account for the fact that a lot of the sprites have either serious outlining issues or messed-up feature due to the resizing. For example, one of Parasect's eyes is shrunken far more than the other one. I could probably point out more, but I've already spent a lot of time explaining this, so I won't.

This is just my analysis as someone who's worked with a lot of sprites. I don't know that much about whatever script you wrote, I was simply pointing out something that should realistically be accounted for when you're resizing sprites. In their current stage, I don't think a lot of these sprites are usable with ease and require far more work to fix up than they do to create, which doesn't seem like a decent output for me.

 

[knuxyl]

This is generation 1. I'm not even going to try to work out the proportions issue, when I look at the images I'm not thinking pidgey is as big as pidgeot, it's more about the quality of the image rather than the proportions problem.

And you're right, the program does not resize images that are at or below 56x56. This was intentional because again, proportions don't matter to me. You're the second person to talk about proportions but I really don't see the point in caring so much about such a trivial point.

It makes no sense to care about the proportions considering dragonite is 7 feet tall and pikachu is 1 foot, so if were going to care about proportions, dragonite should be 56 pixels tall and pikachu should be 8 pixels tall. See how that ends up? It makes no sense to do things that way.

I see what you're saying now though and I appreciate the criticism. But this kinda stuff doesn't matter in a 56x56 frame.

I'm gonna get back to you with a fixed up black/white2 sprite to show you the capabilities this has. Btw I'm not a sprite artist.

 

[knuxyl]

Dragonite

to

The original filtered image is here

And the source image is here

Took 10 minutes.

In-Game

Point is, even though they come out crappy from the filter program, it doesn't take much time to fix it up. Dragonite still looks a little weird with that foot, but other than that, that's a gen 5 sprite inside gen 1 game.

 

[Trev]

It's definitely not a Gen V sprite and the quality is average depending on who cleans it up, but you're ignoring literally everything I'm saying so I'm not going to continue. And no, Pikachu doesn't have to be 8 pixels tall, but it shouldn't be bigger than its evolution.

 

[knuxyl]

That dragonite sprite is from Gen V, Black/White 2. And yeah, quality isn't perfect, im not an artist and I spent 10 minutes on it.

Scyther from Ruby

Scyther after it went through the filter

Scyther after touch up -- Original Scyther

Scyther finished In-Game -- Scyther original In-Game

I don't care what you say, these are fantastic base sprites for people wanting newer gen sprites in older games. You've only provided input about the proportions, which I am going to ignore because it is irrelevant when in a 56x56 environment (pikachu dragonite example).

 

[Trev]

You're still ignoring what I'm saying :v Any sprite can look better when fixing it up. What I'm saying is that making them correctly proportioned isn't an easy task and most people aren't going to want to do it, and the sprites are going to look very, very weird in-game when people start realizing that a lot of the smaller Pokemon aren't actually that small. It might be fine for you, but to people who grasp even a basic knowledge of how the sprites work (most people) they're gonna see that it looks unusual. GF has kept proportions throughout every main aeries game and even retained the original sizes when translating sprites over to the Gen 3 games. Sure, an individual sprite can look good on it's own, but when you have a Dratini that looks proportionally larger than a Dragonite (while subsequently looking better because it wasn't resized), then it's going to come across as rather unusual.

It's not really as hard of a solution as you're making it to be. Instead of, "put everything in 56x56," try rescaling all sprites with ratios similar to their evo lines. Like, if Blastoise gets rescaled by 95%, scale Wartortle and Squirtle by 95%. Even if you don't want to clean them up, people willing to use the sprites can, and they'd probably be more open to having to just clean up as opposed to rescaling and cleaning.

EDIT: In fact, maybe consider doing that with the 64x64 resource since you can rescale every single sprite down to 56x56 without worrying about proportions, since Chaos already did that when he made the sprites.

 

[knuxyl]

... I've said it like 3 times. I don't care about the proportions. Please just go on if that's all you're gonna bicker about. I've been playing pokemon for like 17 years and I have literally never once even thought about proportions. If other people think about that irrelevancy while playing I pity them because I'm having fun while they're calculating nonsense.

 

[Hands]

Gen 1 is in a completely unique style that separates it from the other gens that all followed a shared progressive path with outlining, shading style, posing etc. Simply editing gen 2-5 sprites will not give you that style, some will look alright but most will not look gen 1 and many will be left with notable anomalies that look jarring.

 

[knuxyl]

Gen 1 is in a completely unique style that separates it from the other gens that all followed a shared progressive path with outlining, shading style, posing etc. Simply editing gen 2-5 sprites will not give you that style, some will look alright but most will not look gen 1 and many will be left with notable anomalies that look jarring.

Yeah I noticed that typo earlier, thread should be called Gen 1 Format, not Style. Style has already been done by Sanqui team, but they lack gen 6-7.

 

[Trev]

I've got news for you: you aren't everyone :v Other people do care about that stuff, and no, we don't calculate it nor do we not enjoy the game. But if you want to make a good usable resource, people are going to be greatly turned off by the sizes and it's like that people who make good hacks will not be interested in the resources because they're so drastically disproportionate and would require a lot of fixing. Just because you don't care doesn't mean others won't, and if you're providing a resource for other people to use, you should be accounting for the fact that not everyone is you.

I've literally given you two possible implementations that would get rid of the problem and your response is basically sticking your fingers in your ears and shouting la la la really loudly. Your program is interesting but the proportions is a really obvious flaw that can be fixed with some more changes to make it better. I'm not saying it's worthless, but fixing something like proportions is going to make it so much better and it'll look really amazing. But you gotta stop acting like any criticism is me saying that it's pointless, and you also have to realize that other people WILL care about these thins.

 

[Nina]

While I think we should all be open for criticism in our best interests, I think you've made your point so far Trev. It's now up to knuxyl to decide if they want to take your feedback in mind. Likewise to your resource, this debating might be best to taken over to PM/VMs at this stage and focus more at the resource work at hand.

 

[knuxyl]

i have got to find a more mature pokemon forum...

 

[Anastasia.R]

Hey, lets try to keep it positive moving forward and with more art. As said, you can take the feedback or not.​

 

[Bloodless]

While I think Trev is rude (in both this thread and gen vii) his points in both still stand. I myself have a thread in both Yellow and Gold style and both threads have sprites sized to reflect relative sizes (welcome to criticism if anything is wrong). You have managed to reduce colours and size but have made bigger sprites too small and blurry. This thread if anything is a commentary on what not to do. Good work in general though.