Is there currently any way to get controller working without requiring the user to map anything?
If it can't be done or would be more difficult than worthwhile, I've got no problem with that but I would need to know if it's something that can be done in general, as a game like Lux will benefit massively from controller support. Heck, even developing would be easier if I could just kick back and grab a controller when I test code.
I would love to have this! The number of buttons on a regular controller is enough for most projects I'd make.
| |
Gamepad support is on my idea list for 511.
| |
Lummox JR wrote:
Gamepad support is on my idea list for 511. If you need any specific help debugging or testing this then let me know. If you don't already have an Xbox 360 USB Controller then I'd also be happy to send one your way via Amazon. Aside from being the most ubiquitous PC gamepad, it's also probably the best controller to use as a baseline for features and compatibility. | |
I have a fairly nice Logitech controller that's pretty close to a PlayStation controller in design; it has a D-pad, four face buttons, top and bottom shoulder buttons on each side, and two thumb sticks with button action. Haven't used in a while, because if I'd try to play games in DosBox while my wife was asleep she heard the tiniest noises from the controller loud and clear--which is really bizarre.
| |
Lummox JR wrote:
I have a fairly nice Logitech controller that's pretty close to a PlayStation controller in design; it has a D-pad, four face buttons, top and bottom shoulder buttons on each side, and two thumb sticks with button action. Haven't used in a while, because if I'd try to play games in DosBox while my wife was asleep she heard the tiniest noises from the controller loud and clear--which is really bizarre. To be honest, game controllers are deceiving in their appearance, and many of them operate very differently under the hood. I have to agree with SilkWizard, 360 controller is probably your best baseline as all windows 7+ computers support it (and I believe Windows XP as well, not 100% on that though). | |
Right on, sounds like that controller will cover everything!
Lummox JR wrote: Haven't used in a while, because if I'd try to play games in DosBox while my wife was asleep she heard the tiniest noises from the controller loud and clear--which is really bizarre. Strange, though in my experience the really tiny noises often do begin to gnaw at my sanity long before any other disturbances. | |
Bravo1 wrote:
To be honest, game controllers are deceiving in their appearance, and many of them operate very differently under the hood. I agree as far as most pc gamepads go, but Logitech is a solid brand for controllers. It should be pretty much on par with the Xbox 360 gamepad. | |
I wouldn't mind playing a few BYOND games using a USB SNES controller or even a USB N64 controller.
The 360 gamepad is by far the most convenient since they are everywhere and the wireless dongle for PC can be fetched for $10 on Amazon with some knowhow on Windows for correct driver install. Give me TrinusVR, Android Phone+GoogleCardboard, and 360 controller support and I'd probably play more BYOND games. | |
I have to warn you that so far I've come up completely blank on Epoch's FPS issue. There's no indication yet why it runs like crap in DS alone, but fine in DD+DS without either of them using up significant CPU.
Ter did mention that you use images a great deal; I wonder if that might be a clue somehow, although I still don't see how the performance would be worse in DS by itself. | |
Hmm. That actually is useful. If there's nothing that's causing DS by itself to run slow, then it might simply be some kind of built-in inefficiency in how some things are handled.
When I was taking care of Ter's bug report about image updates, I re-discovered something unsettling about the way DS handles images: Instead of a 1:1 correlation with DD like most other things use, it assigns each image a DS-specific "index" that isn't related to its ID at all. There are several places where the code has to look up an image by its ID, which means it first has to find the index. So there's some serious potential for O(N^2) behavior going on there. If you're using a crapload of images, I wonder if that's the culprit. Maybe the index list is filling up, things run slowly, and then as that clears out or as images in use start to fill up easier-to-find slots in the index array, it gets faster again. IMO the image index scheme is a relic and should probably be replaced. I considered doing it right then and there with Ter's bug, but I felt there was way too much potential for something to go wrong if I jumped right into it then. | |
This is exactly what happens with my tests I've showed in FPS issues. And its probably not related to Image because you can simply do this in a new project with almost nothing in it.
And you not been able to reproduce those new bugs just shows how old your system is, is time to upgrade. | |
Yut Put wrote:
I think I actually am using at least 1 image per turf on the screen for tile outlines. I'm also using an image for the lighting plane master and images for each light on the screen. I suppose that qualifies as a crap load. Hrm, maybe half a crapload, but potentially enough to fit my hypothesis. If the slow-fast cycle doesn't happen when you don't move around, that's a big clue too. I can't think of anything that would cause cycling on 30-second intervals exactly, which leads me to believe that the timing of that has something to do with your specific project. | |
I'm very curious how multiple gamepads... gamepi... gamepad... whatever the plural would be, handled.
I'd imagine one issue would be detecting multiple gamepads and then having to decipher which button goes to what gamepad and if there would be gamepad disconnect detection. | |
Gamepads sounds weird to me. Like saying mouses but it's still acceptable when talking about a computer mouse, instead of saying mice.
| |
The idea that BYOND will at least have some form of gamepad support is exciting. I think that feature alone will make this a much more serious engine to consider for game development. This may also help to bring in players from a completely different niche.
However, I'm not a fan of mapping the gamepad controls to the keyboard and/or mouse. I think the gamepad should be considered as its own separate entity; whatever form it may take. At the very least I would want to be able to "map" every aspect of the gamepad directly to verb commands, including the axes (the sticks and the triggers), unless separate procs are used for those. In any case, arguments would be required to provide the positional and pressure data corresponding to the different axes. I can imagine this would be similar to the MouseWheel() proc. Mapping the gamepad to the keyboard doesn't really make sense. A gamepad provides a level of precision that just doesn't translate to keyboard keys. At the same time, gamepad sticks are not very good for moving a mouse, especially without controlling the sensitivity. I think that is something that is better left up to developers to implement. BYOND moving the actual mouse cursor around just sounds like it would be strange and buggy. I don't think it would even be possible in the webclient. Browsers don't provide access to the system on that level, for obvious reasons. Also, I can only speculate as to whether or not this is the case, but it sounds like placing the gamepad at a high enough level of abstraction to "feed" the input to the keyboard and/or mouse would result in some kind of delay. When providing built-in gamepad support, you really don't want to have a delay. Gamepads are designed to be as responsive as possible, and the software should reflect this. | |
Multiverse7 wrote:
However, I'm not a fan of mapping the gamepad controls to the keyboard and/or mouse. I think the gamepad should be considered as its own separate entity; whatever form it may take. While I see some value in that sort of thing, I think 99% of the use cases will be to make playing easier than it is by keyboard+mouse. At the very least I would want to be able to "map" every aspect of the gamepad directly to verb commands, including the axes (the sticks and the triggers), unless separate procs are used for those. In any case, arguments would be required to provide the positional and pressure data corresponding to the different axes. I can imagine this would be similar to the MouseWheel() proc. I'm really not sure how axes could be mapped to verbs in an analog way, unlike simply treating them like a D-pad if desired. What you're suggesting would be a proc that would be called any time the axis changed, which could be once per tick. I think there might be some use cases for that, so I'll keep it in mind, but I think it's likely to be a network hog. Mapping the gamepad to the keyboard doesn't really make sense. A gamepad provides a level of precision that just doesn't translate to keyboard keys. At the same time, gamepad sticks are not very good for moving a mouse, especially without controlling the sensitivity. I don't think that argument holds water, for a few reasons. Mapping the D-pad and buttons to the keyboard makes a very great deal of sense (especially if combos can be setup), and controlling sensitivity is built into my plan. I think that is something that is better left up to developers to implement. BYOND moving the actual mouse cursor around just sounds like it would be strange and buggy. I don't think it would even be possible in the webclient. Browsers don't provide access to the system on that level, for obvious reasons. Moving the mouse with a gamepad would make certain games playable for people who are really uncomfortable with a WASD+mouse setup, which is why I'm keen on that. I don't see myself playing Lux, for instance, without a feature like that. But you're absolutely right that controlling the mouse would be impossible in the webclient. Also, I can only speculate as to whether or not this is the case, but it sounds like placing the gamepad at a high enough level of abstraction to "feed" the input to the keyboard and/or mouse would result in some kind of delay. When providing built-in gamepad support, you really don't want to have a delay. Gamepads are designed to be as responsive as possible, and the software should reflect this. That won't be the case. Keyboard and mouse commands themselves are sent once per tick, and gamepad commands--whether mapped directly to a verb or counted as a key-up/down--would behave exactly the same. In other words, there's no delay that isn't already built into the system with any other input mode. Client-side commands like .winset are an obvious exception. | |
HRESULT EnumDevices(DI8DEVCLASS_GAMECTRL,lpCallback,pvRef,DIEDFL_ATT ACHEDONLY)
This calls:
BOOL DIEnumDevicesCallback(lpddi,pvRef)
lpddi is a reference to DIDEVICEINSTANCE, which is a struct with a simple format:
Important device types: DI8DEVTYPEGAMEPAD_STANDARD, DI8DEVTYPEGAMEPAD_LIMITED
From there you call EnumObjects() to query information on each input available on the controller. For instance, you can count Axis 1, Axis 2, Axis 3, ABSAXIS, push/toggle buttons, or a force-feedback actuator. There's a lot more, but this is all that really matters.
TL;DR: Controllers are standardized now. The only trouble is that controllers now support pressure sensitive and floating point axis inputs. If BYOND implements controller support using DirectX8, it's burdening itself through yet another deprecated API and having to create new client verbs or client variables to store axis offset data or trigger pressure data.
The actual implementation is more or less a non-issue. The problem I see is in hamfisting it into BYOND's structure itself.
I've got USB Xbox 360, PS3, NES, SNES, Gamecube, and N64 controllers for my computer. Even these inferior chinese knockoffs are using standardized HID schemas to make the automation of any mainstream controller detection and object enumeration painless.
I suppose the real worry is getting that data to the developer in a manner that isn't totally insane because polling is the single best way to interact with DirectInput8 HIDs and polling HID object data per frame and firing it to the server could in many cases generate a lot of headache for developers. It's not just the API, it's also about mating performance, user expectations, and developer control.
XInput further marries us to Microsoft in that it is exclusively for a singular HID layout. DirectX8 further marries us to deprecated Windows-exclusive products and divides the codebase further as the webclient obviously cannot support this.
The only sane choices are SDL or GLFW. Working with OpenGL 3.2+ GLFW compatible code is god damn amazing. Real trouble is the manpower and energy it would take to convert all of our existing Win32-foo (of which there is a lot) would be an absolutely mountainous task.
I'd be more than willing to approach the task of rewriting Dream Maker's UI and DreamSeeker's UI in modern OpenGL as an experimental build, but my knowledge of C is much more spotty than my knowledge of DM, and my GLSL know-how is incredibly rusty, particularly when dealing with writing fallback shaders and feeding efficient batches into the hardware rendering pipeline from the C end of things. Even then it's questionable how much progress I'd be able to make due to the fact that it'd likely take me months to even begin to understand half of the things that are in BYOND's source code, and there'd be no promise that I could figure out what obscure bits of hacked-in code would break when trying to migrate away from Microsoft-locked chunks of the engine.