New answers tagged

1

Might be a bit late, but I did this same thing recently. The simplest method for me was to give each SKSpriteNode object a unique name, and parse the sprite's name from the description property: sprite.physicsBody?.description


0

You'r approach is rather strange, but stick with it an learn it's faults / strengths because creating it your way is a great way to learn. Below is the same concept just cleaned up a bit. Remember that in your setup, the box object has to be offset so the left side of the box is at the same position as its parent. This can be done with sprites setting the ...


4

Aside from my comment (don't have the flexibility to pull back a specific post at the moment) the answer to your question: No, but... There is no CPU gain or loss by changing scale. It's not even correlated, except for one case. And that one case is rendering. When you scale an object (especially non-uniformly) then it cannot be batched with other ...


1

One possible solution could be to use weak_ptr. A weak_ptr is like a shared_ptr, except it doesn't keep the object alive. If there are no shared_ptrs pointing to the object, it will be deleted, and then any weak_ptrs will hold NULL. You can use the lock method to get a shared_ptr from a weak_ptr. Example use: shared_ptr<Thingy> s = ...


7

At the moment I'm using std::shared_ptr to support multiple ownership of GameObjects so that they are held by both the scene and any other GameObjects within the game Don't do that. shared_ptr is often the wrong tool for the job, and that certainly applies here. Remember that smart pointers are for managing ownership; shared_ptr is about sharing ...


2

I see a couple of options: Have the Scene refuse to destroy a GameObject if the ref_count of it's shared_ptr is more than 1. This will oblige your users to take a great care of what happens. This might not be very fun or practical, though. In your GameObject architecture, add a listener pattern: when GameObject A links to GameObject B, tell B that A is ...


1

There is no one size fits all answer to this, as is so often the case. Generally though, if you can precompute it, do it. If your robot doesn't change all the time, so for example you build it and it stays the same the whole time, then what's the point of calculating all of its parts every frame. But if it does change all the time then obviously you can't ...



Top 50 recent answers are included