More than 31 object types??

#1 The object types are based on a 32bit value. Since each type takes up one bit... you can only have 32 types.

It wouldn't be simple to extend this past 32bits... so if at all possible... steal bits that you don't plan to use. For example if your not using Atlas or Vehicles you can remove that code from your build of Torque and reuse those bits for your own types.

#2 Even a complex game shouldn't need that many bits. But you could always change the object type stuff to be a U64, which gives you 32 more type masks. I'd be a little nervous about doing this, as if I ate up 32 types quickly, another 32 might not help me that much...

What sort of types are you adding that are taking up the bits? Is it likely you will use up the next 32 quickly? If so, there are other techniques you can use to distinguish different kinds of objects.

#3 The problem is that stock TGEA sucks up 29 bits to begin with.... you merge a couple of resources and your out of bits.

I would prune out bits that i don't plan to use in my game if i wanted the easy solution.

The long term fix is replacing the U32 with a SimObjectType class which requires types to be registered at startup. You can then easily expand it to more bits if need be without needing to know what the size of the type is.

#4 Ah hah... That's pretty terrible. :)

What's the downside of the U64 fix? (Other than that it's not infinitely flexible - although I think one of the nice things about the type mask stuff is that it is very very simple and fast.)

#5 The downside of just replacing all the typemasks with U64s is that your wasting an opportunity to define a unique type for it. What would be easier to search for in the codebase? This...

U64 mTypeMask;

... or this...

SimObjectType mTypeMask;

Using a simple class which wraps a U64 is just as fast, more clearly defines the use of the mask, and makes it easier to change the mask size at a later date.

#6 Thanks for the replies, it seems that the SimObjectType class fix would be the most appropriate way to go.
thanks again.

#7 A typedef is a good idea. But your explanation made it sound like there would be more to it than that - maybe a linked list or some sort of dynamically sized bitvector to support arbitrary numbers of object types. Anyway, it doesn't really matter that much, there are obviously several good ways to resolve this problem and as long as people are able to make their games, life is good. :)

#8 Almost sounds like a job for STL "bitset" hehe