Post by RavMahov on Feb 18, 2014 12:01:06 GMT -5
Have you ever thought that it would be awesome to (re)make our favorite PisteGamez game, Pekka Kana 2, but you have no idea how, and where to start? Well, if that’s the case, this article is for you.
Its main purpose is to speed up any ongoing (and future) remake development, by providing data and hints about some parts of the game mechanisms. This way, you should be able to instantly come up with solution for your favorite language and platform, instead of researching engine parts by yourself.
Warning: This article is written by a human, and thus it can contain errors. If you encounter any of these, or understatements (parts that require clarification on any point), tell us. We are not responsible for anything bad that comes from reading this article and/or using any knowledge acquired from it, not to mention result of misunderstanding of any part of it.
Today’s topic: Palette – what you should know and what not to do with PK2 image data
As far as I remember, none of the remakes, recodes and fan games that use PK2 sprites take the palette into account. Most of them use altered graphics, mostly with alpha-channel transparency, sometimes made by hand using some kind of “pen” tool. Also, they use a different format, like PNG or GIF. Both of these things are really, really wrong when it comes to PK2.
“What’s wrong with it?”, you might ask. There are a couple of reasons, and things they imply. But for now, a bit of history.
Back in the ‘90s, most of the graphic cards could use only 256 colors at once. These colors were stored as palette, and could be changed by programmer at any time. This changed colors on the screen instantly, and was cheap, both in terms of memory and CPU usage. This allowed for a couple of things, most notably something called palette shifting or color cycling [more about it here and here].
The example of color cycling in PK2 is the pulsing color in some backgrounds, tiles and sprites (most visible in the Factory levels, also conveyor belts). It’s done by “shifting” the 15th row of PK2 palette (more accurate term would probably be “rotating”, because we do not lose any of the “end” colors, but instead put one of them at the beginning or end). The rest of effects achieved through using palette would be transparency (each of colors in the last row is considered to be transparent, and as you can see in Paint, the “background” color varies from file to file in PK2 sprites and other images), orange pigs and other monsters, and probably the most important thing: shading.
What do I mean by shading? Did you notice that, when the level is being loaded, loading text changes its color, especially when the level is going to be night-themed? It happens because PK2 is loading its palette from background (if available) and the rest of images are automatically adjusted to it. That allows tiles and sprites not to stand out (too much) in the night-themed levels, and most likely it’s the main culprit if your custom sprites do not look as expected in-game.
[screenshots from palette shading live demo]
What should you do in this case? You need to either look for 8-bit palettized mode in your language, some library or functions that allow to emulate it, or load bitmap image and deal with it by yourself. It’s not as hard as you might think, though. Might be a bit harder to do it “the best way”, but that’s not always needed. In JavaScript, it took about two evenings to code the demo (and find and fix a little oversight), after a bit of research in this matter. If you are interested in details, write below, and it will be explained in Part 2.
Now, why shouldn’t you alter the original images? The first thing is that the editor you are using might not guarantee that the palette used in the image will not be altered, too. Also, if you save the image with “bit depth” other than 8-bit, you are guaranteed to lose any palette information. That’s because in the most, if not all of 8-bit color images, values in pixel array are “pointers” to the actual color values in the color palette, while in 24-bit and 32-bit, they’re most probably colors in format like RGB (8 bits per channel, so, from 0 to 255 per red, green and blue), RGBA (the same as before, but there is additional 8-bit channel for transparency, also called alpha channel), BGRA and others. All of that is compressed in some way, but that doesn’t matter. What does matter is that, in color palette, the palette entries do not need to be different. That means, if you convert it to 24-bit/32-bit image, you just can’t go back, because neither you, nor the program does know which palette entry was used for this “green” and that “green”.
That was the case with the original Pekka Kana levels, and it took me a bit to understand why some of the things have the same color and still, the game knows that it’s not tile, but an enemy. After converting levels to the PNG and loading them in JSPK, all of the “green” pixels (with the same RGB values, of course) were tiles. After a bit of time spent on searching editor capable of changing palette, I made sure that there was no single color with the same value (at least where I needed it), and then it worked. I do not recommend doing that in PK2, because the game relies on it much more than in PK1.
The last thing I want to say in that matter for now is that… I'm not sure if it's all that we need to know about. It seems that PK2 also uses the palette indices in the pixel array for collisions, and maybe much more (that would explain why physics was a bit off in PK2 SDL port).
Soon, I might add live demo of tiles being shaded using background palette.
If you liked the article, comment it below
Edit:
The live example is... well... live. Try it here.
Its main purpose is to speed up any ongoing (and future) remake development, by providing data and hints about some parts of the game mechanisms. This way, you should be able to instantly come up with solution for your favorite language and platform, instead of researching engine parts by yourself.
Warning: This article is written by a human, and thus it can contain errors. If you encounter any of these, or understatements (parts that require clarification on any point), tell us. We are not responsible for anything bad that comes from reading this article and/or using any knowledge acquired from it, not to mention result of misunderstanding of any part of it.
Today’s topic: Palette – what you should know and what not to do with PK2 image data
As far as I remember, none of the remakes, recodes and fan games that use PK2 sprites take the palette into account. Most of them use altered graphics, mostly with alpha-channel transparency, sometimes made by hand using some kind of “pen” tool. Also, they use a different format, like PNG or GIF. Both of these things are really, really wrong when it comes to PK2.
“What’s wrong with it?”, you might ask. There are a couple of reasons, and things they imply. But for now, a bit of history.
Back in the ‘90s, most of the graphic cards could use only 256 colors at once. These colors were stored as palette, and could be changed by programmer at any time. This changed colors on the screen instantly, and was cheap, both in terms of memory and CPU usage. This allowed for a couple of things, most notably something called palette shifting or color cycling [more about it here and here].
The example of color cycling in PK2 is the pulsing color in some backgrounds, tiles and sprites (most visible in the Factory levels, also conveyor belts). It’s done by “shifting” the 15th row of PK2 palette (more accurate term would probably be “rotating”, because we do not lose any of the “end” colors, but instead put one of them at the beginning or end). The rest of effects achieved through using palette would be transparency (each of colors in the last row is considered to be transparent, and as you can see in Paint, the “background” color varies from file to file in PK2 sprites and other images), orange pigs and other monsters, and probably the most important thing: shading.
What do I mean by shading? Did you notice that, when the level is being loaded, loading text changes its color, especially when the level is going to be night-themed? It happens because PK2 is loading its palette from background (if available) and the rest of images are automatically adjusted to it. That allows tiles and sprites not to stand out (too much) in the night-themed levels, and most likely it’s the main culprit if your custom sprites do not look as expected in-game.
[screenshots from palette shading live demo]
What should you do in this case? You need to either look for 8-bit palettized mode in your language, some library or functions that allow to emulate it, or load bitmap image and deal with it by yourself. It’s not as hard as you might think, though. Might be a bit harder to do it “the best way”, but that’s not always needed. In JavaScript, it took about two evenings to code the demo (and find and fix a little oversight), after a bit of research in this matter. If you are interested in details, write below, and it will be explained in Part 2.
Now, why shouldn’t you alter the original images? The first thing is that the editor you are using might not guarantee that the palette used in the image will not be altered, too. Also, if you save the image with “bit depth” other than 8-bit, you are guaranteed to lose any palette information. That’s because in the most, if not all of 8-bit color images, values in pixel array are “pointers” to the actual color values in the color palette, while in 24-bit and 32-bit, they’re most probably colors in format like RGB (8 bits per channel, so, from 0 to 255 per red, green and blue), RGBA (the same as before, but there is additional 8-bit channel for transparency, also called alpha channel), BGRA and others. All of that is compressed in some way, but that doesn’t matter. What does matter is that, in color palette, the palette entries do not need to be different. That means, if you convert it to 24-bit/32-bit image, you just can’t go back, because neither you, nor the program does know which palette entry was used for this “green” and that “green”.
That was the case with the original Pekka Kana levels, and it took me a bit to understand why some of the things have the same color and still, the game knows that it’s not tile, but an enemy. After converting levels to the PNG and loading them in JSPK, all of the “green” pixels (with the same RGB values, of course) were tiles. After a bit of time spent on searching editor capable of changing palette, I made sure that there was no single color with the same value (at least where I needed it), and then it worked. I do not recommend doing that in PK2, because the game relies on it much more than in PK1.
The last thing I want to say in that matter for now is that… I'm not sure if it's all that we need to know about. It seems that PK2 also uses the palette indices in the pixel array for collisions, and maybe much more (that would explain why physics was a bit off in PK2 SDL port).
Soon, I might add live demo of tiles being shaded using background palette.
If you liked the article, comment it below
Edit:
The live example is... well... live. Try it here.
?