T3D 1.1 Preview - Only 1 SimObjectTypes bit left - RESOLVED (THREED-1581)

#1 Lol, this could be a problem.

#2 Agreed. Potential for quite the problem indeed.

#3 Logged as THREED-1581 as an improvement.

#4 My call is go to 64-bit. Even if you really want to, you're not going to reduce the type masks to less than about 20 anyway -- and that's still only leaving limited room for add-ons.

#5 yeah. it is serious problem to me..

#6 @Jeff - Was this a reduction in available bits in the 1.1 preview?

@Daniel

Moving to 64bit typemasks is a harder problem that it seems at first:

1. Need to find all uses of U32s for typemasks and replace them with a real SimTypeMask type.

2. Add 64bit bitmask support to TorqueScript.

3. Deal with the fallout of 100s of resources and packs breaking.

Still we'll discuss this and see what we can do.

#7 @Tom -- T3D has been gradually using up the bits:
T3D 1.0.1 -- 5 bits available
T3D 1.1 B3 -- 3 bits available
T3D 1.1 Preview -- 1 bit available

I'm not surprised switching to a 64-bit mask would be non-trivial and most likely very destabilizing. I was quite worried that TorqueScript could not currently represent a 64-bit integer. Unfortunately, the engine's been painted into a corner in this regard. In the near-term, I'm hopeful that some of the existing types have become, in practice, vestigial. For instance, GameBaseHiFiObject appears to only be reverenced within a block of code which is disabled by default.

#8 Does the VehicleBlockerObject actually serve any real useful purpose in Torque... other than some possible hack to prevent vehicles from entering Interiors or Forcefields etc leftover from Tribes?

#9 I wonder if switching mTypeMask from a single unsigned 32bit integer to a BitVector instead would be feasible?

You'd have to change all of the SimObjectTypes from being declared as BIT(x) to just being x, change the sets and tests to use BitVector's functions, and likely add a way to easily hand in a group/list of types to test but that is not insurmountable (likely could get most of it done in a day and add a day to handle backwards compatibility for legacy script functions). You might could even add an | operator overload for legacy code. It would nicely sidestep the 64bit issues.

You could also likely take a similar approach for the net mask flags (like where ShapeBase has used up nearly all of them).

#10 I agree with Matt Fairfax and is pretty much the same conclusion I came to last night about this problem. A BitVector instead of doing bitmask tests with a fixed integer size 32bit, 64bit, etc... This would allow pretty much no limit on the number of SimObjectTypes, just in case in the near future we break the 64 object types boundary if we go 64bit (U64) bitmasks.

Somebody might ask how we could ever need more than 64 object types, but then again Tribes 2 devs didn't think we would break the 32 object type limit either. :)

#11 IMO the quickest way to solve this problem would be to group the types.

There are bits that can never be set at the same time so allocating them all from the same range just wastes bit space. Instead, the bits should be grouped.

For example, by simply using the highest bit as a toggle, you immediately end up with 60 bits instead of 32. Just that bits from one group can never be set at the same time as the bits from the other group.

Most likely, we will need more than one group that can be set at the same time but even with 2-3 groups, we end up with more than 32 bits. Also, we can have certain bits that are shared across all type masks and certain bits that are grouped.

This solution has several benefits:

* We can stick to 32bits.
* No code changes other than modifying the masks in objectTypes.h necessary.
* We can reserve a group for user customization that we will never touch; no conflicts anymore.

//Edit:
One thing that might require changes in certain places is where bitmasks are combined. Combining certain masks with others can end up creating bad masks depending on the grouping.

//Edit:
BTW not saying the highest-bit toggle makes any sense in our case. Just serves to illustrate this stuff in principle.

#12 Use the Micro$oft solution - make a U32 mTypeMask2 and carry on! lol

#13

Quote:Use the Micro$oft solution - make a U32 mTypeMask2 and carry on! lol

Heh. Well, it's in fact another totally viable solution. It's just that these bits couldn't be used with container queries and such which would make them useful only for certain things.

#14 I think in the longer run, switching to 64 bit would be the ideal solution, even though it would be the harder route to take.

But it would be worth it.

#15 I just recently posted my idea on TDN: tdn.garagegames.com/wiki/T3D/DevTalk/Engine/SimObjectTypes.

Comments, suggestions, and flames are welcomed. I am right at this moment still making changes throughout my copy of T3D 1.1 preview code to hopefully eventually post a patch/diff file for all to see here.

@Matt Fairfax: Why aren't you on IRC? shame shame... ;)

#16 Well first and easiest solution is to get back the 4 bits we've lost since T3D 1.0.1. Often i find that these bits are not used wisely. If your not gonna use it for container queries... you don't need to add a bit at all. Do we know what bits were added?

We should also consider taking back some bits that are not very useful. Its better to use high level categories for type masks and filter those results. Yes its a bit less efficient as you don't skip the bounding volume tests on objects you don't need... but for the right types this a very minor thing. Like replacing the typemask for "Player", "Vehicle", and "Camera" with one for "ControlObject" would be more general.

Still Rene's proposed solution could be easier to deal with. Often your either looking for everything, static enviroment stuff, or gameplay objects.

#17 Recently added types: OccluderObjectType, ZoneObjectType, ConvexShapeObjectType, ForestObjectType.

#18 How about making some macros - STD_TYPEMASK_OR, EXT_TYPEMASK_OR, STD_TYPEMASK_AND, etc. ?

The macros look after the toggle bit.

Feed in your masks to be tested, get a mask back. One set of macros for the standards (up to 31) and a set for extended. Maybe a third set for custom (with two toggles instead of one)...

Results for each bunch can even be or'd together afterwards, if needed.

#19 Actually, the BitVector sounds cool, too. And the 64 bit option. And the bit grouping scheme, too.

Who gets to make that choice? We could have a poll. They're all good choices but each has different trade-offs. I'm a fan of performance gain even at the expense of a little complexity. So, to me, whatever runs fastest is best.... lol

#20 And while we're at it, let's not forget that network MaskBits are almost at their limit too.