Re: [warzone2100-dev] The dirt trail to 3.1
On 23/01/12 09:04 PM, buginator wrote: On Fri, Jan 20, 2012 at 12:49 PM, Christian Ohm chr...@gmx.net wrote: Anything else that needs to be done? Are Safety0ff's buffer swap and vexed's lobby patches final? The lobby patch works as intended, but, the backend infrastructure needs to be fixed. The last time I tried Safety0ff's patch, it did fix the issues I saw/had. No it is not final, I meant to have vexed test the older patch in the ticket (because I do not remember if that one fixed everything as well.) I intended to remove the pie_UniTransBoxFill - pie_BoxFill change in that older patch. Regards, -Safety0ff ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [warzone2100-dev] #2815: Qt's swapinterval method for x11 is no suitable for warzone
Hi all, I've added a patch that allows QtGame to control the swap interval on all platforms to this ticket, could everyone one review test it please? -Safety0ff ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [warzone2100-dev] Reorganization of maps
On 11/07/11 09:52 PM, Per Inge Mathisen wrote: 2) Maps are moved to data/maps/ which contains map name.ini and either a map name.zip OR a map name/ directory for each map What is the rationale for putting a map name.ini outside of the map name.zip or map name/ directory? ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
[warzone2100-dev] Raycasting algorithm
I was looking in raycast.cpp on other business and I noticed that the callback could potentially be called twice for one tile, or not at all, depending on how the ray crosses the tile. So I'm wondering whether anyone has noticed this before and if there are opinions about changing/fixing this. Regards, -Safety0ff ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
[warzone2100-dev] X axis rotation direction
Hi all, I've been working with the coordinates in warzone and I've noticed that the following: - It can though of as a right handed coordinate system where the axes observed from an observer aligned with the positive Z axis the X axis would represent left and the Y axis would represent up. - The rotations are such that a positive direction (aka heading, aka yaw) and roll result in anticlockwise rotations about the Y and Z axes respectively. - A positive pitch rotation results in a clockwise rotation about the X axis. My question is: do you think it would be better to change it so that a positive pitch results in an anticlockwise rotation so that rotations are consistent ? Basically I see two ways of proceeding, either change the existing code so that assumes anticlockwise X axis rotations, or improve / fix any documentation about the rotations. Having all the rotations anticlockwise would mean that they wouldn't require negation in the rendering code. Thanks, -Safety0ff P.S. Please also confirm that the above is correct. ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
[warzone2100-dev] [Bug 741888] Re: WarZone2100 crashes during the startup
commits: b7cb308f30590bbd1508b9a15e2e8dd3d1d769ab, 2d4d2d807d98fd9cd3b49891faf0b34976330915 Fix this and they are present in versions 2.3.6 and later. -- You received this bug notification because you are a member of Warzone 2100 Project, which is subscribed to warzone2100 in Ubuntu. https://bugs.launchpad.net/bugs/741888 Title: WarZone2100 crashes during the startup Status in “warzone2100” package in Ubuntu: Incomplete Bug description: Binary package hint: warzone2100 $ warzone2100 Could not attach to process. If your uid matches the uid of the target process, check the setting of /proc/sys/kernel/yama/ptrace_scope, or try again as the root user. For more details, see /etc/sysctl.d/10-ptrace.conf ptrace: Operation not permitted. /home/volodya/16579: No such file or directory. No stack. No registers. No frame selected. The program has no registers now. Saved dump file to '/tmp/warzone2100.gdmp-LSE1Nr' If you create a bugreport regarding this crash, please include this file. Segmentation fault $ apt-cache showpkg tremulous warzone2100 Package: warzone2100 Versions: 2.3.4-1 (/var/lib/apt/lists/ubuntu.tiscali.nl_dists_maverick_universe_binary-i386_Packages) (/var/lib/dpkg/status) Description Language: File: /var/lib/apt/lists/ubuntu.tiscali.nl_dists_maverick_universe_binary-i386_Packages MD5: ee73db23fc6dca6f64a0d1c5fe0e9235 Reverse Depends: warzone2100-music,warzone2100 warzone2100-dbg,warzone2100 2.3.4-1 warzone2100-data,warzone2100 Dependencies: 2.3.4-1 - libc6 (2 2.8) libgcc1 (2 1:4.1.1) libgl1-mesa-glx (16 (null)) libgl1 (0 (null)) libglc0 (2 0.7.1) libglee0d1 (0 (null)) libglu1-mesa (16 (null)) libglu1 (0 (null)) libogg0 (2 1.0rc3) libopenal1 (0 (null)) libphysfs1 (2 1.1.1) libpng12-0 (2 1.2.13-4) libpopt0 (2 1.16) libsdl1.2debian (2 1.2.10-1) libstdc++6 (2 4.2.1) libtheora0 (2 1.0~beta1) libvorbis0a (2 1.1.2) libvorbisfile3 (2 1.1.2) libx11-6 (0 (null)) warzone2100-data (2 2.3.4) warzone2100-data (1 2.3.4-1) warzone2100-music (2 2.3.4) warzone2100-music (1 2.3.4-1) Provides: 2.3.4-1 - Reverse Provides: Package: tremulous Versions: 1.1.0-5 (/var/lib/apt/lists/ubuntu.tiscali.nl_dists_maverick_multiverse_binary-i386_Packages) (/var/lib/dpkg/status) Description Language: File: /var/lib/apt/lists/ubuntu.tiscali.nl_dists_maverick_multiverse_binary-i386_Packages MD5: 84dae4b1a45bdd04509391194955191e Reverse Depends: tremulous-server,tremulous tremulous-doc,tremulous tremulous-data,tremulous Dependencies: 1.1.0-5 - libc6 (2 2.11) libopenal1 (0 (null)) libsdl1.2debian (2 1.2.10-1) tremulous-data (2 1.1.0-1) tremulous-doc (0 (null)) tremulous-server (0 (null)) Provides: 1.1.0-5 - Reverse Provides: ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
[warzone2100-dev] [Bug 741888] Re: WarZone2100 crashes during the startup
I meant those fix the ptrace/security issue. -- You received this bug notification because you are a member of Warzone 2100 Project, which is subscribed to warzone2100 in Ubuntu. https://bugs.launchpad.net/bugs/741888 Title: WarZone2100 crashes during the startup Status in “warzone2100” package in Ubuntu: Incomplete Bug description: Binary package hint: warzone2100 $ warzone2100 Could not attach to process. If your uid matches the uid of the target process, check the setting of /proc/sys/kernel/yama/ptrace_scope, or try again as the root user. For more details, see /etc/sysctl.d/10-ptrace.conf ptrace: Operation not permitted. /home/volodya/16579: No such file or directory. No stack. No registers. No frame selected. The program has no registers now. Saved dump file to '/tmp/warzone2100.gdmp-LSE1Nr' If you create a bugreport regarding this crash, please include this file. Segmentation fault $ apt-cache showpkg tremulous warzone2100 Package: warzone2100 Versions: 2.3.4-1 (/var/lib/apt/lists/ubuntu.tiscali.nl_dists_maverick_universe_binary-i386_Packages) (/var/lib/dpkg/status) Description Language: File: /var/lib/apt/lists/ubuntu.tiscali.nl_dists_maverick_universe_binary-i386_Packages MD5: ee73db23fc6dca6f64a0d1c5fe0e9235 Reverse Depends: warzone2100-music,warzone2100 warzone2100-dbg,warzone2100 2.3.4-1 warzone2100-data,warzone2100 Dependencies: 2.3.4-1 - libc6 (2 2.8) libgcc1 (2 1:4.1.1) libgl1-mesa-glx (16 (null)) libgl1 (0 (null)) libglc0 (2 0.7.1) libglee0d1 (0 (null)) libglu1-mesa (16 (null)) libglu1 (0 (null)) libogg0 (2 1.0rc3) libopenal1 (0 (null)) libphysfs1 (2 1.1.1) libpng12-0 (2 1.2.13-4) libpopt0 (2 1.16) libsdl1.2debian (2 1.2.10-1) libstdc++6 (2 4.2.1) libtheora0 (2 1.0~beta1) libvorbis0a (2 1.1.2) libvorbisfile3 (2 1.1.2) libx11-6 (0 (null)) warzone2100-data (2 2.3.4) warzone2100-data (1 2.3.4-1) warzone2100-music (2 2.3.4) warzone2100-music (1 2.3.4-1) Provides: 2.3.4-1 - Reverse Provides: Package: tremulous Versions: 1.1.0-5 (/var/lib/apt/lists/ubuntu.tiscali.nl_dists_maverick_multiverse_binary-i386_Packages) (/var/lib/dpkg/status) Description Language: File: /var/lib/apt/lists/ubuntu.tiscali.nl_dists_maverick_multiverse_binary-i386_Packages MD5: 84dae4b1a45bdd04509391194955191e Reverse Depends: tremulous-server,tremulous tremulous-doc,tremulous tremulous-data,tremulous Dependencies: 1.1.0-5 - libc6 (2 2.11) libopenal1 (0 (null)) libsdl1.2debian (2 1.2.10-1) tremulous-data (2 1.1.0-1) tremulous-doc (0 (null)) tremulous-server (0 (null)) Provides: 1.1.0-5 - Reverse Provides: ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
[warzone2100-dev] Concurrency documentation rule
The documentation for the concurrent code in warzone is severely lacking documentation (just like the rest of the code). I just don't think it is acceptable for nuances of concurrent programming to go undocumented, so I propose a new rule going forward: Detailed documentation for all concurrent code must be created, no exceptions. By detailed documentation, I mean something like a sequence diagram in the wiki, a large comment block explaining the flow/ sequence of events, etc. The minimum that should be explained (imo): thread lifetimes, synchronization, message passing. Thoughts? I'll help out with this once my schedule clears up (i.e. I'm not just trying to make work for others). -Safety0ff ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [warzone2100-dev] adding a linear algebra library
On 19/05/11 05:41 AM, Per Inge Mathisen wrote: I am, but I think we should use the recently released Eigen 3, which is still not much supported on linux distros. Not sure if that means we should inline it in our own distribution for a while. By the time master is stable for release, Eigen 3 is probably everywhere, and we can drop our own copy of it. - Per That is exactly what I was thinking. ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [warzone2100-dev] adding a linear algebra library
Is everyone still on board with this? ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
[warzone2100-dev] Patch review request (#2667)
Hi all, could you please review/test the patch in #2667? http://developer.wz2100.net/ticket/2667 It includes a few extra changes, but you know how it is when you're going through the code. It includes this patch: http://developer.wz2100.net/attachment/ticket/2515/mouseJustFix.patch And fixes #308. Feel free to commit if you feel it is ready. Thanks, -Safety0ff ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [warzone2100-dev] Plan proposal
On 24/04/11 08:04 AM, Per Inge Mathisen wrote: * We need a way for users to convert old maps to the new format. I will write a command-line app to do it, and Fastdeath has offered to set up a php service for it, using that app. * Once a new map format is ready, we can start experimenting with a new map renderer. Of course, these things go together, so I assume that the new map format will have a few revisions before it is stabilized. * The new map renderer should use shaders, but not require as much hardware as the current. Consider this statement ironical? Only if you have made a habit out of thinking that poor drivers mean weak hardware. But lots of recent weak/cheap hardware now have quite decent OpenGL ES 2 drivers. The new map renderer needs to be fast, maintainable, and extensible. We first need to start writing down what we want as the format. * QtGame (support for resolution changing) needs to be finished. * Finally, we should be looking at utilizing Qt for making a new GUI, like we were thinking with betawidget. This task also does not need to be finished before stable release. Last time I checked, for Qt widgets to work properly on all platforms with Opengl we need to use a qgraphicsview and a qglwidget subclass, and set the glwidget as the background for the graphics view (like this: http://www.qtcentre.org/wiki/index.php?title=Accelerate_your_Widgets_with_OpenGL ). When I was doing some testing of QtGame (on Windows), we ran into issues with using the QGLWidget with normal widgets as children. The issues (IIRC) were with event handling and widget rendering. When I ran into these issues I coded a qgraphicsview based demo and it did not exhibit the same problems (though creating widget layouts seemed much more awkward). Though this issue seemed to have magically gone away (maybe after a Qt version upgrade), it is my opinion that this needs to be tested and proven to be viable on all supported platforms. I think this could be done by altering QtGame and getting feedback via the forums (poll anyone?) -Safety0ff ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [warzone2100-dev] Plan proposal
On 24/04/11 07:34 PM, dak180 wrote: While it might be the only one currently maintained there is also: https://github.com/dak180/WZME If someone wants to resurrect it. Unless you just want the UI layout, I wouldn't waste my time on it. ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
[warzone2100-dev] Is ticket #1956 a duplicate?
I'm not sure whether there is a subtle difference between this ticket and closed tickets #1900 and #1906. ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
[warzone2100-dev] [Bug 652082] Re: fails trying to use unexistant library
Looks like you might have two warzone2100 executables:
/usr/games/warzone2100 which seems to find all the 64bit libs
fine.
/home/encolpe/bin/warzone2100which looks for 32bit libs but fails to find
physfs, theora and glc.
Either install the 32bit libs for the 32bit version (~/bin/warzone2100)
or use /usr/games/warzone2100 (64bit) version.
--
You received this bug notification because you are a member of Warzone
2100 Project, which is subscribed to warzone2100 in Ubuntu.
https://bugs.launchpad.net/bugs/652082
Title:
fails trying to use unexistant library
Status in “warzone2100” package in Ubuntu:
Incomplete
Bug description:
Binary package hint: warzone2100
On a new maverick installation I get this error running warzone2100:
$ warzone2100
warzone2100: error while loading shared libraries: libphysfs.so.1: cannot
open shared object file: No such file or directory
The libphysfs1 is coorectly installed:
$ dpkg -S libphysfs.so.1
libphysfs1: /usr/lib/libphysfs.so.1
$ ls -lh /usr/lib/libphysfs.so.1
lrwxrwxrwx 1 root root 27 2010-09-30 15:20 /usr/lib/libphysfs.so.1 -
/usr/lib/libphysfs.so.2.0.1
$ ls /usr/lib/libphysfs.so.2.0.1
/usr/lib/libphysfs.so.2.0.1
ends of the starce output :
open(/lib32/tls/i686/sse2/cmov/libphysfs.so.1, O_RDONLY) = -1 ENOENT (No
such file or directory)
stat64(/lib32/tls/i686/sse2/cmov, 0xffdb3eec) = -1 ENOENT (No such file or
directory)
open(/lib32/tls/i686/sse2/libphysfs.so.1, O_RDONLY) = -1 ENOENT (No such
file or directory)
stat64(/lib32/tls/i686/sse2, 0xffdb3eec) = -1 ENOENT (No such file or
directory)
open(/lib32/tls/i686/cmov/libphysfs.so.1, O_RDONLY) = -1 ENOENT (No such
file or directory)
stat64(/lib32/tls/i686/cmov, 0xffdb3eec) = -1 ENOENT (No such file or
directory)
open(/lib32/tls/i686/libphysfs.so.1, O_RDONLY) = -1 ENOENT (No such file or
directory)
stat64(/lib32/tls/i686, 0xffdb3eec) = -1 ENOENT (No such file or
directory)
open(/lib32/tls/sse2/cmov/libphysfs.so.1, O_RDONLY) = -1 ENOENT (No such
file or directory)
stat64(/lib32/tls/sse2/cmov, 0xffdb3eec) = -1 ENOENT (No such file or
directory)
open(/lib32/tls/sse2/libphysfs.so.1, O_RDONLY) = -1 ENOENT (No such file or
directory)
stat64(/lib32/tls/sse2, 0xffdb3eec) = -1 ENOENT (No such file or
directory)
open(/lib32/tls/cmov/libphysfs.so.1, O_RDONLY) = -1 ENOENT (No such file or
directory)
stat64(/lib32/tls/cmov, 0xffdb3eec) = -1 ENOENT (No such file or
directory)
open(/lib32/tls/libphysfs.so.1, O_RDONLY) = -1 ENOENT (No such file or
directory)
stat64(/lib32/tls, 0xffdb3eec)= -1 ENOENT (No such file or
directory)
open(/lib32/i686/sse2/cmov/libphysfs.so.1, O_RDONLY) = -1 ENOENT (No such
file or directory)
stat64(/lib32/i686/sse2/cmov, 0xffdb3eec) = -1 ENOENT (No such file or
directory)
open(/lib32/i686/sse2/libphysfs.so.1, O_RDONLY) = -1 ENOENT (No such file
or directory)
stat64(/lib32/i686/sse2, 0xffdb3eec) = -1 ENOENT (No such file or
directory)
open(/lib32/i686/cmov/libphysfs.so.1, O_RDONLY) = -1 ENOENT (No such file
or directory)
stat64(/lib32/i686/cmov, 0xffdb3eec) = -1 ENOENT (No such file or
directory)
open(/lib32/i686/libphysfs.so.1, O_RDONLY) = -1 ENOENT (No such file or
directory)
stat64(/lib32/i686, 0xffdb3eec) = -1 ENOENT (No such file or
directory)
open(/lib32/sse2/cmov/libphysfs.so.1, O_RDONLY) = -1 ENOENT (No such file
or directory)
stat64(/lib32/sse2/cmov, 0xffdb3eec) = -1 ENOENT (No such file or
directory)
open(/lib32/sse2/libphysfs.so.1, O_RDONLY) = -1 ENOENT (No such file or
directory)
stat64(/lib32/sse2, 0xffdb3eec) = -1 ENOENT (No such file or
directory)
open(/lib32/cmov/libphysfs.so.1, O_RDONLY) = -1 ENOENT (No such file or
directory)
stat64(/lib32/cmov, 0xffdb3eec) = -1 ENOENT (No such file or
directory)
open(/lib32/libphysfs.so.1, O_RDONLY) = -1 ENOENT (No such file or
directory)
stat64(/lib32, {st_mode=S_IFDIR|0755, st_size=16384, ...}) = 0
open(/usr/lib32/tls/i686/sse2/cmov/libphysfs.so.1, O_RDONLY) = -1 ENOENT
(No such file or directory)
stat64(/usr/lib32/tls/i686/sse2/cmov, 0xffdb3eec) = -1 ENOENT (No such file
or directory)
open(/usr/lib32/tls/i686/sse2/libphysfs.so.1, O_RDONLY) = -1 ENOENT (No
such file or directory)
stat64(/usr/lib32/tls/i686/sse2, 0xffdb3eec) = -1 ENOENT (No such file or
directory)
open(/usr/lib32/tls/i686/cmov/libphysfs.so.1, O_RDONLY) = -1 ENOENT (No
such file or directory)
stat64(/usr/lib32/tls/i686/cmov, 0xffdb3eec) = -1 ENOENT (No such file or
directory)
open(/usr/lib32/tls/i686/libphysfs.so.1, O_RDONLY) = -1 ENOENT (No such
file or directory)
stat64(/usr/lib32/tls/i686, 0xffdb3eec) = -1 ENOENT (No such file or
directory)
open(/usr/lib32/tls/sse2/cmov/libphysfs.so.1, O_RDONLY) = -1 ENOENT (No
such file or directory)
stat64(/usr/lib32/tls/sse2/cmov, 0xffdb3eec) = -1 ENOENT (No such file or
directory)
Re: [warzone2100-dev] request to remove 3rd party libs that we embed
On 11-03-17 08:38 PM, buginator wrote: Pabs3 mentioned that we should remove all embedded 3rd party libs, and I am OK with this. This would mean we remove glee from source, as well as miniupnp. I think the iniparser stuff is custom, though I am not 100% sure. Objections ? I am in favor of this (for glee and miniupnpc). -Safety0ff ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
[warzone2100-dev] Ticket #343 Patch review
I've posted a patch to #343 and it'd be great if anyone familiar with exchndlr.cpp (i.e. Giel) could review it. Thanks, -Safety0ff ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [warzone2100-dev] Intent to merge, intent to destroy
On 11-03-30 03:23 PM, Per Inge Mathisen wrote: PS The new javascript scavenger script is attached as an example for those too lazy to look in the qtscript branch. From the script: And we can use the built-in Math library switch (Math.random() * 10) How does that work with Cyp's determinism work? Shouldn't it use our deterministic rng ? ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
[warzone2100-dev] How long will we officially maintain Windows 2000 compatibility?
Many of the Windows API functions we use are deprecated, while I have no intention using functions whose minimum is Win XP at the moment, I couldn't help but wonder what the official word on maintaining this compatibility is. Regards, -Safety0ff ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
[warzone2100-dev] Cross compiling qt branch
Hey all, In case it is of interest to anyone: I successfully cross compiled the Qt branch using mingw-cross-env. It is about 12 MB bigger than master built with mingw-cross-env (32.8MB versus 44.9MB). Seems to run OK on wine. Instructions are here: http://developer.wz2100.net/wiki/CompileGuideWindows/MingwCrossEnv I had to merge master, and I pushed it here: https://github.com/Safety0ff/warzone2100/commits/qt Regards, Safety0ff ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [warzone2100-dev] [Warzone 2100 Trac] #1066: Warzone doesn't support non-ASCII chars in PhysFS 2.0.0
Hey all, I'm pretty sure I've got this all figured out (tested it on Windows and it worked with unicode characters in addition to characters in the current code page). The implications are: CMake now required to cross compile (specifically for building Physfs 2). The precompiled version of physfs should be removed from the tarball (I've set things such that the Physfs 2 build overwrites the files from the tarball for the time being). Anyways, please review the two commits at the tip here: https://github.com/Safety0ff/warzone2100/commits/masterphysfs2 And voice your opinions concerns ASAP. I intend for these changes to be present in the next master alpha/release. Thanks. -Safety0ff ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [warzone2100-dev] [Warzone 2100 Trac] #1066: Warzone doesn't support non-ASCII chars in PhysFS 2.0.0
Hey all, I've post two patches to this ticket and It'd be great it if some people could test them. Requirements: You must have cmake installed (for physfs 2+ cross compilation) Instructions: Apply both patches and cross compile warzone. Put base.wz and mp.wz in a directory whose path contains non-ascii characters (see ticket for a better description of the issue). Try launching warzone (on windows) using the --datadir option. ( Zarel since you're one of the reporters in the original ticket, it'd be great if you could find a way to test this.) Let's get this 1+ year old ticket closed. :) -Safety0ff ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
[warzone2100-dev] Any feedback for #2458 ?
Hey all, I posted this patch a few weeks ago and would like to have some feedback as whether or not it should be committed. http://developer.wz2100.net/ticket/2458 Use pkg-config for quesoglc build configuration. Regards, -Safety0ff ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [warzone2100-dev] Directory layout changes for future build system
It seems there isn't enough support for this change (moving lib/* to src/). Next subject: Opinions on moving miniupnpc from lib/netplay to somewhere else? ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [warzone2100-dev] Directory layout changes for future build system
On 11-01-15 04:01 AM, Per Inge Mathisen wrote: Generally, I am worried that we are now making so many huge changes to the codebase that all existing patches soon have to be written from scratch. This is not cool. Specifically, I do not see a good reason for this change. Compiling parts of a codebase to a temporary library is quite normal practice, and I like having the code available in a shallow structure. - Per I don't see how this is a bigger deal for patches than the c - cpp rename, it is more or less a rename plus a removal of the useless lib/ in the include directives, which shouldn't require rewriting a patch from scratch. Moving stuff from lib to src doesn't create a deeper structure, lib and src have the same number of characters, so files will be at the same depth no matter how you spin it. If you're alluding to me moving the contents of src to src/warzone2100 (in the CMake branch) then let me make it clear that the purpose of this thread of discussion was for the lib to src move *only*. I'm rather indifferent about that change. On 11-01-15 10:14 AM, Christian Ohm wrote: On Saturday, 15 January 2011 at 1:18, Safety0ff wrote: Hi all, While working on a CMake build system I took the opportunity to move the contents from lib to src. I don't see what that gains us, to me it'll only lead to confusion between old and new layout and breaking of existing patches/branches. Somewhat loosely related, what would be good imo is a lib/3rdparty directory, for all the third party code we include. The rationale for this was: 1) It helped me to keep the build system rational without compiling some of the parts into libraries (like the current system does.) Even automake can build the whole Warzone without building separate libraries (though it's not configured that way atm). I put third party code in a top level 3rdparty directory in the CMake branch, I didn't see a reason to put third party stuff in lib/3rdparty/*, that just seems unnecessary hierarchy. What I said does not imply that it was mandatory to build Warzone without building separate libraries, what was meant is that doing so kept things cleaner / more logical. I am aware that autotools can do that too, but IIRC you lose certain options (using separate build flags, IIRC). On 11-01-15 10:32 AM, dak180 wrote: Generally this is why I am in favor of using feature branches in personal forks instead of patches; no mater the changes made they will still be able to be rebased onto the apropreate branch (or merged if there has been a significant change of contents). Or you can use this if you have git patches: http://developer.wz2100.net/wiki/GitTricks#Merginganoldpatch ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
[warzone2100-dev] Directory layout changes for future build system
Hi all, While working on a CMake build system I took the opportunity to move the contents from lib to src. The rationale for this was: 1) It helped me to keep the build system rational without compiling some of the parts into libraries (like the current system does.) 2) lib is more commonly used for: - The binary output directory for libraries. - A directory that contains pre-compiled dependencies. - A directory where dependencies can be placed for linking (for this sometimes the plural is used: libs) I would like this to be discussed so that we reach definite decision on the matter. Regards, -Safety0ff ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [warzone2100-dev] [Warzone2100-commits] [Warzone2100/warzone2100] cc0756: Use the stats to determine struct height and clea...
On 10-11-30 12:28 PM, Per Inge Mathisen wrote: Can you say a little bit more about why you think this is a good solution? To me, this looks like a huge hack. Stats height values 1 have never been used before, AFAICT, so they might be random for all I know. Instinctively I would think that it is better to find the height from the model, instead of looking some number up in a stats file (which sounds like unnecessary duplication of data). - Per I was having issues using the height (max vertex height) of certain models (it lead to odd rules regarding what can fire over what) and the values in the stats files more or less modelled the behaviour I was trying to achieve. Fron what I saw when looking at the stats, the values aren't random, at the moment they are one of 1, 2 or 3 and are somewhat proportional to the height of the structure. With the 3.0 beta 4 release imminent it seemed important that that issue be resolved, if you come up with a better solution that addresses the issue, by all means replace mine with it. ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
[warzone2100-dev] Crash handler doesn't work with Ubuntu 10.10
Hi all, Ubuntu has added ptrace scope protection in 10.10 [1,2]. This causes an issue with crash handlers. See kde [3], chromium[4], wine[5], etc. From what I've read, the solution is to define the constant if it is not defined and call the function (prctl will ignore unknown options.) In addition to this we will need to hold the child process until we have called prctl in the parent. I briefly tested that this solves the issue on my system with the following changes: http://pastebin.com/tpZ04MTc Obviously that patch does not synchronise the child (the purpose was only to check that it would work.) Please discuss. -Safety0ff [1] https://wiki.ubuntu.com/SecurityTeam/Roadmap/KernelHardening#ptrace%20Protection [2] https://wiki.ubuntu.com/Security/Features#PTRACE%20scope [3] https://launchpad.net/bugs/589841 [4] http://code.google.com/p/chromium/issues/detail?id=46368 [5] http://bugs.winehq.org/show_bug.cgi?id=24193 ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [warzone2100-dev] Reordering data layout
On 10-10-02 04:21 AM, Guangcong Luo wrote: As for merging base and mp, what's your plan to deal with the massive campaign imbalance that would cause? Though I do not know precisely what Buginator has in mind, merging does not imply that SP and MP will have the same stats. AFAIK, it should not be too difficult to edit the .wrf and .lev files so that the modes use different stats (actual mileage may vary). -Safety0ff ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [warzone2100-dev] The new branch and what we all need to decide on (tcmask textures)
On 10-09-28 03:52 AM, Per Inge Mathisen wrote: We do not have simply original models with TCmask enabled anywhere. The one ticket I saw that claimed to have this turned out to be 1) containing other stuff as well, and 2) had several issues that were never resolved. (The ticket no. in question is: http://developer.wz2100.net/ticket/1757 ) The issues that were noticed in the screenshot you posted were fixed within a day. In the revised changes, the derrick changes are reverted. It looks like the only .pie that has any modifications is blhq.pie (some flags were added to polygons which will need to be removed before committing). Also, the power gen's texture was rectified as well. The tcmask flag is set on the power gen pie which is useless as there isn't any tcmask applied to its texture (not a big deal either). -Safety0ff ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [warzone2100-dev] The new branch and what we all need to decide on
On 10-09-28 12:38 PM, dak180 wrote: if we can it would be good to start getting some of the ArtRev models in game. I think that's a whole other can of worms, I'm not sure it's a good time to go there. Regards, -Safety0ff ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [warzone2100-dev] [Warzone2100-commits] SF.net SVN: warzone2100:[11676] trunk/data/base/shaders/tcmask.vert
On 10-09-18 11:43 AM, Giel van Schijndel wrote: Another question; which models actually use this shader? See: http://developer.wz2100.net/ticket/1757 http://sourceforge.net/projects/wzgraphicmods/ ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
[warzone2100-dev] Ticket #2009
I think I'll commit the conservative patches in #2009, cfrelease.diff (trunk) and 23leaks.diff (2.3), since nobody has commented on the boat rocking version. ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
[warzone2100-dev] ticket #2009 - Request for thoughts/feedback
Hey all, I made some patches to fix the CFURLRef leaks under Mac and I'd like to know which solution you want used. My first patch (dir.diff) adds a function and moves some code in a new .h/.c file pair (makes main.c a little tidier). The added function removes duplicate code and accompanying conditional inclusions e.g. h//ttp://developer.wz2100.net/changeset/10316/branches/2.3/lib/framework/i18n.c (r9835 for trunk) http://developer.wz2100.net/changeset/11230/trunk/lib/ivis_opengl/textdraw.c (Plus the origin of the above code in main.c) In the ticket I've also added the fix only versions (cfrelease.diff and 23leaks.diff). As you can see every time something changes with that code, it has to be changed in three different places. Other notes: - There are some build systems I cannot update (Mac, MSVC, etc.) - The copyright is missing a 2100 Anyways, let me know what you want (or commit it yourself.) Regards, -Safety0ff ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [warzone2100-dev] Bug #1871 and whether there are 8 frame animations
On 10-06-28 01:51 AM, Safety0ff wrote:
another that returns whether it has team colours.
Something like this:
inline BOOL hasTeamColours (const iIMDShape* imd) { return
imd-numFrames == 8; }
inline BOOL hasAnimation (const iIMDShape* imd) { return
(imd-numFrames 0 !hasTeamColours(imd)); }
Hey again,
A little adjustment to my previous message, I meant texture team
colours, so the name of the function would have to be different ( since
a model could have TCMask team colours.)
___
Warzone-dev mailing list
Warzone-dev@gna.org
https://mail.gna.org/listinfo/warzone-dev
[warzone2100-dev] Bug #1871 and whether there are 8 frame animations
Hi all,
I found a fix for bug #1871, but I also found some hacks in there that I
took the opportunity to remove.
Patch #1 leaves the hacks in place, patch #2 removes the hacks:
http://developer.wz2100.net/attachment/ticket/1871/structframes.diff
http://developer.wz2100.net/attachment/ticket/1871/structframes2.diff
This made me wonders whether there are any PIEs with 8 frame animation
(e.g non-teamcolour with 8 frames).
There shouldn't be any, but I checked all the standard pies in the
*/struct/ folder ( just to make sure for patch #2).
If there aren't any PIEs that have 8 non-teamcolour frames, then I
propose we make two functions, one that returns whether a imd has
animations, and another that returns whether it has team colours.
Something like this:
inline BOOL hasTeamColours (const iIMDShape* imd) { return
imd-numFrames == 8; }
inline BOOL hasAnimation (const iIMDShape* imd) { return (imd-numFrames
0 !hasTeamColours(imd)); }
The purpose would be to prevent repetition and clean up the code.
So let me know:
- Whether you know if there aren't any pie files that (ab)use 8
animation frames.
- If you oppose my proposition.
- Whether you have any objections to patch #2 going into trunk (
possibly modified to use functions like those shown above.)
P.S. The comments for getModularScaledGraphicsTime are wrong about the
range returned, this is why imd-numFrames is passed in rather than
numFrames - 1.
-Safety0ff
___
Warzone-dev mailing list
Warzone-dev@gna.org
https://mail.gna.org/listinfo/warzone-dev
[warzone2100-dev] Endianness function reorganization proposal
Hey all, We currently have 4 different ways of dealing with endianess ( 5 before r11002), they are: PHYSFS_swap* ( declared in physfs.h, used 39 times ) SDL_swap*( declared in SDL_endian.h, used 15 times) System networking functions hton* ntoh* ( declared in netinet/in.h, arpa/inet.h, winsock2.h, etc. used 53 times) endian_* word (defined in endian_hack.h, inline functions that swap using pointers, used ~511 times) I think we should rename endian_hack.h to wz_endian.h and turn it into the single header that provides all the declarations to deal with endian swapping (for network and other code.) What do you guys think? Anyways, even if you disagree with doing the above, SDL_swap* should be removed in favor of the PHYSFS_swap* and hton* ntoh* ( for nettypes.c). ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [warzone2100-dev] Release plans
buginator wrote: 1) Qt. The Main menu / in game menus suffer from a state conflict. That is, when we set modes, (pie_SetRendMode() pie_SetTranslucencyMode()), it looks like we are conflicting with the way Qt is handling the window/widget. Qt suggest to use beginNativePainting()/endNativePainting(), but that causes a big performance hit, and didn't really fix anything when I tried some tests with that. The QPainter in iV_DrawTextRotated is changing the state. Adding a pie_SetRendMode(REND_OPAQUE); call seems to alleviate the issue. Is changing the main menu colors to match the backdrop is intentional? -Safety0ff ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [warzone2100-dev] Changeset 10691: semperfi starvation problem
Hi, I had more details for this problem but I forgot to give them last time per was on IRC. Anyways, it might be a more of a T3 problem, the following screenshots were taken on NTW2 T3 with max starting power. As you can see only one semperfi ai managed its money carefuly enough to avoid starvation. I spectated one AI and it seemed to wait a little too long to start building the power plants, then it ran out power because it was building other stuff at the same time. Screenshots: http://imagebin.ca/view/wC8X3Kp.html http://imagebin.ca/view/4HAkb3Jn.html http://imagebin.ca/view/ECQxXYt.html http://imagebin.ca/view/E0pGajy.html http://imagebin.ca/view/eNtFPn.html http://imagebin.ca/view/FUqlMPO.html http://imagebin.ca/view/DADS-j.html http://imagebin.ca/view/iVspmas.html http://imagebin.ca/view/S1XQOd.html http://imagebin.ca/view/2va-SN.html http://imagebin.ca/view/YJ30sV.html http://imagebin.ca/view/QVqAc8.html ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [warzone2100-dev] Warzone's direction for 2.3 series
C yp wrote: Think the main part is power, movement and experience. Think floating-point might be (mis)used a few other random places, but probably nowhere that isn't easy to fix. Think it's used all over the place in src/effects.c, but that file _shouldn't_ affect the game state (except that maybe it does, think Safety might have said something about oil well burning times depending on src/effects.c, not sure if I understood, since it's hard to believe there could be something hacky like that in a codebase like this). -Cyp For fire effects (not only oil well fires,) the _killEffect_ function retrieves the tile from the position (Vector3f,) and clears the fire bit of that tile. Effect times seem to use integers. If you don't believe me then look at the _killEffect_ function, it is very short. That clearing of the fire bit causes bug #1100 because there might be multiple fire effects whose position corresponds to a given tile. The first effect to die will clear the bit. -Safety0ff ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
