Zinth
Smash Apprentice
Well, I've searched the boards pretty thoroughly for this and didn't find anything, so:
I'm interested in having an AR code that always draws hitboxes/hurtboxes -- just like in debug mode, but all the time instead of in just debug mode. My motivation for this is that I feel that having a burned copy of Melee where the hitboxes/hurtboxes are always drawn would serve as a useful tool for learning hitbox ranges, invincibility frames, etc.
It seems that a code to do this has not already been found (but if someone does have one in his/her hat, I would like to see it), and so I have set out to attempt to find such a code myself. My initial efforts, however, have, it would seem, been less useful than I had hoped, so I thought I would ask the community for any advice (and if anyone wants to help work on this, that would be cool, too).
My first attempt involved running Dolphin in debug mode so I could get RAM dumps, in the hope that I might find a change in memory that corresponds to the hitboxes being drawn. I attempted to minimize the number of frames (thus, presumably, the number of undesired memory changes) between RAM dumps by using features of Dolphin. My methodology was as follows:
1. Run Dolphin in debug mode and play SSBM with the AR code to enable debug mode
2. Enter Melee's debug mode and start a match under the "developer" debug level
3. Use the SSBM debug command to render the character models and hitboxes/hurtboxes simultaneously, and enter SSBM's debug "freeze frame" mode (start button)
4. Enter Dolphin's "Frame Advance" mode, and dump the RAM
5. Input the SSBM debug command to render character models but not hitboxes/hurtboxes and advance two frames so it takes effect
6. Dump the RAM
I then used HexEdit (for Mac) to compare the "before" and "after" RAM dumps for differences. However, there were far too many changes to memory to test all of them in an appealing amount of time. Perhaps this is how it usually is, and I will simply have to spend hours/days (there were too many differences for me to spend the time to click through them all) sifting through all of the memory changes to find the ones that render hitboxes/hurtboxes? Or perhaps my technique can be refined somehow so that there are less unwanted changes in memory? Or maybe there is some information (e.g., a list of memory locations that have been deciphered) which will help me sort through it all and find what I'm looking for? I'm open to any suggestions.
On a more speculative note, I am wondering if anyone has any idea how the option of rendering hitboxes/hurtboxes or not is stored in memory? I don't know if there's a single global variable that controls all hitbox/hurtbox rendering, or if each hitbox/hurtbox has its own flag somewhere that determines whether or not it is rendered (this seems less likely to me). I do know that the hitboxes/hurtboxes can be rendered per player in debug mode, so there's probably at least a flag for each player that determines whether that player's character's hitboxes/hurtboxes are rendered.
Any feedback will be appreciated. In the meantime, I'll keep working at it.
I'm interested in having an AR code that always draws hitboxes/hurtboxes -- just like in debug mode, but all the time instead of in just debug mode. My motivation for this is that I feel that having a burned copy of Melee where the hitboxes/hurtboxes are always drawn would serve as a useful tool for learning hitbox ranges, invincibility frames, etc.
It seems that a code to do this has not already been found (but if someone does have one in his/her hat, I would like to see it), and so I have set out to attempt to find such a code myself. My initial efforts, however, have, it would seem, been less useful than I had hoped, so I thought I would ask the community for any advice (and if anyone wants to help work on this, that would be cool, too).
My first attempt involved running Dolphin in debug mode so I could get RAM dumps, in the hope that I might find a change in memory that corresponds to the hitboxes being drawn. I attempted to minimize the number of frames (thus, presumably, the number of undesired memory changes) between RAM dumps by using features of Dolphin. My methodology was as follows:
1. Run Dolphin in debug mode and play SSBM with the AR code to enable debug mode
2. Enter Melee's debug mode and start a match under the "developer" debug level
3. Use the SSBM debug command to render the character models and hitboxes/hurtboxes simultaneously, and enter SSBM's debug "freeze frame" mode (start button)
4. Enter Dolphin's "Frame Advance" mode, and dump the RAM
5. Input the SSBM debug command to render character models but not hitboxes/hurtboxes and advance two frames so it takes effect
6. Dump the RAM
I then used HexEdit (for Mac) to compare the "before" and "after" RAM dumps for differences. However, there were far too many changes to memory to test all of them in an appealing amount of time. Perhaps this is how it usually is, and I will simply have to spend hours/days (there were too many differences for me to spend the time to click through them all) sifting through all of the memory changes to find the ones that render hitboxes/hurtboxes? Or perhaps my technique can be refined somehow so that there are less unwanted changes in memory? Or maybe there is some information (e.g., a list of memory locations that have been deciphered) which will help me sort through it all and find what I'm looking for? I'm open to any suggestions.
On a more speculative note, I am wondering if anyone has any idea how the option of rendering hitboxes/hurtboxes or not is stored in memory? I don't know if there's a single global variable that controls all hitbox/hurtbox rendering, or if each hitbox/hurtbox has its own flag somewhere that determines whether or not it is rendered (this seems less likely to me). I do know that the hitboxes/hurtboxes can be rendered per player in debug mode, so there's probably at least a flag for each player that determines whether that player's character's hitboxes/hurtboxes are rendered.
Any feedback will be appreciated. In the meantime, I'll keep working at it.