Game Development Community

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:

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?

#1
08/10/2005 (12:55 pm)
I vote bug.


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.
#2
10/25/2006 (11:50 am)
Bump

This is still in 1.5 as well. Can we get an official bug/no bug?
#3
10/25/2006 (12:00 pm)
I also vote bug. looks to me like it should be
enum 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
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.