Encapsulate looking up a decorId from CollisionObjects

[Deconimus]

See this comment in #31.

Added int decorIdForCollisionObject(struct CollisionObject* collisionObject) to decor_object_list and replaced all relevant calls.

[mwpenny]

Looks good. We might eventually need a global ID system for collision objects.

[Deconimus]

We might eventually need a global ID system for collision objects.

Perhaps. For collision objects this could be kept rather simple though, e.g. COLLISION_TYPE_STATIC, COLLISION_TYPE_DYNAMIC, COLLISION_TYPE_DECOR etc.

I was thinking, maybe we should have a way of accessing the decor object that the collision object belongs to (if any). Looking at how collisionObject.trigger callbacks are implemented with their collisionObject.data void-pointer (e.g. in trigger_listener or fizzler). Collision objects of type COLLISION_TYPE_DECOR could either store the pointer to the decor object in collisionObject.data, or in a new pointer collisionObject.decor for stronger type-safety.

[mwpenny]

That's true. There are tradeoffs: IDs make comparisons between different types easy but add some duplication. The data pointer approach requires checks for each collision type but provides access to arbitrary object information after that.

Right now though, regardless of approach, the information needed in the end would ultimately just be the object type anyway (e.g., decorType == DECOR_TYPE_CUBE).

In most cases, I imagine only like types will be compared, and so the data pointer would work well for that. As we discussed in #31, this isn't needed right now, but would be useful when the time comes.