Re: [warzone2100-dev] git test repo active (also for hg/bzr users)

[Thomas Rast]

buginator wrote:
> 
> Using msysgit and or TortoiseGit (which needs msysgit installed), the
> results are somewhat better, you can push, but, I ran into a fatal
> issue, that I couldn't resolve.  It still is unstable, unless all you
> do is basic commands, like pull, commit, and push.  Once you start
> doing branches, tags, merges, then all bets are off.

If the state of git on windows is as abysmal as you claim it is,
please report (in detail!) your problems with msysgit to their list or
to the git list, and the problems with tortoisegit to the respective
folks.  Otherwise we have no hopes of ever resolving this.

(If you need some help in diagnosing your exact issues, feel free to
ask.)

-- 
Thomas Rast
tr...@{inf,student}.ethz.ch


signature.asc
Description: This is a digitally signed message part.
___
Warzone-dev mailing list
Warzone-dev@gna.org
https://mail.gna.org/listinfo/warzone-dev

Re: [Warzone-dev] 2.1 beta 2

[Thomas Rast]

Per Inge Mathisen wrote:
> I have committed some performance optimizations to trunk that doubled
> the fps count on my Intel X3000. I would like to hear reports from
> other people if it gives them improved performance, and no new bugs,

and on IRC:
>  can those of you who are CPU-limited notice any fps improvements
>  due to my latest commits?

I use a laptop with Core2 Duo 2.20GHz and nVidia Quadro FX 570M, and
tested with an -O3 compiled Warzone.  This appears to be CPU limited,
as the Warzone process ran at 100% CPU (one core).  To get
reproducible numbers, I started a skirmish on Rush-T2 at position 0,
zoomed out all the way, tilted the camera to maximum (looking almost
from the top), aligned north and centered on HQ.

Results are, very roughly, 120 FPS with r4022, 130 FPS with r4029, and
140 FPS with 4037 (=HEAD as of this writing).  So your changes today
indeed yielded another improvement.

Note that the FPS reproducibly drop by about 8-10, then climb back up,
right at the start of the game.  I assume this is caused by the three
AI players running their scripts.

HTH :-)
Thomas

-- 
GPG key ID 'BB66CCFD' available from hkp://subkeys.pgp.net or:
http://n.ethz.ch/student/trast/public-key.asc






signature.asc
Description: This is a digitally signed message part.
___
Warzone-dev mailing list
Warzone-dev@gna.org
https://mail.gna.org/listinfo/warzone-dev

[Warzone-dev] [bug #10956] Assertion error in multiplayer

[Thomas Rast]

URL:
  

 Summary: Assertion error in multiplayer
 Project: Warzone Resurrection Project
Submitted by: thomasrast
Submitted on: Saturday 02/02/2008 at 01:19
Category: Engine: Graphics
Severity: 4 - Important
Priority: 5 - Normal
  Status: None
 Assigned to: None
Originator Email: 
 Open/Closed: Open
 Discussion Lock: Any
 Release: svn/trunk
Operating System: GNU/Linux
 Planned Release: None

___

Details:


error   : SetUpInputFile(): Couldn't open input file:
'multiplay/learndata/player0/Sk-Clover-T2.lrn' for player 0:
File not founderror   : widgSetTabs id=3500: invalid major id 1 >= max 1
error   : Assert in Warzone: form.c:609 : widgSetTabs (major <
psForm->numMajor), last script event: '27 (CALL_DROID_DESTROYED)'
warzone2100: form.c:609: widgSetTabs: Assertion `major < psForm->numMajor'
failed.

Program received signal SIGABRT, Aborted.
[Switching to Thread -1228896528 (LWP 19966)]
0xe410 in __kernel_vsyscall ()


(gdb) bt full
#0  0xe410 in __kernel_vsyscall ()
No symbol table info available.
#1  0xb7b12875 in raise () from /lib/tls/i686/cmov/libc.so.6
No symbol table info available.
#2  0xb7b14201 in abort () from /lib/tls/i686/cmov/libc.so.6
No symbol table info available.
#3  0xb7b0bb6e in __assert_fail () from /lib/tls/i686/cmov/libc.so.6
No symbol table info available.
#4  0x0819dabc in widgSetTabs (psScreen=0xb8e1d28, id=3500, major=1,
minor=0)
at form.c:608
psForm = (W_TABFORM *) 0xc4c9b80
__FUNCTION__ = "widgSetTabs"
__PRETTY_FUNCTION__ = "widgSetTabs"
#5  0x080a8044 in intDoScreenRefresh () at hci.c:903
StatsWasUp = 1
OrderWasUp = 0
objMajor = 1
objMinor = 0
statMajor = 2
statMinor = 0
psFlag = (FLAG_POSITION *) 0x0
#6  0x080a89e2 in intRunWidgets () at hci.c:1578
retID = 1065353216
retCode = 3219067848
quitting = 0
structX = 1167212544
structY = 135947984
structX2 = 0
structY2 = 136524874
objMajor = 0
objMinor = 514
psStructure = (STRUCTURE *) 0x3f80
psDroid = (DROID *) 0x0
i = 0
widgOverID = 0
__FUNCTION__ = "intRunWidgets"
__PRETTY_FUNCTION__ = "intRunWidgets"
#7  0x080ca31d in gameLoop () at loop.c:203
psCurr = (DROID *) 0xd59f80
psNext = (DROID *) 0xb7e5e74e
psCBuilding = (STRUCTURE *) 0x0
psNBuilding = (STRUCTURE *) 0x20
psCFeat = (FEATURE *) 0xff0a
psNFeat = (FEATURE *) 0xb7eb7820
i = 3085662240
widgval = 0
quitting = 0
intRetVal = 3085662240
clearMode = 7
__FUNCTION__ = "gameLoop"
__PRETTY_FUNCTION__ = "gameLoop"
#8  0x080cc553 in runGameLoop () at main.c:630
No locals.
#9  0x080cc8e7 in mainLoop () at main.c:803
event = {type = 4 '\004', active = {type = 4 '\004', gain = 0 '\0', 
state = 0 '\0'}, key = {type = 4 '\004', which = 0 '\0', state = 0 '\0',

keysym = {scancode = 70 'F', sym = 4294901760, mod = KMOD_NONE, 
  unicode = 0}}, motion = {type = 4 '\004', which = 0 '\0', 
state = 0 '\0', x = 70, y = 538, xrel = 0, yrel = -1}, button = {
type = 4 '\004', which = 0 '\0', button = 0 '\0', state = 0 '\0', x = 70,

y = 538}, jaxis = {type = 4 '\004', which = 0 '\0', axis = 0 '\0', 
value = 70}, jball = {type = 4 '\004', which = 0 '\0', ball = 0 '\0', 
xrel = 70, yrel = 538}, jhat = {type = 4 '\004', which = 0 '\0', 
hat = 0 '\0', value = 0 '\0'}, jbutton = {type = 4 '\004', which = 0
'\0', 
button = 0 '\0', state = 0 '\0'}, resize = {type = 4 '\004', w =
35258438, 
h = -65536}, expose = {type = 4 '\004'}, quit = {type = 4 '\004'}, user =
{
type = 4 '\004', code = 35258438, data1 = 0x, data2 = 0x0}, 
  syswm = {type = 4 '\004', msg = 0x21a0046}}
#10 0x080cccd7 in main (argc=2, argv=0xbfdf15b4) at main.c:957
---Type  to continue, or q  to quit---
No locals.





___

Reply to this item at:

  

___
  Message sent via/by Gna!
  http://gna.org/


___
Warzone-dev mailing list
Warzone-dev@gna.org
https://mail.gna.org/listinfo/warzone-dev

[Warzone-dev] [bug #10955] Segfault in MP game

[Thomas Rast]

URL:
  

 Summary: Segfault in MP game
 Project: Warzone Resurrection Project
Submitted by: thomasrast
Submitted on: Saturday 02/02/2008 at 01:14
Category: None
Severity: 3 - Normal
Priority: 5 - Normal
  Status: None
 Assigned to: None
Originator Email: 
 Open/Closed: Open
 Discussion Lock: Any
 Release: svn/trunk
Operating System: GNU/Linux
 Planned Release: None

___

Details:

Only special thing that comes to mind was that the AI player on our team set
a beacon to call for help.

error   : SetUpInputFile(): Couldn't open input file:
'multiplay/learndata/player0/Sk-Clover-T2.lrn' for player 0:
File not founderror   : map_Height: x coordinate is a negative SDWORD passed
as an UDWORD: -20
error   : map_Height: y coordinate is a negative SDWORD passed as an UDWORD:
-20
 
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -1228753168 (LWP 19834)]
0x08178f2d in updateCurrentPower (psPowerGen=0xcedd9d0, player=0)
at power.c:331
331 asPower[player]->extractedPower += extractedPower ;
 
 
#0  0x08178f2d in updateCurrentPower (psPowerGen=0xcedd9d0, player=0)
at power.c:331
power = 0
i = 4
extractedPower = 0
#1  0x08178e6e in updatePlayerPower (player=0) at power.c:295
psStruct = (STRUCTURE *) 0xced8a90
#2  0x080ca407 in gameLoop () at loop.c:265
psCurr = (DROID *) 0xa7d8c0
psNext = (DROID *) 0xb7e8174e
psCBuilding = (STRUCTURE *) 0x0
psNBuilding = (STRUCTURE *) 0x20
psCFeat = (FEATURE *) 0xff0a
psNFeat = (FEATURE *) 0xb7eda820
i = 0
widgval = 0
quitting = 0
intRetVal = INT_NONE
clearMode = 7
__FUNCTION__ = "gameLoop"
__PRETTY_FUNCTION__ = "gameLoop"
#3  0x080cc553 in runGameLoop () at main.c:630
No locals.
#4  0x080cc8e7 in mainLoop () at main.c:803
event = {type = 3 '\003', active = {type = 3 '\003', gain = 0 '\0', 
state = 0 '\0'}, key = {type = 3 '\003', which = 0 '\0', state = 0 '\0',

keysym = {scancode = 96 '`', sym = SDLK_F12, mod = KMOD_NUM, 
  unicode = 0}}, motion = {type = 3 '\003', which = 0 '\0', 
state = 0 '\0', x = 96, y = 0, xrel = 293, yrel = 0}, button = {
type = 3 '\003', which = 0 '\0', button = 0 '\0', state = 0 '\0', x = 96,

y = 0}, jaxis = {type = 3 '\003', which = 0 '\0', axis = 0 '\0', 
value = 96}, jball = {type = 3 '\003', which = 0 '\0', ball = 0 '\0', 
xrel = 96, yrel = 0}, jhat = {type = 3 '\003', which = 0 '\0', 
hat = 0 '\0', value = 0 '\0'}, jbutton = {type = 3 '\003', which = 0
'\0', 
button = 0 '\0', state = 0 '\0'}, resize = {type = 3 '\003', w = 96, 
h = 293}, expose = {type = 3 '\003'}, quit = {type = 3 '\003'}, user = {
type = 3 '\003', code = 96, data1 = 0x125, data2 = 0x1000}, syswm = {
type = 3 '\003', msg = 0x60}}
#5  0x080cccd7 in main (argc=2, argv=0xbff82744) at main.c:957
No locals.




___

Reply to this item at:

  

___
  Message sent via/by Gna!
  http://gna.org/


___
Warzone-dev mailing list
Warzone-dev@gna.org
https://mail.gna.org/listinfo/warzone-dev

[Warzone-dev] [patch #917] Fixes segfault in recvResearchStatus()

[Thomas Rast]

URL:
  

 Summary: Fixes segfault in recvResearchStatus()
 Project: Warzone Resurrection Project
Submitted by: thomasrast
Submitted on: Sunday 01/06/2008 at 02:54
Category: Fix
Priority: 5 - Normal
  Status: None
 Privacy: Public
 Assigned to: None
Originator Email: 
 Open/Closed: Open
 Discussion Lock: Any

___

Details:

Revision 3374 crashes along the lines of

#0  0x08100243 in cancelResearch (psBuilding=0x1) at research.c:2075
#1  0x081729c8 in recvResearchStatus () at multiplay.c:990
psBuilding = (STRUCTURE *) 0x1

I believe the attached patch is the correct fix. Using this, a 1.5 hour game
2man+6AI game did not segfault.



___

File Attachments:


---
Date: Sunday 01/06/2008 at 02:54  Name: wz-r3374-researchstatus.diff  Size:
333B   By: thomasrast



___

Reply to this item at:

  

___
  Message sent via/by Gna!
  http://gna.org/


___
Warzone-dev mailing list
Warzone-dev@gna.org
https://mail.gna.org/listinfo/warzone-dev

[Warzone-dev] Sensor targeting fix

[Thomas Rast]

Hello once more

I guess my time didn't allow for as much contribution as I would have
liked, but of course I couldn't keep my fingers off Warzone either,
and it really bothered me that sensors were essentially useless given
WZ's focus on artillery.

So here goes.  It's even less than a one-line fix: it only shifts
around a '//'.

The underlying problem is that sensor droids have numWeaps=0 but
uninitialized asWeapons, and chooseOrderObj used the latter to detect
if the droid is armed.  Someone (Watermelon?) who knows the finer
details of DROID structs might want to clarify and/or fix deeper
below.

Greetings
Thomas

-- 
GPG key ID 'BB66CCFD' available from hkp://subkeys.pgp.net or:
http://n.ethz.ch/student/trast/public-key.asc

Index: src/order.c
===
--- src/order.c	(revision 970)
+++ src/order.c	(working copy)
@@ -3261,8 +3261,8 @@
 }
 	}
 	// else default to attack if the droid has a weapon
-	//else if (psDroid->numWeaps > 0
-else if (psDroid->asWeaps[0].nStat > 0
+	else if (psDroid->numWeaps > 0
+//else if (psDroid->asWeaps[0].nStat > 0
 			&& psObj->player != psDroid->player
 			&& !aiCheckAlliances(psObj->player , psDroid->player) )
 	{


pgpLsZiZCMfxp.pgp
Description: PGP signature
___
Warzone-dev mailing list
Warzone-dev@gna.org
https://mail.gna.org/listinfo/warzone-dev

Re: [Warzone-dev] droidSetBits() segfault or: stories of a bug

[Thomas Rast]

Hi Dennis

> Ah yes, I didn't commit that, because it may hide a bug. You experienced a 
> segfault, and now fix it by reseting the vars. Better would be to find out 
> why the vars got corrupted. And at least do an ASSERT() (Will just print a 
> error message in NDEBUG mode.)

You're probably right, I will investigate a bit.  However, the first
mail was wrong in that it's actually not the segfault triggering, but
the (pre-patch) ASSERT, which still ruins the ongoing game in DEBUG
mode...

- Thomas

-- 
GPG key ID 'BB66CCFD' available from hkp://subkeys.pgp.net or:
http://n.ethz.ch/student/trast/public-key.asc




pgppHm83kAL1d.pgp
Description: PGP signature
___
Warzone-dev mailing list
Warzone-dev@gna.org
https://mail.gna.org/listinfo/warzone-dev

[Warzone-dev] droidSetBits() segfault or: stories of a bug

[Thomas Rast]

Hello

The attached patch (my apologies for gzipping a <1kB file, but mailman
keeps invalidating my signatures if I attach diffs) fixes a small but
rather annoying segfault in droidSetBits().  If you don't care about
the details, you can skip the rest of the mail and apply it, but since
the effects were rather interesting, I recommend you start reading
_without looking at the patch_.

The first symptom I got was a segfault at the very end of the loading
screen (i.e. just before the 3d display would appear) in the following
loop, at the marked line:

for (inc = 0;inc < psDroid->numWeaps;inc++)
{
psDroid->turretRotation[inc] = 0; /* <-- droid.c:4610 */
psDroid->turretPitch[inc] = 0;
}

At first, the problem seemed obvious: gdb told me that 'inc' was on
the order of 1'000'000, far larger than it should be.  But printing
psDroid->numWeaps reveals that it is 0!  Furthermore, this happens
_only if compiling without debugging_.  Inserting a debugging print
like so:

for (inc = 0;inc < psDroid->numWeaps;inc++)
{
fprintf(stderr, "%d", inc);
psDroid->turretRotation[inc] = 0;
psDroid->turretPitch[inc] = 0; 
}

(or any variation on the theme) also lets it run normally.  Even more
obscurely, the output will be

  0
  1
  2
  3
  4
  5
  6
  7

which is still quite invalid, as it's not supposed to run past 2 (at
most).

[If you can, without reading any further, come up with an explanation
for this seemingly totally illogical and erratic behaviour, please
tell me your mail address as you would have saved me quite some grief
;-)]

After quite some time of debugging, experimenting and staring at the
code (and playing rev 452, which I consider stable ;-) ) it turned out
that the loop termination condition was not initialized at this point,
thus explaining how 'inc' could get so large and trigger a segfault:

psDroid->numWeaps = pTemplate->numWeaps;   /* moved before the loop */
for (inc = 0;inc < psDroid->numWeaps;inc++)
{
psDroid->turretRotation[inc] = 0;
psDroid->turretPitch[inc] = 0;
}

That's the change the patch does, and it fixes the bug.  However, I
couldn't stop at this point; I had to find out why its behaviour was
so erratic.  The crucial hint is in the following print, and its
output:

psDroid->numWeaps = pTemplate->numWeaps;
for (inc = 0;inc < psDroid->numWeaps;inc++)
{
fprintf(stderr, "%x, %u", psDroid->numWeaps, inc);
psDroid->turretRotation[inc] = 0;
psDroid->turretPitch[inc] = 0;
}

This results in

  51f95e69, 0
  51f95e69, 1
  51f95e69, 2
  51f95e69, 3
  51f95e69, 4
  51f95e69, 5
  51f95e69, 6
  51f9, 7
  

Looking hard at the zeroes, I realised that in a _debugging_ compile,
since 'turretRotation' and 'turretPitch' is before 'numWeaps' in the
DROID structure, as 'inc' gets larger, the loop will reset 'numWeaps'
to 0 after a few iterations and then stop.  However, in a _release_
compile, with compiler optimisations, the compiler (GCC 4.0.3) moves
psDroid->numWeaps to a register (a valid optimisation, as referencing
psDroid->turretRotation effectively promises it does not modify
anything out of the array bounds), thus the termination condition is
never corrected and we can't know how long the loop runs.  And
finally, if the 'fprintf' is inserted in a release build, the crash
goes away, as the compiler now runs out of registers and has to reload
psDroid->numWeaps from memory, where it has been changed in the
meantime.

I've learned:

1. Check your initialisers.  Three times over.

2. Never trust GDB.  It tells the truth.

3. There's been a deeper reason all along for this vague feeling that
   I hate C (and C++ too).

- Thomas

PS: Off topic, but one of my patches (charon-tabs-segfault.diff) seems
to have been lost in the noise.  Could someone commit that?

-- 
GPG key ID 'BB66CCFD' available from hkp://subkeys.pgp.net or:
http://n.ethz.ch/student/trast/public-key.asc




charon-droidSetBits-segfault.diff.gz
Description: GNU Zip compressed data


pgp2YHsXFqISR.pgp
Description: PGP signature
___
Warzone-dev mailing list
Warzone-dev@gna.org
https://mail.gna.org/listinfo/warzone-dev

[Warzone-dev] string.h function warnings

[Thomas Rast]

Hello once again

This patch should fix the (many) warnings about 'memcpy', 'memset' and
so on that are declared in  which was not included in most
files.

- Thomas

-- 
GPG key ID 'BB66CCFD' available from hkp://subkeys.pgp.net or:
http://n.ethz.ch/student/trast/public-key.asc



charon-string.h-warnings.diff.gz
Description: GNU Zip compressed data


pgpX8E8kby2Oq.pgp
Description: PGP signature
___
Warzone-dev mailing list
Warzone-dev@gna.org
https://mail.gna.org/listinfo/warzone-dev

[Warzone-dev] Reload/HP bars overlapping

[Thomas Rast]

Hello

Another small fix, this one fixes the sign error in
drawWeaponReloadBar(), so that the reload bars for the 2nd turret will
be displayed below the 1st instead of over the HP bar.

- Thomas

-- 
GPG key ID 'BB66CCFD' available from hkp://subkeys.pgp.net or:
http://n.ethz.ch/student/trast/public-key.asc

Index: src/display3d.c
===
--- src/display3d.c	(Revision 455)
+++ src/display3d.c	(Arbeitskopie)
@@ -3325,8 +3325,8 @@
 		{
 			firingStage = (2*scrR) - 1;
 		}
-		pie_BoxFill(scrX - scrR-1, 6+scrY + 0 - (weapon_slot * 5), scrX - scrR +(2*scrR),6+scrY+3 - (weapon_slot * 5), 0x00020202);
-		pie_BoxFill(scrX - scrR,   6+scrY + 1 - (weapon_slot * 5), scrX - scrR +firingStage, 6+scrY+2 - (weapon_slot * 5), 0x00ff);
+		pie_BoxFill(scrX - scrR-1, 6+scrY + 0 + (weapon_slot * 5), scrX - scrR +(2*scrR),6+scrY+3 + (weapon_slot * 5), 0x00020202);
+		pie_BoxFill(scrX - scrR,   6+scrY + 1 + (weapon_slot * 5), scrX - scrR +firingStage, 6+scrY+2 + (weapon_slot * 5), 0x00ff);
 		return;
 	}
 	/*  /
@@ -3418,8 +3418,8 @@
 firingStage = (2*scrR) - 1;
 			}
 			/* Power bars */
-			pie_BoxFill(scrX - scrR-1, 6+scrY + 0 - (weapon_slot * 5), scrX - scrR +(2*scrR),6+scrY+3 - (weapon_slot * 5), 0x00020202);
-			pie_BoxFill(scrX - scrR,   6+scrY + 1 - (weapon_slot * 5), scrX - scrR +firingStage, 6+scrY+2 - (weapon_slot * 5), 0x00ff);
+			pie_BoxFill(scrX - scrR-1, 6+scrY + 0 + (weapon_slot * 5), scrX - scrR +(2*scrR),6+scrY+3 + (weapon_slot * 5), 0x00020202);
+			pie_BoxFill(scrX - scrR,   6+scrY + 1 + (weapon_slot * 5), scrX - scrR +firingStage, 6+scrY+2 + (weapon_slot * 5), 0x00ff);
 		}
 	}
 }
@@ -3505,7 +3505,6 @@
 health*=2;
 pie_BoxFill(scrX-scrR - 1, scrY - 1, scrX + scrR + 1, scrY + 2, 0x00020202);
 pie_BoxFill(scrX-scrR, scrY, scrX - scrR + health, scrY + 1, longPowerCol);
-
 drawWeaponReloadBar((BASE_OBJECT *)psStruct, psStruct->asWeaps, 0);
 			}
 			else


pgpmxMhNuiJpN.pgp
Description: PGP signature
___
Warzone-dev mailing list
Warzone-dev@gna.org
https://mail.gna.org/listinfo/warzone-dev

Re: [Warzone-dev] Patches (2 segfaults + 3 minor)

[Thomas Rast]

Sorry for the spam, but...

> Attached are a few small patches.

The signature is broken, probably due to a bug in KMail.  If you want,
I can re-send, but the whole routine is a bit pointless anyway as you
can't verify my public key.

- Thomas

-- 
GPG key ID 'BB66CCFD' available from hkp://subkeys.pgp.net or:
http://n.ethz.ch/student/trast/public-key.asc




pgpI7pyYhsk99.pgp
Description: PGP signature
___
Warzone-dev mailing list
Warzone-dev@gna.org
https://mail.gna.org/listinfo/warzone-dev

[Warzone-dev] Patches (2 segfaults + 3 minor)

[Thomas Rast]

Hello everyone!

First off allow me to thank you for the work so far.  I especially
like the linux port! :-)

Attached are a few small patches.  All of them are against r450, which
is HEAD as of this writing.  In order of severity:

* charon-sound-id-segfault.diff

This one is not reproducible.  It happened to me only once; the people
I play with had some similiar out-of-the-blue segfaults, but they
weren't running the game in debug mode or GDB so we can't confirm.
For some reason I couldn't figure out, 'sound_Play3DTrack' got a
sample with an 'iTrack' of 2608, which is quite obviously wrong
(MAX_TRACKS is defined to be 600 at the top of the file).  So I simply
put in a safeguard that makes it silently ignore such a sample, and
did the same for 'sound_Play2DTrack' just to be sure.

It appears to work now, but the patch could definitely need some error
reporting and/or investigation of the actual source of the problem.
I have attached a backtrace along with the patch in case someone more
versed in the code wants to have a look at it.

* charon-tabs-segfault.diff

Patches a reproducible segfault.  Try this:
1) Start a skirmish game on any map, in at least T2 mode.
2) Build three VTOL factories.
3) Pop up the factory production menu. Note that the last factory you
   built is on a new page, by itself.
4) Select a truck and click on the VTOL factory to upgrade it _without
   closing the factory menu_.  Boom.

I'm not entirely sure the way I fixed it is the "right thing", but it
works (it skips back to the first page in the menu).

* charon-decl-fix.diff

mingw32-gcc chokes on the difference between SDWORD and DWORD.  (My
GCC 4.0.3 on Linux didn't, however.)

* charon-cl-help.diff

devurandom changed --viewport to --resolution, but forgot to change
the --help text.

* charon-console-rebindable.diff

This patch makes the "show me the console backlog" key rebindable.
With my swiss german keyboard setup this is required, as I can only
type the backtick as a dead key followed by space, which is ignored by
warzone.

Hope that helps.  I'm afraid(?) more will follow ;-)

Off topic, I would prefer to scale the UI as everything is a bit too
small on my 1400x1050 laptop screen.  I've browsed around for some
time, but haven't found a real "entry point" to the widget drawing
stuff where such an OpenGL call could be fit in.  Is there such a
place?  If not, how does the widget system work?

- Thomas

-- 
GPG key ID 'BB66CCFD' available from hkp://subkeys.pgp.net or:
http://n.ethz.ch/student/trast/public-key.asc


Index: src/clparse.c
===
--- src/clparse.c	(Revision 450)
+++ src/clparse.c	(Arbeitskopie)
@@ -6,6 +6,7 @@
  */
 #ifndef _MSC_VER
 #include 
+#include 
 #endif	// not for .net I should say..  --Qamly
 #include "lib/framework/frame.h"
 #include "lib/widget/widget.h"
@@ -83,7 +84,7 @@
 		"   --savegame NAMELoad a saved game NAME\n"
 		"   --window   Play in windowed mode\n"
 		"   --version  Output version info and exit\n"
-		"   --viewport WIDTHxHEIGHTSet the dimensions of the viewport (screen or window)\n"
+		"   --resolution WIDTHxHEIGHT  Set the dimensions of the viewport (screen or window)\n"
 		"   --(no)shadows  Toggles the shadows\n"
 		"   --(no)soundToggles the sound\n"
 		   );
Index: src/keymap.c
===
--- src/keymap.c	(Revision 450)
+++ src/keymap.c	(Arbeitskopie)
@@ -377,7 +377,7 @@
 	keyAddMapping(KEYMAP_ASSIGNABLE,KEY_IGNORE,(KEY_CODE)KEY_MAXSCAN,KEYMAP_PRESSED,kf_JumpToSensorUnits,	strresGetString(psStringRes,STR_BIND_SENJ));
 	keyAddMapping(KEYMAP_ASSIGNABLE,KEY_IGNORE,(KEY_CODE)KEY_MAXSCAN,KEYMAP_PRESSED,kf_JumpToCommandUnits,	strresGetString(psStringRes,STR_BIND_COMJ));
 	keyAddMapping(KEYMAP_ASSIGNABLE,KEY_IGNORE,KEY_TAB,KEYMAP_PRESSED,kf_ToggleOverlays,			strresGetString(psStringRes,STR_BIND_OVERL));
-	keyAddMapping(KEYMAP_ALWAYS,KEY_IGNORE,KEY_BACKQUOTE,KEYMAP_PRESSED,kf_ToggleConsoleDrop,strresGetString(psStringRes,STR_BIND_CONSOLE));
+	keyAddMapping(KEYMAP_ASSIGNABLE,KEY_IGNORE,KEY_BACKQUOTE,KEYMAP_PRESSED,kf_ToggleConsoleDrop,strresGetString(psStringRes,STR_BIND_CONSOLE));
 	//**
 	// IN GAME MAPPINGS - Single key presses - ALL __DEBUG keymappings will be removed for master
 	keyAddMapping(KEYMAP_ASSIGNABLE,KEY_IGNORE,KEY_B,KEYMAP_PRESSED,kf_CentreOnBase,			strresGetString(psStringRes,STR_BIND_CENTV));
Index: lib/framework/configfile.h
===
--- lib/framework/configfile.h	(Revision 450)
+++ lib/framework/configfile.h	(Arbeitskopie)
@@ -4,8 +4,8 @@
 
 extern BOOL openWarzoneKey(void);
 extern BOOL closeWarzoneKey(void);
-extern BOOL getWarzoneKeyNumeric(const char *pName, SDWORD *val);
-extern BOOL setWarzoneKeyNumeric(const char *pName, SDWORD val);
+extern BOOL getWarzo