Welcome, Guest. Please login or register. Did you miss your activation email?

Author Topic: Private Joystick Structures  (Read 134 times)

0 Members and 1 Guest are viewing this topic.

Reicha7

  • Newbie
  • *
  • Posts: 11
  • Game Programmer
    • View Profile
    • Personal Site
Private Joystick Structures
« on: April 17, 2025, 02:32:29 am »
Is there a specific reason why certain structures like the Joystick Manager, Joystick states etc. are private?

I'm working on my own Gamepad wrapper for Joysticks that will support DirectInput and XInput so needs to generically cache button states achieved in different manners. I see that Joystick class let's me request on a per-button basis but that call is then going through and getting the manager each time to retrieve a single value when if I could get the manager myself I could just directly iterate through its button states myself.

I'm building from source so I could just go and move JoystickManager to public (which does have a few knock-ons from what I've seen) but I was also curious as to why it was hidden away beyond just not wanting to risk it being used incorrectly?

kojack

  • Sr. Member
  • ****
  • Posts: 366
  • C++/C# game dev teacher.
    • View Profile
Re: Private Joystick Structures
« Reply #1 on: April 17, 2025, 10:21:48 am »
You can access the joystick manager without modifying any source, its not actually private, just in a namespace called priv.
For example I just did this and it works for my gamepad:
auto state = sf::priv::JoystickManager::getInstance().getState(0);
All buttons and axes are then in the state variable.

Although the manager's header and a bunch of dependent ones are located in the source directories rather than the header directories, so you may need to add some additional include paths when you build.

The most likely reason for the way its designed is to prevent excessive dependencies being pulled in. Including just joystick.hpp has little impact, it's header is pretty minimal. But including joystickmanager.hpp will also pull in dinput.h and mmsystem.h (when doing windows builds). If the end user doesn't need to use dinput and mmsystem themselves, then its best to not pull them into any cpp that wants joystick access.
This also means an sdk build has minimal headers needed, for example you don't need directinput headers available if you are just using a prebuilt sdk, because the joystickmanager is just internal to the sfml libs.
« Last Edit: April 17, 2025, 10:31:53 am by kojack »

Reicha7

  • Newbie
  • *
  • Posts: 11
  • Game Programmer
    • View Profile
    • Personal Site
Re: Private Joystick Structures
« Reply #2 on: April 18, 2025, 03:09:50 pm »
I see what you mean about the include paths. Ended up hitting a number of issues trying to include certain files.

Honestly I still believe that just moving a few things (the definition of Joystick State, the location of EnumArray.hpp) and adding some extra functions to Joystick.hpp will fit more in line with what I need without having to mess around trying to include a bulkier file like JoystickManager

kojack

  • Sr. Member
  • ****
  • Posts: 366
  • C++/C# game dev teacher.
    • View Profile
Re: Private Joystick Structures
« Reply #3 on: April 18, 2025, 07:59:09 pm »
I think the joystick system does need a bit of a refresh. It's still stuck in the ancient past of 32 button limits (DirectInput moved to 128 button limit in 1997).

I don't think the JoystickState class really needs to be obscured, it isn't implementation specific (all platforms share the same struct). It might be handy for user code to be able to grab the state via a function in the Joystick namespace, such as for recording snapshots of input state.

Reicha7

  • Newbie
  • *
  • Posts: 11
  • Game Programmer
    • View Profile
    • Personal Site
Re: Private Joystick Structures
« Reply #4 on: April 18, 2025, 09:27:18 pm »
Yeah that's basically all I ended up needing to do.

I made a fork of SFML with the changes for posterity: https://github.com/archieyates/arya-SFML/commit/507e7be415838a9f83204da612aac2d255b0ae19