PathCamera MaskBits bug?
by James Spellman · in Torque Game Engine · 08/10/2005 (11:18 am) · 4 replies
I can't tell if someone is being clever or that we've been living with a horrible bug for some time:
Just what is this doing? Is it supposed to be:
or was it supposed to be:
like how masks are used everywhere else?
enum MaskBits {
WindowMask = Parent::NextFreeMask,
PositionMask = Parent::NextFreeMask + 1,
TargetMask = Parent::NextFreeMask + 2,
StateMask = Parent::NextFreeMask + 3,
NextFreeMask = Parent::NextFreeMask << 1
};Just what is this doing? Is it supposed to be:
PositionMask = (WindowMask + SceneObject::ScaleMask), TargetMask = (WindowMask + GameBase::InitialUpdateMask)
or was it supposed to be:
PositionMask = Parent::NextFreeMask << 1, TargetMask = Parent::NextFreeMask << 2,
like how masks are used everywhere else?
#3
nice catch.
the original code can't possibly be right.
for example, with the values Kirk provided,
if you set StateMask (0x02000003) then you have also set PositionMask (0x02000001).
- which seems very, very unlikely to be the intended result.
and now consider if Parent::NextFreeMask were 0x02000001 instead of 0x0200000:
then StateMask would be 0x0200004 and PositionMask would be 0x02000002,
and setting StateMask would no longer also set PositionMask.
.. that is, the behaviour of setting the masks will change if an additional mask is added upstream in the class heirarchy, which can't possibly be right.
10/25/2006 (12:00 pm)
I also vote bug. looks to me like it should beenum MaskBits {
WindowMask = Parent::NextFreeMask,
PositionMask = Parent::NextFreeMask << 1,
TargetMask = Parent::NextFreeMask << 2,
StateMask = Parent::NextFreeMask << 3,
NextFreeMask = Parent::NextFreeMask << 4
};nice catch.
the original code can't possibly be right.
for example, with the values Kirk provided,
if you set StateMask (0x02000003) then you have also set PositionMask (0x02000001).
- which seems very, very unlikely to be the intended result.
and now consider if Parent::NextFreeMask were 0x02000001 instead of 0x0200000:
then StateMask would be 0x0200004 and PositionMask would be 0x02000002,
and setting StateMask would no longer also set PositionMask.
.. that is, the behaviour of setting the masks will change if an additional mask is added upstream in the class heirarchy, which can't possibly be right.
#4
It would be nice if GG actually responded to these bug reports, it's rather ruded to just ignore us like this.
If someone can verify the master server problem I reported it would also be nice.
10/25/2006 (2:25 pm)
It looks like a bug to me too. Orion's layout looks correct. If you add 1 or any value to a mask then you are treating it as a number not a mask. The result will be a number which has no relation to the flags it's intended to represent.It would be nice if GG actually responded to these bug reports, it's rather ruded to just ignore us like this.
If someone can verify the master server problem I reported it would also be nice.
Torque Owner Kirk Haynes
That said, here's some generic background on masks for reference.
Masks have their basis in NetObject for the member U32 mDirtyMaskBits;
SceneObject subclasses NetObject and adds the following masks
enum SceneObjectMasks { ScaleMask = 1 << 0, // 0x00000001 NextFreeMask = ScaleMask << 1 // 0x00000002 };GameBase subclasses SceneObject and adds the following masks
enum GameBaseMasks { InitialUpdateMask = Parent::NextFreeMask, // 0x00000002 DataBlockMask = InitialUpdateMask << 1, // 0x00000004 ExtendedInfoMask = DataBlockMask << 1, // 0x00000008 ControlMask = ExtendedInfoMask << 1, // 0x00000010 NextFreeMask = ControlMask << 1 // 0x00000020 };ShapeBase subclasses GameBase and adds the following masks in it's default implementation
with MaxSoundThreads, MaxScriptThreads, and MaxMountedImages equal to 4
enum ShapeBaseMasks { NameMask = Parent::NextFreeMask, // 0x00000020 DamageMask = Parent::NextFreeMask << 1, // 0x00000040 NoWarpMask = Parent::NextFreeMask << 2, // 0x00000080 MountedMask = Parent::NextFreeMask << 3, // 0x00000100 CloakMask = Parent::NextFreeMask << 4, // 0x00000200 ShieldMask = Parent::NextFreeMask << 5, // 0x00000400 InvincibleMask = Parent::NextFreeMask << 6, // 0x00000800 SkinMask = Parent::NextFreeMask << 7, // 0x00001000 SoundMaskN = Parent::NextFreeMask << 8, // 0x00002000 ThreadMaskN = SoundMaskN << MaxSoundThreads, // 0x00020000 ImageMaskN = ThreadMaskN << MaxScriptThreads, // 0x00200000 NextFreeMask = ImageMaskN << MaxMountedImages // 0x02000000 };PathCamera subclasses ShapeBase and adds the following masks
enum MaskBits { WindowMask = Parent::NextFreeMask, // 0x02000000 PositionMask = Parent::NextFreeMask + 1, // 0x02000001 TargetMask = Parent::NextFreeMask + 2, // 0x02000002 StateMask = Parent::NextFreeMask + 3, // 0x02000003 NextFreeMask = Parent::NextFreeMask << 1 // 0x04000000 };PathCamera::MaskBits::PositionMask overlaps PathCamera::MaskBits::WindowMask and SceneObject::SceneObjectMasks::ScaleMask
PathCamera::MaskBits::TargetMask overlaps PathCamera::MaskBits::WindowMask and GameBase::GameBaseMasks::InitialUpdateMask
PathCamera::MaskBits::StateMask overlaps PathCamera::MaskBits::WindowMask, SceneObject::SceneObjectMasks::ScaleMask and GameBase::GameBaseMasks::InitialUpdateMask
Some interesting notes:
PathCamera::packUpdate calls Parent::packUpdate(con,mask,stream); so any base class bits will be sent by the parents
GameBase::packUpdate implements sending the scale when the ScaleMask bit is set
SceneObject doesn't implement a packUpdate method however SceneObject does implement a callback for subclasses to manage scale changes.