Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Topics - Mu
Pages: [1]

1
edit: I've just realized I've posted in the wrong area. Got so caught up in browsing through all the posted pixel art threads. Sorry!

Hello,

I'm a bit of a C++ programmer and an artist. I hope to become somewhat competent at pixel art, and I aim to develop a PC game which would have gameplay and art similar to Secret of Mana/Secret of Evermore/Terranigma, etc. I would like to restrict myself to most of the limitations of SNES games in order to be authentic, but also for a couple legitimate reasons which I'll talk (and ask) about.

Limitations:

http://en.wikibooks.org/wiki/Super_NES_Programming/SNES_Specs

  • Picture Processor Unit: 15-Bit
  • Video RAM: 64 KB of VRAM for screen maps (for 'background' layers) and tile sets (for backgrounds and objects); 512 + 32 bytes of 'OAM' (Object Attribute Memory) for objects; 512 bytes of 'CGRAM' for palette data.
  • Palette: 256 entries; 15-Bit color (BGR555) for a total of 32,768 colors.
  • Maximum colors per layer per scanline: 256.
  • Maximum colors on-screen: 32,768 (using color arithmetic for transparency effects).
  • Resolution: between 256x224 and 512x448. Most games used 256x224 pixels since higher resolutions caused slowdown, flicker, and/or had increased limitations on layers and colors (due to memory bandwidth constraints); the higher resolutions were used for less processor-intensive games, in-game menus, text, and high resolution images.
  • Maximum onscreen objects (sprites): 128 (32 per line, up to 34 8x8 tiles per line).
  • Maximum number of sprite pixels on one scanline: 256. The renderer was designed such that it would drop the frontmost sprites instead of the rearmost sprites if a scanline exceeded the limit, allowing for creative clipping effects.
  • Most common display modes: Pixel-to-pixel text mode 1 (16 colors per tile; 3 scrolling layers) and affine mapped text mode 7 (256 colors per tile; one rotating/scaling layer).

I feel that one of the most important things here is 15-bit color (32768 colors). So, 5 bits (32 unique vals) for each of the three color channels of RGB. This means (I believe), color values (represented in bytes, 0-255), should only ever be multiples of 8. So, "16 8 40" is a valid SNES color. This also means (I believe), that while "0 0 0" is valid, "255 255 255" isn't. "White" I assume would then be "248 248 248". Would this be right?

Manual restrictions while painting:

One issue I have is it's uncomfortable to draw in MSPaint using only values with multiples of 8, since I have to manually define the values myself. Normally that's not a problem, but there is the possibility of human error -- what if I accidentally draw with "214 214 214" (invalid) when I intended to draw with "224 224 224" (valid)? I wouldn't notice (and no one else would), but it would still be incorrect! Is there some method or program that supports drawing in 15-bit color, so that the tool itself would "support" the limitation, and not be "faked" manually by myself?

Palettes:

This is more of a programming question, but I assume someone else has done this, post-SNES. I'm interested in sprite palettes for a few reasons. In SNES games, it seems that sprites generally don't use over 16 colors, and they like to re-use colors. Of course, if there is indeed a limit of 16 colors, then obviously reusing colors wherever possible is smart. In the image below, Guile's (via Capcom) skin ranges from white to peach to brown. The browns are reused on his boots and pants, the white is reused for highlights all over, and even the peach is reused in his hair color. The blue pixel for his eyes is the same blue of his tattoo, etc. There are also many games where different characters use the same color palettes, so the total palettes saved is cut down. I understand these things, but I would like to know if my assumptions are right, and anything else that might be interesting or useful about this.



One thing I want to say here is that the # of colors stated is only representative of the # of colors in the pictured frame. Therefore, they may (probably) have one or more colors in their REAL palettes. (Perhaps it really is 16 total?)

One feature that I admire greatly, which is actually used more than I initially realized, is swapping out one or more color values in a palette at any time. This is used so frequently in SNES games! In Street Fighter II: TNC, you can pick different palettes for your fighter by pressing a different attack (rather than light punch) at character select. This is a palette swap for the whole session until you lose and pick a character again. This means (though, I'm still making assumptions here) the game does not store multiple sprite sheets for every skin, but rather just one, and swaps the colors out as required. Another example from SFII: TNC is Ryu's fireball. Normally, it has a white-to-blue palette. However, if you do a slightly longer sequence you get a fiery fireball, using a yellow-to-red palette. It would surely be wasteful to have to store frames for the blue and red fireball separately, since they can be palette-swapped for the same effect.

In countless RPGs, like Final Fantasy, Chrono Trigger, and even Secret of Evermore (kid & dog pictured above, via Square USA), partial palette swapping occurs to illustrate status effects. The dark gray border of the kid above turns lime green if he is poisoned, and cycles smoothly from lime green, to black, to lime green, and repeats. In this case, only that single value in his palette would be swapped out. In FF6 and some other games, poison is illustrated differently. Instead of the outline changing, their actual skin color (3 or so colors) turns pale purple. I wanted to demonstrate that cool effect on the Evermore kid, but I realized they used one of his skin tones in his brown vest. :) However, if the user had the option to change the Secret of Evermore kid's shirt and pants color, they could use the same feature by swapping out only those colors (assuming they were fine with the two light blue pixels on the eyes being changed as well).



Nowadays, when people develop retro-looking games, I believe they usually just make multiple sprite sheets with the alternate colors. Computers now aren't limited by memory or processing power, so it's sometimes easier to just do it that way.

However, on top of being truly optimized for memory, there were other awesome features of palette swapping. Use a Candy on yourself in Secret of Mana and watch what happens. The palette of your entire character temporarily cycles through a blue-to-white gradient, which gives an impressive magical shimmer on the entire character (possible excluding the color value for his shadow). The fact that this is done in an optimized, limited manner, is excellent. Adding additional frames on the sprite sheet itself just to accomplish the same feature seems a bit lazy and wasteful, especially if I want to support multiple colors (i.e. blue-to-white for heal, red-to-yellow for burned, green-to-purple for plagued, etc).

I believe I understand the theory (assuming the things I've said in this post are correct), but I don't quite understand the "how". If anyone has any information on how to actually render graphics in this indexed manner (using only indexed images is a starting point, but I'm unsure from there) and take advantage of palette swapping, it would be wonderful. Also, of course, the renderer could (hopefully) only support 15-bit color. (Because plain rendering 24-bit PNGs through DirectX with "manually-imposed" limitations is definitely not the same thing..!)

I haven't been really asking precise questions, but I'd be very appreciative of knowledge on any of these subjects, or anything I haven't mentioned but would appear to be helpful or interesting. Thank you! :)

Pages: [1]