Why doesn't mario get hurt here? Do they add i-frames, or is the shell's hitbox only in the front half?
>>3334183
What kind of meme are you trying to start?
>>3336467
The hitbox is slightly smaller than the sprite to prevent Mario dying on what seems to be nothing
>>3336471
it's research
Shit like this should be documented
>>3336475
Well, for one, Mario doesn't get hurt by a shell if the shell itself isn't moving, as you can see one the gif you posted, Mario can kick shells. If the shell was moving, he'd get hit by it instead. It's not about hitboxes.
I still think you want to troll, but I can't discern what kind of trolling are you aiming for.
ITT: OP has never actually played SMB3.
>>3336479
But right after he kicks it, he's overlapping the shell which is now in a moving state. So does the shell's hitbox size change when it changes state?
>>3336467
My two cents are that the game checks if Mario's kicking animation is playing. If true, no damage is dealt.
You can test it by kicking a shell and timing it so that another shell touches you from behind (while the animation is visibly playing).
>>3336534
Awesome, thank you! So it is i-frames, sort of. For the kick animation.
My guess is that they managed to sync it such that by the time the game checks if Mario is touching a shell, the shell's already moved.
can it keep track of the movement direction? Shell coming towards Mario is death, shell going away is not?
>>3336534
Or you can kick a shell while standing right next to a wall.
Why can small Mario run through Bowser's legs without getting hurt?
>>3336487
The shell will only hurt Mario if it is moving in his direction. In that gif it is going the other way.
>>3337546
if it hits you from behind, it's still moving towards you (distance between Mario and shell is decreasing each frame). The direction Mario is facing, or even if he's trying to run away, is secondary
>>3337548
That seems like a waste of memory and processing power for an NES game.
>>3337564
>waste of memory
The game must keep track of the direction the shell is going. That can be a bitflag
>waste of processing power
if the shell's center point is left of mario (that's a single cmp) and the shell's direction is right (check the bitflag), it's a collision. If the shell's center point is right of mario and the shell's direction is left, it's a collision. Otherwise it's clear. That's about 10-20 cycles tops. That routine is only checked if shell and mario overlap their hitboxes to begin with, to check if the collision is successful or not. That is, while the shell is moving freely, none of that code is executed
>>3337582
>A stepped on shell does not cause any harm to Mario, no matter how you interact with it. You can kick it, and it will turn into a moving shell, which *can* hurt you
OP shows a scene where a shell is moving while touching Mario, that's the problem. It's the first couple frames after Mario kicked the shell. The kick happens while the two visually overlap. From that point on the shell moves, but visually touches Mario, yet he's not hurt. What's the internal logic behind this sequence?
>>3337574
I see now.
I was thinking: find distance between mario and shell > store that value for a frame > find distance again > check if that value is less than previous value
>>3337592
welcome to the world of cycle counting. There's always a solution that's more efficient. Mine's pretty brute force as well, you can probably shave off an instruction or two while keeping the same logic
