Fully functional retro palette editor
It only took about a day to get everything up and running seamlessly with the palette editor, thanks to prior work done with my Sonic hacking app (See first post for more on that). Unlike that one, which supported only 64 colors, this one supports 16 lines of 15 colors each, with a hidden line to serve as a base for the art to be drawn with. I'll explain the need for that shortly, but first, a quick look at the process.
Creating the palette
The first thing to do was to generate the palette itself. Thanks to PixelatedPope's Palette Swapper, generating the palette is as easy as having a single sprite with all of the desired colors. This sprite is created at runtime by drawing a series of colored boxes onto a surface and saving it as an asset. At the top left you see a large box. It's comprised of 16 columns of 15 colors, and you'll notice that the first one is grayscaled, while the others are red. This is important and I'll get to that shortly. But the idea of the program at this stage, is that when the user switches columns using the left/right arrows, it will change the active row, and the new shader will color the block using those colors. Well, it didn't work as intended... in that it didn't work at all! ANY input seemed to just make the block vanish! Why? Up to now, I've no clue. I'd used the shader many times and always knew how to implement it correctly. But it doesn't matter, because:
Successful palette swapping
After rebuilding everything from scratch, which took minutes, everything worked perfectly. Also, you'll no longer see a grayscale line in the palette because that line, while still part of the actual palette sprite, is now hidden to avoid editing. This is important because the Palette Swapper needs to use the first line of colors to know which pixel belongs to which row. See above, Megaman has a dark red scheme. These colors are in the second line in slots #5 and #6. In the first line, these colors are Megaman's recognizable blue colors. But, this is not actually what the sprite looks like within the program. The actual sprite uses monotone colors from the hidden line in slots #5 and 6. As the user switches lines, those pixels will change colors to whatever is in those two slots. All of the pixels in the sprite follow this pattern.
Palette Editing
Finally, we needed the ability to edit the palettes. That was quite simple to do. Providing keyboard input allows the user to increment or decrement the colors by 8. An important note is that colors in this engine are limited to 15-bit RGB color, like the SNES. Without going too much into technical aspects, this means that the three color components are ONLY multiples of 8. In order to properly track changes and have them correctly shown whenever the palette is redrawn due to user editing, a data grid (think: spreadsheet) contains the actual palette data in numerical form {BBGGRR}. These numbers are used to tell the engine what color each pixel in the palette sprite is supposed to be. Simple as that. Next thing to tackle is replacing that block with whatever sprite we want... so we need to import new sprites. But we'll stop here for today.
The first thing to do was to generate the palette itself. Thanks to PixelatedPope's Palette Swapper, generating the palette is as easy as having a single sprite with all of the desired colors. This sprite is created at runtime by drawing a series of colored boxes onto a surface and saving it as an asset. At the top left you see a large box. It's comprised of 16 columns of 15 colors, and you'll notice that the first one is grayscaled, while the others are red. This is important and I'll get to that shortly. But the idea of the program at this stage, is that when the user switches columns using the left/right arrows, it will change the active row, and the new shader will color the block using those colors. Well, it didn't work as intended... in that it didn't work at all! ANY input seemed to just make the block vanish! Why? Up to now, I've no clue. I'd used the shader many times and always knew how to implement it correctly. But it doesn't matter, because:
After rebuilding everything from scratch, which took minutes, everything worked perfectly. Also, you'll no longer see a grayscale line in the palette because that line, while still part of the actual palette sprite, is now hidden to avoid editing. This is important because the Palette Swapper needs to use the first line of colors to know which pixel belongs to which row. See above, Megaman has a dark red scheme. These colors are in the second line in slots #5 and #6. In the first line, these colors are Megaman's recognizable blue colors. But, this is not actually what the sprite looks like within the program. The actual sprite uses monotone colors from the hidden line in slots #5 and 6. As the user switches lines, those pixels will change colors to whatever is in those two slots. All of the pixels in the sprite follow this pattern.
Finally, we needed the ability to edit the palettes. That was quite simple to do. Providing keyboard input allows the user to increment or decrement the colors by 8. An important note is that colors in this engine are limited to 15-bit RGB color, like the SNES. Without going too much into technical aspects, this means that the three color components are ONLY multiples of 8. In order to properly track changes and have them correctly shown whenever the palette is redrawn due to user editing, a data grid (think: spreadsheet) contains the actual palette data in numerical form {BBGGRR}. These numbers are used to tell the engine what color each pixel in the palette sprite is supposed to be. Simple as that. Next thing to tackle is replacing that block with whatever sprite we want... so we need to import new sprites. But we'll stop here for today.
Comments
Post a Comment