1. Summary
  2. Files
  3. Support
  4. Report Spam
  5. Create account
  6. Log in

0.5a Windows Build

Talk about ideas and the code.

0.5a Windows Build

Postby cpicon92 » Sun Nov 28, 2010 5:54 am

Here is my build of ETR, for others to try out and criticize: http://mcmco.tk/etr-0.5dev_win32.7z
I built it on a 64 bit version of Windows, so I'd really like it if somebody who has a 32 bit version could tell me if it works.

---------------

You read that right. I actually succeeded in compiling the new ETR code on Windows (this probably would've been easier for someone who actually knew what he or she was doing...). I'm going to try to document the procedure for anybody who may be interested, and for myself in the future. Please feel free to point out things that could be done better.

1. Install MinGW (and msys) on Windows (I haven't tried the linux MinGW)
This is not nearly as convoluted as it used to be. You just use the installer and check off c++ and the developer toolkit.

2. Install Dependencies
This is arguably the hardest part of the process. On Linux, where you either use a package manager, or you follow the standard build order for every package. On MinGW you have to either manually locate binaries and copy them, or compile them yourself.
The packages that need to be installed are as follows:
-SDL
-SDL_mixer
-SDL_image
-freetype2
-freeglut
I can't really go over each one individually, because it would take too long, but I'll give some general instructions. Firstly, all of the SDL packages are available precompiled from their respective websites. One must download the Windows package that most closely fits (sometimes mingw, sometimes vc++). To install these, you must manually copy the files in the archives to their respective locations in the MinGW root.
Secondly, freetype2 isn't available (as far as I could find) for mingw, so I compiled it from source. If you wish to do the same, I want to emphasize that you shouldn't EVER type "make install" in msys, as this will install the files to the msys locations (where the compiler won't be able to find them). Instead you should configure, make, and then use "make install DESTDIR=/c/foo/bar/". This will install the files to the temporary folder 'bar' on your C drive. From there, you can manually copy the files in the proper way.
For those of you who aren't so keen on compiling from source, I have uploaded my build of freetype:http://mcmco.tk/freetype-2.4.3_mingw.zip.
Freeglut is present to replace the missing GLUT library on MinGW. You can download a copy from here: http://www.transmissionzero.co.uk/software/freeglut-devel/.

3. Code Modifications
In order to get ETR to compile on Windows I had to make some (sometimes dubious) modifications to the code. I'm kind of hoping erin will be able to provide a more elegant way of doing this, given this information.
Firstly, we must let the compiler know that we're on Windows with mingw. To the best of my knowledge, the easiest way to do this is in 'bh.h', by switching the commented lines.
Code: Select all
#define OS_LINUX
// #define OS_WIN32_MINGW

becomes
Code: Select all
// #define OS_LINUX
#define OS_WIN32_MINGW

After that, we have to modify the makefile to link to the Windows versions of all of the libraries required.
Code: Select all
LDFLAGS = -lglut -lGL -lGLU -lSDL -lSDL_image -lSDL_mixer -lfreetype

becomes
Code: Select all
LDFLAGS = -lfreeglut -lopengl32 -lGLU32 -lSDL -lSDL_image -lSDL_mixer -lfreetype

Lastly, we make a weird modification to main.cpp to prevent Windows from making a hissy fit (this could definitely be improved, but that discussion is for another time). Basically you add an extra #undef, as follows:
Code: Select all
int main( int argc, char **argv ) {

becomes
Code: Select all
#undef main
int main( int argc, char **argv ) {


4. Compile
Open msys from the start menu, go to the directory where the code is stored, and type "make". If no errors appear, then there should be an etr.exe sitting in the source directory.

---------------------------------------

Known Issues
Currently, I can only find two issues with the Windows build.
- Changing the resolution screws up the graphics until you restart the game. (This was the case in PPRacer and ETR, as well)
- Starting the game causes a cmd dialog to pop up. I really know nothing about the workings of C on Windows, so suppressing this is beyond me for now.
cpicon92
Site Admin
 
Posts: 89
Joined: Mon Apr 19, 2010 12:51 pm

Re: 0.5a Windows Build

Postby erin10 » Sun Nov 28, 2010 11:05 am

That's great, congratulations !!!

I've installed it on a 32 bit Windows, only for a first, quick test. It doesn't start in fullscreen mode but starts well in windowed mode. When I switch to fullscreen at runtime, the prog doesn't crash but doesn't show any texture. It looks drolly, imagine the scenery without terrain. Another discovery (in windowed mode): the displayed fps is always constantly 60, independent of the conditions, snowfall for example. I'm sure the prog runs much faster, yes, I can feel it.

But all this is not really important, I suppose that the prog must be compiled on a windows 32 system. However, the windows build is an important advancement.

Updating of the windows build should be as easy and as fast as possible in a well-installed mingw environment. For this reason I'll try to prepare the Makefile and the bh.h in a way that the files can used with a minimum of adaption. When I'm ready with the code I'll try to install mingw on my 32 windows provided that nobody else will do it sooner.

Nice that you've documentated the compiling procedure. In my opinion such articles should be the substance of the wiki.
erin10
 
Posts: 90
Joined: Sun May 23, 2010 9:18 am

Re: 0.5a Windows Build

Postby erin10 » Sun Nov 28, 2010 12:18 pm

A compliment:

Changing the resolution screws up the graphics until you restart the game. (This was the case in PPRacer and ETR, as well)

I found some interesting information in the SDL wiki:
Code: Select all
User note 2: Also note that, in Windows, setting the video mode resets the current OpenGL context. You must execute again the OpenGL initialization code (set the clear color or the shade model, or reload textures, for example) after calling SDL_SetVideoMode. In Linux, however, it works fine, and the initialization code only needs to be executed after the first call to SDL_SetVideoMode (although there is no harm in executing the initialization code after each call to SDL_SetVideoMode, for example for a multiplatform application).

Probably a solution for the problem, it looks promising.

Starting the game causes a cmd dialog to pop up.

Why not? Even Blender pops up the cmd dialog.
erin10
 
Posts: 90
Joined: Sun May 23, 2010 9:18 am

Re: 0.5a Windows Build

Postby cpicon92 » Mon Nov 29, 2010 2:59 pm

Good to hear that it works outside of my computer. Hopefully reinitializing opengl will fix the pesky graphics problem. That would almost be a feature in an of itself for this release.
While blender does pop up a cmd dialog, no native Windows apps do. There are lots of reasons why it's not great to have it. For one thing, less technically inclined people get frightened when they see white on black text, it makes them think they've got a virus. It also creates an extra window on the taskbar, which takes up space and gets in the way when you're using the character editor (which seems to work well in Windows, btw).
cpicon92
Site Admin
 
Posts: 89
Joined: Mon Apr 19, 2010 12:51 pm

Re: 0.5a Windows Build

Postby erin10 » Mon Nov 29, 2010 4:56 pm

On

http://osix.net/modules/article/?id=670

I found:

Code: Select all
Compile with g++ -mwindows hello_win.cpp -o hello_win

... Without the -mwindows option, when run from Explorer you would also get a nasty DOS box appear for the duration of the program. However this might be a useful place to send debugging information; if you also include stdio.h you can use printf to display on this window.

Does it help?

For the graphics problem I need to have mingw installed. I don't know how far I must go back with the initialization. Maybe we have to rebuild the OpenGL window from the scratch. I must watch the results of the different modifications.
If it won't work I suggest to change the resolution at the next start. By no means the screen should be unreadable at runtime.
erin10
 
Posts: 90
Joined: Sun May 23, 2010 9:18 am

Re: 0.5a Windows Build

Postby cpicon92 » Tue Nov 30, 2010 5:23 am

Your compiler flag fixed the problem. I have updated my uploaded binary to reflect this. The old Windows build of ETR channeled all of the print commands into a log.txt type file, I would make that modification here, but I have no idea where to begin.
I have also altered the code to change the file 'options' to 'options.txt' on Windows, since Windows won't define an editor for files without an extension.
About the graphics: if you don't want to bother figuring out the reinitialization of opengl, I think making the user restart is a perfectly acceptable solution (Windows users are used to restarting things :lol:).

At your suggestion I have adapted this post into a wiki page:
https://sourceforge.net/apps/mediawiki/ ... on_Windows

On a completely unimportant side-note, I can't seem to figure out why you're having trouble running it on a 32-bit OS. I've been testing it on Windows 98, and it seems to work alright (albeit really slowly). Here's a screenshot for the fun of it:

Image
cpicon92
Site Admin
 
Posts: 89
Joined: Mon Apr 19, 2010 12:51 pm

Re: 0.5a Windows Build

Postby erin10 » Tue Nov 30, 2010 9:12 am

Your compiler flag fixed the problem.

For me, it wasn't really a problem, but Windows users ...

The old Windows build of ETR channeled all of the print commands into a log.txt type file, I would make that modification here, but I have no idea where to begin.

Already done. That is what I called "saving the messages in a file". I've replaced the print commands with 'Message (...)'. The message system does twice: it prints the message immedately on the cmd dialog and it collects the messages and stores them on exiting. The file is 'messages' in the config folder. Hope that I didn't slip some print statements.

I have also altered the code to change the file 'options' to 'options.txt' on Windows, since Windows won't define an editor for files without an extension.

Yes, why not. The extensions of all config files are arbitrary.

I think making the user restart is a perfectly acceptable solution (Windows users are used to restarting things

So we'll give them some more chances to train it. But I'll set a precompiler flag so that a restart is only required on Windows.

I can't seem to figure out why you're having trouble running it on a 32-bit OS. I've been testing it on Windows 98, and it seems to work alright

I got the troubles when I started the game in fullscreen mode. In windowed mode (like to be seen on your screenshot) it was ok - as far as I didn't switch to fullsreen at runtime. BTW: At which museum did you find a computer with an installed Win 98?

---------------
And now, last but not least: I'm ready with the code and I'll upload it this afternoon.
erin10
 
Posts: 90
Joined: Sun May 23, 2010 9:18 am

Re: 0.5a Windows Build

Postby cpicon92 » Tue Nov 30, 2010 11:45 pm

Already done. That is what I called "saving the messages in a file". I've replaced the print commands with 'Message (...)'. The message system does twice: it prints the message immedately on the cmd dialog and it collects the messages and stores them on exiting. The file is 'messages' in the config folder. Hope that I didn't slip some print statements.

Perfect, this works nicely. Perhaps it should be called messages.txt, but that's a minor issue.

BTW: At which museum did you find a computer with an installed Win 98?

Actually, it's my Linux laptop. I have Windows 98 running in a virtual machine. It's useful for emulating old Windows programs without using obscene amounts of ram.

For the sake of my sanity I have made all the Windows changes to the code and committed them along with a separate makefile which will trigger them. Now all you have to do to compile on Windows is run "make -f win32.make". This isn't a perfect solution (possibly, it's an incentive to use a configure script), but it works fine as long as you don't have to modify the makefile too often.
cpicon92
Site Admin
 
Posts: 89
Joined: Mon Apr 19, 2010 12:51 pm

Re: 0.5a Windows Build

Postby erin10 » Wed Dec 01, 2010 1:56 pm

First: The freeglut package is not required. In early versions of Tuxracer glut was used in case that SDL was not available or installed. Sometime PPRacer decided to make SDL mandatory, and that was quite reasonable. I did the same with my Bunny Hill code but neglected to remove the entry from the Makefile.

Second: I tried to install mingw and mysys. It wasn't trouble-free but at last it worked somehow.

Third: Problems with the Windows builds! I've installed your build on two systems:

- Windows XP 32 bit:
a) start in fullscreen mode failed, typical windows error message, expressionless.
b) start in windowed mode: it ran, but fps was konstant 60, that isn't correct.
c) switch to fullscreen at runtime: all textures lost
d) changing resolution at runtime: some worked (e.g. 1024 -> 800), other like c)

- Windows 7 64 bit:
a) start in fullscreen AND windowed mode ok, fps ok
b) changings at runtime the same as above

- My own build, tested on Windows XP 32 bit:
a) start in windowed mode possible, but fps konstant 60, error message on exiting
b) start in fullscreen mode: not possible, no start, no message

Then I compiled glframe, a little test program with a simple non-textured OpenGL scenery and a rolling sphere, normally steered by the keyboard. But the sphere was not steerable or movable on Windows. No, something is wrong, either with my code or with the mingw environment.
erin10
 
Posts: 90
Joined: Sun May 23, 2010 9:18 am

Re: 0.5a Windows Build

Postby cpicon92 » Wed Dec 01, 2010 3:19 pm

I have some work to do that must get done today, so I'll write more in the near future. But I felt I needed to post something quickly on the subject of 32-bit xp. Do you have access to more than one computer with it installed? Because in my virtual machine of XP the game works fine (it only has the errors that you describe having in Windows 7). This makes me believe that the problem is a. caused at a low level by the hardware, or b. something that's wrong with your install of XP. I think in order to really figure out what's going on, we're going to need to test it in more places.
cpicon92
Site Admin
 
Posts: 89
Joined: Mon Apr 19, 2010 12:51 pm

Next

Return to Developer Discussion

Who is online

Users browsing this forum: No registered users and 0 guests

cron