I've been talking to jman2050, and I've offered my graphics engine, NeedleMouse, to the project. NeedleMouse is almost complete already, but for the purposes of this project, I'm gonna need to make some changes to it (and I'd like to optimize it, out of practice). Before we get too deep into sprite creation and what-not, we should first come up with set rules for the graphics engine, and how it'll behave. Also, before I go any farther, I'd like to note that I'm completely open to criticism, and ideas on how to do things better or more efficiently.
I guess I'll start by describing how NeedleMouse works. NeedleMouse is written in C++ using SDL. It utilizes SDL_RotoZoom to handle scaling and rotation. The graphics engine is split into several pieces:
The core of the graphics engine is NMLayer. NMLayer encompasses an SDL_Layer and works a lot like a photoshop layer does. Individual graphics effects can be applied to layers separately. I.E. you can have layer1 apply a sin-wave effect like in Tidal Tempest Zone, while all the layers behave normally. You can create an unlimited amount of layers. You can also individually set the alpha for each layer, I.e. "50% alpha blending for this layer."
NeedleMouse also has a palette called NMPalette. NMPalette is a list of colors from which to draw from. I've currently got it set at 5 palettes with 64 colors each, but those numbers can be changed. I think I heard that someone wants 256 colors and 1 alpha... I could change it to 5 palettes of 256 colors each. NMPalette assigns a special color to the alpha, which I'll touch upon later. In addition to these 5 palettes, there's also an option to import a second NMPalette for scanline palette swapping. I.e. "after the 50th row, start drawing with the alternate palette." This lets NeedleMouse achieve similar effects the water effect from Sonic.
NMLayer draws from NMTileMap, which is made up of NMTile. NMTileMap is just what it sounds like - a collection of NMTiles. NMTiles are 64 bytes big, with each byte referring to a color index from NMPalette. You can think of them as 8x8 little sprite maps.
Sprites are arranged in TSR files - TheSonicRender, a format I created. TSR files are self-contained graphic objects. a TSR file contains info on how NMTileMap should be read to build a tile, and it contains info on how to build every frame of animation for an object. For example, say we took a picture of sonic and split him up into NMTiles, and lets assume for this example that Sonic is contained in 6 NMTiles. The TSR File for sonic would contain info on how to read from NMTileMap to arrange the NMTiles into the Sonic we all know and love. TSR files also contain information about how to animate the objects, I.e. "animation 1 is 5 frames long, which are frames X, Y, Z, A, & B, and on frame B, start animation 2." They also tell what default palette to use in NMPalette. I.E. "draw with palette 2." The sprite information in TSR files are stored using an array of chars, with the value of the char being the color index to point to in NMPalette. I.e. 'A' would point to color 65. If anyone has a better way to store color information, I'm all ears... this could be very easily rewritten to more accurately match the way sprites are stored on the genesis.
Palettes are stored as NPL files, which are simply arrangements of rgb values. Again, like the sprite info, these can be rewritten to more accurately match the way Sonic the Hedgehog stores it's palette information.
NMLayer can also pull from NMText - a text class which pulls fonts from a bmp file. It works as you'd imagine - you create a BMP file with every character you'd need, then assign XYWH coordinates for SDL_Rects inorder to blit them from the bmp directly to the NMLayer. This was originally a cheap trick I used to quickly get debug info from my engine, but it's stuck. I'd be up for rewriting it, but honestly it works fine (IMO)
Again, all this is flexible, and I'm willing to change anything that needs to be changed.
I think the first step should be to standardize the format. How many colors do we want, how many palettes do we need? I had NMPalette include 5 maps of 64 colors so I could do palette rotation without fucking up lots of different parts of the image. I.E. Sonic and the sky could share the color blue, with the same color index, but the sky could rotate without sonic changing as Sonic would use Pal1 and the sky would use Pal2.
What screensize should we use? It's currently set to 320x480, but it can very easily be changed. Should we have a limit on NMTileMap, or should something be handled differently? All this stuff will be crucial to figuring out what we can, and can't do with the images, and right now the limitations of the engine are flexible to what we need.
So feel free to comment or leave ideas.
EDIT: WHAT WE NEED TO FINALIZE THUS FAR:
-Number of colors
-Number of Palettes
-Flexible Palette (Check)
-Read original Sonic palette info
-Read original Sonic sprite info
-Mode 7 (partially implimented)
-Polygon rendering (very, very buggy)
Oh, and I almost forgot - I've been creating, for a very long time, an image editor which makes it easy to create art for the engine. You can import an image of any format, and have it automatically convert it into a NPL, TSR, and TileMap files. You can also set and organize animations from the program.
This post has been edited by Athelstone: 26 April 2008 - 04:24 AM