Hacker News Reader

Comment by SXX | Hacker News Reader

I’m not using SDL or any other library to hide those platform differences.

Once start working on Linux port he'll regret about that. Every developer that start with own platform-specific code end up using SDL2 anyway. Don't do that mistake.

View on HN

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.

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.

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?

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.

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.

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.

> - 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.

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.

Looks like it really is damn hard to get right.

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.

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

An alternative is Cocos2d-x, but they manage memory using a single autorelease pool.

I might be wrong, but I think I remember that Cocos2d-x uses SDL under the hood.

From what I can gather, not with V3 and above. I think starting V4 they will go render-agnostic so they can use Vulkan and Metal.

Besides, there is more than rendering for a decent engine. Managing controls in an agnostic way is nice to. I am actually working on adding better control-events so it can wrap Windows, Windows phone, Apple TV and External controllers easier.

> "From what I can gather, not with V3 and above. I think starting V4 they will go render-agnostic so they can use Vulkan and Metal."

That would make sense, last time I touched it was back in 2012.

> "Besides, there is more than rendering for a decent engine."

For sure, but Cocos2d-x is a complete software framework and SDL is meant to be a library. Although I would grant that it would make sense if the author would choose to use a game engine for his game.

>> "From what I can gather, not with V3 and above. I think >> starting V4 they will go render-agnostic so they can use >> Vulkan and Metal."

>That would make sense, last time I touched it was back in >2012.

Cocos2d-x has never used SDL for anything.

for v4 the renderer is vastly different. Going from v2 to v3 there were major changes here as well.

No, SDL is not used under the hood.

Before going with SDL2, I'd highly suggest evaluating it compared to GLFW.

Reply on news.ycombinator.com