News: 11 March 2016 - Forum Rules
Current Moderators - DarkSol, KingMike, MathOnNapkins, Azkadellia, Danke

Author Topic: Approach to creating a menu hack  (Read 1152 times)

pmac135

  • Jr. Member
  • **
  • Posts: 9
    • View Profile
Approach to creating a menu hack
« on: June 26, 2018, 09:47:13 am »
I'm working on a hack for a SFC game (for simplicity, a RPG that has on screen menus (not a separate screen with transition for the menu)). I want to implement something similar to a custom debug menu. I've got the work environment set up, the ability to hook into the code to check for button presses to spawn such a menu, and ROM space to execute custom code.

I could use help trying to figure out what the best logical approach to tackling something like this would be. Advice in abstract form is fine.

Goals/Questions:
  • How would a hacker be able to identify something like a 'menu creation' function that already exists in the game? Would you set breakpoints around calls when you press the normal menu button? What kind of activity would you look for, to discern the non-helpful code from what you're looking for?
  • Are there any good, modern (or at least relevant) resources for navigating custom text insertion in something like a temporary menu (as opposed to translating something that already exists)?

Even if you don't have the answer to my questions, a push in the right direction would be really helpful. The idea of existing something that's already in the game is pretty simple to me, but taking the leap to create a new custom menu/functionality/whatever is a bit lost on me right now. Thanks

FAST6191

  • Hero Member
  • *****
  • Posts: 2898
    • View Profile
Re: Approach to creating a menu hack
« Reply #1 on: June 26, 2018, 03:50:41 pm »
I don't know current hacking grade SNES emulators that well but on the NES in things like FCEUX there are function finders wherein you go to the game, do essentially everything* but load the menu (move up, down, left, right, interact, wait to see if it changes audio, wait for any npcs to move...), tell it then to watch and when you next load a menu it will say "haha this function/list of functions was never called before" and then you have your menu handler.

*if you want to go to a really low feature area of the game (no npcs, nothing to interact with) then that also works. Doing "everything but" is just a way to narrow down the eventual search list.

That said the traditional way would be to look at the button press handler (the buttons are some register in the hardware somewhere, sometimes they will be copied (debounced) to another normal area of memory, usually then every vblank will be a function that checks this and responds accordingly) and see what it does.

Menu hacking itself is something of an aside from most of the rest of text hacking. It is where you encounter things like fixed width sections (no pointers or size values, see also why various RPGs of that era will have odd spell names), issues with graphics (most games will have a next text box command, or you can finesse your translation to fit within limits, menus however, especially overlay ones, tend not to have such luxuries and that could lead you down a massive hole), direct functionality tied to it (meaning it won't necessarily be in nice text sections and may even be wedged in the game code somewhere), it might even have a different font and encoding but that is probably not a huge deal here.

If there are sub menus (think the sort of thing a bad UI might make you press b 20 times to get back to the game) then that can be both easier or harder to handle.

Basically there is no general case for the second bullet point so I doubt you will find anything of great general relevance, and actually probably not much in the game specific world either. Anybody playing at adding menus like this probably knows anything I will write here in this reply.

Option 2. If there is a menu option you don't care about or could be considered redundant then knock that out in favour of your debug menu. It may save fiddling with graphics issues as well.
A lesser, but more elegant in some ways, version of this would be to do like the game devs of that era often did and "hide" the debug menu call in a lesser used menu function. You find it in the same way as the general menu call function (maybe even easier if you do have a feature like the function finder as there are even fewer things to do in a menu)

pmac135

  • Jr. Member
  • **
  • Posts: 9
    • View Profile
Re: Approach to creating a menu hack
« Reply #2 on: June 27, 2018, 09:47:17 am »
Yes, I understand. Others' thoughts would be helpful but thank you for the reply

Psyklax

  • Hero Member
  • *****
  • Posts: 1107
    • View Profile
    • Psyklax Translations
Re: Approach to creating a menu hack
« Reply #3 on: June 28, 2018, 10:47:09 am »
a SFC game (for simplicity, a RPG that has on screen menus (not a separate screen with transition for the menu)).

Apologies in advance for this, but why do people insist on keeping their target game a secret? I see this all the time. In some cases, telling everyone which game you're talking about can actually make it easier to get help. Sorry, I just don't understand the secrecy.

Nothing personal to you, by the way, you're just the latest person I've seen doing this. :)