Re: [Warzone-dev] Project rename, website changes
Zarel wrote: lots of good reasons for good changes Fine with me. - Gerard ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] [Warzone2100-commits] SF.net SVN: warzone2100:[7192] branches/lua2/data/mods/global
Kreuvf wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Dennis Schridde wrote: Explanation of the acronym TD and a short summary of the contents would be nice. I figured out that TD stands for Tower Defense which reminds me of the Starcraft defense maps. But I am curious what this is about as well ;) Correct, it stands for Tower Defense. For those who have never played one here is a short description: * You have a certain amount of lives (say 20) * Enemy units appear somewhere, and try to reach a destination * To stop them, you build towers which shoot at them and sometimes force them to travel through an elaborate maze of towers * For every unit killed you get a small amount of money (power), which you can use to build more towers * If some get through, you lose lives * After the first group, a stronger/faster group of units appears, and the cycle repeats. The lua2 branch now has a tower defense mod, which can be activated using --mod=td. It has one 4 player map where the enemies start at 2 points at the top of the map and try to reach the bottom. You have to work together to stop them all. Regards, Gerard ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Question on maps
Florian Schanda wrote: Our eventual aim is to write a random map generator for warzone Nice. I already have a start of that, but it is far from finished. Take a look at the random_map branch in the git://gitorious.org/warzone2100/gerard_.git repository. What I have currently got working is a relatively open map in different themes (arizona, rockies, urban). The urban setting looks really weird, as it is not flat enough to be a real city. To start a random map select one of the Rnd-* maps from the skirmish menu. What does not work yet is saving/loading (due to the fact that it uses the new terrain renderer) and network play. Both probably need support for a new map format. The code is in src/randommap.c. - Gerard ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] [Warzone-commits] r6929 - /trunk/lib/netplay/netlog.c
Per Inge Mathisen wrote: On Mon, Mar 30, 2009 at 4:14 PM, Git SVN Gateway g.c.k...@student.tudelft.nl wrote: Fix ticket #293: Crashes in netlog code. Did you find the same fix hidden in my 2.2 branch, too? ;-) I didn't, thanks for reminding me. I guess I'll have to set up a script that will scan for changes... - Gerard ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Mods considered harmful considered harmful
Per Inge Mathisen wrote: Popular suggested or created modifications to the game rules quickly become integrated into the core rules, draining the pool of mods available for players. True, but if the mods would not have been there, would the same changes have been included in the game? Mods mostly concern changes like graphics, balancing and new game modes. Hardcore developers love too look at the code too much to bother with that. (I probably won't be touching the terrain textures again for example) The problem was that a generalized code engine that supports all kinds of strange rules is inherently more difficult to maintain, and very much more difficult to write an actual, fun game on top of. I agree that we should be careful not to become a victim of the Inner platform effect [1]. People do not want all those choices, they just want something that's simple, fast, and intuitive. If they really want to do complicated stuff there is always the source. I would really like to have something akin to the Warcraft 3 map editor. (the unreal tournament map editor was also way too much fun) Just make a map, place units and buildings, do some modifications to the tech tree and perhaps use a few predefined triggers to do a few predefined actions (suggested set: the minimum required to make a tower defense). Dennis Schridde wrote: Multiple mods: Morrowind and Oblivion (sorry, again...) have some mods which are rather metamods. They combine several others into one. I think it is good to limit the game to load just one mod. Like you said, if people want to run multiple mods, they will have to create a new mod for that, or devise some sort of package management system. Oh, and mods should ONLY work in vanilla (no custom scripts/tech tree mods) multiplayer and skirmish games. We DO need to add support for network games with mods however. The game needs to make sure everyone has the same mod. (by checking the md5 of the .wz?) Also mods should just plain be in the mods directory. By the way, does anyone else think we've got a really messed up directory structure for the data as well? Zarel wrote: I do think we should merge mp.wz and warzone.wz back together. +1 I think it is really annoying for people when they have finished the campaign they will have to learn an almost completely different game. And it complicates stuff for us. - Gerard [1] http://en.wikipedia.org/wiki/Inner-Platform_Effect ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
[Warzone-dev] Git - SVN Gateway up and running
Hello everyone, I'm still a little sad that we didn't switch to Git. However, I made it possible to use both Git and SVN. Anyone who wants to crawl out of the SVN pit is welcome to clone git://gitorious.org/warzone2100/mainline.git If you have any interesting commits in your public repository I will pull from you and commit them to SVN, where they will end up as being committed by mr. Git SVN Gateway. A From: line at the bottom will show the original author. Any commits from SVN will also show up in the mainline repository, so you can pull/fetch from there to keep up to date with the work being done in SVN. Keep in mind that it is a manual process (I have to be able to resolve any merge conflicts) so it might lag behind a day or two. One of the problems is that I'm the only one that can operate the gateway (as you can't clone a git-svn repository). This could be solving by hosting the repository on a server somewhere, where developers could login to run the script and fix merges. Regards, Gerard P.S. For those interested, the latest version of the script can be found at http://gitorious.org/projects/warzone2100/repos/mainline/blobs/master/tools/gitsvngateway/gitsvngateway Any suggestions about shell scripting (it's my first !) or better uses of Git are welcome of course. ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Ready for the switch to git?
Hi all, I'm glad the Ready for the switch to git? email spawned a lively discussion, and that a lot of people tried to actually use git. Below are replies to different people, bundled together to prevent me from repeating myself: Zarel wrote: 2009/3/13 Stephen Swaney sswa...@centurytel.net The ability to branch freely is great but without a primary location for the source keeping track of who is 'it' sounds difficult. How do we keep all the package maintainers connected to what is going on? I echo this. Having a single repository makes sure conflicts get resolved quickly. If we don't have that, then what do we have? Several versions of Warzone, each incompatible with each other, and no way to easily merge them? That's the best part, we *do* have a way to easily merge them. Git is designed to make this easy. I mean, I wouldn't mind having my local copy as a separate repo, but it should be merged with trunk fairly quickly. In short, I prefer the current way. I think all active developers will fetch from everyone daily so we will have a smooth flow of commits. Despite everyone telling that it works I'm really curious myself how well it does. The central repository is a good fallback if it turns out not to. In addition, Git doesn't have anywhere near as good a Windows GUI as TortoiseSVN. I like being able to diff/blame/make-patch in around two clicks. Committing is two clicks. Unless you only want to commit some files, in which case it gives a list with a bunch of checkboxes. All versioned files are checked by default, and there are buttons to check all, none, or versioned only. You definitely did not try git gui and gitk. You won't have to go to the commandline for your everyday tasks. - Right click on the folder with your repository - git gui - Make some changes, click Rescan. - Click the icon in front of the changed files you want to commit, or click Stage Changed to add them all - Write a commit message in the textbox - Click commit When you want to push your commits: - Remote - Push - Push For the blame: - Repository - browse * files - Click a file I never used git gui, and I was able to figure it out quickly. Give it a try. Don't be afraid to ask, either in #warzone2100-dev or #git. (helpful people over there) Elio Gubser wrote: I'd like to stick with svn. The only _really_ issue is buggy's connection problems. We should only tackle this problem and not create new ones with introducing a completely different vcs. At least I am very happy with svn (and gna) I really feel restricted by svn. (I probably already told everyone a few times). It feels like being stuck on windows when you are used to linux, like being stuck on ice without ice skates, like programming in Visual Basic, like eating soup without a spoon. (no offense to the people who regularly do these things, especially to the ones without a spoon) You might not yet feel the restrictions (yet), but in my opinion it is best to use the most powerful tool/language/vcs from the start, rather than waiting until you need it. It might take some time getting used to it, but when you need the complicated features at least you are ready for it. bugs buggy wrote: Another Q, what are these (core.autocrlf core.safecrlf ) supposed to be set at? Svn tracks what they are (either CR or CR+LF), git don't have this, so how do we know what to set these values at ? What happens if some are CR and some are CR+LF? Or did Gerard fix this on the initial repo dump? I believe git internally uses LF, and you can ask it to convert it to another format when you checkout. It seems to work but you might have to do a git reset --hard (it's a scary name for a simple command) if git diff shows changes on all lines of all files. Regards, Gerard ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Ready for the switch to git?
Freddie Witherden wrote: +1 on sticking with SVN. Could you tell us your reasons for wanting to stick with svn? - Gerard ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Ready for the switch to git?
Per Inge Mathisen wrote: Personally I am scared by things like this: On Fri, Mar 13, 2009 at 11:49 AM, Dennis Schridde devuran...@gmx.net wrote: Devurandom has convinced me that a shared repository (with multiple people pushing to) does not work well with git. The wording is perhaps a bit unfortunate ;) Having one shared repository does work, but you would be using git just as a complicated svn clone. The nice thing about git is that it does not enforce any workflow. I think we should start out with the official git way, and see how we like it. So let's not rush wildly into the unknown, even if Buginator is hurting and git looks like the next coming of revision control right now... ;-) As long as nobody gets hurt it will all be fun and games right? - Gerard ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
[Warzone-dev] SVN - Git?
Hello everyone, Due to: - GNA being unable to provide reliable SVN access to everyone (especially to Buginator) - Terrible support for branches in SVN - Devu, Giel and me using it already I would like to propose we switch to Git (http://git-scm.com/) for our version control needs. Advantages: - Cheap local branches (try it once and you're addicted) - Good merge support - Speed (a diff between two random revisions is almost instant) - git checkout prevents the need to have different directories with different branches Disadvantages: - People have to learn to use Git (took me two days) - Less supported (it will take a year before there are git plugins for everything) Q: Why Git? Why not Bzr, Hg? A: Better to get used to the power tool now rather than to be stuck with DVCS Basic. Q: Wouldn't this leave windows users out in the cold? A: I tried msysgit 1.6.1-preview20081227 (from http://code.google.com/p/msysgit/) and it worked great in my XP vm. Not even a need to get to the command line with (the included) git-gui. Q: What if we later decide Git wasn't the right choice? A: We just commit everything to SVN again and continue to use that. For some Git propaganda see: DVCS Comparision http://vcscompare.blogspot.com/ I would ask you to check out Git, and tell me what you think. It might be best to find a small Git repo somewhere (http://gitorious.org/projects) to experiment with. You won't be able to push (the svn commit) of course, but it's enough to get a feel for it. Things to try are: cloning the repo, creating a local branch, committing to the branch, rebasing the branch, merging the branch, cherry picking a change and checking out some random point in history. Use gitk to keep track of where you are in the history tree. - Gerard ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] A plan to refactor and clean up the warzone code base
Per Inge Mathisen wrote: I would like to suggest that we start refactoring the Warzone codebase so that it can more easily be unit tested aggressively. Would it be an idea to wait for the merge from the terrain and the lua branch? That's going to be one hell of a job after we refactor the code. I might be repeating myself, but I'd like to branch and release asap, and merge the terrain and lua branches in. We can then to all the nice refactoring we want. - Gerard ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] 2.2 branch
Freddie Witherden wrote: Hi all, On 31 Jan 2009, at 09:05, Dennis Schridde wrote: Nope, not much holding back 2.2. I would like to see the new lobby protocol which Gerard was working on make it into 2.2. Will simplify things in the future. I did slightly more work on it, and was not satisfied with the end result. It just didn't feel right (oooh). I think we should completely rewrite the joining/hosting code. Also, JSON is quite OK, but a way to send lua objects safely would be even better. We would have one dependency (+one interface) less. - Gerard ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
[Warzone-dev] Branching for 2.2
Hi everyone, Merry Christmas! We have only just released 2.1, but I think we should be deciding on the next release already. The two points to consider are: * what do we want to include? * when do we want to do the release.? We currently have a really stable trunk. (when was the last time it crashed for you?) I think we should not waste this by adding a lot of stuff (like the new terrain renderer) before doing a release with it. My proposal would be to branch off for 2.2 within a few weeks. We then push out some beta's to quickly iron out all bugs and we can release 2.2 in a few months. That is, if Giel is willing to manage another release after so little time has passed. (great job on 2.1 by the way) What do you think about this? I'd really like to have the new terrain in trunk, so I'd like the branch to be as soon as possible. Regards, Gerard ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Branching for 2.2
Dennis Schridde wrote: Am Donnerstag, 25. Dezember 2008 15:51:16 schrieb Gerard Krol: Hi everyone, Merry Christmas! We have only just released 2.1, but I think we should be deciding on the next release already. Generally I agree. But what are the new features of current trunk? snip Is that *all*? Even compared to the late 2.1 betas that's *nothing*... I think the main point of this is that we should be updating the changelog. It has now been 7 months since we branched 2.1. This was revision 4789 (compared with almost 6500 we are now). I don't think 7 months between branching different releases is too short. Checking the SVN log shows enough changes. I don't know how many of those were backported of course. I don't feel like updating the changelog now, but I'll check it out somewhere this week. Forgot something: Before we do any release, I'd like to finish my work on the projectiles, which will likely not happen before end of January (other work takes priority...) I already have a replacement for the current projectile system, but the more advanced aiming functionality takes a bit more time to implement. At least more than the 10 minutes of spare time I (should) have. The big question is, would this be a reason to delay the branching + release for a month or two? Does it fix any bugs? Especially if you don't know if you will have time to finish it soon, I don't think we should wait for it. I agree with Per that 2.2 would be a nice target for long term support. I only hope that it doesn't become as much of a pain as 2.0. Regards, Gerard ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] File Association For Mods
Per Inge Mathisen wrote: On Sat, Nov 29, 2008 at 6:13 PM, Dennis Schridde [EMAIL PROTECTED] wrote: Mixing and matching mods is never a good idea. If we encouraged it then it would just lead to more useless bug reports. That's all the fun. ;) Multiple mods. Of course there'd be incompatibilities, but that should not concern us, as long as we are not causing them. Do you really think users will understand that what the cause of the bug is? It sure will not be obvious, eg they could play a long time before the effect becomes apparent, perhaps forget that they used mods, and it may show itself in really strange glitches. If multiple mods is made easy, we will spend a lot of time going over vague bug reports due to it. Sure we can just close them when (if) we realize that the cause behind the bug report is conflicting mods, but wasting time on *bogus* bug reports is far more annoying than spending time tracking real bugs. I think multiple small mods would be a cool feature. You know the unreal tournament options like large heads etc.? I think it would be really cool to be able to have both a extended research mod and a large turrets mod for example. Perhaps we should integrate the tiny mods in the game (and make them inter-operate well), and then only allow one external mod active at a time. - Gerard ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
[Warzone-dev] Upgrade to Subversion 1.5?
Hi all, We are using a lot of branches lately, and it would be nice to be able to use the new merge tracking features which are available in svn 1.5. As far as I know upgrading would not have any disadvantages (after rebuilding the index). See http://subversion.tigris.org/svn_1.5_releasenotes.html for more information. What's your opinion about this? If nobody objects I'll open a ticket at Gna! and ask them to upgrade. - Gerard ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] New Terrain Renderer
Kreuvf wrote: How is the performance affected? Try it out yourself (branches/terrain) and report the framerate you get. For me it drops the framerate by 50% currently. But this is with 7 terrain layers and no optimisations. Most levels look fine with only 4 layers. I guess we can reduce it to a framerate drop of 20% with the knowledge we currently have. If we were to study some opengl, or a guru passes by, it can probably be 2x faster than what we have now. - Gerard ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
[Warzone-dev] New Terrain Renderer
Hi all, Please check out http://forums.wz2100.net/viewtopic.php?f=6t=2379p=23075#p23075 and tell me what you think. Regards, Gerard ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] How not to use a version control system
The untested commit: after a careful reading of the code you conclude that there possibly can't be any bugs left. Unfortunately a trivial bug renders the entire program unusable. Better stay available to do emergency fix-ups. (coloured cursors anyone?) Nice list. Now how to make sure people read it - Gerard Per Inge Mathisen wrote: There are various ways you should not commit things into a version control system. Let's go through some of them: The commit run: I have to go now or I'll be late for..., then you commit today's work and bolt out the door. A sure way to see to that your colleagues sit late or go home early, depending on how close to deadline they are. The blind commit: I committed *what*? Always check what changes are lurking in your working copy before doing a commit. The sweet relief commit: After painstakingly long hours of debugging, it finally works, and you wrap it up with a commit. It feels good to be done. Except you also committed tons of debug code, snarky comments and commented out parts, making sure that the next session will be even more painstaking. Always read over the whole diff again before committing. The superhuman commit: A truly massive amount of improvements and fixes in a single commit, usually signed with a suitably heroic one-liner commit message for punch-line. Since it contains so much good stuff, nobody has the heart to revert it when they find regressions, and due to its massive size, nobody else can bisect it to find errors. The commit flood: Having been bitten by the superhuman commit, you split your work instead into dozens if not hundreds of separate commits. Guaranteed to make anyone who tries to follow the commit log give up in despair, and makes the whole work impossible commit when done. The stroke of genius commit: Why didn't anyone think of this before? There is usually a good reason. Always sleep on a good idea. It may not seem so bright the next morning. The late night commit: Having *finally* fixed all the bugs and cleaned up the code, you write a long and informative commit message, squint at the rising sun, and go to bed. Except that your brain is so full of diet coke that you have no idea what you were doing, and committed from the wrong working copy. Just never commit anything after midnight. The search replace commit: You find an annoying but unimportant frequent mistake in the source code, and fix it by search and replace on all occurrances then committing the improvement. As a result, every other working copy get conflicts and nothing can be reverted or merged past this point. - Per ___ 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
[Warzone-dev] [patch #1111] Fade out the edges of the visible map to prevent popping mountains
URL: http://gna.org/patch/? Summary: Fade out the edges of the visible map to prevent popping mountains Project: Warzone Resurrection Project Submitted by: gerard_ Submitted on: Saturday 11/08/2008 at 21:27 Category: Feature Priority: 3 - Low Status: Ready For Test Privacy: Public Assigned to: None Originator Email: Open/Closed: Open Discussion Lock: Any Planned Release: None ___ Details: When looking at the horizon and scrolling over the map with fog of war enabled shows mountain ranges popping up when they enter the part of the map that is drawn. By fading the edges to transparency instead of black, they fade in beautifully. Possible problems: * Drawing order: If a droid or projectile is behind the mountain that is partially faded, it will show up as being in front of it. This was not tested. Droids only seem to be drawn for the visible part of the map however. * Performance: All map tiles are now drawn with transparency enabled. This could have an influence on the perfomance, but this was not observed. ___ File Attachments: --- Date: Saturday 11/08/2008 at 21:27 Name: fade_edges.patch Size: 4kB By: gerard_ http://gna.org/patch/download.php?file_id=4996 ___ Reply to this item at: http://gna.org/patch/? ___ Message sent via/by Gna! http://gna.org/ ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] [Warzone-commits] r3712 - /trunk/src/intelmap.c
Dennis Schridde wrote: Am Donnerstag, 7. Februar 2008 20:19:17 schrieb Gerard Krol: Author: gerard_ Date: Thu Feb 7 20:19:15 2008 New Revision: 3712 URL: http://svn.gna.org/viewcvs/warzone?rev=3712view=rev Log: Make sure that long lines of text are correctly drawn and wrapped for the intelligence display. This also works for larger fonts. This fixes bug #10913, and makes patch #965 obsolete. Modified: trunk/src/intelmap.c - Form-width, Form-height, + Form-width-40, Form-height, Magic value? Yep, oops... In fact, we need some magic value magician to dispel the entire file. - Gerard ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] [bug #10995] --nosound broken
The sound data that would be stored is the current track playing. Scripts can set this and expect to be able to query which one is playing. If the scripts select a piece of music with a certain theme and feeling, we want that track to play again when the game is loaded, preferably even at the point where it left off. A solution would be to explicitly notify the script that it is being loaded, so that it can restart the music. Also, the trouble is that it is much more difficult to keep the games internal state correct when some pieces of code are sometimes executed, and sometimes not. Minimising the amount of conditional code is a good thing I think. - Gerard Kevin Gillette wrote: the correct way to do it *is* to skip past all sound specific stuff from the game loop when --nosound is used. frankly, there's no reason at all to store any sound-related data in a savegame -- all you lose is about a second's worth of sounds that were initiated just before the save point, just as there is no noticable benefit to storing the animation frame index for cyborgs in a game like this. the benefit by not running all the sound specific stuff is that you save ticks, and not necessarily bring system requirements down, but along with other optimizations, keep them from skyrocketing upwards. On Feb 5, 2008 2:26 PM, Gerard Krol [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: URL: http://gna.org/bugs/?10995 Summary: --nosound broken Project: Warzone Resurrection Project Submitted by: gerard_ Submitted on: Tuesday 02/05/2008 at 22:26 Category: Engine: Sound Severity: 3 - Normal Priority: 5 - Normal Status: None Assigned to: None Originator Email: Open/Closed: Open Discussion Lock: Any Release: svn/trunk Operating System: GNU/Linux Planned Release: None ___ Details: The --nosound command line option is broken, using it causes an assert: never : directory: script/binary never : directory: script/data never : file: SCRIPTVAL cam1a.vlo wz : Loading script data cam1a.vlo script : allocated space for 27 events error : resGetDataFromHash: Unknown ID: 66d7b27 Type: WAV error : Assert in Warzone: frameresource.c:579 : resGetDataFromHash (psRes != NULL), last script event: 'none' warzone2100: frameresource.c:579: resGetDataFromHash: Assertion `psRes != ((void *)0)' failed. The way --nosound is implemented is wrong, it is better to act like --dry-run, and perform all operations except the actual openall calls. This makes it that you can start a game with --nosound, save, start with --sound, and continue (with the sound playing as it would have been). ___ 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] Attached fix for VPATH builds (VERSION 2)
Kelly Anderson wrote: Hmmm, amazing, as soon as I saw the patch on the mailing list I realized I could use a variable that's already set by autoconf/automake instead of the PWD thing. :-D Here's the version that properly embraces autoconf/automake. Seems to work fine here. Committed in r3406. Thanks for the patch! - Gerard ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
[Warzone-dev] New scripting language summary
Summary of opinions about replacing the scripting language: Ari: Worthwile, python too heavy weight Dennis: We should ask Troman Troman: Likes the current scripting engine (+ its syntax), does not want to sacrifice functionality Freddy: We should have an automatic converter, would like a branch Kevin: Would like to keep the old scripting language along with the new one. I think we should switch to Lua as a scripting language. The switch should be 100% so that the old wzscript can retire and we don't need to maintain it anymore. I disagree with Kevin on this point. We need an automatic converter that can convert all existing scripts. I'll create a branch this weekend, and we'll see how it turns out. - Gerard ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
[Warzone-dev] [patch #908] New sequence code preview
URL: http://gna.org/patch/?908 Summary: New sequence code preview Project: Warzone Resurrection Project Submitted by: gerard_ Submitted on: Wednesday 12/26/2007 at 11:42 Category: Feature Priority: 5 - Normal Status: In Progress Privacy: Public Assigned to: gerard_ Originator Email: Open/Closed: Open Discussion Lock: Any ___ Details: Work in progess! data/test.lua is the script for the movie. ___ File Attachments: --- Date: Wednesday 12/26/2007 at 11:42 Name: newseq.patch Size: 511kB By: gerard_ http://gna.org/patch/download.php?file_id=3457 ___ Reply to this item at: http://gna.org/patch/?908 ___ Message sent via/by Gna! http://gna.org/ ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
[Warzone-dev] Replacing the scripting language?
Hi everybody, You all know we are in the possession of our very own scripting language. From time to time the question has been raised if we'd want to replace the home grown language with something more standard. The advantages would be: * We don't need to maintain the old scripting language anymore * We would gain extra flexibility in the scripts The main disadvantage is however that we would need to convert all existing scripts to the new format. I believe this is possible using a modified version of the script parser that is used in Warzone. For the new scripting language to use the only competition was between Lua and Python. I am fan of Python as a language, but the ease of which Lua can be embedded amazed me. If we are going to switch I'd definitely recommend Lua. I'm currently writing a new sequence system using Lua, and I'm really pleased by the ease of working with Lua the C API. Please tell me what you think about switching to Lua as our scripting language. Regards, Gerard ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Stomping the new netcode into WZ
My experience is that just committing something to trunk is the easiest and quickest way to test changes. Why not commit the entire patch this weekeind and have every developer run the game in a debugger and play a few games? I suppose we can catch all bugs in a few hours then. We can always revert if it does not work out. - Gerard Van: [EMAIL PROTECTED] namens Per Inge Mathisen Verzonden: di 18-12-2007 11:46 Aan: Development list Onderwerp: Re: [Warzone-dev] Stomping the new netcode into WZ On 12/18/07, Dennis Schridde [EMAIL PROTECTED] wrote: Ok... This seems to be a very actively discussed topic, which is interesting to lots of people it seems... [/irony] Perhaps it was a mistake to make a separate branch for it, and we should instead commit it piece by piece into trunk? Then let people have a few days of pain^H^H^Hdiligent testing for each piece? - Per ___ 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] BSPIMD and PIETOOL
The BSP's are not used anywhere in the actual rendering code, so any change in fps should be impossible. The PIETOOL defines can be dropped. - Gerard -Original Message- From: [EMAIL PROTECTED] on behalf of Per Inge Mathisen Sent: Mon 23-4-2007 20:08 To: Development list Subject: [Warzone-dev] BSPIMD and PIETOOL I would like to dump support for the BSP part of IMDs. It was introduced to speed up Warzone on the PSX, as far as I can tell, and it does nothing to speed things up on my box. Try it yourself by commenting out the #define BSPIMD line in lib/ivis_common/ivisdef.h header. By removing it, we can simplify the PIE format, and work towards the goal of making it more easy to use with 3D hardware acceleration. I would also like to dump the PIETOOL defines. I think this was only used by the pie tools, whose primary function was, as far as I can tell, to generate the BSP tables for PIE files. Any objections? - Per ___ 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] [Warzone-commits] r1164 -/trunk/lib/ivis_opengl/screen.c
This is interesting, in C++ mode MSVC seems to be almost C99 compatible: http://groups.google.nl/group/comp.lang.c/browse_thread/thread/dbb0628227294c59/231a8816e8e87e3e Could someone test this? - Gerard -Original Message- From: [EMAIL PROTECTED] on behalf of Per Inge Mathisen Sent: Mon 23-4-2007 21:57 To: Development list Subject: Re: [Warzone-dev] [Warzone-commits] r1164 -/trunk/lib/ivis_opengl/screen.c In 4/23/07, Giel van Schijndel [EMAIL PROTECTED] wrote: Well a very good reason: readability and ease of maintenance. Ease of maintenance also means making it easy for people to use tools they are used to. For good or bad (as you see it), MSVC is in active use, and so should not be broken by patches. - Per ___ 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] [Warzone-commits] r1032 - in /trunk: lib/framework/ lib/netplay/ lib/sound/ src/
Giel van Schijndel wrote: Gerard Krol schreef: Author: gerard_ Date: Sat Apr 7 15:23:14 2007 New Revision: 1032 ... 4. Commented out some unused sound code. I just love Valgrind :) There's no need to comment out code, in fact it probably is better to simply remove it. If we or anyone ever need that code back, then Subversion can retrieve it. Reverse difference merging of a revision can do it for example: `svn merge -r500:499` will reverse all changes made in revision 500 and apply them to your local working copy. So as long as you make a note of what it is you removed in your commit log it should be fine. Cluttering the codebase with commented out code probably is worse than ever needing to track down a revision in which some part of code was removed. Fine, I'll remove it then. Plus your way of commenting out code (#if 0;#endif) isn't very easy to spot and recognize as disabled code. This is the recommended way to comment out code though. /* */ don't properly nest. - Gerard ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] [Fwd: Compilation error at generated resource_parser.tab.h]
Kamaze wrote: Original-Nachricht From: - Mon Apr 09 13:31:27 2007 Date: Sun, 8 Apr 2007 21:50:33 -0300 From: Alejandro Pulver [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Compilation error at generated resource_parser.tab.h Mime-Version: 1.0 Content-Type: multipart/signed; boundary=Sig_fuYRTC9U2JBLiKWwDVejF=n; protocol=application/pgp-signature; micalg=PGP-SHA1 Hello. I maintain the FreeBSD port (it's like a Gentoo .ebuild) of Warzone 2100, and when I was updating it to the 2.0.6 version I got an error. The configure/make output and generated resource_parser.tab.h are attached. If you need more information I will provide it. Do you know how to solve this? You need to use a more recent version of Bison. It seems that at least version 2 is needed. Double check that you are invoking the correct version of Bison. Take a look at: http://wz2100.net/wiki/development:compile_guide_freebsd - Gerard ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Video support
Constantine Pokrovsky wrote: Hi. I have reversed the video decompressor. Please, give me some information how to implement the rendering mechanism in the best way. I suppose you mean the decoder for the RPL format? That's quite an achievement, but I'm afraid that does not help us in any way. The original video's were not released under the GPL, and we will thus not be adding any support for them. This does not mean we will do entirely without FMV's however, as I am working on a new sequence system that already supports OGG/Theora. This will however only be used to play free (as in freedom) movies. For more information about the FMV's I suggest to take a look at this forum thread: http://wz2100.net/forum/index.php?topic=458.0 - Gerard ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] rev 970 breaks at end of mission 1 (crash)
I had this too, but not anymore with the old memory system ripped out. Could you try current svn trunk and see if the crash still occurs? - Gerard The Watermelon wrote: On 4/2/07, [EMAIL PROTECTED] mailto:[EMAIL PROTECTED]* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: On Mon, 02 Apr 2007 04:26:39 -0400 The Watermelon [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: this problem usually happens when objects are incompatible with each other,try doing a cleanup and full-recompile and see if this cures the problem.It might be a bug if cleanup and full-recompile dont fix it... Did a clean, then recompile, same thing. Warzone2100-Dbg.exe!memBlockCmp(void * key1=0x0013ede4, void * key2=0x0013) Line 143 + 0x3 bytes C Warzone2100-Dbg.exe!treapFindRec(_treap_node * psRoot=0x0343a468, void * key=0x0013ede4, int (void *, void *)* cmp=0x0054a579) Line 314 + 0xf bytes C Warzone2100-Dbg.exe!blkPointerValid(_block_heap * psHeap=0x01659750, void * pData=0x031307ec, int size=872) Line 587 + 0x15 bytesC Warzone2100-Dbg.exe!blkPointerValidAll(void * pData=0x031307ec, int size=872) Line 612 + 0x11 bytesC Warzone2100-Dbg.exe!memPointerValid(void * pPtr=0x031307ec, unsigned int size=872) Line 385 + 0xd bytesC Warzone2100-Dbg.exe!droidUnderRepair(_droid * psDroid=0x031307ec) Line 5943 + 0xe bytes C Warzone2100-Dbg.exe!drawDroidSelections() Line 3636 + 0x35 bytes C Warzone2100-Dbg.exe!draw3DScene () Line 416 C Warzone2100-Dbg.exe!displayWorld() Line 1628 C Warzone2100-Dbg.exe!addIntelScreen() Line 6904 C Warzone2100-Dbg.exe!displayImmediateMessage(_message * psMessage=0x083dfb60) Line 2143C Warzone2100-Dbg.exe!scrAddMessage() Line 1380 + 0x9 bytes C Warzone2100-Dbg.exe!interpRunScript(_script_context * psContext=0x031ad250, _interp_runtype runType=IRT_EVENT, unsigned int index=3, unsigned int offset=0) Line 780 + 0x8 bytes C Warzone2100-Dbg.exe!eventFireCallbackTrigger(_trigger_type callback=TR_CALLBACKSTART) Line 1077 + 0x1e bytes C Warzone2100-Dbg.exe!stageThreeInitialise() Line 1839 + 0x7 bytes C Warzone2100-Dbg.exe!levLoadData(char * pName=0x00e21180, char * pSaveName=0x, int saveType=0) Line 1137 + 0x5 bytesC Warzone2100-Dbg.exe!SDL_main(int argc=2, char * * argv=0x0013fdb8) Line 577 + 0xe bytes C Warzone2100-Dbg.exe!_main() + 0xd1 bytes C [EMAIL PROTECTED]() + 0x1ed bytesC Warzone2100-Dbg.exe!__tmainCRTStartup() Line 589 + 0x35 bytes C Warzone2100-Dbg.exe!WinMainCRTStartup () Line 414 C kernel32.dll!7c816fd7() [Frames below may be incorrect and/or missing, no symbols loaded for kernel32.dll] weird,does it crash at the start of the game or after loading a save?seems the callstack is pointing to droid selection event function ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] patch 835 is not right?
[EMAIL PROTECTED] wrote:
The patch in 835 which is (i think),
pimemode.c:void pie_ScreenFlip(CLEAR_MODE clearMode)
if (screen_GetBackDrop()) { screen_Upload(NULL);}
Is wrong.
I don't hope so, that was my first commit ;)
This breaks shadows backdrops. You can tell instant at CAM_3A.
Breaks shadows? That would be most unlikely. I noticed that the
transporters shadows were not exactly right (they do not reach all the
way to the ground at first), but that was already so in 834.
What backdrops are broken? Could you post a screenshot?
Note: I tested this using --game CAM_3A
I can not check if loop.c is wrong, GNA is too busy and can not do
diff!
:(
I'm having no problems with GNA here, but maybe they are already over.
The only modifications in loop.c are in the videoloop, so they should
have no effect on other parts of the game. (sadly, with the current code
this is not always the case)
- Gerard
___
Warzone-dev mailing list
Warzone-dev@gna.org
https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] [Fwd: warzone2100-2.0.5 fails to compile on Gentoo/amd64]
Kamaze wrote: Original-Nachricht Betreff: warzone2100-2.0.5 fails to compile on Gentoo/amd64 Datum: Mon, 26 Feb 2007 00:34:24 +0300 Von: Dmitrij Czarkoff [EMAIL PROTECTED] An: [EMAIL PROTECTED] Tried to compile warzone2100 on my amd64 machine (both via portage and manually). After autogen.sh and configure run OK it fails to make. See the log (make -dk --warn-undefined-variables ../warzone2100.log) attached. About my computer: CPU: Turion64 MT28 Chipset: ATi RX480M + ATi SB400 RAM: 1Gb (I don't know vendor, but no bugs were discovered) OS: Gentoo I've got all the demands (as listed in COMPILE instruction) met. As You don't name the versions of software needed, I'm reporting mines (output of emerge -pv): [ebuild R ] sys-devel/autoconf-2.61 USE=-emacs 0 kB [ebuild R ] sys-devel/gcc-4.1.2 USE=gtk nls (-altivec) -bootstrap -build -doc -fortran -gcj (-hardened) -ip28 -ip32r10k -mudflap (-multilib) -multislot (-n32) (-n64) -nocxx -objc -objc++ -objc-gc -test -vanilla 0 kB [ebuild R ] sys-devel/make-3.81 USE=nls -static 0 kB [ebuild R ] media-libs/libsdl-1.2.11-r1 USE=X aalib alsa opengl xv -arts -dga -directfb -esd -fbcon -ggi -libcaca -nas -noaudio -noflagstrip -nojoystick -novideo -oss (-svga) -xinerama 0 kB [ebuild R ] media-libs/sdl-net-1.2.6 0 kB [ebuild R ] media-libs/libvorbis-1.1.2 USE=-aotuv 0 kB [ebuild R ] media-libs/libmad-0.15.1b-r2 USE=-debug 0 kB [ebuild R ] sys-libs/zlib-1.2.3-r1 USE=-build 0 kB [ebuild R ] dev-games/physfs-1.0.1 0 kB [ebuild R ] media-libs/openal-0.0.8-r1 USE=alsa mp3 sdl vorbis -arts -debug -esd 0 kB [ebuild R ] media-libs/libpng-1.2.16 USE=-doc 0 kB [ebuild R ] media-libs/jpeg-6b-r8 0 kB What could be the problem here? Your link command line: gcc -g -O2 -DNDEBUG -I/usr/include/SDL -D_GNU_SOURCE=1 -D_REENTRANT -I/usr/X11R6/include/SDL -m32 -DYY_STATIC -DDEFAULT_DATADIR=\/usr/local/share/warzone2100\ Notice the -m32? You are compiling warzone to a 32 bit executable. Now look at this: /usr/lib/gcc/x86_64-pc-linux-gnu/4.1.2/../../../../x86_64-pc-linux-gnu/bin/ld: skipping incompatible /usr/X11R6/lib/libphysfs.so when searching for -lphysfs /usr/lib/gcc/x86_64-pc-linux-gnu/4.1.2/../../../../x86_64-pc-linux-gnu/bin/ld: skipping incompatible /usr/X11R6/lib/libphysfs.a when searching for -lphysfs /usr/lib/gcc/x86_64-pc-linux-gnu/4.1.2/../../../../x86_64-pc-linux-gnu/bin/ld: skipping incompatible /usr/lib/gcc/x86_64-pc-linux-gnu/4.1.2/../../../libphysfs.so when searching for -lphysfs /usr/lib/gcc/x86_64-pc-linux-gnu/4.1.2/../../../../x86_64-pc-linux-gnu/bin/ld: skipping incompatible /usr/lib/gcc/x86_64-pc-linux-gnu/4.1.2/../../../libphysfs.a when searching for -lphysfs /usr/lib/gcc/x86_64-pc-linux-gnu/4.1.2/../../../../x86_64-pc-linux-gnu/bin/ld: skipping incompatible /usr/lib/libphysfs.so when searching for -lphysfs /usr/lib/gcc/x86_64-pc-linux-gnu/4.1.2/../../../../x86_64-pc-linux-gnu/bin/ld: skipping incompatible /usr/lib/libphysfs.a when searching for -lphysfs /usr/lib/gcc/x86_64-pc-linux-gnu/4.1.2/../../../../x86_64-pc-linux-gnu/bin/ld: cannot find -lphysfs You seem to have the 64 bit lib of physfs. I suggest you just compile warzone for 64 bit (so without the -m32), works fine for me (amd64, Debian). - Gerard ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
RE: [Warzone-dev] Evaluate AngelScript as an alternative to lua?
I'd say we'd better use a more mature alternative, as Lua or Python. A little comparison: Anglescript, call script function from C: http://www.angelcode.com/angelscript/sdk/docs/manual/pages/man_callscriptfunc.html Anglescript, call C function from script: no clear example found Python, call script function from C: http://docs.python.org/ext/pure-embedding.html Needs quite some code. (but the example is quite complete) Python, call C function from script: http://docs.python.org/ext/extending-with-embedding.html Really easy Lua, call script function from C: http://www.lua.org/manual/2.1/subsection3_7_6.html Clear Lua, call C function from script: http://www.lua.org/pil/26.1.html Clear Please judge for yourself, but Python has my preference, as I have quite a lot of experience with the language. - Gerard -Original Message- From: [EMAIL PROTECTED] on behalf of Kamaze Sent: Wed 21-2-2007 0:11 To: Development list Subject: [Warzone-dev] Evaluate AngelScript as an alternative to lua? Website: http://www.angelcode.com/angelscript/ Infos: http://www.angelcode.com/angelscript/features.asp I read a bit about it and played a bit around with it. It looks clean, fast, small and stable. And has a c/c++ syntax. Binding of functions and vars seems to be very easy. Maybe you/we should make a closer look to it :) - Kamaze ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev winmail.dat___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
[Warzone-dev] Re: [Warzone-commits] r792 - in /trunk: lib/sound/track.c lib/sound/track.h src/data.c
Giel van Schijndel wrote:
Author: muggenhor
Date: Mon Feb 19 22:52:27 2007
New Revision: 792
URL: http://svn.gna.org/viewcvs/warzone?rev=792view=rev
Log:
* removed some redundant code from src/data.c:
- the function dataAudioLoad first checked whether the audio system is
disabled and if it is sets return buffer (*ppData) to NULL, even though this
functionality is already performed by the function it calls
(audio_LoadTrackFromBuffer)
Well, you made a little mistake there. The function is supposed to
return FALSE ONLY when an error occurs. Returning FALSE causes for me:
error: resLoad: failed to parse wrf/frontend.wrf
error: Shutting down after failure
And you also made it return FALSE when sound is disabled. The attached
patch corrects this, and also removes the redundant function
audio_LoadTrackFromBuffer which was only a very thin wrapper for
sound_LoadTrackFromBuffer. The check if sound is enabled is again in
dataAudioLoad.
- Gerard
Index: src/data.c
===
--- src/data.c (revision 792)
+++ src/data.c (working copy)
@@ -989,13 +989,16 @@
/* Load an audio file */
BOOL dataAudioLoad(char *pBuffer, UDWORD size, void **ppData)
{
- // If audio is disabled or a track can't be constructed the return value will be NULL
- *ppData = audio_LoadTrackFromBuffer( pBuffer, size );
+ if ( audio_Disabled() == TRUE )
+ {
+ *ppData = NULL;
+ // No error occurred (sound is just disabled), so we return TRUE
+ return TRUE;
+ }
+// Load the track from a file
+ *ppData = sound_LoadTrackFromBuffer( pBuffer, size );
- if (*ppData == NULL)
- return FALSE;
-
- return TRUE;
+ return *ppData != NULL;
}
void dataAudioRelease( void *pData )
Index: lib/sound/audio.c
===
--- lib/sound/audio.c (revision 792)
+++ lib/sound/audio.c (working copy)
@@ -614,23 +614,8 @@
}
//*
-// ===
-// ===
//
-TRACK *audio_LoadTrackFromBuffer(char *pBuffer, UDWORD udwSize)
-{
- // if audio not enabled return TRUE to carry on game without audio
- if ( g_bAudioEnabled == FALSE )
- {
- return NULL;
- }
- return sound_LoadTrackFromBuffer( pBuffer, udwSize );
-}
-
-//*
-//
-
// Routine to convert wav filename into a track number
// ... This is really not going to be practical on the PSX is it?
//
Index: lib/sound/audio.h
===
--- lib/sound/audio.h (revision 792)
+++ lib/sound/audio.h (working copy)
@@ -36,7 +36,6 @@
extern BOOL audio_Disabled( void );
extern BOOL audio_LoadTrackFromFile( char szFileName[] );
-extern TRACK * audio_LoadTrackFromBuffer(char *pBuffer, UDWORD udwSize);
extern BOOL audio_SetTrackVals( char szFileName[], BOOL bLoop, int *piID,
int iVol, int iPriority, int iAudibleRadius );
extern BOOL audio_SetTrackValsHashName( UDWORD hash, BOOL bLoop, int iTrack, int iVol,
___
Warzone-dev mailing list
Warzone-dev@gna.org
https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Patch: removal of duplicate code
Per Inge Mathisen wrote: On 2/17/07, Gerard Krol [EMAIL PROTECTED] wrote: I went duplicate code hunting, and fixed these occurrences of copypaste. There are quite some more, but I leave those for another time. I have been working on this, and committed parts of it, but it is a real pain to check it for correctness. Yeah, it is. Struggled with that myself too. I see that the two functions merged in src/display3d.c have differences, though, where one function used buildingBrightness and another brightness, which are calculated differently, while in the merged function, buildingBrightness only is used. Calculated differently? I just took another look at the code, and this does not seem to be the case. The value buildingBrightness is just abandoned at some point, and brightness is used. It would be nice to know if such changes are intentional or not. In principle the code should behave exactly as before. The only change I remember is that some value that has something to do with the muzzle flash that was different for the normal buildings and the defensive buildings. I supposed the value on the defensive buildings was updated at some time, and the value for the normal buildings was forgotten, so I made both normal and defensive buildings use the muzzle flash parameter from the defensive buildings. - Gerard ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Patch: Nicer water
Dennis Schridde wrote: Am Samstag, 17. Februar 2007 schrieb Gerard Krol: By tweaking 2 lines the water really improves a lot! 4p-Sk-FishNets is a good map to test. - Gerard I applied it in my local copy... Nice in general, but the alpha change should be done to the texture and not in the code, IMO... Eg. Grim's textures have a good alpha setting for water, which makes them look ugly with these changes... I agree that doing the alpha in the textures is better, much more flexibility that way. Maybe you could only apply the second change? That improves the riverbeds alot in my opinion. The alpha in the texture pages can then come some later time. By the way, why aren't grims textures in svn? I might want to improve on some textures too, and it would nice to be able to continue from his work. - Gerard ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
[Warzone-dev] Patch: Nicer water
By tweaking 2 lines the water really improves a lot!
4p-Sk-FishNets is a good map to test.
- Gerard
Index: src/display3d.c
===
--- src/display3d.c (revision 774)
+++ src/display3d.c (working copy)
@@ -120,10 +120,10 @@
#define WATER_TILE 17 // ID of water tile.
#define BED_TILE 5// ID of river bed tile.
-#define WATER_ALPHA_LEVEL 255 //was 164 // Amount to alpha blend water.
+#define WATER_ALPHA_LEVEL 164 // Amount to alpha blend water.
#define WATER_ZOFFSET 32 // Sorting offset for main water tile.
#define WATER_EDGE_ZOFFSET 64 // Sorting offset for water edge tiles.
-#define WATER_DEPTH 127 // Amount to push terrain below water.
+#define WATER_DEPTH 60 // Amount to push terrain below water.
/ Prototypes /
// TODO: Declare as many static as possible.
@@ -891,7 +891,7 @@
{
// Push the terrain down for the river bed.
PushedDown = TRUE;
- shiftVal = WATER_DEPTH + ((3*environGetData(playerXTile+j,playerZTile+i))/2);
+ shiftVal = WATER_DEPTH + ((environGetData(playerXTile+j,playerZTile+i))/4);
altVal = 0;//environGetValue(playerXTile+j,playerZTile+i);
tileScreenInfo[i][j].y -= (shiftVal+altVal);
// And darken it.
___
Warzone-dev mailing list
Warzone-dev@gna.org
https://mail.gna.org/listinfo/warzone-dev
[Warzone-dev] Patch: removal of duplicate code
Hi, I went duplicate code hunting, and fixed these occurrences of copypaste. There are quite some more, but I leave those for another time. - Gerard PS. Patches pending commit: fog.patch (2007-2-10) duplicates.patch.gz Description: GNU Zip compressed data ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
[Warzone-dev] Patch: (well sort of) tertiles texture pages
Hi, The data/texpages/tertiles* texture pages were messed up because someone just enlarged the whole image. This caused tiles to bleed into adjacent ones. I retrieved the original files from the Berlios repository and scaled those tile by tile using a self written Python script. If any other texturepages need resizing I can do those easily as well. The new texpages can be found at http://www.uploadtemple.com/view.php/1171751085.gz (8.7 MB) Regards, Gerard ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Please apply this patch
Giel van Schijndel wrote:
Giel van Schijndel schreef:
Gerard Krol schreef:
I know I only posted it only 4 days ago, but I really sleep better
when I know my patches have been applied. Could someone apply this
patch? I even polished it a little bit more.
This patch prevents a segfault when designing a droid on amd64.
Reproduce: on amd64, go to the droid design screen and design a
construction droid. Then hover your mouse over another system, like
sensor or command.
Regards,
Gerard
Applied in r750.
Hope you did sleep well enough those 4 days? Anyway I'm hoping you'll
sleep better now again ;-) .
Sorry, I haven't looked at your latest patch until after committing the
previous one.
Anyway your latest version looks a bit ugly to me. There's an awfully
large amount of casts in there, not to mention that your insertion of
that switch statement uses the variable `type` which at that point isn't
yet initialized = undefined behaviour.
Oops, I guess that must be a copy-paste error.
Plus I'm not quite sure what the difference is between the first and
second patch. Not meaning to offend you though.
I just noticed that my patch created a lot of warnings (16) about
'warning: initialization from incompatible pointer type'. The second
patch was a quick attempt to solve that problem. A little too quick as
it seems.
I tought about it a little and the attached patch avoids the casting
problem and also doesn't give the warnings.
- Gerard
Index: src/design.c
===
--- src/design.c (revision 762)
+++ src/design.c (working copy)
@@ -3615,14 +3615,14 @@
UDWORDpower, i;
if (psStats != NULL) {
-COMP_BASE_STATS* bodyStats = asBodyStats + sCurrDesign.asParts[COMP_BODY];
-COMP_BASE_STATS* brainStats = asBrainStats + sCurrDesign.asParts[COMP_BRAIN];
-COMP_BASE_STATS* sensorStats = asSensorStats + sCurrDesign.asParts[COMP_SENSOR];
-COMP_BASE_STATS* ECMStats = asECMStats + sCurrDesign.asParts[COMP_ECM];
-COMP_BASE_STATS* repairStats = asRepairStats + sCurrDesign.asParts[COMP_REPAIRUNIT];
-COMP_BASE_STATS* constructStats = asConstructStats + sCurrDesign.asParts[COMP_CONSTRUCT];
-COMP_BASE_STATS* propulsionStats = asPropulsionStats + sCurrDesign.asParts[COMP_PROPULSION];
-COMP_BASE_STATS* weaponStats = asWeaponStats + sCurrDesign.asWeaps[0];
+UDWORD bodyPower= (asBodyStats + sCurrDesign.asParts[COMP_BODY])-buildPower;
+UDWORD brainPower = (asBrainStats + sCurrDesign.asParts[COMP_BRAIN])-buildPower;
+UDWORD sensorPower = (asSensorStats + sCurrDesign.asParts[COMP_SENSOR])-buildPower;
+UDWORD ECMPower = (asECMStats + sCurrDesign.asParts[COMP_ECM])-buildPower;
+UDWORD repairPower = (asRepairStats + sCurrDesign.asParts[COMP_REPAIRUNIT])-buildPower;
+UDWORD constructPower = (asConstructStats + sCurrDesign.asParts[COMP_CONSTRUCT])-buildPower;
+UDWORD propulsionPower = (asPropulsionStats + sCurrDesign.asParts[COMP_PROPULSION])-buildPower;
+UDWORD weaponPower = (asWeaponStats + sCurrDesign.asWeaps[0])-buildPower;
type = statType(psStats-ref);
@@ -3662,25 +3662,25 @@
switch (type)
{
case COMP_BODY:
- bodyStats = psStats;
+ bodyPower = psStats-buildPower;
break;
case COMP_PROPULSION:
- propulsionStats = psStats;
+ propulsionPower = psStats-buildPower;
break;
case COMP_ECM:
- ECMStats = psStats;
+ ECMPower = psStats-buildPower;
break;
case COMP_SENSOR:
- sensorStats = psStats;
+ sensorPower = psStats-buildPower;
break;
case COMP_CONSTRUCT:
- constructStats = psStats;
+ constructPower = psStats-buildPower;
break;
case COMP_REPAIRUNIT:
- repairStats = psStats;
+ repairPower = psStats-buildPower;
break;
case COMP_WEAPON:
- weaponStats = psStats;
+ weaponPower = psStats-buildPower;
break;
//default:
//don't want to draw for unknown comp
@@ -3689,15 +3689,15 @@
// this code is from calcTemplatePower
//get the component power
- power = bodyStats-buildPower + brainStats-buildPower + sensorStats-buildPower + ECMStats-buildPower + repairStats-buildPower + constructStats-buildPower;
+ power = bodyPower + brainPower + sensorPower + ECMPower + repairPower + constructPower;
/* propulsion power points are a percentage of the bodys' power points */
- power += (propulsionStats-buildPower *
- bodyStats-buildPower) / 100;
+ power += (propulsionPower *
+ bodyPower) / 100;
//add weapon power
// FIXME: Only takes first weapon into account
-power += weaponStats-buildPower;
+power += weaponPower;
for(i=1; isCurrDesign.numWeaps; i++)
{
power += (asWeaponStats + sCurrDesign.asWeaps[i])-buildPower;
@@ -3727,14 +3727,14 @@
UDWORDbody, i;
if (psStats != NULL
[Warzone-dev] Please apply this patch
I know I only posted it only 4 days ago, but I really sleep better when
I know my patches have been applied. Could someone apply this patch? I
even polished it a little bit more.
This patch prevents a segfault when designing a droid on amd64.
Reproduce: on amd64, go to the droid design screen and design a
construction droid. Then hover your mouse over another system, like
sensor or command.
Regards,
Gerard
Index: src/design.c
===
--- src/design.c (revision 747)
+++ src/design.c (working copy)
@@ -3612,13 +3612,43 @@
static void intSetTemplatePowerShadowStats(COMP_BASE_STATS *psStats)
{
UDWORDtype;
- //SDWORDAvail, Used, Total;
- DROID_TEMPLATE compTempl;
- if (sCurrDesign != NULL psStats != NULL)
- {
- //create the comparison Template
- memcpy(compTempl, sCurrDesign, sizeof(DROID_TEMPLATE));
+ if (psStats != NULL) {
+BODY_STATS* bodyStats = asBodyStats + sCurrDesign.asParts[COMP_BODY];
+BRAIN_STATS* brainStats = asBrainStats + sCurrDesign.asParts[COMP_BRAIN];
+SENSOR_STATS* sensorStats = asSensorStats + sCurrDesign.asParts[COMP_SENSOR];
+ECM_STATS* ECMStats = asECMStats + sCurrDesign.asParts[COMP_ECM];
+REPAIR_STATS* repairStats = asRepairStats + sCurrDesign.asParts[COMP_REPAIRUNIT];
+CONSTRUCT_STATS* constructStats = asConstructStats + sCurrDesign.asParts[COMP_CONSTRUCT];
+PROPULSION_STATS* propulsionStats = asPropulsionStats + sCurrDesign.asParts[COMP_PROPULSION];
+WEAPON_STATS* weaponStats = asWeaponStats + sCurrDesign.asWeaps[0];
+ switch (type)
+ {
+ case COMP_BODY:
+ bodyStats = (BODY_STATS*)psStats;
+ break;
+ case COMP_PROPULSION:
+ propulsionStats = (PROPULSION_STATS*)psStats;
+ break;
+ case COMP_ECM:
+ ECMStats = (ECM_STATS*)psStats;
+ break;
+ case COMP_SENSOR:
+ sensorStats = (SENSOR_STATS*)psStats;
+ break;
+ case COMP_CONSTRUCT:
+ constructStats = (CONSTRUCT_STATS*)psStats;
+ break;
+ case COMP_REPAIRUNIT:
+ repairStats = (REPAIR_STATS*)psStats;
+ break;
+ case COMP_WEAPON:
+ weaponStats = (WEAPON_STATS*)psStats;
+ break;
+ //default:
+ //don't want to draw for unknown comp
+ }
+
type = statType(psStats-ref);
/*if type = BODY or PROPULSION can do a straight comparison but if the new stat is
a 'system' stat then need to find out which 'system' is currently in place so the
@@ -3648,43 +3678,56 @@
}
else
{
-type = COMP_UNKNOWN;
+ // compare it with the current weapon
+type = COMP_WEAPON;
}
}
switch (type)
{
case COMP_BODY:
- compTempl.asParts[COMP_BODY] = (BODY_STATS *)psStats - asBodyStats;
+ bodyStats = (BODY_STATS*)psStats;
break;
case COMP_PROPULSION:
- compTempl.asParts[COMP_PROPULSION] = (PROPULSION_STATS *)psStats -
-asPropulsionStats;
+ propulsionStats = (PROPULSION_STATS*)psStats;
break;
case COMP_ECM:
- compTempl.asParts[COMP_ECM] = (ECM_STATS *)psStats - asECMStats;
+ ECMStats = (ECM_STATS*)psStats;
break;
case COMP_SENSOR:
- compTempl.asParts[COMP_SENSOR] = (SENSOR_STATS *)psStats -
-asSensorStats;
+ sensorStats = (SENSOR_STATS*)psStats;
break;
case COMP_CONSTRUCT:
- compTempl.asParts[COMP_CONSTRUCT] = (CONSTRUCT_STATS *)psStats -
-asConstructStats;
+ constructStats = (CONSTRUCT_STATS*)psStats;
break;
case COMP_REPAIRUNIT:
- compTempl.asParts[COMP_REPAIRUNIT] = (REPAIR_STATS *)psStats -
-asRepairStats;
+ repairStats = (REPAIR_STATS*)psStats;
break;
case COMP_WEAPON:
- compTempl.asWeaps[0] = (WEAPON_STATS *)psStats - asWeaponStats;
+ weaponStats = (WEAPON_STATS*)psStats;
break;
//default:
//don't want to draw for unknown comp
}
+ // this code is from calcTemplatePower
+ UDWORD power, i;
- widgSetMinorBarSize( psWScreen, IDDES_POWERBAR,
-calcTemplatePower(compTempl));
+ //get the component power
+ power = bodyStats-buildPower + brainStats-buildPower + sensorStats-buildPower + ECMStats-buildPower + repairStats-buildPower + constructStats-buildPower;
+
+ /* propulsion power points are a percentage of the bodys' power points */
+ power += (propulsionStats-buildPower *
+ bodyStats-buildPower) / 100;
+
+ //add weapon power
+// FIXME: Only takes first weapon into account
+power += weaponStats-buildPower;
+ for(i=1; isCurrDesign.numWeaps; i++)
+ {
+ power += (asWeaponStats + sCurrDesign.asWeaps[i])-buildPower;
+ }
+ widgSetMinorBarSize( psWScreen, IDDES_POWERBAR,
+power);
}
else
{
@@ -3705,12 +3748,18 @@
static void intSetTemplateBodyShadowStats(COMP_BASE_STATS *psStats)
{
UDWORDtype;
- DROID_TEMPLATE compTempl;
- if (sCurrDesign != NULL psStats != NULL)
- {
- //create the comparison Template
- memcpy(compTempl, sCurrDesign, sizeof(DROID_TEMPLATE));
+ if (psStats != NULL) {
+BODY_STATS* bodyStats = asBodyStats +
Re: [Warzone-dev] Patch: Severe pointer abuse in design.c (Finally a x86_64 bug! )
The Watermelon wrote: On 2/10/07, *Gerard Krol* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Hi all, As some of you may know, power required and hit points of droid parts are stored in central arrays. Individual body types are an index into this array and are used like this: (asBodyStats + psTemplate-asParts[COMP_BODY])-buildPower The code in intSetTemplatePowerShadowStats and intSetTemplateBodyShadowStats did store a pointer in this index by using the difference with the asBodyStats address, so that after this addition the correct address would magically reappear. Guilty code looks like this: compTempl.asParts[COMP_BODY] = (BODY_STATS *)psStats - asBodyStats; Funny thing is: on 64bit: sizeof(SDWORD) sizeof(void*) In the attached patch, the calls to calcTemplatePower and calcTemplateBody were removed, and the (simple) formula's used for calculation were directly included in the two modified functions. - Gerard I think that kind of stuff is everywhere in the source,at least I saw multiple instances of 'weapId = psStats - asWeaponStats' or 'psStats = asWeaponStats + weaponId'. In most of the case psStats points to an member of the array asWeaponStats. In that case weaponId is a small integer (0 to about a max of 40) and the code is correct. The bug is by the way exposed if you design a new droid, put a system on it (sensor for example) and then hover your mouse over another system (like the construction unit). The game then segfaults. - Gerard ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
[Warzone-dev] Patch: Fog of War / Mist
Fog of War seems to be broken in that it renders a foggy sky instead
of a black background. Fixed that.
- Gerard
Index: src/loop.c
===
--- src/loop.c (revision 726)
+++ src/loop.c (working copy)
@@ -183,8 +183,9 @@
#endif
//JPS 24 feb???
- if (fogStatus FOG_BACKGROUND)
+ if (war_GetFog())
{
+// Mist
clearMode = CLEAR_FOG;//screen clear to fog colour D3D
if (loopMissionState == LMS_SAVECONTINUE)
{
@@ -194,6 +195,7 @@
}
else
{
+// Fog of War
clearMode = CLEAR_BLACK;//force to black 3DFX
}
pie_ScreenFlip(clearMode);//gameloopflip
Index: src/multiint.c
===
--- src/multiint.c (revision 726)
+++ src/multiint.c (working copy)
@@ -1989,6 +1989,7 @@
widgSetButtonState(psWScreen, MULTIOP_FOG_ON,WBUT_LOCK);
widgSetButtonState(psWScreen, MULTIOP_FOG_OFF,0);
game.fog = TRUE;
+war_SetFog(FALSE); // FIXME: multiplayer FOG_ON means fog of war active
if(bHosted)
{
sendOptions(0,0);
@@ -1999,6 +2000,7 @@
widgSetButtonState(psWScreen, MULTIOP_FOG_ON,0);
widgSetButtonState(psWScreen, MULTIOP_FOG_OFF,WBUT_LOCK);
game.fog = FALSE;
+war_SetFog(TRUE);
if(bHosted)
{
sendOptions(0,0);
Index: lib/ivis_opengl/piemode.c
===
--- lib/ivis_opengl/piemode.c (revision 726)
+++ lib/ivis_opengl/piemode.c (working copy)
@@ -134,6 +134,10 @@
case CLEAR_OFF_AND_NO_BUFFER_DOWNLOAD:
break;
case CLEAR_BLACK:
+ glDepthMask(GL_TRUE);
+ glClearColor(0.0f,0.0f,0.0f,0.0f);
+ glClear( GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT );
+ break;
default:
glDepthMask(GL_TRUE);
fog_colour.argb = pie_GetFogColour();
___
Warzone-dev mailing list
Warzone-dev@gna.org
https://mail.gna.org/listinfo/warzone-dev
[Warzone-dev] Patch: Severe pointer abuse in design.c (Finally a x86_64 bug! )
Hi all,
As some of you may know, power required and hit points of droid parts
are stored in central arrays. Individual body types are an index into
this array and are used like this:
(asBodyStats + psTemplate-asParts[COMP_BODY])-buildPower
The code in intSetTemplatePowerShadowStats and
intSetTemplateBodyShadowStats did store a pointer in this index by using
the difference with the asBodyStats address, so that after this addition
the correct address would magically reappear. Guilty code looks like this:
compTempl.asParts[COMP_BODY] = (BODY_STATS *)psStats - asBodyStats;
Funny thing is: on 64bit: sizeof(SDWORD) sizeof(void*)
In the attached patch, the calls to calcTemplatePower and
calcTemplateBody were removed, and the (simple) formula's used for
calculation were directly included in the two modified functions.
- Gerard
Index: src/design.c
===
--- src/design.c (revision 731)
+++ src/design.c (working copy)
@@ -3612,13 +3612,18 @@
static void intSetTemplatePowerShadowStats(COMP_BASE_STATS *psStats)
{
UDWORDtype;
- //SDWORDAvail, Used, Total;
- DROID_TEMPLATE compTempl;
- if (sCurrDesign != NULL psStats != NULL)
- {
- //create the comparison Template
- memcpy(compTempl, sCurrDesign, sizeof(DROID_TEMPLATE));
+ if (psStats != NULL) {
+COMP_BASE_STATS* bodyStats = asBodyStats + sCurrDesign.asParts[COMP_BODY];
+COMP_BASE_STATS* brainStats = asBrainStats + sCurrDesign.asParts[COMP_BRAIN];
+COMP_BASE_STATS* sensorStats = asSensorStats + sCurrDesign.asParts[COMP_SENSOR];
+COMP_BASE_STATS* ECMStats = asECMStats + sCurrDesign.asParts[COMP_ECM];
+COMP_BASE_STATS* repairStats = asRepairStats + sCurrDesign.asParts[COMP_REPAIRUNIT];
+COMP_BASE_STATS* constructStats = asConstructStats + sCurrDesign.asParts[COMP_CONSTRUCT];
+COMP_BASE_STATS* propulsionStats = asPropulsionStats + sCurrDesign.asParts[COMP_PROPULSION];
+COMP_BASE_STATS* weaponStats = asWeaponStats + sCurrDesign.asWeaps[0];
+
+
type = statType(psStats-ref);
/*if type = BODY or PROPULSION can do a straight comparison but if the new stat is
a 'system' stat then need to find out which 'system' is currently in place so the
@@ -3648,43 +3653,56 @@
}
else
{
-type = COMP_UNKNOWN;
+ // compare it with the current weapon
+type = COMP_WEAPON;
}
}
switch (type)
{
case COMP_BODY:
- compTempl.asParts[COMP_BODY] = (BODY_STATS *)psStats - asBodyStats;
+ bodyStats = psStats;
break;
case COMP_PROPULSION:
- compTempl.asParts[COMP_PROPULSION] = (PROPULSION_STATS *)psStats -
-asPropulsionStats;
+ propulsionStats = psStats;
break;
case COMP_ECM:
- compTempl.asParts[COMP_ECM] = (ECM_STATS *)psStats - asECMStats;
+ ECMStats = psStats;
break;
case COMP_SENSOR:
- compTempl.asParts[COMP_SENSOR] = (SENSOR_STATS *)psStats -
-asSensorStats;
+ sensorStats = psStats;
break;
case COMP_CONSTRUCT:
- compTempl.asParts[COMP_CONSTRUCT] = (CONSTRUCT_STATS *)psStats -
-asConstructStats;
+ constructStats = psStats;
break;
case COMP_REPAIRUNIT:
- compTempl.asParts[COMP_REPAIRUNIT] = (REPAIR_STATS *)psStats -
-asRepairStats;
+ repairStats = psStats;
break;
case COMP_WEAPON:
- compTempl.asWeaps[0] = (WEAPON_STATS *)psStats - asWeaponStats;
+ weaponStats = psStats;
break;
//default:
//don't want to draw for unknown comp
}
+ // this code is from calcTemplatePower
+ UDWORD power, i;
- widgSetMinorBarSize( psWScreen, IDDES_POWERBAR,
-calcTemplatePower(compTempl));
+ //get the component power
+ power = bodyStats-buildPower + brainStats-buildPower + sensorStats-buildPower + ECMStats-buildPower + repairStats-buildPower + constructStats-buildPower;
+
+ /* propulsion power points are a percentage of the bodys' power points */
+ power += (propulsionStats-buildPower *
+ bodyStats-buildPower) / 100;
+
+ //add weapon power
+// FIXME: Only takes first weapon into account
+power += weaponStats-buildPower;
+ for(i=1; isCurrDesign.numWeaps; i++)
+ {
+ power += (asWeaponStats + sCurrDesign.asWeaps[i])-buildPower;
+ }
+ widgSetMinorBarSize( psWScreen, IDDES_POWERBAR,
+power);
}
else
{
@@ -3705,12 +3723,18 @@
static void intSetTemplateBodyShadowStats(COMP_BASE_STATS *psStats)
{
UDWORDtype;
- DROID_TEMPLATE compTempl;
- if (sCurrDesign != NULL psStats != NULL)
- {
- //create the comparison Template
- memcpy(compTempl, sCurrDesign, sizeof(DROID_TEMPLATE));
+ if (psStats != NULL) {
+COMP_BASE_STATS* bodyStats = asBodyStats + sCurrDesign.asParts[COMP_BODY];
+COMP_BASE_STATS* brainStats = asBrainStats + sCurrDesign.asParts[COMP_BRAIN];
+COMP_BASE_STATS* sensorStats = asSensorStats + sCurrDesign.asParts[COMP_SENSOR];
+COMP_BASE_STATS* ECMStats = asECMStats +
[Warzone-dev] Patch for preventing segfault in skirmish
Hi,
I'm pleased to say that Warzone seems to run fine on AMD64, that is,
after applying the attached patch.
For a return type of bool (integer value 0) the array gets accessed
with a negative index of -11. This just goes unnoticed most of the time
I guess, but I was lucky to experience a segfault.
- Gerard
Index: lib/script/script_lexer.l
===
--- lib/script/script_lexer.l (revision 722)
+++ lib/script/script_lexer.l (working copy)
@@ -257,7 +257,14 @@
BOOL object;
// See if this is an object pointer
- object = asScrTypeTab[psFunc-retType - VAL_USERTYPESTART].accessType == AT_OBJECT;
+ if (!asScrTypeTab || psFunc-retType VAL_USERTYPESTART)
+ {
+ object = FALSE;
+ }
+ else
+ {
+ object = asScrTypeTab[psFunc-retType - VAL_USERTYPESTART].accessType == AT_OBJECT;
+ }
if (object)
{
___
Warzone-dev mailing list
Warzone-dev@gna.org
https://mail.gna.org/listinfo/warzone-dev
RE: [Warzone-dev] Patch for removing the AND and OR macro's
Sorry for using a MS product ;), I will set up thunderbird (icedove) tomorrow... for now, apt-get install tnef? - Gerard -Original Message- From: [EMAIL PROTECTED] on behalf of Giel van Schijndel Sent: Fri 26-1-2007 23:27 To: Development list Subject: Re: [Warzone-dev] Patch for removing the AND and OR macro's Gerard Krol schreef: Hi all, The AND and OR macro's annoyed me, so I decided to remove them in flavor of the native and ||. - Gerard Erm, maybe try another mail client than MS outlook, because all attachments I see is winmail.dat (oulook is known for that kind of stupidity, just google winmail.dat). -- Giel winmail.dat___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
[Warzone-dev] Java applet for IRC
Hi, How about putting a link to http://java.freenode.net/index.php?channel=warzone on the page http://www.wz2100.net/irc-chat.html, or even the applet itself like described at: http://java.freenode.net/howto.php ? Regards, Gerard ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Ari: Still valid? Workaround for MacOS gcc 4.0.0 bug
Ari Johnson wrote:
Yes, the bug is still there.
On 12/8/06, Dennis Schridde [EMAIL PROTECTED] wrote:
Is the bug in this code still present? Or can we remove the tmp int?
lib/ivis_common/bitimage.c:92:
// Load the texture pages.
for (i = 0; i Header-NumTPages; i++) {
int tmp;/* Workaround for MacOS gcc 4.0.0
bug. */
Just rename tmp to pageID. Then there's no problem with leaving it in
(for me, at least).
It's maybe even more readable, and the compiler will optimize it away
anyhow.
- Gerard
___
Warzone-dev mailing list
Warzone-dev@gna.org
https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Automatic dependencies
Dennis Schridde wrote: Am Montag, 13. November 2006 00:04 schrieb Gerard Krol: Dennis Schridde wrote: Am Freitag, 10. November 2006 16:54 schrieb Gerard Krol: Hi, The complete lack of dependencies somewhat bothers me, so I ran (X11) makedepend. Attached are changes for the Makefile.raw's. Now you don't have to run make clean all the time anymore. Could someone with access to automake also incorporate the changes into the Makefile.am's? Is the makedepend exe included in MinGW? Because I rewrote the Makefile.raw s to run with just a plain MinGW installation (without MSys). Would be ugly if we now required a non standard exe for a task like dependency checking... Eh, no, makedepend is part of the linux/cygwin x11-bin package, I ran the cygwin version. And it is not that every user needs to run make depend, it just needs to be done when there are changes to the includes. I believe there are switches to make gcc do the same as makedepend, but a lot slower. But in the Makefile I found .PHONY depend... Would mean that he does depend on every run, or am I wrong? No, .PHONY is a flag that signals make that the targets do not produce a file (such as an .o or .exe), see http://theory.uwinnipeg.ca/gnu/make/make_33.html - Gerard ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Automatic dependencies
Dennis Schridde wrote: Am Montag, 13. November 2006 19:54 schrieb Per Inge Mathisen: Most of the sed code is just magic that I copied from somewhere else, probably http://make.paulandlesley.org/autodep.html which is a must-read. Does that code run always before the %.o: %.c rule is applied to any file? Yes. if we want Makefile.raw to be able to run from within a dos shell (no sed for example). No sed is just the beginning. Does anything of any complexity really run in a DOS shell? I would guess even just make would struggle, with different path delimiters and all that. For those who do not want to run mingw/msys/cygwin, surely just using VS is a better choice. It worked _pretty_ well till now (after I rewrote the Makefile.raws and striped any SHianisms)... I did the last releases with only cmd.exe and a MinGW 3.4.5 installation, without any extras like MSys or CygWin... I don't really know, I'm using MSys AND Cygwin for developement. Anyone just using DOS? - Gerard PS. Why not join irc.freenode.net #warzone? Quite busy there ;) ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
[Warzone-dev] SVN broken
This change:
Revision 450 - (view) (download) (as text) - [select for diffs]
Modified Sat Nov 4 02:11:26 2006 CET (15 hours, 53 minutes ago) by devurandom
File length: 9752 byte(s)
Diff to previous 389
- Droped a lot of (nearly) unused types from lib/framework/types.h
- Remove lots of unused functions (Windows/DDraw related)
- Now store the used bitdepth in the config and thus make it configurable
without having to modify the sourcecode
Contains (this is an excerpt):
--- trunk/src/clparse.c 2006/09/23 14:56:18 389
+++ trunk/src/clparse.c 2006/11/04 01:11:26 450
@@ -250,13 +270,13 @@
else if ( strcasecmp( tokenType, --shadows ) == 0 )
{
// FIXME Should setDrawShadows go into warzoneconfig?
Or how should config values be handled in general? By the system using it? Or
by warzoneconfig? Or by config keys only?
- //setDrawShadows( TRUE );
- setWarzoneKeyNumeric( shadows, TRUE );
+ setDrawShadows( TRUE );
+// setWarzoneKeyNumeric( shadows, TRUE );
}
else if ( strcasecmp( tokenType, --noshadows ) == 0 )
{
- //setDrawShadows( FALSE );
- setWarzoneKeyNumeric( shadows, FALSE );
+ setDrawShadows( FALSE );
+// setWarzoneKeyNumeric( shadows, FALSE );
}
else if ( strcasecmp( tokenType, --sound ) == 0 )
{
Which gives an error while compiling:
g++ -m32 -DVERSION=\2.0.5\ -DYY_STATIC -I.. -I../..
-I/home/Gerard/Warzone-DevPkg/include -fpermissive -Wall -O0 -g3 -DDEBUG -mwindows
-DWIN32 -c -oclparse.o clparse.c
clparse.c: In function `BOOL ParseCommandLine(int, char**)':
clparse.c:273: error: `setDrawShadows' undeclared (first use this function)
clparse.c:273: error: (Each undeclared identifier is reported only once for
each function it appears in.)
make[1]: *** [clparse.o] Error 1
- Gerard
___
Warzone-dev mailing list
Warzone-dev@gna.org
https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] More patches for warnings
Dennis Schridde wrote: Am Donnerstag, 2. November 2006 22:27 schrieb Troman: - Original Message - From: Dennis Schridde [EMAIL PROTECTED] To: Development list warzone-dev@gna.org Sent: Wednesday, November 01, 2006 11:50 PM Subject: Re: [Warzone-dev] More patches for warnings Am Mittwoch, 1. November 2006 23:03 schrieb Gerard Krol: Hi, This evenings work ;) new.patch contains the addition of two macro's, and the use of them to replace MALLOC MALLOC itself is a macro around some custom wrapper around malloc... So perhaps we should also check if we (additionally to using this NEW wrapper) could drop that MALLOC malloc wrapper... (I don't really know what exact functionality MALLOC and FREE provide, besides that FREE checks for NULL pointers, what is useless as free() is defined by the C std to do nothing in that case.) --Dennis PS: Idea seems good, didn't look at the patch. It is a cleaner approach, but for me it is more intuitively to use MALLOC since already the name implies that malloc functionality will be used at some point. And these 2 new macros will not replace all occurances of MALLOC, so we are just introducing more macros for the same functionality. But anyway, I will be an impartial executor of a collective opinion. To make it painless for everyone if no objections will be raised until tomorrow evening I will just go on and apply the patch. Well, then make it MALLOC instead. NEW is also more C++ style... I'd be ok with it, but it doesn't bring much real benefit, though you could even don't use NEW. Also most ppl would probably not use NEW anyway as they are used to MALLOC/malloc and that's what's used in most of the code. You are right YaWM (Yet another Wrapper Macro) is probably not needed and would clutter the code even more. I have a lot more experience using the C++ new than the C malloc, as you guessed, so the new seems more natural to me. And how about calling it MALLOC_NEW? It is indeed YaWM, but it saves a cast and a sizeof. And I find (SOME_LONG_TYPENAME*)MALLOC(sizeof(SOME_LONG_TYPENAME)*a*b) not so nice to look at as MALLOC_NEW_ARRAY(SOME_LONG_TYPENAME, a*b) But I guess the former is more C. If someone wonders what this macro does, he can take an easy look at mem.h Shall I try to completely remove all MALLOC calls and replace them with MALLOC_NEW? The MALLOC calls left are for strings and texture pages and such, but they can then be replaced with: MALLOC_NEW_ARRAY(char, size) The alternative is that I add casts to all MALLOC's that not yet have them, this would fix a lot of warnings too. - Gerard ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
