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

Officially had it with SDL

Recommended Posts

I've heard Allegro is a great alternative to SDL, but I'm not seeing it as widely used. Is it because it's generally "heavier" than SDL? Aside from it being popular with DOS apps (rarely do I hear people using it for OGL).

Looks like Allegro has better sound management too?

Share this post


Link to post

Allegro has definitely matured a lot recently because of Allegro 5, but as far as sound goes it's still missing a few features that would be vital for a Doom port. In particular, there is no built-in MIDI support so it would all have to be done with a different library.

Share this post


Link to post

Whenever I hear about Allegro I'm surprised it still exists. It reminds me of days gone by, using DJGPP and the likes. I mean, it started as an Atari ST library!

Share this post


Link to post
Ladna said:

So I found Gorilla Audio. It doesn't seem like the worst thing ever.

Sounds lovely except for the complete (and unsurprising) lack of MIDI support. Until something actually compileable (ie. not FluidSynth) exists which doesn't make MIDIs sound like a trainwreck, there's nothing we can do to completely get away from SDL_mixer.

andrewj said:

SFML is a C++ alternative to SDL: http://www.sfml-dev.org

Never used it myself though, and you'd still need to play MIDI somehow.

Having zero audio support is the only reason EE doesn't already have a SFML implementation of its video HAL. Doesn't do any good to replace SDL with something that doesn't fully replace SDL.

Share this post


Link to post
chungy said:

DJGPP still exists and is still maintained. :p


This is true. It's also C++11 compliant. Which is impressive.

Share this post


Link to post

If it uses Windows system MIDI output, yes, it's a trainwreck. I consider that part of the system broken beyond repair.

It's really too bad that the makers of FluidSynth have made their product vitually uncompileable on Windows - but what I don't understand is why just using a precompiled DLL like ZDoom is not an option.

Share this post


Link to post
Quasar said:

Having zero audio support is the only reason EE doesn't already have a SFML implementation of its video HAL.

Huh? According to the website, SFML 2.0 has an Audio module for playing sound.

Share this post


Link to post
Graf Zahl said:

It's really too bad that the makers of FluidSynth have made their product vitually uncompileable on Windows - but what I don't understand is why just using a precompiled DLL like ZDoom is not an option.

I wonder how big their audience is, that they don't have something easily prepared on Windows.

Share this post


Link to post

The problem with compiling FluidSynth on Windows is mostly because of the dependencies it has. Each of the lib required by FS depends on several other libs, which in turn depends on others, and so on. By the time you've got them all built, you have basically replicated the entire Linux development environment.

Randy mentioned a libintl replacement; I wonder what it was.

Share this post


Link to post
Gez said:

Randy mentioned a libintl replacement; I wonder what it was.

Good heavens, now the burden of internationalization and localization comes to sound libraries? Just force people learn English, not make the program harder to build.

Share this post


Link to post

Isn't Windows MIDI what SDL mixer uses? I just fired up PrBoom+ and PortMidi sounds just like SDL mixer.

Also I have no doubt I can compile Fluidsynth. When I get it working I can probably also host the project and dependencies somewhere. For me, that's the reason I don't just want to use Randy's DLL; I'd rather be in control of my own destiny when it comes to dependencies. For EECS, I also compiled all its dependencies myself in the project (including SDL*) because I could set options better and link them statically. It's not that big a deal.

Share this post


Link to post
Ladna said:

For EECS, I also compiled all its dependencies myself in the project (including SDL*) because I could set options better and link them statically. It's not that big a deal.

You mean the Windows executable?

Share this post


Link to post

Portmidi has worked fantastic in Odamex (thanks to a lot of tweaks by Dr. Sean when it comes to handling the midi data). It uses the windows midi synth, but NOT the windows mixer. What this means is that, unlike sdl_mixer, the midi volume can be controlled independently from the rest of the sounds on Vista/7/8.

Share this post


Link to post
printz said:

You mean the Windows executable?


Both Windows & Linux. On Windows, a lot of people don't like dozens of DLLs in the program folder (including me), and on Linux I didn't want to fuck around with library problems. "Hey my demo didn't load" ... days and days of debugging ... "oh my libarchive wasn't build with XZ support, lolz".

EECS has dependencies that EE doesn't: GnuTLS, libcurl, libarchive, etc. There are very few Linux distributions that keep up with current versions of all those dependencies, so rather than force users to fight with their package manager or distribution, I just statically linked everything. If small binary size is really important to a user, 99% of the time they're capable enough to compile EE themselves. If not they shouldn't be fucking around with it, and I certainly don't want to deal with their problems (of all support issues, compilation/installation are just the worst). In fact, my first suggestion to someone having trouble with EECS and who wasn't using the static distribution would be to use it, and see if the problem still happens.

I also had a cross-compilation system setup on a Linux machine to build for Windows. It was easier to script this way; whenever I wanted to release a new test build I just ran a script instead of firing up the XP VM, loading Code::Blocks (or whatever), updating SVN, loading the project, opening up WinSCP, blah blah blah.

===

Anyway, enough OT.

1. Gorilla Audio + PortMidi seems workable if the Windows MIDI sounds are acceptable (i.e., no one deeply wants to change the synth sounds).

2. SFML seems like it has audio support, but its MIDI support seems like it's through a 3rd party library called sfmidi, which uses FluidSynth. Dunno exactly what that means, do we still have to build FluidSynth? Does FluidSynth suck?

The other thing is that someone should figure out if there are stupid problems under Mac or Linux with either Gorilla or SFML.

Share this post


Link to post
Ladna said:

2. SFML seems like it has audio support, but its MIDI support seems like it's through a 3rd party library called sfmidi, which uses FluidSynth. Dunno exactly what that means, do we still have to build FluidSynth? Does FluidSynth suck?


I'm sure one could use PortMIDI with SFML.

FluidSynth doesn't suck, far from it. It's kinda CPU-intensive so it's better to have dual-core or better so that the FluidSynth thread doesn't harm game performances, and building all its thick jungle of dependencies is tedious on Windows; but other than these two issues there's no complaint to be had.

Share this post


Link to post
Gez said:

It's kinda CPU-intensive

Sounds wasteful, especially if other libs are not CPU intensive in comparison.

Share this post


Link to post
printz said:

Sounds wasteful, especially if other libs are not CPU intensive in comparison.



It's only an issue on single core CPUs and they are really getting old these days. But do you know how much CPU time the systems synth needs? I haven't measured it so it may also incur some performance loss on single core CPUs.

Share this post


Link to post

Don't forget that in some cases the "system synth" is hardware. Almost any computer where softsynth CPU usage is a problem has a hardware synth of some kind. I know even my business grade P2 laptop does and whether ZDoom uses it or a softsynth can be the difference between playable and not playable.

Edit: Speaking of which, I wonder if it's possible to separate ZDoom's midi code from FMOD? As far as I can tell it handles midi playback by itself.

Share this post


Link to post
Blzut3 said:

Don't forget that in some cases the "system synth" is hardware. Almost any computer where softsynth CPU usage is a problem has a hardware synth of some kind. I know even my business grade P2 laptop does.


I doubt that. I never had any hardware accelerated MIDI support since using onboard audio and that's more than 10 years ago - long before multi-core CPUs became common. The last sound hardware I had that could was an old Soundblaster that didn't even have wavetables.


Blzut3 said:

Edit: Speaking of which, I wonder if it's possible to separate ZDoom's midi code from FMOD? As far as I can tell it handles midi playback by itself.



None of the streaming code ever directly calls FMod. There's a handful of calls into the sound object to get some needed information, like sample rate, or opening a hardware stream. The rest is completely independent of the underlying sound information and should be portable to different engines with a little bit of work.

That includes all MIDI players that create sound data on their own, i.e. all except FMOD and the system player.

Share this post


Link to post

Looking forward to the "Officially had it with SFML" thread in a couple of years from now.

Share this post


Link to post
andrewj said:

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


Which is why midi has to use sdl_mixer in linux (unless it supports alsa hardware midi which would be a total relief; or even timidity++). Wouldn't recommend anything that has to do with OSS for linux since alsa is the primary sound engine (unless you could do both of course; personally like OSS myself over Alsa (besides the lack of a system-wide equalizer).

EDIT:
Just had the most dumb ass moment in my life's history with doom. After all these years I found out portmidi is supported with prboom and it is the best midi playback you can get bar none! No longer do I have to **&^! around with sdl_mixer's BS. It even supports hardware midi and doesn't need you to specify a port (it does all that automagically! Wow! And it's on linux and Prboom-plus to top it off (yes prboom-plus is the best one!11one'sszz)...

Share this post


Link to post

Hmm in terms of midi support, do you mean sdl plays the actual instruments / has its own synth, or do you just mean outputting the midi instructions?

If it's the former, I don't see why it is a requirement? People can just change their midi device in windows anyway, so that you can use a softsynth (like the free yamaha one) or BASSMIDI and use soundfonts or something.

So surely it is better to use a different library?

Or am i misunderstanding?


Another (related) question (that i don't know if anyone knows the answer):
Does the ECWolf source port use sdl then? Because for me the sound on that game pops and distorts lot and sounds quite bad.

Share this post


Link to post
notindeed said:

Does the ECWolf source port use sdl then? Because for me the sound on that game pops and distorts lot and sounds quite bad.

It does. There's another layer of complexity there though since half of the sounds in Wolf3D are FM synthesized. The digitized sounds are also in 7042Hz which I currently just linearly resample to 44.1kHz for SDL_mixer. (The lack of even a simple resampling algorithm is one of SDL_mixer's annoying flaws.)

Share this post


Link to post
Ladna said:

Isn't Windows MIDI what SDL mixer uses? I just fired up PrBoom+ and PortMidi sounds just like SDL mixer.


PortMidi can use any Windows or ALSA MIDI device you choose so it doesn't have to go through the Microsoft GM Synth if the user has a better alternative available. There is really nothing special about PortMidi itself - it's a much lower-level library for MIDI playback than SDL_Mixer. You have to parse MIDI files yourself and feed PortMidi the appropriate MIDI events in real-time.

The advantage that PortMidi offers over SDL_Mixer is that you can feed volume events to the MIDI device to adjust the overall volume of playback instead of SDL_Mixer's approach of calling midiOutSetVolume(), which unfortunatley causes digital audio volume to change as well.

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
×