Re: [Warzone-dev] Current problems compiling

2006-11-11 Thread Dennis Schridde 
Am Dienstag, 7. November 2006 22:30 schrieb Dennis Schridde:
> 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 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.in.
> > >
> > > Makefile.in should not be in the repository, it is created from
> > > Makefile.am by running ./autogen.sh. Revision 464 added some mingw
> > > stuff to the build system, the culprit being the added "win32" in
> > > SUBDIRS in the main Makefile.am, which should probably enclosed in an
> > > "if MINGW32". (If it serves any purpose. Looking at the diff for r464
> > > it doesn't. What's win32/warzone2100.o for and how is it generated?)
> >
> > Another problem was #include  in src/gateway.c.  I think
> > that somewhere along the way we lost the configure.ac bits to find
> > malloc.c and attach an appropriate -I to CFLAGS.  (My system has
> > malloc.h, but it is not in /usr/include but rather a subdirectory of
> > that one.)
>
> I removed that looong ago, I think. :(
> I'll check if there is an autoX way to find the correct -I flag...
The inclusion of malloc.h doesn't seem to be needed. Removed in r471.

> > configure.ac still refers to win32/Makefile, but there is no
> > win32/Makefile.am in the repository.  The only files in win32 that I
> > get with a fresh checkout are Warzone.sln, Warzone.vcproj,
> > warzone2100.ico, and warzone2100.rc.
>
> Did I forgot to commit the file? :( Now fixed.


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

Re: [Warzone-dev] Automatic dependencies

2006-11-11 Thread Dennis Schridde 
Am Freitag, 10. November 2006 16:54 schrieb Gerard Krol:
> Hi,
>
> The complete lack of dependencies somewhat bothers me, so I ran (X11)
> makedepend. Attached are changes for the Makefile.raw's.
> Now you don't have to run "make clean" all the time anymore.
> Could someone with access to automake also incorporate the changes into
> the Makefile.am's?
Is the makedepend exe included in MinGW?
Because I rewrote the Makefile.raw s to run with just a plain MinGW 
installation (without MSys). Would be ugly if we now required a non standard 
exe for a task like dependency checking...

--Dennis


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

Re: [Warzone-dev] Clipping bug + fix

2006-11-11 Thread Gerard Krol 

Dennis Schridde wrote:

Am Samstag, 11. November 2006 18:40 schrieb Gerard Krol:
  

The clipping in src/bucket3d.c doesn't seem to work for me, as droids
and buildings disappear when they are not entirely off screen.
Anyone else has this problem?

Yes, this problem exists since long. It's just that nobody yet has bothered to 
fix it...
  

I hacked a *7 into the radius calculation and everything seems to work
fine, and I guess it is not a big problem nowadays when we draw 3 droids
and a building too much.


Why *7 ? Any specific reasons or found by trial and error?
What is FP12_MULTIPLIER ?
  

FP12_MULTIPLIER is (1<<12) but I don't have a clue what it stands for.
The 7 was just trial and error.

Someone with some experience with 3D viewports should write a new 
equation for the size of a circle on screen, and we can use that.
For now I suggest adding it to the TODO list (or a to be created HACK 
list (on the Wiki?)) so we don't forget about it.


- Gerard

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

Re: [Warzone-dev] Clipping bug + fix

2006-11-11 Thread Dennis Schridde 
Am Samstag, 11. November 2006 18:40 schrieb Gerard Krol:
> The clipping in src/bucket3d.c doesn't seem to work for me, as droids
> and buildings disappear when they are not entirely off screen.
> Anyone else has this problem?
Yes, this problem exists since long. It's just that nobody yet has bothered to 
fix it...
> I hacked a *7 into the radius calculation and everything seems to work
> fine, and I guess it is not a big problem nowadays when we draw 3 droids
> and a building too much.
Why *7 ? Any specific reasons or found by trial and error?
What is FP12_MULTIPLIER ?

--Dennis


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

[Warzone-dev] Clipping bug + fix

2006-11-11 Thread Gerard Krol 
The clipping in src/bucket3d.c doesn't seem to work for me, as droids 
and buildings disappear when they are not entirely off screen.

Anyone else has this problem?
I hacked a *7 into the radius calculation and everything seems to work 
fine, and I guess it is not a big problem nowadays when we draw 3 droids 
and a building too much.


- Gerard
Index: src/bucket3d.c
===
--- src/bucket3d.c  (revision 469)
+++ src/bucket3d.c  (working copy)
@@ -31,12 +31,14 @@
 #define BUCKET_RANGE   32000
 
 #define BUCKET_CLIP
-#define CLIP_LEFT  (0)
+#define CLIP_LEFT  ((SDWORD)0)
 #define CLIP_RIGHT ((SDWORD)DISP_WIDTH)
-#define CLIP_TOP   (0)
+#define CLIP_TOP   ((SDWORD)0)
 #define CLIP_BOTTOM ((SDWORD)DISP_HEIGHT)
 //scale depth = 1<>STRETCHED_Z_SHIFTsDisplay.imd->radius) * 2;//other building clipping not 
so close
+   radius = 
(((STRUCTURE*)pObject)->sDisplay.imd->radius);
 #endif
}
 
___
Warzone-dev mailing list
Warzone-dev@gna.org
https://mail.gna.org/listinfo/warzone-dev

Re: [Warzone-dev] Patch by Watermelon: bug fixes

2006-11-11 Thread Dennis Schridde 
Am Samstag, 11. November 2006 11:41 schrieb Gerard Krol:
> Gerard Krol wrote:
> > I think this is what Watermelon intended to send:
> >
> > sensorcrash.patch: fixes a crash when repairing a not damaged command
> > center, corrects the mouse cursor (change by me)
> > penetrate.patch: adds penetration for certain weapon types

> prediction.patch: improves the prediction for bullets
Shouldn't the z vector be considered for non VTOLs, too?
Eg when shooting up a hill or similar?

--Dennis


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

Re: [Warzone-dev] Patch by Watermelon: bug fixes

2006-11-11 Thread Gerard Krol 

Gerard Krol wrote:

I think this is what Watermelon intended to send:

sensorcrash.patch: fixes a crash when repairing a not damaged command 
center, corrects the mouse cursor (change by me)

penetrate.patch: adds penetration for certain weapon types


Penetrate contained to different patches, splitted it up into:

penetrate.patch: adds penetration for certain weapon types
prediction.patch: improves the prediction for bullets

- Gerard
Index: src/combat.c
===
--- src/combat.c(revision 469)
+++ src/combat.c(working copy)
@@ -104,9 +104,15 @@
//Watermelon:predicted X,Y offset per sec
SDWORD  predictX;
SDWORD  predictY;
-   //Watermelon:dirty dist
+   //Watermelon:sqrt dist
SDWORD  dist;
+   //Watermelon:vtolDist
+   SDWORD  vtolDist;
+   SDWORD  zDiff;
+   BOOLbFlyingVTOL;
 
+   bFlyingVTOL = FALSE;
+
ASSERT( PTRVALID(psWeap, sizeof(WEAPON)),
"combFire: Invalid weapon pointer" );
ASSERT( PTRVALID(psAttacker, sizeof(BASE_OBJECT)),
@@ -343,8 +349,20 @@
xDiff = abs(psAttacker->x - psTarget->x);
yDiff = abs(psAttacker->y - psTarget->y);
distSquared = xDiff*xDiff + yDiff*yDiff;
-   //Watermelon:dirty dist
-   dist = dirtySqrt(psAttacker->x,psAttacker->y,psTarget->x,psTarget->y);
+   //Watermelon:actual dist
+   dist = sqrt(distSquared);
+
+   //Watermelon:need to calculate the vtol actual distance(affected by 
vector z)
+   if (psTarget->type == OBJ_DROID)
+   {
+   if (vtolDroid((DROID *)psTarget) && !(((DROID 
*)psTarget)->sMove.Status == MOVEINACTIVE))
+   {
+   zDiff = abs(psAttacker->z - psTarget->z);
+   vtolDist = (SDWORD)(sqrt(dist*dist + zDiff*zDiff));
+   bFlyingVTOL = TRUE;
+   }
+   }
+
longRange = proj_GetLongRange(psStats, 
(SDWORD)psAttacker->z-(SDWORD)psTarget->z);
if (distSquared <= (psStats->shortRange * psStats->shortRange) AND
distSquared >= (psStats->minRange * psStats->minRange))
@@ -367,13 +385,24 @@
{
/* Kerrrbaaang ! a hit */
//Watermelon:Target prediction
-   if(psTarget->type == OBJ_DROID)
+   if (psTarget->type == OBJ_DROID)
{
-   predictX = (cos(((DROID *)psTarget)->sMove.dir) 
* ((DROID *)psTarget)->sMove.speed * sqrt(distSquared)) /psStats->flightSpeed;
+   //Watermelon:If it's a flying VTOL use vtolDist
+   if (bFlyingVTOL)
+   {
+   predictX = (SDWORD)((sin(((DROID 
*)psTarget)->sMove.dir) * ((DROID *)psTarget)->sMove.speed * vtolDist) 
/psStats->flightSpeed);
+   predictX += psTarget->x;
+   predictY = (SDWORD)((cos(((DROID 
*)psTarget)->sMove.dir) * ((DROID *)psTarget)->sMove.speed * vtolDist) 
/psStats->flightSpeed);
+   predictY += psTarget->y;
+   }
+   else
+   {
+   predictX = (SDWORD)((sin(((DROID 
*)psTarget)->sMove.dir) * ((DROID *)psTarget)->sMove.speed * dist) 
/psStats->flightSpeed);
predictX += psTarget->x;
-   predictY = (sin(((DROID *)psTarget)->sMove.dir) 
* ((DROID *)psTarget)->sMove.speed * sqrt(distSquared)) /psStats->flightSpeed;
+   predictY = (SDWORD)((cos(((DROID 
*)psTarget)->sMove.dir) * ((DROID *)psTarget)->sMove.speed * dist) 
/psStats->flightSpeed);
predictY += psTarget->y;
}
+   }
else
{
predictX = psTarget->x;
@@ -418,17 +447,20 @@
{
/* Kerrrbaaang ! a hit */
//Watermelon:Target prediction
-   if(psTarget->type == OBJ_DROID)
+   //Watermelon:If it's a flying VTOL use vtolDist
+   if (bFlyingVTOL)
{
-   predictX = (cos(((DROID *)psTarget)->sMove.dir) 
* ((DROID *)psTarget)->sMove.speed * sqrt(distSquared)) /psStats->flightSpeed;
+   predictX = (SDWORD)((sin(((DROID 
*)psTarget)->sMove.dir) * ((DROID *)psTarget)->sMove.speed * vtolDist) 
/psStats->flightSpeed);
predictX += psTarget->x;
-   predictY = (si