Loki only shipped CD’s for installing your application and there wasn’t hot fixes waiting when you got CD from post or yes there where but I had to wait and wait for 200 MB blob to download for ages with my 57600 modem. All the time I thought that I’ll boot Windows for playing Castle Wolfestein. It was long before before Linux have any gaming community what so ever. There weren’t Firefox or Chrome available and Google was just starting to own our lifes.  So it was dark days of late ’90 (we had electricity thanks for asking).

Loki was founded on 1998 and  it got on bankruptcy on 2001 after IT bubble blowed. Loki changed Linux in good way. One thing that they left behind was called Simple Direct Layer (SDL1). SDL layer sits top on Xorg that makes creating games more ease. You can port your game to Windows and Mac OS X with little effort. Current version of SDL is SDL2.

Good thing about SDL is that it abstracts drawing to screen in Windows, Mac OS X and X-windows. SDL1 was all about pixel buffers but SDL2 is all about surfaces and acceleration. It support many more OSes but that’s not the what we are looking at today. So how do you playing audio out of SDL1/2?. Good thing is audio interface stayed same through conversion from SDL1 to SDL2. They only added few bugs and float point audio in SDL2.  SDL1 have recording but I didn’t manage to make it work so if anyone with more patience than me can lead me to correct path I would be happy puppy. Here is SDL Github location: https://github.com/illuusio/linux-audio-example/tree/master/sdl

Simple Direct Layer API

Supported outputs: Alsa, Oss, Pulseaudio, Mac OS X, Windows, iOS, Android
License: SDL1 GNU Lesser General Public License 2.1 and SDL2 ZLib license

SDL API is like name says very simple and it’s very popular toolkit. SDL can be found on every bigger Linux distribution out of box (at least SDL1 and SDL2 is fast spreading). SDL can be used for graphics, input and audio. SDL API is actually almost dead simple. Support for audio outputs if very good on Linux and things are like if it’s working on Linux it works on Mac OS X and Windows the same.  Playing audio was so easy that I get frustrated when I tried to make recording example. I even read the source code how it should be done and yes It doesn’t work with SDL2 that what I learner but I couldn’t get it working in SDL1 nether.
SDL audio API is fully and only callback based. You give your callback function and it just get called when SDL feels audio should be played. After that you feed the correct type output as much callback asks and then you wait another callback to feed more. Simple and very efficient.
If you compare callback system to Pulseaudio with SDL you can’t get no information what ALSA, Pulseaudio or OSS is doing. You just feed and they just get played out of speakers. If audio is that what makes your game rock then SDL could be what you want.

SDL audio for whom.

It’s for people who don’t need much or don’t have interested how audio get played. People who likes to get audio out with ease and fast. Currently SDL development is under Steam umbrella so they have some commercial interest with it. SDL1 was licensed with LGPL+2.0 and SDL2 is under Zlib license which mostly same like than MIT-license. SDL is also mostly rock solid, sanely licensed (SDL2) and used by many many Indie (The UnReal World RPG if I have to mention one Indie game that I know well) and not so Indie games. Biggest problem with whole SDL is lack of documentation. There is wiki but if there is no question you crawler through web and test everything you find along if it solves your problem. Development is also little bit slow and fixing bugs are not getting fixed in fast but if you can live with that it’s all yours!

Summary: Very simple to get audio out of speaker. Not for high-end or surround sound but mostly for games or playing videos this is excellent! Learning curve is non exist or  there is small: you got to understand C well to work with SDL. Works with IOS and Android so if you are on cross platform this can help you out.

openSUSE situation

openSUSE 12.3 or 13.1 doesn’t have SDL2 from basic installation. openSUSE 13.2 and tubleweed are ok . So how to solve this without some ugly static compile hacks? One solutions is to make user fetch it from OBS and Games repository that have SDL2 for openSUSE 12.3 and 13.1.

zypper ar http://download.opensuse.org/repositories/games/openSUSE_12.3/games.repo
zypper ref
zypper install libSDL2

Or make them do it YaST. It’s rather easy and most of the people can do (if they have skills to install openSUSE).

Ubuntu situation

There is SDL2 for Ubuntu 13.10 and above. Problem is that Ubuntu policy is that two LTS should be supported. So in this time they are 12.04 and 14.04. Last one is no problem. SDL2 is installable with no hustle but Ubuntu 12.04, 12.10 or 13.04 are more problematic. Again problem solve by asking people to fetch stuff from other place that normal repository. Michael Imamura packs debs for 12.04 till 14.04 so you can make them get them there.

Debian situation

In Upcoming Debian 8 there is SDL2 packages but with Debian stable 7 you must use Wheezy-backports to achieve these.

Fedora situation

Fedora should be ok.

Arch situation

Arch is up-to-date distribution so you just start using.

I’m still wondering this static linking stuff. It has some good points. Time will tell when new release forms up!

Good, Bad and Ugly CURL

Curl is nice library for transferring anything from anywhere that have some kind of protocol over internet. It’s been stable for ages and have nice programming interface. So we thought this is easy new dependency for URW. We should know better.

User installed Ubuntu deb package and tried to launch URW in Arch received error  that was:

/usr/lib/libcurl.so.4: version `CURL_OPENSSL_3' not found

Ok very nice and constructive error message. What to do? This in the dark side of Linux knowledge. If you search from web what this means you will notice there is plenty of packages that suffers from this. mostly they are proprietary like URW and build to work with Ubuntu and don’t work with Arch. It has something to do with openSSL and how old it is but that is far I debugged it.

ARGH ARCH!

So I installed Arch Virtualbox and started to research on this. So how to find it there ‘CURL_OPENSSL_3‘ in libcurl.so.4 or not. use ‘strings’ command (now you should say, “elementary dear Watson”, so you you don’t look stupid).

strings /usr/lib/libcurl.so.4 | grep CURL_OPENSSL_3

And no there is nothing with that name but

strings /usr/lib/libcurl.so.4 | grep CURL_OPENSSL_

Gives a shot. There is ‘CURL_OPENSSL_4‘ so what to do? You can’t do nothing if you don’t get very hazardous. You can sed ‘CURL_OPENSSL_4‘  to ‘CURL_OPENSSL_3‘ but there is no promises it will work and it’s not very convenient.

You can get Ubuntu deb, extract curl.so out of it and use LD_LIBRARY_PATH-variable (how to do that?  or use OpenSUSE version of URW that works out-of-the-box.

Nor of them is very elegant. Probably we’ll have to start building Arch package also because that is most elegant version of this.

Emscripten in nutshell

Emscripten is stated in their Github page (which seems to be only place to reach this project) like this:

Emscripten is an LLVM-to-JavaScript compiler. It takes LLVM bitcode - which can be generated from C/C++, using llvm-gcc or clang, or any other language that can be converted into LLVM - and compiles that into JavaScript, which can be run on the web (or anywhere else JavaScript can run).

So in other words you can your existing C++ or C source code and compile it (with minor changes) to javascript pseudocode with LLVM back-end. I thought it can’t be working and started digging further.

How to test it on openSUSE

If you have openSUSE 12.3 or above you are good to go or you need to install LLVM 3.2 or above from OBS. You can do it with zypper like this:

zypper install llvm llvm-devel llvm-clang llvm-clang-devel git nodejs

Ain’t Clang just another C-compiler? So why not use GCC? Answer is LLVM is very flexible system (GCC is kinda married to C/C++. even there is many other backends) that turns code to Abstract syntax tree and then back-end compiles it to binary (which can anything from machine code to some of your favorite byte code like Java/C#). So in other words you have parser (clang) and you write back-end to generate code (javascript) quite easily (in theory). I think it was kind idea behind GCC in version 3.0 but as said it doesn’t work as seamlessly as it works in LLVM. Another strong point with LLVM is license. (L)GPL is fine license but if you have compiler you license should be as free as it gets.

So HOW TO TEST IT?

I haven’t got time to make rpm-package from Emscripten because I’m still learning by myself but I’ll share now what I have learned:

• Read documentation
• Read documentation
• Read documentation

Ok now you have read Emscripten documentation and you have clang, nodejs and git installed. Clone the Emscripten Git-repo

git clone https://github.com/kripken/emscripten.git

If you just want to test something you can follow this tutorial: http://sol.gfxile.net/emscripten/ so you get the idea. This how far I’ll take you this time. I’ll figure out some SDL examples to be ported (since UnReal World RPG uses SDL) in near future so stay tuned.