July 2009  ➟ Go back to June 2009. ➟ Proceed to August 2009. In these blog entries, you will find information on the things that I am currently working on. Whatever you read in recent entries does not necessarily describe things that are available for public download. The sole purpose of this blog is to inform you about the progress on development which will eventually - that is, in the future - result in an actual release of those features. Do not mistake this blog for a changelog.  2009-07-07 (Tuesday)  I am considering to use OpenTK instead of the Tao Framework in the future. Both are copyrighted software packages that provide bindings to OpenGL and OpenAL for use with .NET languages. OpenTK ships with an actual license text, while the Tao Framework does not. While I am not keen to obeying license terms and be subject to legal prosecution in case of failure, the license for OpenTK almost seems acceptable, except for one clause. Either way, the involved depencency jungle could be simplified with OpenTK. All that is needed is two .NET libraries which are portable without recompilation, plus an OpenGL-compatible graphics driver, plus OpenAL or OpenAL Soft libraries. The OpenTK libraries, as said above, might be distributable, while the others are platform-dependent anyway. An additional benefit of using OpenTK instead of the Tao Framework is 64-bit support, which is not currently offered by the Tao Framework on Windows. Before I finally decide on accepting or declining the license terms, I have made a feasibility study to evaluate how much work would be involved in porting the code base. I have already adapted the renderer and sound manager to most parts, which is tedious but quite straight-forward work, while all SDL-related things such as window creation, mouse and joystick support would have to be ported or rewritten. There basically is just one real problem that I see at the moment. OpenAL, or more specifically ALUT, has the annoying property of feeding stereo WAV sounds directly to OpenAL, which requires mono sounds to work correctly. So far, I have been using SDL to load stereo WAV sounds, converted them to mono via SDL, and then fed the raw data to OpenAL. There would be no point of using OpenTK if I couldn't mimick this behavior somehow. The only possibility I see at the moment would be writing my own WAV decoder, which is not entirely unfeasible for uncompressed sounds. As most existing routes and trains use stereo sounds, dropping support for them is out of question, thus this problem needs to be addressed and seems the only technical problem aside from the ideologic one.  2009-07-08 (Wednesday)  I don't even know why I considered surrendering to license terms. OpenTK allegedly incorporates material from other software made by big companies. Just proving that this material is in fact licensed under the terms the OpenTK development team claims would be impossible as I don't even know what this material is. I am not the one who plays these kinds of legal games, and I am definately not obeying terms that might not even apply just on a good faith basis. You wouldn't want to get chased by Novell or even Lucasfilm, would you? The only acceptable thing is and stays copyright-free or public domain material. There are still benefits involved in using OpenTK over Tao, but only if I can overcome the technical problems involved with stereo sounds. If I in fact make the switch from Tao to OpenTK in the future, possibly with openBVE 2, users would "only" be required to download a 5 MiB or so package to obtain the required libraries, which is much less compared to Tao.  2009-07-15 (Wednesday)  I have recently acquired a new homepage management software that is relatively similar to my own in that it essentially transforms a wiki-style markup language into a fully-fledged HTML page, but this software has proper support for CSS. I will eventually redesign the homepage to make it easier to read - which is especially a problem with the documentation at the moment. Similar in style to the recent forum update, the new homepage might look somewhat like this [1] [2] (very early work).  2009-07-23 (Thursday)  The sound subsystem is currently a bit of a problem as it uses ALUT for initialization and loading sounds. With OpenAL 1.1, ALUT became deprecated and is not supported on Mac OS X any longer, which is why Mac users cannot use sound at the moment. Getting rid of ALUT is twofold. The initialization of OpenAL is easily done manually, but loading sounds is not. I have written my own WAV parser for PCM sounds, including the capabilities of converting from any amount of channels to mono, and of converting from any sample rate to any sample rate. The latter is probably not required as OpenAL accepts any sample rate, not only the popular ones such as 11025, 22050 and 441000, for example. However, given that the hardware ultimately uses a specific sample rate, converting to the hardware sample rate might increase performance as runtime conversions are unnecessary. I haven't tested this yet, but ultimately, it is unessential. The problem is loading other sounds but WAV PCM. Via ALUT, any decoder that is installed on the machine seems to be available, meaning that OGG Vorbis, for example, could be officially supported in the future. I had already used OGG Vorbis early in openBVE's development to see if it was working. On Windows, only the codec needs to be installed, while I suppose that on Linux, is is available out of the box. On Mac OS X, I am not so sure, but I presume some decoder will be available for it as well. What is the problem is that the machine's installed codecs are only exposed via ALUT, which as initially said is deprecated and increasingly unsupported. Writing my own OGG Vorbis parser is likely out of the blue, so what remains is to either confine ourselves to uncompressed WAV PCM with cross-platform support, or to ALUT without. An interesting problem...  2009-07-27 (Monday)  I have finished my experiments with OpenTK and must conclude that its over-object-orientation makes things too complicated for me to work with. Therefore, I am sticking to the Tao Framework, which is probably better anyway as OpenTK has not reached its v1.0 status yet. As I spent the last week preparing openBVE 1.2, I neglected work on openBVE 2.0 for quite some time, but have resumed that now. As I had the time to rethink the API, I made some changes here and there, but still have not anything yet worth showing. I hope to have at least a working object viewer within the next days, followed by a working route viewer. One thing that is bothering me at the moment is related to the fact that I am using interfaces to implement the API both on the plugin side, as well as on the side of the host application. Given that all interface members must be implemented by an application that wants to make use of the interface, this approach does not seem to leave any space for future additions. Once a plugin is out implementing the original interface, any changes to the interface would render the plugin incompatible. It would be nice to have some input from a fellow .NET developer on how to resolve this.  Links  ➟ Go back to June 2009. ➟ Proceed to August 2009.