SDL 2.x because SDL 1.2 is not updated and has many disgusting things in it (only one possible window etc). SDL 2.x is just uselessly complicated (they added textures, like the good old surfaces were not enough) and it's still shit (it registers a SIGINT and a SIGQUIT handler forcefully and has bad API design).
>>10 Dillo, Links, Xombrero,Midori.(they're crippled in some ways). The problem is no one competent enough wants the burden of maintaining and writing a browser for years, so they lag behind in speed/features.
Name:
Anonymous2015-04-19 6:35
Use SDL 2.x, but statically link it into your program. That's what all of the Linux game developers are doing anyway, for binary distribution. Works even on Fedora Core.
SDL 2 is full of terrible stuff. SDL 1 makes *some* sense.
Name:
Anonymous2015-07-30 8:19
Run formally verified unmaintained software. If has no need to change.
Name:
Anonymous2015-07-30 16:49
If SDL 1 sucks, and SDL 2 also sucks, what alternatives are there? OpenFL?
Name:
Anonymous2015-07-30 17:11
The initial idea of SDL was just a standardized frame-buffer access, so you can easily port 2d games between platforms. Now SDL is a huge bloated mess of an API.
Name:
Anonymous2015-07-30 17:21
>>22 Well, it's for making games, so they added interfaces to stuff you need for making games:
- Input handling (mouse, keyboard, controllers...) - Filesystem access - Decoding various media formats - Playing audio
You can prove SDL is useless by writing a game that uses none of these.
Can anyone give an in-depth explanation of what they think is shit about SDL?
I haven't looked too much at the source, but I do know it uses fucking autoconf.
Name:
KIKES2015-07-31 21:17
class JEWS { static public void main( String args[] ) { System.out.println( "JEWS" ); } }
Name:
Anonymous2015-07-31 22:16
>>33 SDL takes too much onto itself, instead of doing just one thing and doing it great, SDL provides sound, cd-rom access, networking and opengl bindings. So you can't use SDL framebuffer functionality without also bringing-in the whole mess. SDL2 made it even worse: instead of breaking functionality into separate libraries, it made even more integration. I.e. SDL2 competes systemd.
Name:
Anonymous2015-07-31 22:36
You can't use SDL2 without dynamic linking.
Name:
Anonymous2015-07-31 23:40
>>35 SDL2 will probably require systemd at some point. I'm wondering about Allegro. All I want, though, is a portable library that can create a window & OpenGL context, take input events, write sound to output buffers, and have a minimum of fussy code potentially fucking up each of those functions. Having seen all the inconsistent behaviour on Linux that SDL has to deal with just to create a possibly fullscreen window, I don't want to write that library.
>>36 It's like they suddenly decided to suck ULRICH DREPPER's dick. However, you can substitute one line in the header file to reenable static linking.
a portable library that can create a window & OpenGL context, take input events
GLFW
write sound to output buffers
this is more difficult, probably have to wrap up OpenAL
Name:
Anonymous2015-07-31 23:52
>>37 Nothing having to do with the anything except the command line on Linux is going to be elegant. Blame X11. It's full of thirty years of hacks to fill every niche use case, and is more bloated than most GNUShit could ever possibly aspire to be. Also, sound is an even greater pain in the ass.