ummm cagey's site is down <!--emo&:(--><img src='http://www.unknownworlds.com/forums/html//emoticons/sad-fix.gif' border='0' style='vertical-align:middle' alt='sad-fix.gif' /><!--endemo-->,what to do <!--emo&???--><img src='http://www.unknownworlds.com/forums/html//emoticons/confused-fix.gif' border='0' style='vertical-align:middle' alt='confused-fix.gif' /><!--endemo-->
And if the bandwidth becomes a problem, you can still move back to Visual Studio 5 without .NET dlls <!--emo&:D--><img src='http://www.unknownworlds.com/forums/html//emoticons/biggrin-fix.gif' border='0' style='vertical-align:middle' alt='biggrin-fix.gif' /><!--endemo--> ... or use an executable packer like UPX.
<!--QuoteBegin-Cloist+Sep 11 2004, 01:25 PM--></div><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>QUOTE</b> (Cloist @ Sep 11 2004, 01:25 PM)</td></tr><tr><td id='QUOTE'><!--QuoteEBegin--> ummm cagey's site is down <!--emo&:(--><img src='http://www.unknownworlds.com/forums/html//emoticons/sad-fix.gif' border='0' style='vertical-align:middle' alt='sad-fix.gif' /><!--endemo-->,what to do <!--emo&???--><img src='http://www.unknownworlds.com/forums/html//emoticons/confused-fix.gif' border='0' style='vertical-align:middle' alt='confused-fix.gif' /><!--endemo--> <!--QuoteEnd--> </td></tr></table><div class='postcolor'> <!--QuoteEEnd--> I'm working on it, should be back up by tomorrow.
p15.5ce1 should be out by the end of the month - i hope, though i am still in need to contact the guy thats doin csg, and see if what he has done effects the rad code
grate a nother vesriosn number <!--emo&:D--><img src='http://www.unknownworlds.com/forums/html//emoticons/biggrin-fix.gif' border='0' style='vertical-align:middle' alt='biggrin-fix.gif' /><!--endemo-->, what is dose it stand for <!--emo&:)--><img src='http://www.unknownworlds.com/forums/html//emoticons/smile-fix.gif' border='0' style='vertical-align:middle' alt='smile-fix.gif' /><!--endemo-->
Its also only a working name, as there are going to be a few people working on the new version, and as such, it should have a proper name
the full version name at this point in time is
ZHLT 1.7.2.5.3.p15.5.ce1
Unless some one can correct me, it sounds right to me
amckern <!--QuoteEnd--> </td></tr></table><div class='postcolor'> <!--QuoteEEnd--> I'd like to interject here -- the reason I added the patch numbers (p2, etc.) was so that if Merl ever updated, people wouldn't be confused by a bump in Merl's numbers and my own. For instance, if Merl made custom 1.8, I'd have released 1.8p15 shortly afterward. If he'd made 2.0, I'd have released 2.0p15. That way people would know that my work up to the 15th patch was in that release.
Since Merl hasn't released an update in years and I'm not developing for the tools any more, there isn't any reason to split off the numbers any further. I actually toyed with simply calling p15 ZHLT 3.0, but decided that it wasn't a good idea to give a flawed build a major revision number.
Since the code is changing hands and Zoner, Merl, and I are all effectively retired from working on it, now would be a good time to make the switch to a saner versioning system. <!--emo&:)--><img src='http://www.unknownworlds.com/forums/html//emoticons/smile-fix.gif' border='0' style='vertical-align:middle' alt='smile-fix.gif' /><!--endemo-->
So I'm all for dropping it once you get a stable build <!--emo&:)--><img src='http://www.unknownworlds.com/forums/html//emoticons/smile-fix.gif' border='0' style='vertical-align:middle' alt='smile-fix.gif' /><!--endemo-->
Thumbs up! I really appreciate all the work that has been put into the tools. Features like transparent shadows, switchable texture lights and unused plane removal even gave the whole engine a push. While you talk about sky problems? What is wrong with the sky? I coded me just another BSP viewer recently and realized sky brushes make it into the map unmodified with all six sides, is that what you talk about?
@Cagey: When I look up your page I get an infinite loop of redirections to the site like this: queriing xp-cagey.com... connecting to xp-cagey.com... queriing xp-cagey.com... connecting to xp-cagey.com... queriing xp-cagey.com... connecting to xp-cagey.com... queriing xp-cagey.com... connecting to xp-cagey.com... ...
<!--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-->In a way yes, but in this case no. A normal CPU has about 8 registers inside the cpu which each can contain up to 32bit of data (four bytes).
It is much faster to access data stored inside the registers than getting loading them from the RAM.
It will take about 20 to 100 times longer acessing data in memmory than acessing data in the registers inside the CPU. But because of the limited amount of registers in the CPU most data and especially arrays must be stored in RAM, but small variables, such as bytes and integers (in newer CPU's even floats) can be stored in registers in the CPU.
The extra for loop doesn't add to the complexity of the algorithm, since the same number of iterations was reached through some spaghetti bitwise opperations.
The whole idea behind my tweak is to cache a byte at the time in the registers, and only load it in from the array in the RAM once every 8 iterations.
Its impossible to explicit declare which variables should be allocated to registers and which should not in M$ visual C++... since it uses an algorithm that figures out which variables are to be allocated into registers manually. (this is not a feature but simply bad coding from microsoft). Anyway, theres a great change that the variables I use will be allocated into registers since they are the only ones alive inside their scopes.
The 0.6% performance improvement I could see in the improvement in compiletime. It isn't much, but a little tweaking here and there makes it all faster in the end.
Another good thing about using two for loops instead of bitwise rotate left operators is that the code is easier to understand. I may have added some code, but I don't think that I've added many more operations.
Its not a revolution, its a tiny tweak B)
------------------ visit www.egir.dk
<!--QuoteEnd--></td></tr></table><div class='postcolor'><!--QuoteEEnd--> <a href='http://countermap.counter-strike.net/ubb/Forum1/HTML/003534.html' target='_blank'>http://countermap.counter-strike.net/ubb/F...TML/003534.html</a> < is the ideas thread at this point in time, as well as the thread your now reading
I think the tools are quite perfect, if the strange clipping holes bug and all the rad problems are fixed, then I'll be happy (I know a lot of people will be happy, too) <!--emo&:p--><img src='http://www.unknownworlds.com/forums/html//emoticons/tounge.gif' border='0' style='vertical-align:middle' alt='tounge.gif' /><!--endemo-->
"sky brushes make it into the map unmodified with all six sides" yep that is what i was talking about, but they also end up douple sided, you can alrady remove the 5 sides by using null or bevel but the douple side is compiler only.
by the way it might be a idear to add gcf support in to the tools using the <a href='http://countermap.counter-strike.net/Nemesis/index.php?c=108#p108' target='_blank'>HLLib.dll</a> by nemesis.
ta talked to egir some weeks ago, about some vis optimising using 2D for initily testing of the vis portals, dont know if he is going to try it.
how is full bright faces (sky or texlight) treated do they get multiple lightmaps like every other suface, couldn't we make it just give them one.
and lastly it seams that steam actualy supports 18x18 light maps so we might be able to increas the subdivide from 240 to 270 if we change the rad to not make a error out of it <a href='http://www.cubed.dk/nobody/stuff/18.png' target='_blank'>324sqrt=18</a>
i think i understand the over bright light_env now
if you use a normal sky brush, with out null, its brighter then with
i dont know if this is part of the opt_planes code, but well have to have a look
I'm also testing the code by Egir, with a few mates in the mapping community, to see if it works, and the results coming back are wondeful
One guy, shaved 1.3 hours of his vis, so it shows a good result
also, the subdived, should be keept the same, as some people, such as ME do not have steam, nor use it - it is also good for those that dont use there net pc's for mapping, and use 1.10 half life, or such, though if its not to much trouble, might inlcude a switch for backways compad
Great...this is all very promising but um...VIS kinda goes a crapload faster when more machines work it...hence netvis. So what would be great is to see a netvis executable with the next version.
Better yet would be to also add the maxdistance stuff in to netvis - even if this part is only run on the server.
Is it also possible that a maxdistance type thingy before leafthread could help take some out beforehand? I don't know anything about the vis algorithms but it can't hurt to throw a few ideas around.
Of course, maxdistance is only any good for large maps or vissing weirdnesses that won't leave in any other manner. *shrug.
<!--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-->and lastly it seams that steam actualy supports 18x18 light maps so we might be able to increas the subdivide from 240 to 270 if we change the rad to not make a error out of it 324sqrt=18<!--QuoteEnd--></td></tr></table><div class='postcolor'><!--QuoteEEnd--> I have to agree with amckern here - make it a switch if you do work this in.
<!--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-->by the way it might be a idear to add gcf support in to the tools using the HLLib.dll by nemesis.<!--QuoteEnd--></td></tr></table><div class='postcolor'><!--QuoteEEnd--> GCF support? For what? Getting textures from WADs stuck in GCFs is all I can think of..mappers need them extracted for hammer anyway...
if you get a map from some on how used textures that you don't have extracted csg will always know where to get the standart textures hammer 4 supports gcf directly so no more having to extract the wads when it comes.
<a href='http://sourceforge.net/projects/cplusplus/' target='_blank'>http://sourceforge.net/projects/cplusplus/</a> I think these are what you may be after. I have no idea what version you need but im trying to find out now.
If i remember correctly it came up a while back (somewhere, damned if i can remember THAT) someone said you need the earlier version 1.xx...
EDIT: Found in the MHLT 1.7 readme: <!--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-->Recommended: (x) CommonC++ 1.4.2+ libraries (for compiling netvis) Available at <a href='http://sourceforge.net/project/?group_id=1523' target='_blank'>http://sourceforge.net/project/?group_id=1523</a><!--QuoteEnd--></td></tr></table><div class='postcolor'><!--QuoteEEnd--> So I'll give that a whirl. Just so you know im trying to compile netvis from MHLT 1.7 so you may or may not have the same results as me one way or another...
EDIT2: Well mostly I got it working... <!--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-->LINK : warning LNK4098: defaultlib "LIBC" conflicts with use of other libs; use /NODEFAULTLIB:library flow.obj : error LNK2001: unresolved external symbol "struct visblocker_t * __cdecl GetVisBlock(char *)" (?GetVisBlock@@YAPAUvisblocker_t@@PAD@Z) Release/netvis.exe : fatal error LNK1120: 1 unresolved externals Error executing link.exe.<!--QuoteEnd--></td></tr></table><div class='postcolor'><!--QuoteEEnd--> Got any ideas? Not knowing what Im doing dosen't help but I'm guessing it can't find this GetVisBlock function anyhere.
Ah I just got rid of the warning by tagging /nodefaultlib:"libc" on the linker(?) command-line..
0.6% faster? Hey, that optimization was a waste of time compared to the sky fix that reduced the compile times by over an hour! But on the other hand this register usage issue is quite dominant in every compiler. Borland's Delphi doesn't do it any better. Considering that two of the eight registers are usually already in use to handle a bit of the program flow (base and stack pointers EBP & ESP) and there are only six left you should really assume tha the compilers try to make the available for the innermost loops of a program, but they don't. In an image resize code I hade a variable for accumulating some pixels in the inner loops and Delphi used RAM for it! So the procedure took ~24 ms. When I used a CPU register (that is even called ACCUMULATOR) it tool only ~9 ms to complete. What we learn from it is: LEARN x86 ASSEMBLER! IT WILL MAKE YOUR CODE AT LEAST TWO TIMES FASTER BY JUST LETTING YOU DECIDE WHERE TO USE REGISTERS INSTEAD OF RAM. Also the good old MMX stuff should be considered. It can process up to eight values at once and only takes one clock cycle for any operation (except for multiply-and-add, which can take up 3 clock cycles). Copy memory with it, shift bytes, calculate vector products, divide/multiply by 2^n... the downside is of course that you can't use it for anything that incorporates floating point numbers.
yeah, i got a freeb source code file from the nvidia devlopersite, that is all machine code (not programable api), that can replace loops of certian types, i'm looking at it, and comparing it with whats the p15.5 source, and going from there
I am still having issues, with why opaue, and lights files other then lights.rad are causing rad to crash on start up - and when i did casting i broke part of csg, so i'm gona go back to the raw code, and start again
--------------------------
Where can i find some info on mmx, and 3dnow (if this is the amd sister of mmx)?
My background is in java, and i'm brining the java princables over to cpp, but also looking at the code, and seeing how i can make it faster
I'd steer clear of 3D-now as although it's in the more recent intel cpu's, it's not in some of the older ones that I could picture a few odd map compilers still using. MMX is in pretty much everything though.
Mmm, my main programming expertise is in Java too, with a smattering of other languages... maybe if I ever get some decent quantity of free time, I'll help have a good look at this code too <!--emo&:)--><img src='http://www.unknownworlds.com/forums/html//emoticons/smile-fix.gif' border='0' style='vertical-align:middle' alt='smile-fix.gif' /><!--endemo-->
I'd like to announce the launch of the ZHLT documentation online, <a href='http://www.zhlt.info' target='_blank'>www.zhlt.info</a>
At the moment, it currently consists of just the documentation I did for XP-Cagey's p14 build, updated for p15, p15.5, and zhlt 3 betas 1 - 3. I will be keeping it updated with changes to ZHLT 3, and plan to add other features (such as links to the different versions of the tools, and links to particularly helpful tutorials). I also welcome any suggestions from the community with regards to the site.
Comments
I'm working on it, should be back up by tomorrow.
I'm working on it, should be back up by tomorrow. <!--QuoteEnd--> </td></tr></table><div class='postcolor'> <!--QuoteEEnd-->
Use <a href='http://66.206.7.133/' target='_blank'>http://66.206.7.133/</a> in the meantime to reach the content <!--emo&:)--><img src='http://www.unknownworlds.com/forums/html//emoticons/smile-fix.gif' border='0' style='vertical-align:middle' alt='smile-fix.gif' /><!--endemo-->
p15.5ce1 should be out by the end of the month - i hope, though i am still in need to contact the guy thats doin csg, and see if what he has done effects the rad code
amckern
custom edition <b>OR</b> community edition
Its also only a working name, as there are going to be a few people working on the new version, and as such, it should have a proper name
the full version name at this point in time is
ZHLT 1.7.2.5.3.p15.5.ce1
Unless some one can correct me, it sounds right to me
amckern
custom edition <b>OR</b> community edition
Its also only a working name, as there are going to be a few people working on the new version, and as such, it should have a proper name
the full version name at this point in time is
ZHLT 1.7.2.5.3.p15.5.ce1
Unless some one can correct me, it sounds right to me
amckern <!--QuoteEnd--> </td></tr></table><div class='postcolor'> <!--QuoteEEnd-->
I'd like to interject here -- the reason I added the patch numbers (p2, etc.) was so that if Merl ever updated, people wouldn't be confused by a bump in Merl's numbers and my own. For instance, if Merl made custom 1.8, I'd have released 1.8p15 shortly afterward. If he'd made 2.0, I'd have released 2.0p15. That way people would know that my work up to the 15th patch was in that release.
Since Merl hasn't released an update in years and I'm not developing for the tools any more, there isn't any reason to split off the numbers any further. I actually toyed with simply calling p15 ZHLT 3.0, but decided that it wasn't a good idea to give a flawed build a major revision number.
Since the code is changing hands and Zoner, Merl, and I are all effectively retired from working on it, now would be a good time to make the switch to a saner versioning system. <!--emo&:)--><img src='http://www.unknownworlds.com/forums/html//emoticons/smile-fix.gif' border='0' style='vertical-align:middle' alt='smile-fix.gif' /><!--endemo-->
i agree with xp we should change to ZHLT 3 as soon as we have a fully stable build.
So I'm all for dropping it once you get a stable build <!--emo&:)--><img src='http://www.unknownworlds.com/forums/html//emoticons/smile-fix.gif' border='0' style='vertical-align:middle' alt='smile-fix.gif' /><!--endemo-->
The team is slowly falling into place, with AJenbo? (Pity you dont put your nick in your email "from"), and a posiblty of Jim_the_coder
Other then that, I hope to make the ZHLT 3 Tools, the last tools, before HL2, with -
Stable
Fast
With what the community wants (Though This is an iffy)
amckern
i just formated my system so i will have to setup the compiler again befor i can look at the sky problem.
While you talk about sky problems? What is wrong with the sky? I coded me just another BSP viewer recently and realized sky brushes make it into the map unmodified with all six sides, is that what you talk about?
@Cagey:
When I look up your page I get an infinite loop of redirections to the site like this:
queriing xp-cagey.com...
connecting to xp-cagey.com...
queriing xp-cagey.com...
connecting to xp-cagey.com...
queriing xp-cagey.com...
connecting to xp-cagey.com...
queriing xp-cagey.com...
connecting to xp-cagey.com...
...
the light_env is brighter in p15, over p13, even when you use the same brightness in hammer
amckern
<!--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-->In a way yes, but in this case no.
A normal CPU has about 8 registers inside the cpu which each can contain up to 32bit of data (four bytes).
It is much faster to access data stored inside the registers than getting loading them from the RAM.
It will take about 20 to 100 times longer acessing data in memmory than acessing data in the registers inside the CPU. But because of the limited amount of registers in the CPU most data and especially arrays must be stored in RAM, but small variables, such as bytes and integers (in newer CPU's even floats) can be stored in registers in the CPU.
The extra for loop doesn't add to the complexity of the algorithm, since the same number of iterations was reached through some spaghetti bitwise opperations.
The whole idea behind my tweak is to cache a byte at the time in the registers, and only load it in from the array in the RAM once every 8 iterations.
Its impossible to explicit declare which variables should be allocated to registers and which should not in M$ visual C++... since it uses an algorithm that figures out which variables are to be allocated into registers manually. (this is not a feature but simply bad coding from microsoft). Anyway, theres a great change that the variables I use will be allocated into registers since they are the only ones alive inside their scopes.
The 0.6% performance improvement I could see in the improvement in compiletime. It isn't much, but a little tweaking here and there makes it all faster in the end.
Another good thing about using two for loops instead of bitwise rotate left operators is that the code is easier to understand. I may have added some code, but I don't think that I've added many more operations.
Its not a revolution, its a tiny tweak B)
------------------
visit www.egir.dk
<!--QuoteEnd--></td></tr></table><div class='postcolor'><!--QuoteEEnd-->
<a href='http://countermap.counter-strike.net/ubb/Forum1/HTML/003534.html' target='_blank'>http://countermap.counter-strike.net/ubb/F...TML/003534.html</a> < is the ideas thread at this point in time, as well as the thread your now reading
amckern
how ever, i will test this complie out, and see if it works
amckern
yep that is what i was talking about, but they also end up douple sided, you can alrady remove the 5 sides by using null or bevel but the douple side is compiler only.
by the way it might be a idear to add gcf support in to the tools using the <a href='http://countermap.counter-strike.net/Nemesis/index.php?c=108#p108' target='_blank'>HLLib.dll</a> by nemesis.
ta talked to egir some weeks ago, about some vis optimising using 2D for initily testing of the vis portals, dont know if he is going to try it.
how is full bright faces (sky or texlight) treated do they get multiple lightmaps like every other suface, couldn't we make it just give them one.
and lastly it seams that steam actualy supports 18x18 light maps so we might be able to increas the subdivide from 240 to 270 if we change the rad to not make a error out of it
<a href='http://www.cubed.dk/nobody/stuff/18.png' target='_blank'>324sqrt=18</a>
if you use a normal sky brush, with out null, its brighter then with
i dont know if this is part of the opt_planes code, but well have to have a look
I'm also testing the code by Egir, with a few mates in the mapping community, to see if it works, and the results coming back are wondeful
One guy, shaved 1.3 hours of his vis, so it shows a good result
also, the subdived, should be keept the same, as some people, such as ME do not have steam, nor use it - it is also good for those that dont use there net pc's for mapping, and use 1.10 half life, or such, though if its not to much trouble, might inlcude a switch for backways compad
amckern
Better yet would be to also add the maxdistance stuff in to netvis - even if this part is only run on the server.
Is it also possible that a maxdistance type thingy before leafthread could help take some out beforehand?
I don't know anything about the vis algorithms but it can't hurt to throw a few ideas around.
Of course, maxdistance is only any good for large maps or vissing weirdnesses that won't leave in any other manner. *shrug.
<!--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-->and lastly it seams that steam actualy supports 18x18 light maps so we might be able to increas the subdivide from 240 to 270 if we change the rad to not make a error out of it
324sqrt=18<!--QuoteEnd--></td></tr></table><div class='postcolor'><!--QuoteEEnd-->
I have to agree with amckern here - make it a switch if you do work this in.
<!--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-->by the way it might be a idear to add gcf support in to the tools using the HLLib.dll by nemesis.<!--QuoteEnd--></td></tr></table><div class='postcolor'><!--QuoteEEnd-->
GCF support? For what?
Getting textures from WADs stuck in GCFs is all I can think of..mappers need them extracted for hammer anyway...
csg will always know where to get the standart textures
hammer 4 supports gcf directly so no more having to extract the wads when it comes.
This is also in the email i sent you, though other people might know the answer
the netvis in you p15.5 is asking for a cc++ set of headerfiles
i'm wondering where you got these from, for your use, as i cant seem to find a win32 version any were
amckern
I think these are what you may be after. I have no idea what version you need but im trying to find out now.
If i remember correctly it came up a while back (somewhere, damned if i can remember THAT) someone said you need the earlier version 1.xx...
EDIT:
Found in the MHLT 1.7 readme:
<!--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-->Recommended:
(x) CommonC++ 1.4.2+ libraries (for compiling netvis) Available at
<a href='http://sourceforge.net/project/?group_id=1523' target='_blank'>http://sourceforge.net/project/?group_id=1523</a><!--QuoteEnd--></td></tr></table><div class='postcolor'><!--QuoteEEnd-->
So I'll give that a whirl. Just so you know im trying to compile netvis from MHLT 1.7 so you may or may not have the same results as me one way or another...
EDIT2:
Well mostly I got it working...
<!--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-->LINK : warning LNK4098: defaultlib "LIBC" conflicts with use of other libs; use /NODEFAULTLIB:library
flow.obj : error LNK2001: unresolved external symbol "struct visblocker_t * __cdecl GetVisBlock(char *)" (?GetVisBlock@@YAPAUvisblocker_t@@PAD@Z)
Release/netvis.exe : fatal error LNK1120: 1 unresolved externals
Error executing link.exe.<!--QuoteEnd--></td></tr></table><div class='postcolor'><!--QuoteEEnd-->
Got any ideas?
Not knowing what Im doing dosen't help but I'm guessing it can't find this GetVisBlock function anyhere.
Ah I just got rid of the warning by tagging /nodefaultlib:"libc" on the linker(?) command-line..
I found some download at gnu.org, but it wanted me to make a dll?
ahhh well, i'll try the source forge one
amckern
Also the good old MMX stuff should be considered. It can process up to eight values at once and only takes one clock cycle for any operation (except for multiply-and-add, which can take up 3 clock cycles). Copy memory with it, shift bytes, calculate vector products, divide/multiply by 2^n... the downside is of course that you can't use it for anything that incorporates floating point numbers.
I am still having issues, with why opaue, and lights files other then lights.rad are causing rad to crash on start up - and when i did casting i broke part of csg, so i'm gona go back to the raw code, and start again
--------------------------
Where can i find some info on mmx, and 3dnow (if this is the amd sister of mmx)?
My background is in java, and i'm brining the java princables over to cpp, but also looking at the code, and seeing how i can make it faster
Adam
Mmm, my main programming expertise is in Java too, with a smattering of other languages... maybe if I ever get some decent quantity of free time, I'll help have a good look at this code too <!--emo&:)--><img src='http://www.unknownworlds.com/forums/html//emoticons/smile-fix.gif' border='0' style='vertical-align:middle' alt='smile-fix.gif' /><!--endemo-->
Reve
(ps: doc site nearly ready)
I'd like to announce the launch of the ZHLT documentation online, <a href='http://www.zhlt.info' target='_blank'>www.zhlt.info</a>
At the moment, it currently consists of just the documentation I did for XP-Cagey's p14 build, updated for p15, p15.5, and zhlt 3 betas 1 - 3. I will be keeping it updated with changes to ZHLT 3, and plan to add other features (such as links to the different versions of the tools, and links to particularly helpful tutorials). I also welcome any suggestions from the community with regards to the site.