Re: [Warzone-dev] Using OBJ (wavefront) for moddeling data.
On 5/19/07, Dennis Schridde [EMAIL PROTECTED] wrote: Am Samstag, 19. Mai 2007 schrieb The Watermelon: this patch is by no means working properly,but with these 2 things fixed it should be usable: 1.Change terrain vertices back to int/change float multiplication/division to shift or use new terrain renderer 2.Fixed some minor texture coords problems. Questions: Why did you turn sx,sy,sz into vertexPos in this patch? That should get into a seperate patch. Why did you use Vector3d at some times? Why did you add this iV_DIVFLOATDIV macro? And what do the magic values mean? iV_TRANSLATE? And actually I expected this patch to be split into smaller parts. Read floats, store floats, render floats or something like that... --Dennis 1.sx,sy,sz are not human-understandable and may get confused with 'x,y,z' in SV_MESH struct 2.it's double used in imdload to pre-calculate some radius stuff 3.iV_DIVFLOATDIV is equal to the old (15)(the max tolerable depth of tile(distance) to draw tile) iV_MULFLOATMUL is equal to the old (115) the problem with the terrain renderer/clipping is that it require the vertices(sx,sy,sz which is relative origin of tile drawing(the top-left tile position)) to be int,or it will cause serious clipping/z-depth fail problems if you dont use int,e.g:the terrain rendering after this patch is completely screwed up when using float terrain vertices. I can make terrain vertices int again,so it should work properly,but SV_MESH will not longer 'inherit' from PIEVERTEX,because the vertexPos in SV_MESH will be a Vector3i instead of a Vector3f due to this change,though such thing can resolved easily by changing few memcpy's of SV_MESH and PIEVERTEX to individual member value assignments,imo let SV_MESH 'inherit' from PIEVERTEX is pointless,since SV_MESH will get stored into a PIEVERTEX and passed to drawTexTriangle eventually. ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Using OBJ (wavefront) for moddeling data.
On 5/19/07, Kamaze [EMAIL PROTECTED] wrote: I would be suprised if you find a common file format which supports connectors. Common or not, Quake III's MD3 file format supports connectors. It also supports animations, which we also need. However, like most formats, it stores triangles, instead of polygons (quads) like PIE files do. We cannot change the 3D data format as long as we need a program to post-process the 3D data, and we do not yet have a replacement for PIE-slicer. - Per ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] [Warzone-commits] r1305 - in /trunk/lib: netplay/netplay.c sound/cdaudio.c
Stefan Huehner schreef: Author: shuehner Date: Sun May 20 15:51:53 2007 New Revision: 1305 URL: http://svn.gna.org/viewcvs/warzone?rev=1305view=rev Log: 2 small fixes in function declarations : () - (void) Modified: trunk/lib/netplay/netplay.c trunk/lib/sound/cdaudio.c According to the ISO C standard (both C89 and C99) this is _not_ necessary. The only place where you need to use a function signature of `(void)`, to indicate a function taking no arguments, is in forward declarations, not in function definitions. -- Giel signature.asc Description: OpenPGP digital signature ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] [Warzone-commits] r1305 - in /trunk/lib: netplay/netplay.c sound/cdaudio.c
On Sun, May 20, 2007 at 04:01:27PM +0200, Giel van Schijndel wrote:
Stefan Huehner schreef:
Author: shuehner
Date: Sun May 20 15:51:53 2007
New Revision: 1305
URL: http://svn.gna.org/viewcvs/warzone?rev=1305view=rev
Log:
2 small fixes in function declarations : () - (void)
Modified:
trunk/lib/netplay/netplay.c
trunk/lib/sound/cdaudio.c
According to the ISO C standard (both C89 and C99) this is _not_
necessary. The only place where you need to use a function signature of
`(void)`, to indicate a function taking no arguments, is in forward
declarations, not in function definitions.
Hmm i haven't got the text here to look it up myself. But chaning i.e.
the static function declaration in cdaudio.c:58 to (void) removes the
following to warning from my gcc warning output:
-cdaudio.c:58: warning: function declaration isn't prototype
-cdaudio.c: In function: 'ProcessedBuffers':
-cdaudio.c:58: warning: old-style function definition
I'am compiling with additional -Wstrict-prototypes abd
-Wold-style-definition to catch these.
And for a direct improvement which comes in changing these i attach the
following 2 test-cases.
test1.c has the following 'static void test1()' and if you compile this
you'll notive that the compiler doesn't catch the function call in main
with an argument. I assume that i wanted to have the test1 function
without arguments.
test2.c is the same programs but with 'static void test1(void)'. Now the
compiler correctly catches the wrong function call.
Regards,
Stefan
static void test1() {
}
int main(int argc, char *argv[]) {
test1(5);
return 0;
}
static void test1(void) {
}
int main(int argc, char *argv[]) {
test1(5);
return 0;
}
___
Warzone-dev mailing list
Warzone-dev@gna.org
https://mail.gna.org/listinfo/warzone-dev
[Warzone-dev] SVN trunk broken
Whenever I approach an enemy oil rig in a skrimish, the game asserts
for me with most recent svn trunk, no local modifications:
error : gridStartIterate: coords off grid
error : Assert in Warzone: mapgrid.c:276 : gridStartIterate ((x =
0) (x gridWidth*GRID_UNITS) (y = 0) (y
gridHeight*GRID_UNITS)), last script event: 'everySec'
warzone2100: mapgrid.c:276: gridStartIterate: Assertion `(x = 0)
(x gridWidth*(8 * (17))) (y = 0) (y gridHeight*(8 *
(17)))' failed.
Dump below:
Program command: src/warzone2100
Version: TRUNK
Type: Debug
Compiled on: May 20 2007
Operating system: Linux
Node name: Jedi
Release: 2.6.19-1.2288.fc5
Version: #1 Sat Feb 10 14:52:17 EST 2007
Machine: i686
Pointers: 32bit
Dump caused by signal: SIGABRT: Process abort signal
...
Loaded symbols for /lib/librt.so.1
0x00220402 in __kernel_vsyscall ()
(gdb) #0 0x00220402 in __kernel_vsyscall ()
No symbol table info available.
#1 0x4bc0eceb in __waitpid_nocancel () from /lib/libpthread.so.0
No symbol table info available.
#2 0x081c41c9 in posixExceptionHandler (signum=6, siginfo=0xbfa6e34c,
sigcontext=0xbfa6e3cc) at exceptionhandler.c:496
btBuffer = {0x81c3bce, 0x220440, 0x4b8c24f1, 0x4b8ba859,
0x80bf3df, 0x816368e, 0x8162b45, 0x8162bb3, 0x80baa77, 0x80bc259,
0x80bc56d, 0x80bc9b7,
0x4b8ae4e4, 0x804ca21, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}
btSize = 14
pid = 9023
gdbPipe = {12, 13}
dumpFile = 11
allreadyRunning = 1
#3 signal handler called
No symbol table info available.
#4 0x00220402 in __kernel_vsyscall ()
No symbol table info available.
#5 0x4b8c0ee9 in raise () from /lib/libc.so.6
No symbol table info available.
#6 0x4b8c24f1 in abort () from /lib/libc.so.6
No symbol table info available.
#7 0x4b8ba859 in __assert_fail () from /lib/libc.so.6
No symbol table info available.
#8 0x080bf3df in gridStartIterate (x=4939, y=65457) at mapgrid.c:274
__FUNCTION__ = gridStartIterate
__PRETTY_FUNCTION__ = gridStartIterate
#9 0x0816368e in projGetNaybors (psObj=0xa56c780) at projectile.c:2356
xdiff = 0
ydiff = 173459328
dx = 4939
dy = 65457
distSqr = 3435973837
psTempObj = (BASE_OBJECT *) 0xa56c780
#10 0x08162b45 in proj_Update (psObj=0xa56c780) at projectile.c:1914
__FUNCTION__ = proj_Update
__PRETTY_FUNCTION__ = proj_Update
#11 0x08162bb3 in proj_UpdateAll () at projectile.c:1943
psObj = (PROJ_OBJECT *) 0xa56c780
#12 0x080baa77 in gameLoop () at loop.c:424
psCurr = (DROID *) 0x0
psNext = (DROID *) 0x0
psCBuilding = (STRUCTURE *) 0x0
psNBuilding = (STRUCTURE *) 0x0
psCFeat = (FEATURE *) 0xedbaa000
psNFeat = (FEATURE *) 0x4c278298
i = 8
widgval = 0
quitting = 0
intRetVal = INT_NONE
clearMode = 7
__FUNCTION__ = gameLoop
__PRETTY_FUNCTION__ = gameLoop
#13 0x080bc259 in runGameLoop () at main.c:526
No locals.
#14 0x080bc56d in mainLoop () at main.c:688
event = {type = 4 '\004', active = {type = 4 '\004', gain = 0
'\0', state = 0 '\0'}, key = {type = 4 '\004', which = 0 '\0', state =
0 '\0',
keysym = {scancode = 249 '�', sym = 65535, mod = KMOD_NONE,
unicode = 0}}, motion = {type = 4 '\004', which = 0 '\0', state = 0
'\0', x = 1273,
y = 688, xrel = -1, yrel = 0}, button = {type = 4 '\004', which =
0 '\0', button = 0 '\0', state = 0 '\0', x = 1273, y = 688}, jaxis = {
type = 4 '\004', which = 0 '\0', axis = 0 '\0', value = 1273},
jball = {type = 4 '\004', which = 0 '\0', ball = 0 '\0', xrel = 1273,
yrel = 688},
jhat = {type = 4 '\004', which = 0 '\0', hat = 0 '\0', value = 0
'\0'}, jbutton = {type = 4 '\004', which = 0 '\0', button = 0 '\0',
state = 0 '\0'},
resize = {type = 4 '\004', w = 45090041, h = 65535}, expose = {type
= 4 '\004'}, quit = {type = 4 '\004'}, user = {type = 4 '\004', code =
45090041,
data1 = 0x, data2 = 0x0}, syswm = {type = 4 '\004', msg = 0x2b004f9}}
#15 0x080bc9b7 in main (argc=3, argv=0xbfa6eab4) at main.c:850
psPaletteBuffer = (iColour *) 0xa2416a0
pSize = 768
(gdb) Detaching from program: /home/devel/warzone/src/warzone2100, process 9008
Anyone feel responsible? ;-)
- Per
___
Warzone-dev mailing list
Warzone-dev@gna.org
https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] SVN trunk broken
On 5/20/07, Per Inge Mathisen [EMAIL PROTECTED] wrote: Whenever I approach an enemy oil rig in a skrimish, the game asserts for me with most recent svn trunk, no local modifications: I should add, it asserts when I approach an enemy oil rig with a combat unit. It works in revision 1295. So it was broken recently. - Per ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] [Warzone-commits] r1305 - in /trunk/lib: netplay/netplay.c sound/cdaudio.c
Stefan Huehner schreef: On Sun, May 20, 2007 at 04:01:27PM +0200, Giel van Schijndel wrote: Stefan Huehner schreef: Author: shuehner Date: Sun May 20 15:51:53 2007 New Revision: 1305 URL: http://svn.gna.org/viewcvs/warzone?rev=1305view=rev Log: 2 small fixes in function declarations : () - (void) Modified: trunk/lib/netplay/netplay.c trunk/lib/sound/cdaudio.c According to the ISO C standard (both C89 and C99) this is _not_ necessary. The only place where you need to use a function signature of `(void)`, to indicate a function taking no arguments, is in forward declarations, not in function definitions. Hmm i haven't got the text here to look it up myself. But chaning i.e. the static function declaration in cdaudio.c:58 to (void) removes the following to warning from my gcc warning output: -cdaudio.c:58: warning: function declaration isn't prototype -cdaudio.c: In function: 'ProcessedBuffers': -cdaudio.c:58: warning: old-style function definition I'am compiling with additional -Wstrict-prototypes abd -Wold-style-definition to catch these. And for a direct improvement which comes in changing these i attach the following 2 test-cases. test1.c has the following 'static void test1()' and if you compile this you'll notive that the compiler doesn't catch the function call in main with an argument. I assume that i wanted to have the test1 function without arguments. test2.c is the same programs but with 'static void test1(void)'. Now the compiler correctly catches the wrong function call. Yes, those are results you can expect when functions don't have forward declarations, as is usual with static functions. So in the case of static functions declaring an argument list of `(void)` is correct. In case of non-static functions however (i.e. with external linkage) you _do_ need a forward declaration. So in that case it is better to keep the argument list of `(void)` in the function declaration and out of its definition. -- Giel signature.asc Description: OpenPGP digital signature ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] SVN trunk broken
Per Inge Mathisen schreef: On 5/20/07, Per Inge Mathisen [EMAIL PROTECTED] wrote: Whenever I approach an enemy oil rig in a skrimish, the game asserts for me with most recent svn trunk, no local modifications: I should add, it asserts when I approach an enemy oil rig with a combat unit. It works in revision 1295. So it was broken recently. Per, would you mind adding this to the bugtracker instead. Thanks, -- Giel signature.asc Description: OpenPGP digital signature ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
[Warzone-dev] Suggestion for Profiling.
Just found this: http://silverspaceship.com/src/iprof/ Maybe someone find this usefull. I read that it isn't ported to other plattforms yet, but here a quote from the readme: ### PLATFORM SUPPORT IProf requires a small amount--less than fifty lines--ofplatform-specific code. Win32 under MSVC is automatically supported with no further effort on your part, using the files prof_win32.c and prof_win32.h To use other platforms, just create equivalent files for your platform. The C file contains a routine for getting an accurate floating point time reading; the H file contains the definition of a 64-bit integer type and a fast routine for reading a timestamp of that size. If 64-bit math isn't available on your platform, or if your timestamp is only 32-bit, you can replace the 64-bit type with a 32-bit type, as long as that item won't overflow in the course of running the application. (A 31-bit millisecond timer is good for 24 days, but is very imprecise for this application.) If reading the timestamp is slow, you will want to minimize how often the zone entry and exit points are called. ### Maybe it would be usefull. - Regards, Kamaze ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
[Warzone-dev] code formatting
Looking at various pieces of code I'm getting quite annoyed, seeing that quite often in the same file (or even in the same function for that matter) uses of tabs and spaces are being mixed up for the purpose of indentation. Therefore I propose we do a one time run over the codebase with a a code formatter. I am currently looking at Artistic Style http://astyle.sourceforge.net/ which seems to perform quite well for this purpose. I currently invoke it like this (with satisfiable results that match our codingstyle): C code: astyle --suffix=none --indent=tab --brackets=break --indent-switches --pad=oper --unpad=paren --min-conditional-indent=0 --mode=c C++ code: astyle --suffix=none --brackets=break --indent-switches --pad=oper --unpad=paren --min-conditional-indent=0 --mode=c --indent-classes --indent-namespaces I'll give an example of the C++ invocation in a commit on the lobbyserver in several minutes. Which doesn't use tabs for indentation (4 spaces instead), simply because that code has too many scope levels to be nice with 8 sized tabs (vim's default behaviour). -- Giel signature.asc Description: OpenPGP digital signature ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
[Warzone-dev] hack to prevent transporters being blown up
Some people have reported problems when their transport got stuck that they couldn't blow it up. (E.g. http://wz2100.net/forum/index.php?topic=606.0 ) This is most certainly the direct result from a so called hack to prevent Transporter's being blown up in droid.c (just for that exact string, although it should be on lines 295, 353). This hack causes function droidDamage (which ought to return TRUE on destruction of a droid) to always returns false if the droid being asked about is a transport (line 295 code). Now, do we want this behaviour or not? (I personally would most certainly don't want the code to check for a specific droid type, instead some kind of indestructible flag which could be set for each droid would be better). -- Giel signature.asc Description: OpenPGP digital signature ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] code formatting
On 5/20/07, Giel van Schijndel [EMAIL PROTECTED] wrote: Therefore I propose we do a one time run over the codebase with a a code formatter. You realize that this will screw up svn blame, right? It is an invaluable bug hunting tool, and am I still annoyed with myself that I did not work harder to save svn history from the berlios days. I'd say we wait with something like this until the codebase is more stable. Right now we need all the bug hunting aid we need, rather than a pretty codebase. - Per ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] [Warzone-commits] r1310 - in /trunk/src: droid.c structure.c
Am Sonntag, 20. Mai 2007 schrieb Giel van Schijndel: Author: muggenhor Date: Sun May 20 18:37:11 2007 New Revision: 1310 URL: http://svn.gna.org/viewcvs/warzone?rev=1310view=rev Log: * remove debug macro TEST_EW (EW as in something dirty perhaps?) Reading the comment just above #define TEST_EW, I know that EW doesn't mean something dirty, but stands for electronic warfare, which apparently was an unreleased feature of the game. I don't know why this only seems to enable and disable multiplay mode, but I'd have loved to know what this was about... --Dennis signature.asc Description: This is a digitally signed message part. ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] SVN trunk broken
Am Sonntag, 20. Mai 2007 schrieb Per Inge Mathisen: On 5/20/07, Per Inge Mathisen [EMAIL PROTECTED] wrote: Whenever I approach an enemy oil rig in a skrimish, the game asserts for me with most recent svn trunk, no local modifications: I should add, it asserts when I approach an enemy oil rig with a combat unit. It works in revision 1295. So it was broken recently. Can confirm this... It must have been broken very very recently as while I was testing my commits I went into the enemy bases a few times and nothing happened. (I didn't do that for all commits though.) Investigating... --Dennis signature.asc Description: This is a digitally signed message part. ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] hack to prevent transporters being blown up
Am Sonntag, 20. Mai 2007 schrieb Giel van Schijndel: Some people have reported problems when their transport got stuck that they couldn't blow it up. (E.g. http://wz2100.net/forum/index.php?topic=606.0 ) This is most certainly the direct result from a so called hack to prevent Transporter's being blown up in droid.c (just for that exact string, although it should be on lines 295, 353). This hack causes function droidDamage (which ought to return TRUE on destruction of a droid) to always returns false if the droid being asked about is a transport (line 295 code). Now, do we want this behaviour or not? (I personally would most certainly don't want the code to check for a specific droid type, instead some kind of indestructible flag which could be set for each droid would be better). There are a few issues... - By simply removing that check you will blow up the wrong transports. - Will you get a new transport if you blew the old one up? If you don't I wonder how you ever want to accomplish the campaign... - Indestructible flag sounds good, but would not be backwards compatible since it needs modifications to the maps and savegames. (Thus nothing for 2.0) --Dennis signature.asc Description: This is a digitally signed message part. ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] [Warzone-commits] r1310 - in /trunk/src: droid.c structure.c
Am Sonntag, 20. Mai 2007 schrieb Giel van Schijndel: Author: muggenhor Date: Sun May 20 18:37:11 2007 New Revision: 1310 URL: http://svn.gna.org/viewcvs/warzone?rev=1310view=rev Log: * remove debug macro TEST_EW (EW as in something dirty perhaps?) Reading the comment just above #define TEST_EW, I know that EW doesn't mean something dirty, but stands for electronic warfare, which apparently was an unreleased feature of the game. I haven't look in what context it was used, but EW could also stand for Edit World - the map editor. I don't know why this only seems to enable and disable multiplay mode, but I'd have loved to know what this was about... --Dennis -- Roman___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] [Warzone-commits] r1310 - in /trunk/src: droid.c structure.c
Am Sonntag, 20. Mai 2007 schrieb Roman: Am Sonntag, 20. Mai 2007 schrieb Giel van Schijndel: Author: muggenhor Date: Sun May 20 18:37:11 2007 New Revision: 1310 URL: http://svn.gna.org/viewcvs/warzone?rev=1310view=rev Log: * remove debug macro TEST_EW (EW as in something dirty perhaps?) Reading the comment just above #define TEST_EW, I know that EW doesn't mean something dirty, but stands for electronic warfare, which apparently was an unreleased feature of the game. I haven't look in what context it was used, but EW could also stand for Edit World - the map editor. The comment Giel removed was: //testing the new electronic warfare for multiPlayer - AB don't want to release with this in the game!! signature.asc Description: This is a digitally signed message part. ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] [Warzone-commits] r1310 - in /trunk/src: droid.c structure.c
Am Sonntag, 20. Mai 2007 schrieb Roman: Am Sonntag, 20. Mai 2007 schrieb Giel van Schijndel: Author: muggenhor Date: Sun May 20 18:37:11 2007 New Revision: 1310 URL: http://svn.gna.org/viewcvs/warzone?rev=1310view=rev Log: * remove debug macro TEST_EW (EW as in something dirty perhaps?) Reading the comment just above #define TEST_EW, I know that EW doesn't mean something dirty, but stands for electronic warfare, which apparently was an unreleased feature of the game. I haven't look in what context it was used, but EW could also stand for Edit World - the map editor. The comment Giel removed was: //testing the new electronic warfare for multiPlayer - AB don't want to release with this in the game!! Well I warned you I haven't looked at the context it was used in. -- Roman___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] SVN trunk broken
On 5/20/07, Dennis Schridde [EMAIL PROTECTED] wrote: It must have been broken very very recently as while I was testing my commits I went into the enemy bases a few times and nothing happened. (I didn't do that for all commits though.) The problem arrived with revision 1303 as far as I can tell. [EMAIL PROTECTED] warzone]$ svn log -r1303 r1303 | devurandom | 2007-05-20 13:05:28 +0200 (Sun, 20 May 2007) | 5 lines - Remove unused code - Remove duplicated code/macros - VECTOR3D-Vector3i - Create float variants of normal functions to simplify Watermelon's float-PIE patch - per ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] SVN trunk broken
Am Sonntag, 20. Mai 2007 schrieb Per Inge Mathisen: On 5/20/07, Dennis Schridde [EMAIL PROTECTED] wrote: It must have been broken very very recently as while I was testing my commits I went into the enemy bases a few times and nothing happened. (I didn't do that for all commits though.) The problem arrived with revision 1303 as far as I can tell. I found that out already, and currently I think pie_ROTATE_TRANSLATE is responsible... --Dennis signature.asc Description: This is a digitally signed message part. ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] SVN trunk broken
Patch that fixes the problem. No idea why it works. But it seems to.
- Per
Index: src/structure.c
===
--- src/structure.c (revision 1311)
+++ src/structure.c (working copy)
@@ -5846,7 +5846,7 @@
barrel.z = 0;
}
- pie_RotateTranslate3iv(barrel, muzzle);
+ pie_ROTATE_TRANSLATE(barrel.x, barrel.z, barrel.y, muzzle-x, muzzle-z, muzzle-y);
muzzle-z = -muzzle-z;
pie_MatEnd();
@@ -5899,7 +5899,7 @@
barrel.z = 0;
}
- pie_RotateTranslate3iv(barrel, muzzle);
+ pie_ROTATE_TRANSLATE(barrel.x, barrel.z, barrel.y, muzzle-x, muzzle-z, muzzle-y);
muzzle-z = -muzzle-z;
pie_MatEnd();
Index: src/droid.c
===
--- src/droid.c (revision 1311)
+++ src/droid.c (working copy)
@@ -4822,7 +4822,7 @@
barrel.z = 0;
}
- pie_RotateTranslate3iv(barrel, muzzle);
+ pie_ROTATE_TRANSLATE(barrel.x, barrel.z, barrel.y, muzzle-x, muzzle-z, muzzle-y);
muzzle-z = -muzzle-z;
pie_MatEnd();
@@ -4871,7 +4871,7 @@
barrel.z = 0;
}
- pie_RotateTranslate3iv(barrel, muzzle);
+ pie_ROTATE_TRANSLATE(barrel.x, barrel.z, barrel.y, muzzle-x, muzzle-z, muzzle-y);
muzzle-z = -muzzle-z;
pie_MatEnd();
Index: lib/ivis_opengl/piematrix.h
===
--- lib/ivis_opengl/piematrix.h (revision 1311)
+++ lib/ivis_opengl/piematrix.h (working copy)
@@ -45,36 +45,40 @@
/***/
extern SDMATRIX *psMatrix;
-extern SDWORD aSinTable[];
+extern SDWORD aSinTable[];
//*
// FIXME DUPLICATE CODE! Already present in trig.c!
-#define SIN(X) aSinTable[(Uint16)(X) 4]
-#define COS(X) aSinTable[((Uint16)(X) 4) + 1024]
+#define SIN(X) aSinTable[(Uint16)(X) 4]
+#define COS(X) aSinTable[((Uint16)(X) 4) + 1024]
//*
-/*!
- * Rotate and translate v with the worldmatrix. Store the result in s
- * \param[in] v Vector to translate
- * \param[out] s Resulting vector
- */
-static inline void pie_RotateTranslate3iv(Vector3i * v, Vector3i * s)
-{
- s-x = ( v-x * psMatrix-a + v-y * psMatrix-d + v-z * psMatrix-g
- + psMatrix-j ) / FP12_MULTIPLIER;
- s-y = ( v-x * psMatrix-b + v-y * psMatrix-e + v-z * psMatrix-h
- + psMatrix-k ) / FP12_MULTIPLIER;
- s-z = ( v-x * psMatrix-c + v-y * psMatrix-f + v-z * psMatrix-i
- + psMatrix-l ) / FP12_MULTIPLIER;
+#define pie_ROTATE_TRANSLATE(x,y,z,xs,ys,zs) \
+{ \
+ xs = (x) * psMatrix-a + (y) * psMatrix-d + (z) * psMatrix-g + \
+psMatrix-j;\
+ ys = (x) * psMatrix-b + (y) * psMatrix-e + (z) * psMatrix-h + \
+psMatrix-k;\
+ zs = (x) * psMatrix-c + (y) * psMatrix-f + (z) * psMatrix-i + \
+psMatrix-l;\
+ xs =FP12_SHIFT;\
+ ys =FP12_SHIFT;\
+ zs =FP12_SHIFT;\
}
+//*
+
//*
+#define pie_CLOCKWISE(x0,y0,x1,y1,x2,y2) y1)-(y0)) * ((x2)-(x1))) = (((x1)-(x0)) * ((y2)-(y1
+//*
+
+
extern void pie_MatInit(void);
___
Warzone-dev mailing list
Warzone-dev@gna.org
https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] SVN trunk broken
On 5/20/07, Per Inge Mathisen [EMAIL PROTECTED] wrote:
Patch that fixes the problem. No idea why it works. But it seems to.
Shorter diff. Still seems to work fine.
- Per
Index: src/structure.c
===
--- src/structure.c (revision 1311)
+++ src/structure.c (working copy)
@@ -5846,7 +5846,7 @@
barrel.z = 0;
}
- pie_RotateTranslate3iv(barrel, muzzle);
+ pie_ROTATE_TRANSLATE(barrel.x, barrel.z, barrel.y, muzzle-x, muzzle-z, muzzle-y);
muzzle-z = -muzzle-z;
pie_MatEnd();
@@ -5899,7 +5899,7 @@
barrel.z = 0;
}
- pie_RotateTranslate3iv(barrel, muzzle);
+ pie_ROTATE_TRANSLATE(barrel.x, barrel.z, barrel.y, muzzle-x, muzzle-z, muzzle-y);
muzzle-z = -muzzle-z;
pie_MatEnd();
Index: src/droid.c
===
--- src/droid.c (revision 1311)
+++ src/droid.c (working copy)
@@ -4822,7 +4822,7 @@
barrel.z = 0;
}
- pie_RotateTranslate3iv(barrel, muzzle);
+ pie_ROTATE_TRANSLATE(barrel.x, barrel.z, barrel.y, muzzle-x, muzzle-z, muzzle-y);
muzzle-z = -muzzle-z;
pie_MatEnd();
@@ -4871,7 +4871,7 @@
barrel.z = 0;
}
- pie_RotateTranslate3iv(barrel, muzzle);
+ pie_ROTATE_TRANSLATE(barrel.x, barrel.z, barrel.y, muzzle-x, muzzle-z, muzzle-y);
muzzle-z = -muzzle-z;
pie_MatEnd();
Index: lib/ivis_opengl/piematrix.h
===
--- lib/ivis_opengl/piematrix.h (revision 1311)
+++ lib/ivis_opengl/piematrix.h (working copy)
@@ -56,19 +56,17 @@
//*
-/*!
- * Rotate and translate v with the worldmatrix. Store the result in s
- * \param[in] v Vector to translate
- * \param[out] s Resulting vector
- */
-static inline void pie_RotateTranslate3iv(Vector3i * v, Vector3i * s)
-{
- s-x = ( v-x * psMatrix-a + v-y * psMatrix-d + v-z * psMatrix-g
- + psMatrix-j ) / FP12_MULTIPLIER;
- s-y = ( v-x * psMatrix-b + v-y * psMatrix-e + v-z * psMatrix-h
- + psMatrix-k ) / FP12_MULTIPLIER;
- s-z = ( v-x * psMatrix-c + v-y * psMatrix-f + v-z * psMatrix-i
- + psMatrix-l ) / FP12_MULTIPLIER;
+#define pie_ROTATE_TRANSLATE(x,y,z,xs,ys,zs) \
+{ \
+ xs = (x) * psMatrix-a + (y) * psMatrix-d + (z) * psMatrix-g + \
+psMatrix-j;\
+ ys = (x) * psMatrix-b + (y) * psMatrix-e + (z) * psMatrix-h + \
+psMatrix-k;\
+ zs = (x) * psMatrix-c + (y) * psMatrix-f + (z) * psMatrix-i + \
+psMatrix-l;\
+ xs =FP12_SHIFT;\
+ ys =FP12_SHIFT;\
+ zs =FP12_SHIFT;\
}
___
Warzone-dev mailing list
Warzone-dev@gna.org
https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] hack to prevent transporters being blown up
On Sun, 20 May 2007 15:42:39 -0400 Dennis Schridde [EMAIL PROTECTED] wrote: Am Sonntag, 20. Mai 2007 schrieb Giel van Schijndel: Some people have reported problems when their transport got stuck that they couldn't blow it up. (E.g. http://wz2100.net/forum/index.php?topic=606.0 ) This is most certainly the direct result from a so called hack to prevent Transporter's being blown up in droid.c (just for that exact string, although it should be on lines 295, 353). This hack causes function droidDamage (which ought to return TRUE on destruction of a droid) to always returns false if the droid being asked about is a transport (line 295 code). Now, do we want this behaviour or not? (I personally would most certainly don't want the code to check for a specific droid type, instead some kind of indestructible flag which could be set for each droid would be better). There are a few issues... - By simply removing that check you will blow up the wrong transports. - Will you get a new transport if you blew the old one up? If you don't I wonder how you ever want to accomplish the campaign... - Indestructible flag sounds good, but would not be backwards compatible since it needs modifications to the maps and savegames. (Thus nothing for 2.0) --Dennis Are you say that the original codebase has bug for transports, or is this a fix for code that was modified from original codebase? I thought that issue was if some file was not found, then it would screw up. This goes back to berlios days. ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] code formatting
On Sun, 20 May 2007 15:04:12 -0400 Per Inge Mathisen [EMAIL PROTECTED] wrote: On 5/20/07, Giel van Schijndel [EMAIL PROTECTED] wrote: Therefore I propose we do a one time run over the codebase with a a code formatter. You realize that this will screw up svn blame, right? It is an invaluable bug hunting tool, and am I still annoyed with myself that I did not work harder to save svn history from the berlios days. I'd say we wait with something like this until the codebase is more stable. Right now we need all the bug hunting aid we need, rather than a pretty codebase. - Per On old berlios mail list, this was talk about, and problem is as you say. It would be more hard to find bugs, among other things. Once codebase is stable, then maybe it will be nice to use prettyC or another one. It also is hard to make people use the code style you want them, if they use to another one. No win really, unless devs run all patches from now on through a style program, and then the code base will get pretty as more patches make way to them. ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
