Not logged inGosu Forums
Forum back to libgosu.org Help Search Register Login
Up Topic Gosu / Gosu Exchange / Additional Mouse Button Support
- - By RavensKrag Date 2011-12-29 22:04
Is there any plans to support "extra" mouse buttons in Gosu? I believe linux supports "n button" mice, and there are some crazy mice out there with a ridiculous number of buttons.  I have a mouse with two additional buttons which are not recognized by Gosu, but work fine with linux in general.  Is there any way to define values for these extra buttons, or at least have some sort of button code pass through Gosu from the OS to allow the usage of these buttons in conjunction with #button_down()?
Parent - - By jlnr (dev) Date 2011-12-30 04:54 Edited 2013-04-01 04:48
It should be super easy to add these buttons, but they'd change the indices of the Gosu::gp* constants. I wouldn't be opposed to it though.

Is there a standard maximum number of buttons to support? 4? 8?
Parent - - By RavensKrag Date 2011-12-30 05:19
Not quite sure how many buttons is "standard" for this sort of thing.  I have an extra 2 buttons on mine, for a total of 9 "buttons"  (counting the scroll wheel with side scrolling).  I feel like that's fairly "standard" in terms of mice with more than R/M/L click and scroll.

If you could guarantee that the values for the Gosu::gp* constants will come right after the mouse ones in the enum, it may be acceptable to just overflow the extra mouse buttons into the Gosu::gp* section.  By that I mean that the extra buttons would simply return the identifiers for gamepad buttons.  Don't really foresee many people using keyboard/mouse and a gamepad simultaneously.  Though I have tried playing Halo like that before... it was interesting.
Parent - - By Spooner Date 2011-12-31 20:50
I think keyboard/mouse vs gamepad might be popular for certain types of games played on a split screen. There shouldn't be an issue with all the constants being shoved up if more are needed, since they are all defined as constants anyway (If you are using the numbers directly, then something is wrong).
Parent - - By RavensKrag Date 2011-12-31 21:38
True, there's really no point to use the enum numbers directly.

You bring up a good point about split screen.  I hadn't considered the possibility of people wanting to play split screen on a computer, as I generally see that as a console feature.  Cobalt is the first game I can think of which is a PC game that has split-screen multiplayer.
Parent - By Spooner Date 2011-12-31 22:35
Plenty of games use shared-keyboard multi-player (I have written 3 of them :D) with or without an actual split screen. Trine 1+2 are immediate commercial games that I can think of doing this. I admit that Cobalt is one of the few that use mouse+keyboard type controls where you'd need to use that along with a controller rather than just being able to use opposite ends of the keyboard.
Parent - - By jlnr (dev) Date 2012-01-01 03:31 Edited 2012-01-01 03:55
Well, something is wrong with Gosu already then. There is no portable way to save players' keyboard configuration short of storing those magic numbers in a file right now. :( You could look them up based on constant names, especially in Ruby, but that doesn't help if the player binds actions to unnamed keys.

Using names with a fallback on numbers, and maybe even storing id_to_char along with it, would be the safest solution. I think Gosu should provide this, actually. It could also store the USB device identifier later if multiple gamepads are ever supported.
Parent - By Spooner Date 2012-01-01 12:44
I save the Chingu input names, which are symbols that reference the gosu constants, so that is fine. But yeah, you could do with something like that in Gosu itself.
Parent - - By RavensKrag Date 2012-01-02 15:50
How is it possible to bind actions to unnamed keys? At least on Linux, when I press a key for which there is no constant, I do not get any ID in #button_down().  Should the ability to bind unnamed keys even exist in Gosu?
Parent - - By jlnr (dev) Date 2012-01-08 08:02
Yes, sure. I think Gosu is even missing names for some really basic keys that I didn't know how to name, like [] (the öäü+# area on a German keyboard). If you do not get the ID, then this is a bug actually- feel free to file it. (It may be related to Gosu translating keys to characters too early on Linux.)
Parent - - By erisdiscord Date 2012-01-09 23:26
KbÖ appears to be a valid identifier in Ruby 1.9.3. C:
Parent - - By jlnr (dev) Date 2012-01-10 18:40
Maybe we can also find a safe character resembling '[' somewhere in Unicode :)
Parent - By erisdiscord Date 2012-01-10 23:21
Now you're just being silly. :D
Parent - By jlnr (dev) Date 2012-01-01 03:30 Edited 2012-01-01 03:52

> it may be acceptable to just overflow the extra mouse buttons into the Gosu::gp* section


This would mess with the internal code, I think :)

Do you want to prepare a patch for the whole story (or at least one OS)? Otherwise you should file a github bug.
Parent - - By jlnr (dev) Date 2013-04-01 09:00
Only a short year later *cough*, this has been fixed: https://github.com/jlnr/gosu/issues/112
Parent - - By RunnerPack Date 2013-04-02 00:26 Edited 2013-04-02 00:50
What's the syntax? The new documentation doesn't seem to list constants, and the rdoc in the gem doesn't seem to have been updated.

EDIT: Never mind; I found the hot-fix update thread...
Parent - By jlnr (dev) Date 2013-04-02 02:34
Ouch - thanks for pointing that out! I forgot to update the fake "gosu.rb that the reference is compiled from. It should really be generated automatically. :/
Parent - By jlnr (dev) Date 2013-04-02 02:52
I have just pushed the changes to the docs, should be synced up to http://libgosu.org/rdoc within the next 24 hours. (I forgot for when the job is scheduled :) )
Up Topic Gosu / Gosu Exchange / Additional Mouse Button Support

Powered by mwForum 2.29.7 © 1999-2015 Markus Wichitill