Simple message question

Jan 24, 2008 at 1:27 AM
Why are we passing the gametime into our message? Would it be possible to simply have the message handling system stamp the message with time when it recieves it (which is instantly)? Or does this have to do with timing of messages over networks?
Jan 24, 2008 at 1:43 AM
Edited Jan 24, 2008 at 1:44 AM
It's probably just for reference.

Word of caution here: GameTime is not valid across Update calls, at least not how you might think. GameTime is a class, not a struct. The instance is held by Game and just passed to Update after updating the appropriate fields. What this means is that if you save a reference to Update's GameTime, and use it during the next update cycle, you're using the current update cycle's GameTime, not the last update cycle's GameTime.

    private GameTime gameTime;
    public override void Update(GameTime gameTime)
        // Right here, this.gameTime == gameTime, not the last frame's GameTime (after the first update cycle)
        this.gameTime = gameTime;
Jan 24, 2008 at 1:59 AM
If that is the case, then gametime is being used improperly in my opinion. For example it is passed during a keyboard key press, and then the next frame or whenever it is handled by the FreeCamera, the camera is using the gametime passed to it from the key press message. This seems like a waste.

Also, a small comment. I added the gamepadhandler class to the configuration.xml, but I was originally getting a break when I ran the program. On Line 177 of ConfigurationManager.cs you will see this snippet of code:
InputHandler handler = Activator.CreateInstance(type, new object[] { game }) as InputHandler;
if (handler == null)
     throw new Exception(string.Format("input handler type '{0}' was not found", typeName));
I actually broke on the first line of that code, and the exception says that the value cannot be null. So we never get a chance to run the if statement if the value is null. I think we may need a try/catch in this case.

The issue was my class didn't have a capital letter in the name, but the XML file did.

I'm about 80% done with the input handler, and have verified it works as intended. It is just very tedious having to do each button, direction on d-pad, trigger, joystick, all in their of IF statement. Unline keyboard where you can load all keys into a single array, the gamepad handling for XNA doesn't have that feature, and unlike the keyboard which has 1 type of input (keys), and mice (which have two, buttons and movement), the gamepad has buttons, thumbsticks for movement, and triggers with values. Not difficult, just tedious.

Jan 24, 2008 at 2:41 AM
I thought they added an easier way to get at the bulk gamepad input in 2.0, but I could be wrong.

Regarding that exception, you're a little off. The exception isn't because its returning a null value, it's because the type parameter is null. In other words, then you convert the class name string to a Type, you're getting a null Type back and feeding it into Activator.CreateInstance. We need to check if type is null before that statement.

Sturm, is there any way to get rid of the Activator.CreateInstance(type, constructor parameters) call? I know it's a long shot, but CreateInstance(type, constructor parameters) doesn't exist on Xbox. Only CreateInstance(type) does. It may require a rework of the BaseManager interface, providing an Initialize that takes a QSGame parameter and leaves the constructor parameter-less.
Jan 24, 2008 at 2:46 AM
Create an issue for it and I'll rework that asap, We can simply move it to an internal method which is invoked right after instantiating. Also if you have the time can you create an issue for the exception when the type wasn't found, a application should never raise a ArgumentNullException.
Jan 24, 2008 at 3:37 AM
Two issues created.

The I assigned the NullArgumentException issue to 0.19, and the CreateInstance rework for 0.20. It's not really a big deal for 0.19 since their is no Xbox support without a managed physics solution.

I don't think the new Initialize method can be internal. The PhysicsManager implementations will be in external assemblies and need to implement them as well. Unless it's going to be a non-virtual method of BaseManager. I'm not sure that's a good idea though.