Game Development Community

bitMask Limit

by Jared Schnelle · in Torque Game Engine · 02/27/2003 (4:43 am) · 3 replies

I've hit the 32 bitMask limit. I'm rather shocked it came so fast(and that it existed); however it's limit makes perfect sense.

For those of you who dont know, there's a hard limit on the number of bitmasks you can use. The mDirtyFlag is a U32, which means we can use no more than 32 flags when sending class data across the network.

I'm sure they did it this way for the super easy ability to do a bitmask check against the mDirtyFlag to see if we need to update stuff to the client. My problem is.. I need more than 32.

I'm wondering what the best solution is to this. Should I just piggy back another set of Bitmasks on the current bitstream? Or should I simply use bools within my classes to check if a network update is needed?

Or should I move the low priority stuff to bools, and simply use the high priority(read: constantly changing) info to the original bit mask?

Thanks for any insight,
Jared

#1
02/27/2003 (11:35 am)
Not sure there's a good way of solving this problem for you easily. I am very suprised though that you've reached 32 groups of data though; your object must be massive.

Are you sure that there's no static data that can't be put into an assocaited datablock or perhaps group your data better somehow?

- Melv.
#2
02/27/2003 (4:08 pm)
Yeah it's the player data object that I've expanded quite a bit. His health / power / other functions take up about 12 different flags.

I didnt realize until after I made the post that it is 32 bits of information _per_ object. Thinking about that, it's quite suprising, but there's just so much class inheritance that it's invevitable I suppose.

I reached 2 "easy" conclusions:

1) For the time being, the health / power / etc are just using bools bMask_Health, bMask_MaxHealth, etc.

2) I could group these into bigger clumps. The Current/Max health could both use the same bitmask, etc.


I'm going to work with 1) for a while and see how it works out.
#3
02/27/2003 (4:34 pm)
I think that rethinking how you're grouping stuff might be the best solution. Consider what percentage of packets each bit is going to impact. If it's less than 1/32 of them, you might consider clumping the bit. :)