Menu
▾
▴
glbsp-public — Open discussion about glBSP
You can subscribe to this list here.
| 2000 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(3) |
Oct
|
Nov
|
Dec
|
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2001 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(1) |
Jul
|
Aug
|
Sep
(1) |
Oct
|
Nov
|
Dec
|
| 2002 |
Jan
(1) |
Feb
|
Mar
|
Apr
|
May
|
Jun
(16) |
Jul
(1) |
Aug
|
Sep
(1) |
Oct
|
Nov
(1) |
Dec
(1) |
| 2004 |
Jan
(4) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(1) |
Oct
|
Nov
|
Dec
|
|
From: Andrew A. <aa...@me...> - 2004-09-29 04:44:14
|
Hi, I'm pleased to announce that glBSP 2.10 has been released. glBSP is a node builder designed for OpenGL DOOM ports. This release should fix crashes with JHexen. Other changes in glBSP 2.10 include: - support V3 GL-Nodes (handle insanely complex levels). - comprehensive problem report when levels fail. - handle levels containing more than 32767 sidedefs. - removed -fresh option (now the default), added -fast option. - removed code to detect and ignore dummy sectors. - overlapping linedefs are detected and ignored. The homepage is: http://glbsp.sourceforge.net Cheers, -- Andrew Apted <aj...@us...> |
|
From: Andre M. <ama...@te...> - 2004-01-05 20:32:30
|
On 2004-01-05 14:53 +1100, Andrew Apted wrote: > On Sun, Jan 04, 2004 at 04:12:15PM +0100, Andre Majorel wrote: > > > > Excerpt: > > > > > Thanks to Lee Killough and André Majorel (the previous and > > > current maintainers of BSP, respectively), glBSP is now under > > > the GNU General Public License (GPL). > > > > Though I did pester Colin about GPLing BSP, I'm not BSP's > > maintainer. Colin is. > > You were the maintainer at the time, right ? But not for long, as that was just before my election as Miss Venezuela. -- André Majorel <ama...@te...> http://www.teaser.fr/~amajorel/ |
|
From: Andrew A. <aa...@me...> - 2004-01-05 03:53:39
|
On Sun, Jan 04, 2004 at 04:12:15PM +0100, Andre Majorel wrote: > > Excerpt: > > > Thanks to Lee Killough and André Majorel (the previous and > > current maintainers of BSP, respectively), glBSP is now under > > the GNU General Public License (GPL). > > Though I did pester Colin about GPLing BSP, I'm not BSP's > maintainer. Colin is. You were the maintainer at the time, right ? Cheers, -- Andrew Apted <aj...@us...> |
|
From: Andre M. <ama...@te...> - 2004-01-04 15:13:54
|
On 2004-01-04 23:02 +1100, Andrew Apted wrote: > http://glbsp.sourceforge.net/ Excerpt: > Thanks to Lee Killough and Andr=E9 Majorel (the previous and > current maintainers of BSP, respectively), glBSP is now under > the GNU General Public License (GPL). Though I did pester Colin about GPLing BSP, I'm not BSP's maintainer. Colin is. --=20 Andr=E9 Majorel <ama...@te...> http://www.teaser.fr/~amajorel/ |
|
From: Andrew A. <aa...@me...> - 2004-01-04 12:02:13
|
Version 2.05 of glBSP (a nodes builder for OpenGL DOOM ports) has just been released. Major changes in this release: - ported glbsp and glBSPX to MacOS X. - added new option "-quiet" for less cluttered output. - glbsp now handles multiple input WADs (GWA mode). - lumps in the output WAD are now aligned properly. - automatically removes dummy sectors from BSP tree. For more information and downloading, visit: http://glbsp.sourceforge.net/ Cheers, -- Andrew Apted <aj...@us...> |
|
From: <kas...@at...> - 2002-12-08 08:17:43
|
I want to thank you for conceiving a splendid OpenGL engine for Doom. Your Doomsday was the first I picked on the list in doomworld.com, and it did not disappoint - it surpassed my expectations! Thanks again, and I wish you continued success. |
|
From: Magazine E. <fem...@ho...> - 2002-11-17 17:15:23
|
Female Entrepreneur is just about ready to launch its much awaited magazine and website!!! If you, or anyone you know, is interested in a complimentary issue and invitation, please respond to this message with the pertinent information including the mailing address and email contact. Find out what Female Entrepreneurs want and need to know... Kelly Swenson Female Entrepreneur |
|
From: Andrew A. <aj...@ne...> - 2002-09-25 12:43:03
|
Hey all,
Version 2.00 of glBSP and glBSPX has been released !
What's new with glBSP 2.00:
+ Building GWA files is now around 3 to 5 times faster, since glBSP
can reuse the original node information.
+ New -fresh option to force creating nodes from scratch.
+ Better reporting about levels that fail to build.
+ Portability fixes: glBSP now runs on big endian CPUs.
+ More Hexen fixes.
=20
Big big thanks must go to Janis Legzdinsh, Jussi Pakkanen and Andr=E9
Majorel for all their input, code and testing. Without them, this
release would never have happened.
Finally... let it be known that this is the *last* release of glBSP.
I have completely finished with everything relating to DOOM. If
something goes wrong with this version, you're on your own. Thanks to
everybody who made a contribution, and anybody who ever found glBSP
useful.
Cheers !
__
\/ Andrew Apted <aj...@us...>
=20
|
|
From: Andre M. <ama...@te...> - 2002-07-18 12:36:11
|
On 2002-06-10 14:57 +1000, Andrew Apted wrote: > Andre Majorel writes: > > > On 2002-06-05 23:26 +1000, Andrew Apted wrote: > > > > > Out of curiosity, which standard ? The draft ANSI C standard at the > > > back of the K&R book says: > > > > > > "Lines beginning with #, perhaps preceded by white space, > > > communicate with this preprocessor." > > > > Err... good question. To my surprise, the latest draft I have > > (n869, 1999-01) seems to allow whitespace as well. And yet I > > remember learning that it's not portable. Damn ! Did I bullshit > > you ? I'll ask on comp.std.c. > > No biggie, if you include those systems which have that limitation > (old ones ? certainly non-standard-conforming ones) then you're > still right to say it's "non portable" (though personally I don't > care much about being THAT portable :). For the record: the guys on comp.std.c have confirmed that a number of compilers used to have that limitation, but they also said that the standard has always allowed white space, ever since 1989. Sorry for this, and thank you for not trusting this fool. -- André Majorel <URL:http://www.teaser.fr/~amajorel/> std::disclaimer ("Not speaking for my employer"); |
|
From: Andrew A. <aj...@ne...> - 2002-06-30 05:26:24
|
Jussi Pakkanen writes: > I tried running Phobia (http://frad.slipgate.org/old/download/phobia.zip) > through glBSP, but the result crashes both JDoom and Vavoom. I emailed the > authors of those ports, and Janis replied with this: > > ---clip--- > That error that Vavoom gives tells that subsector is enclosed only by > the mini-segs. And this is a problem of the glBSP. There's nothing > engine can do here. > ---clip--- > > The actual error message of Vavoom is "Subsector 6316 without sector. > Stack trace: Host_Frame". OK, I've looked into this now, and I'm certain that the problem is *not* a subsector enclosed only by mini-segs. I added code to glbsp to check this situation, and it never happened (I tested with three different -factor values). What did happen is this: Warning: Number of GL segs (58429) has OVERFLOWED the normal limit! Overflow errors usually mean that the output is unusable, since there are too many segs (or whatever) to be accessed using 16 bit numbers. Really massive levels (above 8000 linedefs or so, like phobia.wad) are prone to this. However: if the engine (Vavoom or whatever) treats the 16 bit fields (in this case, the GL seg references) as unsigned, then this level should work. I tried it in EDGE and it loaded and ran (I wouldn't say "worked" per se, as it wasn't designed to work properly in EDGE). So I think the problem *does* lie with the engines, and partly with this level which is simply too complex, and partly with the Doom level formats where 16 bit values limit things. Cheers, __ \/ Andrew Apted <aj...@us...> |
|
From: Andrew A. <aj...@ne...> - 2002-06-29 07:56:43
|
Jussi Pakkanen writes: > Hi > > I tried running Phobia (http://frad.slipgate.org/old/download/phobia.zip) > through glBSP, but the result crashes both JDoom and Vavoom. I emailed the > authors of those ports, and Janis replied with this: > > ---clip--- > That error that Vavoom gives tells that subsector is enclosed only by > the mini-segs. And this is a problem of the glBSP. There's nothing > engine can do here. > ---clip--- > > The actual error message of Vavoom is "Subsector 6316 without sector. > Stack trace: Host_Frame". I'll download the wad to try it out. I've thought this problem for a while, and a miniseg-only subsector should be impossible, since the function that picks a partition line ensures that there is a least one real seg on both sides. Could well be a bug in glBSP... Cheers, __ \/ Andrew Apted <aj...@us...> |
|
From: Jussi P. <jpa...@cc...> - 2002-06-27 21:18:51
|
Hi I tried running Phobia (http://frad.slipgate.org/old/download/phobia.zip) through glBSP, but the result crashes both JDoom and Vavoom. I emailed the authors of those ports, and Janis replied with this: ---clip--- That error that Vavoom gives tells that subsector is enclosed only by the mini-segs. And this is a problem of the glBSP. There's nothing engine can do here. ---clip--- The actual error message of Vavoom is "Subsector 6316 without sector. Stack trace: Host_Frame". If you want to try this yourself, you'll have to remove the Legacy colormap features (meaning textures whose names begin with "#"). -- Jussi Pakkanen |
|
From: Andrew A. <aj...@ne...> - 2002-06-23 11:45:17
|
Jesser writes: > I am trying to use the newest version of GLBSP with hexen.wad, but > it skips converting level 08, this occurs in both the unpatched and > patched version of the game. Has anyone else had this problem? I haven't heard of this problem before. I don't have the full Hexen, so can't test it here. What operating system is it (Windows or Linux) ? Please capture the output and post it here. Under the graphical version (glBSPX) this is done with the "File -> Save Log" menu item. For the normal version, put "> gb_out.txt" at the end of the command line (without the quotes). This may give a clue. BTW, please post using plain text, as HTML is a bit of a nuisance for many people. Cheers, __ \/ Andrew Apted <aj...@us...> |
|
From: Jesser <je...@po...> - 2002-06-12 22:24:41
|
I am trying to use the newest version of GLBSP with hexen.wad, but it skips converting level 08, this occurs in both the unpatched and patched version of the game. Has anyone else had this problem?<br> <br> ____________________________________________________<br> myVine.com - Unlimited Internet as low as $12.95/mo<br> www.myVine.com<br> |
|
From: Andrew A. <aj...@ne...> - 2002-06-10 04:55:23
|
Andre Majorel writes: > On 2002-06-05 23:26 +1000, Andrew Apted wrote: > > Out of curiosity, which standard ? The draft ANSI C standard at the > > back of the K&R book says: > > > > "Lines beginning with #, perhaps preceded by white space, > > communicate with this preprocessor." > > Err... good question. To my surprise, the latest draft I have > (n869, 1999-01) seems to allow whitespace as well. And yet I > remember learning that it's not portable. Damn ! Did I bullshit > you ? I'll ask on comp.std.c. No biggie, if you include those systems which have that limitation (old ones ? certainly non-standard-conforming ones) then you're still right to say it's "non portable" (though personally I don't care much about being THAT portable :). Cheers, __ \/ Andrew Apted <aj...@us...> |
|
From: Andrew A. <aj...@ne...> - 2002-06-08 05:42:35
|
Jussi Pakkanen writes: > On Fri, 7 Jun 2002, Andrew Apted wrote: > > > The attached patch should fix it, if you don't mind having one > > last go at it, that would be great. > > Now it works. I ran glbsp on IRIX 6.5 with the -DCPU_BIG_ENDIAN switch and > loaded the file to JDoom. It said "gl nodes (or info?) found" and ran OK. > I don't use JDoom much, but I think it works now. Cool, thanks. Cheers, __ \/ Andrew Apted <aj...@us...> |
|
From: Jussi P. <jpa...@cc...> - 2002-06-07 15:05:25
|
On Fri, 7 Jun 2002, Andrew Apted wrote: > The attached patch should fix it, if you don't mind having one > last go at it, that would be great. Now it works. I ran glbsp on IRIX 6.5 with the -DCPU_BIG_ENDIAN switch and loaded the file to JDoom. It said "gl nodes (or info?) found" and ran OK. I don't use JDoom much, but I think it works now. -- Jussi Pakkanen |
|
From: Andrew A. <aj...@ne...> - 2002-06-07 12:23:24
|
Jussi Pakkanen writes: > > > Compilation fails with the following: > > > > > > ../seg.h:93: stray '\' in program > > > ../seg.h:97: stray '\' in program [SNIP] > > This was caused by DOS's CR/LF line changes. Converting source files to > UNIX-format fixed it. Ahh, ok. > This still does not work. It compiles as before, but now the error is: > > Opened PWAD file : /home/info/jpakkane/RetroEps.wad > Reading 104 dir entries at 0x195FEE > > Creating nodes using tunable factor of 7 > > Building GL nodes on E1M1 > > Error: *** No such sector number #65537 *** I found the problem, and that 65537 was a massive clue (the number should only be 16 bits). Seems the << and >> operators do "integer promotion" i.e. a 16 bit number gets promoted to 32 bits by them, which IMHO is pretty counter-intuitive (I always thought the LHS stayed the same), but it's in the standard. The attached patch should fix it, if you don't mind having one last go at it, that would be great. Cheers, __ \/ Andrew Apted <aj...@us...> |
|
From: Andre M. <ama...@te...> - 2002-06-06 18:37:31
|
On 2002-06-05 23:26 +1000, Andrew Apted wrote: > Andre Majorel writes: > > > Trying to compile glBSP 1.96 on Digital Unix 4.0 with the native > > compiler does not work because the preprocessor (rightfully) > > ignores preprocessor directives where the "#" is not on column 1. > > Per the standard, there must not be anything between the start > > of the line and the "#". > > Out of curiosity, which standard ? The draft ANSI C standard at the > back of the K&R book says: > > "Lines beginning with #, perhaps preceded by white space, > communicate with this preprocessor." Err... good question. To my surprise, the latest draft I have (n869, 1999-01) seems to allow whitespace as well. And yet I remember learning that it's not portable. Damn ! Did I bullshit you ? I'll ask on comp.std.c. -- André Majorel <URL:http://www.teaser.fr/~amajorel/> std::disclaimer ("Not speaking for my employer"); |
|
From: Jussi P. <jpa...@cc...> - 2002-06-06 18:26:46
|
On Wed, 5 Jun 2002, Andrew Apted wrote:
> > Compaq Tru64 UNIX 4.0G
> > =20
> > Compilation fails with the following:
> > =20
> > ../seg.h:93: stray '\' in program
> > ../seg.h:97: stray '\' in program
> > =20
> > This happens with gcc 2.95.3. Strangely it works with Tru64 UNIX 5.1=
A.
> =20
> Hmmmm, it is weird. Maybe the problem lies in the C preprocessor
> (cpp) not handling the '\' at the ends of lines properly (i.e. ANSI-C
> way). Seems like it ignores them, so the next lines are treated as
> actual code instead of part of the define. Please try manually
> joining the lines in an editor and compiling again.
This was caused by DOS's CR/LF line changes. Converting source files to
UNIX-format fixed it.
> > IRIX 6.5
> > =20
> > Maybe a bug with the big/little endian code?
>=20
> Sort of. The endianness code is compile-time, you need to add
> -DCPU_BIG_ENDIAN to the CFLAGS in the makefile and recompile. I'd be
> really grateful if you (and/or Andr=E9) could try that and see if it
> works (e.g. produces a usable output wad), since AFAIK glbsp has never
> been run under a big endian CPU before.
This still does not work. It compiles as before, but now the error is:
Opened PWAD file : /home/info/jpakkane/RetroEps.wad
Reading 104 dir entries at 0x195FEE
=20
Creating nodes using tunable factor of 7
=20
Building GL nodes on E1M1
Error: *** No such sector number #65537 ***
Again, it seems to be an endianness problem.
--=20
Jussi Pakkanen
|
|
From: Andrew A. <aj...@ne...> - 2002-06-06 13:55:57
|
Jussi Pakkanen writes: > I was playing around with glBSP on a few different Unices=20 Cool... > and had some problems. =20 Not so cool... > Compaq Tru64 UNIX 4.0G > =20 > Compilation fails with the following: > =20 > In file included from ../blockmap.h:25, > from ../blockmap.c:32: > ../level.h:335: parse error before `->' > In file included from ../blockmap.c:35: > ../seg.h:93: parse error before `*' > ../seg.h:93: stray '\' in program > ../seg.h:97: stray '\' in program > =20 > This happens with gcc 2.95.3. Strangely it works with Tru64 UNIX 5.1A. =20 Hmmmm, it is weird. Maybe the problem lies in the C preprocessor (cpp) not handling the '\' at the ends of lines properly (i.e. ANSI-C way). Seems like it ignores them, so the next lines are treated as actual code instead of part of the define. Please try manually joining the lines in an editor and compiling again. > IRIX 6.5 > =20 > Compiles ok but fails when run: > =20 > pyramid:~/glbsp/cmdline> glbsp eternall.wad -o tmpp.wad > =20 > *** GL BSP Node Builder. 1.96 (C) 2001 Andrew Apted. *** > *** Based on BSP 2.3 (C) 1998 Colin Reed, Lee Killough *** > =20 > Opened PWAD file : eternall.wad > Reading -234487808 dir entries at 0x5C168A01 > Warning: Read directory count consistency failure (0,-234487808) > Error: No levels found in wad ! > =20 > Maybe a bug with the big/little endian code? Sort of. The endianness code is compile-time, you need to add -DCPU_BIG_ENDIAN to the CFLAGS in the makefile and recompile. I'd be really grateful if you (and/or Andr=E9) could try that and see if it works (e.g. produces a usable output wad), since AFAIK glbsp has never been run under a big endian CPU before. I'll look into pinching the endian detection code from Yadex. > These are not serious problems (I have no intention of really using gl= BSP > on these platforms ;-)), but I figured you'd might like to know this. Thanks ! Cheers, __ \/ Andrew Apted <aj...@us...> =20 |
|
From: Andrew A. <aj...@ne...> - 2002-06-06 13:55:57
|
Andre Majorel writes:
> Trying to compile glBSP 1.96 on Digital Unix 4.0 with the native
> compiler does not work because the preprocessor (rightfully)
> ignores preprocessor directives where the "#" is not on column 1.
> Per the standard, there must not be anything between the start
> of the line and the "#".
Out of curiosity, which standard ? The draft ANSI C standard at the
back of the K&R book says:
"Lines beginning with #, perhaps preceded by white space,
communicate with this preprocessor."
> The following patch fixes this. It was made with the following
> command : find . -type f -name "*.[ch]" | xargs perl ...[SNIP]
Applied.
Cheers,
__
\/ Andrew Apted <aj...@us...>
|
|
From: Andre M. <ama...@te...> - 2002-06-04 11:05:20
|
On 2002-06-04 11:43 +0300, Jussi Pakkanen wrote: > I was playing around with glBSP on a few different Unices and had some > problems. > > Compaq Tru64 UNIX 4.0G > > Compilation fails with the following: > > In file included from ../blockmap.h:25, > from ../blockmap.c:32: > ../level.h:335: parse error before `->' > In file included from ../blockmap.c:35: > ../seg.h:93: parse error before `*' > ../seg.h:93: stray '\' in program > ../seg.h:97: stray '\' in program > > This happens with gcc 2.95.3. Strangely it works with Tru64 UNIX 5.1A. This is weird because it compiles fine (modulo a few other problems) with the native compiler (DEC C V5.6). > IRIX 6.5 > > Compiles ok but fails when run: > > pyramid:~/glbsp/cmdline> glbsp eternall.wad -o tmpp.wad > > *** GL BSP Node Builder. 1.96 (C) 2001 Andrew Apted. *** > *** Based on BSP 2.3 (C) 1998 Colin Reed, Lee Killough *** > > Opened PWAD file : eternall.wad > Reading -234487808 dir entries at 0x5C168A01 > Warning: Read directory count consistency failure (0,-234487808) > Error: No levels found in wad ! Same thing here : # ./glbsp 11.wad *** GL BSP Node Builder. 1.96 (C) 2001 Andrew Apted. *** *** Based on BSP 2.3 (C) 1998 Colin Reed, Lee Killough *** * No output file specified. Using: 11.gwa Opened PWAD file : 11.wad Reading 184549376 dir entries at 0x90CD0100 Error: *** Trouble reading wad directory *** gcc-3.0.1, Irix 6.5. > Maybe a bug with the big/little endian code? Looks like it. int32(184549376) is int32(11) with the endianness backwards. I seem to remember that Yadex or DeuTex has the same problem, BTW. :-) -- André Majorel <URL:http://www.teaser.fr/~amajorel/> std::disclaimer ("Not speaking for my employer"); |
|
From: Andre M. <ama...@te...> - 2002-06-04 10:06:58
|
Trying to compile glBSP 1.96 on Digital Unix 4.0 with the native
compiler does not work because the preprocessor (rightfully)
ignores preprocessor directives where the "#" is not on column 1.
Per the standard, there must not be anything between the start
of the line and the "#". The following patch fixes this. It was
made with the following command :
find . -type f -name "*.[ch]" | xargs perl -i -p -e 's/^(\s+)#/#$1/'
diff -ur glbsp/blockmap.c glbsp-1.96.hash/blockmap.c
--- glbsp/blockmap.c Mon Dec 17 03:06:17 2001
+++ glbsp-1.96.hash/blockmap.c Tue Jun 4 12:01:38 2002
@@ -140,9 +140,9 @@
{
uint16_g *cur = block_lines[blk_num];
- #if DEBUG_BLOCKMAP
+# if DEBUG_BLOCKMAP
PrintDebug("Block %d has line %d\n", blk_num, line_index);
- #endif
+# endif
if (blk_num < 0 || blk_num >= block_count)
InternalError("BlockAdd: bad block number %d", blk_num);
@@ -188,10 +188,10 @@
int bx, by;
int line_index = L->index;
- #if DEBUG_BLOCKMAP
+# if DEBUG_BLOCKMAP
PrintDebug("BlockAddLine: %d (%d,%d) -> (%d,%d)\n", line_index,
x1, y1, x2, y2);
- #endif
+# endif
// handle truncated blockmaps
if (bx1 < 0) bx1 = 0;
@@ -373,10 +373,10 @@
PrintWarn("Blockmap has OVERFLOWED! May cause problems "
"or even crash\n");
- #if DEBUG_BLOCKMAP
+# if DEBUG_BLOCKMAP
PrintDebug("Blockmap: Last ptr = %d duplicates = %d\n",
cur_offset, dup_count);
- #endif
+# endif
block_compression = (orig_size - new_size) * 100 / orig_size;
diff -ur glbsp/level.c glbsp-1.96.hash/level.c
--- glbsp/level.c Thu Dec 27 07:52:22 2001
+++ glbsp-1.96.hash/level.c Tue Jun 4 12:01:38 2002
@@ -227,9 +227,9 @@
DisplayTicker();
- #if DEBUG_LOAD
+# if DEBUG_LOAD
PrintDebug("GetVertices: num = %d\n", count);
- #endif
+# endif
if (!lump || count == 0)
FatalError("Couldn't find any Vertices");
@@ -268,9 +268,9 @@
DisplayTicker();
- #if DEBUG_LOAD
+# if DEBUG_LOAD
PrintDebug("GetSectors: num = %d\n", count);
- #endif
+# endif
raw = (raw_sector_t *) lump->data;
@@ -315,9 +315,9 @@
DisplayTicker();
- #if DEBUG_LOAD
+# if DEBUG_LOAD
PrintDebug("GetSidedefs: num = %d\n", count);
- #endif
+# endif
raw = (raw_sidedef_t *) lump->data;
@@ -360,9 +360,9 @@
DisplayTicker();
- #if DEBUG_LOAD
+# if DEBUG_LOAD
PrintDebug("GetLinedefs: num = %d\n", count);
- #endif
+# endif
raw = (raw_linedef_t *) lump->data;
@@ -432,9 +432,9 @@
DisplayTicker();
- #if DEBUG_LOAD
+# if DEBUG_LOAD
PrintDebug("GetLinedefs: num = %d\n", count);
- #endif
+# endif
raw = (raw_hexen_linedef_t *) lump->data;
@@ -507,9 +507,9 @@
if (! sector)
return;
- #if DEBUG_POLYOBJ
+# if DEBUG_POLYOBJ
PrintDebug(" Marking SECTOR %d\n", sector->index);
- #endif
+# endif
// mark all lines of this sector as precious, to prevent the sector
// from being split.
@@ -582,10 +582,10 @@
y1 = best_match->start->y;
y2 = best_match->end->y;
- #if DEBUG_POLYOBJ
+# if DEBUG_POLYOBJ
PrintDebug(" Closest line was %d Y=%1.0f..%1.0f (dist=%1.1f)\n",
best_match->index, y1, y2, best_dist);
- #endif
+# endif
// directly on the line ?
if (fabs(best_dist) < DIST_EPSILON)
@@ -607,10 +607,10 @@
else
sector = best_match->left ? best_match->left->sector : NULL;
- #if DEBUG_POLYOBJ
+# if DEBUG_POLYOBJ
PrintDebug(" Sector %d contains the polyobj.\n",
sector ? sector->index : -1);
- #endif
+# endif
if (! sector)
{
@@ -654,10 +654,10 @@
if (type != PO_SPAWN_TYPE && type != PO_SPAWNCRUSH_TYPE)
continue;
- #if DEBUG_POLYOBJ
+# if DEBUG_POLYOBJ
PrintDebug("Thing %d at (%1.0f,%1.0f) is a polyobj spawner.\n",
i, x, y);
- #endif
+# endif
MarkPolyobjPoint(x, y);
}
@@ -1092,7 +1092,7 @@
VertexAddWallTip(line->end, x1-x2, y1-y2, right, left);
}
- #if DEBUG_WALLTIPS
+# if DEBUG_WALLTIPS
for (i=0; i < num_vertices; i++)
{
vertex_t *vert = vertices[i];
@@ -1107,7 +1107,7 @@
tip->right ? tip->right->index : -1);
}
}
- #endif
+# endif
}
//
@@ -1291,7 +1291,7 @@
}
} while (count > 0);
- #if DEBUG_POLYOBJ
+# if DEBUG_POLYOBJ
PrintDebug("\n");
for (i=0; i < num_linedefs; i++)
{
@@ -1300,7 +1300,7 @@
if (line->polyobj)
PrintDebug("Linedef #%d belongs to a polyobj\n", i);
}
- #endif
+# endif
}
@@ -1537,13 +1537,13 @@
count++;
- #if DEBUG_BSP
+# if DEBUG_BSP
PrintDebug("PUT SEG: %04X Vert %04X->%04X Line %04X %s "
"Angle %04X (%1.1f,%1.1f) -> (%1.1f,%1.1f)\n", seg->index,
UINT16(raw.start), UINT16(raw.end), UINT16(raw.linedef),
seg->side ? "L" : "R", UINT16(raw.angle),
seg->start->x, seg->start->y, seg->end->x, seg->end->y);
- #endif
+# endif
}
if (count >= 32768)
@@ -1592,12 +1592,12 @@
count++;
- #if DEBUG_BSP
+# if DEBUG_BSP
PrintDebug("PUT GL SEG: %04X Line %04X %s Partner %04X "
"(%1.1f,%1.1f) -> (%1.1f,%1.1f)\n", seg->index, UINT16(raw.linedef),
seg->side ? "L" : "R", UINT16(raw.partner),
seg->start->x, seg->start->y, seg->end->x, seg->end->y);
- #endif
+# endif
}
if (count >= 32768)
@@ -1631,10 +1631,10 @@
AppendLevelLump(lump, &raw, sizeof(raw));
- #if DEBUG_BSP
+# if DEBUG_BSP
PrintDebug("PUT SUBSEC %04X First %04X Num %04X\n",
sub->index, UINT16(raw.first), UINT16(raw.num));
- #endif
+# endif
}
if (num_subsecs >= 32768)
@@ -1687,12 +1687,12 @@
AppendLevelLump(lump, &raw, sizeof(raw));
- #if DEBUG_BSP
+# if DEBUG_BSP
PrintDebug("PUT NODE %04X Left %04X Right %04X "
"(%d,%d) -> (%d,%d)\n", node->index, UINT16(raw.left),
UINT16(raw.right), node->x, node->y,
node->x + node->dx, node->y + node->dy);
- #endif
+# endif
}
void PutNodes(char *name, int do_gl, node_t *root)
diff -ur glbsp/node.c glbsp-1.96.hash/node.c
--- glbsp/node.c Mon Dec 17 03:06:17 2001
+++ glbsp-1.96.hash/node.c Tue Jun 4 12:01:38 2002
@@ -491,9 +491,9 @@
int i;
int total = 0;
- #if DEBUG_SUBSEC
+# if DEBUG_SUBSEC
PrintDebug("Subsec: Clockwising %d\n", sub->index);
- #endif
+# endif
// count segs and create an array to manipulate them
for (cur=sub->seg_list; cur; cur=cur->next)
@@ -555,7 +555,7 @@
if (total > 32)
UtilFree(array);
- #if DEBUG_SORTER
+# if DEBUG_SORTER
PrintDebug("Sorted SEGS around (%1.1f,%1.1f)\n", sub->mid_x, sub->mid_y);
for (cur=sub->seg_list; cur; cur=cur->next)
@@ -566,7 +566,7 @@
PrintDebug(" Seg %p: Angle %1.6f (%1.1f,%1.1f) -> (%1.1f,%1.1f)\n",
cur, angle, cur->start->x, cur->start->y, cur->end->x, cur->end->y);
}
- #endif
+# endif
}
//
@@ -593,13 +593,13 @@
"(%d gaps, %d segs)\n", sub->index,
sub->mid_x, sub->mid_y, gaps, total);
- #if DEBUG_SUBSEC
+# if DEBUG_SUBSEC
for (cur=sub->seg_list; cur; cur=cur->next)
{
PrintDebug(" SEG %p (%1.1f,%1.1f) --> (%1.1f,%1.1f)\n", cur,
cur->start->x, cur->start->y, cur->end->x, cur->end->y);
}
- #endif
+# endif
}
}
@@ -658,9 +658,9 @@
{
seg_t *cur;
- #if DEBUG_SUBSEC
+# if DEBUG_SUBSEC
PrintDebug("Subsec: Renumbering %d\n", sub->index);
- #endif
+# endif
sub->seg_count = 0;
@@ -671,10 +671,10 @@
sub->seg_count++;
- #if DEBUG_SUBSEC
+# if DEBUG_SUBSEC
PrintDebug("Subsec: %d: Seg %p Index %d\n", sub->seg_count,
cur, cur->index);
- #endif
+# endif
}
}
@@ -734,9 +734,9 @@
DetermineMiddle(sub);
- #if DEBUG_SUBSEC
+# if DEBUG_SUBSEC
PrintDebug("Subsec: Creating %d\n", sub->index);
- #endif
+# endif
return sub;
}
@@ -804,10 +804,10 @@
if (cur_comms->cancelled)
return GLBSP_E_Cancelled;
- #if DEBUG_BUILDER
+# if DEBUG_BUILDER
PrintDebug("Build: BEGUN @ %d\n", depth);
DebugShowSegs(seg_list);
- #endif
+# endif
// pick best node to use. None indicates convexicity.
best = PickNode(seg_list, depth);
@@ -817,18 +817,18 @@
if (cur_comms->cancelled)
return GLBSP_E_Cancelled;
- #if DEBUG_BUILDER
+# if DEBUG_BUILDER
PrintDebug("Build: CONVEX\n");
- #endif
+# endif
*S = CreateSubsec(seg_list);
return GLBSP_E_OK;
}
- #if DEBUG_BUILDER
+# if DEBUG_BUILDER
PrintDebug("Build: PARTITION %p (%1.0f,%1.0f) -> (%1.0f,%1.0f)\n",
best, best->start->x, best->start->y, best->end->x, best->end->y);
- #endif
+# endif
// create left and right super blocks
lefts = (superblock_t *) NewSuperBlock();
@@ -879,9 +879,9 @@
FindLimits(lefts, &node->l.bounds);
FindLimits(rights, &node->r.bounds);
- #if DEBUG_BUILDER
+# if DEBUG_BUILDER
PrintDebug("Build: Going LEFT\n");
- #endif
+# endif
ret = BuildNodes(lefts, &node->l.node, &node->l.subsec, depth+1);
FreeSuper(lefts);
@@ -892,16 +892,16 @@
return ret;
}
- #if DEBUG_BUILDER
+# if DEBUG_BUILDER
PrintDebug("Build: Going RIGHT\n");
- #endif
+# endif
ret = BuildNodes(rights, &node->r.node, &node->r.subsec, depth+1);
FreeSuper(rights);
- #if DEBUG_BUILDER
+# if DEBUG_BUILDER
PrintDebug("Build: DONE\n");
- #endif
+# endif
return ret;
}
@@ -935,9 +935,9 @@
seg_t *new_head = NULL;
seg_t *new_tail = NULL;
- #if DEBUG_SUBSEC
+# if DEBUG_SUBSEC
PrintDebug("Subsec: Normalising %d\n", sub->index);
- #endif
+# endif
while (sub->seg_list)
{
@@ -962,9 +962,9 @@
}
else
{
- #if DEBUG_SUBSEC
+# if DEBUG_SUBSEC
PrintDebug("Subsec: Removing miniseg %p\n", cur);
- #endif
+# endif
// set index to a really high value, so that SortSegs() will
// move all the minisegs to the top of the seg array.
@@ -1013,9 +1013,9 @@
int real_total = 0;
int degen_total = 0;
- #if DEBUG_SUBSEC
+# if DEBUG_SUBSEC
PrintDebug("Subsec: Rounding off %d\n", sub->index);
- #endif
+# endif
// do an initial pass, just counting the degenerates
for (cur=sub->seg_list; cur; cur=cur->next)
@@ -1044,9 +1044,9 @@
real_total++;
}
- #if DEBUG_SUBSEC
+# if DEBUG_SUBSEC
PrintDebug("Subsec: degen=%d real=%d\n", degen_total, real_total);
- #endif
+# endif
// handle the (hopefully rare) case where all of the real segs
// became degenerate.
@@ -1056,21 +1056,21 @@
InternalError("Subsector %d rounded off with NO real segs",
sub->index);
- #if DEBUG_SUBSEC
+# if DEBUG_SUBSEC
PrintDebug("Degenerate before: (%1.2f,%1.2f) -> (%1.2f,%1.2f)\n",
last_real_degen->start->x, last_real_degen->start->y,
last_real_degen->end->x, last_real_degen->end->y);
- #endif
+# endif
// create a new vertex for this baby
last_real_degen->end = NewVertexDegenerate(last_real_degen->start,
last_real_degen->end);
- #if DEBUG_SUBSEC
+# if DEBUG_SUBSEC
PrintDebug("Degenerate after: (%d,%d) -> (%d,%d)\n",
(int)last_real_degen->start->x, (int)last_real_degen->start->y,
(int)last_real_degen->end->x, (int)last_real_degen->end->y);
- #endif
+# endif
last_real_degen->degenerate = 0;
}
@@ -1098,9 +1098,9 @@
}
else
{
- #if DEBUG_SUBSEC
+# if DEBUG_SUBSEC
PrintDebug("Subsec: Removing degenerate %p\n", cur);
- #endif
+# endif
// set index to a really high value, so that SortSegs() will
// move all the minisegs to the top of the seg array.
diff -ur glbsp/reject.c glbsp-1.96.hash/reject.c
--- glbsp/reject.c Mon Dec 17 03:06:17 2001
+++ glbsp-1.96.hash/reject.c Tue Jun 4 12:01:38 2002
@@ -206,9 +206,9 @@
CreateReject(matrix);
- #if DEBUG_REJECT
+# if DEBUG_REJECT
CountGroups();
- #endif
+# endif
lump = CreateLevelLump("REJECT");
diff -ur glbsp/seg.c glbsp-1.96.hash/seg.c
--- glbsp/seg.c Mon Dec 17 03:06:17 2001
+++ glbsp-1.96.hash/seg.c Tue Jun 4 12:01:38 2002
@@ -185,13 +185,13 @@
seg_t *new_seg;
vertex_t *new_vert;
- #if DEBUG_SPLIT
+# if DEBUG_SPLIT
if (old_seg->linedef)
PrintDebug("Splitting Linedef %d (%p) at (%1.1f,%1.1f)\n",
old_seg->linedef->index, old_seg, x, y);
else
PrintDebug("Splitting Miniseg %p at (%1.1f,%1.1f)\n", old_seg, x, y);
- #endif
+# endif
// update superblock, if needed
if (old_seg->block)
@@ -210,18 +210,18 @@
new_seg->start = new_vert;
RecomputeSeg(new_seg);
- #if DEBUG_SPLIT
+# if DEBUG_SPLIT
PrintDebug("Splitting Vertex is %04X at (%1.1f,%1.1f)\n",
new_vert->index, new_vert->x, new_vert->y);
- #endif
+# endif
// handle partners
if (old_seg->partner)
{
- #if DEBUG_SPLIT
+# if DEBUG_SPLIT
PrintDebug("Splitting Partner %p\n", old_seg->partner);
- #endif
+# endif
// update superblock, if needed
if (old_seg->partner->block)
@@ -392,13 +392,13 @@
return FALSE;
}
- #define ADD_LEFT() \
+# define ADD_LEFT() \
do { \
if (check->linedef) info->real_left += 1; \
else info->mini_left += 1; \
} while (0)
- #define ADD_RIGHT() \
+# define ADD_RIGHT() \
do { \
if (check->linedef) info->real_right += 1; \
else info->mini_right += 1; \
@@ -578,11 +578,11 @@
// make sure there is at least one real seg on each side
if (!info.real_left || !info.real_right)
{
- #if DEBUG_PICKNODE
+# if DEBUG_PICKNODE
PrintDebug("Eval : No real segs on %s%sside\n",
info.real_left ? "" : "left ",
info.real_right ? "" : "right ");
- #endif
+# endif
return -1;
}
@@ -602,12 +602,12 @@
if (part->pdx != 0 && part->pdy != 0)
info.cost += 25;
- #if DEBUG_PICKNODE
+# if DEBUG_PICKNODE
PrintDebug("Eval %p: splits=%d iffy=%d near=%d left=%d+%d right=%d+%d "
"cost=%d.%02d\n", part, info.splits, info.iffy, info.near_miss,
info.real_left, info.mini_left, info.real_right, info.mini_right,
info.cost / 100, info.cost % 100);
- #endif
+# endif
return info.cost;
}
@@ -629,12 +629,12 @@
if (cur_comms->cancelled)
return FALSE;
- #if DEBUG_PICKNODE
+# if DEBUG_PICKNODE
PrintDebug("PickNode: %sSEG %p sector=%d (%1.1f,%1.1f) -> (%1.1f,%1.1f)\n",
part->linedef ? "" : "MINI", part,
part->sector ? part->sector->index : -1,
part->start->x, part->start->y, part->end->x, part->end->y);
- #endif
+# endif
// something for the user to look at
(*progress) += 1;
@@ -691,9 +691,9 @@
int progress=0;
int prog_step=1<<24;
- #if DEBUG_PICKNODE
+# if DEBUG_PICKNODE
PrintDebug("PickNode: BEGUN\n");
- #endif
+# endif
// compute info for showing progress
if (depth <= 3)
@@ -720,7 +720,7 @@
return NULL;
}
- #if DEBUG_PICKNODE
+# if DEBUG_PICKNODE
if (! best)
{
PrintDebug("PickNode: NO BEST FOUND !\n");
@@ -731,7 +731,7 @@
best_cost / 100, best_cost % 100, best->start->x, best->start->y,
best->end->x, best->end->y);
}
- #endif
+# endif
// all finished, return best Seg
return best;
@@ -931,7 +931,7 @@
intersection_t *cur, *next;
seg_t *seg, *buddy;
- #if DEBUG_CUTLIST
+# if DEBUG_CUTLIST
PrintDebug("CUT LIST:\n");
for (cur=cut_list; cur; cur=cur->next)
{
@@ -943,7 +943,7 @@
cur->r.left ? cur->r.left->index : -1,
cur->r.right ? cur->r.right->index : -1);
}
- #endif
+# endif
// scan the intersection list...
@@ -1047,7 +1047,7 @@
AddSegToSuper(right_list, seg);
AddSegToSuper(left_list, buddy);
- #if DEBUG_CUTLIST
+# if DEBUG_CUTLIST
PrintDebug("AddMiniseg: %p RIGHT sector %d (%1.1f,%1.1f) -> (%1.1f,%1.1f)\n",
seg, seg->sector ? seg->sector->index : -1,
seg->start->x, seg->start->y, seg->end->x, seg->end->y);
@@ -1055,7 +1055,7 @@
PrintDebug("AddMiniseg: %p LEFT sector %d (%1.1f,%1.1f) -> (%1.1f,%1.1f)\n",
buddy, buddy->sector ? buddy->sector->index : -1,
buddy->start->x, buddy->start->y, buddy->end->x, buddy->end->y);
- #endif
+# endif
}
// free intersection structures into quick-alloc list
diff -ur glbsp/wad.c glbsp-1.96.hash/wad.c
--- glbsp/wad.c Mon Dec 17 03:06:17 2001
+++ glbsp-1.96.hash/wad.c Tue Jun 4 12:01:38 2002
@@ -305,9 +305,9 @@
lump->start = UINT32(entry.start);
lump->length = UINT32(entry.length);
- #if DEBUG_DIR
+# if DEBUG_DIR
PrintDebug("Read dir... %s\n", lump->name);
- #endif
+# endif
// link it in
lump->next = NULL;
@@ -341,9 +341,9 @@
if (i != 4)
continue;
- #if DEBUG_DIR
+# if DEBUG_DIR
PrintDebug("Found level name: %s\n", L->name);
- #endif
+# endif
// check for invalid name and duplicate levels
if (strlen(L->name) > 5)
@@ -365,9 +365,9 @@
// ignore previous GL lump info
if (CheckGLLumpName(lump->name))
{
- #if DEBUG_DIR
+# if DEBUG_DIR
PrintDebug("Discarding previous GL info: %s\n", lump->name);
- #endif
+# endif
FreeLump(lump);
wad.num_entries--;
@@ -394,9 +394,9 @@
lump->flags |= LUMP_IS_LEVEL;
wad.current_level = lump;
- #if DEBUG_DIR
+# if DEBUG_DIR
PrintDebug("Process dir... %s :\n", lump->name);
- #endif
+# endif
// link it in
lump->next = NULL;
@@ -430,9 +430,9 @@
return;
}
- #if DEBUG_DIR
+# if DEBUG_DIR
PrintDebug("Process dir... |--- %s\n", lump->name);
- #endif
+# endif
// mark it to be loaded
lump->flags |= LUMP_READ_ME;
@@ -455,9 +455,9 @@
// --- ORDINARY LUMPS ---
- #if DEBUG_DIR
+# if DEBUG_DIR
PrintDebug("Process dir... %s\n", lump->name);
- #endif
+# endif
if (CheckLevelLumpName(lump->name))
PrintWarn("Level lump `%s' found outside any level\n", lump->name);
@@ -524,9 +524,9 @@
DisplaySetBar(1, cur_file_pos);
DisplayTicker();
- #if DEBUG_LUMP
+# if DEBUG_LUMP
PrintDebug("Reading... %s (%d)\n", lump->name, lump->length);
- #endif
+# endif
if (lump->length == 0)
return;
@@ -794,12 +794,12 @@
DisplaySetBar(1, cur_file_pos);
DisplayTicker();
- #if DEBUG_LUMP
+# if DEBUG_LUMP
if (lump->flags & LUMP_COPY_ME)
PrintDebug("Copying... %s (%d)\n", lump->name, lump->length);
else
PrintDebug("Writing... %s (%d)\n", lump->name, lump->length);
- #endif
+# endif
if (ftell(out_file) != lump->new_start)
PrintWarn("Consistency failure writing %s (%08X, %08X\n",
@@ -924,12 +924,12 @@
WriteDirEntry(cur);
count++;
- #if DEBUG_DIR
+# if DEBUG_DIR
if (cur->flags & (LUMP_IS_LEVEL | LUMP_IS_GL_LEVEL))
PrintDebug("Write dir... %s\n", cur->name);
else
PrintDebug("Write dir... %s :\n", cur->name);
- #endif
+# endif
if (cur->flags & LUMP_IS_LEVEL)
{
@@ -938,9 +938,9 @@
if (cur->flags & LUMP_IGNORE_ME)
continue;
- #if DEBUG_DIR
+# if DEBUG_DIR
PrintDebug("Write dir... |--- %s\n", L->name);
- #endif
+# endif
WriteDirEntry(L);
count++;
@@ -954,9 +954,9 @@
if (cur->flags & LUMP_IGNORE_ME)
continue;
- #if DEBUG_DIR
+# if DEBUG_DIR
PrintDebug("Write dir... |--- %s\n", L->name);
- #endif
+# endif
WriteDirEntry(L);
count++;
@@ -1023,9 +1023,9 @@
{
lump_t *cur;
- #if DEBUG_DIR
+# if DEBUG_DIR
PrintDebug("Create Lump... %s\n", name);
- #endif
+# endif
// already exists ?
for (cur=wad.current_level->level_list; cur; cur=cur->next)
@@ -1070,9 +1070,9 @@
lump_t *cur;
lump_t *gl_level;
- #if DEBUG_DIR
+# if DEBUG_DIR
PrintDebug("Create GL Lump... %s\n", name);
- #endif
+# endif
// create GL level marker if necessary
if (! wad.current_level->level_buddy)
--
André Majorel <URL:http://www.teaser.fr/~amajorel/>
std::disclaimer ("Not speaking for my employer");
|
|
From: Jussi P. <jpa...@cc...> - 2002-06-04 08:43:59
|
Hi
I was playing around with glBSP on a few different Unices and had some
problems.
Compaq Tru64 UNIX 4.0G
Compilation fails with the following:
In file included from ../blockmap.h:25,
from ../blockmap.c:32:
../level.h:335: parse error before `->'
In file included from ../blockmap.c:35:
../seg.h:93: parse error before `*'
../seg.h:93: stray '\' in program
../seg.h:97: stray '\' in program
This happens with gcc 2.95.3. Strangely it works with Tru64 UNIX 5.1A.
IRIX 6.5
Compiles ok but fails when run:
pyramid:~/glbsp/cmdline> glbsp eternall.wad -o tmpp.wad
*** GL BSP Node Builder. 1.96 (C) 2001 Andrew Apted. ***
*** Based on BSP 2.3 (C) 1998 Colin Reed, Lee Killough ***
Opened PWAD file : eternall.wad
Reading -234487808 dir entries at 0x5C168A01
Warning: Read directory count consistency failure (0,-234487808)
Error: No levels found in wad !
Maybe a bug with the big/little endian code?
These are not serious problems (I have no intention of really using glBSP
on these platforms ;-)), but I figured you'd might like to know this. If
you want to ask further questions on this subject, please email me
directly, as I don't subscribe to this mailing list.
--
Jussi Pakkanen
|
