gzdoom in ubuntu : customize key control

[kkmin]

I can't customize control key in ubuntu gzdoom.

w:forward
s:backward
a:move left
d:move right

<= thease do not work, I can not input in screen.

only arrow key works.

Am I something wrong?

[Rachael]

What are your country settings and key input settings in Ubuntu?

[kkmin]

I am Korean, Korean key setting in ubuntu

[Rachael]

That was actually an extremely crucial bit of information, and I am glad you came back to provide that.

I don't know exactly what's wrong here, but from the sound of it, GZDoom (SDL) is not correctly mapping the key letters to the actual key scan codes. As a result the keys that are coming back seem to be unrecognized.

I have never used an Asian keyboard layout. Are you able to start GZDoom using the Latin input mode and leave it that way? If not - then it sounds like we're going to have to find a way to force SDL to recognize the Latin scan codes regardless of the current keyboard layout, if it somehow finds that they don't otherwise exist in the current layout.

[Hirogen2]

On the upside, I can actually input Japanese characters into gzdoom quite successfully, with only little bugs remaining. (1. only the first Unicode character of the multi-character IME output is copied over. 2. Player Setup submenu does not use the new font yet.) Of course, the usefulness of such input is limited to the console and menu (e.g. player name), and indeed should not be on while the level tick is running.

Not sure if SDL can actually do that. mplayer for example gets raw codes, but it is not using SDL's keyboard input. asteroids3D also gets raw codes, but it too is not using SDL input but glutKeyboardFunc.

[kkmin]

thank you for reply.

[Graf Zahl]

On the upside, I can actually input Japanese characters into gzdoom quite successfully, with only little bugs remaining. (1. only the first Unicode character of the multi-character IME output is copied over. 2. Player Setup submenu does not use the new font yet.) Of course, the usefulness of such input is limited to the console and menu (e.g. player name), and indeed should not be on while the level tick is running.

Not sure if SDL can actually do that. mplayer for example gets raw codes, but it is not using SDL's keyboard input. asteroids3D also gets raw codes, but it too is not using SDL input but glutKeyboardFunc.

I have been wondering if it makes sense to replace SDL with GLFW. Unlike SDL it's far less invasive and can also be safely used on Windows and macOS without screwing up the I/O handling for everything. I have been doing multi-platform games with it and generally find it a very workable option, because unlike SDL I can make it interoperate with Windows's DirectInput backend.

[Chris]

I have been wondering if it makes sense to replace SDL with GLFW.

GLFW is one of the more-mentioned libraries I see next to SDL (along with SFML). I can't see much reason not to try if you think it can work better, though my one concern would be gamepad support. SDL has a gamepad/controller API that maps known joysticks to a common layout (you get left/right sticks, shoulder buttons, a D-Pad, A/B/X/Y, etc, and SDL worries about mapping the given joystick's axises (axii?) and buttons to them using a premade database). GZDoom doesn't seem to currently use SDL's controller API, so there won't be any loss here, but it's something to be aware of if there were future plans to.

[Enjay]

given joystick's axises (axii?)

The plural of axis is axes (same spelling as plural of axe). Aaaand that's about all I can contribute to this discussion.

[dpJudas]

I would personally go the other way. Drop SDL on Linux and interface the platform directly. On Windows I see no advantage in adopting a wrapper library whatsoever when there's already a working platform binding in place.

Not that it truly matters what I think as I won't do the work either way.

[Chris]

Drop SDL on Linux and interface the platform directly.

The thought of using X11 directly still gives me nightmares. Though even aside from that, some people are moving to Wayland which has its own interfaces (there is an X11 compatibility layer so it'll still work, but if you're knowingly going that route anyway, why not something cleaner like SDL or GLFW that directly deals with X11/Wayland for you).

[dpJudas]

Because I don't think interfacing X11 is particular tricky (done it before). The biggest catch are the window manager hints, which I admit is a PITA, but on the other hand once you've paid your taxes for Linux desktop WM hell, you no longer have to rely on distros updating SDL for Vulkan support, for example. Essentially the same reason I prefer my own solution on Windows and macOS - the cost of writing the platform binding is one-time early on, but the benefits of not having the abstraction lib between you and your platform is worth it in the long run.

As for Wayland, they provide a xlib compatibility layer. I'll take that technology a little more seriously when it works on my computer.

Edit: Sorry for the harsh words, but I completely agree with Linus Torvalds when he commented on "Why Linux Failed On the Desktop". I get why people feel you need an abstraction library just to target that platform, but I don't think that applies anywhere else. What got me commenting in the first place was Graf talking about using one of those abstraction libs for Windows. That I feel is a bad idea when there's already a perfectly working solution in place. I'm sure those are fine libs but I don't think any of them does it better than the direct GZDoom code built for Win32 today.

[Chris]

The biggest catch are the window manager hints, which I admit is a PITA, but on the other hand once you've paid your taxes for Linux desktop WM hell, you no longer have to rely on distros updating SDL for Vulkan support, for example.

Instead, you have to worry about your code working with future (or untested current) WMs people may use. It's not a one-time thing, given that WMs and X itself are continuously updating. Not that this necessarily means broken compatibility, but adapting to the current best practices that gives a better user experience. Some code you wrote a while ago may only support Xinerama or XVidMode, for example, and so won't get the benefits of XRandR. Code you wrote to support XRandR 1.0 won't be able to take advantage of XRandR 1.3 features, etc. A library like SDL or GLFW deals with this for you too, since you can update to the newest version to take advantage of the new things people care about, with your code only needing minimal changes if any at all. It can also keep support for older stuff, or emulate newer features, as a fallback for systems that need it (supporting XVidMode when XRandR wasn't available, or mouse warping to simulate the mouse locking added in XInput2). Not to mention common issues and pitfalls a developer may stumble into with these APIs which need debugging and testing as they crop up, that these libraries have long ago dealt with.

Edit: Sorry for the harsh words, but I completely agree with Linus Torvalds when he commented on "Why Linux Failed On the Desktop". I get why people feel you need an abstraction library just to target that platform, but I don't think that applies anywhere else.

That seems to be a separate issue. From what I get, he's talking about being able to simply get and install applications, which different distributions handle differently (hence the mention of Flatpak), rather than the APIs used by developers. Fragmentation isn't the reason for abstraction libraries like SDL and GFLW, it's because using the APIs directly is a pain with a lot of boiler plate (where you have features that some niche programs need, but the general use-case doesn't so most developers end up needing to do the same things). When you're writing cross-platform code, having to maintain several platform-specific backends is also a pain, especially when you want to add new features -- some platforms end up lagging behind, and you get into issues of first-/second-/third-class support. As a developer, it's easier to push that work off onto someone else who's willing to deal with it.

[dpJudas]

There's no guarantee SDL deals with that as the new best practice<tm> may rely on information not available to SDL without additional hints. On the other hand, since SDL has to abstract several platforms there's no guarantee that the hints required to take full advantage of XRandR 1.3 features are available as hints, since those hints may not have any meaning on other platforms.

I don't like abstraction libraries mainly because as soon as someone didn't bother adding a feature to the abstraction I'm more or less fucked. For example, recently the lazy folks at Qt didn't bother supporting proper frameless (main) windows. As a result, I cannot make a visual style that follows the general trend of the Windows platform. My applications look "old" and "dated" as a result and I'm losing the competition against HTML chrome engine wrapper apps like Discord. SDL has similar limitations or otherwise nobody would have bothered to write direct Cocoa support for macOS when there's already a SDL implementation for it. Some of the users on Doomworld are complaining the software renderer of their source ports are stuttering - what if that's caused by SDL? If so they are game over. That sort of stuff.

There are situations where I don't have the resources to write the proper platform implementation and therefore have to rely on such libraries, but ultimately I only do this if I have no other choice.

[Chris]

There's no guarantee SDL deals with that as the new best practice<tm> may rely on information not available to SDL without additional hints.

Sure, but given the number of applications that rely on SDL/similar, if it's a desired feature it won't be ignored. If you can't update your code to supply new hints for a new feature, you likely couldn't update your code to access the new feature directly either. So with the former, you may or may not get an automatic improvement with a library update, and with the latter, you definitely won't.

I don't like abstraction libraries mainly because as soon as someone didn't bother adding a feature to the abstraction I'm more or less fucked. For example, recently the lazy folks at Qt didn't bother supporting proper frameless (main) windows. As a result, I cannot make a visual style that follows the general trend of the Windows platform.

Well, even Microsoft has a hard time following the general trend of Windows' visual style. But more seriously, if it's a feature that a lot of applications need, they can't ignore it. Don't get me wrong, if there's something you actually need that a platform-independent solution doesn't provide, it's totally understandable that you'd do it "manually". If enough developers are willing and able to avoid Qt for not providing what they need, it would be a kick in the pants for the Qt folks to find a way to provide it.

Some of the users on Doomworld are complaining the software renderer of their source ports are stuttering - what if that's caused by SDL? If so they are game over.

If so, it sounds like a serious bug that would be affecting not only those Doom source ports, but everything else that uses SDL for similar functionality, and should be a high priority for them to fix. But to turn that around, what if that stuttering is caused by developers using X directly, and not knowing how to use X correctly because their preferred/only dev system is Windows, or they don't have the time to work on the non-Windows code? No amount of improvements made to SDL will fix code that doesn't use it.

I actually find it interesting that even today, there are some games with native Linux ports that you actually get better performance when running the Windows version under Wine. It's obviously not a problem with the platform's capabilities since Wine is using all the same facilities a native game could (in a less-than-efficient manner, even), but the developers of such games simply don't have the time or financial incentive to make their Linux-specific code as good as it could be. So a way to avoid that problem would be writing as little Linux-specific code as possible to begin with (an SDL/GLFW/SFML/whatever backend that's only used on Linux I'd still consider to be Linux-specific, since most developer attention will be with code used on Windows).

There are situations where I don't have the resources to write the proper platform implementation and therefore have to rely on such libraries, but ultimately I only do this if I have no other choice.

I generally look at it from the other direction. There are situations where I will write platform-dependent code because I have no choice to get what I need, but I first look to platform-independent solutions where possible.