Strongly Recommanded Modification to GG about GhostInfo.updateMask

#1 It is very fast to transmit/receive a 32 bit number instead of 32 objects.
You can combine a few masks in a single mask.
You can check for unused masks in parent classes.
I can't believe you reached the limit, your object should be huge.

I think there is a resource for 64 bit mask.

#2 If you have 64 masks, you're raising the base size of your object updates by quite a bit. IE 64bits minimum unless you are doing something clever like Picasso says.

Are you profiling your network usage to make sure you are being as efficient as possible? A lot of the time you can group uncommon things into one big mask - you waste a little bandwidth when they need to update but since they change so rarely, it doesn't matter.

edit: It would be nice of GG to typedef that U32, though, so you can easily change to a U64 or a structure, though.

#3 Also of note as I have this in our tracker as we have hit that 32 limit is that most of the child classes will start their flags at the end of the previous classes's flags. While there might only be 4 or 5 flags in a single class, once you add them all up hitting 32 isn't all that difficult.

#4 I still insist on my point!
Actually the updated infos is something like a tree structure, So is it better to have a tree structure-like maskbits?

#5 I like Ben's idea of making a typedef for the net mask. it should default to U32, but then it woud be easy to change to a U64 if necessary.

#6 To bring up history, this has been debated in the past--and even with the increase in general computing power for the mass market, blithely changing from a bitmask to a more complex structure has a significant (and I mean very large) performance impact.

To this day, without going in and writing pure assembly code, a bitmask test is still one of the fasted operations you can do at the C++ source code level--and the entire networking system is based on being able to apply dozens to low hundreds of updates to client side objects per tick--which is only 32 milliseconds.

Stipulating that more bitmask values are needed for expandability reasons (I've run into this myself in the past on personal projects), a move to a non-maximally performant test is still not the best solution.

Also stipulating Ben Garney's observation that moving from 32 bit to 64 bit increases the general size of objects significantly, it's still a better option than implementing a system that is based on a different big O for update applications.

#7 One more observation--bitmask availability is reduced heavily by deriving classes from ShapeBase, or even worse, Player. Unless your target class simply must have everything that both ShapeBase and Player provide functionality wise, you should strongly consider inheriting from GameBase directly.

#8 I agree with Stephen.

If you reached the bitmask limit, this means you surpassed the intended purpose of the example classes (aka: anything below GameBase), and thus it is time to roll your own classes (deriving from GameBase or even from SceneObject directly). You're only hurting your game by having all the ShapeBase and Player stuff hogging your network.

I feel obligated to remind Torque is a game engine, not a game maker. The major difference between the two being that in game engines are meant to be modified to suit your game.

If you really need to have a whole lot of flags for your object, I think you can use a BitVector to store them and send them using stream->writeBits().

#9 I know that internally we've taken care not to derive from ShapeBase or GameBase unless its a clear win. You'll notice alot of the new classes derive directly from SceneObject to avoid the overhead.