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.
>>40 I'm not sure if that's supposed to be something snarky or not. But anyway, I won't. Changing X11 for Wayland is like changing from KDE to Gnome. It's the same skyscraper built on a sand dune, but with a different decoration. If something wants to replace X11, then it should at least be a good replacement, not a just a slight improvement to an internal architecture that is already shit. If you want to have break compatibility, break it hard and make it worth it.
>>41 That's what I've been saying all along. Of course the Lennart-types think I'm insane and shout me down.
I want something at least resembling Plan 9's /dev/draw and rio, not Xorg-nextgen.
Name:
Anonymous2015-08-01 1:27
>>41 I don't think you understand what Wayland is. Wayland is a display server protocol designed from scratch, Wayland is designed to be lightweight and flexible while dropping the X11 cruft of the past. The Wayland protocol doesn't include any support for networking, its purpose is to connect programs to your computer graphics system. You need to extend Wayland to include network support like Wayland+VNC or Wayland+X11 or Wayland+RDP.
While it's true that Wayland/Weston is written by the same team who maintains X.org, this team is actually the best team to know about how developers are actually using X11 today to draw graphics and where X11 graphics is obsolete in today's context. The graphical technology that was an extension of X11 is now easy to use and extend with the Wayland protocol.
Name:
Anonymous2015-08-01 1:32
>>42 What, is there a better open way to do multichannel 3d sound simulation? Are you simplying complaining that OpenAL is overengineered for the case of simple two channel sound playback?
Name:
Anonymous2015-08-01 2:07
Don't need to use X11 if you're gonna write a fullscreen graphics program on Linux, just bypass that shit and use DRM to write to the framebuffer directly. And it's not even that much code, it's comparable to setting up a window in xlib or xcb.
Name:
Anonymous2015-08-01 2:57
>>44 I know what it is. You say that it was designed from scratch, but it isn't. It is only written from scratch. The X11 taint is still there. I'm not even against networking (even though it is stupid).
The Unix philosophy is not a good idea for things like this. All it does is allow tons of idiotic NIH libraries to pop up. You don't have to install 500MB of libraries to get a Hello World dialog on windows. It needs a tight integration with the OS. 90% of the features need to be gone. Composition and window management and all the other shit should be inseparable. No switching out components just for the fuck of it. No extra libraries to put widgets on the screen. Desktop managers should just be themes and a menu. It sure would save a dick load of time, effort, and memory to not have to have 100 libraries (then KDE and Gnome libs on top of that) installed just because it's a complete pain in to make a window without them.
But, if there was any interest in something like that, it would probably just merge X11 and GTK+ and KDE or some other sort of almost-incompatible unholy abomination of hacked together shitware long enough to get it to just barely work. Instead of getting anything sane, you'd end up with the Systemd of GUIs. The open source community is absolutely terrible at things like this. Gnome can't even make a resource monitor that doesn't eat tens of megabytes just to display a list box.
Name:
Anonymous2015-08-01 3:33
>>47 You're talking about the size of libraries when a base Windows install is 20+ gigabytes. It's nice to have the ability to opt out of unnecessary features. And hand-holding distros will package all of that for you by default.
Name:
Cudder !cXCudderUE2015-08-01 5:08
GDI is superior.
>>47 This, I wish the circlejerking *nix crowd would just adopt the Win32 API.
>>48 My Windows directory is currently 939MB and I have another 1.1GB in Program Files.
>>49 Win32 is a steaming pile and always has been. Even within Microsoft, only the Windows teams have ever been enamored of it. The original NT team was famous in their distaste for it, in fact.
Real time audio synthesis, midi and OpenGL in Praxis for the windows build come courtesy of the Win32 API. On Linux, audio is through SDL, midi is through RtMidi and a midi server like Timidity, and OpenGL is through Mesa. The fact that the Win32 API offers a "one-stop-shop" for basic, functional audio and OpenGL that is guaranteed to exist on any windows machine makes me happy and makes things much easier. Using the Win32 API for a windows program is so rock solid and everlasting, its like you are writing for a games console. Say what you want about it, but the fact that the Win32 API hasn't fundamentally changed since Win95 and continues to be useful makes it extremely valuable. It is a truly eternal, dependable API, and the main reason as a programmer I continue to use windows sometimes.