Category: interviews

Presented by JAM of Metroid Construction

To see JAM’s developed sets on RA, click here. You can also follow him on YouTube.

An Epic Mechanics Hack

JAM’s Spazer Plasma Mix hack of Super Metroid has been featured in comprehensive mods such as Hyper Metroid and Super Metroid Redux. So what does this hack do? Read on.

1. Demo Reel

December 17, 2025

Writes clymax:

Spazer-Plasma combo can be combined with any combination of the other beams.

2. Full Showcase

October 9, 2016

Writes LabyrinthHunterSKB:

Great patch. A definite must pick up for every Super Metroid fan that always want a Spazer and Plasma combined that Nintendo couldn’t do for this game. I decided to showcase this because this was really cool. There is a reason for this and its not because they were lazy at all.

3. Dev Commentary

Original Post: https://forum.metroidconstruction.com/index.php?msg=46573

July 14, 2015

5 years ago…

I started this project without any chance to success. In next few days I understood a lot of information, where the needed pointers are, how the tilemap structure works etc. It allows me to understand what to do and how to do it.

I started planning my work finally realized that I’ll have no space to make what I want to. Then I got rid of unused tilemaps (like Plasma Beam 3 tiles long. In game used only states of 1, 2 and 4 tiles). I tried to optimize the data, but still got failed. Not enough space.

I have idea to avoid it, by using the same tilemaps for different beams and it works fine, so I started repointed, worked a lot and then… suddenly understood that all optimized tilemaps are looking corrupted in the rooms with acid. So Many Time WASTED.

I was working on this project and stoped from it from time to time and then I finally found a decision. How to fit all this data into bank $93. It works perfectly when I tried it, but then, still have got problems in some rooms, like small graphical glitch reported by many users. There is no way to avoid it, so I’ve continued my works.

While optimizing the data I’ve also noticed that how bad the Spazer tilemaps made. And that vertical and horizontal beams have different size. Besides of that, all sprites for Wave + Plasma beam is asymmetric that makes it impossible to insert beam between them without looking that “not right”, so I got rid of that asymmetry.

I’ve noticed that wide of Spazer and Waved Spazer Beams are changed differently. So I made separate behaviour just for shooting the Spazer + Plasma Beam without Wave. I had enough space for that, luckily.

Then… more unused data was found. Optimization, repointing, repeat, repeat. There were truly over 9000 minutes of working in pure hex in total. I haven’t worked with timer on, but I guess, it close to 15000. Finally I wrote all the tilemaps. Of course, there were some bugs in my tilemaps, so I tested every beam flying in any direction until…

I released version 0.99 with all tilemap done that works more or less stable and without tiling errors. Of course, there were things I wanted to fix, but I have no idea, how to make it.

Few mounths later I SUDDENLY realized what was wrong and released v0.992 with Phantoon fixed. Blame devs, not me, who set wrong Frozen AI pointer. But still, all the enemies still sharing its Spazer + Plasma vulnerabilities with ammo vulnerabilities. I wanted to fix it, but have no idea, what to do.

Few mountts later I SUDDENLY (again) have found where the pointers were stored. Setting to pointer to RAM $12 and accessing it later. Not surpising it took So Many Time… Understanding this eventually allows me to split ammo vulnerabities to finally make every eneme have its own unique vulnerabilities for Spazer + Plasma, not shared for something else. So, I wrote the code for it and make SMILE JX support for it, because vulnerabilities are now stored in a bit different order.

Thus, v0.995 was born. All vulnerabilities are separated, but not repointed. Now could I repoint them if someone could use the same space in Bank $B4. I was so tired and take a break. Poor RealRed did this manully for his awesome hack and succeed with it. Still this patch had minor bugs and one major: Ninja Pirates don’t won’t to reflect the shots and crashing the game. The bug discovered long time ago, but with no solution. And… it was pretty simple. There is 1 reference for uncharged beam arrays and 2 references for charged. And I forgot to change one pointer. That is it. v0.996 is ready. No more fatal errors.

Present time…

After a long break I’ve resumed my work on SMILE JX and with help of it finally repointed and expanded all the vulnerabilities array which can be freely edited in JX or RF (hi, Sadi. We both started a major projectes 5 years ago). Too bad, I can do it only for vanilla ROM, as if you’ve repointed something in Bank $B4, this patch may (or, most likely will) corrupt your data. Special tool in JX v2.84 will expand it manually, no matter if there was repointed data or if there isn’t. So, v0.997 of this patch is ready and released at the right moment. Check the first post.

FREE SPACE USED:
1A74B8..1A75EF

If this space is unused in your hack, it’s OK to apply it. Check for previous posts to know usage in another banks.

This version have a bonus. Since default power of Charge+Ice+Wave+Spazer+Plasma is 1500 (dec) and default power of Hyper Beam is 1000 (dec), I decided to make Hyper more powerful. Its power increased to 2000 (dec). And since you can mix all the beams, why the Hyper should looks like you’ve only collected Charge and Plasma? So, here you go, a new Plasma Beam. Wider and more powerful:

Full Combo item will be included tomorrow.

4. Exclusive Interview with JAM

November 14, 2025

FFV Central:

“Spazer Plasma Mix (v0.998).ips”: Be able to combine both the Spazer Beam alongside the Plasma Beam (by JAM). The original v0.997 patch by JAM had a bug in which Phantoon couldn’t be damaged with Missiles nor Super Missiles, this has been fixed by me and made a new v0.998 version of the patch with the fix to Phantoon’s vulnerabiliy table with SMILE RF. NOTE: There are graphical issues when using this patch.

Are the graphical issues specific to [Super Metroid] Redux…?

JAM: Nope, this is how this patch was made from the start. Almost the whole data bank was recoded and that’s why it’s not v1.something. I made the new tiletable that way, so for every frame of beam my tiletable starts from using my code, then a single fake tile that causes graphical issues and then the original game code for Wave+Plasma that was relocated. That fake tile is needed to determine the size of array for the already used in game combination. So, it was made like this, if simple, for each frame:

[array size of mixed beam shot][center beam data][fake tile data[array size of side beams]][side beam data]

Fake tile data is what causing the graphical glitches as for each tile the format is:

[XX XX YY TT TT]

where XX is the X position of the tile; YY is the Y position; TT is the graphical data to display, including flip data (is the graphic mirrored horizontally, vertically or both). So I just placed that tile as much outside of screen as I could and TT here is used as array size of the beam that is already in the game, which is 2 bytes. This is the source of that glitch. I don’t remember for sure but I guess I even made it more complex to use the data of usual Plasma Beam shots, followed by the data of Wave+Plasma shot (that dual bars waving), separated by fake tiles. All that needed to save space because the data of all beams, including the new ones would not fit the data bank and I know why developers haven’t did that. They could repoint some data that is already there but not beam related to another bank and they still could make the game size under 3 Mbs but that would need the other banks to be organized better.

As for enemy vulnerabilities, bank $B4 is overused. I guess, it’s $B4 if I remember it correctly. That patch modifies the vulnerability array for each enemy to include 4 extra bytes for the new beam combination without actually writing the new data. It supposed to be done by my own version of SMILE. It was coded but not released. My patch could contain this data without using any other software to repoint and extend the actual data but that means, if you have new enemies or modified vulnerabilities data of the existing ones and somewhere at 90% of hack making progress you decide to use my patch, all your custom data would be overwritten and you need to change the vulnerabilities again. That’s why the actual enemy vulnerabilities data was not included.

FFV Central: Can’t you just use the Plasma entry of the vulnerability data? Then you could add a hack routine to check for Spazer and then boost the vulnerability by another multiplier, such as +30%, on the fly. Assuming there is space for that hack routine for this admittedly inelegant solution. [Editor’s note: clymax would later in a new mod implement this suggestion but as applied to beam damage.]

JAM: It’s not the actual beam damage data, I mean the modifiers for every enemy. It’s just an array of $14 bytes for each enemy, one byte per beam/missile to determine who is vulnerable and immune to what. You can set immunity, 0.5x damage, 1x, 1.5x, 2x, 2.5x and so on. With patch applied it’s $18 bytes per enemy now, so these arrays needs to be relocated.

FFV Central: Noted. Thank you.

Related Posts

So, what do you think? Comment below, or come check us out on Discord.

This post has been viewed 39 time(s).