The VG Resource

Full Version: Sonic the hedgehog 2-Super Sonic Rip
You're currently viewing a stripped down version of our content. View the full version with proper formatting.
[Image: 35hemv5.png]
[Image: 1euk5e.png]

Well, here you go. Please note: this will the only and last time I ever rip from a game again, as I enjoy custom sprites a lot more.

Enjoy that now. Smile
Wow that looks great! You must be really smart! Big Grin
(03-20-2011, 01:27 PM)Mighty Jetters Wrote: [ -> ]Wow that looks great! You must be really smart! Big Grin

Thank you. Smile
This is a great rip - shame you don't want to go into more ripping...

Good rip though - It's online now. Really beats the previous sheet that was online!

Good job.
(03-21-2011, 08:18 AM)Dazz Wrote: [ -> ]This is a great rip - shame you don't want to go into more ripping...

Good rip though - It's online now. Really beats the previous sheet that was online!

Good job.

I would, but because of my shedule, it would take a long time to rip again. So instead, I'd rather use my time for custom stuff. Smile

and Thank you, good sir.
Thanks man & great job ^^
While the rip itself isn't too bad, I am here to flog you with thorny branches and rusty chains because you got the palette values completely wrong.

Most emulators and tools assume that each RGB component in a Genesis palette is a multiple of 16. (Before you even say it, notice how you omitted all the odd numbers? I'm counting those too.) HOWEVER! From official design notes unearthed from the Genesis' development, it's supposed to be multiples of 17. The end result is that a value of F = 255, the colors will be more vibrant, yet there is still a consistent scale.

I suggest you fix this error! Smile
(03-26-2011, 06:09 PM)Techokami Wrote: [ -> ]Most emulators and tools assume that each RGB component in a Genesis palette is a multiple of 16. (Before you even say it, notice how you omitted all the odd numbers? I'm counting those too.) HOWEVER! From official design notes unearthed from the Genesis' development, it's supposed to be multiples of 17. The end result is that a value of F = 255, the colors will be more vibrant, yet there is still a consistent scale.

I suggest you fix this error! Smile

Hmm. That does make sense, but what I've researched says otherwise. I'll look into the mutliples of 17 (or 34 in this case) for Genesis thing more before I change anything though, because if you are right, I have to completely recolor this and that's going to be a pain.

If it is possible, would you be kind enough to link me to these Genesis development documents? Also, I think next week I will be getting a Genesis from an old game store so I can do further research on it myself.

The Sega Genesis stores color values in a 16-bit data type with 3 significant bits for each color channel. 0x00 should be the darkest, and 0x07 should be the brightest. What those values translate to depends on your output device.

Genecyst uses a less accurate method of color conversion, its screenshots are darker
Gens uses a more accurate method for the 16-bit screen output, however its screenshot function bit-shifts those values into 24-bit, so a Print Screen screenshot and screenshot from the emulator will produce different colors on most machines.
If you're using the Kmod extension of Gens, its tile and sprite tools also use a less accurate method of color conversion.

The color difference isn't usually noticeable to the eye, until you start mixing pieces from different ripping methods.
(03-29-2011, 08:25 AM)DarkWolf Wrote: [ -> ]Genecyst uses a less accurate method of color conversion, its screenshots are darker
Gens uses a more accurate method for the 16-bit screen output, however its screenshot function bit-shifts those values into 24-bit, so a Print Screen screenshot and screenshot from the emulator will produce different colors on most machines.
If you're using the Kmod extension of Gens, its tile and sprite tools also use a less accurate method of color conversion.


I used Gens, but I know what you mean about the screenshot function shifting the colors which is why I had to manually change the color from the sprite I took from the screenshot to match the rest of the sheet. It was more painful that I had anticipated.

How about SonikSprite? Is that accurate enough in terms of color?
This is the most accurate. You will have to shift colors manually, but if you use a good image editor and have indexed colors, it should make correcting things much much easier.