Re: [Warzone-dev] projectile fixes and flatten imd fixes
On 4/29/07, The Watermelon [EMAIL PROTECTED] wrote:
Attached fixed projfix13a and the fixes for flattenimd crash which was
reported in forum a few days ago.
Here is a reworked version of the patch for the flattenimd issue.
There were some problems with switching MAX/MIN and missing -1 for
index. Also cleaned up the code in question a bit (sorry for mixing
bug fix and cleanup... should not normally do this).
- Per
Index: src/display3d.c
===
--- src/display3d.c (revision 1193)
+++ src/display3d.c (working copy)
@@ -4230,17 +4230,17 @@
/* Flattens an imd to the landscape and handles 4 different rotations */
static iIMDShape *flattenImd(iIMDShape *imd, UDWORD structX, UDWORD structY, UDWORD direction)
{
-UDWORD i;
-UDWORD pointHeight,centreHeight;
-SDWORD shift;
+ UDWORD i, centreHeight;
ASSERT( imd-npoints iV_IMD_MAX_POINTS,
flattenImd: too many points in the PIE to flatten it );
/* Get a copy of the points */
memcpy(alteredPoints,imd-points,imd-npoints*sizeof(Vector3i));
+
/* Get the height of the centre point for reference */
centreHeight = map_Height(structX,structY);
+
/* Now we go through the shape looking for vertices on the edge */
/* Flip reference coords if we're on a vertical wall */
@@ -4252,77 +4252,64 @@
{
case 0:
for(i=0; i(UDWORD)imd-npoints; i++)
+ {
+ if (abs(alteredPoints[i].x) = 63 || abs(alteredPoints[i].z) = 63)
{
-if(abs(alteredPoints[i].x) = 63 || abs(alteredPoints[i].z)=63)
-{
- pointHeight = map_Height(structX+alteredPoints[i].x,structY-alteredPoints[i].z);
- shift = centreHeight - pointHeight;
- alteredPoints[i].y -= (shift-4);
-}
+UDWORD tempX = MIN(structX + alteredPoints[i].x, WORLD_COORD(mapWidth - 1));
+UDWORD tempY = MAX(structY - alteredPoints[i].z, 0);
+SDWORD shift = centreHeight - map_Height(tempX, tempY);
+
+alteredPoints[i].y -= (shift - 4);
}
+ }
break;
case 90:
for(i=0; i(UDWORD)imd-npoints; i++)
+ {
+ if (abs(alteredPoints[i].x) = 63 || abs(alteredPoints[i].z) = 63)
{
-if(abs(alteredPoints[i].x) = 63 || abs(alteredPoints[i].z)=63)
-{
- pointHeight = map_Height(structX-alteredPoints[i].z,structY-alteredPoints[i].x);
- shift = centreHeight - pointHeight;
- alteredPoints[i].y -= (shift-4);
-}
+UDWORD tempX = MAX(structX - alteredPoints[i].z, 0);
+UDWORD tempY = MAX(structY - alteredPoints[i].x, 0);
+SDWORD shift = centreHeight - map_Height(tempX, tempY);
+
+alteredPoints[i].y -= (shift - 4);
}
+ }
break;
-
case 180:
for(i=0; i(UDWORD)imd-npoints; i++)
+ {
+ if (abs(alteredPoints[i].x) = 63 || abs(alteredPoints[i].z) = 63)
{
-if(abs(alteredPoints[i].x) = 63 || abs(alteredPoints[i].z)=63)
-{
- pointHeight = map_Height(structX-alteredPoints[i].x,structY+alteredPoints[i].z);
- shift = centreHeight - pointHeight;
- alteredPoints[i].y -= (shift-4);
-}
+UDWORD tempX = MAX(structX - alteredPoints[i].x, 0);
+UDWORD tempY = MIN(structY + alteredPoints[i].z, WORLD_COORD(mapHeight - 1));
+SDWORD shift = centreHeight - map_Height(tempX, tempY);
+
+alteredPoints[i].y -= (shift - 4);
}
+ }
break;
case 270:
for(i=0; i(UDWORD)imd-npoints; i++)
+ {
+ if(abs(alteredPoints[i].x) = 63 || abs(alteredPoints[i].z)=63)
{
-if(abs(alteredPoints[i].x) = 63 || abs(alteredPoints[i].z)=63)
-{
- pointHeight = map_Height(structX+alteredPoints[i].z,structY+alteredPoints[i].x);
- shift = centreHeight - pointHeight;
- alteredPoints[i].y -= (shift-4);
-}
+UDWORD tempX = MIN(structX + alteredPoints[i].z, WORLD_COORD(mapWidth - 1));
+UDWORD tempY = MIN(structY + alteredPoints[i].x, WORLD_COORD(mapHeight - 1));
+SDWORD shift = centreHeight - map_Height(tempX, tempY);
+
+alteredPoints[i].y -= (shift - 4);
}
+ }
break;
-
default:
- debug( LOG_ERROR, Weirdy direction for a structure in renderWall );
+ debug(LOG_ERROR, Weird direction (%u) for a structure in flattenImd, direction);
abort();
break;
}
-/*
- if (psStructure- direction == 90)
- {
-for(i=0; iimd-npoints; i++)
-{
- pointHeight = map_Height(structX-alteredPoints[i].z,structY-alteredPoints[i].x);
- shift = centreHeight - pointHeight;
- alteredPoints[i].y -= shift;
-}
- }
- else
- {
-for(i=0; iimd-npoints; i++)
-{
- pointHeight = map_Height(structX+alteredPoints[i].x,structY-alteredPoints[i].z);
- shift = centreHeight - pointHeight;
- alteredPoints[i].y -= shift;
-}
- }
-*/
- imd-points = alteredPoints;
- return(imd);
+
+ imd-points = alteredPoints;
+ return imd;
}
static void getDefaultColours( void )
Index: src/map.c
===
--- src/map.c (revision 1192)
+++ src/map.c (working copy)
@@ -1321,10 +1321,11 @@
//SDWORD lowerHeightOffset,upperHeightOffset;
SDWORD dx, dy, ox,
Re: [Warzone-dev] projectile fixes and flatten imd fixes
On 4/29/07, Per Inge Mathisen [EMAIL PROTECTED] wrote: On 4/29/07, The Watermelon [EMAIL PROTECTED] wrote: Attached fixed projfix13a and the fixes for flattenimd crash which was reported in forum a few days ago. Here is a reworked version of the patch for the flattenimd issue. There were some problems with switching MAX/MIN and missing -1 for index. Also cleaned up the code in question a bit (sorry for mixing bug fix and cleanup... should not normally do this). - Per ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev no problem I just fixed projfix13 according to the original code and changed tile_shift to WORLD_COORDS macro projfix13d.patch Description: Binary data ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] projectile fixes and flatten imd fixes
Forgot to include projectile.c changes in projfix13d,fixed version: projfix13e.patch Description: Binary data ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Projectile Fixes
You can always do the cheap rectangular hit box check first, and then only do the radius check if that indicates a possible hit - should be fairly cheap since most objects are going to be clear misses (until you start lobbing nukes from your 3 turret mega-units). Basic clipping-style tests. (And of course you compare squares of the distance, rather than bothering to squareroot each side of the equation) -- - Gus yea that is what wz projectiles use to test hits,I just changed the 'constant' tile/4 radius to imd (xmax + ymax)/2 and added zdiff check to fix ground to ground weapon projectiles hitting air units bug with the new 'hit' system.(the old 'hit' system is similar to warcraft III's or generals's(all homing except few large ballistic weapon),the new 'hit' system is similar to total annihilation's(all 'real' except homing ones)) _ Don't just search. Find. Check out the new MSN Search! http://search.msn.click-url.com/go/onm00200636ave/direct/01/ ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Projectile Fixes
Am Mittwoch, 29. November 2006 07:25 schrieb zz zz:
This is not really your definition of square is it? ;)
+radSquared = psStats-radius * psStats-radius *
psStats-radius;
that is radCuded,to save a temporary variable in that function,I used the
same variable name for radSquared and radCuded.
Why are those many ifs included? Eg at:
+if
(psTempDroid-droidType == DROID_CONSTRUCT)
+{
+zdiff -=
(asConstructStats[psTempDroid-asBits[COMP_CONSTRUCT].nStat]).pIMD-ymax;
+}
because those non-combat component uses different data storage name in
memory,asRepairStats for repair turret,asConstructStats for
contruct,asBrainStats for commander etc etc.
zdiff -= somecomponent.imd.ymax is equal to
z hitbox += display height of the component.img
So you use the real size of the turrets to calculate the hitbox?
Am Dienstag, 28. November 2006 20:41 schrieb zz zz:
+//Watermelon:fix turret pitch for more turrets
+if (((DROID *)psAttacker)-numWeaps 0)
+{
+if (weapon_slot = 0)
+{
+((DROID *)
psAttacker)-turretPitch[weapon_slot] = psObj-pitch;
+}
+}
+else
+{
+((DROID *) psAttacker)-turretPitch[0]
= psObj-pitch;
+}
Why can't just
((DROID *) psAttacker)-turretPitch[weapon_slot] = psObj-pitch;
be used? Is weapon_slot not 0 if we got 0 numWeaps?
And: Do we have negative wpn slots?
actually it should never get to 'numWeaps = 0',I'll remove the 'else
{((DROID *) psAttacker)-turretPitch[0] = psObj-pitch;}' line.
negative wpn slots = the projectile is created by another projectile,so the
wpn slots is set to -1 (negative 1) in this particular case,to distinguish
projectile sent by turret(draw muzzle flash) and projectile sent by other
projectile(dont draw muzzle flash).
Just curious: Why is following done? To save dereferencings of pointers?
if (psStats-penetrate)
{
bPenetrate = TRUE;
}
I need to pass a bool to send projectile function,I dont think passing
'psStats-penetrate' is a good idea,since the weapon nStat(aka Id in
asWeaponStats,to retrieve weapon info read from weapon.txt) is already
passed to that function as the first parameter.
Again curious: What does this do? (Is that the hitbox check?)
+/* see if psCurrD is hit (don't hit
main target twice) */
+if (((BASE_OBJECT *)psCurrD !=
psObj-psDest)
+((SDWORD)psCurrD-x = tarX0)
+((SDWORD)psCurrD-x = tarX1)
+((SDWORD)psCurrD-y = tarY0)
+((SDWORD)psCurrD-y = tarY1)
+((SDWORD)psCurrD-z = tarZ0)
+((SDWORD)psCurrD-z = tarZ1))
yes it's hitbox.
Everyone: Please fix all of the following, if you see it in the code:
+DBP1((Damage
to object %d, player %d\n,
+
psCurrD-id, psCurrD-player));
This has to be some debug() call.
ok I'll replace it with debug()
Does this mean that you can hit friendly units now?
+/* Do damage to everything in range */
+for (i=0; iMAX_PLAYERS; i++)
this check has been there for ages,only radius damage can 'hit' friendly
units.
Again just curious: When I thought about an own engine (a long while ago)
I had the idea to use hitbubbles instead of hitboxes, so I don't need
to check whether something is between all sides of the box, but only need
to compare the distance to the mid of the bubble with the radius.
Why is this not a good approach, or: Why didn't you choose this approach?
isnt distance calculation more costy(esp 3D vector ones) than few =
comparisons?
It would be something like
sqrt( (x1-x2)^2 + (y1-y2)^2 + (z1-z2)^2 ) radius
So yes, you are probably right. With all those ^2 and the sqrt it would
probably have been slow.
On the paper draft for my engine I just compared the lines of math needed. ;)
What I just thought of (totally off topic): Does perhaps GL offer some way of
doing vector math like this? (Add 2 vectors and calculate it's length.)
pgpyCMW53WVFB.pgp
Description: PGP signature
Re: [Warzone-dev] Projectile Fixes
On 11/29/06, Dennis Schridde [EMAIL PROTECTED] wrote: What I just thought of (totally off topic): Does perhaps GL offer some way of doing vector math like this? (Add 2 vectors and calculate it's length.) No, but you can abuse shaders to do it, if you are really desperate for more speed ;-) This is not advisable until the method of using GPU for ordinary math calculation becomes a bit more standardized, though. Right now you have to write one set of code for Nvidia and another for ATI cards. However, if you can do several operations in parallell, you can optimize a great deal by using SSE(2) instructions. Although I think the biggest savings come from just selecting a good algorithm in the first place :-) - Per ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Projectile Fixes
On 11/29/06, zz zz [EMAIL PROTECTED] wrote: Again just curious: When I thought about an own engine (a long while ago) I had the idea to use hitbubbles instead of hitboxes, so I don't need to check whether something is between all sides of the box, but only need to compare the distance to the mid of the bubble with the radius. Why is this not a good approach, or: Why didn't you choose this approach? isnt distance calculation more costy(esp 3D vector ones) than few = comparisons? anyway I didnt create that hitbox check,I just added tarZ0 and tarZ1 to make sure it works for VTOL's. You can always do the cheap rectangular hit box check first, and then only do the radius check if that indicates a possible hit - should be fairly cheap since most objects are going to be clear misses (until you start lobbing nukes from your 3 turret mega-units). Basic clipping-style tests. (And of course you compare squares of the distance, rather than bothering to squareroot each side of the equation) -- - Gus ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Projectile Fixes
zz zz schreef: List of fixes: 1.Fixed a crash when firing the 2nd/3rd indirect weapon in combFire in combat.c. 2.Fixed target prediction finally(confused by x,y,z in pie and x,y,z in game and swapped the sin and cos and never thought droid-sMove.dir is in degree's ...) AA weapons can hit VTOL's relatively easy now due to this change. 3.Added smoke to AA gun bullet explosion effect even if it hits the target. 4.Fixed a bug which prevents AA weapon area of effect damage from working properly(VTOL's was excluded in area effect damage check in original project_Impact function),the 25% chance of AOE damage of AA weapons defined in weapons.txt should work now. 5.Changed units hitbox radius to use unit pie imd: avg(imd.xmax + imd.zmax) for 2D radius (imd.zmax + component.imd.zmax) for height(z) radius note:in pie/imd z is in game y,in pie/imd y is in game z 6.Removed the 'HeightBonus' thing since it's no longer needed. Maybe you could zip or gzip your patch since your mail client seems to mangle it. (Or gpg sign it as ascii armor without detached sig, that gives you plane base64 which your mail client shouldn't be able to torture). -- Giel signature.asc Description: OpenPGP digital signature ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Projectile Fixes
zz zz schreef: List of fixes: 1.Fixed a crash when firing the 2nd/3rd indirect weapon in combFire in combat.c. 2.Fixed target prediction finally(confused by x,y,z in pie and x,y,z in game and swapped the sin and cos and never thought droid-sMove.dir is in degree's ...) AA weapons can hit VTOL's relatively easy now due to this change. 3.Added smoke to AA gun bullet explosion effect even if it hits the target. 4.Fixed a bug which prevents AA weapon area of effect damage from working properly(VTOL's was excluded in area effect damage check in original project_Impact function),the 25% chance of AOE damage of AA weapons defined in weapons.txt should work now. 5.Changed units hitbox radius to use unit pie imd: avg(imd.xmax + imd.zmax) for 2D radius (imd.zmax + component.imd.zmax) for height(z) radius note:in pie/imd z is in game y,in pie/imd y is in game z 6.Removed the 'HeightBonus' thing since it's no longer needed. When applying your patch I'm getting compiler errors, these to be precise: feature.h: In function `void proj_ImpactFunc(PROJ_OBJECT*)': feature.h:54: error: too many arguments to function `BOOL featureDamage(FEATURE*, UDWORD, UDWORD)' projectile.c:2081: error: at this point in file feature.h: In function `BOOL objectDamage(BASE_OBJECT*, UDWORD, UDWORD, UDWORD)': feature.h:54: error: too many arguments to function `BOOL featureDamage(FEATURE*, UDWORD, UDWORD)' projectile.c:2507: error: at this point in file Which occurs because you added `psStats-weaponClass' before `psStats-weaponSubClass' in the argumentlist on line 2081. And because you added `weaponClass' before `weaponSubClass' in the argumentlist on line 2507. Both these changes where done without modifying feature.h and feature.c which would be a required change. When I simply revert the changes of those two lines your patch compiles without errors. -- Giel signature.asc Description: OpenPGP digital signature ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Projectile Fixes
When applying your patch I'm getting compiler errors, these to be precise: feature.h: In function `void proj_ImpactFunc(PROJ_OBJECT*)': feature.h:54: error: too many arguments to function `BOOL featureDamage(FEATURE*, UDWORD, UDWORD)' projectile.c:2081: error: at this point in file feature.h: In function `BOOL objectDamage(BASE_OBJECT*, UDWORD, UDWORD, UDWORD)': feature.h:54: error: too many arguments to function `BOOL featureDamage(FEATURE*, UDWORD, UDWORD)' projectile.c:2507: error: at this point in file Which occurs because you added `psStats-weaponClass' before `psStats-weaponSubClass' in the argumentlist on line 2081. And because you added `weaponClass' before `weaponSubClass' in the argumentlist on line 2507. Both these changes where done without modifying feature.h and feature.c which would be a required change. When I simply revert the changes of those two lines your patch compiles without errors. -- Giel I didnt touch 'featureDamage()' function,maybe someone changed it recently after I created this patch...though I didnt have problems compiling with these changes with the latest rev. this is rev 391 line 1891 to line 1894:(line 2078 to line 2081 after my changes) bKilled = featureDamage(psCurrF, calcDamage(weaponRadDamage( psStats, psObj-player), psStats-weaponEffect, (BASE_OBJECT *)psCurrF), psStats-weaponClass, psStats-weaponSubClass); _ Fixing up the home? Live Search can help http://imagine-windowslive.com/search/kits/default.aspx?kit=improvelocale=en-USsource=hmemailtaglinenov06FORM=WLMTAG ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Projectile Fixes
zz zz schreef: When applying your patch I'm getting compiler errors, these to be precise: feature.h: In function `void proj_ImpactFunc(PROJ_OBJECT*)': feature.h:54: error: too many arguments to function `BOOL featureDamage(FEATURE*, UDWORD, UDWORD)' projectile.c:2081: error: at this point in file feature.h: In function `BOOL objectDamage(BASE_OBJECT*, UDWORD, UDWORD, UDWORD)': feature.h:54: error: too many arguments to function `BOOL featureDamage(FEATURE*, UDWORD, UDWORD)' projectile.c:2507: error: at this point in file Which occurs because you added `psStats-weaponClass' before `psStats-weaponSubClass' in the argumentlist on line 2081. And because you added `weaponClass' before `weaponSubClass' in the argumentlist on line 2507. Both these changes where done without modifying feature.h and feature.c which would be a required change. When I simply revert the changes of those two lines your patch compiles without errors. -- Giel I didnt touch 'featureDamage()' function,maybe someone changed it recently after I created this patch...though I didnt have problems compiling with these changes with the latest rev. this is rev 391 line 1891 to line 1894:(line 2078 to line 2081 after my changes) bKilled = featureDamage(psCurrF, calcDamage(weaponRadDamage( psStats, psObj-player), psStats-weaponEffect, (BASE_OBJECT *)psCurrF), psStats-weaponClass, psStats-weaponSubClass); Are you sure about the revision number of 391? Because the most current version is 510. Secondly I've checked the logs and I found that the function prototype has indeed changed in revision 507, so my advise is to change your patch accordingly and it should then compile cleanly. Diff of feature.h r507: Index: feature.h === --- feature.h(revision 506) +++ feature.h(revision 507) @@ -51,8 +51,7 @@ wreckage to clear*/ extern FEATURE* checkForWreckage(DROID *psDroid); -extern BOOL featureDamage(FEATURE *psFeature, UDWORD damage, UDWORD weaponClass, - UDWORD weaponSubClass); +extern BOOL featureDamage(FEATURE *psFeature, UDWORD damage, UDWORD weaponSubClass); #endif -- Giel signature.asc Description: OpenPGP digital signature ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Projectile Fixes
Am Dienstag, 28. November 2006 12:53 schrieb zz zz:
List of fixes:
1.Fixed a crash when firing the 2nd/3rd indirect weapon in combFire in
combat.c.
2.Fixed target prediction finally(confused by x,y,z in pie and x,y,z in
game and swapped the sin and cos and never thought droid-sMove.dir is in
degree's ...) AA weapons can hit VTOL's relatively easy now due to this
change.
3.Added smoke to AA gun bullet explosion effect even if it hits the target.
4.Fixed a bug which prevents AA weapon area of effect damage from working
properly(VTOL's was excluded in area effect damage check in original
project_Impact function),the 25% chance of AOE damage of AA weapons defined
in weapons.txt should work now.
5.Changed units hitbox radius to use unit pie imd:
avg(imd.xmax + imd.zmax) for 2D radius
(imd.zmax + component.imd.zmax) for height(z) radius
note:in pie/imd z is in game y,in pie/imd y is in game z
6.Removed the 'HeightBonus' thing since it's no longer needed.
Ignoring all those other mails for now... (Will read those patches later.)
This is not really your definition of square is it? ;)
+ radSquared = psStats-radius * psStats-radius *
psStats-radius;
Why are those many ifs included? Eg at:
+ if
(psTempDroid-droidType == DROID_CONSTRUCT)
+ {
+ zdiff -=
(asConstructStats[psTempDroid-asBits[COMP_CONSTRUCT].nStat]).pIMD-ymax;
+ }
Apart from that the patch seems to look ok.
--Dennis
pgpBccRpQyBc8.pgp
Description: PGP signature
___
Warzone-dev mailing list
Warzone-dev@gna.org
https://mail.gna.org/listinfo/warzone-dev
