Screenhot of Mape showing the map of Krakatoa

Developers from Clonk Rage might remember Mape, an editor for dynamic landscapes described by a Landscape.txt file. The editor shows a live preview of the generated map while editing the Landscape.txt code, so that the engine does not need to be started to see the generated map.

Mape has been refurbished to work with OpenClonk, and it has been integrated into the OpenClonk source code, so that it is now officially part of OpenClonk. On the Development Snapshots page the current version can be downloaded including all dependencies for the Windows builds such that it runs straight out of the box. There is also a wiki page available which describes it in more detail.

Happy Mapping 🙂

The nightly builds and development snapshots have been unavailable for some time now. Partly they were obsolete due to the new autobuild system, however we lacked the option to obtain a snapshot of the current game state which runs out-of-the-box. This gap has been filled now by the revamped development snapshots. Instead of being only built once a week they now become available a few minutes after a developer makes a change to the game.

This means, that you can always playtest the current state of development without checking out the repository or building the engine yourself!

Also, check out the revamped archive for downloading old versions of the game.

I wonder whether it was by intention but it made my day. 🙂 Commit b6bec718c930:

C4Group::FindNextEntry only writes in the result buffer finding a file (#618)

Before “Initialize some uninitialized variables”, SCopy would do nothing because the StdStrBug still contained the parameter, but with that patch, it wrote the empty string into the result buffer.

Until recently the sources of the developer mode documentation have been in German. This was due to traditional reasons since the documentation is based on the Clonk Rage one which was only available in German for some time and which was later translated into English. However this made it quite hard for international folks to contribute since a German version had to be available before it could be translated into other languages (see bug #287). So after some initial work by Maikel I sat down this weekend with the goal in mind to turn around the situation: The main documentation sources should be in English which can then be translated into German (or other languages). The way the translation process works is that a tool called xml2po scans all XML files in docs/sdk/ which make up the documentation and creates so-called po files which contain all strings that need to be translated and their translation into a certain language. The po files are edited by human translators and, once finished, are eventually used to generate translated documentation XML.

The following steps were required (plus/minus some detail work):

1. Finish the English translation: When I started there were like 200 untranslated German strings in the documentation which I needed to translate. gtranslator is a nice tool to do the translation, except for the fact that it does not show where the string to translate originates from (i.e. from which XML file and line) — I had to look that up in the plain po file when I needed the information.
2. Write a script which reads the po file of the English translation, replaces the German content of all XML files with the English version and creates a po file which contains the translation from English into German. This started off as a quite nice and clear python program but then I added handling for an increasing number of special cases until it resulted in code I am certainly not proud of anymore… but well, it did it’s job in the end. Another thing I learned while doing this: It’s a good idea try to avoid mixing python strings and unicode objects; instead always use either one or the other — otherwise you get strange UnicodeDecodeError exceptions and whatnot all over the place… that’s why I normally prefer strongly typed programming languages.
3. Get rid of duplicate entries in the newly created de.po. There were quite a few cases where two different German strings translated to the same in English, especially in tables which list (English) identifiers that should remain untranslated since they refer to the name of a setting in a configuration file. I decided to mark them with a different tag in the XML (<literal_col> instead of <col>) which causes them not to show up in the translation.

Some of the strings to be translated contain XML fragments, for example for inserting placeholders or highlighting portions of the text. Quite a few of this XML was broken in the English translation. I wonder why this did not show up previously when building the documentation.

Now if you want to translate the documentation to German or even another language all you need to do is to edit docs/de.po with your favorite translation tool (which might be a simple text editor, the format of the file is pretty self-explanative). On Linux you can then easily regenerate the .po file (by scanning the XML files for new strings) and create the translated version by running make in docs/ (for Windows that’s a bit more complicated, but you can have a look at README.cygwin.txt which has instructions). This also converts the XML into HTML suitable for display by any web browser (for example Firefox cannot handle the XMLs directly for some reason). If you want to create a translation to a new language from scratch and need a po file to start with (or want it to be integrated into the make process without knowing how to do so) feel free to approach a developer in the forums or the chat. A word of warning though: Translating all the docs is a huge effort since it includes more than 4,000 strings. However it’s also perfectly fine to only translate parts of it as a start. Untranslated strings will remain in English.

Despite this work there is still quite some documentation tasks to be carried out. Newton gave a nice overview in the forums. Just now you don’t have an excuse anymore not to do it, my English speaking friends :). Additionally some of the code examples still contain German string literals or comments. Eventually they should be turned into English as well though I think most of the examples are understable already since they are accompanied by an explanative description. If you edit the documentation XMLs you can directly review your changes with Internet Explorer (not Firefox though).

Our Nightly Builds have recently gotten quite some overhaul. We now support builds for multiple architectures and with multiple compilers. In addition to 32 bit Windows builds we added 64 bit Windows builds built with both MinGW and MSVC (courtesy of Isilkor). Build status is now not only green (build worked) or red (build failed) but can also be some color in between indicating the number of warnings the build generated. Maybe this can motivate developers to get the build on their platform as green as possible? 🙂

It required some puzzling to set up the cross-compilation environment for 64-bit MinGW: Debian’s gcc-mingw32 package comes with a 64-bit C compiler, but does not include a C++ compiler (Debian bug). So I tried to compile the MinGW compiler myself I was not able to get working though. Instead I did what the reporter of the bug mentioned above suggested: I apt-get source‘d the gcc-mingw32 package, enabled C++ support in debian/rules and rebuilt the package, which worked nicely. Most OpenClonk dependencies offer 64bit binaries, others are available via the GNOME project. Only fmod and d3dx9 were problematic since they did not provide a 64 bit import library. However I was able to create corresponding import libraries from the DLLs with MinGW’s gendef and dlltool tools. I still wonder a bit why import libraries are needed at all if all information is available in the DLL anyway – I was thinking import libraries carry information that is not in the DLL and that’s why they are required for linking.

Loose plans for the future are to provide builds for other platforms such as Linux (maybe even as .rpms and/or .debs) and to provide the Windows development snapshots as an installer.

[caption id=”attachment_105″ align=”alignleft” width=”300″ caption=”Top row from left to right: Loriel, Sven2, Clonk-Karl, Zapper. Bottom row: Newton, Irina, Maikel, G

In case you want to cross compile the OpenClonk engine from Linux, this is how I made it work:

First, install the mingw32 cross compiler for your distribution. On Debian the package is called mingw32. Then, fetch the required dependencies. You can get libpng, jpeg, zlib, freetype and openssl from gnuwin32. Fetch the developer packages and unpack all to a deps/ subdirectory. glew binaries can be found on its hompage. I put these into a separate glew/ directory but it’s probably also fine to throw the files together with the others into deps/. fmod can be fetched from fmod.org. Again, I put it into a separate fmod/ directory.

Now comes the only somewhat tricky part: The d3dx library. MinGW has a library file for it, called libd3dx9d.a, but there are no header files. However, Wine ships them (in /usr/include/wine/windows/d3dx9*.h on my system). So copy all of them into d3dx9/include/ (or deps/include/ FWIW). Not all symbols used by OpenClonk are declared in Wine’s header files though, so I added the remaining ones required. Here is the resulting patch. There is one more problem though: MinGW’s libd3dx9d.a does not export the symbol D3DXCompileShader. I therefore used d3dx9.lib from the official DirectX SDK and put it into d3dx9/lib/. If you don’t have it already it’s quite annoying to obtain though: You have to download a multi-100MB installer just for that single library file. I think it should be possible however to create a working libd3dx9.a using Wine’s .def file, but I haven’t tried this.

OK, so once this is done we have all dependencies together. What remains to be done is to create a so-called toolchain file for cmake to tell it that we are not going to target the platform on which we are building. For that purpose, create a new file called toolchain-mingw32.cmake (or different, it does not matter) and add this content:

# the name of the target operating system
SET(CMAKE_SYSTEM_NAME Windows)
 
# which compilers to use for C and C++
SET(CMAKE_C_COMPILER i586-mingw32msvc-gcc)
SET(CMAKE_CXX_COMPILER i586-mingw32msvc-g++)
SET(CMAKE_RC_COMPILER i586-mingw32msvc-windres)
 
# here is the target environment located
SET(CMAKE_FIND_ROOT_PATH /usr/i586-mingw32msvc /home/ck/deps /home/ck/glew/glew-1.5.2 /home/ck/d3dx9 /home/ck/fmod/fmodapi375win/api)
 
# adjust the default behaviour of the FIND_XXX() commands:
# search headers and libraries in the target environment, search
# programs in the host environment
set(CMAKE_FIND_ROOT_PATH_MODE_PROGRAM NEVER)
set(CMAKE_FIND_ROOT_PATH_MODE_LIBRARY ONLY)
set(CMAKE_FIND_ROOT_PATH_MODE_INCLUDE ONLY)

Remember to adapt the paths to the dependency files as necessary. One final thing to do, if you have used separate directories for glew, fmod and d3dx9 is to add Symlinks to deps:

ln -s glew/glew-1.5.2/include/GL deps/include/GL
ln -s fmod/fmodapi375win/api/inc/*.h deps/include
ln -s d3dx9/include/*.h deps/include

I think this is only required because OpenClonk’s CMake script does not add the include paths of these libraries to the Compiler Flags (which it probably is supposed to do). Finally run

cmake -DCMAKE_TOOLCHAIN_FILE=~/toolchain-mingw32.cmake -DCMAKE_INSTALL_PREFIX=~/mingw-install
make

and have fun watching how the Code is compiled.

Zapper hasn’t yet, so let me inaugurate this blog. We, the OpenClonk team, continue the development of Clonk since matthes does no longer have time to steer the direction of the project. So since about 3/4 years many changes have already been implemented into the Clonk engine and much work has been performed overhauling the Game content. Since most graphics would have to be recreated due to the new Zoom functionality we took the opportunity and decided to redo the whole core objects pack, leading to a different GamePlay so that OpenClonk will not “just” be another iteration of the existing 2D titles but also be a bit different. Rest assured that the core principles such as controlling small human-like beings in hectic scenarios will stay, though :). For more information feel free to explore our Wiki and forums, which is also where most discussion takes place, along with #openclonk-dev on irc.euirc.net.

On a technical note, and to show what I have been working on, let me show what changing a sign and renormalizing a vector can do:

Before:

After:

The usual disclaimer for screenshots of software which is in heavy development applies of course: Everything is work in progress, so neither the clonk graphics nor the (pixelized) landscape graphics are final.