Announcement

Collapse
No announcement yet.

Background Processing of Joystick/Gamepad Input when not in focus

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

    [FEATURE REQUEST] Background Processing of Joystick/Gamepad Input when not in focus

    Hi,

    I'd like to be able to continue controlling the player even while the window is not in focus using a joystick or gamepad but this doesn't seem possible as it stands today. Is this something that we could please get added? I've been testing on Windows but I suspect that it is the same case on Linux and Mac as well.

    Any help on this would be very much appreciated.

    #2
    You always have your Input processing, probably you're confused with Input mode concept.
    You can pass your input data to UI only, Game Logic only or both if you want to.
    In PlayerController look at Set Input Mode Game/UI/Game&UI nodes
    SuperGrid: Marketplace Page | Feedback Thread | Demo | Website
    Level design and prototyping for newbies

    Comment


      #3
      Originally posted by zeOrb View Post
      You always have your Input processing, probably you're confused with Input mode concept.
      You can pass your input data to UI only, Game Logic only or both if you want to.
      In PlayerController look at Set Input Mode Game/UI/Game&UI nodes
      Do you mean that joystick input is still being captured even when the Unreal window is not in focus and that by setting the input mode I can capture that? My intention is to still allow user movement in the game world even when the user has alt+tab'ed to another non-Unreal window on his computer.

      Comment


        #4
        Originally posted by hesham View Post
        Do you mean that joystick input is still being captured even when the Unreal window is not in focus and that by setting the input mode I can capture that? My intention is to still allow user movement in the game world even when the user has alt+tab'ed to another non-Unreal window on his computer.
        You would need to modify the core files of UE4 that interact with the OS to always listen for input events to do this (if that is even possible), but I would not recommend doing so. Overriding default behavior of the OS will create more problems than it's worth. Potential security issues would be one reason as you could be opening a backdoor into the OS for hackers to exploit, and is generally something to avoid unless absolutely necessary.

        I'm curious why you want to add that behavior though, are you launching a separate program along with the game?
        Free Community Ocean & Sky Project || Join us on Discord! || Trello Roadmap

        Comment


          #5
          Originally posted by DotCam View Post
          You would need to modify the core files of UE4 that interact with the OS to always listen for input events to do this (if that is even possible), but I would not recommend doing so. Overriding default behavior of the OS will create more problems than it's worth. Potential security issues would be one reason as you could be opening a backdoor into the OS for hackers to exploit, and is generally something to avoid unless absolutely necessary.

          I'm curious why you want to add that behavior though, are you launching a separate program along with the game?
          This is 100% not true. By default, programs will continue to receive controller input even when they do not have focus (This is not the case for keyboard events). Unreal will be choosing to ignore this input somewhere in the engine code.

          You can easily confirm this by putting a breakpoint in the SendControllerEvents function that applies to you and then pushing a button. The engine will respond, but no input event is fired in the game.

          I found this thread while looking for the same thing as the OP. It's super frustrating to try to debug input based blueprints since you can't be looking at the blueprint when pressing the buttons/sticks. So if someone does know how to fix this (or if they can even just point me to the code where Unreal discards the input events), I would appreciate it.

          Comment


            #6
            Originally posted by hesham View Post
            Hi,

            I'd like to be able to continue controlling the player even while the window is not in focus using a joystick or gamepad but this doesn't seem possible as it stands today. Is this something that we could please get added? I've been testing on Windows but I suspect that it is the same case on Linux and Mac as well.

            Any help on this would be very much appreciated.
            As time has passed, it may not be necessary anymore ...

            When focus lost UGameViewportClient :: LostFocus() is called.
            At that time, APlayerController :: FlushPressedKeys () called and the inputs are erased.
            You can do this by overrideing this function so that it does not clear the key.

            Comment


              #7
              Could you please explain what steps I would need to take in order to overload the function?

              Comment


                #8
                Was looking for the same thing.

                Usually input is pumped from the Messages Queues. Input (especially keyboard input) will only be placed in the queue of the focused application.
                https://docs.microsoft.com/en-us/win...message-queues

                To retrieve events if the application is not focused, you can register hooks.
                https://docs.microsoft.com/en-us/win...ow%20procedure.
                Though the hooks I was able to register did not work for me when the application was in the background.

                Never the less I was looking for events from my XBox controller, and the hooks did not even catch those when the application was in the foreground.
                When you use the RawInput plugin, you can fix it by copying the plugin to your project and changing the code:

                RawInputWindows.cpp
                Code:
                FRawInputWindows::FRawInputWindows(const TSharedRef<FGenericApplicationMessageHandler>& InMessageHandler)
                : IRawInput(InMessageHandler)
                {
                ...
                   // Register a default device if desired
                   if (GetDefault<URawInputSettings>()->bRegisterDefaultDevice)
                   {
                      const uint32 Flags = RIDEV_INPUTSINK;//0;         // CHANGE HERE
                      const int32 PageID = 0x01;
                      int32 DeviceID = 0x04;
                      DefaultDeviceHandle = RegisterInputDevice(RIM_TYPEHID, Flags, DeviceID, PageID);
                ...
                }
                For the Flags, see here: https://docs.microsoft.com/en-us/win...rawinputdevice


                When running the Editor:
                The editor has performance throttels when in the background which can cause problems with the input even though the input should be queued by the system (?!?!).
                1: One severe when the editor is minimized: hard throtteling to 3FPS.
                To fix it you need to create a custom UUnrealEdEngine and register it in DefaultEngine.ini config file.
                Code:
                [/Script/Engine.Engine]
                UnrealEdEngine=/Script/MODULENAME.CLASSNAMEWITHOUTPREFIX
                Then in the custom UUnrealEdEngine override:
                Code:
                // We want the engine to always run full performance
                virtual bool ShouldThrottleCPUUsage() const override
                {
                   return false;
                }
                2: The second causes a 5ms sleep when in background and can only be fixed with a custom engine
                WindowsPlatformApplicationMisc.cpp
                Remove or change the code
                Code:
                FWindowsPlatformApplicationMisc::PumpMessages(bool bFromMainLoop)
                {
                  ...
                #if WITH_EDITOR
                   if( HadFocus && !HasFocus )
                   {
                       // Drop our priority to speed up whatever is in the foreground.
                      SetThreadPriority( GetCurrentThread(), THREAD_PRIORITY_BELOW_NORMAL );
                   }
                   else if( HasFocus && !HadFocus )
                   {
                      // Boost our priority back to above normal as initially set in WindowsRunnableThread::CreateInternal.
                     SetThreadPriority( GetCurrentThread(), THREAD_PRIORITY_ABOVE_NORMAL );
                   }
                   if( !HasFocus )
                   {
                       // Sleep for a bit to not eat up all CPU time.
                       FPlatformProcess::Sleep(0.005f);
                   }
                   HadFocus = HasFocus;
                
                #endif
                  ...
                }
                NodePrefabs | PluginBuilder | NotificationBackbone | WidgetBox | DebugWidget

                Comment


                  #9
                  Usually this doesn't work because of windows and custom drivers for the joypad.
                  The reason it could work with a 360 controller is the windows drivers for it. The same isn't necessarily true for an off-brand controller though, or a steam controller in my case.

                  either way, its mostly a limit imposed by the way the OS works rather than the engine itself.

                  In other words, this should probably be a request for the M$ team rather than the epic team.


                  Comment

                  Working...
                  X