News | Forum | People | FAQ | Links | Search | Register | Log in
Mapping Help
This is the place to ask about mapping problems, techniques, and bug fixing, and pretty much anything else you want to do in the level editor.

For questions about coding, check out the Coding Help thread: https://www.celephais.net/board/view_thread.php?id=60097
First | Previous | Next | Last
Willem 
I'm not exactly sure bout the implementation, but it seems it could be faster with multi core processor indeed.
I already discussed this topic with aguirRe, and he told me that ID indeed had their first VIS process running onto multicore Unix machine, but it has never been ported to Windows in this way: Window VIS tools are single CPU only, and AFAIK.. unless somebody has a specific tool on his own ;) 
 
The code is in there - it's just #ifdef'd out. All a Windows programmer would have to do is define "_alpha" (or whatever the symbol) is in preprocessor symbols of their compiler and fix the errors that spit out. It was really pretty simple on Mac.

I've not done much multithreading on Windows so I can't say how closely the structures and such relate to what id wrote on their Unix machine but it can't be more than a few hours of hunting around some documentation to find equivalents. 
So Willem... 
...care to do me a little favor? 
 
Haha ... I might take a stab at it. Which VIS do people use? Point me at some source code and I'll take a crack at it this weekend but no promises... 
BJP's Of Course 
I didn't mean compiling the vis tool, though! 
 
negke already in 90% 
Not Quite 
Full: 76.65%, Elapsed:359h 37m, Left:885h 2m, Total:1244h 39m, 28% 
 
negke

Oh, well, the best solution long term would be to get a Windows version with multithreading working. I could run it for you, yes, but that's painful. :P

To be clear, this?

http://user.tninet.se/~xir870k/visbjp.zip 
Yep 
 
Willem 
somebody provided be a vis tool that is supposed to run 40% faster than Id's original one... but I never tested it as I did not trust the guy that much: anyone who wants to benchmark it can send me an email: I'll provide the stuf.... at your own risk :P 
Forgot To Mention... 
... I also have the source... 
 
Can someone hook me up with a .PRT and a matching .BSP file so I can run some VIS debugging? 
PRT Files... 
...you can generate them yourself from the BSP. Use for example BspInfo (delivered with aguirRe's visbjp suite) and the -prt flag. 
 
Ha! So you can, awesome. Thanks! 
Go Willem! 
 
OK, This Might Work... 
...but it comes with zero assurances of it actually working or not corrupting data. :P

I took some of my lunch hour today to see if this could be done quickly.

http://files.getdropbox.com/u/161473/Vis.zip

That should be a multi-threaded version of BJP VIS. When you run it, you'll see some additional text appear like:

"Using X threads."

The X will be however many cores/processors you have in your machine.

The percentage and progres stuff is all kinds of messed up and I don't have time to fix it today - lunch time is over! But I'll take a look at that in the future once the basics are nailed down.

Anyway, try it, run some side by side timings and let me know if I'm crazy or if this actually works.

The best way to see it work is to start up your Task Manager and look at the processor activity. All of your cores/processors should be pegged at 100% when this is running.

Thanks! 
 
swapping to your vis for all my vising needs. i'm seeing 100% cpu usage, so it appears to be working fine. i'll let you know if anything weird happens.

you are currently on my list of people made of awesomeness for this, btw. ^_^

damn, i wish i had a quad core though. :( 
 
The part that scares me is if the map will load into Quake when it's done. That's something I can't test here. :) Let me know, plz! 
Willem 
Despite it may load, it also can generates HOMs and leaks.... wait and see :P 
 
I don't see why it shouldn't load into Quake. After all, all you changed was the resource management. The actual vis calculation and state file handling remains untouched.
I'm running a test at the moment. One hour of willemvis vs one hour of regular (single-threaded) vis. The time estimations would help here, but whatever. No idea if there's much of a gain. I don't have a real multicore machine, just one of those p4-hyperthreading dudes (I was always suspicious about this being a possible bottleneck). 
 
How many threads does it say you're using? If it's more than 1, you should see SOME improvement. 
OK, I Think I Fixed The Time Estimates And Percentages... 
I also renamed the EXE for easier use.

http://files.getdropbox.com/u/161473/WVis.zip

Give that a shot if you want the time estimates to be useful. 
Will Test This For Future Builds 
 
 
So I guess now, whoever has the most cores/processors on their machine needs to become a VIS mule for the group. :P 
 
Yes, there's definitely some improvement (with 2 threads) - I'd say it's at least 40% faster. I was so dumb as to accidentally close the window just now, so I can't tell the exact difference, unfortunately. But still, your version is useful for running at night when there're no other programs running beside vis. Thanks for offerning your lunch break. 
First | Previous | Next | Last
You must be logged in to post in this thread.
Website copyright © 2002-2024 John Fitzgibbons. All posts are copyright their respective authors.