Re: [Warzone-dev] input.c changes and projectile.c fix
Am Montag, 13. November 2006 19:38 schrieb zz zz: > > > no,it's just 'reset' the hit bounding box's radius bonus to 1(no bonus) > > > >It just looked to me that wpRadius is set before entering the loop of > >neighbours and is never after set back to the old value (dependend on the > >wpn), so for other neighbours it would still be 1. But maybe I am wrong, > >was just a quick look. > > you are right,wpRadius is never set back to the old value,but it shouldnt > be a big problem,since this function is called every game loop/frame. I don't like the idea of letting a bug happen, because it's negative effects might be minor... This leads to very ugly things as we should all know by now. --Dennis pgpEviGjfm43b.pgp Description: PGP signature ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] input.c changes and projectile.c fix
Am Montag, 13. November 2006 20:07 schrieb zz zz: > >I mean generally for input handling... Wouldn't it be much simpler to just > >use > >SDL and in our eventhandler redirect specific events to special functions? > >(And not have another layer above it. (and not have 1001 places where > >events > >are handled, OffTopic)) > > > >--Dennis > > you cannot use the broken 'doubleclick' event in the current code...that's > why it was left with a comment '//TODO:double click' imo So SDL _has_ a doubleclick event?? What I meant was anyway a bit different: 1st Generally (a bit OT) I'd like to have one central eventhandler in WZ, which just calls functions of the subsystems when specific events occur. (Currently I think we have several of such handlers?) 2nd Strip additional layers where appropriate. Eg the input handling layer. Check SDL events instead and where that is not possible (doubleclick?) check whether in the last x ticks (eg use SDL_getTicks() instead of using the framerate calculation) there was allready a click and if yes interprete a doubleclick instead of a singleclick. Warning: This may be completely crapy; I intended to have a look at this in some holidays when I got more time. --Dennis pgpAOulkjtw9z.pgp Description: PGP signature ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Automatic dependencies
Dennis Schridde wrote: Am Montag, 13. November 2006 19:54 schrieb Per Inge Mathisen: Most of the sed code is just magic that I copied from somewhere else, probably http://make.paulandlesley.org/autodep.html which is a must-read. Does that code run always before the %.o: %.c rule is applied to any file? Yes. if we want Makefile.raw to be able to run from within a dos shell (no sed for example). No sed is just the beginning. Does anything of any complexity really run in a DOS shell? I would guess even just make would struggle, with different path delimiters and all that. For those who do not want to run mingw/msys/cygwin, surely just using VS is a better choice. It worked _pretty_ well till now (after I rewrote the Makefile.raws and striped any SHianisms)... I did the last releases with only cmd.exe and a MinGW 3.4.5 installation, without any extras like MSys or CygWin... I don't really know, I'm using MSys AND Cygwin for developement. Anyone just using DOS? - Gerard PS. Why not join irc.freenode.net #warzone? Quite busy there ;) ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Automatic dependencies
Am Montag, 13. November 2006 19:54 schrieb Per Inge Mathisen: > Most of the sed code is just magic that I copied from somewhere else, > probably http://make.paulandlesley.org/autodep.html which is a > must-read. > > > Does that code run always before the %.o: %.c rule is applied to any > > file? > > Yes. > > > if we want Makefile.raw to be able to run from within a dos shell (no sed > > for example). > > No sed is just the beginning. Does anything of any complexity really > run in a DOS shell? I would guess even just make would struggle, with > different path delimiters and all that. For those who do not want to > run mingw/msys/cygwin, surely just using VS is a better choice. It worked _pretty_ well till now (after I rewrote the Makefile.raws and striped any SHianisms)... I did the last releases with only cmd.exe and a MinGW 3.4.5 installation, without any extras like MSys or CygWin... --Dennis pgp29JjgKehrA.pgp Description: PGP signature ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
[Warzone-dev] Fwd: Re: Warzone Licensing
Updates on Warzone Licensing. As you can read in the forwarded mail Virgil is still in touch with Alex McLean and I am optimistic that there will be good results for us. As we probably don't want to wait with the 2.0.5 release till February (even though it was delayed for lng allready), I think it is best to get some readme's and license files written, which say that we are in touch with Alex and working on getting the clear statement from him that everything released on 06.12.2004 in that file is GPLed and till then provide everything under the GPL as this is what we think was intended (good faith). Is someone volunteering to write that? Best is probably if he followed the discussion and knows the mail from eg Dan Ravicher and those various other mails we gathered on this topic. I guess we will keep both source and data together in one archive (tar.bz2) on release and let distributors seperate them if they need to? If all goes well there won't be a need to split it anyway by the end of February. --Dennis -- Weitergeleitete Nachricht -- Subject: Re: Warzone Licensing Date: Montag, 13. November 2006 03:33 From: [EMAIL PROTECTED] To: "Dennis Schridde" <[EMAIL PROTECTED]> On Tue, 7 Nov 2006 16:44:38 +0100, "Dennis Schridde" <[EMAIL PROTECTED]> said: > Hi! > > Long time not heard from you... > Are there any news on the licensing of Warzone? Did you get Pivotal / > Alex > McLean to say something? Did I miss anything? > > --Dennis Hello ! * Sorry I didn't respond sooner... my job has become all consumming the last few weeks (moved from Colorado to Arizona, set-up new household, training 2 new field op teams, & so on..). * You haven't missed anything, Dennis. * This time of year is super busy for game developers / distributors, holiday deadlines, etc. A.M. won't have time to look into this licencing clarification until after the new year. That's 'bout it. With Coyote making the WZ downloads available @ wztoys - should be able to deal with this situation until Jan - Feb '07 when we can realistically look foward to some progress on the SCi/Eidos front. * I'm used to this slowness from the many years it took to get the source released - WZ is not even on their (SCi's) priority list and they certainly have no intention of taking any action like has been suggested by GPL overseers. * If there is any movement before the end of the year I'll let you know immediately. Cheers, vg --- pgp0tseDwIf4W.pgp Description: PGP signature ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] input.c changes and projectile.c fix
I mean generally for input handling... Wouldn't it be much simpler to just use SDL and in our eventhandler redirect specific events to special functions? (And not have another layer above it. (and not have 1001 places where events are handled, OffTopic)) --Dennis you cannot use the broken 'doubleclick' event in the current code...that's why it was left with a comment '//TODO:double click' imo _ Express yourself instantly with MSN Messenger! Download today it's FREE! http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/ ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Automatic dependencies
Most of the sed code is just magic that I copied from somewhere else, probably http://make.paulandlesley.org/autodep.html which is a must-read. Does that code run always before the %.o: %.c rule is applied to any file? Yes. if we want Makefile.raw to be able to run from within a dos shell (no sed for example). No sed is just the beginning. Does anything of any complexity really run in a DOS shell? I would guess even just make would struggle, with different path delimiters and all that. For those who do not want to run mingw/msys/cygwin, surely just using VS is a better choice. - Per ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] input.c changes and projectile.c fix
> maybe I'll change it to psObj->type != OBJ_TARGET(camera object),there is > only 5 'types' of objects,not need to do that imo.Also,psObj is > BASE_OBJECT,adding new option/flag to that struct might break many things > including netcode... So we should have another item on the TODO? > because both of them are 'Building',I need to set wpRadius to 1 for them,or > their bounding box will be enlarged to unrealistic level(the one kamaze > mentioned in forum) > > damageable flag is only available for 'FEATURE' type,even the transport in > sp campaign uses a hack to prevent it from being destroyed... And yet another item for the TODO list? not sure,I am just avoiding modifying anything that might affect multiplayer code/requires multiplayer code changes. > no,it's just 'reset' the hit bounding box's radius bonus to 1(no bonus) It just looked to me that wpRadius is set before entering the loop of neighbours and is never after set back to the old value (dependend on the wpn), so for other neighbours it would still be 1. But maybe I am wrong, was just a quick look. you are right,wpRadius is never set back to the old value,but it shouldnt be a big problem,since this function is called every game loop/frame. _ Try the next generation of search with Windows Live Search today! http://imagine-windowslive.com/minisites/searchlaunch/?locale=en-us&source=hmtagline ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Automatic dependencies
Am Montag, 13. November 2006 19:12 schrieb Gerard Krol: > Per Inge Mathisen wrote: > > On 11/13/06, Gerard Krol <[EMAIL PROTECTED]> wrote: > >> And it is not that every user needs to run "make depend", it just needs > >> to be done when there are changes to the includes. I believe there > >> are switches to make > >> gcc do the same as makedepend, but a lot slower. > > > > I do not know about slower, but there is no need to add dependencies > > to files that are checked in, at least not if you use gcc -M. > > You mean that the dependency information is already there (in the .c > files) so we should not commit it to SVN another time? > > > The standard way to do this is, it seems, to create new, hidden files > > with > > dependency information for each .c file. In autohell, those are added > > as .Po files in a separate .deps directory. One advantage of this is > > that you do not need to check in changes to dependencies to the > > repository. > > This is a bit of a problem if we want Makefile.raw to be able to run > from within a dos shell (no sed for example). What exactly does this sed magic do, actually? To me it looks like: - Remove comentary lines - ? - Remove ending backslashes - Remove empty lines - ? Is that all needed? I tested it a bit and didn't get any comments or empty lines. Ending backslashes don't seem evil to me, either. Are they interpreted badly by mingw32-make? --Dennis pgpfrcbrvpih8.pgp Description: PGP signature ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Automatic dependencies
Am Montag, 13. November 2006 18:54 schrieb Per Inge Mathisen: > On 11/13/06, Gerard Krol <[EMAIL PROTECTED]> wrote: > > And it is not that every user needs to run "make depend", it just needs > > to be done when there are changes to the includes. I believe there are > > switches to make gcc do the same as makedepend, but a lot slower. > > I do not know about slower, but there is no need to add dependencies > to files that are checked in, at least not if you use gcc -M. The > standard way to do this is, it seems, to create new, hidden files with > dependency information for each .c file. In autohell, those are added > as .Po files in a separate .deps directory. One advantage of this is > that you do not need to check in changes to dependencies to the > repository. > > I had some fun with gnu make and gcc -M a few months ago, and created > a very generalized build system with only those two components, > including configuration checking, 'make dist' and dependency > generation. You can see it at > http://svn.gna.org/viewcvs/buckyball/trunk/ if you are interested. I > do not know how well something like that would scale. Looks interesting... $(OBJDIR)/%.o : %.c $(COMPILE.c) -MD -o $@ $< @mkdir -p $(DEPDIR) @mv $(do).d $(df).d @cp $(df).d $(df).P; \ sed -e 's/#.*//' -e 's/^[^:]*: *//' -e 's/ *\\$$//' \ -e '/^$$/ d' -e 's/$$/ :/' < $(df).d >> $(df).P; \ rm -f $(df).d -include $(SOURCE:%.c=$(DEPDIR)/%.P) Does that code run always before the %.o: %.c rule is applied to any file? Otherwise it should be run before and look similar to gcc -I. -MM -MF file.P file.c (-MM: Don't include system headers in the list.) --Dennis pgpBDEmKEKzbt.pgp Description: PGP signature ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Automatic dependencies
Per Inge Mathisen wrote: On 11/13/06, Gerard Krol <[EMAIL PROTECTED]> wrote: And it is not that every user needs to run "make depend", it just needs to be done when there are changes to the includes. I believe there are switches to make gcc do the same as makedepend, but a lot slower. I do not know about slower, but there is no need to add dependencies to files that are checked in, at least not if you use gcc -M. You mean that the dependency information is already there (in the .c files) so we should not commit it to SVN another time? The standard way to do this is, it seems, to create new, hidden files with dependency information for each .c file. In autohell, those are added as .Po files in a separate .deps directory. One advantage of this is that you do not need to check in changes to dependencies to the repository. This is a bit of a problem if we want Makefile.raw to be able to run from within a dos shell (no sed for example). I had some fun with gnu make and gcc -M a few months ago, and created a very generalized build system with only those two components, including configuration checking, 'make dist' and dependency generation. You can see it at http://svn.gna.org/viewcvs/buckyball/trunk/ if you are interested. I do not know how well something like that would scale. I think it would scale the same way makedepend does, it just is O(n) on .c files, just with a higher constant I guess. - Gerard ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] input.c changes and projectile.c fix
Am Montag, 13. November 2006 18:16 schrieb zz zz:
> > if (asProjNaybors[i].psObj->player != psObj->player &&
> >
> >
> >
> > (asProjNaybors[i].psObj->type == OBJ_DROID ||
> > asProjNaybors[i].psObj->type == OBJ_STRUCTURE ||
> > asProjNaybors[i].psObj->type == OBJ_BULLET ||
> > asProjNaybors[i].psObj->type == OBJ_FEATURE) &&
> >
> >Can't this be put down into classes? ( psObj->class )
> >Or mark all attackable OBJ_... via bitmask? ( psObj->type & CLS_ATTACKABLE
> >)
> >Or add a attackable option to the object? ( psObj->attackable )
>
> maybe I'll change it to psObj->type != OBJ_TARGET(camera object),there is
> only 5 'types' of objects,not need to do that imo.Also,psObj is
> BASE_OBJECT,adding new option/flag to that struct might break many things
> including netcode...
So we should have another item on the TODO?
> > if ( psTempObj->type == OBJ_BULLET )
> > {
> > if ( !bMissile || (((PROJ_OBJECT
> > *)psTempObj)->psWStats->weaponSubClass !=
> >WSC_COUNTER) )
> > {
> > continue;
> > }
> > }
> >
> > //Watermelon:dont apply the 'hitbox' bonus if the
> > target is a building
> > if ( psTempObj->type == OBJ_STRUCTURE ||
> > psTempObj->type ==
> > OBJ_FEATURE) {
> >
> >
> >
> > //Watermelon:ignore oil resource and pickup
> > if ( psTempObj->type == OBJ_FEATURE )
> > {
> > if ( ((FEATURE
> > *)psTempObj)->psStats->damageable == 0)
> >
> >Why check this inside the OBJ_STRUCTURE part? Shouldn't it be an extra
> >part?
> >Also: Why don't check for psObj->damageable directly?
>
> because both of them are 'Building',I need to set wpRadius to 1 for them,or
> their bounding box will be enlarged to unrealistic level(the one kamaze
> mentioned in forum)
>
> damageable flag is only available for 'FEATURE' type,even the transport in
> sp campaign uses a hack to prevent it from being destroyed...
And yet another item for the TODO list?
> > {
> > continue;
> > }
> > }
> >
> >
> >
> > wpRadius = 1;
> >
> >Won't this break?
> >When a projectile flies next to a building it's radius is always reduced
> > to 1
> >it seems to me...
>
> no,it's just 'reset' the hit bounding box's radius bonus to 1(no bonus)
It just looked to me that wpRadius is set before entering the loop of
neighbours and is never after set back to the old value (dependend on the
wpn), so for other neighbours it would still be 1. But maybe I am wrong, was
just a quick look.
pgpWdAbthKcKa.pgp
Description: PGP signature
___
Warzone-dev mailing list
Warzone-dev@gna.org
https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] input.c changes and projectile.c fix
Am Montag, 13. November 2006 18:28 schrieb zz zz:
> >What is this?
> >
> >+if (aKeyState[code] & KEY_RELEASED)
> >+{
> >+aKeyState[code] &= ~KEY_RELEASED;
> >+}
> >+if (aKeyState[code] & KEY_RELEASED)
> >+{
> >+aKeyState[code] &= ~KEY_RELEASED;
> >+}
>
> Think it's a mistake I made,it should be:
> if (aKeyState[code] & KEY_RELEASED)
> {
> aKeyState[code] &= ~KEY_RELEASED;
> }
> if (aKeyState[code] & KEY_PRESSRELEASE)
> {
> aKeyState[code] &= ~KEY_PRESSRELEASE;
> }
>
> >Also: This shall not be an "else if"?
> >
> >+lastKeydown = frameGetFrameNumber();
> >
> >Shouldn't this be "lastKeydown = CurrFrameNum;"?
>
> yes,either should work,though yours might be better and faster.
>
> >And: Why can't SDL be used directly? (We just have another layer above the
> >input...)
> >
> >--Dennis
>
> I am not familiar with SDL,but I think there isnt a 'working' doubleclick
> event in SDL.
I mean generally for input handling... Wouldn't it be much simpler to just use
SDL and in our eventhandler redirect specific events to special functions?
(And not have another layer above it. (and not have 1001 places where events
are handled, OffTopic))
--Dennis
pgpOiQoB597XB.pgp
Description: PGP signature
___
Warzone-dev mailing list
Warzone-dev@gna.org
https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Automatic dependencies
On 11/13/06, Gerard Krol <[EMAIL PROTECTED]> wrote: And it is not that every user needs to run "make depend", it just needs to be done when there are changes to the includes. I believe there are switches to make gcc do the same as makedepend, but a lot slower. I do not know about slower, but there is no need to add dependencies to files that are checked in, at least not if you use gcc -M. The standard way to do this is, it seems, to create new, hidden files with dependency information for each .c file. In autohell, those are added as .Po files in a separate .deps directory. One advantage of this is that you do not need to check in changes to dependencies to the repository. I had some fun with gnu make and gcc -M a few months ago, and created a very generalized build system with only those two components, including configuration checking, 'make dist' and dependency generation. You can see it at http://svn.gna.org/viewcvs/buckyball/trunk/ if you are interested. I do not know how well something like that would scale. - Per ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Automatic dependencies
Am Montag, 13. November 2006 18:30 schrieb Gerard Krol: > Dennis Schridde wrote: > > Am Montag, 13. November 2006 00:04 schrieb Gerard Krol: > >> Dennis Schridde wrote: > >>> 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... > >> > >> Eh, no, makedepend is part of the linux/cygwin x11-bin package, I ran > >> the cygwin version. > >> And it is not that every user needs to run "make depend", it just needs > >> to be done when > >> there are changes to the includes. I believe there are switches to make > >> gcc do the same as > >> makedepend, but a lot slower. > > > > But in the Makefile I found ".PHONY depend"... > > Would mean that he does "depend" on every run, or am I wrong? > > No, ".PHONY" is a flag that signals make that the targets do not produce > a file (such as an .o or .exe), see > http://theory.uwinnipeg.ca/gnu/make/make_33.html We used it for updating the svnversion in src/version.c on every run of make... --Dennis pgpofUciyPMmJ.pgp Description: PGP signature ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Automatic dependencies
Dennis Schridde wrote: Am Montag, 13. November 2006 00:04 schrieb Gerard Krol: Dennis Schridde wrote: 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... Eh, no, makedepend is part of the linux/cygwin x11-bin package, I ran the cygwin version. And it is not that every user needs to run "make depend", it just needs to be done when there are changes to the includes. I believe there are switches to make gcc do the same as makedepend, but a lot slower. But in the Makefile I found ".PHONY depend"... Would mean that he does "depend" on every run, or am I wrong? No, ".PHONY" is a flag that signals make that the targets do not produce a file (such as an .o or .exe), see http://theory.uwinnipeg.ca/gnu/make/make_33.html - Gerard ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] input.c changes and projectile.c fix
What is this?
+ if (aKeyState[code] & KEY_RELEASED)
+ {
+ aKeyState[code] &= ~KEY_RELEASED;
+ }
+ if (aKeyState[code] & KEY_RELEASED)
+ {
+ aKeyState[code] &= ~KEY_RELEASED;
+ }
Think it's a mistake I made,it should be:
if (aKeyState[code] & KEY_RELEASED)
{
aKeyState[code] &= ~KEY_RELEASED;
}
if (aKeyState[code] & KEY_PRESSRELEASE)
{
aKeyState[code] &= ~KEY_PRESSRELEASE;
}
Also: This shall not be an "else if"?
+ lastKeydown = frameGetFrameNumber();
Shouldn't this be "lastKeydown = CurrFrameNum;"?
yes,either should work,though yours might be better and faster.
And: Why can't SDL be used directly? (We just have another layer above the
input...)
--Dennis
I am not familiar with SDL,but I think there isnt a 'working' doubleclick
event in SDL.
-Watermelon
_
Express yourself instantly with MSN Messenger! Download today it's FREE!
http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/
___
Warzone-dev mailing list
Warzone-dev@gna.org
https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] input.c changes and projectile.c fix
if (asProjNaybors[i].psObj->player != psObj->player &&
(asProjNaybors[i].psObj->type == OBJ_DROID ||
asProjNaybors[i].psObj->type == OBJ_STRUCTURE ||
asProjNaybors[i].psObj->type == OBJ_BULLET ||
asProjNaybors[i].psObj->type == OBJ_FEATURE) &&
Can't this be put down into classes? ( psObj->class )
Or mark all attackable OBJ_... via bitmask? ( psObj->type & CLS_ATTACKABLE
)
Or add a attackable option to the object? ( psObj->attackable )
maybe I'll change it to psObj->type != OBJ_TARGET(camera object),there is
only 5 'types' of objects,not need to do that imo.Also,psObj is
BASE_OBJECT,adding new option/flag to that struct might break many things
including netcode...
if ( psTempObj->type == OBJ_BULLET )
{
if ( !bMissile || (((PROJ_OBJECT *)psTempObj)->psWStats->weaponSubClass
!=
WSC_COUNTER) )
{
continue;
}
}
//Watermelon:dont apply the 'hitbox' bonus if the
target is a building
if ( psTempObj->type == OBJ_STRUCTURE ||
psTempObj->type == OBJ_FEATURE)
{
//Watermelon:ignore oil resource and pickup
if ( psTempObj->type == OBJ_FEATURE )
{
if ( ((FEATURE
*)psTempObj)->psStats->damageable == 0)
Why check this inside the OBJ_STRUCTURE part? Shouldn't it be an extra
part?
Also: Why don't check for psObj->damageable directly?
because both of them are 'Building',I need to set wpRadius to 1 for them,or
their bounding box will be enlarged to unrealistic level(the one kamaze
mentioned in forum)
damageable flag is only available for 'FEATURE' type,even the transport in
sp campaign uses a hack to prevent it from being destroyed...
{
continue;
}
}
wpRadius = 1;
Won't this break?
When a projectile flies next to a building it's radius is always reduced to
1
it seems to me...
no,it's just 'reset' the hit bounding box's radius bonus to 1(no bonus),the
comparison function:
if ((xdiff*xdiff + ydiff*ydiff) < (wpRadius *
(SDWORD)(establishTargetRadius(psTempObj)) *
(SDWORD)(establishTargetRadius(psTempObj))) )
{
//hit
}
//not hit
As you can see,the TargetRadiusSquared is multiplied by the 'wpRadius' when
comparing distSquared and TargetRadiusSquared,setting it to '1' wont break
anything as far as I know.The 'wpTargetRaidus' is to compensate the weapons'
inability of hitting moving target after the projectile 'hit' system
changes,now all projectiles have to actually collide with object to do
damage to it.
_
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] input.c changes and projectile.c fix
if (asProjNaybors[i].psObj->player != psObj->player &&
(asProjNaybors[i].psObj->type == OBJ_DROID ||
asProjNaybors[i].psObj->type == OBJ_STRUCTURE ||
asProjNaybors[i].psObj->type == OBJ_BULLET ||
asProjNaybors[i].psObj->type == OBJ_FEATURE) &&
Can't this be put down into classes? ( psObj->class )
Or mark all attackable OBJ_... via bitmask? ( psObj->type & CLS_ATTACKABLE )
Or add a attackable option to the object? ( psObj->attackable )
asProjNaybors[i].psObj->visible[psObj->player] &&
!aiCheckAlliances(asProjNaybors[i].psObj->player,psObj->player))
{
psTempObj = asProjNaybors[i].psObj;
//Watermelon;so a projectile wont collide with another
projectile unless
it's a counter-missile weapon
if ( psTempObj->type == OBJ_BULLET )
{
if ( !bMissile || (((PROJ_OBJECT
*)psTempObj)->psWStats->weaponSubClass !=
WSC_COUNTER) )
{
continue;
}
}
//Watermelon:dont apply the 'hitbox' bonus if the
target is a building
if ( psTempObj->type == OBJ_STRUCTURE ||
psTempObj->type == OBJ_FEATURE)
{
//Watermelon:ignore oil resource and pickup
if ( psTempObj->type == OBJ_FEATURE )
{
if ( ((FEATURE
*)psTempObj)->psStats->damageable == 0)
Why check this inside the OBJ_STRUCTURE part? Shouldn't it be an extra part?
Also: Why don't check for psObj->damageable directly?
{
continue;
}
}
wpRadius = 1;
Won't this break?
When a projectile flies next to a building it's radius is always reduced to 1
it seems to me...
//Watermelon:AA weapon shouldnt hit buildings
if ( psObj->psWStats->surfaceToAir ==
SHOOT_IN_AIR )
{
continue;
}
}
pgpZQuIlWraoZ.pgp
Description: PGP signature
___
Warzone-dev mailing list
Warzone-dev@gna.org
https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] input.c changes and projectile.c fix
Ok, I'll do some heavy testing on mountain maps. ;) (Would it create a negative effects to use z for all? Like performance etc...) In wz,indirect projectile uses velocity XY(2d velocity) only,even though they looked like a trajectory.Using vector z when calculating predicted position for indirect projectiles might reduce their accuracy significantly. So my idea was to remove the 3rd stacked turret from usual heavy bodies and just add it for the still-to-come ultra-heavy-bodies. --Dennis Python is probably too 'narrow' for 3 turrets,'late game' ones might have enough 'width' to fit 2 turrets on parallel + 1 front 'embedded',I'll look for the application to view/edit pie models and try to re-design the turret positions,currently all .pie using the same connector position offsets just for tests sake: 0 original turret position (turret 1) 1 original VTOL turret position (VTOL turret) 2 original VTOL turret position + Vector(0,0,15) (turret 2,half-'embedded' into body) 3 original turret position + Vector(0,0,20) (hence the stacked turret 3) -Watermelon _ Express yourself instantly with MSN Messenger! Download today it's FREE! http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/ ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] input.c changes and projectile.c fix
What is this?
+ if (aKeyState[code] & KEY_RELEASED)
+ {
+ aKeyState[code] &= ~KEY_RELEASED;
+ }
+ if (aKeyState[code] & KEY_RELEASED)
+ {
+ aKeyState[code] &= ~KEY_RELEASED;
+ }
Also: This shall not be an "else if"?
+ lastKeydown = frameGetFrameNumber();
Shouldn't this be "lastKeydown = CurrFrameNum;"?
And: Why can't SDL be used directly? (We just have another layer above the
input...)
--Dennis
pgp3uQEINCeiy.pgp
Description: PGP signature
___
Warzone-dev mailing list
Warzone-dev@gna.org
https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] input.c changes and projectile.c fix
Am Montag, 13. November 2006 09:54 schrieb zz zz: > wzinputpatch2.patch: > > 1.Changed mouse key KEY_STATE enum from 0,1,2,3,4 ... > to 1,2,4,8,16 ... > > 2.Changed aMouseState[MAX_SCANS] from KEY_STATE to UBYTE > > 3.Changed the mouse 'key state' in inputProcessEvent to bitwise > operation,prevously each 'key state' was exclusive,that's what makes > 'double click' event so hard to implement in my opinion. > > 4.Added a static Uint64 CurrFrameNum to get frame number in > InputProcessEvent function,'double click' event is triggered when there are > 2 'KEY_DOWN' events within (1 + frameGetAverageRate()*0.25) frames.(thanks > to Gerard for the '1+frameGetAverageRate()*0.25' idea) > > projfix1.patch: > > 1.Fixed a bug,which enables you to destroy oil resource/artifact/pickup > permanently. > > Problems in previous patches by me: > > 1.Concerning the crash problems with uninitialized asWeaps[0].nStat,the > uninitialized behavior is intended because non-weapon droid's > asWeaps[DROID_MAXWEAPS] should never be ininitialized. > > 2.The uninitialzied numWeaps problem is a compability issue,in old template > format in droid.c,'numWeaps' was commented-out,I re-enabled it recently > when adding multi-turret,so the 2 trucks given to you in skirmish might > have a corrupted or uninitialized numWeaps value under certain > circumstances when copying 'non-exist' numWeaps values from old template > format data. > > 3.I think the crashes have something to do with a bug in original code: > > Droids with 0 weapons/numWeaps were never supposed to be checked in those > functions,but the safety check 'if (psDroid->numWeaps > 0)' in various > functions was commented-out by someone for unknown reason,instead,they use > 'if (psDroid->asWeaps[0].nStat > 0)' hack to check whether a droid has a > weapon or not,which can be bypassed by a '0xcd'/'0xdd' marked uninitialized > value easily and results in a null pointer crash eventually.I just > re-added/uncommented 'if (psDroid->numWeaps > 0)' and it cured the crashes. > > 4.Projectile target prediction vector z is not used for ground units is > because the height difference between 2 ground units is usually > negligible,I'll make all target prediction to take vector z into > consideration if ground units have problems hitting each other on > higher/lower terrain. Ok, I'll do some heavy testing on mountain maps. ;) (Would it create a negative effects to use z for all? Like performance etc...) > 5.The connectors(hardpoints) position problem(2nd and 3rd turret 'stack') > is due to the size problem of a .pie for a 'body',the body pie in wz are > way too small/narrow for multiple weapons,not to mention the turrets are > too big in wz,even light body with 1 ripplerocket looked rediculous.There > is no cure for this unless someone with artistic skills remake the body > pies with greater scale. So my idea was to remove the 3rd stacked turret from usual heavy bodies and just add it for the still-to-come ultra-heavy-bodies. --Dennis pgpArDqcRD5Us.pgp Description: PGP signature ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Automatic dependencies
Am Montag, 13. November 2006 00:04 schrieb Gerard Krol: > Dennis Schridde wrote: > > 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... > > Eh, no, makedepend is part of the linux/cygwin x11-bin package, I ran > the cygwin version. > And it is not that every user needs to run "make depend", it just needs > to be done when > there are changes to the includes. I believe there are switches to make > gcc do the same as > makedepend, but a lot slower. But in the Makefile I found ".PHONY depend"... Would mean that he does "depend" on every run, or am I wrong? --Dennis pgpuoYRBnu2Qh.pgp Description: PGP signature ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
[Warzone-dev] input.c changes and projectile.c fix
wzinputpatch2.patch:
1.Changed mouse key KEY_STATE enum from 0,1,2,3,4 ...
to 1,2,4,8,16 ...
2.Changed aMouseState[MAX_SCANS] from KEY_STATE to UBYTE
3.Changed the mouse 'key state' in inputProcessEvent to bitwise
operation,prevously each 'key state' was exclusive,that's what makes 'double
click' event so hard to implement in my opinion.
4.Added a static Uint64 CurrFrameNum to get frame number in
InputProcessEvent function,'double click' event is triggered when there are
2 'KEY_DOWN' events within (1 + frameGetAverageRate()*0.25) frames.(thanks
to Gerard for the '1+frameGetAverageRate()*0.25' idea)
projfix1.patch:
1.Fixed a bug,which enables you to destroy oil resource/artifact/pickup
permanently.
Problems in previous patches by me:
1.Concerning the crash problems with uninitialized asWeaps[0].nStat,the
uninitialized behavior is intended because non-weapon droid's
asWeaps[DROID_MAXWEAPS] should never be ininitialized.
2.The uninitialzied numWeaps problem is a compability issue,in old template
format in droid.c,'numWeaps' was commented-out,I re-enabled it recently when
adding multi-turret,so the 2 trucks given to you in skirmish might have a
corrupted or uninitialized numWeaps value under certain circumstances when
copying 'non-exist' numWeaps values from old template format data.
3.I think the crashes have something to do with a bug in original code:
Droids with 0 weapons/numWeaps were never supposed to be checked in those
functions,but the safety check 'if (psDroid->numWeaps > 0)' in various
functions was commented-out by someone for unknown reason,instead,they use
'if (psDroid->asWeaps[0].nStat > 0)' hack to check whether a droid has a
weapon or not,which can be bypassed by a '0xcd'/'0xdd' marked uninitialized
value easily and results in a null pointer crash eventually.I just
re-added/uncommented 'if (psDroid->numWeaps > 0)' and it cured the crashes.
4.Projectile target prediction vector z is not used for ground units is
because the height difference between 2 ground units is usually
negligible,I'll make all target prediction to take vector z into
consideration if ground units have problems hitting each other on
higher/lower terrain.
5.The connectors(hardpoints) position problem(2nd and 3rd turret 'stack') is
due to the size problem of a .pie for a 'body',the body pie in wz are way
too small/narrow for multiple weapons,not to mention the turrets are too big
in wz,even light body with 1 ripplerocket looked rediculous.There is no cure
for this unless someone with artistic skills remake the body pies with
greater scale.
- Watermelon
_
Don't just search. Find. Check out the new MSN Search!
http://search.msn.com/
Index: input.c
===
--- input.c (revision 469)
+++ input.c (working copy)
@@ -25,18 +25,18 @@
/* The possible states for keys */
typedef enum _key_state
{
- KEY_UP,
- KEY_PRESSED,
- KEY_DOWN,
- KEY_RELEASED,
- KEY_PRESSRELEASE, // When a key goes up and down in a frame
- KEY_DOUBLECLICK,// Only used by mouse keys
- KEY_DRAG, // Only used by mouse keys
+ KEY_UP = 1,
+ KEY_PRESSED = 2,
+ KEY_DOWN = 4,
+ KEY_RELEASED = 8,
+ KEY_PRESSRELEASE = 16, // When a key goes up and down in a frame
+ KEY_DOUBLECLICK = 32, // Only used by mouse keys
+ KEY_DRAG = 64, // Only used by mouse keys
} KEY_STATE;
/* The current state of the keyboard */
-static KEY_STATE aKeyState[KEY_MAXSCAN];
+static UBYTE aKeyState[KEY_MAXSCAN];
/* The current location of the mouse */
static SDWORD mouseXPos, mouseYPos;
@@ -51,7 +51,7 @@
static SDWORD dragX, dragY;
/* The current mouse button state */
-static KEY_STATE aMouseState[6];
+static UBYTE aMouseState[6];
/* The size of the input buffer */
@@ -65,6 +65,8 @@
static char *pCharStartBuffer, *pCharEndBuffer;
static char currentChar;
+//Watermelon:lastKeydown;
+static Uint64 lastKeydown;
static KEY_CODE sdlKeyToKeyCode(SDLKey key)
{
@@ -101,12 +103,12 @@
for(i=0; itype)
{
@@ -267,22 +273,36 @@
}
code = sdlKeyToKeyCode(event->key.keysym.sym);
- if ((aKeyState[code] == KEY_UP) ||
- (aKeyState[code] == KEY_RELEASED) ||
- (aKeyState[code] == KEY_PRESSRELEASE))
+ if ((aKeyState[code] & KEY_UP) ||
+ (aKeyState[code] & KEY_RELEASED) ||
+ (aKeyState[code] & KEY_PRESSRELEASE))
{
- aKeyState[code] = KEY_PRESSED;
+ if (aKeyState[code] & KEY_UP)
+ {
+ aKe
