Esempio n. 1
0
    // So the other part we need is to actually feed input for the device. Notice
    // that we already have the IInputUpdateCallbackReceiver interface on our class.
    // What this does is to add an OnUpdate method that will automatically be called
    // by the input system whenever it updates (actually, it will be called *before*
    // it updates, i.e. from the same point that InputSystem.onBeforeUpdate triggers).
    //
    // Here, we can feed input to our devices.
    //
    // NOTE: We don't have to do this here. InputSystem.QueueEvent can be called from
    //       anywhere, including from threads. So if, for example, you have a background
    //       thread polling input from your device, that's where you can also queue
    //       its input events.
    //
    // Again, we don't have actual input to read here. So we just make up some stuff
    // here for the sake of demonstration. We just poll the keyboard
    //
    // NOTE: We poll the keyboard here as part of our OnUpdate. Remember, however,
    //       that we run our OnUpdate from onBeforeUpdate, i.e. from where keyboard
    //       input has not yet been processed. This means that our input will always
    //       be one frame late. Plus, because we are polling the keyboard state here
    //       on a frame-to-frame basis, we may miss inputs on the keyboard.
    //
    // NOTE: One thing we could instead is to actually use OnScreenControls that
    //       represent the controls of our device and then use that to generate
    //       input from actual human interaction.
    public void OnUpdate()
    {
        var keyboard = Keyboard.current;

        if (keyboard == null)
        {
            return;
        }

        var state = new CustomDeviceState();

        state.x = 127;
        state.y = 127;

        // WARNING: It may be tempting to simply store some state related to updates
        //          directly on the device. For example, let's say we want scale the
        //          vector from WASD to a certain length which can be adjusted with
        //          the scroll wheel of the mouse. It seems natural to just store the
        //          current strength as a private field on CustomDevice.
        //
        //          This will *NOT* work correctly. *All* input state must be stored
        //          under the domain of the input system. InputDevices themselves
        //          cannot private store their own separate state.
        //
        //          What you *can* do however, is simply add fields your state struct
        //          (CustomDeviceState in our case) that contain the state you want
        //          to keep. It is not necessary to expose these as InputControls if
        //          you don't want to.

        // Map WASD to stick.
        var wPressed = keyboard.wKey.isPressed;
        var aPressed = keyboard.aKey.isPressed;
        var sPressed = keyboard.sKey.isPressed;
        var dPressed = keyboard.dKey.isPressed;

        if (aPressed)
        {
            state.x -= 127;
        }
        if (dPressed)
        {
            state.x += 127;
        }
        if (wPressed)
        {
            state.y += 127;
        }
        if (sPressed)
        {
            state.y -= 127;
        }

        // Map buttons to 1, 2, and 3.
        if (keyboard.digit1Key.isPressed)
        {
            state.buttons |= 1 << 0;
        }
        if (keyboard.digit2Key.isPressed)
        {
            state.buttons |= 1 << 1;
        }
        if (keyboard.digit3Key.isPressed)
        {
            state.buttons |= 1 << 2;
        }

        // Finally, queue the event.
        // NOTE: We are replacing the current device state wholesale here. An alternative
        //       would be to use QueueDeltaStateEvent to replace only select memory contents.
        InputSystem.QueueStateEvent(this, state);
    }
    // Invoked when a line of data is received from the serial device.
    public void OnMessageArrived(string msg)
    {
        Debug.Log("Message arrived: " + msg);

        // this works with CustomDevice.cs it actually feeds input for the device. Notice
        // that we already have the IInputUpdateCallbackReceiver interface on CustomDevice class.
        // What this does is to add an OnMessageArrived method that will automatically be called
        // by the input system whenever it updates!
        // Here >> feed input to our devices.
        //
        // NOTE: InputSystem.QueueEvent can be called from anywhere, including from threads.
        //       So in this case, we have a background thread polling input from your device,
        //       that's where we can also queue its input events.
        //
        // The original script read input on CustomDevice class. It made up some stuff
        // there for the sake of demonstration. Additionally, It polled the keyboard...
        //
        // NOTE: The keyboard there was part of OnUpdate. however,
        //       they run OnUpdate from onBeforeUpdate, i.e. from where keyboard
        //       input has not yet been processed. This means that our input will always
        //       be one frame late. Plus, because we are polling the keyboard state here
        //       on a frame-to-frame basis, we may miss inputs on the keyboard.
        //
        // NOTE: One thing we could instead is to actually use OnScreenControls that
        //       represent the controls of our device and then use that to generate
        //       input from actual human interaction.

        var state = new CustomDeviceState();

        state.x = 127;
        state.y = 127;

        // WARNING: It may be tempting to simply store some state related to updates
        //          directly on the device. For example, let's say we want scale the
        //          vector from WASD to a certain length which can be adjusted with
        //          the scroll wheel of the mouse. It seems natural to just store the
        //          current strength as a private field on CustomDevice.
        //
        //          This will *NOT* work correctly. *All* input state must be stored
        //          under the domain of the input system. InputDevices themselves
        //          cannot private store their own separate state.
        //
        //          What you *can* do however, is simply add fields your state struct
        //          (CustomDeviceState in our case) that contain the state you want
        //          to keep. It is not necessary to expose these as InputControls if
        //          you don't want to.

        // Map buttons to 1, 2, and 3.
        if (msg == "0")
        {
            state.buttons |= 1; // |= will only ever add bits to the target
        }
        //string msg1 = msgSplit[1];
        // Map the stick.
        if (msg == "right")
        {
            state.x -= 127;
        }
        if (msg == "left")
        {
            state.x += 127;
        }
        if (msg == "up")
        {
            state.y += 127;
        }
        if (msg == "down")
        {
            state.y -= 127;
        }

        // Finally, queue the event.
        // NOTE: We are replacing the current device state wholesale here. An alternative
        //       would be to use QueueDeltaStateEvent to replace only select memory contents.
        InputSystem.QueueStateEvent(CustomDevice.current, state);
    }