Running an X (Xorg) server on your Raspberry Pi is frustrating. You can either use the fbdev or fbturbo driver which will give an un-accelerated 2D environment with swrast 3D (OpenGL) all beating your poor RPi’s CPU. Overclocking it will only help you so much which is a pity considering that there is another layer on the SoC that would be perfect for that but is now unused.
Enter the VideocoreIV (VC4) and Eric Anholt (formally of Intel, now of Broadcom), who are going to breath new life into the RPi. The idea is to offload the 2D rendering, via Glamor, to the VC4 with OpenGL calls. Since a OpenGL stack needs to exist, that means there will be a Direct Rendering Manager (DRM) Linux kernel module and Gallium/DRI module in Mesa.
This is happening now, here is the current status of support via the Piglit test-suite: skip 19102, fail 3866, pass 3146, crash 153, total 26267
Now that I’m a proud owner of a Raspberry Pi, I’ve being really stressing the little guy. There is only but so much a ARMv6 processor, on an microSD with only 512MiB of ram can do, which means that compiling on such a machine is going to take a really long time.
Take for example OpenMW, currently it takes about 4 minutes on a quad-core i7 to compile. You’re in for a treat on the Pi, it will take you at least a day, two days if you realize that half-way through the OOM Killer came through and killed your cc process. This is about the time you start wondering about various ways to improve the situation, such as a larger swap file or using zram.
At this point, I was wondering about other ways compiling binaries and packages for the Pi. There was cross-compiling, but then I would have to set up a full toolchain and recompile all the packages from scratch. That will have to be for another post though as it is another world. Another option is to try virtualizing the Pi and apparently QEMU gets us pretty darn close.
We’re still quite busy with developing 0.4 and thought it was best to backport our fixes into the 0.3 branch. As a result we ended up having an additional 2 releases in the 0.3 branch!
What’s new in this release
We’ve added DOS support in the form of SoundBlaster 16 playback in the player. The other big surprise is MIDI type-2 support, which came as a by-product of fully supporting XMI files like those from The Legend of Kyrandia. The rest of the changes are further enhancements to our build system and bug-fixes.
We have a brand new release on our 0.3 branch! The intent here is to be the bridge between the older 0.2 series and our feature rich 0.4 that is currently under development.
Source and binaries can be found on our github release page:
New and Old Developers
After a few months of development, we’ve really brought WildMIDI a long way. We are rejoined by Chris Ison (Wildcode) who had taken a small break away from development. Another developer has also joined us from uHexen2, Ozkan Sezer, who has contributed quite a lot to the project. Welcome guys! If you want to help out, just create a github account, fork us and send pull requests. Other forms of help are also appreciated, tracking down bugs and new platforms for us to support.
After several years of silence, There is now a new version of WildMIDI! Chris “Wildcode” Ison seems to have fallen off the planet around February of 2012 and the bug reports and patches have been accumulating on his SourceForge page. I decided to dump his SVN repository to github and continue hacking where he left off. We are still very much 100% API/ABI compatible and new versions can be considered drop-in replacements. We will continue to be open to developers that wish to improve WildMIDI but keep in mind that our goal is to be small and fast. We also wish Chris the very best and want very much for him to rejoin the project.
There have been a lot of changes since WildMIDI 0.2.3.5, mostly involving our new build system.