[PLUGIN] Joystick / Game controller support! v1.2.0

Started by Wyz, Fri 20/08/2010 19:43:43

Previous topic - Next topic

DoorKnobHandle

This is awesome, planning on using this in a couple of projects! Is there any way you can get force feedback functionality in there?

Wyz

Thanks!
Well force feedback is a story apart, it is capable of doing a great number of effects and has a quite large interface. It will be better off in a separate plugin; I like the plugin to be clean and simple. Maybe if more people are interested I'll make a plugin for it in the future. :)
Life is like an adventure without the pixel hunts.

DoorKnobHandle

Are you planning on making this plugin open source? Because I don't think it makes too much sense to have two separate plugins, on for the controller support and the other for force-feedback. I have no experience with this (but with Direct3D and DirectInput I do have some) and I would give it a try. I won't have the time to write my own gamepad plugin from ground up though. Of course, I don't wanna force you to release your source code. :D

subspark

#43
Take a look at this, Wyz:
http://blogs.msdn.com/b/pstubbs/archive/2006/02/13/531008.aspx

Lighting up the LEDs on the Xbox360 controller seems possible.

Agreed with dkh. Force feedback is essential.

Cheers,
Spakry.

Wyz

I'm not that interested in lighting up leds on a specific game controller. ;)
There is more to haptic feedback then simply letting the motors roll. If I want to implement such thing, then I want the developer to have full access to it's capabilities. I wouldn't call it essential if you are still able to play a game without it.

I'm not ready to release the source at this time, I already had in mind to release the framework so it can be ported to different platforms in the future. I don't want to be a jerk and shut my ears for suggestions by other people, it is more an advice since I did read into this material when I was plotting the plugin. I also see that other wrapper libraries separate the haptic feedback from the actual input module, it seems a natural thing to do. There is just a lot more to haptic feedback then people think. (site I stumbled on)

But hey if you're willing to give it a shot anyway, I can always try to make the plugin work together with it and help with it.
Life is like an adventure without the pixel hunts.

subspark

QuoteIf I want to implement such thing, then I want the developer to have full access to it's capabilities
Well that was the intention. Dkh and I are working on a Street Fighter'esque arcade fighter and would really love to work with you to help develop and improve haptic feedback under one kick-ass plugin.

I can understand the light thing for now but ultimately, exploring the led switches is an interesting notion to us and might be something to explore further into the future.
For now, I really want to home in on great controller support for optimal gameplay feel, which is something your plugin is starting to give us even now! 8)

Hope we can help you develop it further for the community.

Cheers,
Sparky.

Shane 'ProgZmax' Stevens

#46
I like this so far but my main issue with this plugin is the sheer amount of damage control you need to employ to be able to even use the gamepad.  Example:

If you are allowing gamepad and/or keyboard control, instead of just having something like if(IsKeyPressed(eKeyA) || joy.IsButtonDown(0)) you literally have to split it off into two functions, the joypad one doing this first:

Code: ags

if(joy!=null)
{


}





Otherwise any bit of code 'potentially' looking for button presses or joystick states crashes the game on run should the person not have a gamepad, period.  This shouldn't happen.  If there is no joystick plugged in, the IsButton/POV/etc calls should self-manage the null state internally and simply do nothing so you don't need to micromanage every call in this way, it's simply not reasonable the way it is now.   Also, I don't think it's really necessary to separate the POV hat into a separate call; IsButtonDown could just as easily handle it.

Also, support for connecting up gamepads AFTER the game has started would be good.  I tried making a function to do this with the opendefaultjoystick but once the game begins it seems to no longer be able to poll the device to see if it has been plugged in.

Hopefully a future version will address this since I was in the middle of implementing gamepad support but this development has made me strip it out again.

abstauber

#47
I'm using some kind of wrapper to avoid too much error checking

Code: ags

function isControlDown() {
  if (IsKeyPressed(eKeyDownArrow)) return true;
  if (joy!=null && joy.Valid() && joy.> 10) return true;
}


Once you have all those functions done, you never have to look back again :)


Wyz

Quote from: subspark on Thu 14/10/2010 13:48:02
Well that was the intention. Dkh and I are working on a Street Fighter'esque arcade fighter and would really love to work with you to help develop and improve haptic feedback under one kick-ass plugin.
(...)
Hope we can help you develop it further for the community.

Sounds great! What I think I do is branch off the current plugin to a version that supports haptic feedback or whatever you want to put in there ;D
When you have something I'll add it to the interface and static link it to the DLL and put it up for the crowds (if that's fine by you). There are some issues because I'm using the native windows API, and it does not support force feedback, so I need to find a way to hook it up to direct input or Xinput.

Quote from: ProgZmax on Sat 16/10/2010 01:00:22
(...)
Hopefully a future version will address this since I was in the middle of implementing gamepad support but this development has made me strip it out again.

You should have let me know that sooner man, I could easily have done something about that.
Well the first issue can be resolved using a wrapper function like abstauber shows. You can even use the function to put in button mapping.
Though I could make a dummy joystick that can always be opened if that helps...

POVs are essentially different from buttons since they have no up and down state. A POV control either points to a certain direction or is centered. Sure you can pretend each direction is a button, and if you like to do it you can make an extender function that does it. But this way you can write shortcuts like (POV & ePOVDown) which is nice.

Well the plugin will detect all installed joysticks (either plugged in or not). I see that that would pose a problem with USB devices that install itself automatically when plugged in. There is no way for the plugin to know when this happens. I could make a function that would flush the entire plugin, but it would leave all pointers dangling, not a very elegant solution.
Life is like an adventure without the pixel hunts.

subspark

#49
Agree with you guys on all points. I too, would like to see nicer internal handling of joypad mechanics.

I also thought that we could run code when a USB controller was plugged in during runtime.
I even made a series of fading icons for it. Now if only we can get them to work properly! :)

Edit: Great to see you online at exactly the same time as I am, Wyz. Dkh and I will have to chat first about all this then come back to you with a definitive answer.

Cheers,
Sparky.

Shane 'ProgZmax' Stevens

#50
I'd definitely like to see it provide a dummy joypad if one isn't connected so I don't need another wrapper function.

Also, it would be nice if the gamepad buttons could have the option to simulate a mouse click as there are so many things in ags that react purely to ORIGINAL MOUSE CLICKS (like guis and dialogs, which do not respond to processclick for some arbitrary reason).  Support for this would make it possible to have a fully gamepad driven adventure game which as of this moment is not possible for the aforementioned reason (I realize you can get around standard gui clicks with GetGUIControlAt but it's extremely messy and does NOT work for dialog clicks).  Indeed, similar support for keypresses would be welcome also!

Thanks for the reply!

Wyz

I'm working on a version that addresses some of your problems. I'll test it some more tomorrow and release it.
Life is like an adventure without the pixel hunts.

subspark

Sounds fantastic Wyz. I can't wait to pump it into our fighting engine!

Cheers,
Sparky.

Wyz



Update!



V1.2.0
- dummy joystick device added (#id is -1)
- Click(...) static method added
- IsOpen(id) static method added
- JoystickRescan() function added (returns true when new devices were found)
- minor optimizations

Also changed the tutorial a bit to include the new functionality.
Life is like an adventure without the pixel hunts.

abstauber

Super-Wyz  strikes again  :=


Just in any case you feel like leaving that project please make sure that you find a successor for this wonderful plugin.

....if just scorporius would have done that with his rain plugin.

Shane 'ProgZmax' Stevens

Hooray!  Now if only we could make Display respond to a button press then that would be everything!

Wyz

Quote from: abstauber on Mon 18/10/2010 15:13:15
Super-Wyz  strikes again  :=


Just in any case you feel like leaving that project please make sure that you find a successor for this wonderful plugin.

....if just scorporius would have done that with his rain plugin.

Don't worry, unless I get hit by a truck the plugin does not die with me.  ;D
When I've got the feeling I've done all I wanted to do with it I'll either release it to the public or put it in the capable hand of someone else.

Quote from: ProgZmax on Tue 19/10/2010 07:05:50
Hooray!  Now if only we could make Display respond to a button press then that would be everything!

Yes, if someone has any brilliant ideas how to interrupt Display messages please let me know. At this point I don't even know if it is possible to do with the plugin API. For the time being you can use the workaround defined in the tutorial (Room 9).
Life is like an adventure without the pixel hunts.

Shane 'ProgZmax' Stevens

Well, using SetSkipSpeech(0) as abstauber suggested will allow mouse buttons to skip Display, but not with joy.Click().  My guess is because Display actually full-on pauses the game aside from checking for user input so none of the player made calls go through.

subspark

EDIT: You know it should be possible to invent our own display system that could respond to input and that doesn't actually pause the game in such a brute force manner.

Yeah 'Display' is one of those old-world leftovers from last decade thats still actually quite useful but, until recently, not in a way that has proved to be a potentially disruptive system to manipluate.
If a workaround isn't discovered, CJ, could we get some kind of plugin input access to toggle display messages off? :)

Damn fine work, Wyz!

Sparky.

Wyz

Thanks!
Well just for convenience let my post the work around here:

Code: ags

// this function will wait for any button input, similar to the WaitMouseKey(...) function
function WaitMouseKeyJoy(int time, Joystick *j)
{
  int buttons = j.buttons;
  
  while (time)
  {
    if ((j.buttons ^ buttons) & j.buttons)
      return (1);
    else
      buttons = j.buttons;
    
    if (WaitMouseKey(1))
      return (1);
    
    if (time > 0)
      time--;
  }
  
  return (0);
}

// Assumes you have a global open joystick instance called: joy
function JDisplay(String message)
{
  int sw = (System.ScreenWidth/4) * 3;
  int w = GetTextWidth(message, eFontFont0) + 14;
  if (w > sw) w = sw;
  int h = GetTextHeight(message, eFontFont0, w) + 7;
  
  DynamicSprite *sprite = DynamicSprite.Create(w+6, h+6, false);
  
  DrawingSurface *s = sprite.GetDrawingSurface();
  s.Clear(16);
  s.DrawingColor = 15;
  s.DrawRectangle(1, 1, w+4, h+4);
  s.DrawingColor = 16;
  s.DrawStringWrapped(3, 3, w, eFontFont0, eAlignLeft, message);
  s.Release();
  
  w = (System.ScreenWidth - w) / 2;
  h = (System.ScreenHeight - h) / 2;
  Overlay *overlay = Overlay.CreateGraphical(w, h, sprite.Graphic, false);
  
  WaitMouseKeyJoy(-1, joy);
  
  overlay.Remove();
  sprite.Delete();
}


Ps.
I'm also eager to see that fighting game. I'm actually also working on one since long, but still too early to disclose any information. ;)
Life is like an adventure without the pixel hunts.

SMF spam blocked by CleanTalk