Donkey Kong Forum
Donkey Kong Strategy => Advanced Donkey Kong Strategy => Topic started by: f_symbols on September 01, 2013, 10:11:50 am
-
Below I have included the hitbox diagram (final version II). The majority of this data was acquired through trial and error testing of the recently released DK source code, along with "debug" in mame. Dean, Jeremy and Jeff H did a majority, if not all of the data gathering, I simply put together a visual representation of their findings.
In order for a collision to "register", the objects must overlap by a minimum of 1 pixel (the black lines are the width of a single pixel in this diagram).
The hitboxes extend from the virtual center point (green labeled pixel in sprites, black for springs), symmetrically in both directions.
Object box size total size
Jumpman 4x6 = 9x13
Fireball 3x2 = 7x5
Foxfire 4x1 = 9x3
Barrel 2x2 = 5x5
Spring 2x2 = 5x5
Pie 8x3 = 17x7 <---Huuj
A few things worth noting:
1. Fireballs and Foxfires DO NOT have the same size hitbox.
2. The pie hitbox is the largest in the game, it extends 1 pixel beyond the left edge of the pie sprite.
3. Jumpmans' X,Y position is offset to the left by a single pixel for sprites with an un-even number of pixels, such as the climbing spirtes.
4. The spring hitbox is the same size regardless of a springs "scrunchiness".
5. The barrel hitbox is also offset by a single pixel to the bottom and left sides of the barrel sprite.
6. The movement of Jumpman and other objects often proceeds at a rate greater than 1 pixel per frame; This means an object could potentially "penetrate further" before registering a hit; you may have 2 or more shared pixels on the X or Y field before a collision is "detected".
(http://i1083.photobucket.com/albums/j389/bilythekid_lvdc/hitboxfinal_zps78ee251b.png) (http://s1083.photobucket.com/user/bilythekid_lvdc/media/hitboxfinal_zps78ee251b.png.html)
I have also drawn a few simulated collisions, to demonstrate the idea of the minimum overlap requirement for a "hit". (updated)
(http://i1083.photobucket.com/albums/j389/bilythekid_lvdc/hitsmore_zpsa1fc0659.png) (http://s1083.photobucket.com/user/bilythekid_lvdc/media/hitsmore_zpsa1fc0659.png.html)
-
Wow this Is actually quite interesting Ethan! Did you figure the hitbox range out on your own, or did you find those images?
-
Ethan, you should double check your collision drawings. I'm pretty sure these are all examples of non-collisions. The pixels in these cases are "tangent" but NOT "overlapping".
-
That's what I was thinking, Dean. I thought you guys had concluded that it needs a 2 pixel overlap to be a collision. The spring drawing where it is barely hitting Jumpman's right toe definitely looks wrong to me; not enough overlap there.
-
And another fail :'( ill fix it again.
I thought that the pixel-thick line had rectified that problem, as it stands now, they all have 1 shared pixel. The pie shows this more clearly; I showed the borders of the outer-pixel, which defines the hit-box, jumpmans' pixel-thick line is overlapping, giving 1 shared pixel. If they need "2 shared pixels" I can take care of that, but as these drawings stand, They all have a single shared hitbox pixel (same X,Y value). Tangental "collisions" would show the black lines adjacent to each other, rather than perfectly overlapping (that is the shared pixel, because the line is 1 pixel wide).
Either way, its really an easy fix, assuming the actual hitbox diagram is correct...
Thanks again for the continued input guys, I really want to get this right.
-
Everything except the spring has one green pixel. Never noticed that before.
-
Everything except the spring has one green pixel. Never noticed that before.
Scott, the green pixel is the X,Y value point for the object of interest. The sprite's do not have green pixels :P
-
Scott, the green pixel is the X,Y value point for the object of interest. The sprite's do not have green pixels :P
Ok, so the spring also has a green pixel, but it's been obscured by the hitbox outline?
-
wht da hell is this...lol
-
Scott, the green pixel is the X,Y value point for the object of interest. The sprite's do not have green pixels :P
Ok, so the spring also has a green pixel, but it's been obscured by the hitbox outline?
No objects have green pixels, I added the different colored pixel to show the "X,Y location" for each object; We know where the sprite sits on screen, but where, within that sprite, does the game think you are (only a single X,Y value for each object)? The changed pixels are to show where the " X,Y center" is for each object type.
EDIT: Kappa
-
No objects have green pixels, I added the different colored pixel to show the "X,Y location" for each object; We know where the sprite sits on screen, but where, within that sprite, does the game think you are (only a single X,Y value for each object)? The changed pixels are to show where the " X,Y center" is for each object type.
Yes, I understood that from the previous explanation. :P
What I was really asking (observing, actually), was whether you intentionally chose a different designation for the 2 springs, since they are the only enemy objects whose X,Y coordinate is not marked with a green pixel.
My Original Thinking
At first, I thought you might have used a green pixel for each spring's X,Y location, then superimposed the hitbox rectangle on top of it, obscuring the pixel. I quickly dismissed this possibility, since it suggests that the X,Y position is located along the perimeter of the hitbox (which doesn't really make sense).
My Current Thinking
After looking at the diagram again, I noticed a black pixel centered within the interior of each spring's hitbox. I'm now assuming that you chose a different color convention (black instead of green) for those X,Y coordinates. Correct?
-
Sorry scott >:( The change of pixel color was simply a contrast issue; I tried to select the colors that would "pop" out of the sprite, so the viewer would notice it readily :)
-
Got it. Thank you for tolerating my idle curiosity. :)
Phew! Nice to finally be on the same page.
-
So, in a few recent games of mine I've been on pie factory wanting to climb up the right side retractable ladder but a freezer has been above me and I wasn't totally sure whether or not there was room to squeeze past it. I figured I should probably learn more about the hotboxes of Mario and the fireballs so that I can always know when it is safe to squeeze past such a fireball.
I'm interested if anyone knows the farthest left that a fireball/firefox can be above a ladder before it becomes unsafe to climb past it on the left, and also the farthest right that it can be before it becomes unsafe to climb past it on the right. Screenshots of the farthest left/right would be preferable if anyone has any for both fireballs and firefoxes. Also, if this can be answered I would like to find out if there's some rule that can be followed so that you always judge when it's safe, something like "It's safe to go whenever the left eye of the fireball is to the right of the right edge of the ladder" (I just made that rule up so I don't know if it's true).
Also, for a freezing fireball at the top right of pie factory, once the fireball has frozen there are two possible places where the fireball can freeze. Typically one spot will be slightly to the left of the retractable ladder and one will be to the right, although these two locations can vary from being far apart away from the ladder to being nearly on top of each other directly on top of the ladder. I would like to know which side of the fireball gives you more room to climb, or in other words, as the 2 freezing locations move closer and closer together does it become unsafe to climb on the left of the fireball or the right of the fireball first?
Lastly, if a freezer has frozen in the leftmost of the two possible freezing locations, I would like to be able to predict based on it's position whether or not it will be possible to squeeze past it on the left side when it moves to the rightmost freezing location, and come up with similar rule for this as above. If this can be figured out it would allow for making it past a freezer that is on the upper right of pie factory without first waiting for a freeze since you could safely climb as soon as it leaves it's leftmost freezing location.
These questions about freezers at the top right of pie factory would also apply to freezers that have reached the top right of barrels. The answers in this case will likely be different than those for pie factory since I doubt the top ladder on barrels has the same positioning relative to the right edge of the top girder as the retractable ladder's positioning relative to the right edge of the screen on pie factory.
If nobody can answer any of these I'll look into this stuff myself.
-
That's tough. One would also have to systematize a way to make sure jumpman is positioned in precisely the same way every time at the top of the ladder.
-
No, I assume jumpman always has the same x-position when climbing the same ladder, and that's all that would matter when determining if he will collide with a freezer at the top.
-
Oh, so you're assuming you'll be able to complete the climb while it is still frozen? Why is it that sometimes they don't stay frozen long enough then? Isn't their first freezing cycle a bit shorter? I was also assuming that there would be cases where you wouldn't have as much time (due to the ladder not being retracted at the right time) where you were wanting to still try to get past. The way you used the word 'move' I wasn't sure if you were referring to making the attempt after you had already seen where it would freeze next (so on a later repeat of the fireball going to either of the two freeze points) and that you were trying to get a 'jump' on it right as it passed over the ladder.
-
So I assume you're talking about the third thing I mentioned about making it past a freezer without first waiting for a freeze. I think you know that once the freezer has gotten stuck in the upper right, every time it reaches one of the two possible freezing points it will either freeze, or reverse direction and dart back to the right immediately without freezing, and these two events happen with equal probability. The way I see it working is that if you see a fireball freeze slightly left of the retractable ladder (in fact the fireball doesn't even need to freeze there, it would just as easily work if the fireball instead darted back to the right immediately at the left freezing point), then you can know the exact position of right freezing point, even if you have never before seen the fireball freeze in the right freezing point, since the fireball travels a fixed distance between freezing points. If based on the hitbox analysis it turns out that this right freezing point isn't within range of hurting Mario then it will be safe to climb up and finish the screen as soon as the fireball moves out of the left freezing point and passes to the right over the ladder, because once it reaches the right freezing point it will either freeze or dart back to the right, so it will never hurt you until, after going to the right again, it moves to the left freezing point again. This should allow for plenty of time to safely complete the screen, even without the fireball freezing.
-
The way I see it working is that if you see a fireball freeze slightly left of the retractable ladder (in fact the fireball doesn't even need to freeze there, it would just as easily work if the fireball instead darted back to the right immediately at the left freezing point), then you can know the exact position of right freezing point, even if you have never before seen the fireball freeze in the right freezing point, since the fireball travels a fixed distance between freezing points. If based on the hitbox analysis it turns out that this right freezing point isn't within range of hurting Mario then it will be safe to climb up and finish the screen as soon as the fireball moves out of the left freezing point and passes to the right over the ladder, because once it reaches the right freezing point it will either freeze or dart back to the right, so it will never hurt you until, after going to the right again, it moves to the left freezing point again. This should allow for plenty of time to safely complete the screen, even without the fireball freezing.
Oh yeah, that would be a very brilliant and practical thing to use in a game! We actually need to look into this!
-
It wouldn't be hard to determine this empirically. You could wait for a freezer and then have Mario walk into it. Then take a snapshot of the preceding frame. The only potential problem is if Mario advances more than 1 pixel per frame. If this is the case you could do it multiple times and take the one where Mario is the closest.
-
Using the hitboxes one pg 1, would this be what you're looking for?
(http://pic90.picturetrail.com/VOL2150/904309/21260953/408021364.jpg)
-
Nice graphic Dave. That would indicate there is more room to sneak up if the freezer is frozen on the right side of the ladder. Still, do they freeze in the same spots? It seems to be pretty random to me. I have snuck up with a fireball frozen right next to the ladder before, and also died trying.
-
Well, They could freeze at any pixel, whenever their counter/timer tells them to.
LOL, imagine having two freezers like the picture, and you go right through and finish like a boss.....might get accused of having a hacked board.
-
I think that there's actually even more room than Dave's picture indicates.
First, we need to realize that the vertical lines in Dave's picture do not represent the ladder. The ladder is 8 pixels wide. The left vertical line of the ladder actually lines up with the black edge of the left side of Jumpman's hitbox. However, the right vertical line of the ladder is one pixel INSIDE the black edge of the right side of Jumpman's hitbox.
Next, in terms of horizontal collisions (left / right edges colliding) with the fireballs, remember that the hitboxes have to completely overlap with each other in order for a hit to register -- if the lines are simply "tangent", it's a miss. So, you can actually move both fireballs one pixel IN and Jumpman could STILL get between them safely!
For vertical positioning, I'm not too clear on the highest point that you could sit on the ladder safely. There's actually another sprite besides the one shown in Dave's picture for Jumpman that shows just his butt, but I think that if you've gotten to that sprite you are in danger of being hit (someone correct me if I'm wrong about that). I think that as long as you stay with this sprite you'll be safe (again, correct that if that's wrong).
It looks like for "rules" involving when you can sneak past the fireball, we can now safely say that if the fireball sprite looks like it does in Dave's picture and is frozen on the right side of the ladder, if the left eye is "tangent" (directly on top of) the right vertical line of the ladder, you will be hit. If it's outside the right vertical line of the ladder, you can make it.
If the fireball is frozen on the left side of the ladder, if any portion of the orange "face" is directly on top of the left vertical line of the ladder, you will be hit. If it's outside the left vertical line of the ladder, you can make it.
Keep in mind that (somewhat counterintuitively) sneaking past the freezer while it's just barely to the left of the ladder is MUCH more risky than sneaking past it while it's just barely to the right of the ladder since it will always move to the right when it unfreezes.
Now, if someone could just determine a concrete solution for how the adjustable ladders work we'd be golden!
-
Now, if someone could just determine a concrete solution for how the adjustable ladders work we'd be golden!
It's my understanding (from Jeremy telling me) that the only variable part of the retracting ladders' retraction phase is how long it remains retracted at the bottom. Everything else is constant (moving up/down, and the time it remains fully extended). What determines how long it remains retracted, I don't know. But I do, however, know that it is possible for it to actually immediately start extending again upon having fully retracted.
-
First, we need to realize that the vertical lines in Dave's picture do not represent the ladder. The ladder is 8 pixels wide. The left vertical line of the ladder actually lines up with the black edge of the left side of Jumpman's hitbox. However, the right vertical line of the ladder is one pixel INSIDE the black edge of the right side of Jumpman's hitbox.
Actually the upper part of the retracting ladder is 10 pixels wide. But the lines represent the edge of the collision box. The other thing is to hope that when you get to the top mario changes to the sprite with box in the same x position....or you could get the temp phantom extra man that happens from finishing the board and colliding at the same time.
(http://pic90.picturetrail.com/VOL2150/904309/21260953/408025512.jpg)
Next, in terms of horizontal collisions (left / right edges colliding) with the fireballs, remember that the hitboxes have to completely overlap with each other in order for a hit to register -- if the lines are simply "tangent", it's a miss. So, you can actually move both fireballs one pixel IN and Jumpman could STILL get between them safely!
Well, we know from pixels, sprites can't move half a pixel, it's one or more pixels at a time, are you saying the black lines overlapping is not yet a collision? then yeah, they both could be moved in one more pixel on each side.
I'm pretty sure from Ethan's example on page one, that would be considered a collision.
-
So after some experimenting it seems to me like the hitboxes shown in the diagrams on the first page are slightly wrong. Specifically, this isn't considered a hit:
(http://s10.postimg.org/pcc4nl0o9/nohit.png)
But this is considered a hit:
(http://s8.postimg.org/pwrj4sded/hit.png)
So Mario's hitbox is wrong, and maybe the fireball's hitbox is wrong as well. I think this really needs to be resolved before we can figure anything out. Preferably the hitboxes should be drawn such that the black lines are part of the hitbox, so that if any part of the black lines are overlapped it is a hit.
It looks like for "rules" involving when you can sneak past the fireball, we can now safely say that if the fireball sprite looks like it does in Dave's picture and is frozen on the right side of the ladder, if the left eye is "tangent" (directly on top of) the right vertical line of the ladder, you will be hit. If it's outside the right vertical line of the ladder, you can make it.
I have a savestate that shows that it is safe to go if the left eye directly lines up with the right vertical line of the ladder, but I think that one pixel further left would make it unsafe.
-
Actually the upper part of the retracting ladder is 10 pixels wide.
Ah, I forgot about that. Therefore, that means ...
I have a savestate that shows that it is safe to go if the left eye directly lines up with the right vertical line of the ladder, but I think that one pixel further left would make it unsafe.
This is true.
are you saying the black lines overlapping is not yet a collision? then yeah, they both could be moved in one more pixel on each side.
I'm pretty sure from Ethan's example on page one, that would be considered a collision.
Yes, this is unfortunate. If you follow the thread, I pointed out this mistake two posts later, but Ethan never fixed the images for collisions. Every one of those examples posted for collisions are all errors -- they are all misses.
I've been using the term "tangent" to mean that the EDGE of the hitbox is SHARED by two objects. This term might be confusing, I'm not sure. By overlapping, I mean that the hitboxes must completely cross over each other so that the edges are no longer shared, but are overlapping each other. Again, maybe not the best term, but I've used these terms consistently and it's the best way that I can describe it.
This can easily be seen in the code. The code makes checks that use the < operator as opposed to the <= operator before a hit is registered. In other words, if the edges have an EQUAL x-coordinate (or y-coordinate), it is NOT a hit.
But this is considered a hit:
Jeff, please double check that -- that cannot possibly be true. Your diagrams show the same number of pixels between the two centers, which, from the code would mean that they would have to be both misses or both hits. In this example, they should both be misses.
You should double check that the fireball in question was not actually using the OTHER fireball sprite, which actually has a different size visually and so perhaps a different amount of the sprite can overlap without causing a collision.
It would be pretty shocking to me if the center actually changes depending on if it's a left facing sprite or a right facing sprite, especially since these sprites all have an odd number of visual pixels horizontally. That just wouldn't make sense to me.
SIDE NOTE: I just noticed that Jumpman's hitboxes of his other sprites in Ethan's diagram are wrong. They are both one pixel too tall (notice that the black box extends one pixel higher than it does for our hunched over sprite, which is correct).
-
fixed, for now...
-
Jeff, please double check that -- that cannot possibly be true. Your diagrams show the same number of pixels between the two centers, which, from the code would mean that they would have to be both misses or both hits. In this example, they should both be misses.
You should double check that the fireball in question was not actually using the OTHER fireball sprite, which actually has a different size visually and so perhaps a different amount of the sprite can overlap without causing a collision.
It would be pretty shocking to me if the center actually changes depending on if it's a left facing sprite or a right facing sprite, especially since these sprites all have an odd number of visual pixels horizontally. That just wouldn't make sense to me.
The collision is correct, and I actually figured out why it happens. So it turns out that for a right-facing fireball the graphics will be aligned slightly differently from the x, y center coordinate of the fireball, and since the hitbox is based on this center coordinate the end result is that the hitbox gets shifted one pixel to the right for a right-facing fireball. It's easy to verify this by comparing the graphics of a fireball climbing a ladder while facing left to the graphics while facing right. Both will have the same x-position and hence the same hitbox but the graphics won't be perfectly mirrored over the hitbox.
It isn't actually that surprising that this happens since in order for this NOT to happen it would require that when the fireball reversed direction, the graphics get mirrored over the center column of pixels, which requires there to be an odd number of pixel columns that get mirrored. I assume that the graphics for the fireball would be stored in a 16x16 block so it would almost definitely be mirroring an even number of pixels, which will cause the relative positioning of the hitbox to be off by one.
Probably the hitbox will also be shifted by one pixel relative to the sprite graphics for all the other sprites as well when they are facing the other direction.
-
Yes Jeff, I agree about the 16*16. Initially I had proposed that because some of the sprites are asymmetrical in width (fire), that the offset must occur when sprites face left or right, however we followed through, with enough detail, to determine that it was not an x,y coordinate shift, we never looked at sprite offset.
All of the sprites I analyzed fell within the 16x16 parameter; ie. The sideways barrel is 16 wide. I'm away from home right now, but I will update my sprite diagram to include all sprites in the game and post it this evening. The exorbitant number of jumpman sprites had me turned off (there's like 10 hammer sprites), but we may as well have them all done once and for all and figure everything out, while the interest is still here...
This was the initial sprite diagram, I will update it later to include more sprites.
(http://i1083.photobucket.com/albums/j389/bilythekid_lvdc/spritesizes_zpsd4939529.png) (http://s1083.photobucket.com/user/bilythekid_lvdc/media/spritesizes_zpsd4939529.png.html)
-
BUMP!!!
1. Just wondering if we solidified our certainty on these hitboxes and what constitutes a collision.
2. Was wondering if we A) have info on the hitbox of the hammer, as well as B) are we certain that Jumpman's hitbox remains the same while he is airborne.
3. Lastly, I was also wondering about how the hitbox/edge of the wall works. In particular, I was wondering why if one is pressed directly up against a wall that it prevents you from doing a true jump.
Thanks for any assistance/answers. <Mruczek>