So I understand Marathon uses a cylinder to represent the hit detection. However, this leads to situations where the player can shoot at the transparent parts of the monster and still register a hit. Is there a technical reason why Bungie decided not to do a transparency check on the sprite to allow the bullets to pass through the empty portions?
I'm thinking it has to do with how the monster's sprite pitches during aiming, or maybe even multiplayer to ensure consistency during quick sprite spins.
Hit Detection
3 posts
• Page 1 of 1
Dec 10th '16, 07:26
I think it partially has to do with the fact that bullets are calculated as actual moving objects, it would make that sort of calculation very costly.
It may also be because it is completely impossible, as the engine calculates physics interaction & collision before it starts drawing the scene.
If one did manage to rebuild the engine from the ground up to do this, there are a few glaring issues. Namely, how would it work when a projectile hits a guy in front of you from the side?
The issue is compounded further by the addition of net-play, where two players can see a third from different angles.
It may also be because it is completely impossible, as the engine calculates physics interaction & collision before it starts drawing the scene.
If one did manage to rebuild the engine from the ground up to do this, there are a few glaring issues. Namely, how would it work when a projectile hits a guy in front of you from the side?
The issue is compounded further by the addition of net-play, where two players can see a third from different angles.
Look, a 3d scenery plugin: http://simplici7y.com/items/3d-scenery-for-m1
Look, an M1 Weapon plugin: http://simplici7y.com/items/tacticus-m1-weapons-redux-2
Look, an M1 Weapon plugin: http://simplici7y.com/items/tacticus-m1-weapons-redux-2
Dec 12th '16, 08:58
It would be difficult, because monsters are drawn as sprites, not cards. The precise xyz position of any given pixel in a sprite isn't defined. It can't be, because as you orbit around a sprite, in yaw or pitch, the sprite doesn't change. I suppose they could've done a transparency check using the projectile's 'point of view' as a way to be consistent.
They would've had an easier time, for example, getting pixel-perfect collision with wall textures that have transparency (grates), because the 2D image is mapped onto a 2D face (wall) instead of to a point.
At some point, I thought it would be possible to hardcode pixel perfect transparent texture collision with Lua. You'd have to define the solid and transparent regions of the texture by hand in the script, and then calculate to which texel the point of impact corresponds. But again, even that wouldn't work for sprites.
They would've had an easier time, for example, getting pixel-perfect collision with wall textures that have transparency (grates), because the 2D image is mapped onto a 2D face (wall) instead of to a point.
At some point, I thought it would be possible to hardcode pixel perfect transparent texture collision with Lua. You'd have to define the solid and transparent regions of the texture by hand in the script, and then calculate to which texel the point of impact corresponds. But again, even that wouldn't work for sprites.
3 posts
• Page 1 of 1
Return to Aleph One Discussion
Who is online
Users browsing this forum: No registered users