1

Looking to find a way to detect pixel-to-pixel overlap between two sprites without involving physics (if possible), because running a bunch of physics calculations each frame seems superfluous.

I have a player sprite and an enemy sprite. The enemy follows the player, and the player takes damage when touching the enemy. Until now, I've simply tracked whether the enemy's position sits inside the player's frame to determine whether the player should take damage.

func touching() {

if position.x > player.frame.minX && 
position.x < player.frame.maxX && 
position.y > player.frame.minY && 
position.y < player.frame.maxY 
{
    dealDamageTo(player: player, amount: collisionDmg)
}

However, there's some empty space in the sprites (invisible pixels), and gameplay would be significantly improved if "touching" were defined by their actual pixels rather than their frames.

A workaround I've tried is to store a "hitbox constant" for my sprites. With this, their overlap calculation now factors in their frame plus (or minus) a hitbox constant depending on if I want "touching" to be further outside or inside of their actual sprite frame.

Is there any pixel-perfect solution that doesn't require me to complicate computations with a physics world and physics bodies?

side note: Wondering if adding physics bodies and then setting

physicsBody.isDynamic = false

would keep out all the extraneous physics computations?

edit: I've realized I assumed physics bodies solves this pixel-perfect issue and could be wrong about that. But, if the solution is to use physics bodies, I'd love any insight anyone might have for how such collisions are being computed.

mnuages
  • 13,049
  • 2
  • 23
  • 40
dandius_zielth
  • 11
  • 2
  • Ask yourself if you really think that adding code to your program to somehow detect if 2 nodes' textures overlap will really be more efficient than having the actual code drawing the nodes to do so? Also - is this a case a premature optimisation? Have you tried using physics bodies and found it to be too slow, or are you just assuming that it will be? – Steve Ives Sep 16 '20 at 10:22
  • @SteveIves Thanks for responding! I'm pretty new to SpriteKit; I suppose I still underestimate how costly drawing updates are versus the logical updates. This certainly could be premature. I have been under the impression that in making a game under mobile's smaller computing power, I should aim to make sure as my project size scales, I have made it as efficient as I can. Eventually I plan on adding multiple enemies, each with their own attacks and player-tracking AI... seemed like a lot to add physics on top of that. Maybe I can only really know when I get to that point. – dandius_zielth Sep 16 '20 at 18:43
  • SpriteKit is pretty well optimised, and modern iPhones and iPads have a lot of CPU power. The physics engine generally doesn't cause any performance issues, with those problems usually coming in having masses of user code in the `update()` for every sprite. However, pixel-perfect collisions are noted in the Apple docs for being CPU intensive, so you might want to see if you need this accuracy everywhere. – Steve Ives Sep 20 '20 at 21:12

0 Answers0