Re: [Warzone-dev] [Warzone-commits] r1428 - in /trunk/src: display3d.c map.h
Per Inge Mathisen schreef: On 6/3/07, Giel van Schijndel [EMAIL PROTECTED] wrote: Remove unused TILE_BITMASK and use INT32_MAX instead of possibly undefined INT_MAX. .. INT_MAX is defined to be the highest (non-negative) value a `signed int` (or just `int`) can have. INT32_MAX is the same for int32_t, so this actually makes the code non-portable. Apart from that INT_MAX is _required_ by the C-standard (I am sure of C99, I don't have the C90 document so can't check that) to be defined in limits.h. INT32_MAX on the other hand is only required when the int32_t is provided by the implementation. Whereas INT_MAX is required to be defined always (since the type `int` is required to be provided always). Some guy reported INT_MAX not working under mingw32 builds, so I changed it to something we make sure is defined. I'll be fine with going back to INT_MAX, if we add a check that it is defined in wzglobal.h or types.h or someplace else, and define it if it is not. I just dug up the ISO C90 standard document. It seems that C90 also _requires_ the definition of INT_MAX in limits.h. So I guess that if there where problems with INT_MAX being undefined the only problem might be is that the source file doesn't include limits.h. As for defining INT_MAX ourselves. To what value should we define it ?? We simply have no way of knowing what its value should be (apart from sizeof(int) * CHAR_BIT, but that requires CHAR_BIT to be defined). The problem is really simple here: both C90 as well as C99 simply _demand_ limits.h defines INT_MAX, so if any compiler doesn't meet that requirement it isn't even a C-compiler. So rather than having us to check in wzglobal.h whether Warzone is actually being compiled by a C-compiler I think the user of the compiler should do this for him/herself. Apart from that I use mingw32 myself, and the code does compile with INT_MAX, although I just found out that one of my local (non-commited) changes is of a header including limits.h, so I guess that was the problem with using INT_MAX there. Aside from that I found that platform.h includes limits.h always for WZ_OS_UNIX systems, so that explains why you didn't have this problem yourself when the mingw32 user did. So I really think this was an error having nothing to do with INT_MAX not being defined when it should be. Instead it was, most likely, the result from neglecting to include limits.h. So I'll simply do that (i.e. include that header) and go back to using INT_MAX then. -- Giel signature.asc Description: OpenPGP digital signature ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] [Warzone-commits] r1440 - in /trunk: lib/netplay/netplay.h src/cmddroid.c src/cmddroid.h src/droid.c
Dennis Schridde schreef: 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.. Not to mention that the native `int` type usually is faster than any random fixed-size integer. So throwing that speed gain away for an assurance of size which you _don't_ need, seems rather stupid to me. Even though that speed gain is usually very small (if it exists in the first place), the fact that you don't need the _only_ advantage of fixed size types, above the native C types, is enough reason _not_ to use them above the native C types. All we need as a minimum size, but those are provided for every single type anyway. -- Giel signature.asc Description: OpenPGP digital signature ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] 2.0.7 again
Dennis Schridde schreef: Giel: Should we add the other config related entries (all New entries except PNG) to the Settings section, or should we move its lone entry to General as well? If you mean these two: * New: Configurable framerate limit * New: Possibility to always allow debugmode Then I'd say yes, move them to the Settings section. -- Giel signature.asc Description: OpenPGP digital signature ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] 2.0.7 again
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Giel van Schijndel Sent: Monday, June 04, 2007 5:55 AM To: Development list Subject: Re: [Warzone-dev] 2.0.7 again Dennis Schridde schreef: Giel: Should we add the other config related entries (all New entries except PNG) to the Settings section, or should we move its lone entry to General as well? If you mean these two: * New: Configurable framerate limit * New: Possibility to always allow debugmode Then I'd say yes, move them to the Settings section. I suggest including the increase form 5 power plants to 6 to equal the number of derricks. A small, but sensible change. ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
[Warzone-dev] [bug #9275] compile fails on non-existing scriptvals_parser.tab.h
URL: http://gna.org/bugs/?9275 Summary: compile fails on non-existing scriptvals_parser.tab.h Project: Warzone Resurrection Project Submitted by: None Submitted on: Montag 04.06.2007 um 15:21 CEST Category: Build system Severity: 5 - Blocker Priority: 5 - Normal Status: None Assigned to: None Originator Email: [EMAIL PROTECTED] Open/Closed: Open Discussion Lock: Any Release: svn Operating System: GNU/Linux ___ Details: Compile on x86_64 gentoo linux fails with the following error messages since last night. I heard of at least one other confirmation (JockeTF). rm -f libwidget.a ar cru libwidget.a bar.o button.o editbox.o form.o label.o scrap.o slider.o tip.o widget.o ../../lib/ivis_opengl/libivis_opengl.a ../../lib/ivis_common/libivis_common.a ../../lib/framework/libframework.a x86_64-pc-linux-gnu-ranlib libwidget.a make[3]: Leaving directory `/var/tmp/portage/games-strategy/warzone2100-/work/warzone2100-/lib/widget' make[3]: Entering directory `/var/tmp/portage/games-strategy/warzone2100-/work/warzone2100-/lib' make[3]: Nothing to be done for `all-am'. make[3]: Leaving directory `/var/tmp/portage/games-strategy/warzone2100-/work/warzone2100-/lib' make[2]: Leaving directory `/var/tmp/portage/games-strategy/warzone2100-/work/warzone2100-/lib' Making all in src make[2]: Entering directory `/var/tmp/portage/games-strategy/warzone2100-/work/warzone2100-/src' make[2]: *** No rule to make target `scriptvals_parser.tab.h', needed by `all'. Stop. make[2]: Leaving directory `/var/tmp/portage/games-strategy/warzone2100-/work/warzone2100-/src' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/var/tmp/portage/games-strategy/warzone2100-/work/warzone2100-' make: *** [all] Error 2 !!! ERROR: games-strategy/warzone2100- failed. Call stack: ebuild.sh, line 1615: Called dyn_compile ebuild.sh, line 972: Called qa_call 'src_compile' ebuild.sh, line 44: Called src_compile warzone2100-.ebuild, line 55: Called die !!! emake failed !!! If you need support, post the topmost build error, and the call stack if relevant. !!! A complete build log is located at '/var/tmp/portage/games-strategy/warzone2100-/temp/build.log'. !!! This ebuild is from an overlay: '/usr/overlays/local-overlay' ___ Reply to this item at: http://gna.org/bugs/?9275 ___ Nachricht geschickt von/durch Gna! http://gna.org/ ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] 2.0.7 again
Hi guys. I don't know if this was fixed or will be fixed until release, but enabling players to save and load campaign games would be a requirement for release in my eyes. ( https://gna.org/bugs/?9262 ) I can't check this right now, because WZ doesn't compile on my computer anymore ( https://gna.org/bugs/index.php?9275 ) - this would be good to fix, too. Apart from that, skirmishes run (relatively) stable for me on my x86_64 gentoo. Regards, tomboy64 Jose Ivey schrieb: -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Giel van Schijndel Sent: Monday, June 04, 2007 5:55 AM To: Development list Subject: Re: [Warzone-dev] 2.0.7 again Dennis Schridde schreef: Giel: Should we add the other config related entries (all New entries except PNG) to the Settings section, or should we move its lone entry to General as well? If you mean these two: * New: Configurable framerate limit * New: Possibility to always allow debugmode Then I'd say yes, move them to the Settings section. I suggest including the increase form 5 power plants to 6 to equal the number of derricks. A small, but sensible change. ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Bugreport forum
Am Montag, 4. Juni 2007 schrieb Kamaze: I'll arrange this tonight. Oups, read that too late. I just removed the new post ability from usual members in the BR board. I also set up a sticky notice explaining the reasons: http://wz2100.net/forum/index.php?topic=691.0 And edited the old sticky: http://wz2100.net/forum/index.php?topic=55.0 Of course anyone shall feel free to edit that in case he wants to improve it. --Dennis signature.asc Description: This is a digitally signed message part. ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] 2.0.7 again
On 6/4/07, BorgCube [EMAIL PROTECTED] wrote: I don't know if this was fixed or will be fixed until release, but enabling players to save and load campaign games would be a requirement for release in my eyes. ( https://gna.org/bugs/?9262 ) I can't check this right now, because WZ doesn't compile on my computer anymore ( https://gna.org/bugs/index.php?9275 ) - this would be good to fix, too. Both of those bug reports are filed against svn trunk, not against the 2.0 branch. Are you saying that they are present also in the 2.0 branch? If so, please add this to the bug reports, as well, so that it does not get forgotten. - Per ___ 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
Ari Johnson schreef: On 6/4/07, Giel van Schijndel [EMAIL PROTECTED] wrote: Dennis Schridde schreef: 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.. Not to mention that the native `int` type usually is faster than any random fixed-size integer. So throwing that speed gain away for an assurance of size which you _don't_ need, seems rather stupid to me. Even though that speed gain is usually very small (if it exists in the first place), the fact that you don't need the _only_ advantage of fixed size types, above the native C types, is enough reason _not_ to use them above the native C types. Is this really the case? On LP64 architectures, 'int' is 32 bits while the native word size on the hardware is 64 bits. Do you have benchmarks on various systems to back this up? I think I shouldn't have even mentioned the speed difference, since it hardly is the most important argument. What is more important in this discussion is: don't use what you don't need. I'll elaborate: the only difference between a regular `int` and say `int32_t` is that `int32_t` provides an additional guarantee that it will _always_ be exactly 32bit long. This is the only difference, and as such the only advantage of using int32_t above int. If however you simply don't need that additional guarantee, then I'd say: don't use it. 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. -- Giel signature.asc Description: OpenPGP digital signature ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] [Warzone-commits] r1440 - in /trunk: lib/netplay/netplay.h src/cmddroid.c src/cmddroid.h src/droid.c
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. Compiler won't dare to optimize on the assumption that the coder will not make any assumptions on the size of his declared types, so it makes no difference either way. My person opinion right now (it could change tomorrow), is that we should just stick to the ugly UDWORD, SWORD, BOOL etc types that warzone was originally coded with, just because it makes things consistent. I like consistent. It also gives the source code a sort of retro, 90ies feel to it ;-) - Per ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] 2.0.7 again
Dennis Schridde schreef: Am Montag, 4. Juni 2007 schrieb [EMAIL PROTECTED]: On Sun, 03 Jun 2007 16:51:36 -0400 Dennis Schridde wrote: What we got so far: Does anyone know of nasty bugs which still need to be tracked down? I.e. serious crashes and the like. Anything else that needs to be backported? Just the oil anim health bar fix I do. This was a trunk-only issue, wasn't it Correct, it only was an issue with trunk, so backporting to 2.0 will not be required. -- Giel signature.asc Description: OpenPGP digital signature ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] 2.0.7 again
Dennis Schridde wrote: Am Montag, 4. Juni 2007 schrieb [EMAIL PROTECTED]: On Sun, 03 Jun 2007 16:51:36 -0400 Dennis Schridde [EMAIL PROTECTED] wrote: What we got so far: Does anyone know of nasty bugs which still need to be tracked down? I.e. serious crashes and the like. Anything else that needs to be backported? Just the oil anim health bar fix I do. This was a trunk-only issue, wasn't it? Also the multiple build units that Jose talks about in bug track... Will have a look at it in case I can find it. AFAIK, this is a trunk only issue. It works ok for me on 2.06 - Jose ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] [Warzone-commits] r1451 - in /trunk/src: display3d.c structure.h
Ari Johnson schreef: Reverted changes from r1417 and r1421 that used 'bool' instead of 'BOOL' and thereby prevented the code from building Does this really _not_ compile ? Because it _should_ compile. (Even with a non-C99 compatible compiler). Just look at lib/framework/types.h: // If we are C99 compatible, the bool macro will be defined in stdbool.h (as _Bool) #if defined(WZ_C99) # include stdbool.h #else // Pretend we are C99 compatible (well, for the bool type then) # ifndef bool # define bool BOOL # endif # ifndef true # define true (1) # endif # ifndef false # define false (0) # endif # ifndef __bool_true_false_are_defined # define __bool_true_false_are_defined (1) # endif #endif /* WZ_C99 */ So if that code doesn't compile when using bool, please fix the above code in types.h instead of reverting back to BOOL. The only scenario I can think of is that the compiler you use claims to be C99 compatible, but doesn't provide macros: bool, true, false and __bool_true_false_are_defined (which it _should_ provide if it claims C99 compatibility). Although I might look over something. -- Giel signature.asc Description: OpenPGP digital signature ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] [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
[Warzone-dev] Current issues
The last time I was able to load my saved game, I still got an assert when a unit was produced at my home base while I was on an away mission. I was going to test that just now with the latest code, but there is now a crash when loading my saved game. I still don't know exactly when this started, but it's fairly recent and very consistent. The crash comes from structure.c line 1800. getTileFeature(map_coord(x), map_coord(y)) returns NULL and then the if() that checks psFeature-psStates-psSubtype causes a segmentation fault. These lines were both changed in r1376. r1375 does not crash when loading my saved game, but r1376 does. Someone with more knowledge of this (including why getTileFeature()'s return value is not sanity-checked before use) may want to look into it. Let me know if I can provide any further information to help. Ari ___ 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
Re: [Warzone-dev] [Warzone-commits] r1440 - in /trunk: lib/netplay/netplay.h src/cmddroid.c src/cmddroid.h src/droid.c
On 6/4/07, Giel van Schijndel [EMAIL PROTECTED] wrote: Ari Johnson schreef: On 6/4/07, Giel van Schijndel [EMAIL PROTECTED] wrote: I think I shouldn't have even mentioned the speed difference, since it hardly is the most important argument. What is more important in this discussion is: don't use what you don't need. I'll elaborate: the only difference between a regular `int` and say `int32_t` is that `int32_t` provides an additional guarantee that it will _always_ be exactly 32bit long. This is the only difference, and as such the only advantage of using int32_t above int. If however you simply don't need that additional guarantee, then I'd say: don't use it. 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. I agree on the documenting part. As for catching issues earlier that's not true at all, since you most likely simply won't have any size problems when using fixed with types (and as such there's no issue on that topic to catch). 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 Well, if you only worry about it when it's on the disk/network already then you're to late already. My thoughts for going about writing to disk/network however are that it is the responsibility of the disk/network read/write code to make sure sizes and endianness are dealt with, and _not_ the responsibility for all of Warzone's code. The first of those (read/write code being responsible) is localized and as such easy to maintain, the latter however (every single piece of code is responsible) is very difficult to maintain and debug. This of course _does_ mean that you should be fairly careful when writing those interfacing functions for reading/writing from disk/network streams. I find that to be much easier to maintain though than having to repeat writing similar code with similar responsibilities all over Warzone's codebase. The problem is that Warzone doesn't isolate such things. When reading data from disk, the common method is to read directly into a game struct. Then the endianizing code that I added has to modify it in place in the struct. It would be much better if we actually did segregate the code and ended up with a clean interface, but right now that's not what we have. This is definitely an area where we could stand to see a *lot* of improvement. Btw one example of where I think we _do_not_ need a fixed size type: uint32_t i; for (i = 0; i x; ++i) doSomethingWith(i); I hope we both can agree here, that this code really does _not_ need the fixed size guarantee (only a minimum size guarantee, because `i` needs to be able to hold `x`). Yes, we can. So in this example case I personally think code like this is better (a tiny little bit more readable as well): unsigned int i; for (i = 0; i x; ++i) doSomethingWith(i); I don't know that it's more readable, but it's not problematic. This kind of variables and most temporaries used to contain arithmetic results, are the main ones I'm thinking of really. That's fine by me. :) ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] [Warzone-commits] r1451 - in /trunk/src: display3d.c structure.h
Giel van Schijndel wrote: So if that code doesn't compile when using bool, please fix the above code in types.h instead of reverting back to BOOL. The only scenario I can think of is that the compiler you use claims to be C99 compatible, but doesn't provide macros: bool, true, false and __bool_true_false_are_defined (which it _should_ provide if it claims C99 compatibility). Although I might look over something. Every other place in the code uses BOOL. Only these two lines used bool. Lines immediately above and below each of them used BOOL. C99 also provides stdbool.h, which on my system defines 'bool'. Have you read the standard? See http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1124.pdf p. 253, which says that stdbool.h defines the bool type. Actually, yes I have read the C99 standard just to create that piece of code ^^ in types.h. If you look carefully then you see that all the #ifndef statements are only executed when I the compiler doesn't claim to support C99. So that piece of code _simulates_ C99 capability for non-C99 compilers. In the context of the platforms WZ currently has builds for, which one uses a non C99 compliant compiler? Or put differently, is this a fix in search of a problem? ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] [Warzone-commits] r1451 - in /trunk/src: display3d.c structure.h
On 6/4/07, Jose Ivey [EMAIL PROTECTED] wrote: In the context of the platforms WZ currently has builds for, which one uses a non C99 compliant compiler? MSVC. - Per ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] [Warzone-commits] r1451 - in /trunk/src: display3d.c structure.h
Per Inge Mathisen schreef: On 6/4/07, Dennis Schridde [EMAIL PROTECTED] wrote: - Run sed s/BOOL/bool/ on the sources. (Well, something more advanced, but you get the point.) Can we please postone all such ideas until 2.2 or 3.0? We _need_ a working 'svn blame' at the moment. Well luckily such a change would _only_ affect lines declaring (i.e. not defining) variables/functions and nothing else. So I don't think this would be a huge problem. Aside from that this (i.e. s/BOOL/bool/) could be done in multiple phases as well I suppose. Do not worry. You will SOON GET USED TO WRITING TYPES IN ALL CAPS!! Maybe, but not to reading caps. -- Giel signature.asc Description: OpenPGP digital signature ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] [Warzone-commits] r1454 - in /trunk: lib/widget/widget.c lib/widget/widget.h src/intdisplay.c
Am Montag, 4. Juni 2007 schrieb Giel van Schijndel: Author: muggenhor Date: Mon Jun 4 20:33:36 2007 New Revision: 1454 URL: http://svn.gna.org/viewcvs/warzone?rev=1454view=rev Log: * added an additional function to lib/widget's interface: `widgSetTipText(WIDGET* psWidget, const char* pTip)` * intdisplay.c now uses the widget interface to set tooltips on its widgets (which is the const-correct way, and better localizes memory management code; i.e. strdup() would be the dirty-hack style alternative) I wonder why the previous pTip = (const char *) was wrong... And where is that memory allocated by strdup freed? Asked differently: Was it ever freed before? If yes, why didn't it crash? --Dennis signature.asc Description: This is a digitally signed message part. ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] [Warzone-commits] r1454 - in /trunk : lib/widget/widget.c lib/widget/widget.h src/intdispla y.c
Am Montag, 4. Juni 2007 schrieb Giel van Schijndel: Dennis Schridde schreef: Am Montag, 4. Juni 2007 schrieb Giel van Schijndel: Author: muggenhor Date: Mon Jun 4 20:33:36 2007 New Revision: 1454 URL: http://svn.gna.org/viewcvs/warzone?rev=1454view=rev Log: * added an additional function to lib/widget's interface: `widgSetTipText(WIDGET* psWidget, const char* pTip)` * intdisplay.c now uses the widget interface to set tooltips on its widgets (which is the const-correct way, and better localizes memory management code; i.e. strdup() would be the dirty-hack style alternative) I wonder why the previous pTip = (const char *) was wrong... And where is that memory allocated by strdup freed? Asked differently: Was it ever freed before? If yes, why didn't it crash The widget destruction routines take care of free'ing. As for why it never crashed before, that's fairly simple: it never did free before. Maybe you want to look at my changes in r1452, r1454 was only to complete the changes of r1542. Thanks for the explanation. I didn't look there, just wondered how it works. signature.asc Description: This is a digitally signed message part. ___ 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] Add back CPU delays?
Well, maybe make this configurable.
At game start check if someone set niceCPU to 1.
If on, set the function pointer shareCPUTime = SDL_Delay;
Otherwise set the functionpointer to null.
This should be afaik faster than another if(){} in the mainloop.
- Kamaze
[EMAIL PROTECTED] schrieb:
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
___
Warzone-dev mailing list
Warzone-dev@gna.org
https://mail.gna.org/listinfo/warzone-dev
