SDL_sound 2.0 | Hacker News Reader

SDL_sound 2.0

github.com

93 pointsingve21 comments

I love release notes like this. Tons of work done, care was taken to make sure it works well, made all the right decisions, and it's entirely drop in replaceable with less (zero) dependencies and fuss.

Just picked up an SDL-based game recently, might need to try this out now.

Not to confuse with SDL_mixer (which is to output sound to audio devices). This is a module for decoding sound files in various formats.

It's interesting that it's moved to single-file libraries for format support, because I think those libraries have effectively replaced it already. Having a single interface supporting multiple formats is a nice thing, though.

There are some disadvantages to these single header libraries, though they may very well be a non-issue for SDL_sound. As an example: I believe stb vorbis doesn’t support “gapless” playback that trims padded silence necessitated by lapped MDCT compression, and IIRC it also does not have sample-accurate fast seeking. This would make it challenging to implement loop points in streaming music using stb vorbis; even if you decode the entire stream into memory to get sample accurate seeking, you still need to compensate for the padded silence.

Truly depends on one’s use case and desired trade-offs.

The name “Icculus” stirs up memories. When I started coding, I used SDL, and the guys at Loki let me help as a volunteer beta tester. I got to test Mindrover and Descent III. I’ve still got hard copies of some of their ports including Sim City 3000.

Yes, that was back in the day I still used to subscribe to Linux Format, had an email signature with something M$ on it and still believed on the year of desktop Linux.

Also when Sam still tried to make a living out of selling SDL support without much luck.

Nowadays the only way to get studios to care is to port Windows binaris into Linux, despite Android, even Google is now creating their own flavour of Windows emulation for Stadia (not that will save Stadia anyway).

Sim City 3000 was ported to Linux ?

I didn't see it in Icculus' resume: https://icculus.org/resume

but it does look like there was a recent project to make it happen: https://github.com/juliogonzalez/sc3u-linux

Just visited Ballantyne, NC. I can see why boatloads are migrating down there ;)

Loki had ported Sim City 3000 Unlimited Edition to Linux and I’ve got it here.

Loki was awesome. I think one of their interns wrote one of the most prominent books on SDL to date. It was terrible learning the kid died from a cancerous mole shortly after. His blog ends on a sad note: http://overcode.yak.net/3

I had that book and talked to him once on IRC. I remember learning of his death. Very sad.

I love SDL. It is what free software should be about.

Hmm, embedded code copies.

Otherwise known as "vendoring". What's the problem?

The embedded copy is going to get out of date. It is better to depend on dependencies (its in the name) instead of vendoring them.

https://wiki.debian.org/EmbeddedCopies

And not pinning means risk of random API breakage and pinning means you're going to have to manually manage versions anyway. So nothing changes.

That is why you have continuous integration, so you can detect and fix breakage due to API change.

CI is only feasible if you make changes to the codebase often. And even then, it's a race condition between you detecting API breakage due to unpinned deps, and a user encountering them.

There's nothing wrong with pinning deps and vendoring them.

You can trigger CI in more ways than just codebase changes; daily/weekly/monthly, when dependencies change versions etc. Then you can know about issues immediately and fix the issues if they are easy to fix or update your dep version ranges if not, then fix the issues at your leisure.

Pinning and vendoring just lead to outdated deps with unfixed issues, especially security issues. Vendoring especially was why log4j had such a high impact, because there was no way to just update log4j and then restart affected services.

I think we will just have to agree to disagree on this.

I guess so. Dependency management isn't a solved problem. You can have all the CI in the world, green keeper, extensive package management toolchains and fancy dedupe/version constraint solvers and still run into pretty catastrophic issues with usability and security.

I don't think the log4j example is really relevant here. You can't compare all dependency-related issues to each other.

Reply on news.ycombinator.com