Note - both Avast! and CoMoDo will 'interfere' with your attempts to build Crimson Fields. Avast! can be set to 'exclude' the folders (& stop interfering), however CoMoDo can't & won't. Other anti-virus / firewall packages are likely to do the same. To build CF you may be forced to unplug your network cable (or disable your WiFi) and 'stop' your AV / firewall software
How can I build (& modify) Crimson Fields ?
You start by creating a 'build environment' and then by building the 'known working' (051) source code on Windows. Until you have achieved this there is no point in making modifications
A1. First you need a C 'compiler' capable of building the required Library and CF source code packages using the existing 'configuration' (batch command) file. I used the Open Source MinGW
PLEASE NOTE. You are about to enter the world of COMMAND LINE 'control'. NOTHING here is 'simple' - either read the MinGW 'Getting Stared' page - especially about 'no spaces' and Environment Variables - or spend days wondering why nothing seems to work as expected ... Note in particular that Error Messages are intended for Linux system admins (where the assumptions about folder and file structure differs from what you get in Windows)
Having downloaded the mingw-get-inst-20120426.exe to c:\temp (or similar), you should also download and read the mingw-get-inst-20120426.README.txt before continuing = it's only really readable using Notepad++, which is also what I use to edit the source code (later).
As usual with README files, much of the information is 'out of date' :-) The fact is, if you select 'latest catalogues' during install (see below) you don't actually have to manually 'update' later. Again, let me stress how 'user unfriendly' all this is ... you will need look for and read the README.txt and/or INSTALL files in every 'package' you download and work out what's vital and what's no longer relevant before proceeding with any attempt to 'compile' the package
On running mingw-get-inst-20120426.exe you should select 'download latest catalogue' and 'add' the c++ compiler & 'MinGW Developer Toolkit' components. Allow install to the default folder (c:\MinGW)
After install, you should find in Start, Programs, MinGW 'MinGW Shell' = this launches the Unix 'command prompt' (Bourne Shell command line interpreter)
A2. Next create a folder in root of c: for the various library & source code packages that will be needed = for example, 'cf051'.
Later (in the .\configure script or the config.log) you will see 'usr' is often shown as a path or folder. This means 'the current logged in users own personal folder (root)' (in Windows that would be 'My Documents') and NOT 'c:\usr\'. In other words, 'usr' is an 'Environment Variable' (equivalent to '%USR%' in a Windows script) - so even if you create an ACTUAL folder named 'usr', you will still end up tearing your hair out when faced with "error: usr - no such folder" :-)
What 'library' source do I need ?
Installing MinGW was the 'easy' part .... from here it gets (a lot) more difficult. Every individual SDL 'component' has a long and distinguished individual development 'history' and the current 'versions' are often incompatible with many (or all) older versions of many (or all) of the other 'component' Libraries - as well being incompatible with the actual CF source code
Later I found this list of required library modules (for Linux on i386). However the list is long and complex, and, I suspect, even harder to 'get right' (for MinGW on Windows) than collecting the 'top level' SDL library packages
After wasting weeks trying to 'make' (build the SDL Libraries & CF) with various different 'versions' and combinations of SDL, SDL_ttf, SDL_mixer & SDL_net etc. (each of which "configure'd" differently and each combination of which resulted in different 'errors' - such as 'zlib... no', 'unknown type' and 'undefined reference' and NONE of which stated what versions of the rest of the 'set' they had ever been 'tested' with (none, at a guess), I concluded that the ONLY way to find a 'compatible' set of Libraries was by 'trial and error'
This is why most of the rest of this page is a story of searching for, and trying to build with, various ancient versions of SDL component source code until I eventually stumbled across a 'set' that 'worked together' well enough to (mostly) support a Crimson Fields source build
Stand-alone component development forcing 'trial & error' builds explains why Linux will never be anything but an enthusiasts 'toy' .... you can read about some of my attempts to build a 'compatible' set of SDL library components below (and weep ....)
A common Error is 'missing file' = so where does mingw 'look' for library files ?
As with anything *nix, 'it depends' :-
When compiling 'c' source code (eg 'file.c'), the gcc compiler will look in :- c:/mingw/include/*.h and C:/mingw/lib/gcc/mingw32/4.6.2/include/*.h for the #include *.h files When compiling 'c++' source code (eg 'file.cpp'), the g++ compiler will look in:- c:/mingw/include/c++/4.6.2/*.h, c:/mingw/include/c++/4.6.2/mingw32/*.h, c:/mingw/include/c++/4.6.2/backward/*.h, c:/mingw/include/*.h and c:/mingw/lib/gcc/mingw32/4.6.2/include/*.h for the #include *.h files
It goes without saying that the compiler will look in '.' i.e. the 'current' folder first (so, for example, when compiling 'myfile.c' if "#include header.h" is encountered, the compiler will first check the folder in which 'myfile.c' resides for 'header.h' before looking in any of the mingw library folders)
To add additional library 'paths', the compiler (gcc) should be 'invoked' with appropriate 'I DIR' (for the #Include *.h) and '-L DIR' (for the *.o components) options
The ONLY way to avoid massive confusion is to 'configure' each of the packages so they compile EVERYTHING into THE SAME folder ('/mingw'), as described below
What Library package versions are needed to compile CF ?
1) First, you have to start with 'known working' components - and the (only ?) known working Windows build is "crimson-051-win32.exe".
I thus decided to focus on building with the 0.5.1 source code, and having achieved this (see at end), I was then able to build 0.5.3 (after making the same modification to fileio.cpp - i.e. inserting the line "#define _WIN32_IE 0x0400" after "#ifdef WIN32" - see later)
Unfortunately, the 'Download' web page on the author's site only offers the 'current' version of Crimson Fields source code (= crimson-0.5.3.tar.gz). Fortunately, the previous versions still exist, but can only be accessed by 'direct' links e.g. crimson-0.5.1.tar.gz Whist you are at it, you should also download crimson-0.5.2.tar.gz and the current 0.5.3 - these will be useful as 'guides' on how to modify the code (I also grabbed 0.4.8, 0.4.9, 0.5.0 hoping they would 'fail to build' in different ways and thus give me some clues on what was wrong)
In case the author removes the older versions, you can also find crimson-0.5.1 source at 'findthatzip'.
NB. The author seems to have had a fatal hard drive crash in the recent past that wiped out both the Forum and his archives. To avoid this happening to you, read my web pages on Data preservation (RAID and backing-up)
2) Next you need to find the 'correct' version of the main SDL component. If you install the Windows executable of CF you will discover that c:\Program Files\crimson.exe has a creation date of 1 Jan 2007. If you 'unpack' the crimson-0.5.1.tar.gz source you find the same date, 1 Jan 2007 (version 0.5.2 source has a date of 13 Dec 2007).
Going to the SDL repositories we find that the 'archive' was apparently 'reset' on 21-Jan-2007 (since every version of SDL from 1.0.0-1 to 1.2.11 has that same date). However 1.2.12 was released in July 2007, so the version we want must be earlier than this, i.e. 1.2.11 or perhaps 1.2.10. Since crimson 'source' INSTALL file states that 'SDL 1.1.15 or later', we can assume that SDL-1.2.10.tar.gz will be 'OK'
In fact, the Windows executable could have been built with any version of SDL between 1.1.15 and 1.2.10 = we just don't know. All we can do is try 1.2.10 and if that fails, go back version by version until we reach 1.1.15 (or forward toward v1.2.15) to find one that 'works'
On my Windows XP computer, whilst 'Checking for dependencies ...', SDL-1.2.10 'configure' generates 5 'sh.exe Application Error' alerts, all of the type 'The Instruction at .... referenced memory at0x000000. The memory could not be read. Click OK to terminate'. I don't get this with the other components, so I dropped 1.2.10.
So I then went straight to the 'latest stable' version, 1.2.15. However the "SDL-devel-1.2.15-mingw32" package lacks the 'configure' script (so can't be installed at all :-) ) and the 1.2.15.tar.gz package 'configure' no longer supports the --prefix option (so it can't 'make install' into the mingw Library folder) = instead it claims 'Libraries have been installed to /usr/local/lib" but actually installs them to C:\MinGW\msys\1.0\local\lib !
In the LINUX/UNIX 'world' you are assumed to 'know' that 'usr' is a 'variable' :-) = typically it is the path to the (root) folder that you, the user, are (assumed to be) operating from (so how I managed to get the SDL libraries placed into c:\mingw\mysys when I was operating from c:\cf051\SDL-1.2.15 is anyone's guess) NB. You are also supposed to know that the UNIX world uses '/' as the path separator and windows uses '\'. Needless to say, get it wrong when defining paths and you will run into all sorts of 'unknown' errors :-)
I then went back to the SDL change log but was unable to discover when the --prefix option was removed. Since 1.2.11 & 12 & 13 are all stated as a 'minor bug release' (as opposed to the 1.2.14 'major') I decided to try SDL-1.2.13. Since it's 'configure' accepted the '--prefix=/mingw' option I decided to stick with 1.2.13
NB. SDL does not natively support 'Direct Draw' etc. (DirectX). For more information, see here
3) Having chosen SDL 1.2.13, we now need compatible (with Crimson 0.5.1 source) versions of SDL_ttf and FreeType2 ... and once again I had to 'guess' by date (any version prior to Jan 2007 should be 'OK')
At the SDL_ttf repository we find version 2.0.8 should be the one we need (2.0.9 wasn't released until July 2007). Again this can only be downloaded using a direct link (SDL_ttf-2.0.8.tar.gz) since the web page only offers the latest version.
After hours of trying to 'make' SDL_ttf 2.0.8, I eventually just 'gave up', went back and downloaded SDL_ttf-2.0.11 source. This 'worked' first time, however I then ran into 2 problems trying to 'make' Crimson Fields (see at end). Unfortunately I have no idea if these problems could have been avoided with SDL_ttf 2.0.8 (or, more likely, not).
At the FreeType repository we discover freetype-2.2.1.tar.gz, released on 13-5-2006, is the one we need (v2.3.0 was released on 17-Jan-2007, 'too late' for a 1-Jan-2007 build)
4) You need the SDL 'mixer' (for sound) and 'net' (for LAN gaming) libraries. Why ? because we don't know if the Windows version of Crimson Fields has ever been successfully built without these (and we don't want to waste even more time trying to sort out 'undefined links' etc.)
4(i) At the SDL_mixer repository we find release 1.2.7 is the one we need (1.2.8 wasn't released until July 2007). The version you need is not offered on the 'download' web page but can be addressed directly at SDL_mixer-1.2.7.tar.gz source 4(ii) At the SDL_net repository we find that release 1.2.6 is the one we want (this is also mentioned in Crimson 0.5.1 INSTALL file). Again this has to be downloaded by 'direct' link at SDL_net-1.2.6.tar.gz source
How to build the Library files ?
WARNING - Avast! will screw up the build of the freetype components by insisting that the (freetype-2.2.1) 'apinames.exe' is 'malware' ('marking' it as a 'false positive' has no effect - Avast! will still 'kill' any new build). To 'recover' you will have to add c:\cf051\* and c:\mingw\* as 'Exclusions' paths in Avast!, then delete the 'freetype' folder and re-build from the original tar.gz
When building, the 'configure' script overwrites (or not) the 'make' script to avoid 'unnecessary work'. Unfortunately, the scrip is not clever enough to discover thatb the file has disappeared due to the intervention of Avast! - so the only way to ensure all files are correctly 'built' (after an Avast! intervention) is to wipe the whole folder and start again from the tar.gz files
1) Start by launching the MinGW Shell ($ command prompt) and 'unpacking' each of the source code packages to it's own folder.
$ cd c:
$ cd cf051
$ tar -xzvf SDL-1.2.13.tar.gz
$ tar -xzvf SDL_mixer-1.2.7.tar.gz
$ tar -xzvf SDL_net-1.2.6.tar.gz
$ tar -xzvf freetype-2.2.1.tar.gz
$ tar -xzvf SDL_ttf-2.0.11.tar.gz
$ tar -xzvf crimson-0.5.1.tar.gz
2) Next, we have to build and install each of the Libraries IN ORDER = SDL itself, then SDL_mixer & SDL_net, then 'freetype' & finally SDL_ttf.
Each component uses parts that have 'gone before' and you should NOT rely on the 'configure' scripts to check that everything is 'in place' = it's entirely possible to successfully install the SDL libraries without the _mixer or _net components .. or (attempt) to make SDL_ttf without freetype - and then wonder why Crimson itself 'falls over' with 'undefined links'
SDL
Before proceeding, you should check out the \SDL-1.2.13\INSTALL file. This will direct you to the web page "http://www.libsdl.org/faq.php?action=listentries&category=4#42" (which, of course, no longer exists :-) ). I suggest you check out the Windows FAQ instead
Note. Using 'prefix=/mingw' instructs 'configure' to set up the make and install so that the install is loaded into the c:/mingw folder, i.e. the default library folder for MinGW
$ cd SDL-1.2.13
$ ./configure --prefix=/mingw
$ make
$ make install
$ cd ..
There is a 'long pause' at the end of 'make install' before you are returned to the command prompt ($) & can return to the root (cf051) folder using the 'cd ..' command. You just have to be patient
If all goes OK, you should see -
Libraries have been installed in:-
/mingw/lib
about half way into make install
SDL_mixer and SDL_net
Crimson 'install' file suggests that crimson source can be 'built' without sound or network support. When I tried this, the 'make' failed with multiple 'missing functions' and 'undefined parameters' - all of which where sound / network related.
I didn't bother wasting my time 'debugging' Crimson's configure '--disable-sound' / '-disable--network' options (and suggest you don't either). Just install SDL_mixer & net now & all will be well later
The _mixer and _net both require SDL be installed first = you will get 'error: *** SDL version 1.2.10 not found!' if you try to build without SDL ... although, with SDL_mixer, this only occurs at line 19,519 in the configure script (I know, because I had to wade through it to find out what was going wrong on multiple occasions :-) )
NOTE - CF uses MIDI to play 'background' music (and .wav for it's sound effects). Of course you will already know this and thus be aware that you need the MIDI support package (timidity - see below). If you want to add support for .mp3 you will have to find & install the mp3 libraries (SMPEG for mp3 (ver 0.4.3 or later)) BEFORE building SDL_mixer - otherwise you have to stick to MIDI and the natively supported 'Org Vorbis' for any new music you want to add later
In SDL_mixer-1.2.7 you will find a README that includes the note :-
"To play MIDI files, you'll need to get a complete set of GUS patches from:
http://www.libsdl.org/projects/mixer/timidity/timidity.tar.gz and unpack them in /usr/local/lib under UNIX, and C:\ under Win32."
For MIDI support, download and unpack the timidity.tar.gz package before attempting to build SDL_mixer. Note that MinGW 'counts' as 'unix' and that 'usr/local/lib' MEANS c:\cf051\SDL_mixer-1.2.7\lib\
After unpacking the timidity and SDL_mixer-1.2.7 tar.gz to SDL_mixer-1.2.7 in Windows using 7-zip, you can compile in MinGW as follows :-
$ cd SDL_mixer-1.2.7
$ ./configure --prefix=/mingw
$ make
$ make install
$ cd ..
If all goes OK, you should see :-
'Libraries have been installed in:
/mingw/lib
about half way into make install
The README in /SDL_net-1.2.6 mentions the sample / test ('chat') harness however this can be ignored and you can go straight into the build
$ cd SDL_net-1.2.6
$ ./configure --prefix=/mingw
$ cd ..
SDL_net configure script will show "WARNING: *** 'Can't find GUI Library - not building test programs" & "The GUI library can be found at: www.libsdl.org/projects/GUILib". This can be ignored.
$ make
$ make install
$ cd ..
If all goes OK, you should see :-
'Libraries have been installed in:
/mingw/lib
about half way into make install
Build the SDL 'test' files
$ cd SDL-1.2.13
$ cd test
$ ./configure
$ make
$ cd ..
$ cd ..
Needless to say, for the 'test' build, you will not get a 'success' (or 'fail') result at the end = you have to scroll back up and check each of the gcc commands to ensure no errors are reported
freetype
Freetype has to be installed before SDL_ttf
After wading through 3 or 4 README / INSTALL files you will discover that the 'standard' configure/make/install process will work OK
Note configure will report 'platform unix' - that is correct, the MinGW command prompt emulates a Unix environment
$ cd freetype-2.2.1
$ ./configure --prefix=/mingw
If configure is successful, you should see "make: Nothing to be done for 'unix'". What this MEANS is, the 'make' configuration file does not need to be changed, however you do still need to run the actual 'make' & 'make install' commands (below)
$ make
WARNING If, toward the end of make, Avast! aborts the sequence (by snatching the 'apinames.exe' file to 'quarantine' as 'malware'), you MUST delete both the cf051/freetype and mingw/freetype folders (and stop Avast! doing it again by making c:/cf051 and c:/mingw folders as 'exceptions' in Real Time Shields, File System Shield, 'Expert Settings' button, Exclusions) before starting again by unpacking the original freetype-2.2.1.tar.gz
Even if all seems OK, toward the end of make (half way through libtool run) I got one 'Warning: Undefined symbol not allowed ..', however this does not seem to be 'fatal' (since I ignored it and carried on and 'everything' seemed to run OK)
$ make install
$ cd ..
If all goes OK, you should see :-
'Libraries have been installed in:
/mingw/lib
about half way into make install
SDL_ttf
The SDL_ttf README simply warns you to install Freetype2 first = unfortunately, it fails to say exactly 'where', but we already know to put our library code at /mingw. So, after we configure, make and make install freetype (see above), only then can we proceed to SDL_ttf.
Note, however, I have been totally unable to 'make' with SDL_ttf-2.0.8. After hours of trying, I went straight to 2.0.11. This worked fine 'first time'.
The 'problem' with SDL_ttf 2.0.8 is that SDL_ttf.c (in C:\cf051\SDL_ttf-2.0.8\) expects to find ftobs.h in the folder .\freetype\internal.In fact, ftobs.h is found in C:\cf051\freetype-2.2.1\include\freetype\internal. No amount of playing around with the --with-freetype -prefix or -exec-prefix parameters will 'solve' this issue (using Windows to grab a copy of C:\cf051\freetype-2.2.1\include\* and place that at C:\cf051\SDL_ttf-2.0.8\ before using configure just results in a stream of 'undefined # in ftobs.h' errors later in make). Just switch to 2.0.11 and all this nonsense disappears
So in MinGW :-
$ cd SDL_ttf-2.0.11
$ ./configure --prefix=/mingw
$ make
$ make install
$ cd ..
If all goes OK, you should see :-
'Libraries have been installed in:
/mingw/lib
about half way into make install
What else needs to be done to build Crimson Fields ?
You should ONLY try building the Crimson Fields source after all the Libraries successfully build and install correctly "in place" (to /mingw/lib)
Crimson's README is just a bit of useless 'advertising', however you should read the INSTALL file - it tells you how to 'enable' the build of the tools (cfed, comet and bi2cf) - this is best done AFTER you achieve success with the basic Crimson Fields 0.5.1 source alone
$ cd crimson-0.5.1
$ ./configure --prefix=c:/cf051/build051
$ make
'make' fails with "In file included from player.h:26 .... from ai.cpp:38 .....
../../src/common/fileio.h:73:3 error: 'HANDLE' does not name a type ..." etc.
The problem highlighted in fileio.h is with the Class definition of 'Directory'. The Class definition depends on the build environment (#ifdef WIN32 ...). Unable to 'work out' what was wrong, I compared crimson-0.5.1 fileio.h with the version in crimson-0.5.3 .. since they differ, I copied 0.5.3 fileio.h to replace the version in 0.5.1 and 'bingo' the 'make' ran past that error
In windows, unpack crimson-0.5.3.tar.gz, locate 'fileio.h' and 'fileio.cpp' and copy these to c:\cf051\crimson-0.5.1\src\common\
Then return to mingw shell and :-
$ make
'make' fails with "fileio.cpp:396:59: error: 'SHGetSpecialFolderPath" was not defined in this scope'.
Once again I compared the various versions of crimson 0.5.x source. This time I found that the call to 'SHGetSpecialFolderPath' only appears in fileio.cpp for crimson source v0.5.1, .2 and .3. It is not present in 0.5.0 (or earlier), however 'going backward' is never a 'good idea', so I investigated the function being called instead and found that it does not appear in any crimson source file, so must be a 'library' function ! Searching c:\mingw we find the call is defined in C:\MinGW\include\shlobj.h - where it is set to SHGetSpecialFolderPathW if Unicode, else SHGetSpecialFolderPath. Both these are WINAPI function calls - so the ACTUAL error is 'Missing WINAPI'
Researching on the internet we discover that to enable win32 API function calls, the variable '_WIN32_IE' has to be defined and set - and it's not anywhere to be found ! As a 'quick fix', I modified the contents of the file c:\cf051\crimson-0.5.1\src\common\fileio.cpp by inserting the line '#define _WIN32_IE 0x0400' immediately after the line '#ifdef WIN32'. Return to MinGW, the 'make' then ran without problems :-
$ make
$ make install
If all goes well you will find 'crimson.exe' in c:\cf051\build051\bin !!
How do I run my newly built crimson.exe ?
If you attempt to 'run' crimson.exe by double clicking on it in Windows, if you are quick enough you might see it's 'splash page' open & immediately close. If you then examine the contents of the \build051\bin folder you will find a 'stderr.txt' file has been created that contains "Error: Couldn't load language resources for language 'en'". Whilst you might think the build has failed, the 'problem' is the usual UNIX habit of 'building' things into folders where they can't be found by other things, so the whole lot fails
In order to 'run' your newly built crimson.exe, you have to move it to the \build051\share\crimson\ folder :-)
To run crimson.exe on another computer (that has never had any version of crimson.exe installed on it) you will need to include the SDL library 'dll' files (SDL.dll, SDL_mixer.dll, SDL_net.dll and SDL_ttf.dll)
You may note that the just 'made' crimson.exe is about 3.6 Mb, whilst the crimson.exe (included in the crimson-051-win32.exe installer) is about 90% smaller (at 392kb) !
This suggests that my build 'process' (above) includes a lot of unnecessary Library code - however since it took me so long to get it to 'build' without error, I haven't bothered to look any closer
What about the CoMET (map editor) and cfed (the map source to play level converter) ?
Just add '--enable-comet' & '--enable-cfed' to the './configure --prefix=c:/cf051/build051' command before 'making' the Crimson 0.5.x. If all is OK, comet.exe, cfed.exe & bi2cf.exe will be found in the '/bin' folder
$ cd crimson-0.5.1
$ ./configure --prefix=c:/cf051/build051 --enable-comet --enable-cfed
$ make
As usual, the .exe has to be moved from the folder where it was built to the 'correct' folder before it will run
CoMET has to be run from a folder containing the .tiles and .units definition files and will ONLY look in the ./levels sub-folder for .lev 'maps' to edit (it will both 'save' a .lev and 'export' a .src to the ./levels sub-folder). CoMET can only open .lev input files. Yet the only way to (easy) way to change the text (narrative, objectives setting etc) is to hand edit the .src. So, you have to 'compile' the .src into a .lev using the cfed.exe
cfed requires access to the (default).tiles and (default).units definition files. The 'easy' way is to place copiers of these in the same folder where you intend to run cfed. To 'compile' mymap.src into mymap.lev :-
cfed mymap.src --units default.units --tiles default.tiles
Needless to say, both default.units and default.tiles are complied versions of the text based Units and Tiles definition files and .bmp Icon files (see later)
What about bi2cf (Battle Isle map converter) ?
As above, you just add '--enable-bi2cf' to the ./configure
For those wanting to convert the Battle Isle maps themselves, but wishing to avoid the pain of recompiling the entire source, you can download bi2cf.exe here
My understanding is that the BI maps original files are still under 'copyright' restrictions, so I can't host them. However I see no reason why I shouldn't host the 'equivalent' versions of those maps built with CF's terrain tiles and unit icons
So, for those in a hurry, here are the converted sets that should play fine with crimson.exe 0.5.1 - 0.5.3 (I have checked the terrain, however I've not checked any of the play function at all) :- BI levels.zip, BI-dd1 levels.zip, BI-dd2 levels.zip Note that I am working on the creating a set of 'double sized' maps equivalent to the Battle Isle maps but with different narrative (text) and play ('event') functionality = see my 'Crimson-0.6.0' page (later).
What's with 'compression' (zlib) ?
Apparently Crimson Fields code uses 'zlib' (a derivative of gzip) compression. However, in a standard build 'with compression', the 'default.units' and 'default.tiles' components appear to be equal in size to the sum of the 'raw' .bmp and control parameter files i.e. default.units = CFunits.bmp + default.usrc + u_(thumbnails).bmp's and default.tiles = CFTiles.bmp + default.tsrc
Further, running configure with the '--without-zlib' option has no effect on the size of the default.units & default.tiles files. Since the crimson.exe is also exactly the same size, I assume that compression is not used within crimson.exe itself (not that this means you can't get a 'missing zlib' error if you mess up the library build)
At a guess, compression is only used with the .lev map files - however these are so small (a few kb's each) that I really haven't noticed any difference. It's also possible compression is needed by bi2cf to 'unpack' the BI map files. Being a great believer in the "if it's not broken don't fix it" approach, I have left zlib 'in'
What about crimson-0.5.2 & 0.5.3 ?
These can both be built successfully after modifying the fileio.cpp file (as detailed above, for 0.5.1)
What about new maps ?
Whilst the configure & build scripts are quite 'clever' (some are 10,000+ lines), making changes (so that, for example, all the maps in \levels\*.src are built) can be a real pain. The simplest approach is to just run 'cfed.exe' manually for each new map after the make; make install process
Whilst this is fine if you only want to build one or two new maps, it can be a real pain if you want to build the (almost 100) Battle Isle maps. The easiest approach is to create a Windows command file (.cmd) to 'post-process' the /levels 'source' folder after building the latest crimson.exe. Since Windows .cmd scripts are hopeless at processing text, you might want to adopt my approach of using a cmd file to 'call' a QBasic script to perform any 'complex text' pre-processing (such as swapping tile codes or changing unit names) required Note that the map source (.src) files contain UNIX style line breaks (line feed = 0x0A) which need to be replaced with Windows style (carriage return + line feed = 0x0D0A) before they can be processed using QBasic scripts (if you don't, QBasic will give you 'Out of string space' errors when "Line Input'ing" the map .src file) NB. Replacing the line endings with the DOS/Win style CR/LF can be achieved by opening the map file in Wordpad and using 'save as' = 'text files' (as suggested by Gregg, another Crimson user !).