Posted: 1/27/2014 3:20 PM
Post subject: Hitboxes
Quote
MUGG
Editor, Expert player (2372)
Joined: 5/15/2007
Posts: 3940
Location: Germany
Gameboy TASer of 2015 NES TAS of 2013 Gameboy TASer of 2011 Gameboy TASer of 2010
So I'm interested in finding hitbox positions in gameboy/gameboy advance games, particularly Kirby & The Amazing Mirror. How would I go about doing that? I'm not so experienced with disassembling, trace logging etc. Maybe people who found hitboxes in their own games could write here how they found it or how it's stored in memory? I appreciate your input
Youtube • Livestream • Progress 11th TASer of the Decade 2010-2019 !
Posted: 1/27/2014 3:47 PM
Quote
TASeditor
Editor, Skilled player (1537)
Joined: 7/9/2010
Posts: 1319
Glitchy TAS of 2015 NES TASer of 2014 Speedy TAS of 2014 NES TAS of 2013
Search for values that change the same as you would search for x/y-positions, relative to the screen or the level. And then you need to somehow find the lenght/heigth of the hitbox.
Favorite animal: STOCK Gt(ROSA)26Sortm1.1(rtTA,EGFP)Nagy Grm7Tg(SMN2)89Ahmb Smn1tm1Msd Tg(SMN2*delta7)4299Ahmb Tg(tetO-SMN2,-luc)#aAhmb/J YouTube Twitch
Posted: 1/27/2014 5:53 PM
Quote
FatRatKnight
Editor, Skilled player (1203)
Joined: 9/27/2008
Posts: 1085
Rectangles have four sides. Games might have two numbers for position, then four numbers to define the hitbox. Or possibly only two numbers, using the position itself as one corner of the box. As for what numbers are used in the hitbox, that depends on the game. What I did is identify the basic object structure, look at numbers I know belonged to what object, and made a guess as to the relation. I know a Soul Blazer object uses 64 bytes and a linked list structure, and when I knew how these objects lined up, some numbers right by the position looked pretty suspicious. I made the leap that they might involve hitboxes, and they were related. Soul Blazer stores hitbox information as how far away each side is from the position. Naturally, these numbers don't change due to position since they already assume position is used from other calculations. The numbers for the top-left corner subtracts from the position to get said corner, while the bottom-right corner adds to the position. It wasn't that one number was negative and the other positive, but that different operations were used for the sides. The numbers really shouldn't be larger than the expected size of the object, values more than 100 pixels probably aren't related to hitboxes. In any case, most games should use some sort of object structure to keep information about a lot of things, whatever form they take. Once you know that these bytes definitely go to this object, see if those bytes have anything to do with what you're looking for. It's also possible the game has multiple spots in memory that relate to the same object, so perhaps those bytes aren't the only ones. That's been my experience so far.
Posted: 1/27/2014 6:11 PM
Quote
MESHUGGAH
Other
Skilled player (1919)
Joined: 11/14/2009
Posts: 1353
Location: 𝔐𝔞𝔤𝑦𝔞𝔯
NES TASer of 2013 NES TAS of 2013 NES TAS of 2012 NES TAS of 2011
If you know the positions of objects, test out which point is it (common ones are center, bottom left + top right / top left + bottom right). Most of the time the "hitbox" size is separated from "objects" properties because it's either hard-coded (probably you can find it in the ROM) or its calculated according to the objects size. With disassembling, you could get the information how the game processes these objects and you could trace log a frame where you get a hit (collision hit) and see how does it decides the hit check. Or goofing with memory values and make a simple lua script to draw a gui.box with values you think are close to your original position. Once you know 1 object's "hitbox" parameter, you can use the same offset (probably) for other ones too.
PhD in TASing 🎓 speedrun enthusiast ❤🚷🔥 white hat hacker ▓ black box tester ░ censorships and rules...
Posted: 1/27/2014 11:58 PM
Quote
Bobo_the_King
Player (80)
Joined: 8/5/2007
Posts: 865
One quick-and-dirty way to find hitboxes would be to use the Smart RAM Search script that FatRatKnight and I wrote. You'll find it here. You could put the bar over the enemy, then slide it up and down as the enemy moves. If its movement is complicated enough, the script should have no problem finding the enemy's y-position. From there, you'll need to look at which of those positions corresponds to the (a?) hitbox. Unfortunately, I never got around to adding the capability to flip the bar on its side and measure things' horizontal positions. The good news is that the x-position should be stored somewhere near the y-position and you might be able to find it by inspection. Do this for a few different enemies and you may be able to deduce where all the hitboxes are stored (they are likely uniformly spaced throughout the memory). If you decide to go this route, tell me what you come up with! I'm always eager to hear that my scripts are being used!
Posted: 1/30/2014 12:43 PM
Quote
MUGG
Editor, Expert player (2372)
Joined: 5/15/2007
Posts: 3940
Location: Germany
Gameboy TASer of 2015 NES TAS of 2013 Gameboy TASer of 2011 Gameboy TASer of 2010
Thanks for the help so far. I didn't find any hitbox data near the position address of an enemy in Kirby & The Amazing Mirror though... But there are some more games that I want to look into and maybe I'll get lucky with some. I can't find the hitbox data when it's in the ROM or calculated on the fly because - as said - I'm no good at disassembling and such things.. Also, please tell me why your lua script will help find the hitbox. Isn't it just another way to search the memory? I could simply use VBA's memory search for that.. EDIT: In fact, I went ahead and tried to make a script for Mario Land 1. But this needs a lot of improving.. I had to rely on a lot of dirty edits (/3 to hitbox, variable a, -8 to ypos) to make it work halfway.. 
Language: lua
while true do

  for i = 0xD100, 0xD19F, 16 do
            if memory.readbytesigned(i) ~= -1 then
            local ypos = memory.readbyte(i+2)-8
            local xpos = memory.readbyte(i+3)
            local movedirection = memory.readbytesigned(i+5)  -- 0:left 1:right
            local hitbox1 = memory.readbyte(i+10)
            local hitbox2 = hitbox1/3
            local typenumber = memory.readbytesigned(i+7)
            local typename = ""            
            local a = 0

            if hitbox1 > 47 then a = 16
            elseif hitbox1 > 31 then a = 8 end

            gui.drawbox(xpos+a,ypos,xpos-hitbox2,ypos-hitbox2, "", "green")
            gui.text(10,10,xpos .. "           ".. ypos  .."             ".. hitbox1)
            gui.drawpixel(xpos,ypos, "red")
            end
  end



vba.frameadvance()
end
Youtube • Livestream • Progress 11th TASer of the Decade 2010-2019 !
Posted: 1/30/2014 3:17 PM
Quote
Bobo_the_King
Player (80)
Joined: 8/5/2007
Posts: 865
MUGG wrote:
Also, please tell me why your lua script will help find the hitbox. Isn't it just another way to search the memory? I could simply use VBA's memory search for that..
Uh... I'm kind of at a loss for words... Your first post asked how to find hitboxes. I offered an easier way to find hitboxes and now you say the Lua script is "just another way to search the memory". Yes it is, but isn't that what you were asking for in the first place? What baffles me is that it sounds like you've considered going about it by disassembling and/or tracelogging, which is complete overkill. I get the impression that you want advice on a very different topic from what's been discussed so far. Smart RAM Search is especially handy for determining the addresses corresponding to (nearly) continuous parameters that are graphically displayed. That means it's ideal for things like hitboxes. Based on the Super Mario Land example I posted on the Smart RAM Search topic, it looks like we can confidently say that Mario's y-extents are stored in addresses C00C and C014 (or possibly C010 and C018). I ran your script (if anyone is wondering, it draws hitboxes on the screen for all sprites except Mario), so it's clear that you have some experience finding hitboxes. What do you need to do in Kirby (or other games) that you haven't done there? Anyway, I realize my post may look combative and I just want to say that is not the tone I intend. I'm genuinely curious about what you're looking for.
Posted: 1/30/2014 5:11 PM
Quote
MUGG
Editor, Expert player (2372)
Joined: 5/15/2007
Posts: 3940
Location: Germany
Gameboy TASer of 2015 NES TAS of 2013 Gameboy TASer of 2011 Gameboy TASer of 2010
Please understand this: I appreciate your help. I didn't try your lua script yet, I only saw from the screenshots what it does. And so I asked to myself, if the whole purpose to use it is to find position addresses, I can do that with memory search already so why use the script? I can find position addresses already. And I know that older games (gameboy) use enemy "slots" where 16 or 32 bytes are used for enemy position, sprite info, etc. so that is the experience that I already had. The experience that I don't have is how do I find hitbox data when it's in ROM? Or when it's calculated (not stored anywhere)? Even if I can't figure out how to do it myself, I hoped to read posts where others explain how they did it. Maybe someone will even be kind enough to help me find hitbox data in the games I had in mind (Kirby&tAM for now).
Youtube • Livestream • Progress 11th TASer of the Decade 2010-2019 !
Posted: 1/30/2014 5:37 PM
Quote
feos
Site Admin, Skilled player (1255)
Joined: 4/17/2010
Posts: 11495
Location: Lake Char­gogg­a­gogg­man­chaugg­a­gogg­chau­bun­a­gung­a­maugg
NES TAS of 2011
When you know well what you are looking for, debugging is not that hard to handle. Damage boxes: either stored in RAM and make perfect sense, or need to be found by when object takes damage. Case 1 is already obvious, now how to debug hitboxes? Set breakpoint on object's HP, it will work when he gets damage. If you pick that frame when breakpoint fires, and trace the code for that frame (from frame boundary accessed by frame advance, to when BP was hit), somewhere in the trace you will see how collision is being checked. You will see 4 points checked with other 4 points, being object and obstacle. If the game stores hitboxes in RAM, these points will be direct addresses. Otherwise you will see how they are made up. Normally X/Y point is taken and some offset is applied to form a box, according to object type. Later in the code HP gets actually decremented. It's very fun to figure these things out, and becomes very useful once you're capable of doing basic stuff with it (I learned it before tasvideos' eyes). Instructions aren't hard to learn during practice. Just get a set of them. http://tasvideos.org/ReverseEngineering.html
Warning: When making decisions, I try to collect as much data as possible before actually deciding. I try to abstract away and see the principles behind real world events and people's opinions. I try to generalize them and turn into something clear and reusable. I hate depending on unpredictable and having to make lottery guesses. Any problem can be solved by systems thinking and acting.