Hitbox Diagram

[Jeffw]

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.

[marinomitch13]

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.

[Jeffw]

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.

[marinomitch13]

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!

[hchien]

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.

[LMDAVE]

Using the hitboxes one pg 1, would this be what you're looking for?

[mikegmi2]

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.

[LMDAVE]

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.

[up2ng]

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!

[marinomitch13]

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.

[LMDAVE]

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.

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.

[Jeffw]

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:


But this is considered a hit:


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.

[up2ng]

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).

[f_symbols]

fixed, for now...

[Jeffw]

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.