[Warzone-dev] patches again
Is anyone looking at all these patches on the ML, or should I stop post them? I am just looks for patch comments like under review, rejected, accepted comments? These wait, June 2 -Oil animation fix health bar. June 23 - First small patch in data.c fix 1 issue. Submit again patch for oil health bar fix. Next patch fix (avoid) bug #9235 (maybe others also). Shadows for wall are not correct, but this small price to pay instead of crashing out of game. Code is just comment out, until you devs decide what best way to fix using static local vars. I have no heard any response when ask. I think it better to do this then crash in game when read details on #9235. Next small patch fix Vector3i use instead of Vector3f. Both parameters is Vector3f. June 27-Fix broken menu broken in rev 1606 June 27 -Enable Fireworks when win again June 27-[Warzone-dev] [patch]Re: displayBufferSize DisplayBuffer (change Displaybuffer to GeneralBuffer, cut it from 5MB to 200K) June 30 - fix lighting -- Click for discounts on certified diamonds and engagement rings http://tagline.hushmail.com/fc/Ioyw6h4ee5pY1i7iPXm4wIcf7ISi7VnKrxGHyahpsyL8KdN0qB9SEm/ ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] [patch] Make lighting work again !
On Sat, 30 Jun 2007 08:04:21 -0400 Dennis Schridde [EMAIL PROTECTED] wrote: Am Samstag, 30. Juni 2007 schrieb [EMAIL PROTECTED]: Another 1 line fix. This make it so game is back to original lighting. Was broken by Dennis, no reason give on change? (when select unit, it strobe again, and when damage unit/building, it gets more dark until it die). When light=true, that make all bright, I thinks this is for debug something. It is not a bug, but a feature. Really, this time. It also ain't nothing to do with debuging. It just uses OpenGL lighting in favour of custom color modifications. The change was intended. The strobe and damage thingies just need to be adapted to modify the material of the object. OK, but until you fix whatever, why not leave that to FALSE, so people can get expected visuals? -- Want a little romance in your life? Click here for romantic candles. http://tagline.hushmail.com/fc/Ioyw6h4ebVTnrrvYZXqvcXgxmLuhnGtO8kcenDoAZVhiUSeUdRpOF4/ ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] [patch]Re: displayBufferSize DisplayBuffer ?
On Wed, 27 Jun 2007 16:00:10 -0400 [EMAIL PROTECTED] wrote: I forgot to say, if want, you could reallocate memory when it detects buffer too small. Other option is to rewrite all those functions to use local variables, instead of the global. Lots of work to do this. Not sure worth it? After looking at code, best thing to **NOT** do away with GeneralBuffer. (displaybuffer). Reason is there are ~628 calls to load into this buffer. Now we have 1 malloc, and 1 free, so that is tons less malloc/free calls we no have to worry about. In hunt for memory leaks, I know now is not present in those routines that use this. So no more changes to that is best until find other leaks. -- Getting Married? Click for People's top wedding picks http://tagline.hushmail.com/fc/Ioyw6h4emakO3gyVpQtj1YVSMyQSXbPSSDTBuDkPvUkIVQLP1nRsOy/ ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] [patch]Re: displayBufferSize DisplayBuffer ?
On Thu, 28 Jun 2007 02:43:45 -0400 [EMAIL PROTECTED] wrote: After looking at code, best thing to **NOT** do away with GeneralBuffer. (displaybuffer). Reason is there are ~628 calls to load into this buffer. Now we have 1 malloc, and 1 free, so that is tons less malloc/free calls we no have to worry about. In hunt for memory leaks, I know now is not present in those routines that use this. So no more changes to that is best until find other leaks. Should not post so late at night. ;) I read my logs backwards. Sorry. GeneralBuffer is use for .gam/bjo/map/ttp files, and so on. It *not* use for wrf/pie/vlo/slo/txt/lev files ... confusion was because the routine that load these resLoad() in frameresource.c has, pFileBuffer = pLoadBuffer; fileBufferSize = bufferSize; These point to GeneralBuffer GeneralBufferSize, **BUT** they are not even use!! BOOL resLoad(const char *pResFile, SDWORD blockID, char *pLoadBuffer, SDWORD bufferSize) Should be then BOOL resLoad(const char *pResFile, SDWORD blockID) resLoad uses own local buffer pointer, and free it when done, or we can change to really use GeneralBuffer GeneralBufferSize. well, it late. night. :) -- Click for special offer on replacement windows - energy efficient http://tagline.hushmail.com/fc/Ioyw6h4eNoT7eVpHUQALGfy7Dxf6bWPdi9wHyY5blvYI2V204itD58/ ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
[Warzone-dev] leaks patches
Looks like flex files leak, this is from run skirmish, 4p, quit as soon as you see base, then quit out of program. Also script_parser.y and so on leak. It no look like any cleanup is done. Also, any plans to commit patches waiting on mailing list sometime this week? This small sample of memory leaks: BYTE SIZE: 72 BLOCK # 311802 FILENAME: ...\lib\script\script_parser.y LINE #: 3293 BYTE SIZE: 72 BLOCK # 315896 FILENAME: ...\lib\script\script_parser.y LINE #: 1309 BYTE SIZE: 72 BLOCK # 317020 FILENAME: ...\lib\script\script_parser.y LINE #: 3293 BYTE SIZE: 72 BLOCK # 317378 FILENAME: ...\lib\script\script_parser.y LINE #: 3293 BYTE SIZE: 2400 BLOCK #3350 FILENAME: \lib\sound\track.c LINE #: 66 BYTE SIZE: 5632 BLOCK # 352443 FILENAME: \lib\ivis_opengl\piedraw.c LINE #: 768 BYTE SIZE: 5632 BLOCK # 352451 FILENAME: \lib\ivis_opengl\piedraw.c LINE #: 736 BYTE SIZE: 6173 BLOCK # 233740 FILENAME: script_lexer.lex.c LINE #: 2761 BYTE SIZE:12596 BLOCK # 123496 FILENAME: * LINE #: 0 BYTE SIZE:16364 BLOCK #3414 FILENAME: \src\astar.c LINE #: 130 BYTE SIZE:16386 BLOCK #1867 FILENAME: level_lexer.lex.c LINE #: 1818 BYTE SIZE:16386 BLOCK #3871 FILENAME: resource_lexer.lex.c LINE #: 1707 BYTE SIZE:16386 BLOCK # 16015 FILENAME: audp_lexer.lex.c LINE #: 1731 BYTE SIZE:16386 BLOCK # 16028 FILENAME: strres_lexer.lex.c LINE #: 1676 BYTE SIZE:16386 BLOCK # 350964 FILENAME: scriptvals_lexer.lex.c LINE #: 1800 BYTE SIZE: 103901 BLOCK # 235387 FILENAME: script_lexer.lex.c LINE #: 2761 BYTE SIZE: 103901 BLOCK # 264281 FILENAME: script_lexer.lex.c LINE #: 2761 BYTE SIZE: 103901 BLOCK # 293175 FILENAME: script_lexer.lex.c LINE #: 2761 BYTE SIZE: 103901 BLOCK # 322069 FILENAME: script_lexer.lex.c LINE #: 2761 -- Click for discounts on certified diamond jewelry - up to 50% off http://tagline.hushmail.com/fc/Ioyw6h4e9Tmv7FnIZC6okejKmMfGZitXiN4F77yehFRKfLmcmB8V10/ ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] [patch] Enable Fireworks when win again!
On Wed, 27 Jun 2007 03:22:12 -0400 Gerard Krol [EMAIL PROTECTED] wrote: I just love breaking things ;) If I remember correctly I wanted to display the statistics about the game (kills etc.) at the end of a multiplayer game. It should be possible to enable fireworks again without removing this functionality. The intRemoveMissionResultNoAnim might have something to do with an empty blue intelligence box appearing at the bottom of the screen when you were defeated, but I'm not sure about that. - Gerard I no change that with that line that was comment out. I see that screen when you are defeated with stats. Now, when win, you see black screen (for video I thinks), then you hit ESC, then a intel screen pops up with fireworks in background, then you close intel screen and fireworks still going off. I no think I ever see stats when you win, but all I do after fireworks is select quit. -- Click for discounts on certified diamonds and engagement rings http://tagline.hushmail.com/fc/Ioyw6h4ee5o9vHaIrmk34HMX4yCDKFxkDPTiKID2QlU0T2b46YoEFI/ ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
[Warzone-dev] [patch]Re: displayBufferSize DisplayBuffer ?
On Wed, 27 Jun 2007 08:37:38 -0400 Giel van Schijndel [EMAIL PROTECTED] wrote: Well it seems that this var, DisplayBuffer, is a global var. I guess implemented there as some misguided attempt at saving a few bytes of memory. The problem is that this global var is so widely spread, that I'm having _a_lot_ of trouble, tracking its state throughout program execution. So unfortunately I cannot just rip this var out. If you (or anyone else) has any idea of any location where the usage of DisplayBuffer can, *safely*, be removed please feel free to point that location out or to submit a patch. The original DisplayBuffer was use for 3dfx, and software rendering, and also loading files. PS2 is faults here, since they need to conserve memory. This patch renames DisplayBuffer to GeneralBuffer, displaybuffersize to generalbuffersize. The size if now 200k instead of 5MB. Played 2 SP levels, and 2 skirmish games, with no error message that size is too small. So a savings of 4.8MB :) It will print message in logs if too small. I no see any file in data directory that is over 200K though. -- Click for discounts on certified diamonds and engagement rings http://tagline.hushmail.com/fc/Ioyw6h4ee5oy07N5UjooVEhRuEOOWeBdRe43eebMI0G8by5yGz9kbs/ Generalbuffer.diff Description: Binary data ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] [Final patch] Patch to fix player name PICK name.
On Tue, 26 Jun 2007 09:55:17 -0400 Giel van Schijndel [EMAIL PROTECTED] wrote: Giel van Schijndel schreef: [EMAIL PROTECTED] schreef: Sorry, I no know that physfs no auto convert / \. I use PHYSFS_getDirSeparator() now. This patch fix problem for linux. (tested) ***DELETE ALL *.sta in multiplay\players !! on windows, it is in profile directory dir for warzone. on linux it is ~/.warzone I thinks it was. Firstly you use PHYSFS_addToSearchPath, you simply shouldn't touch any part of the search path after initialization. Then there are some other problems with this patch one of them being that it won't work with any other files than the .sta files (and this function is meant to work with more). Also it assumes that all directories always only contain the correct files (i.e. multiplay/players is _always_ expected to contain *.sta files only, which is a dangerous assumption. Anyway apart from that this patch did inspire me to rewrite this function entirely myself. So thanks for pointing out the problem. PS Looking at your patch I'm getting to think that you somehow where reluctant to change the function's declaration/signature (i.e. the list of arguments + return value type). If you think it might be better to change the function's signature then just do so a next time. Yes, I rather change function, but I no know if it is OK or not. I also know about only thinking of *.sta files in that directory. I try to do search of *.sta, but it never works for me, so in end, I just said players directory. Original for windows did only check *.sta, this also why I left the correct me comments, since I no not how to do *.sta when I try. -- Click for discounts on fashionable Italian charm bracelets http://tagline.hushmail.com/fc/Ioyw6h4eoPxHojNj5CNsxnoyxCGkVcDvvs55ziBL3JUgUigqQp9gRI/ ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Patch fixes
Any response to these patches?
When apply patch to fix bug #9235 (below), you see, multiple runs
of game will show a huge memory leak. Looking at windows task
manager while game is running, and quit out of skirmish (or mp
game), then again run, and quit, and run, I see that all memory in
system is used up, and page file is over 1GB in size until quit
game.
On Sat, 23 Jun 2007 17:21:30 -0400 vs2k5 wrote:
First small patch in data.c fix 1 issue.
Submit again patch for oil health bar fix.
Next patch fix (avoid) bug #9235 (maybe others also).
Shadows for wall are not correct, but this small price to pay
instead of crashing out of game. Code is just comment out, until
you devs decide what best way to fix using static local vars. I
have no heard any response when ask. I think it better to do this
then crash in game when read details on #9235.
Next small patch fix Vector3i use instead of Vector3f. Both
parameters is Vector3f.
Index: data.c
===
--- data.c (revision 1591)
+++ data.c (working copy)
@@ -932,8 +932,10 @@
}
if (Tpage-Palette != NULL)
free(Tpage-Palette);
+
free(Tpage);
+ Tpage=NULL;
}
Index: display3d.c
===
--- display3d.c(revision 1591)
+++ display3d.c(working copy)
@@ -1522,7 +1522,8 @@
psComp-orientation.y = vecRot.y;
psComp-orientation.z = vecRot.z;
- renderAnimComponent( psComp );
+ bucketAddTypeToList( RENDER_ANIMATION, psComp );//This
needed
to correctly draw ANIM frame.
+//renderAnimComponent( psComp );//we no want to draw base
on
position!
}
}
}
@@ -2430,9 +2431,9 @@
UDWORD buildingBrightness, specular;
// HACK to be able to use static shadows for walls
// We just store a separate IMD for each direction
static iIMDShape otherDirections[3];
static BOOL directionSet[3] = {FALSE, FALSE, FALSE};
- iIMDShape *originalDirection;
+ iIMDShape *originalDirection=NULL;
if(psStructure-visible[selectedPlayer] || godMode ||
demoGetStatus())
@@ -2533,6 +2534,7 @@
temp = imd-points;
// now check if we need to apply the wall hack
+/*
if ( psStructure-direction 0 psStructure-pStructureType-
type == REF_WALL )
{
// switch them
@@ -2546,7 +2548,7 @@
directionSet[(int)psStructure-direction / 90 -
1] = TRUE;
}
}
-
+*/
flattenImd(imd, structX, structY, psStructure-direction );
/* Actually render it */
@@ -3984,7 +3986,7 @@
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));
+ memcpy(alteredPoints, imd-points, imd-npoints *
sizeof(Vector3f));//was Vector3i
/* Get the height of the centre point for reference */
centreHeight = map_Height(structX,structY);
--
Click for discounts on fashionable Italian charm bracelets
http://tagline.hushmail.com/fc/Ioyw6h4eoPwtO3GMiQGPBpMEP1n8mX1TVfxud9hyiClzZdGgPNytf4/
___
Warzone-dev mailing list
Warzone-dev@gna.org
https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] displayBufferSize DisplayBuffer ?
On Tue, 26 Jun 2007 18:33:44 -0400 Giel van Schijndel [EMAIL PROTECTED] wrote: [EMAIL PROTECTED] schreef: Should not memory be H*W*color depth ? Example 1024x768x4(RGBA) = 3145728, but game does 1024x768x2=1572864. If have 1600x1200x4, then that is 7.68MB, but game has 3.84MB . Even with 1600x1200x3 (RGB) = 5.76MB. The confuse part is DisplayBuffer is used to load wrf, .gam and other file types. What has this to do with what your resolution is? SDL does correct calculation for screen space, so I no understand this? You most likely discovered badly written code. Without a file:linenumber we can't see for ourselves though (and more importantly can't do much about it). So if you could point out where this is, I'd appreciate that. As for the display depth. Depending on what piece of code you're looking at, it ought to be either RGB or RGBA, so 3 could be a valid value just as well. Anyway, as of now I should have been in bed already. So I'll look into the specifics somewhere tomorrow. allocate here, init.c(959):displayBufferSize = pie_GetVideoBufferWidth()*pie_GetVideoBufferHeight()*2; and now show strange loads into this DisplayBuffer , src\game.c(1374): pFileData = DisplayBuffer; (loads up the .gam file) src\game.c(1465): pFileData = DisplayBuffer; (use here to load savegame file) src\game.c(11305): pFileData = DisplayBuffer; (use here to load script file) and this strange stuff goes on... I think this buffer should be rename to GeneralBuffer. I still no see how that 500 value or video resolution plays role yet. Last I check, no wrf file or any file in wz over 1MB. Maybe for safety, but that is too much safe. -- Click to get free info on kitchen remodeling at 50% - 70% off http://tagline.hushmail.com/fc/Ioyw6h4dczjDx1RGblGoBZqbh2IPQSg2qQSkFzx0tLwBZzdU7tw9m2/ ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] [patch] Re: [bug #9396] multiplayer set-up screen: player name is borked
On Mon, 25 Jun 2007 18:11:08 -0400 Giel van Schijndel [EMAIL PROTECTED] wrote: [EMAIL PROTECTED] schreef: On Mon, 25 Jun 2007 15:39:09 -0400 [EMAIL PROTECTED] wrote: For old game, when click flag next to player name, did it ever show list player names?? I make patch for this on list now. Maybe you'd be so kind to attach them as files rather than dumping them in the rest of the text, it's easier to work with patches when they're files. OK Both patch attach. -- Click to find great rates on home insurance, save big, shop here http://tagline.hushmail.com/fc/Ioyw6h4d8gXzOEcIiN0fnCIclvOg22EweTWkiVxWWpiIHhiDQflewu/ playername.diff Description: Binary data playernamePICK.diff Description: Binary data ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Patch to fix player name PICK.
This patch make slight change to remove #ifdef WIN32 on a var, so it compile OK on linux now. -- Click to get kitchen cabinets direct, wholesale prices, special offer http://tagline.hushmail.com/fc/Ioyw6h4eNQDZL4RKrmolhmPnpoltRQ3I9HypnfFGGHsiHgBz5Pf4YG/ multimenu.diff Description: Binary data ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] MSVC broken on ... STATIC_ASSERT ?
On Sun, 24 Jun 2007 17:16:00 -0400 Dennis Schridde
[EMAIL PROTECTED] wrote:
Am Sonntag, 24. Juni 2007 schrieb [EMAIL PROTECTED]:
Error49 error C2143: syntax error : missing ';' before 'type'
\src\multibot.c 1158
Error50 error C2061: syntax error : identifier
'sendRequestDroid'
src\multibot.c 1225
Error51 error C2059: syntax error : ';' \src\multibot.c 1225
Error52 error C2059: syntax error : 'type' \src\multibot.c
1225
STATIC_ASSERT(sizeof(id) == sizeof(pD-id));
Please check whether this version works:
#define STATIC_ASSERT( expr ) \
do { enum { assert_static__ = 1/(expr) }; } while(0)
Yes, it now compile OK with that change.
--
Click for free info on accredited degrees with 150K/ year potential
http://tagline.hushmail.com/fc/Ioyw6h4dDpFQH69Ea3XFdDElFsuAEmYBV9xQL6CsvfWCSN5lHdJ7OW/
___
Warzone-dev mailing list
Warzone-dev@gna.org
https://mail.gna.org/listinfo/warzone-dev
[Warzone-dev] Shadow code cause crashes.
When gerard change shadow code, he do,
in display3d.c
// HACK to be able to use static shadows for walls
// We just store a separate IMD for each direction
static iIMDShape otherDirections[3];
static BOOL directionSet[3] = {FALSE, FALSE, FALSE};
Very bad to use static here, since on multiple runs of games, these
vars retain old game values, and when try to access, it cause
access error, since memory was free, but static vars never clear so
it no know this. This why crash bug #9235.
Same true for other static vars in other functions that use malloc
but never use free, and also have same problem as above.
How fix best way? Change to global, and then on one cleanup stage,
clear these?
--
Click to find great rates on medical insurance, save big, shop here
http://tagline.hushmail.com/fc/Ioyw6h4d8QNDo6w88tszxHGxpb1GRBBfpxIEyD8ip1wkEurUmbKDnw/
___
Warzone-dev mailing list
Warzone-dev@gna.org
https://mail.gna.org/listinfo/warzone-dev
[Warzone-dev] [patch] crash fix for track.c
Got memory free twice. Index: track.c === --- track.c (revision 1523) +++ track.c (working copy) @@ -160,6 +160,7 @@ sound_FreeTrack( psTrack ); free( psTrack ); + psTrack=NULL; } //* -- Click for dental plans with huge savings, top service and coverage http://tagline.hushmail.com/fc/CAaCXv1KbKiDK3CTb29qptkgAxV88Vdl/ ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Memory design problems.
On Sat, 16 Jun 2007 08:26:25 -0400 Dennis Schridde [EMAIL PROTECTED] wrote: Am Samstag, 16. Juni 2007 schrieb [EMAIL PROTECTED]: On Fri, 15 Jun 2007 14:35:08 -0400 Giel van Schijndel [EMAIL PROTECTED] wrote: [EMAIL PROTECTED] schreef: They do keep track of all objects in treap, and the macro remove of , #define PTRVALID(ptr, size) memPointerValid(ptr, size) did this work for us. Replace PTRVALID() with if(ptr)||==NULL) checks is not same thing what original does! Did you actually check the r990 diff before you pressed the send button in your mail client? http://svn.gna.org/viewcvs/warzone/trunk/lib/framework/mem.h?rev=9 9 0view=diffr1=990r2=989p1=trunk/lib/framework/mem.hp2=/trunk/l i b/framework/mem.h Yes. This is debug builds. How else to find problems? You debug in release mode? How shall debugmode PTRVALID help avoid crashes in release builds? They will no help in release build, they not meant to. This why I say debug builds it help. I am trying to find memory bugs in debug builds, since we know what values are for wrong pointers. If find errors in debug builds, then you will no see crash in release builds. They have uninit, dangling, and corruption checks. -- Click to find great rates on home insurance, save big, shop here http://tagline.hushmail.com/fc/CAaCXv1QU9DHxazsqCXddTzH9qLpok5U/ ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Memory design problems.
On Wed, 13 Jun 2007 18:13:44 -0400 Giel van Schijndel [EMAIL PROTECTED] wrote: Dennis Schridde schreef: There must have been some special assumption on Pumpkins heap implementation which magically prevented eternal doom. Till now no one found out how it worked that wonder. I've got a very good clue on how that heap thingy worked in preventing segmentation faults. Since a HEAP_FREE never actually released the memory back to the OS or to the malloc/free implementation we simply where never punished (by segfaults) if we _did_ access dangling pointers anyway. Now that we do use mallocfree however memory is much more volatile (since all memory is now allocated from one pool rather than several dedicated pools), which makes memory to which dangling pointers point more likely to change in value, and thus become invalid to whatever function uses it. Keep in mind though that with both the heap system as well as malloc/free the pointers where _wrong_, it's just that now we are able to actually debug them, and feel the pain resulting from lots of years where debugging wasn't performed. I no think you right. It was correct, it was designs this way. In rev 990 muggenhor, removes checks for invalid pointers. Why? They do keep track of all objects in treap, and the macro remove of , #define PTRVALID(ptr, size) memPointerValid(ptr, size) did this work for us. Replace PTRVALID() with if(ptr)||==NULL) checks is not same thing what original does! Original will call memPointerValid(ptr, size). This then check if the block is in the treap. If yes, then IS valid pointer/object. If no, then object is NO valid, returns FALSE, calling routine returns back without doing anything. Now Crash in our cases, since pointer/object is NO NULL, which is the new check, so this is wrong. I debug full missions that crash on current (see bugs reports), and compare back to berlios versions. I then set breakpoints at code where current crash, and check pointers. I see 'invalids' pointers, and game deals with them as program to. This why I say just because you no like this design of original, no make it wrong? It worked for them fine did it not? -- Click for special offer on replacement windows - energy efficient http://tagline.hushmail.com/fc/CAaCXv1SRWqeB3jZeDH7xTcLPgTdhJYj/ ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Memory design problems.
On Fri, 15 Jun 2007 14:35:08 -0400 Giel van Schijndel [EMAIL PROTECTED] wrote: [EMAIL PROTECTED] schreef: They do keep track of all objects in treap, and the macro remove of , #define PTRVALID(ptr, size) memPointerValid(ptr, size) did this work for us. Replace PTRVALID() with if(ptr)||==NULL) checks is not same thing what original does! Did you actually check the r990 diff before you pressed the send button in your mail client? http://svn.gna.org/viewcvs/warzone/trunk/lib/framework/mem.h?rev=99 0view=diffr1=990r2=989p1=trunk/lib/framework/mem.hp2=/trunk/li b/framework/mem.h Yes. This is debug builds. How else to find problems? You debug in release mode? The PTRVALID macro was ptr != NULL in r985:989. See this: #define PTRVALID(ptr, size) (ptr != NULL) So all I did there was expanding the PTRVALID macro (to increase readability). As you can see, this PTRVALID macro only actually did anything when compiled in debugging mode. Therefore saying it was correctly designed and that removing the PTRVALID macro invalidated the correct system is wrong. ? We try to find dangling pointers, and other memory issues. They have debug system in code already just for these errors. So it was correct code they have for debug builds to find problems. just because you no like this design of original, no make it wrong? It worked for them fine did it not? No I don't like how the memory management for Warzone is designed. And sticking with this because it worked for them is a fallacy (look it, i.e. fallacy, up on wikipedia if you like). Fallacy = flaw ? I am no say stick with it. I am say that we insert it back in to help debug problems we have now, so to see where things go wrong. The checks they had did catch most errors for them, now we need same help to detect these errors. As I say before, efence/valgrind no really help, unless you know better how to use them? If yes, share with rest so we can fix this? -- Click to find great rates on home insurance, save big, shop here http://tagline.hushmail.com/fc/CAaCXv1QU9GHggbX8JSWf6sOy12HX4kv/ ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Patch for tex.c
On Wed, 13 Jun 2007 16:54:33 -0400 Giel van Schijndel
[EMAIL PROTECTED] wrote:
Dennis Schridde schreef:
Index: tex.c
===
--- tex.c (revision 1494)
+++ tex.c (working copy)
@@ -264,7 +264,7 @@
void iV_unloadImage(iV_Image *image)
{
- if (image)
+ if (image-bmp)
{
free(image-bmp);
image-bmp = NULL;
The idea of this if was probably to check whether we got passed
a NULL
pointer, not to check whether bmp was allready freed.
I don't know what ISO-C says, but I would guess that it is legal
to call free
on a NULL pointer... Am I wrong about this?
free(NULL) is very much legal yes. It should be similar to a no-
op. If
image is NULL however, then you're dereferencing a NULL pointer to
receive the bmp pointer, which is _not_ legal.
The game crash on that line, free(image-bmp).
Since it set to NULL after 1st free call, we can then assume that
image pointer is wrong/corrupted.
So then fix is to find where image is free, and make sure is set to
NULL?
--
Click for dental plans with huge savings, top service and coverage
http://tagline.hushmail.com/fc/CAaCXv1KbKmhmSwUVNYZYFq7GZpiNmcq/
___
Warzone-dev mailing list
Warzone-dev@gna.org
https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Memory design problems.
On Wed, 13 Jun 2007 14:16:26 -0400 Dennis Schridde [EMAIL PROTECTED] wrote: Am Mittwoch, 13. Juni 2007 schrieb [EMAIL PROTECTED]: On Mon, 11 Jun 2007 16:45:58 -0400 Dennis Schridde Valgrind should help... Will try on the weekend. You apparently dove deep into the code and found several places where unitialised memory comes from or pointers are not set to NULL. Maybe you can create a list? (variablename, file, line) Create list of all variables that crash on? It looks to me this is most for droids. (target/sound/and so ) I think, could be best is when droid is made, put this into global (linked list?) list. Then on droid dead, we clear entry in list. Then before all calls that have to use droid data, we check if match on global list. If yes, then continue. If no, then abort out of routine.This list may be, 300 units (max?) for each player. I thinks this will works OK. Maybe have to do this for all other types units/buildings also? I am not sure whether I understood you correctly, in case you want an alive-list with all droids being alive and before using any pointer, walk the list to see whether it is in that list, is maybe a good idea, and maybe not. Our thoughts about this on IRC were as follows: - Walking a long list with all units in it is slooow. Walking this list before dereferencing any pointer is possibly even slower. - Dead-lists (prune-lists, as they are called in WZ according to Per) are probably better to walk, because they usually are shorter. - Refcounting is probably even better. - Fully ID based system is another option, but maybe too slow. It could be speed up by caching the pointer in case you can ensure that you don't destroy the droid while the function (...) runs. This needs some work of the user (of the ID system), though. Another option is use heap again. I am no sure what is best. If we walk list, 300 is not too bad list to walk. Max players is 8, so 2400 is max list size. (live/about to die, and no in list, then it is dead) How does bullets/missiles work in game? Does it keep track in list someplace? I will try see more info how berlios version works. -- Click for a free comparison on healthcare coverage and save 100's http://tagline.hushmail.com/fc/CAaCXv1QUc0Q43ytBsnmKZueOrv7gaae/ ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Patch for tex.c
On Wed, 13 Jun 2007 17:31:17 -0400 Dennis Schridde [EMAIL PROTECTED] wrote: Am Mittwoch, 13. Juni 2007 schrieb [EMAIL PROTECTED]: The game crash on that line, free(image-bmp). Since it set to NULL after 1st free call, we can then assume that image pointer is wrong/corrupted. So then fix is to find where image is free, and make sure is set to NULL? So the problem is not that image-bmp is already freed, but that image was freed somewhere before we want to free image-bmp? That's ugly and should be fixed, instead of checking for bmp being null... Can you please provide a backtrace or tell us who tried to unload an image twice? Besides that: frameresource.c:667 might be the cause and should be investigated. Yes, next time crash @ that point, I will post stack dump. -- Click here for self-employed health insurance. Compare quotes for free! http://tagline.hushmail.com/fc/CAaCXv1KdvbID6M83HGOk7Ts3FLbUkYv/ ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Memory design problems.
On Mon, 11 Jun 2007 16:45:58 -0400 Dennis Schridde [EMAIL PROTECTED] wrote: Am Montag, 11. Juni 2007 schrieb [EMAIL PROTECTED]: I now trace back many problems now with warzone. It all because of switch from MALLOC/FREE, and HEAP usage to malloc/free, as I try to say before. I finds that most all crashes I find is because of this, and also most all crashes in games both SP and MP is because of this changes. The game use HEAP, and would always do memset to clear out everything. The game was design this way. I thinks PS2 is main reasons for this, to save many calls, and footprint of code size. With change to malloc/free no HEAP, then we have dangling pointers (0x) use. We also have many uninit (0xcdcdcdcd) use. From svn 1100, reverts back to this. Now do as in bug 9235, and 9233 no happen. Others bugs also no happen. Then update to next version, and now happens all time you try. Way to part fix is to go through all code and do as I say before. We still have problems of copy of structures, since one area may be clear and fall out of scope, but copy still here, and when try to access, it crash. This what seem to happen in 9235 9233, and others. When game before use HEAP, when clear everything in HEAP was clear to NULL. This how they reset game elements for many things. Very hard to find memory bugs now. We gots stack trace, but this no show where original 0x/0xcdcdcdcd happens. Is any tools to help this? I no have $1300 for Rational PurifyPlus, which is mades to find this. Anything on linux? I try efence/valgrind, and it no help really. Valgrind should help... Will try on the weekend. You apparently dove deep into the code and found several places where unitialised memory comes from or pointers are not set to NULL. Maybe you can create a list? (variablename, file, line) Create list of all variables that crash on? It looks to me this is most for droids. (target/sound/and so ) I think, could be best is when droid is made, put this into global (linked list?) list. Then on droid dead, we clear entry in list. Then before all calls that have to use droid data, we check if match on global list. If yes, then continue. If no, then abort out of routine.This list may be, 300 units (max?) for each player. I thinks this will works OK. Maybe have to do this for all other types units/buildings also? -- Patio furniture that can last you a lifetime. Below retail. Click Now. http://tagline.hushmail.com/fc/CAaCXv1UT8WDmne20hDyZOspBR1KPqQv/ ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
[Warzone-dev] Memory design problems.
I now trace back many problems now with warzone. It all because of switch from MALLOC/FREE, and HEAP usage to malloc/free, as I try to say before. I finds that most all crashes I find is because of this, and also most all crashes in games both SP and MP is because of this changes. The game use HEAP, and would always do memset to clear out everything. The game was design this way. I thinks PS2 is main reasons for this, to save many calls, and footprint of code size. With change to malloc/free no HEAP, then we have dangling pointers (0x) use. We also have many uninit (0xcdcdcdcd) use. From svn 1100, reverts back to this. Now do as in bug 9235, and 9233 no happen. Others bugs also no happen. Then update to next version, and now happens all time you try. Way to part fix is to go through all code and do as I say before. We still have problems of copy of structures, since one area may be clear and fall out of scope, but copy still here, and when try to access, it crash. This what seem to happen in 9235 9233, and others. When game before use HEAP, when clear everything in HEAP was clear to NULL. This how they reset game elements for many things. Very hard to find memory bugs now. We gots stack trace, but this no show where original 0x/0xcdcdcdcd happens. Is any tools to help this? I no have $1300 for Rational PurifyPlus, which is mades to find this. Anything on linux? I try efence/valgrind, and it no help really. -- Click to compare save $100's on medical insurance, free quote http://tagline.hushmail.com/fc/CAaCXv1QS4TSzADl4cqaTpwf5ze0dt3h/ ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
[Warzone-dev] Patch for droid.c to fix MSVC issue
Index: droid.c
===
--- droid.c (revision 1482)
+++ droid.c (working copy)
@@ -231,10 +231,11 @@
// If the shell penetrated the armour work out how much damage it
actually did
if (damage armour)
{
+ // Retrieve highest, applicable, experience level
+ unsigned int level = getDroidLevel(psDroid);
actualDamage = damage - armour;
- // Retrieve highest, applicable, experience level
- unsigned int level = getDroidLevel(psDroid);
+
{
unsigned int cmdLevel = cmdGetCommanderLevel(psDroid);
level = MAX(level, cmdLevel);
--
Click for free estimate on vinyl siding, 200% stronger lower cost
http://tagline.hushmail.com/fc/CAaCXv1SJD70sHnzJxOeA7cf1ONpxMvF/
___
Warzone-dev mailing list
Warzone-dev@gna.org
https://mail.gna.org/listinfo/warzone-dev
[Warzone-dev] Fix for not defined macros with aclocal
Here is output, fix was to do, gettextize -f Then ./autogen.sh works. I post here to help anyone else that has this error to make WZ. This is Ubuntu 7.04. I do not know if make difference or not. - ../autogen.sh + checking for xgettext = 0.15 ... found 0.16.1, ok. + checking for msgfmt = 0.15 ... found 0.16.1, ok. + checking for autoconf = 2.56 ... found 2.61, ok. + checking for automake = 1.8 ... found 1.8.5, ok. + checking for bison = 1.31 ... found 2.3, ok. + checking for flex = 2.4.2 ... found 2.5.33, ok. + running aclocal ... aclocal: macro `AM_MKINSTALLDIRS' required but not defined aclocal: macro `bh_C_SIGNED' required but not defined aclocal: macro `gt_HEADER_INTTYPES_H' required but not defined aclocal failed - check that all needed development files are present on system [EMAIL PROTECTED]:~/wz_src/warzone$ gettextize gettextize: *** po/Makefile.in.in exists: use option -f if you really want to delete it. gettextize: *** Stop. [EMAIL PROTECTED]:~/wz_src/warzone$ gettextize -f Copying file ABOUT-NLS Copying file config.rpath Not copying intl/ directory. Copying file po/Makefile.in.in Copying file po/Makevars.template Copying file po/Rules-quot Copying file po/boldquot.sed Copying file po/[EMAIL PROTECTED] Copying file po/[EMAIL PROTECTED] Copying file po/insert-header.sin Copying file po/quot.sed Copying file po/remove-potcdate.sin Adding an entry to po/ChangeLog (backup is in po/ChangeLog~) Copying file m4/gettext.m4 Copying file m4/iconv.m4 Copying file m4/lib-ld.m4 Copying file m4/lib-link.m4 Copying file m4/lib-prefix.m4 Copying file m4/nls.m4 Copying file m4/po.m4 Copying file m4/progtest.m4 Copying file m4/codeset.m4 Copying file m4/glibc2.m4 Copying file m4/glibc21.m4 Copying file m4/intdiv0.m4 Copying file m4/intl.m4 Copying file m4/intldir.m4 Copying file m4/intmax.m4 Copying file m4/inttypes_h.m4 Copying file m4/inttypes-pri.m4 Copying file m4/lcmessage.m4 Copying file m4/lock.m4 Copying file m4/longdouble.m4 Copying file m4/longlong.m4 Copying file m4/printf-posix.m4 Copying file m4/size_max.m4 Copying file m4/stdint_h.m4 Copying file m4/uintmax_t.m4 Copying file m4/ulonglong.m4 Copying file m4/visibility.m4 Copying file m4/wchar_t.m4 Copying file m4/wint_t.m4 Copying file m4/xsize.m4 Adding an entry to ChangeLog (backup is in ChangeLog~) Please run 'aclocal -I m4' to regenerate the aclocal.m4 file. You need aclocal from GNU automake 1.8 (or newer) to do this. Then run 'autoconf' to regenerate the configure file. You will also need config.guess and config.sub, which you can get from the CVS of the 'config' project at http://savannah.gnu.org/. The commands to fetch them are $ wget 'http://savannah.gnu.org/cgi- bin/viewcvs/*checkout*/config/config/config.guess' $ wget 'http://savannah.gnu.org/cgi- bin/viewcvs/*checkout*/config/config/config.sub' You might also want to copy the convenience header file gettext.h from the /usr/share/gettext directory into your package. It is a wrapper around libintl.h that implements the configure -- disable-nls option. Press Return to acknowledge the previous three paragraphs. -- Click to find great rates on health insurance, save big, shop here http://tagline.hushmail.com/fc/CAaCXv1QUc3D83IvFQySHqS5V0CeqOeW/ ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
[Warzone-dev] autogen.sh error?
What is missing? ../autogen.sh + checking for xgettext = 0.15 ... found 0.16.1, ok. + checking for msgfmt = 0.15 ... found 0.16.1, ok. + checking for autoconf = 2.56 ... found 2.61, ok. + checking for automake = 1.8 ... found 1.8.5, ok. + checking for bison = 1.31 ... found 2.3, ok. + checking for flex = 2.4.2 ... found 2.5.33, ok. + running aclocal ... aclocal: macro `AM_MKINSTALLDIRS' required but not defined aclocal: macro `bh_C_SIGNED' required but not defined aclocal: macro `gt_HEADER_INTTYPES_H' required but not defined -- Get your dream car or truck. Click here. http://tagline.hushmail.com/fc/CAaCXv1VEJgyY0deqA25aTc1H369fuka/ ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
[Warzone-dev] Patch for .vcproj file broke in 1462
Index: Warzone2100.vcproj === --- Warzone2100.vcproj (revision 1467) +++ Warzone2100.vcproj (working copy) @@ -223,7 +223,6 @@ RelativePath=..\lib\framework\frameresource.c /File - /File File RelativePath=..\lib\framework\input.c @@ -1357,7 +1356,6 @@ RelativePath=..\src\hci.h /File - /File File RelativePath=..\lib\ivis_common\imd.h -- Click to get kitchen cabinets direct, wholesale prices, special offer http://tagline.hushmail.com/fc/CAaCXv1SOPpZ6cq070zeanh76c4jmK6u/ ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Add back CPU delays? +patch?
On Tue, 05 Jun 2007 18:21:43 -0400 Giel van Schijndel [EMAIL PROTECTED] wrote: [EMAIL PROTECTED] schreef: Hmm. I like easy approach, which would be, as before. When paused, game loops through this over and over, so it is one big busy loop. So you still need a delay to fix. Why go make complex code, when add 1 call fix issue? This only hits when user paused. The point here is: adding 1 call a thousand times (yes that number is very much exaggerated) isn't a simple solution anymore. So when you find a place where WZ hogs the CPU too much. Simply adding an SDL_Delay call, without considering why the other SDL_Delay call(s) present don't do their job in the first place, is plainly stupid (IMO). Or in other words: don't fight the symptoms but the cause of them. I explain, and you still think it stupid? Maybe I explain this way. There is only 1 SDL_delay call now. That is in main game loop. This suppose to only run 60 (defaults) times per second. So the one and only SDL_delay call will never have ANY effect on 2nd loop. It still is calling 2nd loop 60 calls per second to a busy loop, (when pause is ACTIVE), it should free up CPU time, not run full speed. Yes, I know another way to fix this, but adding SDL_Delay() is easy way to fix this CPU HOGGING ACTION. Understand now? No reason to NOT free CPU up when pause is ACTIVE. -- Click for dental plans with huge savings, top service and coverage http://tagline.hushmail.com/fc/CAaCXv1KbKirK0FaefqE9UZlm6xAuDAD/ ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Add back CPU delays? +patch?
On Tue, 05 Jun 2007 19:50:04 -0400 Giel van Schijndel [EMAIL PROTECTED] wrote: So the one and only SDL_delay call will never have ANY effect on 2nd loop. This really is the most important info you've given by now. This explains where the problem is, know if only we knew what you mean with 2nd loop, we can look at the problem ourselves. I show patch, maybe it lost. In loop.c, where I add the removed SDL_Delay(). That is 2nd loop I was talk about. Main game loop is one with the only SDL_Delay(). Yes, I know another way to fix this, but ... Please elaborate on that, rather than this one call SDL_Delay solution. It most likely is more interesting. You could just do framerate=1; then on resume framerate = default. But for other reasons, this not best. Pointer will be too slow now. -- Click to get kitchen cabinets direct, wholesale prices, special offer http://tagline.hushmail.com/fc/CAaCXv1SOPpg558L60d60IsrLGI3K85h/ ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] [Warzone-commits] r1440 - in /trunk: lib/netplay/netplay.h src/cmddroid.c src/cmddroid.h src/droid.c
On Mon, 04 Jun 2007 13:18:21 -0400 Ari Johnson [EMAIL PROTECTED] wrote: On 6/4/07, Giel van Schijndel [EMAIL PROTECTED] wrote: Now please tell me. Why should we at all want to have that size guarantee in any non-networking, non-file code ? I think we don't need it anywhere in those portions of code, so would really vote for using a plain `int` instead and leave the compiler a bit more freedom for optimizations, etc. Like I said originally, as long as you are very careful when you deal with file or networking code, it doesn't matter to me. However, what I have seen in the past is a lot of carelessness on variable types that eventually get read from or written to the disk. (I still haven't looked at the networking code but I'm sure it's just as much of a mess.) Using the same size variables in the non- file/networking code to represent data that gets put on disk or the network also has the advantages of catching issues earlier and documenting the size of the data on disk or the network more clearly. Basically, the we'll worry about it when it's on disk or the network attitude has been the cause of enough problems to make me wary of anyone who holds it. I have to agree, only if 100% positive that this 'int' will not come later to think that it should be int32_t instead. If you wants network code, file save code, and other code to be 100% compatable, between all machines and compilers, then only option is to specify size exact on how it should be. -- Click to find great rates on medical insurance, save big, shop here http://tagline.hushmail.com/fc/CAaCXv1QS4STAf65YbdLliYCqBiGHWnN/ ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Oil anim fix patch
On Mon, 04 Jun 2007 03:11:04 -0400 Gerard Krol [EMAIL PROTECTED] wrote: My intention was Now only transparent objects are rendered by the bucket sort. (as it doesn't have any benefit for solid ones) The moving health bar was a side effect which I didn't notice. Again rendering animated components using the bucket sort is not what we want. I would suggest fixing renderAnimComponent so that it doesn't have this side-effect. (maybe pushing/popping the transform matrix) - Gerard I no think you can do simple push/pop, that is not how routine works. Much easier to just use, as original code intend, the bucketAddTypeToList( ) so they can be draw in right order. Then no need to add push/pop specific code to handle this when that call does work for us. If not broke, no fix right? -- Click to find great rates on life insurance, save big, shop here http://tagline.hushmail.com/fc/CAaCXv1QSYLRCwre8TRDgU8J4GT1QlDk/ ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
[Warzone-dev] Add back CPU delays?
As is now, WZ eats all CPU time. Even when pause. Can we add the removed SDL_Delay() calls that were take out? Friends can no longer play on laptop very long because of this. This is release builds. -- Click to compare save $100's on medical insurance, free quote http://tagline.hushmail.com/fc/CAaCXv1QS4TPwcxJLaCjSeRxpaP5VU58/ ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Bison/flex errors in grammar ?
On Sun, 03 Jun 2007 06:55:31 -0400 Per Inge Mathisen [EMAIL PROTECTED] wrote: On 6/3/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: For all the asserts, is root cause error in grammar files Or is code problem? All .l .y files change from original, so is there a way to check these files for problems? Someone explain better those asserts? Which asserts? - Per The ones I include in original message. line 958 in interp.c 1080 in event.c. Those are ones that makes game unplayable in debugger, since you must hit ignore all the time. error : interpRunScript: jump out of range error : interpRunScript: *** ERROR EXIT *** (CurEvent=51) error : Original event ID: 67 (of 114) error : Current event ID: 51 (of 114) error : Call depth : 1 error : interpRunScript: error while executing a script error : Assert in Warzone: f:\warzone_src\gna\lib\script\interp.c:958 : interpRunScript (FALSE), last script event: 'buildTruck' error : eventFireCallbackTrigger: event initialisedEvent: code failed error : Assert in Warzone: f:\warzone_src\gna\lib\script\event.c:1080 : eventFireCallbackTrigger (FALSE), last script event: 'buildTruck' error : interpRunScript: jump out of range error : interpRunScript: *** ERROR EXIT *** (CurEvent=51) error : Original event ID: 67 (of 114) error : Current event ID: 51 (of 114) error : Call depth : 1 -- Click here to find experienced pros to help with your home improvement project. http://tagline.hushmail.com/fc/CAaCXv1SNNRpyd7Ya1syAMEMD6gynnou/ ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Bison/flex errors in grammar ?
On Sun, 03 Jun 2007 14:35:36 -0400 Roman [EMAIL PROTECTED] wrote: vs2k5 wrote: error : interpRunScript: jump out of range error : interpRunScript: *** ERROR EXIT *** (CurEvent=51) error : Original event ID: 67 (of 114) error : Current event ID: 51 (of 114) error : Call depth : 1 error : interpRunScript: error while executing a script error : Assert in Warzone: f:\warzone_src\gna\lib\script\interp.c:958 : interpRunScript (FALSE), last script event: 'buildTruck' error : eventFireCallbackTrigger: event initialisedEvent: code failed error : Assert in Warzone: f:\warzone_src\gna\lib\script\event.c:1080 : eventFireCallbackTrigger (FALSE), last script event: 'buildTruck' error : interpRunScript: jump out of range error : interpRunScript: *** ERROR EXIT *** (CurEvent=51) error : Original event ID: 67 (of 114) error : Current event ID: 51 (of 114) error : Call depth : 1 I just made a game with 1.10 AI and can't confirm it so far. Did you run game from MSVC debugger? I think you said that you use MSVC? -- Click here to find experienced pros to help with your home improvement project. http://tagline.hushmail.com/fc/CAaCXv1SNNWRT7frSLbOxgOSwwSyOyb9/ ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Bison/flex errors in grammar ?
On Sun, 03 Jun 2007 15:01:30 -0400 Dennis Schridde [EMAIL PROTECTED] wrote: Am Sonntag, 3. Juni 2007 schrieb [EMAIL PROTECTED]: On Sun, 03 Jun 2007 14:54:26 -0400 Roman [EMAIL PROTECTED] wrote: On Sun, 03 Jun 2007 14:35:36 -0400 Roman [EMAIL PROTECTED] wrote: vs2k5 wrote: error : interpRunScript: jump out of range error : interpRunScript: *** ERROR EXIT *** (CurEvent=51) error : Original event ID: 67 (of 114) error : Current event ID: 51 (of 114) error : Call depth : 1 error : interpRunScript: error while executing a script error : Assert in Warzone: f:\warzone_src\gna\lib\script\interp.c:958 : interpRunScript (FALSE), last script event: 'buildTruck' error : eventFireCallbackTrigger: event initialisedEvent: code failed error : Assert in Warzone: f:\warzone_src\gna\lib\script\event.c:1080 : eventFireCallbackTrigger (FALSE), last script event: 'buildTruck' error : interpRunScript: jump out of range error : interpRunScript: *** ERROR EXIT *** (CurEvent=51) error : Original event ID: 67 (of 114) error : Current event ID: 51 (of 114) error : Call depth : 1 I just made a game with 1.10 AI and can't confirm it so far. Did you run game from MSVC debugger? I think you said that you use MSVC? Yes, I use MSVC in debug mode. -- Ok, here is how I do it. Run warzone from debug menu. Pick multiplayer. Then skirmish. Then leave everything as is. (default map, and everything else) When game loads up, 1 assert. Then while in game, those 2 asserts always show up when move screen around. I can replicate this 100% time. I can not confirm this. I can play for several minutes without one assert. Here is video of issue. http://www.sendspace.com/file/xl4ije It is abouts 7MB in size. Quality not best, but it too big if I go high quality. -- Click to compare life insurance rates. Great rates, quick and easy. http://tagline.hushmail.com/fc/CAaCXv1QSYKsbvIt4iDCt1CZTcctJitJ/ ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] [Warzone-commits] r1440 - in /trunk: lib/netplay/netplay.h src/cmddroid.c src/cmddroid.h src/droid.c
On Sun, 03 Jun 2007 15:03:14 -0400 Dennis Schridde [EMAIL PROTECTED] wrote: Am Sonntag, 3. Juni 2007 schrieb Ari Johnson: On 6/3/07, Giel van Schijndel [EMAIL PROTECTED] wrote: Author: muggenhor Date: Sun Jun 3 17:51:56 2007 New Revision: 1440 URL: http://svn.gna.org/viewcvs/warzone?rev=1440view=rev Log: * turn some usages of WinAPI types (*WORD) into their native C counterparts (e.g. int, unsigned int, etc.) Are you sure about that? Int and unsigned int vary in size according to the ABI. It is far better to use integers of a known size that will not change according to the system you are on. uint32_t and int32_t, for instance. As long as you stay on the same system that should not matter, should it? Eg. if that int never reaches the borders of your system (via file or network), then it should be perfectly legal to use them... --Dennis It would be much safer to use u/int32_t, since nobody knows all functions that are use by network code. Then all 32 vs 64bit systems may have problems later on. -- Click to get free info on kitchen remodeling at 50% - 70% off http://tagline.hushmail.com/fc/CAaCXv1MQyEbZdLpv91jw1OiYAK4ALz5/ ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Bison/flex errors in grammar ?
On Sun, 03 Jun 2007 17:14:51 -0400 Jose Ivey [EMAIL PROTECTED] wrote: I can't reproduce this either. Vs25k: when you clean build and complie, do you first manually delete all the the .h and c. script parser files in the win32 directory? Maybe you have stale lexer libraries Yes, I do this. I also do clean. Last thing I think is ask someone to zip/rar/7z all .l .y bison/flex output files, so I can compare. Maybe it is bison/flex program cause error? -- Click to get free info on kitchen remodeling at 50% - 70% off http://tagline.hushmail.com/fc/CAaCXv1MQyEPF3LZtazva9fbVxzf9c6b/ ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Oil anim fix patch
On Sat, 02 Jun 2007 08:07:00 -0400 Dennis Schridde [EMAIL PROTECTED] wrote: Am Samstag, 2. Juni 2007 schrieb [EMAIL PROTECTED]: I guess even stupid people can fix things? :( Did someone say that? --Dennis Yes, as pointed out by my friend who is on irc channel. :( -- Click here to find experienced pros to help with your home improvement project. http://tagline.hushmail.com/fc/CAaCXv1SNNQKAPYp2xB2nSX2lsvqE7y6/ ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Oil anim fix patch
On Sat, 02 Jun 2007 15:06:01 -0400 Dennis Schridde [EMAIL PROTECTED] wrote: Am Samstag, 2. Juni 2007 schrieb [EMAIL PROTECTED]: Yes, as pointed out by my friend who is on irc channel. :( In case you are refering to my talk with Giel: It was not about you being stupid in any way. You, just as other people incl. me do at times, asked about something which was discussed long before and which was clear to anyone else. In case I appeared rude, I appologize. I didn't meant to be. I can't speak for Giel, but I think he neither meant to say you are stupid. But the Smart Questions guide is really a good one and I read it again from time to time just to remind me of how I should ask and point out issues. And for the issue in question, when accepting the decision and thinking about it a while, you would have come to the conclusion that the absense of MALLOC doesn't mean the end of the world and you can still use memset and friends in cases _where that is needed_. --Dennis So patch good or not? -- No medical insurance? Click here to protect yourself and your family. http://tagline.hushmail.com/fc/CAaCXv1QUc4LVSy1wK4hYfDnEu1Eegyz/ ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Update To Kills/Rank Mechanism
On Sat, 02 Jun 2007 16:15:17 -0400 Freddie Witherden [EMAIL PROTECTED] wrote: Hi. Do units carry over rankings? I never notice much difference, they die too fast. I am not sure what you mean by carry over rankings. Could you elaborate somewhat? The experience points/rank is what I mean. If unit get lot kills in 1 mission, I never notice if same unit is any better in next mission. For your mod, would not it make fix place/wall units very powerful? To the best of my knowledge experience is only relevant for droids and not structures. Ok, when you post a patch, I play with it some. -- Click to find great rates on medical insurance, save big, shop here http://tagline.hushmail.com/fc/CAaCXv1QS4VOga3z1kbZ0ESwJCaqzyST/ ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Oil anim fix patch
On Sat, 02 Jun 2007 16:31:31 -0400 Per Inge Mathisen [EMAIL PROTECTED] wrote: On 6/2/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: So patch good or not? I am curious as to why it is correct, and what else might break, not just whether it fixes the bug. I see that gerard changed it in r1007: --- - r1007 | gerard_ | 2007-04-05 17:24:03 +0200 (Thu, 05 Apr 2007) | 2 lines 1. Now only transparent objects are rendered by the bucket sort. 2. Added some asserts to check if droids stay on the map. @@ -1891,7 +1851,7 @@ psComp-orientation.y = vecRot.y; psComp-orientation.z = vecRot.z; - bucketAddTypeToList( RENDER_ANIMATION, psComp ); + renderAnimComponent( psComp ); } } } Gerard, any comment on how this should be fixed? - Per Gerard make mistake, since when renderAnimComponent() is call, it uses new position. This is why it swing up and down. With bucketAddTypeToList () (original) call, then it adds to list, and it no calculate position of new animation frame to draw. If this is original call, how can this break something else ? The other calls may also need change back to original, but I have not notice any other quirks. -- Save money on your project by attaining multiple quotes from contractors. Click here. http://tagline.hushmail.com/fc/CAaCXv1SNNPVPo65wOz5fPEzQ2mSIfgj/ ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] [Fwd: Warzone for Ubuntu]
On Fri, 01 Jun 2007 12:59:37 -0400 Joseph Price [EMAIL PROTECTED] wrote: I've been playing around with the package a little more and have noticed that it needs the win32/ dir etc. when building. I guess maybe it is best I leave it as it is... sorry for the noise. Pricey I think the win32 is only use when MSVC is use to compile. It should no be needed for linux at all. Maybe mistake in makefile? -- Self-Employed? Need a Health Plan? Click here to get self-employed health insurance. http://tagline.hushmail.com/fc/CAaCXv1KdvdEeQ4lvSH9n6KSNpHKPHcT/ ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
[Warzone-dev] Oil anim fix patch
I guess even stupid people can fix things? :( Index: src/display3d.c === --- src/display3d.c (revision 1430) +++ src/display3d.c (working copy) @@ -1614,7 +1614,8 @@ psComp-orientation.y = vecRot.y; psComp-orientation.z = vecRot.z; - renderAnimComponent( psComp ); + bucketAddTypeToList( RENDER_ANIMATION, psComp );//This needed to correctly draw ANIM frame. +// renderAnimComponent( psComp );//we no want to draw base on position! } } } -- Click to compare save $100's on medical insurance, free quote http://tagline.hushmail.com/fc/CAaCXv1QS4WL4c3aW39VT0UOfQlEhwKe/ ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Gateway and zone debug illustration
On Fri, 01 Jun 2007 22:30:30 -0400 Jose Ivey [EMAIL PROTECTED] wrote: Oops. I accidentally turned on a gateway illustration debug feature. Turning it back off... Would this be a helpful switches to include in the command line or config file? It might help people who are designing maps or working on AI scripts and functions. In map editor, I think you already see these gateway items? For AI, I no think it helps, since the map maker must design map with proper gateway for them to work. Lav_coyote has documentation for this. -- Click for dental plans with huge savings, top service and coverage http://tagline.hushmail.com/fc/CAaCXv1KbKmEjgN8iyPfeiQI9WzUCUov/ ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Gateway and zone debug illustration
On Sat, 02 Jun 2007 00:06:35 -0400 Jose Ivey [EMAIL PROTECTED] wrote: -Original Message- From: vs2k5 In map editor, I think you already see these gateway items? For AI, I no think it helps, since the map maker must design map with proper gateway for them to work. Lav_coyote has documentation for this. You can see them in the map editor, but I thought it might be helpful to see how the AI was using without having to toggle it in the map editor. I don't know if the map editor has a switch to make gateways visible during game play. This good point. This will then be like the sensor visible toggle, so you can see how far out units sensor range is. A gateway toggle to see what needs to be fixed in some maps? -- Click for estimates on vinyl siding, 200% stronger and lower cost http://tagline.hushmail.com/fc/CAaCXv1SJD56n4ynTzPMFVFx8zGEECcP/ ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
[Warzone-dev] Crash in piedraw.c
Unhandled exception at 0x00558cba in Warzone2100-Dbg.exe:
0xC005: Access violation reading location 0x000a
for (n=0; npPolys-npnts; n++, index++)
{
line 385 crash-- pieVrts[n].sx = scrPoints[*index].x;
+ index 0x000a int *
[0xa] = {x=8.265e-040#DEN y=1.8341107e-036 z=1.9864262e-036 }
pPolys = 0x0428fd68 {flags=0x000c zcentre=0x0001
npnts=0x0007939c ...}
Start MP game, just leave everything defaults. Then hit ok.
Now quit game. Now start same game again. Crash.
--
Click here to find an affordable personal injury lawyer that you trust.
http://tagline.hushmail.com/fc/CAaCXv1aVjpyaOOoB5sRbYQtzkZj8X9t/
___
Warzone-dev mailing list
Warzone-dev@gna.org
https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] WZ getting less stable as time goes on?
On Tue, 29 May 2007 09:34:43 -0400 Dennis Schridde [EMAIL PROTECTED] wrote: Am Dienstag, 29. Mai 2007 schrieb [EMAIL PROTECTED]: I no sure if I am only one, but game not playable with all asserts going off. Would be better to still assert, and then activate a forced crash so we can find all problems? We need this so we can get stack dump, to find what is going on. (in debug builds, so not to mess release builds) I have to go back hundreds of revision to get back to playable game. There is branches/2.0 for stable and playable games... Problem must be stack corruption some place I think. Maybe bad code, but we must fix problems, back to a playable state. Maybe devs will stop with code modification and now everyone go on bug(s) hunt? You are using SVN trunk, after all. If you want something stable, use 2.0. Sure even the trunk shouldn't crash all the time, but lately I heard several people saying that it got quite stable again and they even played a network game which lasted significantly longer than an hour. So it can't be all that bad. I mean if you start play game in debugger, then you can no longer play without getting assert dialogs. Then you must hit i (ignore) every few moves. If you play game with no debugger or play 'release' builds, then, yes, you can play it without those dialogs, bad data don't crash game. This is what I mean when I can't play game. Before builds, I never saw asserts while play game in debugger. I use debugger to finds memleaks, and other errors. If someone has lots time, enable #define DEBUG_MEMORY for MSVC, even on dual core 3GHz system, it is very slow. I tried over 35 mins, and didn't get to any game. -- Click to find great rates on health insurance, save big, shop here http://tagline.hushmail.com/fc/CAaCXv1QUc1I4bT63UTLWT0DdHvqXiRR/ ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Sound code crash heap.c problem
On Tue, 29 May 2007 15:51:10 -0400 Giel van Schijndel [EMAIL PROTECTED] wrote: [EMAIL PROTECTED] schreef: For sound crash on double quit (not always crash), the problems is that psObj is destoryed before the sound code get chance to play/remove it. So psObj is pointing to nothing, but psSimpleObj-type (which is psObj) points to area of memory that has been freed. It then crash. How to fix this? We have to make sure sound is removed before psObj is out of scope. Anyone know where psObj is killed off? I know there is no free(psObj) that would be too easy to find. ;) psObj is some kind of droid; psObj is never used by the sound code itself, instead it is passed to a callback function. I think that the best/easiest solution would be to simply drop the callback support. All it currently does is calling a given function with that psObj pointer upon finishing of playback from one sound effect. Devurandom in rev 1101, in heap.c, you change FREE MALLOC to free malloc, but you no set what is free to NULL. You also do not set malloc memory to 0. This could be cause of more errors, since lots code expect this. This my understanding of what FREE MALLOC macro did before. Actually this probably _will_ be the cause of errors (as devurandom pointed out when he changed that). The fix however is _not_ to revert back to previous behaviour. Since depending on malloc calls to return zero-initialized memory, or free calls to set the pointer to NULL is very, very bad programming style. in aud.c, line 70, /* check projectiles */ if ( psSimpleObj-type == OBJ_BULLET ) so sound code checks if psObj fired bullet. I am no sure I understand how remove of callback will help here. I am look to see how older sound code worked this out. Why that very bad programming style? Once you free pointer, how else you know it free if no set to NULL? The malloc memory being zero out is also standard from projects I have seen. -- Click here for fast, free health insurance quotes. Low rates - great deals nationwide. http://tagline.hushmail.com/fc/CAaCXv1QUc4KPCkKfCzQhDRiNargTZtQ/ ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Sound code crash heap.c problem
On Tue, 29 May 2007 16:13:52 -0400 Dennis Schridde [EMAIL PROTECTED] wrote: Why that very bad programming style? Once you free pointer, how else you know it free if no set to NULL? I usualy know that a pointer is invalid by setting it to NULL. Yes, so FREE(temp) is really free(temp) temp=NULL; If you leave free(temp) without setting to NULL, then program never knows it was free before. I still no see why this bad programming style? The malloc memory being zero out is also standard from projects I have seen. Code that depends on variables to be initialized should do that itself. OK, this was just a nicer way I thinks, since use of memset is faster than doing lots of assignment to 0 operations. -- Free information - Learn about Hardwood Floors. Click now! http://tagline.hushmail.com/fc/CAaCXv1SLotIRlrZC1vYd1AeEh7QznMz/ ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] [bug #9237] errors on MSVC compile svn r1408 [patch]
On Tue, 29 May 2007 18:46:23 -0400 Jose Ivey NO-REPLY.INVALID-
[EMAIL PROTECTED] wrote:
URL:
http://gna.org/bugs/?9237
Summary: errors on MSVC compile svn r1408
Project: Warzone Resurrection Project
Submitted by: urbanvoyeur
Submitted on: Tuesday 05/29/2007 at 22:46
Category: Build system
Severity: 3 - Normal
Priority: 5 - Normal
Status: None
Assigned to: None
Originator Email:
Open/Closed: Open
Discussion Lock: Any
Release: svn
Operating System: Microsoft Windows
___
Details:
1strres.c
1h:\document\programming\wz2100\wz_svn_trunk\lib\framework\strres.
c(391) :
error C2275: 'PHYSFS_file' : illegal use of this type as an
expression
1h:\document\programming\wz2100\devpkg-
msvc\include\physfs.h(274) :
see declaration of 'PHYSFS_file'
1h:\document\programming\wz2100\wz_svn_trunk\lib\framework\strres.
c(391) :
error C2065: 'fileHandle' : undeclared identifier
___
Reply to this item at:
http://gna.org/bugs/?9237
Index: strres.c
===
--- strres.c(revision 1410)
+++ strres.c(working copy)
@@ -37,6 +37,8 @@
#include strres.h
#include strresly.h
+
+
/* The string resource currently being loaded */
STR_RES*psCurrRes;
@@ -387,8 +389,9 @@
/* Load a string resource file */
BOOL strresLoad(STR_RES* psRes, const char* fileName)
{
+ PHYSFS_file *fileHandle = PHYSFS_openRead(fileName);
psCurrRes = psRes;
- PHYSFS_file* fileHandle = PHYSFS_openRead(fileName);
+
if (!fileHandle)
{
debug(LOG_ERROR, strresLoadFile: PHYSFS_openRead(\%s\)
failed
with error: %s\n, fileName, PHYSFS_getLastError());
--
Click to find great rates on medical insurance, save big, shop here
http://tagline.hushmail.com/fc/CAaCXv1QS4Y6DT8MHCKHAeIYVeVRSGBs/
___
Warzone-dev mailing list
Warzone-dev@gna.org
https://mail.gna.org/listinfo/warzone-dev
[Warzone-dev] WZ getting less stable as time goes on?
I no sure if I am only one, but game not playable with all asserts going off. Would be better to still assert, and then activate a forced crash so we can find all problems? We need this so we can get stack dump, to find what is going on. (in debug builds, so not to mess release builds) I have to go back hundreds of revision to get back to playable game. Problem must be stack corruption some place I think. Maybe bad code, but we must fix problems, back to a playable state. Maybe devs will stop with code modification and now everyone go on bug(s) hunt? Also, is possible for svn to know dependancy of files? I mean if someone change xxx.c and xxx.h and we revert back xxx.c but not xxx.h because we don't know right away if what change in xxx.h is needed? The other idea I have is to start from known working codebase (first import from berlios?), and then add patch 1 by 1, but this takes very long time for 1 persons to do. How do we fix this? -- Click for free info on adult education and start making $150k/ year http://tagline.hushmail.com/fc/CAaCXv1S62vVhg8sglYaEiCYLVygbrTR/ ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
[Warzone-dev] assert list
Run-Time Check Failure #1 - A cast to a smaller data type has caused a loss of data. If this was intentional, you should mask the source of the cast with the appropriate bitmask. For example: char c = (i 0xFF); function.c : psFunction-outputModifier=(UBYTE)outputModifier; interp.c: InstrPointer += (SWORD)data; == Lists of asserts I forgets to include in other message, error : interpRunScript: jump out of range error : interpRunScript: *** ERROR EXIT *** (CurEvent=1) error : Original event ID: 1 (of 6) error : Current event ID: 1 (of 6) error : Call depth : 0 error : interpRunScript: error while executing a script error : Assert in Warzone: \lib\script\interp.c:958 : interpRunScript (FALSE), last script event: 'initialisedEventTwo' error : eventFireCallbackTrigger: event initialisedEventTwo: code failed error : Assert in Warzone: \lib\script\event.c:1080 : eventFireCallbackTrigger (FALSE), last script event: 'initialisedEventTwo' error : interpRunScript: jump out of range error : interpRunScript: *** ERROR EXIT *** (CurEvent=0) error : Original event ID: 0 (of 6) error : Current event ID: 0 (of 6) error : Call depth : 0 error : interpRunScript: error while executing a script error : Assert in Warzone: \lib\script\interp.c:958 : interpRunScript (FALSE), last script event: 'initialisedEvent' error : eventFireCallbackTrigger: event initialisedEvent: code failed error : Assert in Warzone: \lib\script\event.c:1080 : eventFireCallbackTrigger (FALSE), last script event: 'initialisedEvent' error : Error while processing audio context: Invalid Name error : interpRunScript: jump out of range error : interpRunScript: *** ERROR EXIT *** (CurEvent=71) error : Original event ID: 71 (of 111) error : Current event ID: 71 (of 111) error : Call depth : 0 error : interpRunScript: error while executing a script error : Assert in Warzone: \lib\script\interp.c:958 : interpRunScript (FALSE), last script event: 'buildPowerGenerators' error : eventFireTrigger: event buildPowerGenerators: code failed error : Assert in Warzone: \lib\script\event.c:1162 : eventFireTrigger (FALSE), last script event: 'buildPowerGenerators' error : interpRunScript: jump out of range error : interpRunScript: *** ERROR EXIT *** (CurEvent=68) error : Original event ID: 68 (of 111) error : Current event ID: 68 (of 111) error : Call depth : 0 error : interpRunScript: error while executing a script error : Assert in Warzone: \lib\script\interp.c:958 : interpRunScript (FALSE), last script event: 'buildDerrick' error : eventFireTrigger: event buildDerrick: code failed error : Assert in Warzone: \lib\script\event.c:1162 : eventFireTrigger (FALSE), last script event: 'buildDerrick' error : interpRunScript: jump out of range error : interpRunScript: *** ERROR EXIT *** (CurEvent=71) error : Original event ID: 71 (of 111) error : Current event ID: 71 (of 111) error : Call depth : 0 error : interpRunScript: error while executing a script error : Assert in Warzone: \lib\script\interp.c:958 : interpRunScript (FALSE), last script event: 'buildPowerGenerators' error : eventFireTrigger: event buildPowerGenerators: code failed error : Assert in Warzone: \lib\script\event.c:1162 : eventFireTrigger (FALSE), last script event: 'buildPowerGenerators' error : interpRunScript: jump out of range error : interpRunScript: *** ERROR EXIT *** (CurEvent=71) error : Original event ID: 71 (of 111) error : Current event ID: 71 (of 111) error : Call depth : 0 error : interpRunScript: error while executing a script error : Assert in Warzone: \lib\script\interp.c:958 : interpRunScript (FALSE), last script event: 'buildPowerGenerators' error : eventFireTrigger: event buildPowerGenerators: code failed error : Assert in Warzone: \lib\script\event.c:1162 : eventFireTrigger (FALSE), last script event: 'buildPowerGenerators' error : interpRunScript: jump out of range error : interpRunScript: *** ERROR EXIT *** (CurEvent=68) error : Original event ID: 68 (of 111) error : Current event ID: 68 (of 111) error : Call depth : 0 error : interpRunScript: error while executing a script error : Assert in Warzone: \lib\script\interp.c:958 : interpRunScript (FALSE), last script event: 'buildDerrick' error : eventFireTrigger: event buildDerrick: code failed error : Assert in Warzone: \lib\script\event.c:1162 : eventFireTrigger (FALSE), last script event: 'buildDerrick' error : interpRunScript: jump out of range error : interpRunScript: *** ERROR EXIT *** (CurEvent=2) error : Original event ID: 2 (of 6) error : Current event ID: 2 (of 6) error : Call depth : 0 error : interpRunScript: error while executing a script error : Assert in Warzone: \lib\script\interp.c:958 : interpRunScript (FALSE), last script event: 'checkEndConditions' error : eventFireTrigger: event checkEndConditions: code failed error :
Re: [Warzone-dev] g++ fixes again
On Wed, 23 May 2007 17:12:02 -0400 Per Inge Mathisen [EMAIL PROTECTED] wrote: On 5/23/07, Dennis Schridde [EMAIL PROTECTED] wrote: Most of these are good, but do we need fixes of this kind?: - buffer = malloc(bufferSize + sizeof(soundDataBuffer)); + buffer = (soundDataBuffer*) malloc(bufferSize + sizeof(soundDataBuffer)); ... Question: ... Why should I not cast? Casting is bad because it makes changing types later obnoxiously hard. It also clutters the code badly. Actually, the best way to do it is like this: buffer = malloc(bufferSize + sizeof(*buffer)); This way you do not explicitly mention the type, and if you later change it, it will not cause size or casting problems. - Per What is use of sizeof (*buffer) ? Padding? -- Looking for insurance? Compare and save 50% today. Click here. http://tagline.hushmail.com/fc/CAaCXv1QT6sib8saUWFKgBKPBhAepxgj/ ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
[Warzone-dev] WZ 2.0.6 hits GH now
Glide again? We need a PR persons to correct this. http://www.gamershell.com/news/38654.html This version adds basic map editing ingame, beacons in multiplayer mode and some UI enhancements Warzone 2010 is a 3D RTS game developed by Pumpkin Studios and published by Eidos Interactive in 1999 for both PC and PlayStation. A fan group called Pumpkin-2 managed to petition Eidos, the legal owner of the source, to make Warzone open-source. Now the game is being developed with lots of features added, such as increased multiplayer unit-limit, support for Glide, several compatibility fixes for Windows XP, and most recently, the introduction of static shadows. -- Click for quotes on laminate flooring, looks like tile 200% cheaper http://tagline.hushmail.com/fc/CAaCXv1SMK8eylwQmp58hRRTyTTjc03t/ ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
[Warzone-dev] rev 1321 broken
Error 294 error C2059: syntax error : '{'
\lib\ivis_common\imdload.c 306
poly-normal = (Vector3i){0.0f, 0.0f, 0.0f};
should be broken down into parts to fix.
___
Warzone-dev mailing list
Warzone-dev@gna.org
https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] rev 1321 broken [patch]
On Mon, 21 May 2007 15:44:46 -0400 Giel van Schijndel
[EMAIL PROTECTED] wrote:
[EMAIL PROTECTED] schreef:
On Mon, 21 May 2007 15:07:04 -0400 [EMAIL PROTECTED] wrote:
Error 294 error C2059: syntax error : '{'
\lib\ivis_common\imdload.c 306
poly-normal = (Vector3i){0.0f, 0.0f, 0.0f};
should be broken down into parts to fix.
Index: lib/ivis_common/imdload.c
===
--- lib/ivis_common/imdload.c(revision 1321)
+++ lib/ivis_common/imdload.c(working copy)
@@ -303,7 +303,9 @@
}
else
{
-poly-normal = (Vector3i){0.0f, 0.0f, 0.0f};
+poly-normal.x = 0.0f;
+poly-normal.y = 0.0f;
+poly-normal.z = 0.0f;
}
if (poly-flags iV_IMD_TEXANIM)
Any comments on this ? Doesn't the original code compile for you
or ?
I post error message first. Since error, no compile.
That is C99 thing anyway, which is why you can no do that with MSVC.
___
Warzone-dev mailing list
Warzone-dev@gna.org
https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] hack to prevent transporters being blown up
On Sun, 20 May 2007 15:42:39 -0400 Dennis Schridde [EMAIL PROTECTED] wrote: Am Sonntag, 20. Mai 2007 schrieb Giel van Schijndel: Some people have reported problems when their transport got stuck that they couldn't blow it up. (E.g. http://wz2100.net/forum/index.php?topic=606.0 ) This is most certainly the direct result from a so called hack to prevent Transporter's being blown up in droid.c (just for that exact string, although it should be on lines 295, 353). This hack causes function droidDamage (which ought to return TRUE on destruction of a droid) to always returns false if the droid being asked about is a transport (line 295 code). Now, do we want this behaviour or not? (I personally would most certainly don't want the code to check for a specific droid type, instead some kind of indestructible flag which could be set for each droid would be better). There are a few issues... - By simply removing that check you will blow up the wrong transports. - Will you get a new transport if you blew the old one up? If you don't I wonder how you ever want to accomplish the campaign... - Indestructible flag sounds good, but would not be backwards compatible since it needs modifications to the maps and savegames. (Thus nothing for 2.0) --Dennis Are you say that the original codebase has bug for transports, or is this a fix for code that was modified from original codebase? I thought that issue was if some file was not found, then it would screw up. This goes back to berlios days. ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] code formatting
On Sun, 20 May 2007 15:04:12 -0400 Per Inge Mathisen [EMAIL PROTECTED] wrote: On 5/20/07, Giel van Schijndel [EMAIL PROTECTED] wrote: Therefore I propose we do a one time run over the codebase with a a code formatter. You realize that this will screw up svn blame, right? It is an invaluable bug hunting tool, and am I still annoyed with myself that I did not work harder to save svn history from the berlios days. I'd say we wait with something like this until the codebase is more stable. Right now we need all the bug hunting aid we need, rather than a pretty codebase. - Per On old berlios mail list, this was talk about, and problem is as you say. It would be more hard to find bugs, among other things. Once codebase is stable, then maybe it will be nice to use prettyC or another one. It also is hard to make people use the code style you want them, if they use to another one. No win really, unless devs run all patches from now on through a style program, and then the code base will get pretty as more patches make way to them. ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Event based mainloop
Posted by Dennis Schridde on May 16, 2007 - 20:45: Am Mittwoch, 16. Mai 2007 schrieb Jose Ivey: I wonder if this change is the reason background applications like diskkeeper now cause stuttering/framerate issues in WZ? If that patch creates problems for you, don't use it. It's as simple as that. In case you can improve it, please do so. But till then I really see no sense in people complaining about issues maybe (or may not be) caused by a patch they applied themselves. ?? You say you wants comments, now complain about getting comments? Hard day? ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] All sorts of problems
On Mon, 14 May 2007 23:24:23 -0400 Jose Ivey [EMAIL PROTECTED] wrote: -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Monday, May 14, 2007 10:56 PM To: Development list Subject: Re: [Warzone-dev] All sorts of problems On Mon, 14 May 2007 18:22:18 -0400 Ari Johnson [EMAIL PROTECTED] wrote: On 5/14/07, Ari Johnson [EMAIL PROTECTED] wrote: On 5/14/07, Jose Ivey [EMAIL PROTECTED] wrote: 5. User interface is not entirely displayed. The radar, debug info (mission name and timer), and mission timer (upper right corner) are displayed, but the console output (expanded or otherwise) and the main command buttons are not displayed. I can see the main command buttons, but the power/oil meter is missing. WinXP, build 1276 The power bar is also missing for me. All of this stuff disappears as of r1264. Maybe something was missed or happens in the wrong order in the refactored code? The same revision introduces the crash from shots being fired. I think from r125x is problem starts. Very hard to find issue. Lots of changes. I agree - there are many issues with the lastest build. But I also understand that we are in the middle of the conversion to event based timing, and we were warned that it was not finished. Should we wait for more updates to the event system before we test further or should we roll back to an earlier version and move forward with a fewer changes until each issue is resolved? I still try to find why this event based system better than the way it was? I no see advantages so far? ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
[Warzone-dev] lobby server ?
I see code is added for lobby server. It is stand alone now, will this ever be in wz, or is wz gui first need to be fix? ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Event based mainloop
On Sat, 12 May 2007 19:57:31 -0400 Dennis Schridde [EMAIL PROTECTED] wrote: Small update, now in sync with r1265. Also hardcoded the FPS again. This time to 25 FPS / 40ms. Anything below 200FPS / 10ms is strongly not recommended. (The game will not react anymore.) --Dennis You say resolution of timer is 10ms? That not good. I think also this will break MP more, since one side can be going much faster than other side? -- Click here for self-employed health insurance. Compare quotes for free! http://tagline.hushmail.com/fc/CAaCXv1KdvbrXAyA2XlWitPQwfOl9C6C/ ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
[Warzone-dev] warzone2100.vcproj patch for rev 1272
Index: Warzone2100.vcproj === --- Warzone2100.vcproj (revision 1272) +++ Warzone2100.vcproj (working copy) @@ -402,10 +402,6 @@ Name=netplay File - RelativePath=..\lib\netplay\netaudio_stub.c - - /File - File RelativePath=..\lib\netplay\netcrypt.c /File -- Do it right the first time. Click to find contractors to work on your home improvement project. http://tagline.hushmail.com/fc/CAaCXv1SNNV2cibUb7LXsJsPLryBjlJL/ ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
[Warzone-dev] Transparent area missing?
in 1272, I notice that on the HQ (top), the area that should be transparent is not anymore? Any one notice this? It now is semi-transparent? -- You could save hundreds on health insurance. Click to get a quote now. http://tagline.hushmail.com/fc/CAaCXv1QUc1ahk6unJYNfTi8P536knE2/ ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Event based mainloop
On Sat, 12 May 2007 18:00:55 -0400 Dennis Schridde [EMAIL PROTECTED] wrote: Surprise, surprise... Here comes the final patch for the event based mainloop. Campaign seems a bit broken... Please leave your comments. --Dennis What broken in campaign mode after this patch? ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Two turrets per body?
On Wed, 09 May 2007 06:59:18 -0400 The Watermelon [EMAIL PROTECTED] wrote: On 5/8/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: On Tue, 08 May 2007 12:10:10 -0400 The Watermelon [EMAIL PROTECTED] wrote: On 5/7/07, Jose Ivey [EMAIL PROTECTED] wrote: I tried three turrets and ran into an unhandled exception here in actionUpdateDroid from action.c What kind of the combination you used for the 3 turret droid? the values of the psActionTarget[0] seems to be valid,the only problem that could cause this is some debug memory value like 0xccc(allocated and uninitialized memory iirc) by MSVC,which bypasses the NULL check against psActionTarget[index] and causes shift operation(psActionTarget[index]-died) on memory address 0xccc,hence the error: Access violation reading location 0xcd08. It still mean there is error in code someplace. Everything should be set to value before checking against NULL. ---MSVC codes 0xCDCDCDCD - Allocated in heap, but not initialized 0x - Released heap memory. 0xFDFDFDFD - NoMansLand fences automatically placed at boundary of heap memory. Should never be overwritten. If you do overwrite one, you're probably walking off the end of an array. 0x - Allocated on stack, but not initialized it's already done in buildDroid in droid.c, I have no idea why it got marked as 0x,at least I didnt have such problems with release build with debug info enabled and memory debug disabled. I think that compile with release build hides lots of problems. If you play game with debug builds, better to find errors, and you see lots of asserts. Same with mingw/linux builds, defaults is release, and devs no see lots of assert errors. -- Click to lower your debt and consolidate your monthly expenses http://tagline.hushmail.com/fc/CAaCXv1QPRRBCOOQo8bhqklZMnDYo7tM/ ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Two turrets per body?
On Tue, 08 May 2007 12:10:10 -0400 The Watermelon [EMAIL PROTECTED] wrote: On 5/7/07, Jose Ivey [EMAIL PROTECTED] wrote: I tried three turrets and ran into an unhandled exception here in actionUpdateDroid from action.c What kind of the combination you used for the 3 turret droid? the values of the psActionTarget[0] seems to be valid,the only problem that could cause this is some debug memory value like 0xccc(allocated and uninitialized memory iirc) by MSVC,which bypasses the NULL check against psActionTarget[index] and causes shift operation(psActionTarget[index]-died) on memory address 0xccc,hence the error: Access violation reading location 0xcd08. It still mean there is error in code someplace. Everything should be set to value before checking against NULL. ---MSVC codes 0xCDCDCDCD - Allocated in heap, but not initialized 0x - Released heap memory. 0xFDFDFDFD - NoMansLand fences automatically placed at boundary of heap memory. Should never be overwritten. If you do overwrite one, you're probably walking off the end of an array. 0x - Allocated on stack, but not initialized --- -- Click here for free information on consolidating your debt. http://tagline.hushmail.com/fc/CAaCXv1QPxduDoGMnkbllyLGFk9fIdA1/ ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Exceptionhandler broken on linux
On Sun, 06 May 2007 17:50:50 -0400 Giel van Schijndel [EMAIL PROTECTED] wrote: [EMAIL PROTECTED] schreef: On Sun, 06 May 2007 17:29:20 -0400 Dennis Schridde [EMAIL PROTECTED] wrote: Ok, then we probably don't need CMake. At least not for MacOS. The current Autotools seem to work quite nicely, raw is maintained by Giel, which leaves only the poor MSVC users, who only have Troman with SVN access, but he afaik doesn't use the shiped project files. I can not get autotools or raw makefile to work. (I post messages on list about this) I assume you mean this: https://mail.gna.org/public/warzone-dev/2007-05/msg00010.html ? I see one thing that is probably wrong there, you're using the MSVC dev-package (which should cause no problems until linking I suppose). That however doesn't explain that compile error, which I'm sure stands apart from the makefile system. I'm guessing it is a bison error. I can only get MSVC to work with latest versions. Autotools did work before the gettext stuff was added. Can you compile latest svn version with mingw/msys? I can compile it with MinGW using the raw makefiles. (Don't have MSYS on my system) -- Giel Which bison flex version you use? -- Too many bills? Click here to simplify your life and lower your debt. http://tagline.hushmail.com/fc/CAaCXv1QPxcIi7e5ufDWLUb0AErjkxjn/ ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Exceptionhandler broken on linux
On Sun, 06 May 2007 18:08:12 -0400 Giel van Schijndel [EMAIL PROTECTED] wrote: [EMAIL PROTECTED] schreef: On Sun, 06 May 2007 17:50:50 -0400 Giel van Schijndel [EMAIL PROTECTED] wrote: [EMAIL PROTECTED] schreef: On Sun, 06 May 2007 17:29:20 -0400 Dennis Schridde [EMAIL PROTECTED] wrote: Ok, then we probably don't need CMake. At least not for MacOS. The current Autotools seem to work quite nicely, raw is mainted by Giel, which leaves only the poor MSVC users, who only have Troman with SVN access, but he afaik doesn't use the shipped project files. I can not get autotools or raw makefile to work. (I post messages on list about this) I assume you mean this: https://mail.gna.org/public/warzone-dev/2007-05/msg00010.html ? I see one thing that is probably wrong there, you're using the MSVC dev-package (which should cause no problems until linking I suppose). That however doesn't explain that compile error, which I'm sure stands apart from the makefile system. I'm guessing it is a bison error. I can only get MSVC to work with latest versions. Autotools did work before the gettext stuff was added. Can you compile latest svn version with mingw/msys? I can compile it with MinGW using the raw makefiles. (Don't have MSYS on my system) Which bison flex version you use? C:\bison --version bison (GNU Bison) 2.1 C:\flex --version flex version 2.5.4 PS Note that on the download page (here: http://wz2100.net/downloads.html ) we have a MinGW development package as well as an MSVC one. -- Giel I follow this, Developer's guide: 1. Get the sourcecode from svn://svn.gna.org/warzone/trunk 2. Get the devpkg 3. Get Flex 2.5 and Bison 1.8 or 2.3 from http://gnuwin32.sf.net/ (Do NOT get 2.1! That one is buggy and known to not work!) 4. When using MSVC additionaly download the Windows Platform SDK 5. Copy makerules/config.mk.tmpl to makerules/confik.mk and adjust the settings 6. Copy src/version.c.tmpl to src/version.c and adjust the version/revision numbers Note: If you intend to distribute the compiled binary those numbers need to be accurate! 2.1 is buggy? ok, I have those versions. $ flex --version flex.exe version 2.5.4 $ bison --version bison (GNU Bison) 2.1 -- Click to lower your debt and consolidate your monthly expenses http://tagline.hushmail.com/fc/CAaCXv1QPROCyjrtNeU9adAN3TJqOVjr/ ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Exceptionhandler broken on linux
On Sun, 06 May 2007 18:33:13 -0400 Dennis Schridde [EMAIL PROTECTED] wrote: Am Montag, 7. Mai 2007 schrieb [EMAIL PROTECTED]: On Sun, 06 May 2007 18:08:12 -0400 Giel van Schijndel [EMAIL PROTECTED] wrote: [EMAIL PROTECTED] schreef: On Sun, 06 May 2007 17:50:50 -0400 Giel van Schijndel [EMAIL PROTECTED] wrote: [EMAIL PROTECTED] schreef: On Sun, 06 May 2007 17:29:20 -0400 Dennis Schridde [EMAIL PROTECTED] wrote: Ok, then we probably don't need CMake. At least not for MacOS. The current Autotools seem to work quite nicely, raw is mainted by Giel, which leaves only the poor MSVC users, who only have Troman with SVN access, but he afaik doesn't use the shipped project files. I can not get autotools or raw makefile to work. (I post messages on list about this) I assume you mean this: https://mail.gna.org/public/warzone-dev/2007- 05/msg00010.html ? I see one thing that is probably wrong there, you're using the MSVC dev-package (which should cause no problems until linking I suppose). That however doesn't explain that compile error, which I'm sure stands apart from the makefile system. I'm guessing it is a bison error. I can only get MSVC to work with latest versions. Autotools did work before the gettext stuff was added. Can you compile latest svn version with mingw/msys? I can compile it with MinGW using the raw makefiles. (Don't have MSYS on my system) Which bison flex version you use? C:\bison --version bison (GNU Bison) 2.1 C:\flex --version flex version 2.5.4 PS Note that on the download page (here: http://wz2100.net/downloads.html ) we have a MinGW development package as well as an MSVC one. -- Giel I follow this, Developer's guide: 1. Get the sourcecode from svn://svn.gna.org/warzone/trunk 2. Get the devpkg 3. Get Flex 2.5 and Bison 1.8 or 2.3 from http://gnuwin32.sf.net/ (Do NOT get 2.1! That one is buggy and known to not work!) 4. When using MSVC additionaly download the Windows Platform SDK 5. Copy makerules/config.mk.tmpl to makerules/confik.mk and adjust the settings 6. Copy src/version.c.tmpl to src/version.c and adjust the version/revision numbers Note: If you intend to distribute the compiled binary those numbers need to be accurate! Where did you get that from? version.c was removed months ago... Here: http://download.gna.org/warzone/development/ bottom page. 2.1 is buggy? It created serious problems on MSVC at least. Do not know. It works fine here under MSVC. -- Start providing for your family by becoming a paralegal. Click Now. http://tagline.hushmail.com/fc/CAaCXv1VQlyccnETSeLb32y4fVc9naER/ ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
[Warzone-dev] loop.c change?
Why was this removed? SDL_Delay(20); //Added to prevent busy loop, and get CPU time back when paused! WZ eats all CPU time now, even when paused? -- Click for dental plans with huge savings, top service and coverage http://tagline.hushmail.com/fc/CAaCXv1KbKlLGQrC3Jgc10pLHlfwUrjf/ ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] MSVC .proj file patch
On Wed, 02 May 2007 14:07:14 -0400 Dennis Schridde [EMAIL PROTECTED] wrote: Am Mittwoch, 2. Mai 2007 schrieb [EMAIL PROTECTED]: This adds filters to .proj file, so better organize in folders (filters). Could you send a file instead? Thanks, Dennis Here it is. Hope it send correct. -- Click to receive credit card help and get out of debt fast http://tagline.hushmail.com/fc/CAaCXv1QMqWaycdSR6F6ja6U34diWNWs/ Warzone2100.vcproj Description: Binary data ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] loop.c change?
On Wed, 02 May 2007 14:51:17 -0400 Dennis Schridde [EMAIL PROTECTED] wrote: Am Mittwoch, 2. Mai 2007 schrieb Giel van Schijndel: Dennis Schridde schreef: Am Mittwoch, 2. Mai 2007 schrieb Giel van Schijndel: Dennis Schridde schreef: Am Mittwoch, 2. Mai 2007 schrieb [EMAIL PROTECTED]: Why was this removed? SDL_Delay(20); //Added to prevent busy loop, and get CPU time back when paused! WZ eats all CPU time now, even when paused? Of course not... We still have the SDL_framerateDelay... Which does not call SDL_Delay if we don't reach our requested frame rate, and that in turn results in CPU hogging. Apart from that I believe that SDL_framerateDelay doesn't get called in the menus. So I think we at least need an explicit SDL_Delay(1) call, maybe only if SDL_framerateDelay didn't call SDL_Delay. I didn't recognize any sideeffects, but it might be possible that we now eat the CPU in the menu or on slow computers. Maybe we should setup a minimum-delay for sdl-framerate. SDL_Delay(1) wont work as expected afaik, since the minimum tick precission guaranteed by SDL is 10ms. Almost correct, that is the precision of the kernel's CPU scheduler although I believe most Linux versions 2.6 have a time slice of 1 msec. Apart from that an SDL_Delay(1) call is just an explicit call to yield the current process so the kernel can use the remaining CPU time and divide it among other processes. Also SDL_Delay guarantees nothing about the amount of time that will be waited, only that it will be at least the time you specify. So a call like SDL_Delay(20) could very well result in losing CPU for 750 ms (if the OS's scheduler decided so). Doesn't the scheduler distribute CPU time between all applications anyway? I don't think we can force it to give us all the CPU. Currently we only request as much as to keep a certain framerate. Which hits the limits on slow PCs, what I don't think is bad (since why would we like to drop the fps even more). The only reason we inserted the delay originaly, was because eg. laptop users don't need 100fps, but would like to keep their CPU idle instead. They can lower the framerate down to 1fps if they want, and that will be exactly what they get. No more, maybe less. So currently the real only issue is that there is no delay in the mainmenu. So then why remove it? It did not hurt anything correct? If game pause, it should take up 0 CPU time. I also wonders how vsynch plays with the delays? Does matter at all if on/off? -- Click here for free information on consolidating your debt. http://tagline.hushmail.com/fc/CAaCXv1QPxS940UplQ6PnAtbi0K8ck6N/ ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Build 1216: Pcx again
On Tue, 01 May 2007 01:01:59 -0400 Jose Ivey [EMAIL PROTECTED] wrote: Build 1216, Using MSVC and fresh SVN download 1LINK : fatal error LNK1104: cannot open file '.\Debug\pcx.obj' I tried excluding pcx.c from the build, but that just caused more problems. Cleaning also did not help. You did not exclude it from project. Linker still see pcx.c in project. That is why the message. Delete file in project, and add png.c in place. Then will compile OK again. -- Free health insurance quotes. Great rates for individuals and families. Click Now. http://tagline.hushmail.com/fc/CAaCXv1QUczqYKhYE5MTzNC6P8MlOr6t/ ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Pieslicer and PIE question?
On Tue, 01 May 2007 22:20:01 -0400 Jose Ivey [EMAIL PROTECTED] wrote: -Original Message- [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Tuesday, May 01, 2007 3:35 PM To: Development list Subject: [Warzone-dev] Pieslicer and PIE question? I try to compile Pieslicer with this version for free: http://msdn.microsoft.com/vstudio/express/vb/ And there is many errors. Has anyone updates on source to fix all errors? Or do we make new format like .obj or .3ds since editor already made for these? The only thing that needs to add is connector points I thinks? It compiles and runs under Vb6, but has a bunch of error in Vb2005 - not of which appear too serious. If we really have permission to use the code then it's worth fixing. I no have VB6. Never try visual basic before to fix those errors. I think only change to add is png and bigger texture sizes. I can not seem to find post by developer of pieslicer on RTS. I think many posts have be deleted because of crash on that site before? I am sure he said do what you wish with code. Anyone still have a copy of what he say? -- Click to get a free auto insurance quote from top company at discount http://tagline.hushmail.com/fc/CAaCXv1QRVxFRqyPDWuUodcA8gVvrE3r/ ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Pieslicer and PIE question?
On Tue, 01 May 2007 20:17:40 -0400 Jose Ivey [EMAIL PROTECTED] wrote: Can we use the pie slicer code? I think it would be nice to have all known WZ utilities put on svn to prevents loss of sources like before. We no know how long other sites will keep pieslicer source up? That is pie slicer (when find permission from developer) [ PIE editor] wdgload (Rodzilla have source?) [Helps unload wdg into files so then can convert to .wz] EditWorld32 (source lost, but have original source) [MAP editor] Anything else? -- Click for free info on associates degrees and make $150K/ year http://tagline.hushmail.com/fc/CAaCXv1JDCL82QhodeL7lOxQvWJB3HUN/ ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
[Warzone-dev] Warzone playability change to much?
If you compare original with current version, you can makes very unbalance units. What can be done about this? Make adding more weapons much more expensive or make unit fire allot slower, move slower? How to decide? AI no build multiple weapons per unit right? -- Click for a free comparison on healthcare coverage and save 100's http://tagline.hushmail.com/fc/CAaCXv1QUc4p0IK9TXBqrK72Si5r5GQK/ ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Warzone networks code
On Wed, 02 May 2007 00:40:24 -0400 The Watermelon [EMAIL PROTECTED] wrote: On 5/1/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: What to do with current networks code in WZ? Try to fix, any one good at network code/problems in latency/sych? Or should we just use game network libs that is open source that handle code for dial modem users or LAN users? I know we talk abouts this before, but nothing I recall was said about what to do/use? These I find that we may be able to work with, http://www.opentnl.org/faq.php is C++ GPL works with Mac, window,linux. HawkNL http://www.hawksoft.com/hawknl/ LGPL, mac, window, linux http://www.zoidcom.com/ Free no comercial use, windows, linux, no mac source? http://www.rakkarsoft.com/ Not GPL anymore, it is Creative Commons Attribution ? http://sourceforge.net/projects/zige/ windows/linux BSD license C/C++ http://twistedmatrix.com/projects/core/ Python, so works for all ? http://www.libsdl.org/projects/SDL_net/ We use this now. After looking at both gamelogics and netcode of wz relatively extensively,I figured out that it's not only netcode that makes wz unplayable in MP,but also the non-constant gamelogics update rate makes the synchronization process impossible,because the PC spec varies from player to player in a mp game. IMO we will need to fix the non-constant gameframe problem first and see the results of such fix before trying to rewrite the netcode,maybe the net desynchronize is 'suddenly' fixed once we fix the gameframe stuff... Was anyone heavy player of 1.x WZ? How was netcode with that? WZ 2.x net code was all new I think because of no DX networking, so I thought problem is with that. If 1.x has same issue, then it is design problem ? -- Need cash? Click to get an instant cash advance http://tagline.hushmail.com/fc/CAaCXv1KmEKEYlHkjiyYriNtVEukIJ6l/ ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] mingw/msys errors help?
Still trying to compile with mingw/msys. I now try make -f Makefile.raw and gets this, mingw32-ar rcv ../libframework.a configfile.o debug.o exceptionhandler.o frame.o frameresource.o heap.o input.o resource_parser.tab.o resource_lexer.lex.o strres.o strres_parser.tab.o strres_lexer.lex.o treap.o trig.o SDL_framerate.o make[2]: mingw32-ar: Command not found make[2]: *** [../libframework.a] Error 127 make[2]: Leaving directory `/f/warzone_src/gna/lib/framework' make[1]: *** [framework] Error 2 make[1]: Leaving directory `/f/warzone_src/gna/lib' make: *** [lib] Error 2 What is mingw32-ar ? -- Debt collectors calling your house? Click here to consolidate into one payment. http://tagline.hushmail.com/fc/CAaCXv1QPRU18U4G9dtRJs1PjaI313et/ ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] mingw/msys errors help?
On Sun, 29 Apr 2007 09:54:22 -0400 Giel van Schijndel [EMAIL PROTECTED] wrote: Jose Ivey schreef: I thought GNUWin32 had a tool to download (getnuwin32) all the latest tools here: http://sourceforge.net/projects/getgnuwin32 It seemed to work ok for me, though it takes up 200mb+ when you get everything. It does download bison 2.1 rather than 1.875, so you have to re- install the earlier bison. For Warzone we don't depend on any specific version of Bison, so as long as you have version 1.31 or higher (which includes 2.1) of Bison you should be fine. -Original Message- From: [EMAIL PROTECTED] [mailto:warzone-dev- [EMAIL PROTECTED] On Behalf Of Dennis Schridde Sent: Sunday, April 29, 2007 4:49 AM To: Development list Subject: Re: [Warzone-dev] mingw/msys errors help? Dev is me, I guess? A devpkg with flex in it? Possible. Someone said he wants to create a gnuwin32 installer for recent versions of the tools, I think... That someone would be me. I have to say though that both Flex and Bison are rather annoying pieces of code to get to compile (although it is impossible). Apart from that I'm a disaster at packaging stuff for M$Win (give me a debian style package manager any time and I'd be happy). Therefore I tried to contact some people of the GnuWin32 project, it seems to be dead however (well at least the mailinglists and forums on sourceforge). -- Giel I forgets Dev also mean Development team. lol. :) Yes, GnuWin32 seems to have stop for long time. I try getnuwin32 and see how it helps. Anyone know if possible to compile faster? It takes 2x long to compile on gcc than on MSVC. I got dual core cpu, and see only 50% use with mingw/msys 100% with MSVC. -- Get free life insurance quotes from top companies. Click Now. http://tagline.hushmail.com/fc/CAaCXv1QSYRYgkQ00cvddusP3dUPpgYh/ ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] mingw/msys errors help?
On Sun, 29 Apr 2007 14:45:34 -0400 Dennis Schridde [EMAIL PROTECTED] wrote: Am Sonntag, 29. April 2007 schrieb [EMAIL PROTECTED]: .../makerules/configure.mk:1: ../makerules/config.mk: No such file or directory Did that work without -j3? Maybe the raw makefiles don't support it... --Dennis No. $ make -f Makefile.raw make -f Makefile.raw -C po make[1]: Entering directory `/f/warzone_src/gna/po' .../makerules/configure.mk:1: ../makerules/config.mk: No such file or directory .../makerules/configure.mk:7: *** You must set VERSION in .../makerules/config.mk. Stop. make[1]: Leaving directory `/f/warzone_src/gna/po' make: *** [po] Error 2 -- Become an interior designer and make up to $100/hour, click now! http://tagline.hushmail.com/fc/CAaCXv1QGcUET1hZzWKpt8y1jfplzUIy/ ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] no more MSVC support
On Sun, 29 Apr 2007 15:42:57 -0400 Jose Ivey [EMAIL PROTECTED]
wrote:
In addition to many warnings I get the following errors when I try
to
compile in MSVC.
c1 : fatal error C1083: Cannot open source file:
'..\lib\ivis_opengl\bspimd.c': No such file or directory
strres_parser.tab.c(874) : error C2449: found '{' at file scope
(missing
function header?)
strres_parser.tab.c(1398) : error C2059: syntax error : '}'
scriptvals_parser.tab.c(981) : error C2449: found '{' at file
scope (missing
function header?)
scriptvals_parser.tab.c(2127) : error C2059: syntax error : '}'
script_parser.tab.c(3525) : error C2449: found '{' at file scope
(missing
function header?)
script_parser.tab.c(8247) : error C2059: syntax error : '}'
resource_parser.tab.c(888) : error C2449: found '{' at file scope
(missing
function header?)
resource_parser.tab.c(1443) : error C2059: syntax error : '}'
chat_parser.tab.c(1393) : error C2449: found '{' at file scope
(missing
function header?)
chat_parser.tab.c(2135) : error C2059: syntax error : '}'
audp_parser.tab.c(953) : error C2449: found '{' at file scope
(missing
function header?)
audp_parser.tab.c(1560) : error C2059: syntax error : '}'make
They did not update the .sln/project files yet, so you have to
delete bspimd.c from project space. I think there are other files
also that need to be delete.
Did you install bison/flex latest versions?
This is one I use,
bison (GNU Bison) 1.875
flex.exe version 2.5.4
--
Click to get a cherished mother's ring at drastically reduced prices
http://tagline.hushmail.com/fc/CAaCXv1M4PEl8inLO6GGjwbji4NEp1c2/
___
Warzone-dev mailing list
Warzone-dev@gna.org
https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] no more MSVC support [here is patch to fix]
If you get svn 1192, then apply this, and should compile OK now.
Index: Warzone2100.vcproj
===
--- Warzone2100.vcproj (revision 1192)
+++ Warzone2100.vcproj (working copy)
@@ -1,7 +1,7 @@
?xml version=1.0 encoding=Windows-1252?
VisualStudioProject
ProjectType=Visual C++
- Version=8,00
+ Version=8.00
Name=Warzone2100
ProjectGUID={BDDCCB7B-F4F7-4768-A1C3-AE20E9F5FDFC}
RootNamespace=Warzone2100
@@ -275,6 +275,14 @@
File
RelativePath=..\lib\ivis_opengl\bspimd.c
+ FileConfiguration
+ Name=Debug|Win32
+ ExcludedFromBuild=true
+
+ Tool
+ Name=VCCLCompilerTool
+ /
+ /FileConfiguration
/File
File
RelativePath=..\src\bucket3d.c
@@ -737,6 +745,10 @@
/File
File
+ RelativePath=..\lib\ivis_common\piestate.c
+
+ /File
+ File
RelativePath=..\lib\ivis_opengl\piestate.c
FileConfiguration
@@ -759,10 +771,6 @@
/FileConfiguration
/File
File
- RelativePath=..\lib\ivis_common\piestate.c
-
- /File
- File
RelativePath=..\lib\ivis_opengl\pietexture.c
/File
--
Lower your debt by up to 50%. Click here to find out how.
http://tagline.hushmail.com/fc/CAaCXv1QPxbxxC2HzAPaCJaGRLu5UrqR/
___
Warzone-dev mailing list
Warzone-dev@gna.org
https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Build 1202: pcx.c
On Sun, 29 Apr 2007 19:48:17 -0400 Jose Ivey [EMAIL PROTECTED] wrote: Build 1202, MSVC c1 : fatal error C1083: Cannot open source file: '..\lib\ivis_common\pcx.c': No such file or directory Where can I find pcx.c? This is the new png handler, right? Yes.. remove pcx.c and add png.c They have to update vcproj file again. ;) -- Don't pay a high mortgage rate. Click to find an affordable mortgage. http://tagline.hushmail.com/fc/CAaCXv1QbtVZPf6lFXCPfdXKfuPxLPCx/ ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Finding map problem(s)
On Sat, 28 Apr 2007 05:27:30 -0400 Per Inge Mathisen [EMAIL PROTECTED] wrote: On 4/28/07, [EMAIL PROTECTED] wrote: Why is debug build no default for building with mingw/msys /linux? I think this why people no see asserts! You must do --enable- debug now for it to enable debug mode. IMHO, I think --enable-debug=yes should be the default for all but release builds. Finally found problem. In rev 227 works, all after do not, it asserts in map. Difference is debug routines (in 229?)? I am too tire now, so can't check for sure, but maybe someone check reason? That would be the change that made the assert visible in MSVC builds. Earlier than this, asserts were just ignored on MSVC. For quite a while, asserts were disabled for all builds. Can you post a backtrace of and instructions for how to reproduce the assert you are seeing? - Per I try with mingw/msys also, so it not MSVC specifics. You mean asserts are ignore in windows builds no matter what compiler? Download the map that Dev fix and posted to mailing list. Then install maps. Start one player skirmish. Then start game. (4 player game). Now move to the center of map where there is raised area with water in middle. It will start to assert when you near. For backtrace, I am not sure how to do this in mingw/sys. I can do this in MSVC OK when I abort. All values in range, h=0223 + dx=-4 + dy=-3 * ELEVATION_SCALE=2 h=0223 + dx=-3 + dy=-2 * ELEVATION_SCALE=2 h=0216 + dx=-3 + dy=-3 * ELEVATION_SCALE=2 h=0216 + dx=-3 + dy=-2 * ELEVATION_SCALE=2 hits this asserts...(and others also) retVal = (SDWORD)((h0 + dx + dy) * ELEVATION_SCALE); ASSERT((retValMAX_HEIGHT,Map height's gone weird!!!)); return ((SWORD)retVal); retVal MAX_HEIGHT should be maybe ?? // Maximun expected return value from get height #define MAX_HEIGHT (256 * ELEVATION_SCALE) so MAX_HEIGHT = 512 error : Assert in Warzone: file map.c:1450 : map_Height (retValMAX_HEIGHT), last script event: 'chooseScoutArea' error : Map height's gone weird!!! error: Error in Warzone: file map.c, function map_Height, line 1480 error: Map height's gone weird!!! error: Error in Warzone: file map.c, function map_Height, line 1499 error: Map height's gone weird!!! -- Click for free info on online degrees and make $150K/ year http://tagline.hushmail.com/fc/CAaCXv1S7YlMML7sMitnjesMKT46dlWe/ ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
[Warzone-dev] loading bar?
Anyone recall which rev broke colours for star bar? It was white/grey before, now it strange colors like blue/yellow/white. The loading bar you see on bottom of screen. -- Click for free comparison on adjustable rate home loans, 0 down, low rates http://tagline.hushmail.com/fc/CAaCXv1KXBaIaWAF0YgjVaaItUyCuL1S/ ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
[Warzone-dev] mingw/msys errors help?
rev 1192: $ ./autogen.sh + checking for xgettext = 0.15 ... You must have xgettext installed to compile . Download the appropriate package for your distribution, or get the source tarball at ftp://ftp.gnu.org/pub/gnu/gettext/ + checking for msgfmt = 0.15 ... You must have msgfmt installed to compile . Download the appropriate package for your distribution, or get the source tarball at ftp://ftp.gnu.org/pub/gnu/gettext/ + checking for autoconf = 2.56 ... found 2.61, ok. + checking for automake = 1.8 ... found 1.9.6, ok. + checking for bison = 1.31 ... found 1.875, ok. + checking for flex = 2.4.2 ... ./autogen.sh: line 61: [: :\msys\1: integer expression expected ../autogen.sh: line 63: [: :\msys\1: integer expression expected found :\msys\1.0\bin\flex.exe, ok I know must get those pakage, but how fix 'line 61: [: :\msys\1: integer expression expected' ? Dev, you plan on new devpackage for mingw/msys that has package in them? -- Click for free info on accredited degrees with 150K/ year potential http://tagline.hushmail.com/fc/CAaCXv1JCgNfOILQr4saSutGyrQhSb7i/ ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
[Warzone-dev] Finding map problem(s)
I do testing to find problems for map asserts, and in test with lav_coyotes map, the problem is not present in 2.0.2.3. It is present in rev 457 (so all 2.0?) //svn.gna.org/svn/warzone/branches/2.0 is wrong someplace. Also, water is change from blue to yellow/brown colour? Trunk rev 592 is Bad. 500 is bad... 300 is bad,150 works. Strange is when water is blue it works (so far), then other than blue, it asserts. So problem is somewhere between rev 150 - 300 in trunk. Must be better way to test. :S Tooks 3 hours to narrow down to this! -- Debt collectors calling your house? Click here to consolidate into one payment. http://tagline.hushmail.com/fc/CAaCXv1QPRQmhzhlz38y5O1YJllYUEzU/ ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
[Warzone-dev] patch testing?
Trying to play test latest (rev 1183), and seem more and more asserts are present, and must do 'ignore' much more now. When patch submits, do people test in both MP and SP? Do even try to research/build units the no cheat way? Anyone else notice all asserts now play SP game? -- Get preapproved for a mortgage in minutes. Great rates and service. Click Here. http://tagline.hushmail.com/fc/CAaCXv1KZGAd3j0xUu3WbJ7BSw5VI6mt/ ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] patch testing?
On Thu, 26 Apr 2007 17:56:44 -0400 [EMAIL PROTECTED] wrote: Trying to play test latest (rev 1183), and seem more and more asserts are present, and must do 'ignore' much more now. When patch submits, do people test in both MP and SP? Do even try to research/build units the no cheat way? Anyone else notice all asserts now play SP game? I forgots to post my asserts. :o error : scrBaseObjGet: was passed an invalid pointer error : interpRunScript: could not do var func error : interpRunScript: *** ERROR EXIT *** (CurEvent=1) error : Original trigger ID: 1 (of 12) error : Current event ID: 1 (of 12) error : Call depth : 0 error : interpRunScript: error while executing a script error : Assert in Warzone: f:\warzone_src\gna\lib\script\interp.c:958 : interpRunScript (FALSE), last script event: 'enm1Start1Trig (CODE)' error : eventFireTrigger: trigger enm1Start1Trig (CODE): code failed error : Assert in Warzone: f:\warzone_src\gna\lib\script\event.c:1134 : eventFireTrigger (FALSE), last script event: 'enm1Start1Trig (CODE)' error : stackReset: stack is not empty error : Assert in Warzone: f:\warzone_src\gna\lib\script\stack.c:1076 : stackReset (((psCurrChunk == psStackBase) (currEntry == 0))), last script event: 'enm1Start1Trig (CODE)' error : scrBuildUnit: NULL factory object error : Assert in Warzone: f:\warzone_src\gna\src\scriptfuncs.c:1475 : scrBuildDroid (FALSE), last script event: 'enm2Start1Evnt' error : interpRunScript: could not do func error : interpRunScript: *** ERROR EXIT *** (CurEvent=8) error : Original event ID: 8 (of 12) error : Current event ID: 8 (of 12) error : Call depth : 0 error : interpRunScript: error while executing a script error : Assert in Warzone: f:\warzone_src\gna\lib\script\interp.c:958 : interpRunScript (FALSE), last script event: 'enm2Start1Evnt' error : eventFireTrigger: event enm2Start1Evnt: code failed error : Assert in Warzone: f:\warzone_src\gna\lib\script\event.c:1162 : eventFireTrigger (FALSE), last script event: 'enm2Start1Evnt' error : Error while processing audio context: Invalid Operation error : Assert in Warzone: f:\warzone_src\gna\src\scriptfuncs.c:1475 : scrBuildDroid (FALSE), last script event: 'enm2Start1Evnt' error : interpRunScript: error while executing a script error : Assert in Warzone: f:\warzone_src\gna\lib\script\interp.c:958 : interpRunScript (FALSE), last script event: 'enm2Start1Evnt' error : eventFireTrigger: event enm2Start1Evnt: code failed error : Assert in Warzone: f:\warzone_src\gna\lib\script\event.c:1162 : eventFireTrigger (FALSE), last script event: 'enm2Start1Evnt' error : Error while processing audio context: Invalid Operation last message repeated 2 times -- Debt collectors calling your house? Click here to consolidate into one payment. http://tagline.hushmail.com/fc/CAaCXv1QPRN24kokQqQW78P33GeQdHxs/ ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] map for testing as requested
Posted by Dennis Schridde on April 24, 2007 - 16:14: Am Dienstag, 24. April 2007 schrieb kim metcalfe: did read where a map was requested with certain stuff required.. read the readme inside. see the pics on the forums. Nice map. And nice tileset. :) I merged all the files into one .wz file (put it into ~/.warzone2100/maps/) and made it trunk compatible. Results attached. --Dennis Thanks to lav_coyote for map, it does look nice. Can you upload the .lnd file instead of the compiled version? I do have errors, error : gwRouteLength: warning only partial route between gateways at (84,86) and (35,32) zone 2 error : gwRouteLength: warning only partial route between gateways at (35,32) and (84,86) zone 2 error : gwCheckZoneSizes: warning zone 1 at (99,21) is too large 1201 tiles (max 600) error : gwCheckZoneSizes: warning zone 2 at (56,58) is too large 7939 tiles (max 600) error : gwCheckZoneSizes: warning zone 3 at (19,100) is too large 970 tiles (max 600) error : gwCheckZoneSizes: warning zone 4 at (102,99) is too large 939 tiles (max 600) error : gwCheckZoneSizes: warning zone 5 at (30,12) is too large 880 tiles (max 600) (retValMAX_HEIGHT), last script event: '14 (CALL_STRUCTBUILT)' error : Map height's gone weird!!! error : Assert in Warzone: f:\warzone_src\gna\src\map.c:1447 : map_Height (retValMAX_HEIGHT), last script event: 'everySec' -- Looking for insurance? Compare and save 50% today. Click here. http://tagline.hushmail.com/fc/CAaCXv1QT6psO69nUyld4ygvPwJftm94/ ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
[Warzone-dev] MAP wdg -.wz convert FAQ
This is how to convert normal map WDG to .wz. Normal in that no custom textures, since that is lots more work. Need to convert pxc to png, and then lots edit in addon.lev. So we no do that now. :) 1: get wdgload biglist2.txt that Rodzilla make. He upload on mailing list. 2: find mapname.wdg you wants. 3: edit biglist2.txt to have maps names *see below* 4: run wdgload [wdgload, biglist2.txt mapname.wdg should all be in folder to keep clean, otherwise wdgload converts ALL *.wdg files!] 5: it makes hugezip.zip file 6: now extract all that to folder 7: change all files to lowercase 8: rename addon.lev to mapname.addon.lev (lower case) 9: change all / to \ IN mapname.addon.lev 10: change mapname on lines that start with game multiplay/maps/4c-mapname.gam (lower case) (from game multiplay/maps/4c-MapName.gam) 4c is only 4p maps in this case! 11: rezip, and then change extension to .wz 12:Stick in maps directory. Should now shows/works. NOTES: you may have to edits addon.lev much more. It depends on original map. Things like dataset might need change. I did test for map 4c-JungleBase.wdg, to see if I can converts. in biglist2.txt, you must add, multiplay\maps\4c-JungleBase multiplay\maps\4c-JungleBase.gam multiplay\maps\4c-JungleBase\DInit.bjo multiplay\maps\4c-JungleBase\Feat.bjo multiplay\maps\4c-JungleBase\Game.map multiplay\maps\4c-JungleBase\Struct.bjo multiplay\maps\4c-JungleBase\TagList.tag multiplay\maps\4c-JungleBase\TTypes.ttp So program knows names! Or you get hashed names (which no work!) If you get 8p-AnotherMap.wdg, then you add multiplay\maps\8p-AnotherMap multiplay\maps\8p-AnotherMap.gam multiplay\maps\8p-AnotherMap\DInit.bjo (and rest of them) No forget that you must edit to lowercase once program makes Hugezip.zip. Hope this helps someone? -- Click for dental plans with huge savings, top service and coverage http://tagline.hushmail.com/fc/CAaCXv1KbKlAKOlxQt8hZIkwbjHvZ7nv/ ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] MAP wdg -.wz convert FAQ
On Tue, 24 Apr 2007 16:27:28 -0400 Dennis Schridde [EMAIL PROTECTED] wrote: Am Dienstag, 24. April 2007 schrieb [EMAIL PROTECTED]: This is how to convert normal map WDG to .wz. Normal in that no custom textures, since that is lots more work. Need to convert pxc to png, and then lots edit in addon.lev. So we no do that now. :) 1: get wdgload biglist2.txt that Rodzilla make. He upload on mailing list. 2: find mapname.wdg you wants. 3: edit biglist2.txt to have maps names *see below* 4: run wdgload [wdgload, biglist2.txt mapname.wdg should all be in folder to keep clean, otherwise wdgload converts ALL *.wdg files!] 5: it makes hugezip.zip file 6: now extract all that to folder 7: change all files to lowercase 8: rename addon.lev to mapname.addon.lev (lower case) 9: change all / to \ IN mapname.addon.lev Actually it has to be the other way round. Yes, you right. Sorry about typos. -- Free health insurance quotes. Great rates for individuals and families. Click Now. http://tagline.hushmail.com/fc/CAaCXv1QUczKyf9OFPoIPjgsdB75vIvw/ ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] [Warzone-commits] r1164 - /trunk/lib/ivis_opengl/screen.c
On Mon, 23 Apr 2007 08:53:38 -0400 The Watermelon [EMAIL PROTECTED] wrote: On 4/22/07, Giel van Schijndel [EMAIL PROTECTED] wrote: Angus Lees schreef: On 4/23/07, *Per Inge Mathisen* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: On 4/23/07, Giel van Schijndel [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: * Use a variable sized array for the scanline array Much as I like variable size arrays, this will break MSVC builds, since MSVC does not support this (it is not a C99-compatible compiler, which really sucks). alloca() ? alloca isn't even standard C, although most _modern_ C compilers support it. Most compilers that support variable sized arrays define those in terms of alloca. So someone who was MSVC will have to confirm that alloca works with MSVC first. Also on Microsoft's page for the C RunTime library reference for VS.NET, they state at the end of the first section (on this page http://msdn2.microsoft.com/en-us/library/abx4dbyh(VS.80).aspx ): This version of Visual C++ is not conformant with the C99 standard. It seems that Microsoft is almost not working at their C- compiler any more. So I'm wondering should we support a compiler that isn't supported by their developers anymore? -- Giel ofcourse we should,many users including myself uses MSVC to compile,and I couldnt recall any free software I have used doesnt support MSVC project/compiler MSVC has best editor/debugger around. Download the free express version, and you will see it really is excellent. I no see real reason for use C99 specific code though, sometime it is bit easier, but only gcc supports it. Original code is pure C, so will be shame to fork project if C99 will be used. :( -- Tired of renting? Click here to buy a home without breaking the bank. Get an interest only loan. http://tagline.hushmail.com/fc/CAaCXv1KoI8B1Dfl1gfbXdQzC903kgnW/ ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] [Warzone-commits] r1164 - /trunk/lib/ivis_opengl/screen.c
On Mon, 23 Apr 2007 03:31:47 -0400 Giel van Schijndel [EMAIL PROTECTED] wrote: Angus Lees schreef: On 4/23/07, *Per Inge Mathisen* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: On 4/23/07, Giel van Schijndel [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: * Use a variable sized array for the scanline array Much as I like variable size arrays, this will break MSVC builds, since MSVC does not support this (it is not a C99-compatible compiler, which really sucks). alloca() ? alloca isn't even standard C, although most _modern_ C compilers support it. Most compilers that support variable sized arrays define those in terms of alloca. So someone who was MSVC will have to confirm that alloca works with MSVC first. I can confirm it no works. It only is OK for C++ compiler. -- Click to become an artist and quit your boring job http://tagline.hushmail.com/fc/CAaCXv1P27275om20ZyZMlFZsXctWr2q/ ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] [Warzone-commits] r1164 - /trunk/lib/ivis_opengl/screen.c
On Mon, 23 Apr 2007 15:40:54 -0400 Giel van Schijndel [EMAIL PROTECTED] wrote: [EMAIL PROTECTED] schreef: On Mon, 23 Apr 2007 08:53:38 -0400 The Watermelon [EMAIL PROTECTED] wrote: ofcourse we should,many users including myself uses MSVC to compile,and I couldnt recall any free software I have used doesnt support MSVC project/compiler As for Watermelon's comment: supporting something purely and only because many users use it is stupid (i.e. numbers alone should not be the motivation for supporting MSVC). I do believe there might be other reasons for supporting MSVC, but I don't see number of users to be a valid reason in that list. MSVC has best editor/debugger around. Well that is of course your opinion, so I'm not going to say anything for or against that. Download the free express version, and you will see it really is excellent. Sure, if you can tell me where to get it. And then only the free version of course (not free as in beer, free as in freedom). What means that? http://msdn.microsoft.com/vstudio/express/ # Price: FREE! # Download Size: 35-70 MB per Express Edition Then platform SDK and all rest about 400MB I think. ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] [Warzone-commits] r1164 -/trunk/lib/ivis_opengl/screen.c
On Mon, 23 Apr 2007 16:24:29 -0400 Gerard Krol [EMAIL PROTECTED] wrote: This is interesting, in C++ mode MSVC seems to be almost C99 compatible: http://groups.google.nl/group/comp.lang.c/browse_thread/thread/dbb0 628227294c59/231a8816e8e87e3e Could someone test this? - Gerard Yes, simple name file .cpp then can compile OK. If change all .c files to .cpp cause errors in some files, stricter control over code, and this is lots to change. ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] working sequence videos :)
On Mon, 23 Apr 2007 18:21:13 -0400 Angus Lees [EMAIL PROTECTED] wrote: On 4/23/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: On Mon, 23 Apr 2007 09:42:23 -0400 Giel van Schijndel [EMAIL PROTECTED] wrote: Angus Lees schreef: So after about a year of learning and coding (I knew nothing about warzone, opengl, ogg, multimedia in general, etc a bit over 12 months ago) I just watched the cam1 intro rpl within warzone :) The code also supports ogg theora/vorbis - and the dec130 (rpl video codec) code works but seems to have a few video glitches that are proving hard to track down. My patch is against the 2.0 branch and I just dumped a copy here: http://www.inodes.org/~gus/warzone-2.0-fmv.patch.gz http://www.inodes.org/%7Egus/warzone-2.0-fmv.patch.gz Still a few FIXMEs (and doesn't meet the coding style guide), but its not too bad. I haven't resurrected the research videos yet - only the fullscreen ones. I think I'm corrupting the first mipmap texture level afterwards or something too - start a new campaign and look at the blue dot over the oil refinery thing immediately after enjoying the movie. Oh, and the patch also updates all the .rpl paths in data/ to have the same case as was on the original CDs - since we're now case- sensitive. Now, how do we want to do this? Should I create another branch and we can perfect it there? -- - Gus What libraries does this depend on? Because I'm getting some linker errors: glBeginFragmentShaderATI, glSetFragmentShaderConstantATI, glSampleMapATI, glColorFragmentOp2ATI, glColorFragmentOp3ATI, glEndFragmentShaderATI -- that looks a lot like ATI-only OpenGL extensions, which if that is true is a real pain, since I don't have any ATI video hardware (all ATI stuff I had had a tendency of burning out, short cutting, and just stopping without explainable reason). gl_yuv.c has code for various vendor extensions to display yuv data. I ripped most of this code from mplayer but then hacked it up a fair amount. I don't have a software yuv to rgb codepath in fact - I was going to do a poll to see if anyone had hardware that wasn't covered by one of the extensions there. I'm not sure how you're meant to do opengl extensions, but whats there links and compiles without warnings for me (on linux). I have an ati card, but the particular code path in gl_yuv that I have been using (and is currently hardcoded) uses GL_ARB_vertex_program - not an extension with 'ATI' in its name. Have a look at gl_yuv.c and tell me what I'm meant to be doing to use opengl extensions :P -- - Gus I think problem was with glext.h not have all *ATI define. The Nvidia dev package no have them listed, so it could not compile link them. -- Need cash? Apply now for a credit loan with fast approval http://tagline.hushmail.com/fc/CAaCXv1QZon7aZNf9FGtwGbLu82rRPq0/ ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Color issue
On Sun, 22 Apr 2007 10:32:41 -0400 Dennis Schridde [EMAIL PROTECTED] wrote: Am Sonntag, 22. April 2007 schrieb Giel van Schijndel: Dennis Schridde schreef: As seen by several people now. Fix unknown. Reference topic: http://wz2100.net/forum/index.php?topic=461.0 Cause is unknown as well btw. This is always with the i810 drivers (i915 and i945 chips), but other games always work well. Even though it's only this driver affect I think have some bug we should try to fix. This is bug only in intel drivers. How fix then? I never seen problem on other chipsets, so it intel only problem. If they try software drivers for openGL, I bet problem no happen on linux. -- Click here for free information on nursing jobs, up to $150/hour http://tagline.hushmail.com/fc/CAaCXv1Rz1tWGsdNXJ3iwMJUaQTmWoJM/ ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
[Warzone-dev] 2 Patches again...
Nobody commit these yet again? Something wrong with them?
This fix crash compile on MSVC
Index: lib/ivis_common/pcx.c
===
--- lib/ivis_common/pcx.c (revision 1162)
+++ lib/ivis_common/pcx.c (working copy)
@@ -27,8 +27,7 @@
#include ivispatch.h
-static const size_t PNG_BYTES_TO_CHECK = 4;
-
+#define PNG_BYTES_TO_CHECK 4
static void wzpng_read_data(png_structp ctx, png_bytep area,
png_size_t size)
{
Index: src/gateway.c
===
--- src/gateway.c (revision 1162)
+++ src/gateway.c (working copy)
@@ -130,6 +130,7 @@
if (aZoneReachable != NULL)
{
free(aZoneReachable);
+ aZoneReachable=NULL;
}
}
@@ -1058,6 +1059,7 @@
if (aNumEquiv)
{
free(aNumEquiv);
+ aNumEquiv=NULL;
}
if (apEquivZones)
{
@@ -1069,6 +1071,7 @@
}
}
free(apEquivZones);
+ apEquivZones=NULL;
}
gwNumZones = 0;
}
--
Are you a homeowner in debt? Need cash now? Click here to refinance your
mortgage.
http://tagline.hushmail.com/fc/CAaCXv1QYGJm5EmL4cL67X0SzmMDG24c/
___
Warzone-dev mailing list
Warzone-dev@gna.org
https://mail.gna.org/listinfo/warzone-dev
