Bulbapedia talk:Project SpriteDex: Difference between revisions

Line 98: Line 98:
I'm not a member of the project, but I have no idea where to put this, but I've noticed your supposed animated Black and White are actually ever going to be animated under a png image format. png image format doesn't support animated images, plus I'm not sure why they weren't under a gif image format similar to the Crystal and Emerald sprites to begin with, but regardless, you claim that animated png images don't work under certain browsers, but they don't work under any browser. I'm really sorry for saying this, but honestly, it really needed to be said. Oh, and this should also go for other supposed animated png image files as well. And again, I'm sorry, but something needed to be said. [[User:Sinjoh|Sinjoh]] ([[User talk:Sinjoh|talk]]) 19:44, 28 July 2012 (UTC)
I'm not a member of the project, but I have no idea where to put this, but I've noticed your supposed animated Black and White are actually ever going to be animated under a png image format. png image format doesn't support animated images, plus I'm not sure why they weren't under a gif image format similar to the Crystal and Emerald sprites to begin with, but regardless, you claim that animated png images don't work under certain browsers, but they don't work under any browser. I'm really sorry for saying this, but honestly, it really needed to be said. Oh, and this should also go for other supposed animated png image files as well. And again, I'm sorry, but something needed to be said. [[User:Sinjoh|Sinjoh]] ([[User talk:Sinjoh|talk]]) 19:44, 28 July 2012 (UTC)
:I'm not sure why you think .apngs don't work on any browser.  I just checked on Firefox, which isn't even a browser I normally use, and they work fine, so that part is true.  Anyways, .apngs are the standard across the site, so this isn't really the best place to take up this problem.  A better place would be the Bulbawiki forum, or by messaging someone who is part of the editorial board. --[[User:Funktastic~!|It's Funktastic~!]] ([[User talk:Funktastic~!|talk]]) 20:12, 28 July 2012 (UTC)
:I'm not sure why you think .apngs don't work on any browser.  I just checked on Firefox, which isn't even a browser I normally use, and they work fine, so that part is true.  Anyways, .apngs are the standard across the site, so this isn't really the best place to take up this problem.  A better place would be the Bulbawiki forum, or by messaging someone who is part of the editorial board. --[[User:Funktastic~!|It's Funktastic~!]] ([[User talk:Funktastic~!|talk]]) 20:12, 28 July 2012 (UTC)
== A few questions before I begin the task I've assigned myself ==
As I've stated when I added myself to the project list,  I intend to fix all sprites from the first two generations, by directly ripping from the ROM itself rather than relying on external resources. However, I have some questions before I can proceed.
1. What is the correct orientation of sprites from Generation I? Should they all face the viewer, or should they be in their pose they would be if you encountered them in the wild? While this is usually the same way, certain sprites, like Pinsir and Tauros from Red/Blue, actually face away from the player when found in the wild.
2. What is the correct palette to use? This question covers pretty much every sprite from Generation I. The Japanese Red and Green versions Super Gameboy palettes are nearly identical, except that Red uses a very light pinkish color as it's brightest (neither use pure white), where as Green uses a very light greenish color. Thankfully, Japanese Blue/International Red/Blue all use the same pinkish color. Yellow version (except the Japanese versions), on the other hand, has both a Super Gameboy palette and a Gameboy color palette (which are nearly identical except in brightness). And finally, which of these four palettes should be applied to the back sprites?
3. How does the conversion from 15-bit color to 24-bit color go? For example, the "very light pinkish" color I talked about before is defined as "R 31/31, G 29/31, B 31/31". Should we:
* 1. Directly shift on 3 empty bits (or multiply each by 8 for people who don't understand bitshifts). That would result in "R 248/255, G 232/255, B 248/255".
* 2. Add one, do the shifting (or multiplying), then subtract one. This has the added advantage of preserving percentage correctly (15/31 would turn into 127/255 instead of 120/255, where 15/31 and 127/255 are usually considered 50%). That would result in "R 255/255, G 239/255, B 255/255".
4. How do I determine the arbitrary transparency requirement with any sort of degree of consistency? Most of these are fairly easy. Others, like Diglett and Gastly (R/B) are fairly straightforward but extremely time consuming (although the neither of them here now actually make all the pixels transparent that I would have thought). But some, like Moltres (R/G), don't have any sort of standardization rules that I could think of to follow. I could probably argue for an eternity whether the pixels at 42, 25 and 42, 26 should or shouldn't be transparent or not, and anyone who gets the concept could easily argue the opposite. What am I to do in this situation?
For now, because of the amount of questions I have on just Generation I, I'm going to only focus on that before I start work on Generation II. Hopefully, if someone can shed some light on these, I can begin the process of ripping and properly converting these.
Thanks. [[User:Stag019|Stag019]] ([[User talk:Stag019|talk]]) 08:12, 8 October 2012 (UTC)
6

edits