[KevvyLava]

Hi all,

I've spent some time working on a Legend of Zelda hack lately, but I want to do some slight modifications to a game that doesn't appear to have any proper utilities, so I'd have to dive in from scratch here, it seems.

My favorite fighting game of all time is Super Street Fighter II: The New Challengers for SEGA Genesis. My only real gripe with the game is that the rounds are often over too quickly, so I'd like to figure out how to change the values so that all attacks do less damage.  There is a mechanic in the game during VS. Mode where you select your damage scaler, but even when selecting 1/8 stars, it's still over quickly.  I suspect there is a way to scale these back, but I really don't even know where to start.

I've seen people on YouTube pulling up the hex data while the game is going to see where the changes are happening in real time, but I have no idea if this is a realistic way to identify this data.

https://ibb.co/BLgF0JC

If anyone can recommend a way for me to identify the damage scaling feature in this game, I would be eternally grateful.  I suppose it'd also be possible to manually edit all of the damage in the game, but that'd probably be a much tougher proposition.

[Dacicus]

I would start off with a RAM search to determine where the damage scaling option is stored for each player in VS. Mode.  It might also be helpful to find the player HP addresses.  Then you'll likely need to use a debugger or a trace log to determine how the damage scale is converted to damage amounts.

[KevvyLava]

Thanks for the response. However, I don't know how to perform a RAM search. Would that allow me to adjust how many "stars" correspond to the damage scaler on the 2P screen? I was hoping it might be straightforward? Is there a program to do this sort of thing to find the hex values, or is this something that you do in the actual emulator while it's running, and you look to see which values are changing?

[gadesx]

Ram search is simply, but
for megadrive maybe the best option is using Retroarch.
(With snes, zsnes, snes9x, etc works fine)

You have to discard incorrect codes.

For example:
Lives code

There is 3,000,000 codes.
Cheat searcher 8 bit, value 2 (because you see 2 lives on screen)

There is 50 codes now.
(All codes != 2 dissapeared)
Doing this sometimes left a few codes and one of them can be Infinite Lives.

The other way is, unknow initial code.
You have to use:
Value is bigger now,
Less now,
Equal, Not Equal.

It takes more time.

Btw I have no idea about trace ram codes to the rom offset.

[Dacicus]

Would that allow me to adjust how many "stars" correspond to the damage scaler on the 2P screen?

It will be a starting point, but you might need to analyze the game's assembly in order to actually make that a permanent change.

Is there a program to do this sort of thing to find the hex values, or is this something that you do in the actual emulator while it's running, and you look to see which values are changing?

RAM search is something you do in an emulator while it's running.  I don't know if Kega Fusion has that capability.  I mostly use BizHawk for systems other than the NES.  There are tutorials available about searching RAM, such as this one and this one from TASVideos.  You can also find video tutorials on YouTube.

[KevvyLava]

It will be a starting point, but you might need to analyze the game's assembly in order to actually make that a permanent change.
RAM search is something you do in an emulator while it's running.  I don't know if Kega Fusion has that capability.  I mostly use BizHawk for systems other than the NES.  There are tutorials available about searching RAM, such as this one and this one from TASVideos.  You can also find video tutorials on YouTube.

Thanks for this information. I'm going to poke around and see if I can do a little damage. We'll see what kind of results I come up with.

[KevvyLava]

OK, so through trial and error I figured out using the RAM search function in Gens ("less than" searches for 2-byte values) that the damage scaler stars (1-8 stars per player) are stored in hex value 00FFFCEA. I was proud that I somehow figured that out. For whatever reason, player one's values are in increments of 256, whereas player 2's values are 1-8.

Now, of course, I have zero idea what to do with this information. haha. I tried using save states to see which values changed in battle, but then I reasoned out that even if I had noticed which values were changing, I wouldn't know how to connect them to what the above hex value is actually telling the emulator.

It appears my missing link is how OOFFFCEA actually sets the attack values for each subsequent game.  I guess in theory that shouldn't be hard to figure out for someone who knows what they are looking for, but I think it's a step-and-a-half beyond where my brain is at on these things.

Of course, I could be way off on this, so thanks in advance for your patience.

[Dacicus]

OK, so through trial and error I figured out using the RAM search function in Gens ("less than" searches for 2-byte values) that the damage scaler stars (1-8 stars per player) are stored in hex value 00FFFCEA. I was proud that I somehow figured that out. For whatever reason, player one's values are in increments of 256, whereas player 2's values are 1-8.

Good work.  It turns out that the damage scaler is only one byte for each character, though.  0x00FFFCEA is the player 1 address and 0x00FFFCEB is the player 2 address.  Not knowing the size (number of bytes) of data definitely makes searching more difficult.  If you've found the size of one value, the same type of data for other players/characters is often the same size.

I've looked into this project, and it requires knowledge of how to use a debugger and how to analyze assembly language.  The damage done depends on several variables:

• The damage scaler values for both the attacking player and defending player
• The character selected for the attacking player
• The type of attack being done
• The health of each player (there's something special about values of 0x50 for the attacker and 0x26 for the defender)
• Some other value that might come from the RNG

There might be other variables that I haven't found yet.  For example, there's an address that gets a special value if one of the characters is Vega, but IDK if that ends up being used for the damage calculation or is used for something else.  Based on the analysis I've done so far, my best guess is that the raw damage values are stored in a table ranging from 0x31772 to 0x31881 in the ROM file.

If you want more practice with RAM searching, try to find the addresses of some of those variables I listed.

[KingMike]

Good work.  It turns out that the damage scaler is only one byte for each character, though.  0x00FFFCEA is the player 1 address and 0x00FFFCEB is the player 2 address.  Not knowing the size (number of bytes) of data definitely makes searching more difficult.  If you've found the size of one value, the same type of data for other players/characters is often the same size.

Well, you can probably guess the size based on the range of data.
A value that only has a possible range of 1-8 shouldn't need 2 bytes of data (at least for 8/16-bit era consoles.
I don't know so much about newer consoles which sound like they like 2 or 4 byte data sizes.)

I do recall magazines like EGM printing a crapton of Game Genie codes back in the day that were all like "character X's move Y does more/less damage". I can't remember if it was the same version but it might be worth a look to see if anyone transcribed all those, as those would probably be a good starting point if there is. If there is a list, you would just to find a decoder app/website to get ROM addresses of that data. I assume that is probably damage tables.

[KevvyLava]

Thank you for your responses.

KingMike: Here are some codes akin to what you're talking about: https://www.gamegenie.com/cheats/gamegenie/genesis/super_sf2.html
I guess I was hoping that the damage scaler in the versus screen could be manipulated to have an effect down the chain on a different scale, rather than having to go in and modify every single attack, which I know for a fact I don't have the skill/knowledge (or time, frankly) to do when you account for all of the variations. My thinking was that if 1* made it so damage was a % scale of whatever 8* is, I could find the reference point of whatever it's scaling based off of and then adjust the number to a smaller number to give the players more health across the board. For example. if it turned out that 1* scaled 25% less than the standard damage for attacks, I could simply adjust it to be 10% or whatever. I can't imagine they have a different table of data for every * setting, right? I did hear that this game, being the largest Genesis cart ever made at the time (40 megs), did a lot "bank switching" or something. Not sure if this kind of thing would be affected or not because the same feature exists in Special Champion Edition.

Dacicus: Thanks for this info. The more I'm digging in here, the more I think this might be totally over my head without formal instruction / watching someone do this sort of stuff in real time. The odds of me correctly analyzing every type of attack/defense level, and the RNG (which I believe is tied to "stun"). Can you link me the resource you were looking at? I did some googling earlier and didn't come up with anything that seemed relevant.

[Dacicus]

Can you link me the resource you were looking at?

There was no resource specific to the game.  I got the info by finding the HP address for each player, dumping trace logs of the frames around when player 2 was taking damage, and analyzing the code in the log.  I did find http://www.romhacking.net/utilities/1123/ useful for debugging.  Also, http://www.romhacking.net/utilities/963/ has a disassembler that lets you specify the starting and ending locations for disassembly.  Unfortunately, neither of those emulators allow you to copy the disassembly from the respective windows.

Here are some codes akin to what you're talking about: https://www.gamegenie.com/cheats/gamegenie/genesis/super_sf2.html

I ran some of those codes through the decoder at http://games.technoplaza.net/ggencoder/js/ and found that they do match up with ROM locations from my analysis.  For example, code 2 "Don't take damage except from throws or grabs--both players" works by calculating the damage but never updating the player's HP with the new value.  Incidentally, it also implies that throws and grabs work via a different routine than the one I've found.

There's another issue that makes hacking this game difficult: ROM checksum fixing tools do not work properly after making edits.  Probably related to the "[c] This code represents a cart with known faulty checksum routines." code that GoodGen puts on it.

[KevvyLava]

The rabbit hole goes deeper! haha.

I think I may reach my limit on this. I might be better off with NES Zelda hacking using tools.  SSF2 appears to be a complicated game...more complicated than I thought.