Re: [Warzone-dev] Re: [Warzone-commits] r686 - /trunk/src/projectile.c
On Sun, 28 Jan 2007 20:59:17 -0800, The Watermelon [EMAIL PROTECTED] wrote: On 1/28/07, Giel van Schijndel [EMAIL PROTECTED] wrote: Author: muggenhor Date: Sun Jan 28 19:19:32 2007 New Revision: 686 URL: http://svn.gna.org/viewcvs/warzone?rev=686view=rev Log: Modification 8 by Watermelon's bugfix patch: * Changed establishTargetHeight in projectile.c to use pIMD rather than displayImd for structures to fix some weird height problems(hopefully). * Giel: Slightly changed the patch's modifications to increase code readability Refer: Message-ID: [EMAIL PROTECTED] Modified: trunk/src/projectile.c some of your change swapped the correct order and causes crash: * height = asBodyStats[psDroid-asBits[COMP_BODY].nStat].pIMD-ymax - asBodyStats[psDroid-asBits[COMP_BODY].nStat].pIMD-ymin;* * psDroid = (DROID*)psTarget;* it tried to access psDroid pointer before it gets initialized as (DROID*)psTarget,the original/correct order is: * psDroid = (DROID*)psTarget; height = asBodyStats[psDroid-asBits[COMP_BODY].nStat].pIMD-ymax - asBodyStats[psDroid-asBits[COMP_BODY].nStat].pIMD-ymin;* It seems Ari fixed this in r688. Would have been nice if the compiler would just kick my ass on this sorts of cases (dereferencing uninitialized pointers). -- Giel ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Fixed using wrong rev as base when changing piedraw.c
Am Sonntag, 28. Januar 2007 schrieb Dennis Schridde: Am Sonntag, 28. Januar 2007 schrieb The Watermelon: Ugly typo: Some notes: - Please DONT create patches which just comment out something. Remove it or don't remove it. We can allways revert using SVN and in the patch we see what you changed, too, so I see really no point to add huge amounts of commented out code. pgpMQQaYzhc6b.pgp Description: PGP signature ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Re: [Warzone-commits] r686 - /trunk/src/projectile.c
Am Montag, 29. Januar 2007 schrieb Giel van Schijndel: On Sun, 28 Jan 2007 20:59:17 -0800, The Watermelon [EMAIL PROTECTED] wrote: On 1/28/07, Giel van Schijndel [EMAIL PROTECTED] wrote: Author: muggenhor Date: Sun Jan 28 19:19:32 2007 New Revision: 686 URL: http://svn.gna.org/viewcvs/warzone?rev=686view=rev Log: Modification 8 by Watermelon's bugfix patch: * Changed establishTargetHeight in projectile.c to use pIMD rather than displayImd for structures to fix some weird height problems(hopefully). * Giel: Slightly changed the patch's modifications to increase code readability Refer: Message-ID: [EMAIL PROTECTED] Modified: trunk/src/projectile.c some of your change swapped the correct order and causes crash: * height = asBodyStats[psDroid-asBits[COMP_BODY].nStat].pIMD-ymax - asBodyStats[psDroid-asBits[COMP_BODY].nStat].pIMD-ymin;* * psDroid = (DROID*)psTarget;* it tried to access psDroid pointer before it gets initialized as (DROID*)psTarget,the original/correct order is: * psDroid = (DROID*)psTarget; height = asBodyStats[psDroid-asBits[COMP_BODY].nStat].pIMD-ymax - asBodyStats[psDroid-asBits[COMP_BODY].nStat].pIMD-ymin;* It seems Ari fixed this in r688. Would have been nice if the compiler would just kick my ass on this sorts of cases (dereferencing uninitialized pointers). I thought GCC does with -Wall... pgpUvsnKFNrds.pgp Description: PGP signature ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Re: [Warzone-commits] r686 - /trunk/src/projectile.c
On Mon, 29 Jan 2007 13:00:43 +0100, Dennis Schridde [EMAIL PROTECTED] wrote: Am Montag, 29. Januar 2007 schrieb Giel van Schijndel: On Sun, 28 Jan 2007 20:59:17 -0800, The Watermelon [EMAIL PROTECTED] wrote: On 1/28/07, Giel van Schijndel [EMAIL PROTECTED] wrote: Author: muggenhor Date: Sun Jan 28 19:19:32 2007 New Revision: 686 URL: http://svn.gna.org/viewcvs/warzone?rev=686view=rev Log: Modification 8 by Watermelon's bugfix patch: * Changed establishTargetHeight in projectile.c to use pIMD rather than displayImd for structures to fix some weird height problems(hopefully). * Giel: Slightly changed the patch's modifications to increase code readability Refer: Message-ID: [EMAIL PROTECTED] Modified: trunk/src/projectile.c some of your change swapped the correct order and causes crash: * height = asBodyStats[psDroid-asBits[COMP_BODY].nStat].pIMD-ymax - asBodyStats[psDroid-asBits[COMP_BODY].nStat].pIMD-ymin;* * psDroid = (DROID*)psTarget;* it tried to access psDroid pointer before it gets initialized as (DROID*)psTarget,the original/correct order is: * psDroid = (DROID*)psTarget; height = asBodyStats[psDroid-asBits[COMP_BODY].nStat].pIMD-ymax - asBodyStats[psDroid-asBits[COMP_BODY].nStat].pIMD-ymin;* It seems Ari fixed this in r688. Would have been nice if the compiler would just kick my ass on this sorts of cases (dereferencing uninitialized pointers). I thought GCC does with -Wall... I believe it does, yes. The only problem is that I need to distinguish those warnings from the ones already present. Hmm, maybe that's a nice idea for some spare time: writing a diff-utility that generates diffs on compiler warnings/errors. Although maybe a bit far fetched. -- Giel ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Re: [Warzone-commits] r686 - /trunk/src/projectile.c
On 1/29/07, Giel van Schijndel [EMAIL PROTECTED] wrote: Hmm, maybe that's a nice idea for some spare time: writing a diff-utility that generates diffs on compiler warnings/errors. Or just fixing those already present? I have to say, though: adding a ton of new warning flags to gcc for the debug builds may not have been a very bright idea. I think it would be better with the general rule that you do not add a new flag before you have removed the warnings it would generate *first* (ie the flag is there to avoid regressions, not to nag people about your TODO list). - Per ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Current problems
On Mon, 29 Jan 2007 08:40:28 -0500, Ari Johnson [EMAIL PROTECTED] wrote: I was wrong - this no longer comes up. However, I saved the game a few times and once this one came up: error: Returned savegame/test.gam Not sure what that means. From _runLoadSave(), if when returning TRUE strlen(sRequestResult) != 0 then a valid game slot was selected otherwise cancel was selected. In hci.c at line 1771, the code checks strlen(sRequestResult) and prints a debug message with LOG_ERROR. This should probably be LOG_NEVER or something similar, since it's not an error. Note that one reason the output I got before may have gone away is that I accidentally reconfigured without --debug. I'll report back as I run into things, but this is definitely getting much cleaner as we go. How about using config.status? It should be generated by configure and retains your configure flags/parameters. -- Giel ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Re: [Warzone-commits] r686 - /trunk/src/projectile.c
On Mon, 29 Jan 2007 15:20:54 +0100, Per Inge Mathisen [EMAIL PROTECTED] wrote: On 1/29/07, Giel van Schijndel [EMAIL PROTECTED] wrote: Hmm, maybe that's a nice idea for some spare time: writing a diff-utility that generates diffs on compiler warnings/errors. Or just fixing those already present? Yes, and not commiting code that adds new ones. I have to say, though: adding a ton of new warning flags to gcc for the debug builds may not have been a very bright idea. I think it would be better with the general rule that you do not add a new flag before you have removed the warnings it would generate *first* (ie the flag is there to avoid regressions, not to nag people about your TODO list). Honestly I don't know what you're talking about here. Since only -Wall is currently passed to gcc for generation of compiler warnings. Unless you count -fpermissive along, which actually turns certain (resolvable) compiler errors into warnings. -- Giel ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Current problems
On 1/29/07, Giel van Schijndel [EMAIL PROTECTED] wrote: On Mon, 29 Jan 2007 08:40:28 -0500, Ari Johnson [EMAIL PROTECTED] wrote: I was wrong - this no longer comes up. However, I saved the game a few times and once this one came up: error: Returned savegame/test.gam Not sure what that means. From _runLoadSave(), if when returning TRUE strlen(sRequestResult) != 0 then a valid game slot was selected otherwise cancel was selected. In hci.c at line 1771, the code checks strlen(sRequestResult) and prints a debug message with LOG_ERROR. This should probably be LOG_NEVER or something similar, since it's not an error. Note that one reason the output I got before may have gone away is that I accidentally reconfigured without --debug. I'll report back as I run into things, but this is definitely getting much cleaner as we go. How about using config.status? It should be generated by configure and retains your configure flags/parameters. I occasionally do a fresh checkout / configure / compile to make sure there's nothing missing from that process. ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Fixed using wrong rev as base when changing piedraw.c
Am Montag, 29. Januar 2007 schrieb The Watermelon: On 1/29/07, Dennis Schridde [EMAIL PROTECTED] wrote: Am Sonntag, 28. Januar 2007 schrieb Dennis Schridde: Am Sonntag, 28. Januar 2007 schrieb The Watermelon: Ugly typo: Some notes: - Please DONT create patches which just comment out something. Remove it or don't remove it. We can allways revert using SVN and in the patch we see what you changed, too, so I see really no point to add huge amounts of commented out code. Removed commented-out lines and move a glMatrixPop and a glMatrixPush out of 'for loop' in pie_DrawRemainingTransShapes in piedraw.c(glLoadIdentity does top stack replacement,no need to do glMatrixPop and glMatrixPush inside 'for loop' imo). display3d.c @@ -1607,9 +1607,9 @@ Can't p[0].x = tileScreenInfo[i+0][j+0].sx; p[0].y = tileScreenInfo[i+0][j+0].sy; p[0].z = tileScreenInfo[i+0][j+0].sz; be replaced with p[0] = tileScreenInfo[i+0][j+0]; or is that not possible because of different data types? Similar things are done in several other locations, too. Maybe some more types can get their x,y,z and u,v coordinates replaced by Vector3 and Vector2 ? Another suggestion would also be to replace pos with position. But I don't exactly know if that's a correct naming anyway. Is the x,y,z in a vertex a position? This is nothing really important. The name position doesn't seem to fit for me, but it may very well be that I am totally wrong. Can iVertex and PIEVERTEX be merged? It seems to me that they are mostly the same. (What does the g field in iVertex mean?) There is also a PIEVECTORF, can't that be replaced by Vector3, too? And iVectorf? Replace it with Vector3d? Ohwowow... I just saw that you replaced iVectorf with Vector3f... That doesn't look good, since iVectorf used doubles, while Vector3f is about floats... Typedefinitions should go with the SDL types, if they are providing an API, IMO. Makes it more obvious what they are representing and in the long run I wanted to replace all Win types with SDL types anyway. iVertex is missing a space in the list. Looks better if it gets it. ;) (Yes, this is a bit nitpicking, but I would forget to change it myself before applying or after someone else applied it.) The name MakeVector3fInt should be improved IMO... Vector3_Float2Int maybe? Is there a commonly used name for such conversions? --Dennis pgpb5dXdLxWV8.pgp Description: PGP signature ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Re: [Warzone-commits] r686 - /trunk/src/projectile.c
Am Montag, 29. Januar 2007 schrieb Christian Ohm: On Monday, 29 January 2007 at 14:55, Giel van Schijndel wrote: Hmm, maybe that's a nice idea for some spare time: writing a diff-utility that generates diffs on compiler warnings/errors. Although maybe a bit far fetched. Tried that some time ago. Not perfect, but works. Looks nice! Why did you use tee and not output-redirection to create make-out.tmp? What I wonder about is that with the sort you use lines like ../lib/sound/track.c: In function ‘sound_PauseTrack’: ../lib/sound/track.c:504: warning: comparison between signed and unsigned might (will?) loose their connection... Maybe the script could be enhanced so it can set a reference point (eg before work, so you don't have compare small incremental steps, but can also look a little further back and see not only what you changed in the last minutes, but also what you changed since your last commit.) --Dennis pgpB9UHYxybMt.pgp Description: PGP signature ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Fixed using wrong rev as base when changing piedraw.c
Am Montag, 29. Januar 2007 schrieb The Watermelon: On 1/29/07, Dennis Schridde [EMAIL PROTECTED] wrote: display3d.c @@ -1607,9 +1607,9 @@ Can't p[0].x = tileScreenInfo[i+0][j+0].sx; p[0].y = tileScreenInfo[i+0][j+0].sy; p[0].z = tileScreenInfo[i+0][j+0].sz; be replaced with p[0] = tileScreenInfo[i+0][j+0]; or is that not possible because of different data types? tileScreenInfo is a SVMESH while p is a Vector3f... Yes, but it contains something that can be seen as a Vector3... Similar things are done in several other locations, too. Maybe some more types can get their x,y,z and u,v coordinates replaced by Vector3 and Vector2 ? Another suggestion would also be to replace pos with position. But I don't exactly know if that's a correct naming anyway. Is the x,y,z in a vertex a position? This is nothing really important. The name position doesn't seem to fit for me, but it may very well be that I am totally wrong. Can iVertex and PIEVERTEX be merged? It seems to me that they are mostly the same. (What does the g field in iVertex mean?) I dont know what the 'g' field is in iVertex either...havent looked at functions that use it...seems to be some color byte... There is also a PIEVECTORF, can't that be replaced by Vector3, too? yes i think it can be safely replaced by Vector3f too... And iVectorf? Replace it with Vector3d? Ohwowow... I just saw that you replaced iVectorf with Vector3f... That doesn't look good, since iVectorf used doubles, while Vector3f is about floats... iVectorf is useless because it will eventually get abused to integer in imdload.c,which is the only instance of iVectorf iirc. I am currently looking into the possibility to change all those x,y,z in PIEVERTEX and other pie structs to float from sint32 to increase the precision of pie point coords like someone suggested in forum,and change imdload function to use '%5.5f'(just a random number) to sscanf imd points in pie files,though all exist pie files will need to be changed to cope with such changes i think... I will change it to Vector3d for better readability anyways. Well, if that Vector3x stores floats, then it should be named Vector3f. My Vector3d was not because it is a vector in 3 dimensional space, but because it is a vector of 3 doubles. So if this vector is never used as a double, but only to store ints, then it should be removed and replaced by Vector3i and not Vector3f... But if it gets to store floats, then it should sure be named Vector3f, as you did it. My name was only for a third Vector3, which should store doubles, because the old iVectorf stored doubles, too. And I don't think it is safe to replace something that assumes to be double with a float. Typedefinitions should go with the SDL types, if they are providing an API, IMO. Makes it more obvious what they are representing and in the long run I wanted to replace all Win types with SDL types anyway. iVertex is missing a space in the list. Looks better if it gets it. ;) (Yes, this is a bit nitpicking, but I would forget to change it myself before applying or after someone else applied it.) The name MakeVector3fInt should be improved IMO... Vector3_Float2Int maybe? Is there a commonly used name for such conversions? --Dennis not sure about the naming stuff Me neither. ;) I just think that MakeVector3fInt is not a very good name. ;) pgpQRzH3hX8Lh.pgp Description: PGP signature ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Re: [Warzone-commits] r686 - /trunk/src/projectile.c
On Monday, 29 January 2007 at 16:39, Dennis Schridde wrote: Looks nice! Why did you use tee and not output-redirection to create make-out.tmp? What I wonder about is that with the sort you use lines like ../lib/sound/track.c: In function ‘sound_PauseTrack’: ../lib/sound/track.c:504: warning: comparison between signed and unsigned might (will?) loose their connection... Yeah, and I don't get error messages there as well. That's what the tee is for, you get the usual output for context, and the diff gives the changes in the warning messages. Maybe the script could be enhanced so it can set a reference point (eg before work, so you don't have compare small incremental steps, but can also look a little further back and see not only what you changed in the last minutes, but also what you changed since your last commit.) Well, my script is of the quick and dirty variant, it just works good when compiling the same set of files. -- I can remember when a good politician had to be 75 percent ability and 25 percent actor, but I can well see the day when the reverse could be true. -- Harry Truman ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
[Warzone-dev] Backport fixes to branches/2.0
Hello everyone! If someone fixes a bug (which apparently happened often lately) and the bug is also present in 2.0.5, perhaps he could also backport that fix to branches/2.0 or at least reply here or add a comment to the commit-message, so we/I know what we/I can and need to backport to 2.0... Thanks, Dennis pgp70I2hRajBh.pgp Description: PGP signature ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
[Warzone-dev] Current status of networking code
What is the current status of the network code? I have been holding off trying to get it to work for Macs for a while because I heard that there was a major overhaul underway. Let me know - that's the next thing to get working on the Mac. ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Current status of networking code
On 1/29/07, Ari Johnson [EMAIL PROTECTED] wrote: What is the current status of the network code? I have been holding off trying to get it to work for Macs for a while because I heard that there was a major overhaul underway. Let me know - that's the next thing to get working on the Mac. It is not currently underway. I was working on it, but it is currently waiting for me to get more spare time. How were you considering fixing it? If it involves concentrating the network code and cleaning it up, nothing could be better for helping things along. - Per ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
[Warzone-dev] VC2005 devpkg files?
I did a clean install of everything, and when I went back to redownload warzone, it seems that the devpkg files are only there for mingw? Before, there were ones for VC 2005. VC2005 can't use ..a files, it is wrong format. Where did those get moved to on the GNA site? Concerned about your privacy? Instantly send FREE secure email, no account required http://www.hushmail.com/send?l=480 Get the best prices on SSL certificates from Hushmail https://www.hushssl.com?l=485 ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
