ZDoom

by **dpJudas** » Mon Apr 15, 2019 9:01 am

Graf Zahl wrote:It all depends. Yes, we have our own Windows backend, our own macOS backend and our own SDL backend.
What if we needed an Android backend - or an iOS backend - or a backend for the next hot thing that comes along in 5 years.

For Android and iOS the big problem isn't calling their CreateWindow equivalent - its supporting their graphics API and chips. Also since those platforms are sandboxed the real work here is figuring out how to deal with packaging as it is so different. Their input UI also uses a completely different principle (touch vs keyboard+mouse), which once again no abstraction library can fix for you.

As for what comes in 5 years, this falls into the You Won't Need It category. With no knowledge of that potential future platform, or the future of your abstraction library of choice, you can't know if can be supported by a trivial recompile. It certainly wasn't the case when the mobile platforms emerged. You have some chance it will magically work thanks to the wrapper lib, but I'd say you won the jackpot if that is the case.

While they 'work' they also cause work. Fortunately not much but it's there. So if there was a practical way to fold it all into one piece of code and offload the backend maintenance to the maintainers of a third party library *WITHOUT compromising our own product* it'd be worth it. Sadly it's here where SDL is a less than optimal solution.

If you don't like the maintenance burden and want to get rid of it, sure, who am I to stop you. Just remember not to blame the user or his hardware if a user shows up that now can't do XYZ thanks to the wrapper lib not having included that problem in its abstraction.

Just as a recent example, until recently the entire Windows backend had no clue about Unicode, it was using the ANSI API for everything and many parts were hard coded to assume 8 bit characters. It was a non-trivial amount of work to change this.

That's more an artifact of the early ZDoom developers not knowing the platform. Even Windows 95 supported the Unicode API. If they had used a wrapper lib back then it too would have used 8-bit and have just about as good an idea about it as the C locale functions (some true character set horror right there).

by **dpJudas** » Mon Apr 15, 2019 8:47 am

Chris wrote: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 think you misunderstood what I meant. I am talking about the situation where the new feature relies on information not exposed by the SDL abstraction. For example if the new Best Practice (god I hate that phrase) is to use Vulkan over OpenGL, or DirectWrite over GDI's font classes, there's no way SDL can close that bridge for you. SDL can only help you each time someone comes up with a new incompatible sound daemon implementation or whatever idiotic "lets just drop the backward compatibility" move they might do next. It cannot magically improve things unless its own abstraction is actually superset of what its wrapping. It is the law of leaky abstractions.

I think such libraries makes sense for stuff that's "unimportant" for you app. Things at the edges where you don't really care if you have the best implementation possible for the platform or not. However, for games I think the display and input handling is quite central to the product.

But more seriously, if it's a feature that a lot of applications need, they can't ignore it.

Never underestimate the power of unwilling developers and managers in key positions. Yes, eventually it will cause them to hurt as they lose users, but celebrating Qt will eventually pay for their unwillingness to serve their customers aren't worth much when you literally built a decade of UI on top of that abstraction library. You will go down with them.

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.

The keyword here is should. What if their active developers mostly reside on Linux? What if most of them only care about OpenGL based Linux games? They might not be retro gamers.

Firefox had a bug where keyboard input would be lost whenever a Flash component was rendered on a page. It had this bug for over 3 years. Every single user affected on Windows. High numbers is no guarantee for them prioritizing something if the manager at Mozilla happens to be one of those people that only use the mouse.

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.

They opted for not caring for the quality. You're right that if you don't care about Linux then using SDL at least give *some* support. That doesn't mean it is better than an actively maintained backend.

Anyway, we probably won't get to agreement here because we have different trust in 3rd party developers. That's essentially what it boils down to. You expect them to provide a good service, and I expect them not to.

by **Graf Zahl** » Mon Apr 15, 2019 12:51 am

dpJudas wrote: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.

I generally agree, as long as it concerns such thick abstraction layers as SDL which make it very hard to work around its shortcomings. That's why I mentioned GLFW which is a very thin layer - it only abstracts the window management but does it in a way that it's still possible to get around it.

I find it a bit puzzling that almost every other port out there settled on SDL and constantly has to deal with some problems by using such a Linux-centric library on Windows. SDL 1.x was particularly problematic if you just happen to use a non-standard keyboard layout. I have no idea what the SDL guys have been doing but they somehow managed to change the system setting in a way that it got Windows to activate its language changer in the status bar. Back in the early days when I was still working on a PrBoom derivate one of the first things I did was to get rid of SDL because it constantly stood in the way of doing things right.

dpJudas wrote: Edit: Sorry for the harsh words, but I completely agree with Linus Torvalds when he commented on "Why Linux Failed On the Desktop".

Nice video. It sums up the problem I have with Linux mostly. One directly applies to GZDoom: On Windows and macOS it's a trivial matter to get a string, give it to the system along with a font and a size and retrieve a perfectly usable graphic for the text. On Linux - no such luck. The system has no facilities and with third party libraries we are again at the mercy of those users who are unwilling to install the needed libraries for whatever reason - be it that their distro of choice does not provide the needed version or they have some irrational antipathy towards one of the dependencies and what not. Fortunately I am not directly involved with this at work but my colleague who is responsible for our software's Linux deployments can tell endless stories about this stuff and how much wasted work it costs. In the end it's just cheaper to equip all working desktops with Windows and forget about this support nightmare.

dpJudas wrote: 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.

It all depends. Yes, we have our own Windows backend, our own macOS backend and our own SDL backend.
What if we needed an Android backend - or an iOS backend - or a backend for the next hot thing that comes along in 5 years.
While they 'work' they also cause work. Fortunately not much but it's there. So if there was a practical way to fold it all into one piece of code and offload the backend maintenance to the maintainers of a third party library *WITHOUT compromising our own product* it'd be worth it. Sadly it's here where SDL is a less than optimal solution.
Just as a recent example, until recently the entire Windows backend had no clue about Unicode, it was using the ANSI API for everything and many parts were hard coded to assume 8 bit characters. It was a non-trivial amount of work to change this.

by **Chris** » Mon Apr 15, 2019 12:16 am

dpJudas wrote: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.

by **dpJudas** » Sun Apr 14, 2019 8:39 pm

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.

by **Chris** » Sun Apr 14, 2019 8:14 pm

dpJudas wrote: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.

by **dpJudas** » Sun Apr 14, 2019 7:18 pm

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.

by **Chris** » Sun Apr 14, 2019 6:53 pm

dpJudas wrote: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).

by **dpJudas** » Sun Apr 14, 2019 5:44 pm

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.

by **Enjay** » Sun Apr 14, 2019 5:40 pm

Chris wrote: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.

by **Chris** » Sun Apr 14, 2019 5:11 pm

Graf Zahl wrote: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.

by **Graf Zahl** » Sat Apr 13, 2019 11:45 pm

Hirogen2 wrote: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.

by **kkmin** » Sat Apr 13, 2019 11:36 pm

thank you for reply.

by **Hirogen2** » Sat Apr 13, 2019 5:27 pm

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.

by **Rachael** » Sat Apr 13, 2019 2:38 am

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.

ZDoom

gzdoom in ubuntu : customize key control

Post a reply

Expand view Topic review: gzdoom in ubuntu : customize key control

Re: gzdoom in ubuntu : customize key control

Re: gzdoom in ubuntu : customize key control

Re: gzdoom in ubuntu : customize key control

Re: gzdoom in ubuntu : customize key control

Re: gzdoom in ubuntu : customize key control

Re: gzdoom in ubuntu : customize key control

Re: gzdoom in ubuntu : customize key control

Re: gzdoom in ubuntu : customize key control

Re: gzdoom in ubuntu : customize key control

Re: gzdoom in ubuntu : customize key control

Re: gzdoom in ubuntu : customize key control

Re: gzdoom in ubuntu : customize key control

Re: gzdoom in ubuntu : customize key control

Re: gzdoom in ubuntu : customize key control

Re: gzdoom in ubuntu : customize key control

Post a reply

Expand view Topic review: gzdoom in ubuntu : customize key control

Login • Register