Jump to content
Search In
  • More options...
Find results that contain...
Find results in...
Csonicgo

Officially had it with SDL

Recommended Posts

I'm getting sick of SDL's lack of (or glacial) progress and its horrible track record. Considering that it's the only free implementation of a media library that the Doom community uses, this affects a lot of ports.

I showed EE off to a few friends this morning on a friend's new computer. What happened? The engine deadlocked for a second on looping midi, sounds cut off and popped, and the midi was off tempo and lagged a bit. gameplay was fine, but the sound was horrible. Same for Prboom, Chocolate Doom and any others we tried. I know EE's sound code, and it is NOT the reason for the total embarrassing performance they saw. It was SDL and only SDL. This is a brand new AMD box with a brand new AMD video card and a solid dedicated soundcard. I can't blame his hardware.

This is not solid. this is horrible. And we've been putting up with it for years. Dare I say the entire open source gaming community has to deal with this clunker, and it's time to throw it out. The only problem is that there is NO alternative. This makes the ports look bad, play bad, sound bad. All those hours coding and tweaking are futile if the display and sound do not work properly.

And I have zero idea of what to do about this.


EDIT: I forgot to mention that in Prboom, the mouse cursor actually showed up over the gameplay screen and stayed there. I have no idea how. That's never happened to me, ever.

Share this post


Link to post

Eternity uses outdated versions of SDL, SDL_mixer and SDL_net, by one minor version number. I tested Windows Eternity with the newest SDL_mixer and there were no MIDI loop deadlocks. I recompiled Eternity for that; I'm not sure if you have to recompile Eternity just for replacing the SDL version.

On OSX I get very good MIDI with the latest stable SDL_mixer. Conversely, ZDoom's MIDI (FMOD?) sounds very bad: most instruments can't sustain.

What about development versions of SDL and satellites?

Share this post


Link to post

I know I use the latest versions in my compiles and on my system. I have no idea what versions we ship out. Those may be outdated. If that is the problem, this is a big problem. If we're shipping EE out with older SDL versions, we are hurting things. We need to come together on what versions to use. I asked about this in #doom-tech and it seems that we use some extremely old versions.

If we can get new MinGW32 compiles of SDL for windows ports, I think we would be set. MinGW32 is best because it works on all windows versions, unlike the 64 fork. MinGW32 also updated recently. If I need to do it I can attempt my hand at it; Though I would like to see someone with much more experience than me try his hand at it.

Share this post


Link to post

Personally I've never had a huge problem with it. Perhaps I'm sheltered from the problems because I rarely ever use Windows nowadays.

Share this post


Link to post
Csonicgo said:

Can everyone that uses SDL tell me what versions they have?


I use SDL 1.2.15 when I need something done quick. But, I don't like using the other SDL_* libs.

Share this post


Link to post
fraggle said:

Personally I've never had a huge problem with it. Perhaps I'm sheltered from the problems because I rarely ever use Windows nowadays.


Not to be a jerk but I think that's the problem with the SDL devs too. Windows isn't going away. Its time to support DirectX besides 5 and sound besides 8 channels. Windows support of SDL is barely there. Maybe the other way around.

I mean SDL DOESN'T SUPPORT DIRECTINPUT. GAAH

Share this post


Link to post

I just checked my SDL libraries and they don't even have version information. They were compiled in January so I suppose it's the latest. Ugh. I'll see what I can do.

Share this post


Link to post

One reason I did not go through with the upgrade, aside from lack of time to test it, was the note in fraggle's changelog about the new SDL_net being broken.

I'd like some explanation on what that means and whether or not I need to avoid upgrading some of the libraries.

Share this post


Link to post

Interesting. I tried to test multiplayer OSX EE with another Doomer (who posts around here), just by using the -net command-line parameter, and it did fail. Sure enough, I was using the latest SDL_net. I wonder if you can use an older SDL_net with the newest SDL.

Share this post


Link to post

SDL 1.2.14.0 here, slightly older but I've experienced no issues with EDGE/3DGE on any Windows-based system. Interesting you mentioned those problems, it makes me want to test the port on other PCs and see if I get the issue. So far though, 3DGE seems covered on this side - no sound/stuttering issues at all.

And about MinGW32, that's what I use to compile 3DGE. I try to update all of the libs it uses, but I think I stuck with the older SDL for some reason. Not complaining, though.

Share this post


Link to post

DoomLegacy: We do not ship SDL with the binary.

It varies as we support anything we can. My Linux 2.4 does not have RWOPs, so DoomLegacy detects the SDL version (I am guessing ver 1.2)
and uses the temp file method of playing midi for old SDL.
With Linux 2.6, it uses RWOPs.

On Win98, will compile and run with SDL.

On DOS and OSX, uses Allegro.

On Win, can compile DirectX

On Linux, can compile for X, or use SDL.

Share this post


Link to post
wesleyjohnson said:

DoomLegacy: We do not ship SDL with the binary.

It varies as we support anything we can. My Linux 2.4 does not have RWOPs, so DoomLegacy detects the SDL version (I am guessing ver 1.2)
and uses the temp file method of playing midi for old SDL.
With Linux 2.6, it uses RWOPs.

On Win98, will compile and run with SDL.

On DOS and OSX, uses Allegro.

On Win, can compile DirectX

On Linux, can compile for X, or use SDL.


does this mean we need an additional, separate zip file for the SDL library?

Share this post


Link to post

Means that the user installs the appropriate SDL for their system, like they would any other library. SDL is not hard to find and there is no need for us to re-distribute their libraries.

The DoomLegacy binary is dynamic linked against the SDL headers.
The header "/usr/include/SDL/SDL_version.h" contains the version numbers.
There are a couple of macros defined there that the code could use to print out the SDL version number of the headers as it was compiled. I did not look closely, but this would NOT give the SDL version number for the dynamically linked library.

On Linux 2.4 I am linking against SDL version 1.2.13,
on Linux 2.6 I am linking against SDL version 1.2.14.
On 64 bit Linux it is compiled by SmiteMeister who may have a more recent SDL version.

Any user can install a more recent SDL and run DoomLegacy as long as it is backward compatible with these headers.

Compiling against the latest headers would not hurt as long as the interface has not changed. If the interface changes, it would break compatibility with older SDL installations, and some users have to run the older SDL versions.

I do not know of any specific complaints about dynamically linking SDL. Have the usual problems with the windows changes messing up previous SDL libraries, and the implications of partially implemented handlers in SDL for some stuff (some querys as to video capability seem to never return true).

Share this post


Link to post

I feel your pain Csonicgo. Seriously. I've been dealing with sdl_mixer's crap for like 3-4 years. I've tried hacking sdl_mixer for different sound options and it just doesn't sound good ever. There's also something else going on beside sdl_mixer which I notice with eternity and prboom++; they both play midi instruments at different volume levels (maybe this is in relation to the mus code).

The best option IMO is for developers to incorporate timidity++ for midi playback. It's the best sounding midi you can get through software as far as I know (this is probably why it can act as a hardware midi module) and it's even better than some hardware modules; you can emulate various midi modules in fact and a lot of options for power users exist. Zdoom on linux (I use slackware) sounds really good with timidity++ and I don't even need it running in the background (supposedly fmod calls timidity++ on demand). Would be really nice if developers added timidity++ support (or the option to choose a hardware midi device).

I'm sorry man...

fraggle said:

Personally I've never had a huge problem with it. Perhaps I'm sheltered from the problems because I rarely ever use Windows nowadays.

I don't understand how someone can not have issues with SDL if they're not on Windows. SDL_mixer has so many problems with volume envelope, wrong instrument levels, wrong stereo panning (sometimes stuff sounds mono and horrid), reverb issues and many other flaws (this is on Linux btw and I've even altered source files with higher sampling rates (defaults to 32000khz which is lower than a Gravis ultrasound), lower latency, and other improvements but it still really sucks). It's really noticeable when switching from sdl_mixer to timidity++. I think people who don't notice any issues either haven't heard proper midi playback or they just don't really care cause they can simply hear some kind of music (even when it's broken). There's a "HOW TO: Timidity for PrBoom-Plus" thread where Mike.Reiner and HackNeyed mention problems with instruments in Doom 2 map 05 in prboom-plus (and guess what it uses sdl_mixer); http://www.doomworld.com/vb/thread/50375/ . I put together an fpatches.zip patchset based on my experience; wasn't sure if anyone would like the set but they're here http://www.doomworld.com/idgames/?id=17195 . As a Linux user I'm someone who's had it with sdl_mixer's use of a really dated timidity and its now foobar'd fluidsynth soundfont backend (how can they add broken soundfont support? If they would just somehow integrate Timidity++ it would fix all these problems and be backwards compatible).

Share this post


Link to post

Timidity++ is plain standard C code that shouldn't use any platform dependent stuff at all.

Share this post


Link to post
Graf Zahl said:

Timidity++ is plain standard C code that shouldn't use any platform dependent stuff at all.

Since when did C have functions for playing sound? I really doubt that there is no platform-dependent code.

Share this post


Link to post
exp(x) said:

Since when did C have functions for playing sound? I really doubt that there is no platform-dependent code.

It's possible to write sound processing and creation code that has no reference to system components or actual audio streams. Such libraries leave it to the embedding to stream their output into a device.

snes_spc is a perfect example; it emulates the behavior of SNES SPC700 sound hardware. All it does is hand you a buffer of the next samples to play and you play them however you're capable of doing it. You could write them to a .wav file, for example, instead.

Such libraries are the most portable and provide the most flexibility in use. I would call them the only really valuable sound libraries. Ones that try to do all that PLUS handle every platform-specific sound backend imaginable, inevitably end up doing a half-assed job at most of them.

Share this post


Link to post
exp(x) said:

Since when did C have functions for playing sound? I really doubt that there is no platform-dependent code.


Maybe not endian-dependent, but there are platform-independent sound libraries out there. Few.

Share this post


Link to post

That makes sense. For some reason I thought that playing sound was more complicated than writing to a file. I should have known better.

Share this post


Link to post
exp(x) said:

That makes sense. For some reason I thought that playing sound was more complicated than writing to a file. I should have known better.

I suppose from how you're saying that, that sending that generated information to the speakers is a trivial process… Is it up to the implementor to find out the API for each platform to play the sound? Does the standard C library have functions for playing sound, in the same way that it has for 'writing to a file'?

Share this post


Link to post
printz said:

I suppose from how you're saying that, that sending that generated information to the speakers is a trivial process… Is it up to the implementor to find out the API for each platform to play the sound? Does the standard C library have functions for playing sound, in the same way that it has for 'writing to a file'?

I think on Linux you can actually do that, by writing to a file handle opened on the audio device :P That's a pretty limited way to do audio though. I don't think any serious program or library does that, not directly at least.

Share this post


Link to post

Lib SDL version 2.0 release candidate came out! http://www.libsdl.org/ I'd like to hear opinions on it. Do you have to change the code of your own program if you want to upgrade from SDL 1.2 to 2.0?

Share this post


Link to post
printz said:

Lib SDL version 2.0 release candidate came out! http://www.libsdl.org/ I'd like to hear opinions on it. Do you have to change the code of your own program if you want to upgrade from SDL 1.2 to 2.0?

It is neither ABI nor API compatible, or in other words, yes.

Share this post


Link to post

There has to be more to the causes of the SDL_mixer complaints.
I have run SDL_mixer on Linux 2.4 for years without hearing any of these problems (Slackware, ALSA, Timidity).

I had problems with ALSA recognizing the built-in mixer on my motherboard. Had to create a special ALSA startup file to fix those settings. Things like that will mess with your sanity because it is hard to track down. What ALSA comes up with by default is close but the controls do not all work right.
Even when ALSA reports that that it configured for a sound card, you should test the ALSA mixer. It makes mistakes.
Getting an ALSA updated to the new sound card improves the sound card interface.

I have more problems with Timidity. I have had to modify the timidity installation to get it to work properly.

It is just as likely ALSA, or its interface to new sound cards, or windows changing some interface.
Should realize that SDL cannot interface directly to the sound card because ALSA owns it. ALSA provides repeater devices. Timidity also outputs through an ALSA repeater port.

Share this post


Link to post
Quasar said:

I think on Linux you can actually do that, by writing to a file handle opened on the audio device :P That's a pretty limited way to do audio though. I don't think any serious program or library does that, not directly at least.


Yep, you could open /dev/dsp and just write sound data to it (and hope the sample format and rate was the same). You could even have a program write the data to stdout, and pipe it to /dev/dsp to hear it, like: mysoundgen > /dev/dsp

Linux used to have OSS, the "Open Sound System", which was based on this idea, and you could control the format and sample rate with ioctl() calls. It was replaced by ALSA, the "Advanced Linux Sound Architecture", but OSS was trying to come back with OSS4 version, which I think is being used by one of the BSD operating systems (maybe NetBSD).

Share this post


Link to post

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×