You really should write a more concise detailed changelog for all the betas. I have no idea what 'added ajimbo's csg code' means for me... how does it change CSG... If you were to explain how you've modified the p15 tools code over the course of the betas people might be more likely to start using the tools (when rad works).
<!--QuoteBegin-Olmy+Oct 20 2004, 12:28 PM--></div><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>QUOTE</b> (Olmy @ Oct 20 2004, 12:28 PM)</td></tr><tr><td id='QUOTE'><!--QuoteEBegin--> Yeah why null faces that will be cut out by bsp anyway? <!--QuoteEnd--> </td></tr></table><div class='postcolor'> <!--QuoteEEnd--> Efficiency, my dear. It's too easy to create everything with null and then add proper textures after. That way, everything that can be nulled, is.
I have been neglecting the code for the past week, due to all these asignments i have been given, how ever i hope to have a working build of ZHLT 3.0 out before hl2, so thats about 2 1/2 weeks
ah, I was about to ask when the non-beta version will be out... but now I see
Please hurry... my compile on my map atm is over an hour long at the MINIMUM settings (fast vis, no opaque, no bounce, ect) and that is a pain in the rear to work with when testing random shaz to see what it looks like in game (aka, lighting effects)
<!--QuoteBegin-FragBait0+Oct 22 2004, 01:52 PM--></div><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>QUOTE</b> (FragBait0 @ Oct 22 2004, 01:52 PM)</td></tr><tr><td id='QUOTE'><!--QuoteEBegin--> 2. Why do you expect ZHLT 3 to fix it? <!--QuoteEnd--> </td></tr></table><div class='postcolor'> <!--QuoteEEnd--> Read any of his posts, it explains a lot.
Anyone with some free time care to try to introduce the changes in that file in the thread linked to in the previous post one at a time to see what causes the problems? Post any results here or email to amckern.
lol my name i definatly not ajimbo it Anders Jenbo or short AJenbo
any way, adding bevel instead would aktualy make sence as the colisions isn't striped and that way you would be able to get corect colision with out sticky eges, so use bevel instead of null to optimise you maps.
the thing that i changed for bsp is that it devides fited and non fited textures by the same value (240 by default)
If your going to send me anything please put zhlt in the subject, or message, as my filters catch that an put it in my zhlt folder, if you dont, it will most liley get removed
I personaly will take a look at the code, and see what has changed
<!--QuoteBegin-Reve+Oct 22 2004, 09:04 AM--></div><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>QUOTE</b> (Reve @ Oct 22 2004, 09:04 AM)</td></tr><tr><td id='QUOTE'><!--QuoteEBegin--> FragBait0: RAD after p13 is horrendously slow.
amckern: Have a reply from XP-Cagey, see <a href='http://www.unknownworlds.com/forums/index.php?showtopic=21248&st=555' target='_blank'>here</a>.
Reve <!--QuoteEnd--></td></tr></table><div class='postcolor'><!--QuoteEEnd--> that answers your question when I looked at the compile logs...
it was indeed the RAD... meh, takes fo-eva!
btw- any progress updates us non-coders can understand ? <!--emo&:p--><img src='http://www.unknownworlds.com/forums/html//emoticons/tounge.gif' border='0' style='vertical-align:middle' alt='tounge.gif' /><!--endemo-->
whats with rad taking forever to compile huge maps? i can do rad on my
athlon 2400 512 meg ram
in like 15 minutes on complex maps that take up 70% of the grid in hammer.
i use ZHLT 2.5.3 Custom Build 1.7, xp-cageys dont work right, when i compile a map, rad gives an error "no light entities found in the map, you dont want to run around in pitch dark do you?"
yeah <a href='http://www.zhlt.tk' target='_blank'>http://www.zhlt.tk</a> for those of you that make typos trying to put all those acro's into a url, such as AMMAHLS - "Amckerns Maps Mods And Half Life Stuff"
please pimp zhlt.tk as it needs at least 25 hits a month for it to stay active, and the .tk will move with the download, so no need to post a new url when the file is updated
I put the beta HLRAD through a profiler and I've attached the results (zipped .rtf file).
The profile was done on a simple map (a little smaller then your average co map) using no HLRAD switches and a debug .exe. I had to use a simple map because the more complex ones took for god damn ever (it takes about 60 times longer for the map to compile with the profiler).
The results don't show any glaring "optimize me here" results, but there are some general optimizations that the tools could probably benefit from (standard stuff). I admit I haven't had a chance to study the results yet, but it might be interesting to put the p13 source through the profiler (if the code still exists) to see if there are any glaring differences.
Edit: I should point out that about 92% of the "% in Method" was spent on WaitForSingleObject() (which makes sense if you think about it). This is important because when you are looking at the below chart (a subset of the attached file), 2.5% is a huge chunk of the 8% not attributed to WaitForSingleObject().
<!--c1--></div><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>CODE</b> </td></tr><tr><td id='CODE'><!--ec1-->Method Name % in Method % with Children Called Average ------------------------------------------------------------------------------- TestLine_r 2.5 2.5 687,143,438 0.3 PointInLeaf 2.4 2.4 112,108,803 1.8 HuntForWorld 0.4 3.3 561,871 64.7 0.5<!--c2--></td></tr></table><div class='postcolor'><!--ec2-->
r = TestLine_r(tnode->children[side], start, mid); // We are forced to really recurse.
if (r != CONTENTS_EMPTY) return r;
node = tnode->children[!side]; // Non-recurse recurse with tnode->children[!side]. VectorCopy(mid, start); // start changed so we need to "pass" it. } } } <!--c2--></td></tr></table><div class='postcolor'><!--ec2--> Before TestLine_r() was purely recursive, now it is an iterative/recursive hybrid and it pays off in performance. This effects BuildFacelights().
do { node = &g_dnodes[nodenum]; plane = &g_dplanes[node->planenum];
dist = DotProduct(point, plane->normal);
if (dist >= plane->dist) { nodenum = node->children[0]; } else { nodenum = node->children[1]; } } while (nodenum >= 0);
return &g_dleafs[-nodenum - 1]; } <!--c2--></td></tr></table><div class='postcolor'><!--ec2--> Before PointInLeaf() was doing an unnecessary comparison and floating point subtraction. This usually wouldn't make too much difference except this function gets called a couple hundred million times and this is something the compiler will not optimize.
<b>getPlaneFromFace():</b> qradutil.cpp <!--c1--></div><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>CODE</b> </td></tr><tr><td id='CODE'><!--ec1--> const dplane_t* getPlaneFromFace(const dface_t* const face) { if (!face) { Error("getPlaneFromFace() face was NULL\n"); }
if (!face->side) { return &g_dplanes[face->planenum]; } else { return &backplanes[face->planenum]; } } <!--c2--></td></tr></table><div class='postcolor'><!--ec2--> The profiler revealed that !face->side is far more common then face->side so I swapped the two (simple optimization rule: the most probable branch should come first). The compiler can handle the ! and again, this is only significant because of the number of times the function is called. (And even then it isn't that significant.)
if (!face->side) { return &g_dplanes[face->planenum]; } else { return &backplanes[face->planenum]; } } <!--c2--></td></tr></table><div class='postcolor'><!--ec2--> Same deal as above.
<b>Results:</b>
<b>Small Test Map</b> Before: 65.11 s After: 60.89 s
<b>Medium Test Map</b> Before: 188.64 s After: 178.22 s
<b>Notes:</b> I used MD5 checksums to insure that the code changes did not effect the HLRAD output. These changes yielded about a 5% speed increase on my test maps, this isn't too significant but not bad for an hours work. The above times are accurate to within a second.
That's all, maybe I'll look at some more complicated functions tomorrow, Nem
Nem you're a star! <!--emo&:)--><img src='http://www.unknownworlds.com/forums/html//emoticons/smile-fix.gif' border='0' style='vertical-align:middle' alt='smile-fix.gif' /><!--endemo-->
Um, removing this floating point subtraction doesn't affect hlrad building maps made in QuArK, which uses floating points, does it? <!--emo&???--><img src='http://www.unknownworlds.com/forums/html//emoticons/confused-fix.gif' border='0' style='vertical-align:middle' alt='confused-fix.gif' /><!--endemo-->
<!--QuoteBegin--></div><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>QUOTE</b> </td></tr><tr><td id='QUOTE'><!--QuoteEBegin--> unnecessary comparison and floating point subtraction<!--QuoteEnd--></td></tr></table><div class='postcolor'><!--QuoteEEnd--> That kinda makes me think that there just <i>was no point</i> to that piece of code. Maybe not though.
Anyways some speed ups in RAD are always a good thing so w00t for Nem. It's also got me tinkering with a profiler on opt_entdata...whoa its awesome stuff...
It's both a good and a bad thing that RAD is optimized quite a bit already - bad because i can't look forward to it getting a huge amount faster but good because it hasn't been even slower for all eternity.
Do a lot of BEVELed surfaces together end up using less clipnodes?
amckern, looking at your <a href='http://downloads.ammahls.com/zhlt/beta/changelog.txt' target='_blank'>changelog for zhlt</a> it says that "Inverse shadows, when using entity light flags" is fixed. Does that mean that the only major issue on my <a href='http://www.zhlt.info' target='_blank'>list of problems with p15.5</a> that still needs fixing is the speed of RAD?
I think it would be nice to release a beta 4 with all the safe stuff in it, like this entity lighting fix, and perhaps the faster entity shadow code from hullu and this new stuff from nem. Then concentrate on the last fixes before 3.0 final (which we ought to work out a release plan for - i.e. lots of mention on different gaming/mapping websites).
Nem, had a chance to play with the p10 mathutil code from XP-Cagey (see links above) and see what's causing the really major speed issue in p14? If we get this fixed, we're almost set for release <!--emo&:)--><img src='http://www.unknownworlds.com/forums/html//emoticons/smile-fix.gif' border='0' style='vertical-align:middle' alt='smile-fix.gif' /><!--endemo-->
<!--QuoteBegin--></div><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>QUOTE</b> </td></tr><tr><td id='QUOTE'><!--QuoteEBegin-->That kinda makes me think that there just was no point to that piece of code. Maybe not though.<!--QuoteEnd--></td></tr></table><div class='postcolor'><!--QuoteEEnd-->
The changes don't change the outcome; they change how you get to the outcome. It's like simplifying a math equation, same result, fewer operations.
<!--QuoteBegin--></div><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>QUOTE</b> </td></tr><tr><td id='QUOTE'><!--QuoteEBegin-->Nem, had a chance to play with the p10 mathutil code from XP-Cagey (see links above) and see what's causing the really major speed issue in p14? If we get this fixed, we're almost set for release.<!--QuoteEnd--></td></tr></table><div class='postcolor'><!--QuoteEEnd-->
That's one thing I'd love to put the profiler through, it should make the problem obvious. I'll see if I can spot anything though.
Ok, I'm a little confused here. I downloaded the p10 mathutil.cpp and it is way different then the mathutil.cpp included in the beta's source. In fact, the mathutil.cpp included in the beta's source seems to be from MHLT 1.7. Am I missing the p15 mathutil.cpp?
BTW the HLRAD_FASTMATH shaved another 3 seconds of the compile time for my small test map. I didn't notice a visual change but my MD5 test shows something is different. Then again it could just be my hacking to get HLRAD_FASTMATH to compile (am I looking at entirely old code here?)
Thers no release date thow we are working on a plan schedual. we want this thing sone just as mutch as you do <!--emo&:)--><img src='http://www.unknownworlds.com/forums/html//emoticons/smile-fix.gif' border='0' style='vertical-align:middle' alt='smile-fix.gif' /><!--endemo-->
Sorry about that, i was trying to see the difrence betwen the files, and did a test build of the beta 4, with the 1.7 file
i'll fix it up tonight when i get home SORRY, and thanks for picking it up mate
Relase date i hope will be some time before hl2, so that gives us just over 19 days, even though alot of people will be still working on there hl1 mod maps, untill they get converted to hl2 mods
-----------------------------------
AJ, can you please send me the unbuged beta 2005 files?
I have been trying to convert the sln's to 2005, but am having issues with defunct files in platform sdk xp sp2 (or what platform sdk are you useing with beta 2005)
<!--QuoteBegin--></div><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>QUOTE</b> </td></tr><tr><td id='QUOTE'><!--QuoteEBegin-->for Face 3723 (texture rClfBox2) at (-1323.973 -220.147 -1042.000) (-1277.798 -161.046 -1042.000) (-1274.000 -164.000 -1042.000) (-1276.954 -167.798 -1042.000) (-1320.046 -223.202 -1042.000) Error: Bad surface extents (2 x 17)<!--QuoteEnd--></td></tr></table><div class='postcolor'><!--QuoteEEnd-->
When using Zoners Tools (1.7p13) i dont get this error...
i checked the brush at the location and there was actually no problems with it, i sat there for almost an hour re-makign the brush and re-trying to compile till i finally tried the old tools... any tracking/work you want me to do? - any more info you need?
*edit* Should I add this to my list of things seriously broken with the p15.5 source code that we're planning to fix for the 3.0 release that's on the front page of zhlt.info? (along with slow rad, messed up shadows, and overbright light_environment). Is there anything else I could add?
I think I've got a map that compiles into an infinite loop.
Who here needs it? I will send on an individual basis. The last edit that made it 'uncompileable' was the placement of the fourth and uppermost layer.
Edit: evidence that it got stuck into an infinite loop? It sucked up memory for about an hour which amounted to 1.3GB, and then on the second attempt it got stuck at 1.6GB. Once it achieved these huge numbers the memory usage ceased increasing and the cpu usage of HLRAD decreased.
Comments
Efficiency, my dear. It's too easy to create everything with null and then add proper textures after. That way, everything that can be nulled, is.
I have been neglecting the code for the past week, due to all these asignments i have been given, how ever i hope to have a working build of ZHLT 3.0 out before hl2, so thats about 2 1/2 weeks
Please hurry... my compile on my map atm is over an hour long at the MINIMUM settings (fast vis, no opaque, no bounce, ect) and that is a pain in the rear to work with when testing random shaz to see what it looks like in game (aka, lighting effects)
But you guys are truckin along! Good luck!
2. Why do you expect ZHLT 3 to fix it?
Read any of his posts, it explains a lot.
amckern: Have a reply from XP-Cagey, see <a href='http://www.unknownworlds.com/forums/index.php?showtopic=21248&st=555' target='_blank'>here</a>.
Reve
any way, adding bevel instead would aktualy make sence as the colisions isn't striped and that way you would be able to get corect colision with out sticky eges, so use bevel instead of null to optimise you maps.
the thing that i changed for bsp is that it devides fited and non fited textures by the same value (240 by default)
If your going to send me anything please put zhlt in the subject, or message, as my filters catch that an put it in my zhlt folder, if you dont, it will most liley get removed
I personaly will take a look at the code, and see what has changed
amckern
amckern: Have a reply from XP-Cagey, see <a href='http://www.unknownworlds.com/forums/index.php?showtopic=21248&st=555' target='_blank'>here</a>.
Reve <!--QuoteEnd--></td></tr></table><div class='postcolor'><!--QuoteEEnd-->
that answers your question when I looked at the compile logs...
it was indeed the RAD... meh, takes fo-eva!
btw- any progress updates us non-coders can understand ? <!--emo&:p--><img src='http://www.unknownworlds.com/forums/html//emoticons/tounge.gif' border='0' style='vertical-align:middle' alt='tounge.gif' /><!--endemo-->
athlon 2400
512 meg ram
in like 15 minutes on complex maps that take up 70% of the grid in hammer.
i use ZHLT 2.5.3 Custom Build 1.7, xp-cageys dont work right, when i compile a map, rad gives an error "no light entities found in the map, you dont want to run around in pitch dark do you?"
lol kills maps that have almost all texlights.
please pimp zhlt.tk as it needs at least 25 hits a month for it to stay active, and the .tk will move with the download, so no need to post a new url when the file is updated
The profile was done on a simple map (a little smaller then your average co map) using no HLRAD switches and a debug .exe. I had to use a simple map because the more complex ones took for god damn ever (it takes about 60 times longer for the map to compile with the profiler).
The results don't show any glaring "optimize me here" results, but there are some general optimizations that the tools could probably benefit from (standard stuff). I admit I haven't had a chance to study the results yet, but it might be interesting to put the p13 source through the profiler (if the code still exists) to see if there are any glaring differences.
Edit:
I should point out that about 92% of the "% in Method" was spent on WaitForSingleObject() (which makes sense if you think about it). This is important because when you are looking at the below chart (a subset of the attached file), 2.5% is a huge chunk of the 8% not attributed to WaitForSingleObject().
<!--c1--></div><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>CODE</b> </td></tr><tr><td id='CODE'><!--ec1-->Method Name % in Method % with Children Called Average
-------------------------------------------------------------------------------
TestLine_r 2.5 2.5 687,143,438 0.3
PointInLeaf 2.4 2.4 112,108,803 1.8
HuntForWorld 0.4 3.3 561,871 64.7 0.5<!--c2--></td></tr></table><div class='postcolor'><!--ec2-->
Nem
<b>TestLine_r():</b> trace.cpp
<!--c1--></div><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>CODE</b> </td></tr><tr><td id='CODE'><!--ec1-->
int TestLine_r(int node, const vec3_t start_c, const vec3_t stop)
{
vec3_t start;
VectorCopy(start_c, start);
while (1)
{
tnode_t* tnode;
float front, back;
if ( node == CONTENTS_SOLID
|| node == CONTENTS_SKY
// || node == CONTENTS_NULL
)
return node;
if (node < 0)
return CONTENTS_EMPTY;
tnode = &tnodes[node];
switch (tnode->type)
{
case plane_x:
front = start[0] - tnode->dist;
back = stop[0] - tnode->dist;
break;
case plane_y:
front = start[1] - tnode->dist;
back = stop[1] - tnode->dist;
break;
case plane_z:
front = start[2] - tnode->dist;
back = stop[2] - tnode->dist;
break;
default:
front = DotProduct(start, tnode->normal) - tnode->dist;
back = DotProduct(stop, tnode->normal) - tnode->dist;
break;
}
if (front >= -ON_EPSILON && back >= -ON_EPSILON)
{
node = tnode->children[0]; // Non-recurse recurse with tnode->children[0].;)
}
else if (front < ON_EPSILON && back < ON_EPSILON)
{
node = tnode->children[1]; // Non-recurse recurse with tnode->children[1].
}
else
{
vec3_t mid;
float frac;
int side;
int r;
side = front < 0;
frac = front / (front - back);
mid[0] = start[0] + (stop[0] - start[0]) * frac;
mid[1] = start[1] + (stop[1] - start[1]) * frac;
mid[2] = start[2] + (stop[2] - start[2]) * frac;
r = TestLine_r(tnode->children[side], start, mid); // We are forced to really recurse.
if (r != CONTENTS_EMPTY)
return r;
node = tnode->children[!side]; // Non-recurse recurse with tnode->children[!side].
VectorCopy(mid, start); // start changed so we need to "pass" it.
}
}
}
<!--c2--></td></tr></table><div class='postcolor'><!--ec2-->
Before TestLine_r() was purely recursive, now it is an iterative/recursive hybrid and it pays off in performance. This effects BuildFacelights().
<b>PointInLeaf():</b> qradutil.cpp
<!--c1--></div><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>CODE</b> </td></tr><tr><td id='CODE'><!--ec1-->
dleaf_t* PointInLeaf(const vec3_t point)
{
int nodenum;
vec_t dist;
dnode_t* node;
dplane_t* plane;
nodenum = 0;
do
{
node = &g_dnodes[nodenum];
plane = &g_dplanes[node->planenum];
dist = DotProduct(point, plane->normal);
if (dist >= plane->dist)
{
nodenum = node->children[0];
}
else
{
nodenum = node->children[1];
}
}
while (nodenum >= 0);
return &g_dleafs[-nodenum - 1];
}
<!--c2--></td></tr></table><div class='postcolor'><!--ec2-->
Before PointInLeaf() was doing an unnecessary comparison and floating point subtraction. This usually wouldn't make too much difference except this function gets called a couple hundred million times and this is something the compiler will not optimize.
<b>getPlaneFromFace():</b> qradutil.cpp
<!--c1--></div><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>CODE</b> </td></tr><tr><td id='CODE'><!--ec1-->
const dplane_t* getPlaneFromFace(const dface_t* const face)
{
if (!face)
{
Error("getPlaneFromFace() face was NULL\n");
}
if (!face->side)
{
return &g_dplanes[face->planenum];
}
else
{
return &backplanes[face->planenum];
}
}
<!--c2--></td></tr></table><div class='postcolor'><!--ec2-->
The profiler revealed that !face->side is far more common then face->side so I swapped the two (simple optimization rule: the most probable branch should come first). The compiler can handle the ! and again, this is only significant because of the number of times the function is called. (And even then it isn't that significant.)
<b>getPlaneFromFaceNumber():</b> qradutil.cpp
<!--c1--></div><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>CODE</b> </td></tr><tr><td id='CODE'><!--ec1-->
const dplane_t* getPlaneFromFaceNumber(const unsigned int faceNumber)
{
dface_t* face = &g_dfaces[faceNumber];
if (!face->side)
{
return &g_dplanes[face->planenum];
}
else
{
return &backplanes[face->planenum];
}
}
<!--c2--></td></tr></table><div class='postcolor'><!--ec2-->
Same deal as above.
<b>Results:</b>
<b>Small Test Map</b>
Before: 65.11 s
After: 60.89 s
<b>Medium Test Map</b>
Before: 188.64 s
After: 178.22 s
<b>Notes:</b>
I used MD5 checksums to insure that the code changes did not effect the HLRAD output. These changes yielded about a 5% speed increase on my test maps, this isn't too significant but not bad for an hours work. The above times are accurate to within a second.
That's all, maybe I'll look at some more complicated functions tomorrow,
Nem
I'll check though that
Good work Nem
Nem you're a star! <!--emo&:)--><img src='http://www.unknownworlds.com/forums/html//emoticons/smile-fix.gif' border='0' style='vertical-align:middle' alt='smile-fix.gif' /><!--endemo-->
That kinda makes me think that there just <i>was no point</i> to that piece of code.
Maybe not though.
Anyways some speed ups in RAD are always a good thing so w00t for Nem.
It's also got me tinkering with a profiler on opt_entdata...whoa its awesome stuff...
It's both a good and a bad thing that RAD is optimized quite a bit already - bad because i can't look forward to it getting a huge amount faster but good because it hasn't been even slower for all eternity.
Do a lot of BEVELed surfaces together end up using less clipnodes?
I think it would be nice to release a beta 4 with all the safe stuff in it, like this entity lighting fix, and perhaps the faster entity shadow code from hullu and this new stuff from nem. Then concentrate on the last fixes before 3.0 final (which we ought to work out a release plan for - i.e. lots of mention on different gaming/mapping websites).
Nem, had a chance to play with the p10 mathutil code from XP-Cagey (see links above) and see what's causing the really major speed issue in p14? If we get this fixed, we're almost set for release <!--emo&:)--><img src='http://www.unknownworlds.com/forums/html//emoticons/smile-fix.gif' border='0' style='vertical-align:middle' alt='smile-fix.gif' /><!--endemo-->
Maybe not though.<!--QuoteEnd--></td></tr></table><div class='postcolor'><!--QuoteEEnd-->
The changes don't change the outcome; they change how you get to the outcome. It's like simplifying a math equation, same result, fewer operations.
<!--QuoteBegin--></div><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>QUOTE</b> </td></tr><tr><td id='QUOTE'><!--QuoteEBegin-->Nem, had a chance to play with the p10 mathutil code from XP-Cagey (see links above) and see what's causing the really major speed issue in p14? If we get this fixed, we're almost set for release.<!--QuoteEnd--></td></tr></table><div class='postcolor'><!--QuoteEEnd-->
That's one thing I'd love to put the profiler through, it should make the problem obvious. I'll see if I can spot anything though.
Nem
BTW the HLRAD_FASTMATH shaved another 3 seconds of the compile time for my small test map. I didn't notice a visual change but my MD5 test shows something is different. Then again it could just be my hacking to get HLRAD_FASTMATH to compile (am I looking at entirely old code here?)
Nem
but is their a release date set? I'd LOVE to not have to compile overnight (my maps starting to get big.. and opaque entities take a LOT of time)
Sorry about that, i was trying to see the difrence betwen the files, and did a test build of the beta 4, with the 1.7 file
i'll fix it up tonight when i get home SORRY, and thanks for picking it up mate
Relase date i hope will be some time before hl2, so that gives us just over 19 days, even though alot of people will be still working on there hl1 mod maps, untill they get converted to hl2 mods
-----------------------------------
AJ, can you please send me the unbuged beta 2005 files?
I have been trying to convert the sln's to 2005, but am having issues with defunct files in platform sdk xp sp2 (or what platform sdk are you useing with beta 2005)
amckern@yahoo.com
Adam
<!--QuoteBegin--></div><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>QUOTE</b> </td></tr><tr><td id='QUOTE'><!--QuoteEBegin-->for Face 3723 (texture rClfBox2) at
(-1323.973 -220.147 -1042.000) (-1277.798 -161.046 -1042.000) (-1274.000 -164.000 -1042.000) (-1276.954 -167.798 -1042.000) (-1320.046 -223.202 -1042.000)
Error: Bad surface extents (2 x 17)<!--QuoteEnd--></td></tr></table><div class='postcolor'><!--QuoteEEnd-->
When using Zoners Tools (1.7p13) i dont get this error...
i checked the brush at the location and there was actually no problems with it, i sat there for almost an hour re-makign the brush and re-trying to compile till i finally tried the old tools... any tracking/work you want me to do? - any more info you need?
the only stable items at this time are bsp, and vis, and its advisable to upgrade both, if not both, then at least use the vis
*edit* Should I add this to my list of things seriously broken with the p15.5 source code that we're planning to fix for the 3.0 release that's on the front page of zhlt.info? (along with slow rad, messed up shadows, and overbright light_environment). Is there anything else I could add?
Who here needs it? I will send on an individual basis. The last edit that made it 'uncompileable' was the placement of the fourth and uppermost layer.
Edit: evidence that it got stuck into an infinite loop? It sucked up memory for about an hour which amounted to 1.3GB, and then on the second attempt it got stuck at 1.6GB. Once it achieved these huge numbers the memory usage ceased increasing and the cpu usage of HLRAD decreased.
I think the tools are entirely p13