WildMIDI 0.4 is here with support for other formats!
WildMIDI 0.4 is released!
It has been two years in development and we’ve pushed WildMIDI 0.4 beyond just MIDI support, we’ve branched out into MIDI like files as well. We’ve worked together with other projects like GStreamer, OpenTESArena, XLEngine (DaggerXL), Thirdeye, ZDoom and more to ask what we can do to make their lives easier, as a result we now support rendering, streaming and playback of many older MIDI-like formats!
What’s new in this release
We’ve added support for KAR (MIDI with Karaoke) files, MIDI Type 2 and many MIDI-like formats such as HMI, HMP, MUS (Id) and XMI! We’ve also expanded our API in libwildmidi to support getting text/karaoke out of files, seeking songs in multi song MIDI Type 2, get errors instead of having a noisy library, setting conversion options, converting MIDI-like files into MIDI files and library now returns a buffer in the Endian format of the host.
Read more
New releases of WorldEngine, OpenMW and TESAnnwyn
WorldEngine 0.19 has been released! In case you’re wondering, WorldEngine is the combination of two projects: Lands and WorldSynth. The biggest gain in the merge is that we’re now two developers on the same wavelength and we’ve added plate tectonic simulations! As things have become more serious and complicated, we’ve had to write tests suites to cover our bases. We’re currently about 86% code coverage and the tests guarantee reproducibility which aids us in finding regressions. We’ve got many contributions, so having these in place are crucial for project stability.
What’s new in WorldEngine 0.19:
- Speed of generation increased by almost a factor of 3 (due to update to Platec and making heavy use of numpy).
- World-generation is now deterministic, i.e. generation is 100% reproducible.
- Added support for exporting heightmaps using libgdal (see http://www.gdal.org/formats_list.html for possible formats).
- Added the ability to modify temperature and humidity ranges as well as the temperature/precipitation curve.
- Added the ability to generate scatter plots showing temperature and humidity of all terrestrial cells.
- Added small variations to the temperature-map based on basic orbital parameters.
- Added a satellite-like view of the world.
- Added support to save/load worlds in/from HDF5-format.
Cross-compiling for Raspberry Pi on Ubuntu
While the Raspberry Pi 2 has four cores to churn through code, it still takes longer to compile than on most workstations and laptops. If you are feeling adventurous, you can try cross-compiling which has become easier to set up and get working.
Cross-compiling is when binaries created are for another target architecture than the one you are compiling on. This kind of set up is very typical when creating Android applications. The end result is that you can take the resulting binary and place on its target platform, and it will run there.
There are even tricks to getting the cross-compiled binary to also run on your native system!
In this guide, I’ll walk you through:
- Setting up a cross-compile toolchain in Ubuntu (15.04 Vivid)
- Setting up the proper exports
- Compiling a test program for your native and target armhf platform
- Compiling the latest Raspberry Pi 2 kernel with VC4 support.
VideocoreIV Glamor on your Raspberry Pi
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
Development on the Raspberry Pi
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.
