The VG Resource

Well, hello once again. Finally, I've made a sprite thread here.
Firstly, I've decided to make Marx in NES style. For no reason, just because.

inb4: too many colors

Some of the outlines have slightly different colour than the others (the legs and feet, mainly). I think the pink anti-aliasing of the yellow parts doesn't work well and sticks out rather than smoothing the lines. It seems wo work fine as shading, but not for anti-aliasing I'd say.

Quote:Some of the outlines have slightly different colour than the others (the legs and feet, mainly)

Fixed.

Quote:I think the pink anti-aliasing of the yellow parts doesn't work well and sticks out rather than smoothing the lines.

Couldn't use any other color without expanding the palette. Which is already overflowed.

then change the colour until it conforms to both needs or don't use it.

It's not NES style. NES is 8-bit, which is 3 colors for every 8x8 square.

It just looks like a smaller version of the official graphics.

actually 8-bit has little to do with console, when you talk about that your talking about the general processor, typically in graphics the X-bit is referring to the colour resolution, i you want it to be in a style specifically aimed at a console thats a whole other constraint in itself.

that said 8-bit colour is typically R3 G3 B2
meaning Red and Green can have the following values (0 - 255 format) 0, 36, 73, 109, 146, 182, 218, 255
and blue can have the following values (0 - 255 format) 0, 85, 170, 255
Thats the closest you can get to 8-bit colour (processable by an 8-bit processor and held within an 8 bits of memory)
Without doing my research I think the NES limitations of colour may have been due to lack of graphical memory, the 3 colours which would have actually been 4 colours including transparency, would mean 2-bits per pixel in an 8x8 square each square assigned 3 colours and a reserved transparency (likely transparency relating to, do not draw).
EDIT: I major goofed my math and some of my logic!
at the native resolution (256 x 240) 60 KB would be the raw, each pixel 8 bits of colour.
compressed however it would be 15KB for the screen and 3.75KB index, however changing index per 8 x 8 square and printing directly to the front buffer so likely memory use at a time was along the lines of 16 Bytes for the 8x8 values and 4 Bytes for the colour buffer.

... sorry for the tangent, misleading ambiguity of the phrase "8-bit" is a touchy subject for me XD

(12-30-2012, 07:07 PM)Bombshell93 Wrote: [ -> ]... sorry for the tangent, misleading ambiguity of the phrase "8-bit" is a touchy subject for me XD

No, no, it actually makes sense to me. I'm sorry for being inaccurate.
It'd be a weird decision, but...

One color too much, though you could cheat this with sprite layering method that they used for Megaman. the only problem is that you have to include parts to it as well.

Still looked good by the way.

Yeah, I'm gonna go with Doc on this one.

Although I would have to say that it might be best to make this sprite into parts anyways, but that's just me.

(12-30-2012, 07:07 PM)Bombshell93 Wrote: [ -> ]actually 8-bit has little to do with console, when you talk about that your talking about the general processor, typically in graphics the X-bit is referring to the colour resolution, i you want it to be in a style specifically aimed at a console thats a whole other constraint in itself.

that said 8-bit colour is typically R3 G3 B2
meaning Red and Green can have the following values (0 - 255 format) 0, 36, 73, 109, 146, 182, 218, 255
and blue can have the following values (0 - 255 format) 0, 85, 170, 255
Thats the closest you can get to 8-bit colour (processable by an 8-bit processor and held within an 8 bits of memory)
Without doing my research I think the NES limitations of colour may have been due to lack of graphical memory, the 3 colours which would have actually been 4 colours including transparency, would mean 2-bits per pixel in an 8x8 square each square assigned 3 colours and a reserved transparency (likely transparency relating to, do not draw).
EDIT: I major goofed my math and some of my logic!
at the native resolution (256 x 240) 60 KB would be the raw, each pixel 8 bits of colour.
compressed however it would be 15KB for the screen and 3.75KB index, however changing index per 8 x 8 square and printing directly to the front buffer so likely memory use at a time was along the lines of 16 Bytes for the 8x8 values and 4 Bytes for the colour buffer.

... sorry for the tangent, misleading ambiguity of the phrase "8-bit" is a touchy subject for me XD

This is a nice brief explanation on 8 bit, but you have to remember that the sprite was aimed to be done in NES style.

E253, I noticed that there were a few frames with a highlight on their tongue, the others don't. Is it intentional? That being said, I like the sprite!

I know the NES stuff now, I got corrected in my own topic where I felt like experimenting with such style.
Far more limitations than I previously thought

(01-03-2013, 03:19 PM)Chris2Balls [:B] Wrote: [ -> ]E253, I noticed that there were a few frames with a highlight on their tongue, the others don't. Is it intentional?

Well, it's based on his KSSU sprites which had this little highlight. It doesn't look very good, I admit, so I've removed it recently. Should I do the same for the ribbon?
Also, can anyone explain this thing about "parts", please?