Hacker News Reader

Comment by picozeta | Hacker News Reader

Furthermore SDL2 is absolutely fantastic and just works. You may say, you do not want to use it as it "just" abstracts away keyboard/mouse/controller input, window and GL context creation but these things are damn hard to get right.

View on HN

As a current SDL2 user: it is not fantastic and it does not just work.

- On Windows, DPI scaling is broken (ask for a 1280x720 window, get 1600x900)

- On Mac, mouse locking is broken

- On Linux, my Xbox gamepads don't work at all

- Required several hacks before it could be used as a CMake submodule

This stuff is under active development, which is shocking for such an established and widespread library. I'm glad it exists, but it doesn't "just work".

Can't really blame it though, it has a very boring and nearly impossible task.

Does high-DPI support work if you put the right declaration in your executable's manifest? Specifically:

    <application xmlns="urn:schemas-microsoft-com:asm.v3">
        <windowsSettings>
            <dpiAware xmlns="http://schemas.microsoft.com/SMI/2005/WindowsSettings">true/pm</dpiAware>
        </windowsSettings>
    </application>

Thanks, yeah I tried something equivalent to this (SetProcessDpiAwareness, as mentioned by another commenter). It broke some other SDL stuff though. I'm just gonna have to screw around with it when release time comes.

Have no idea about DPI on Windows, but from my experience mouse locking on OS X worked and my Xbox pad works for sure (checked just month ago or so). I know about some issues with force feedback, but not sure if those are even SDL issue.

PS: What OS X version you had problem with?

Tested on El Capitan. IIRC, SDL_SetRelativeMouseMode didn't work at all, the cursor remained visible. After some workarounds, there are still issues with the cursor not re-centering correctly, menu bar remaining visible, etc.

It's probably because I'm on a random Git commit rather than a stable release, but I had to do that due to another issue. It's surprising how many things are in flux, given how long it's been around.

> - On Linux, my Xbox gamepads don't work at all

Really? I use Linux full time at home and I've never had problems with 360 controllers either when developing with SDL2 or playing games built with it. Are you talking about original Xbox and/or Xbox One controllers?

Aftermarket Xbox 360 controllers. I've seen other Linux SDL games work with 360 controllers, so I assume the problem is on my end. I just wanted to contest the notion that SDL "just works". It still takes a lot of fiddling unfortunately.

It has its own quirks, but I was mostly impressed with SFML when I tried it. SDL always seemed vaguely badly designed -- it worked well enough that I never seriously considered replacing it, but I can't say I ever really enjoyed using it.

The DPI scaling issue is probably because you didn't call SetProcessDpiAwareness

Yeah I tried that before and it solved the problem, but then it broke some other aspects of SDL. Can't quite remember, I think fullscreen got messed up.

There's code in SDL specifically for high DPI, but it's confusing and practically undocumented.

It's just something I'll have to mess around with a while, and then remember not to breathe on anything once it's working. :)

Looks like it really is damn hard to get right.

Also, your game will continue working natively when linux transitions to using wayland/mir, without having to run via an X11 shim.

This is true for the alternatives as well, approximately nobody writes raw Xlib apps in modern times.

Unfortunately most of game developers that decide against use of SDL2 do that based on their experience of Windows development where it's pretty much standard to have own code for everything (except development tools and some middleware). E.g they think that their own code going to take less lines and be cleaner than SDL.

As result these people usually don't even consider any alternatives as all of them even worse from their standpoint.

... And those developers are generally right.

I would use SDL in Linux ports of things because it is the closest to a reasonable native API on Linux (which says more about Linux than SDL actually). But even having done so I would then use native APIs in Windows, OSX, etc.

If your standard of quality is high enough, it won't really be possible to reach it using a blanket API like SDL everywhere.

It's reasonable to keep native code when you already spend months / years working with it. Or if you're huge company with hundreds of programmers that want to have own everything.

Though when it's relatively new game with own engine and small team maintenance cost for own cross platform code going to be high. Even on Windows there is tons of small problems that already solved within SDL. It's really not fun to debug problems of XP, Vista and some not updated systems.

PS: Also as far as I aware SDL2 currently used by all Valve games on all platforms. I pretty sure they wouldn't be using it if it's wasn't working well.

IIRC Valve uses SDL for some things but also goes around it and uses platform APIs for other things.

So it means you prefer SDL2 on Linux because it is the least awful. Can you elaborate why you would not use it on e.g. Windows? Which parts of it do you consider inappropriate do use it cross-platform?

Nothing on the post above is even remotely accurate.

So much explained disagreement.. not?

SDL2 also have nice SDL_DYNAMIC_API feature that let users to switch to different library version even if it's statically linked.

Reply on news.ycombinator.com