Topic: Palette Swapping demo for GameMaker

[TheouAegis]

Here's my palette swapping demo/tutorial for use in Game Maker. You could potentially use it in other game design software as long as they allowed bitwise file editing. This demo shows that palette swapping is pretty fast when used with proper programming techniques. Of course I used CV3 as a backdrop for the demo. You can't jump, just duck and whip. There are three candles which will drop a whip upgrade (which does nothing, so you can pick it up 3 times). This will demonstrate a per-step palette swap. There is also a Bone Pillar to demonstrate using multiple palettes for enemies.

Included in the demo is a script I wrote up quickly last night for simulating attribute tables and nametables (how backgrounds were handled on the NES). The script hasn't been tested because I have my doubts that it's even feasible. Still, it's there for anyone that wants to use it.

There is one other aspect I touched upon in the Information but didn't implement in the demo. I thought about it some more today and the more I think about it, the better the idea seems: Rather than having one sprite allocated for each sprite (meaning clicking the New Sprite icon for each sprite), it would be better for an NES-style game to have one sprite for each instance. For games like Castlevania, there are only ever 34 or so instances in the room at any one time (can reduce that even further -- you can make it so there can only be one type of subweapon at a time, so all three subweapon instances could be set to the same sprite). So you don't need any more than 34 sprites total (give or take). This would require a palette swap every time the sprite changes, but would drastically reduce RAM at an unknown cost to CPU load. Just something to think about.

DropBox download
MediaFire download

Revised GML script only

[Inccubus]

Cool.

[Esco]

Interesting.......... could this be modified to work with more colors per sprite? Say........... 16-32? I tried looking thru it to figure out how you did this............ but well, there isn't much notation to go on honestly to figure it all out.

On a side note: I was messing around with the concept of mapping where each pixel in each frame of a sprite was to a text file, and then using that to quickly change colors as needed. But I never could quite get it to work. Good to see that someone else showed those non believers on GM that this is truly possible.

[TheouAegis]

Don't use text files. Simple enough. Working with binary files is considerably faster, or should be. Working with text, GM has to translate everything, but binary is as binary does.

If you read the Game Information's entry on pal_swap_gif(), it covers multiple colors. I just tested and what I said in the game info was actually incorrect. I said 15 colors should be easy, but it's not that simple. GM only allows 8 bytes per variable (at which point it becomes signed, but that's unimportant here). Using the method I did in this demo, you can only store 8 palette entries in a variable at a time. So 16 colors and 32 colors would be doable, but would require additional variables. You'd probably want to use an array so you could just use a for loop to handle it. So like, in this demo if a palette was referred to as $2C1808 (since the transparent color would be ignored), that refers to palette entries $2C and $18 and $08 (out of a max palette of $3F).

For a 32-color palette, you'd need 4 variables to hold the palette if you use the same method.

palette[0]=$2C2F585A5C5E5F60
palette[1]=$626364707172787A
palette[2]=$9094989C9EAAABAC
palette[3]=$B5B7B9BABBDADB //leave 1 empty for transparency

Then the script would need to be altered such that on each iteration you'd check if palette[p]>0 and swap out accordingly.


I would hope GM decompiles its sprites before the game runs, but if it doesn't, that'd explain why sprite reading functions are so slow. As I said in the Game Information, a GMSPR file is a seriously compressed file. I took one look at the data and said, "Fuck it". Palette-swapping a PNG file would be faster than workign with GMSPR files.

[Esco]

Thanks for the reply. I looked thru this and your stuff again, but I sadly do not comprehend what you mean. Are you planning on releasing a demo of just your palette swap code with the necessary example files like most GM users do? If so I can just wait until you do and look at that. Because the way you have your file set up now (hexadecimal instead of decimal values for numbers and non color values, extra unrelated things, no notes, no example pal file, etc.) I just cannot make heads or tails of this. 

[TheouAegis]

There are no "necessary example files". It's not a simple copy-and-paste type of code. It needs to be implemented into a project. If I posted just the palette swapping code (which I've done before), no one would even know how to use it. They'd just look at it, tell me they think it makes sense, then forget about it because implementation would be over their heads. For PSX sprite palette swapping, you'll have to make yourself comfortable with working with a hex editor, if you aren't already; storing all the palettes in your game itself would take up too much memory. Although I don't know how much of SotN actually used palette swapping and how much was new sprites or overlays (like the rainbow effect).

Anyway, here's just the one script itself and another lengthy readme.txt for you to go over, as well as an external copy of YPbPr.pal for you to look at in a hex editor.

https://www.dropbox.com/s/366gyi5jpammyus/script_explained.zip

[Esco]

Before I say anything else, let me thank you for the reply and for taking the time to make a small example for me.

I appreciate the effort, the readme helps some, but sadly your code is a huge lump of argument0-15's, and hexadecimal, lol. It is still going to take a while to make any sense of it. But I will mess around with it some for sure. Thanks again.

[TheouAegis]

As I said in the readme, if you're getting confused by arguments (btw, argument0 is used as a normal script-pass argument) and alarms without events, then you need to expand your mind and stop thinking inside the box, which is what it means when you get confused in that way. Nowadays I can look at a code I typed up using arguments and it not only makes sense right away, it also looks aesthetically pleasing (to me at least). As for alarms... yeah I have a database of what each alarm actually corresponds to. It's not efficient, maybe, but some alarms I end up memorizing just like i have RAM offsets memorized. The way I see it, alarms and arguments are recognized by GM so using them as temporary or local variables (although when used outside of a script arguments are global variables) makes them get highlighted so they stand out in the code; that makes it a lot easier to read the code for me.

Edit:
Look at it this way: The only real issue you can cite against me using arguments and alarms is that you and the rest of the GMC have preconceived notions of what arguments and alarms are for. Go through my code and make the following substitutions:

argument0 = pickle
argument1 = lettuce
argument2 = tomato
argument3 = beef
argument4 = cheese
argument5 = bread
argument6 = egg
argument7 = mustard
argument8 = catsup
argument9 = relish
argument10 = onion
argument11 = fries
argument12 = soda
argument13 = patty
argument14 = cone
argument15 = pie
alarm[0] = cherry
alarm[1] = vanilla
alarm[2] = orange
alarm[3] = grape
alarm[4] = diet
alarm[5] = lime
alarm[6] = lemon
alarm[7] = acai
alarm[8] = apple

You get the idea. It wouldn't make any difference; it'd just change the excuse from being, "That's not what those variables are used for," to, "Those variables don't make any sense." If you think that example is bad, then how about this example:

alarm[0] = osasuna
alarm[1] = bizitza
alarm[2] = abiadura
alarm[3] = norabidea
alarm[4] = xede
argument0 = aita
argument1 = aitona
argument2 = birraitonak
argument3 = ama
argument4 = amona
argument5 = umea

You'd complain that the variable names were nonsensical and you couldn't understand the code because none of the variables made sense. In all fairness, that last example would make a LOT of sense if you copied that into Google Translate for Basque-->English.

Regardless of the name of the variable, to understand a code, you have to look beyond the surface (the variable names) and look at the roots. Look at the whole and not the parts. Since it's so easy to just re-download the files anyway, just open the palette swap script, delete all the comments, and just stare at it. It's a tiny script and if you just look at it without getting hung up on variable names -- which is really what your problem is -- then you should be able to see the whole picture. You can see a painting by Michelangelo and understand what it depicts without even knowing why or how it's a Michelangelo painting.

When the only code you read day in and day out is just 0445FAD493C258E000532, you stop worrying about descriptive names and just try to keep your variables in order. (My alarms are somewhat haphazard, but there actually is a loose set of rules governing how I use arguments... which has no meaning to anyone who isn't looking at the same blocks of code as me. )

[Esco]

As I said in the readme, if you're getting confused by arguments (btw, argument0 is used as a normal script-pass argument) and alarms without events, then you need to expand your mind and stop thinking inside the box, which is what it means when you get confused in that way.

............ you have no idea what you are babbling about here.

The issue is not my thought process; the issue is that your code is a sloppy, undocumented mess, and a poor example to be publicly submitted ANYWHERE of your work, as it assumes that the user knows what each of this argument#'s are the equivalent of. Which only you would know, without looking ALL throughout all of the code and different objects one by one.

I was trying to be nice about it since you just tried to help me (though I will have no use for this in the end).... but after your arrogant response above, I will be more than happy to just tell you the truth instead.
 

Nowadays I can look at a code I typed up using arguments and it not only makes sense right away, it also looks aesthetically pleasing (to me at least).

See my above response for why that works so good for you... and just you.

The mess of a long post

I am not reading that. And I doubt anyone else will either. 

[TheouAegis]

https://www.dropbox.com/s/o6vmrqwveuev7cf/pal_swap_gif.gml

There, a revised script for you. Still uses arguments, but they're arranged in more logical order and in such a way that commenting out their respective lines will allow them to be passed in the script call if you wanted to for whatever reason.

Also has fewer comments and the SWITCH statement has been converted to an algorithm. A sample code snippet for handling more than 8 colors was added as well.

Can't get much cleaner than a script that's defined in the first 5 lines (for a palette with less than 8 colors) and then left  to its own devices.