[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [liquidwar-user] LW 5.6.0pre1 windows binary

From: Christian Mauduit
Subject: Re: [liquidwar-user] LW 5.6.0pre1 windows binary
Date: Sun, 7 Dec 2003 17:38:05 +0100
User-agent: Mutt/1.3.28i


On Sat, Dec 06, 2003 at 05:44:21PM -0500, Redick David A wrote:
> what exactly is the map generator doing.. or not doing?
> and whats the testing enviroment for the window binary
> (compiler, win9x or xp, allegro version etc)
Here's the environment I use:

- Win98. In fact Win2000 is not suitable for compiling Liquid War. 
See explication below (related to DJGPP).

- Visual C++ 6.0. This is the compiler I use. It's proprietary, it's old
it sucks, but...'s the easiest way to compile Allegro programs
under Windows. You need to run the VCVARS32.BAT (comes with the
compiler) before starting to do anything.

- DJGPP. LW requires some DJGPP related tools (GNU make for instance) and 
those won't run with DJGPP under WinNT/2000/XP. You could technically use
another GNU make than the one that comes with DJGPP, there's one with
Cygnus, but well, historically I used DJGPP and I just continue to use
it. Of course once it's been compiled LW will run fine on Win2000
machines, but compiling requires being on Win98, for now at least.

- Allegro (of course!). To compile it under Windows, use the commands:
fix.bat msvc
make install
I still use Allegro 4.0.3 but I might use the latest Allegro 4.1.12
for 5.6.0. I don't think it makes a big difference anyway, honestly you
could use any Allegro 4.x release it should work.

You'll probably need to tweak your boot files if you want all these
tools to work. Here are a few usefull config lines, which might save
some time:


set PATH=%PATH%;c:\progra~1\micros~1\vc98\bin\


Last remark, I recently updated the code so that everything compiles
fine under Win32. If all files compile but link fails for instance, you
simply have an outdated sourcetree. Point is Savannah is currently down
because of a recent and rather unpleasant attack/rootkit story, so you
might not be able to cvs up right away.

Once you've all this installed (with PATH set up and all), a simple
make -f
should compile the game 8-)

make package_win32 
on your buildtree *but* in a UNIX environment (I personnally compile the
game on a shared samba directory) will build the .zip file.

This being said, here's the problem with LW and lwmapgen under Windows:
LW tries to run lwmapgen (or lwwinmap.exe to be more precise) with the
"system" command. This works fine under UNIX. The liquidwar-mapgen
inherits STDOUT STDIN STDERR from its parent (liquidwar) process and it
runs in background. Everything's fine.

Under Windows, it does not work the same way. For "some reason" when you
use the "system" function the program which is launched tries to grab
the display. I guess this is because on this OS there's no such thing as
running a process without a graphic context... So what happens is that
when you press the "Random map" button Windows switches back away from
DirectX (assuming you were running LW in fullscreen mode) and you see
your desktop, with explorer opened on it (or whatever program was
running), and that's it. As lwwinmap returns immediately you do not even
realize that it's because of this that you were thrown away from

Still, Liquid War is available in the "taskbar" and you can click on it
and you go back to the game, with your map generated, and it works 8-)

Point is you need to click on the Liquid War button in the taskbar all
the time: this is obviously not acceptable.

I suspect that this problem could be solved using the native
CreateProcess Windows function, and passing special arguments to it in
order to tell it *not* to try to set up a graphic context, and run in
pure background mode. I don't think it's very hard to do, but it's a
very Windowish thing and I'm drifting away from Windows development, and
I'm far from being an expert Win32 developper 8-)

As you can see, the problem really does not come from your program, it's
due to the way Windows understands the "system" call.

Of course the other solution would be to include lwmapgen within lw and
not fire it as an external program anymore. Still, now that all the
packaging has been done this way, I think trying to find a solution with
CreateProcess or something like this might be better.

Also, maybe calling "system" is OK, and we could find another solution
which would be to link lwwinmap so that it's some sort of "service"
process that purely runs in background... Or link it as a graphical
windowed program and not initialize any window at all...

I'm sure there's a solution, only we did not find it yet. But again I
think this problem won't delay 5.6.0. It's been several long months
since 5.5.9 has been released, players should not wait for too long 8-)

> also you mentioned that you're still getting segfault and /0 error.
> what functions and settings cause this?
Well, I honestly haven't taken the time to really track down the bugs,
but it happens that problems arise mostly when map is small. The current
lwmapgen implementation limits the size to a minimum of 100x100 but I
think that for testing asking for 10x10 maps should show the bugs even
faster. Ideally the program should work even on 3x3 maps. I mean it
would generate a stupid empty map but not go the "core dump" way.

Here's a command I used to generate some core dumps:
while true; do src/liquidwar-mapgen --width 100 --height 100 ; done > 
lwmapgen.log 2>&1

The output is attached to this mail.

Have a nice day,


PS: sorry for other people on the list who might not all be interested
in this rather technical discussion, but well, this email still contains
valuable information such as a practical "how to compile the game on
win32" which can always be usefull. Anyway, if this is too much, please
tell, I might even create a liquidwar-devel list for instance.

Christian Mauduit <address@hidden>     __/\__ ___
                                        \~/ ~/(`_ \   ___                   /_o _\   \ \_/ _ \_            \/      \___/ \__)

Attachment: lwmapgen.log.gz
Description: Binary data

reply via email to

[Prev in Thread] Current Thread [Next in Thread]