ErikH2000 wrote:
I was hoping one of the guys that has built DROD more recently than me would pipe up. (Hint, hint 
) I'm sure to botch this.
Er .. I was going to reply to this, but then I forgot. Wops. In any case, I don't think you botched it.
Andy101 wrote:
I am using windows XP and am trying to compile using dev c++
Oh man. Dev-C++ uses mingw, doesn't it ? I don't think anyone tried building using cygwin/mingw yet. I've never used Dev-C++, so I have no idea how it works. Are you using the Linux makefile, the Visual C++ project files, or did you make your own Dev-C++ project ?
So, anyway, it looks like your winnt.h defines WCHAR to be a wchar_t for some reason, so unless we either don't include winnt.h anywhere (which I'm guessing isn't an option) or rename WCHAR to something else (gah), WCHAR
has to be wchar_t for you. This may actually work, but
only if wchar_t is 16-bit (ie 2 bytes). I'm pretty sure this is the case for mingw, actually, but try this just in case (and hope it outputs 2):
#include <stdio.h>
int main (int argc, char *argv[])
{
printf("sizeof(wchar_t) = %u\\n", sizeof(wchar_t));
return 0;
}
Assuming that went okay, we are, of course, back to your original problem:
Main.cpp In function `int SDL_main(int, char**)':
168 Main.cpp `wszDRODbranch' undeclared (first use this function)
I have no idea why this doesn't work. Check that:
1. Main.cpp #includes "
DRODLib/GameConstants.h"
2. DRODLib/GameConstants.h defines wszDRODbranch (should be "
static const WCHAR *wszDRODbranch = NULL;"
for JtRH).
Main.cpp In function `void GetAppPath(const char*, WSTRING&)':
1109 Main.cpp cannot convert `WCHAR*' to `CHAR*' for argument `2' to `DWORD GetModuleFileNameA(HINSTANCE__*, CHAR*, DWORD)'
I also don't know why this doesn't work. This is in the GetAppPath function, right ? Here's the relevant code for me (2.0.12):
#if defined(__linux__)
(...)
#elif (defined WIN32)
WCHAR wszPathBuffer[MAX_PATH+1];
if (GetModuleFileName(NULL, wszPathBuffer, MAX_PATH))
{
wstrAppPath = wszPathBuffer;
return;
}
else //On older versions of Windows, Unicode functions fail.
{
char szPathBuffer[MAX_PATH+1];
if (GetModuleFileNameA(NULL, szPathBuffer, MAX_PATH))
{
AsciiToUnicode(szPathBuffer, wstrAppPath);
return;
}
}
#elif defined(__APPLE__) || defined(__FreeBSD__)
(...)
#endif
(...)
As you can see the second argument to GetModuleFileNameA (szPathBuffer) is defined to be a char array at the line before the call, so how can the compiler think this is a WCHAR array ? Is your code different ?
On what I think is a totally unrelated note I found that I had to change everything of the form { {'F'},{'o'},{'n'},{'t'},{'s'},{0} } to { 'F','o','n','t','s',0 } in order for these sections of the code to compile.
Yes, this is a known problem. Unfortunately the extra braces are required when WCHAR is a composite type (which is the case in Linux builds). The We() macro was added to deal with this problem, but we didn't use it everywhere because it didn't seem to be required everywhere and using the We() macro results in strings being even uglier than they are already. For maximum compatibility, "
strings"
of that form should be changed to use the We() macro, like this:
{ We('F'),We('o'),We('n'),We('t'),We('s'),We(0) }
If you can list the places your compiler complained, I can update the source to use the We macro there.
- Gerry
[Last edited by trick at 01-07-2006 09:00 PM]
As a result I get a string of errors related to undefined references to functions of the form c4_... when linking.
. Using the latest source code I only had to make a few minor tweaks to the code to persuade it to compile. For some reason the static version of libjpeg that I have does not work so I had to compile with a dynamic version but apart from that the executable doesn't require any extra .dlls. I accidentally compiled with SDL 1.2.8 at first leading to DROD crashing when an orb was hit repeatedly, and presumably in other circumstances as well, but I can confirm that everything works fine with SDL 1.2.9.
