IMPORTANT: TIME TO DECIDE

[erin]

Yes, that's freetype, the headers can't be found.

Code: Select all

ft_font.h:19:10: #include expects "FILENAME" or <FILENAME>
ft_font.h:20:10: #include expects "FILENAME" or <FILENAME>
ft_font.h:21:10: #include expects "FILENAME" or <FILENAME>
ft_font.h:22:10: #include expects "FILENAME" or <FILENAME>

The missed filenames are declared in the freetype header, and this error implicates all the other errors.

I don't know how to solve it since I don't know how mingw works.
Does mingw emulate the unix file structure? If not, where must the libraries and includes be placed on Windows? Perhaps it's possible to set another path to the headers instead of -I/usr/include/freetype2.

BTW: It's time for me to get familiar with mingw to keep the code in a compilable state.

[erin]

It's a lot simpler than the font library. I only suggested it because it is incredibly simple to both use and depend upon.

So I will download and try the code. Thank you for the hint. You seem to have already experiences with that.

[cpicon92]

I don't know how to solve it since I don't know how mingw works.
Does mingw emulate the unix file structure? If not, where must the libraries and includes be placed on Windows? Perhaps it's possible to set another path to the headers instead of -I/usr/include/freetype2.
BTW: It's time for me to get familiar with mingw to keep the code in a compilable state.

I'd like to get it to compile first, then I can write a whole guide on compiling it with Mingw and Msys, it will save you a lot of time seeing as I've been using mingw since the original ETR release. The path for freetype should be the same on Windows as on unix because mingw has a folder called /usr/include/freetype2, I think I accidentally compiled the unix version of freetype from source and this is the result. I'm going to start over on my Desktop instead of my Laptop, where I haven't messed anything up yet.

EDIT:
I figured out the freetype problem. It turns out that the simulated usr directory is contained in the msys include folder, not the mingw one, it was just a matter of copying and pasting the freetype includes from one to the other. The number of compile errors is very short now:

Code: Select all

g++ -c main.cpp -Wall -O2 -I/usr/include/freetype2
main.cpp: In function `int SDL_main(int, char**)':
main.cpp:340: warning: control reaches end of non-void function
g++ -c ogl.cpp -Wall -O2 -I/usr/include/freetype2
ogl.cpp: In function `void InitGLExtensions()':
ogl.cpp:19: error: `wglGetProcAddress' was not declared in this scope
make: *** [ogl.o] Error 1


[EFU]

Did you forget to [#include <windows.h>] - that line is needed somewhere at the top of the main header file (e.g. bh.h) - it may help with wgl; obviously, it's only for Windows-es, so it can be something like this:

Code: Select all

#ifdef WINDOWS //or #ifdef WIN32 or something...
#include <windows.h>
#endif


[cpicon92]

after including windows.h:

Code: Select all

g++ -c main.cpp -Wall -O2 -I/usr/include/freetype2
main.cpp: In function `int SDL_main(int, char**)':
main.cpp:340: warning: control reaches end of non-void function
g++ -c ogl.cpp -Wall -O2 -I/usr/include/freetype2
ogl.cpp: In function `void SetViewport(int, int)':
ogl.cpp:49: error: expected unqualified-id before '=' token
ogl.cpp:50: error: expected unqualified-id before '=' token
ogl.cpp:56: error: expected primary-expression before ',' token
ogl.cpp:56: error: expected primary-expression before ')' token
make: *** [ogl.o] Error 1


This is all so far over my head, I can't begin to figure out how to troubleshoot it.

[EFU]

Finally, I've managed to compile it on Windows XP using MinGW, but the game crashes at the very beginning (it's only possible to see for just a moment the game screen with the background filled with its blueish color and without any buttons or images). About your mentioned error, CPicon, that error never occured to me while I was trying to compile the game - be sure that you have the latest source code, and, if there are *.o files or bh file, remove those before starting the make. By the way after the compilation there can be linking problems, and this is my LDFLAGS (from the Makefile):

Code: Select all

LDFLAGS = -lGL -lGLU -lmingw32 -lSDLmain -lSDL -lSDL_image -lSDL_mixer -lfreetype


you need to have symbolic links in /usr/lib from libGL.a to libopengl32.a and from libGLU.a to libglu32.a. Additionally, I merged all the system folders (bin, etc, include, lib, libexec, share ...) in MSYS and MinGW with each other - so that I have 2 copies of those in both MSYS and MinGW... I don't know if it helps or no; and I attach the bunnyhill source directory.

[cpicon92]

Thanks for providing me with your code dir, it turned out to be the fact that i loaded an include in the wrong spot (i feel pretty stupid). I now have a working executable, it just doesn't seem to be able to find the data dir:

Code: Select all

CSPList::Load - unable to open
failed to load common textures
CSPList::Load - unable to open
wrong default font
CSPList::Load - unable to open
CSPList::Load - unable to open
could not load courses.lst


[erin]

The situation is a bit confusing. I see that EFU has downloaded the develop snapshot, too. This code is not convenient for solving all problems, it is only to test the font. Currently I'm restructuring the code

- english comments
- replacing the old SPList (based on C) with a new CSPList (C++ with string class). That's not ready
- avoiding C strings to make the code safer (work in progress, too)

Please let me finish this work before discussing other bugs and deficiencies.

Now the OpenGL extension pointers. They are not used yet, and at the moment we can remove the related code. You can comment out the statement InitGLExtensions (in function InitGL, ogl.cpp). Another hint: It's easy (and fast) to compile with a simple selfmade Makefile but sometimes it's necessary to delete all *.o files in the tree, especially after having changed any thing in a header file. That can result in a segfault or other inexplicable error messages.

[EFU]

erin, I know that that was just a current development version of the code; we're dealing with Windows-specific issues - I don't think this will mess things up.
About these "failed loads": in main.cpp file at the beginning of SetGameParams function there is a following line (in my case it is the line 65):

Code: Select all

if (strlen (game.progdir) > 5) game.progdir[strlen(game.progdir)-3] = 0;


You just need to change "3" to "7" at the end of line, e.g.:

Code: Select all

if (strlen (game.progdir) > 5) game.progdir[strlen(game.progdir)-7] = 0;


In short, this is because the names of executables in most *nix-es (e.g. in linux) do not have extensions (like ".exe"); so in Windows-es there are additional 4 symbols (that need to be removed).
After this change, I still have other problems with the inability to load .png files. I think default SDL_image doesn't support png files so it may be necessary to recompile it manually - in that case LDFLAGS needs to have "-lpng -lz" part in Makefile, also png.h must not be included and libpng and libz must be installed. Ye, and, of course, I may be wrong about SDL_image

[EFU]

... and I forgot to mention: in bh.h file there is a line:

Code: Select all

//#   define SEP "\\"


It should be uncommented:

Code: Select all

#define SEP "\\"


And before compiling the code, remove all *.o files and bh.exe.

[erin]

From the SDL_image website:

Description:
SDL_image is an image file loading library.
It loads images as SDL surfaces, and supports the following formats: BMP, GIF, JPEG, LBM, PCX, PNG, PNM, TGA, TIFF, XCF, XPM, XV

[cpicon92]

Ok, I've got a perfectly working windows build put together. Thanks for all your help. The attached zip file includes bh.exe and all the dependencies (you have to provide the data dir). I tested everything (including fullscreen at 1650 by 1080) and it seems to work fine.

@EFU: I think the reason you couldn't load PNGs had to do with the way you compiled sdl on mingw. I got the blue screen as you described, and then I copied bh.exe into its own folder along with the optimized binary DLLs of the dependencies from the official websites. Now it works fine.

[erin]

I've done the code revision for the most part. Could you sum up the changes that are required to make it compilable on Windows?

then I can write a whole guide on compiling it with Mingw and Msys, it will save you a lot of time seeing as I've been using mingw since the original ETR release.

That would be a great help. As article on the wiki?

[erin]

Now it works fine.

... and it runs much faster as on Linux. Nevertheless I've detected at least 2 bugs:

- Sometimes the program crashes when I start another race and click on the play button. I have to check if this happens on Linux, too. Normally I don't use the mouse for the menu navigation (is faster to use the keyboard).
- The preview pictures are not visible. I'm sure that has to do with the scaling of these textures and probably with the OpenGL version. Very old OpenGLs can't scale textures, which are loaded by glTexImage3D, in the right way. Using gluBuild2DMipmaps instead might solve that problem but the pics will appear very unsightly. First they are scaled to power of 2 for creating the mipmaps, then you must scale them back to the desired size. Suspicion: Is it possible that the OpenGL header of Windows is obsolete? It's wellknown that Windows favours Direct X.

And now some words about the code. I've finished the revision as mentioned. A new SP library, it becomes mature. Before uploading the code I will check if the OpenGL errors are displayed correctly, and additionally I will implement a config file, first in the program folder. For tests it will be better to try out different options without compiling the program every time.

[cpicon92]

What graphics card to you have? All the images work fine for me (Radeon HD4850). I have the same problem as you, but it only happens for the Holy Grail and Challenge one races. Those two courses crash the game consistently, there isn't even any error output.