Am Dienstag, 7. November 2006 00:22 schrieb Gerard Krol:
> Watch out for the:
>
> #ifndef WZ_OS_WIN
>
> I guess it's better to have the same data types on all platforms. (On MinGW
> BOOL is defined as int) And as memory usage is not really an issue, why not
> leave BOOL == int? We just need to mak
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
On Tuesday, 7 November 2006 at 12:41, Dennis Schridde wrote:
> Am Dienstag, 7. November 2006 00:22 schrieb Gerard Krol:
> > Watch out for the:
> >
> > #ifndef WZ_OS_WIN
> >
> > I guess it's better to have the same data types on all platforms. (On MinGW
> > BOOL is defined as int) And as memory us
Am Dienstag, 7. November 2006 14:05 schrieb Thomas Rast:
> Hello
>
> The attached patch (my apologies for gzipping a <1kB file, but mailman
> keeps invalidating my signatures if I attach diffs)
Doesn't seem to help. :
(
> fixes a small but
> rather annoying segfault in droidSetBits(). If you don'
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 righ
Am Dienstag, 7. November 2006 16:43 schrieb 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
I'll just quote Watermelon:
"1.Fixed a bug has something to do with AA weapon hitting
ground unit(didnt check vector z for AA weapons)2.Tweaked the target
prediction for AA weapon,they now use both zDiff and dist to calculate predicted
x,y offsets,they should be better at hitting VOTLs now.
Forwarding another patch by Watermelon (looks like this patch
includes previous one):
Watermelon:
1.predictX,predictY offsets were swapped by mistake,they
should be fixed now.2.Fixed a crash when ordering truck to 'repair' a
full-health command center
3.Made proj_SendProjectile to accept an
Am Dienstag, 7. November 2006 17:03 schrieb Troman:
> Forwarding another patch by Watermelon (looks like this patch includes
> previous one):
>
> Watermelon:
> 1.predictX,predictY offsets were swapped by mistake,they should be fixed
> now.
>
> 2.Fixed a crash when ordering truck to 'repair' a full-
On 11/7/06, Dennis Schridde <[EMAIL PROTECTED]> wrote:
The interesting thing is _why_ does it break with BOOL not being int?
Means: _Who_ is relying on BOOL, which logically could be 1bit, to be 32bit
long? Why does this make WZ segfault? ...
Could be due to loading a binary file in which bool
Am Dienstag, 7. November 2006 18:06 schrieb Per Inge Mathisen:
> On 11/7/06, Dennis Schridde <[EMAIL PROTECTED]> wrote:
> > The interesting thing is _why_ does it break with BOOL not being int?
> > Means: _Who_ is relying on BOOL, which logically could be 1bit, to be
> > 32bit long? Why does this m
With a fresh subversion checkout, you cannot compile Warzone because
there is no win32/Makefile.in file in the repository. There are also
currently crash bugs on MacOS that I am going to try to find time to
track down, but hopefully someone knows what is going on with the
win32 missing Makefile.i
- Original Message -
From: "Dennis Schridde" <[EMAIL PROTECTED]>
To: "Development list"
Sent: Tuesday, November 07, 2006 6:58 PM
Subject: Re: [Warzone-dev] BOOL used to store pointers?
Am Dienstag, 7. November 2006 18:06 schrieb Per Inge Mathisen:
On 11/7/06, Dennis Schridde <[EMAIL P
On Tuesday, 7 November 2006 at 13:05, Ari Johnson wrote:
> With a fresh subversion checkout, you cannot compile Warzone because
> there is no win32/Makefile.in file in the repository. There are also
> currently crash bugs on MacOS that I am going to try to find time to
> track down, but hopefully
Ari Johnson schreef:
> With a fresh subversion checkout, you cannot compile Warzone because
> there is no win32/Makefile.in file in the repository. There are also
> currently crash bugs on MacOS that I am going to try to find time to
> track down, but hopefully someone knows what is going on with
Christian Ohm schreef:
> What's win32/warzone2100.o for and how is it generated?
>
That one is generated from win32/warzone2100.rc by windres and its
purpose is to add an icon and version information to the executable.
--
Giel
signature.asc
Description: OpenPGP digital signature
___
On 11/7/06, Christian Ohm <[EMAIL PROTECTED]> wrote:
On Tuesday, 7 November 2006 at 13:05, Ari Johnson wrote:
> With a fresh subversion checkout, you cannot compile Warzone because
> there is no win32/Makefile.in file in the repository. There are also
> currently crash bugs on MacOS that I am g
Am Dienstag, 7. November 2006 19:26 schrieb Troman:
> >- Original Message -
> >From: "Dennis Schridde" <[EMAIL PROTECTED]>
> >To: "Development list"
> >Sent: Tuesday, November 07, 2006 6:58 PM
> >Subject: Re: [Warzone-dev] BOOL used to store pointers?
> >
> >Am Dienstag, 7. November 2006 1
Am Dienstag, 7. November 2006 20:02 schrieb Giel van Schijndel:
> Ari Johnson schreef:
> > With a fresh subversion checkout, you cannot compile Warzone because
> > there is no win32/Makefile.in file in the repository. There are also
> > currently crash bugs on MacOS that I am going to try to find
Am Dienstag, 7. November 2006 21:08 schrieb Ari Johnson:
> On 11/7/06, Christian Ohm <[EMAIL PROTECTED]> wrote:
> > On Tuesday, 7 November 2006 at 13:05, Ari Johnson wrote:
> > > With a fresh subversion checkout, you cannot compile Warzone because
> > > there is no win32/Makefile.in file in the re
Another session:
(I guess no output from cpPrintFunc() means that the debuglogsystem skiped it,
because it was the same message as before.)
main: newMapInitialise
never: levLoadData: setting mission heap
never: blkReset: ../src/init.c at 1086: memory usage:
never: Blocks
It seems like setBackgroundFog is causing trouble. There was one call
before
it, but I didn't print the name of it. :(
I can't see anything suspicious, but if anything, I'd say it's
stackPopParams() that is causing problems. Maybe you can take a closer look
at it. Most interesting place is
*
Dennis Schridde schreef:
>> Yes I've also had some compile problems when trying to compile the trunk
>> on Windows (compiling trunk on GNU/Linux works alright). Instead I'm
>> currently compiling from the 2.0 branch this works (with considerably
>> less compiler errors, lots of warnings though).
>>
Am Dienstag, 7. November 2006 23:42 schrieb Giel van Schijndel:
> Dennis Schridde schreef:
> >> Yes I've also had some compile problems when trying to compile the trunk
> >> on Windows (compiling trunk on GNU/Linux works alright). Instead I'm
> >> currently compiling from the 2.0 branch this works
24 matches
Mail list logo
