Rocks'n'Diamonds

I have been trying unsuccessfully to compile the Rocks and Diamonds source code for Windows 98 (or DOS). I am using (what I believe to be) the latest DJGPP compiler set (DJDEV203, GCC343B, GPP343B) with Allegro. I think I have everything as the errors I am getting are not related to missing header files. They are fairly basic compile time errors, such as duplicated case labels in a switch statement. Some of them I could try to fix myself (though I would prefer not to fiddle with the source at this stage) while others are more subtle and difficult to track down.
My question is - are there known compatibility issues between earlier and later versions of DJGPP that might account for these errors? If so which version should I be using and where do I get it? If not, what other reasons are there for compile errors and has anyone else had problems?

> My question is - are there known compatibility issues between earlier and later versions of
> DJGPP that might account for these errors?

I'm not sure about DJGPP itself, but there are indeed known compatibility problems between versions of Allegro! To be precise, compiling R'n'D with newer versions of Allegro does not work! (This could be fixed, but the DOS version of R'n'D is treated as a "legacy" version, so I don't put much work in it anymore.)

Using Allegro version 3.x should work (using 3.0 here), but version 4.x is known to fail.

> If so which version should I be using and where do I get it?

If it's really Allegro, try to get version 3.0, or if you have some programming knowledge, you might be able to get it to work with recent Allegro versions -- it's probably not that hard, it's just something I currently don't want to spend time on. Nevertheless, I would happily incorporate patches to get it working with the current Allegro version.

If it's Allegro and you can't find version 3.0 anywhere, I could send the needed files to you.

> If not, what other reasons are there for compile errors and has anyone else had problems?

BTW: It would be easier to guess if you had posted some of the compiling error messages here...

I compiled RnD with MinGw (devcpp) on windows.
Some type definitions not exists:
Eventfilter, Bitmap, Pixel aso...
located in file system.h
Compiling it with VC the same error occur.
And additional errors in "CONF_CHR.C" - What this? I see no variable, define or type definition in it. Is this a C source?
I use SDL1.2.8 and RnD3.1.1.
Can you give some help? maybe compiler options i should try.
How can i compile (and debug) RnD on Windows.

I've never tried to compile it under windows itself, but you need additionally at least the sdl_image, sdl_mixer, and sdl_net packages. (at least that's what I had to install for my cross-compile environment)

Of course i have a cross-compiler environment (minGW) and of course i have all the needed include and lib files.
For compiling it under minGW this site is helpful:
http://www.netadelica.com/coding/sdl/install.html

And I found the bug (poor windows)
There is the file sdl.h in RnD-directory. It includes the SDL.H
And windows have no case sensitivity in filenames, it's included himself.
Not so easy to guess right.
I renamed it to rndsdl.h and rename the include directives too.
And it works. I can compile it under windows, using the "eclipse-SDK" (very good IDE) and cygwin.
So please rename sdl.h to rndsdl.h (or ever you want) for the next release, please.

> There is the file sdl.h in RnD-directory. It includes the SDL.H
> And windows have no case sensitivity in filenames, it's included himself.
> Not so easy to guess right.

Nasty...

> I renamed it to rndsdl.h and rename the include directives too.
> And it works. I can compile it under windows, using the
> "eclipse-SDK" (very good IDE) and cygwin.
> So please rename sdl.h to rndsdl.h (or ever you want) for the next
> release, please.

I had a look at this, and the real bug was even different from what you found out (which also solves the problem): In "src/libgame/sdl.h", I included the file "SDL.h" by using

#include "SDL.h"

instead of

#include <SDL.h>

The first one looks into the current directory first, while the second (correct) one looks into the specified include directories first. When using <...> instead of "..." in sdl.h for the SDL include files, it should work fine.
(Else you would never know if there might be a system include file with the same name as an include file in your project, causing endless trouble.)

Please check if this solution also works for you!

Yes, this also works.
But you have luck...
you write in "sdl.h" #DEFINE SDL_H
in "SDL.H" there is written: #DEFINE _SDL_H
...or is that always like that? (is this a unix naming convention?)

btw: I forced the makefile to use PLATFORM=cross-win32 and I have to change posix_mkdir to call mkdir with two parameters (I think the cygwin environment need this). That's all.

> Yes, this also works.

Good to know -- thanks for testing this!

> But you have luck...
> you write in "sdl.h" #DEFINE SDL_H
> in "SDL.H" there is written: #DEFINE _SDL_H
> ...or is that always like that? (is this a unix naming convention?)

Well, sort of. Using C macros or other names with a leading underscore (like _FOO or _bar) is usually reserved for internal system definitions and should (usually) not be used in applications. Therefore, if using a notation like the above, there should be no collisions.

> btw: I forced the makefile to use PLATFORM=cross-win32 and I have to
> change posix_mkdir to call mkdir with two parameters (I think the cygwin
> environment need this). That's all.

Yes, using Cygwin, the code should nearly be the same as in the Unix version; things like "posix_mkdir()" are needed when using "native" Windows compilers and libraries...