• Hey Guest! Ever feel like entering a Game Jam, but the time limit is always too much pressure? We get it... You lead a hectic life and dedicating 3 whole days to make a game just doesn't work for you! So, why not enter the GMC SLOW JAM? Take your time! Kick back and make your game over 4 months! Interested? Then just click here!

Legacy GM Gamepad support and multiple input types

S

Snayff

Guest
@Fel666 Evening buddy, do you foresee any issues with this in GM2? Will it still work as intended?
 
S

Snayff

Guest
Thanks for letting me know! I'll give it a go and see what happens.
 
S

Snayff

Guest
I recently tried using some other controllers (playstation, non-branded third party) and they weren't picked up. Have I missed something or is there something else that needs to be added in?
 
GMWolf

GMWolf

aka fel666
Snayff said:
I recently tried using some other controllers (playstation, non-branded third party) and they weren't picked up. Have I missed something or is there something else that needs to be added in?
Click to expand...
As long as windows can pick them up as xinput controllers, It should work fine IN GM> (I think playstation controllers should be working).
I know there are some motherboards that have issues picking up playstation controllers, and may need to have their bios updated.
 
S

Snayff

Guest
Thanks for coming back to me, Fel.

The pc picked up the controllers, as did other games, but it didnt work with mine. If it should work then I must have done something wrong so I will rewatch your video and see if anything jumps out.
 
Last edited by a moderator:
GMWolf

GMWolf

aka fel666
hogwater said:
I skimmed through the video; your controllers don't work because he/she is only checking slot 0, which covers XInput controllers. Playstation and other random controllers will be DirectInput, and appear in "slots" 4+.

See this post of mine for how to easily support most controllers- https://forum.yoyogames.com/index.php?threads/gamepad-slot-behavior.36110/#post-222516
Click to expand...
Good spot.

I really should have used the device events to detect the controller in this tutorial.
I may have to revisit this again.
 
FrostyCat

FrostyCat

Redemption Seeker
I don't think anyone should look at this just as a mechanism for supporting gamepads. It is much more.

"Input objects" don't always have to relate back to current local input. They can be exploited to accept other input for different tasks:
  • By recording the sequence of input values and playing it back, this is replay in a nutshell. This gets the "rocket science" treatment around here.
  • By listening for packets instead of local input, this is multiplayer in a nutshell. This too gets the "rocket science" treatment around here.
  • By recording the sequence of input values and then playing it back at 9999 FPS (drawing disabled, fixed random seed), you can quickly replicate game interactions with 100% reflex independence. This testing technique is unheard of around here.
  • By getting an algorithm to set the input values, this is AI in a nutshell. This removes the need to duplicate objects for agents that both players and AI could control.
Simply uncoupling your input from playable agents will open these doors. This has the potential to be a new GM best practice in the making.

Sadly, we still have no shortage of novices who would dismiss this as being too abstract to be useful, then continue to bet their lives on Spalding and HeartBeast. This will be a weapon reserved for the deserving few who spend time critically thinking about their tools.
 
R

Roa

Member
FrostyCat said:
I don't think anyone should look at this just as a mechanism for supporting gamepads. It is much more.

"Input objects" don't always have to relate back to current local input. They can be exploited to accept other input for different tasks:
  • By recording the sequence of input values and playing it back, this is replay in a nutshell. This gets the "rocket science" treatment around here.
  • By listening for packets instead of local input, this is multiplayer in a nutshell. This too gets the "rocket science" treatment around here.
  • By recording the sequence of input values and then playing it back at 9999 FPS (drawing disabled, fixed random seed), you can quickly replicate game interactions with 100% reflex independence. This testing technique is unheard of around here.
  • By getting an algorithm to set the input values, this is AI in a nutshell. This removes the need to duplicate objects for agents that both players and AI could control.
Simply uncoupling your input from playable agents will open these doors. This has the potential to be a new GM best practice in the making.

Sadly, we still have no shortage of novices who would dismiss this as being too abstract to be useful, then continue to bet their lives on Spalding and HeartBeast. This will be a weapon reserved for the deserving few who spend time critically thinking about their tools.
Click to expand...
interesting time to name drop, but 100% agree in every facet. Ive personally used the first 2 and 4rth in tandem to sort of make my own Halo franchise style video archive mode
 
GMWolf

GMWolf

aka fel666
FrostyCat said:
I don't think anyone should look at this just as a mechanism for supporting gamepads. It is much more.

"Input objects" don't always have to relate back to current local input. They can be exploited to accept other input for different tasks:
  • By recording the sequence of input values and playing it back, this is replay in a nutshell. This gets the "rocket science" treatment around here.
  • By listening for packets instead of local input, this is multiplayer in a nutshell. This too gets the "rocket science" treatment around here.
  • By recording the sequence of input values and then playing it back at 9999 FPS (drawing disabled, fixed random seed), you can quickly replicate game interactions with 100% reflex independence. This testing technique is unheard of around here.
  • By getting an algorithm to set the input values, this is AI in a nutshell. This removes the need to duplicate objects for agents that both players and AI could control.
Simply uncoupling your input from playable agents will open these doors. This has the potential to be a new GM best practice in the making.

Sadly, we still have no shortage of novices who would dismiss this as being too abstract to be useful, then continue to bet their lives on Spalding and HeartBeast. This will be a weapon reserved for the deserving few who spend time critically thinking about their tools.
Click to expand...
Actually, this is very true.
It is the point I wanted to get across at first. But I knew I had to find a way to get views, so I kinda disguised it as a controller tutorial.
I think I forgot that along the way. But @FrostyCat Is correct: the decoupling technique is quite powerful, and given the poor job I did of covering the controller setup, it is probably what you take away from this video.
 
kburkhart84

kburkhart84

Firehammer Games
This is actually why I did my FHInput extension the way I did it. It supports custom inputs that the player can easily choose at gametime(like many games). It doesn't care which input device it is(whether it is keyboard, mouse, or gamepad slots 0-11). And, it has the concept of a "player." A player is just a copy of the actions your game has(actions are move left, jump, shoot, etc...). You can have as many players as you need at any given time. And the players can be set to "manual" input instead. This way, instead of polling devices for inputs, it lets the code do it. The code can then make decisions however it wants, AI, whatever, and the agent that is using the actions/player system doesn't have to know or care if the input is coming from devices or from an AI, and the code the agent uses can be all the same.
 
You must log in or register to reply here.
Top