First bounty claimed, multi-thread VIS bug fixed

« Tronyn reviews: For Love of Evil (and associated maps) by Hrimfaxi || First Model converter alpha released »

## First bounty claimed, multi-thread VIS bug fixed

I am very happy to announce the first bounty being claimed. Tuna has fixed the bug in WVis where interrupting and resuming would lead to an error. The patch is available here. A binary is available here. (Somehow I could not create a ZIP file, sorry…)

Thanks Tuna!

The model converter and Ogg Vorbis bounties are going strong. I am very glad how well this turns out.

17.01.2010 in quaddicted.com | 9 Comments »

### 9 Responses to “First bounty claimed, multi-thread VIS bug fixed”

1. Willem Says:
   17.01.2010 14:34

   AWESOME!

   Seriously go ahead and make a proper release and put it on Quaketastic. Up the version number and throw a readme into that directory or something. I’m really doubting i’ll have time to package this up properly anytime soon.

2. Spirit Says:
   17.01.2010 17:11

   Thanks. :)

3. Tuna Says:
   17.01.2010 17:25

   This was great fun! I hope this one turns out to be error free. If not let me know.

   Save points can cause to situations where threads will be idle while waiting to the last one to finish. I suggest increasing the save time to a higher value than the default to reduce those situations.

4. negke Says:
   17.01.2010 19:23

   This seens like a somewhat counterproductive method? For if a portal on one thread takes considerably longer than all others (and by that I mean hours or more – for example in my latest map, vis got stuck on a particularly stubborn portal for 16 days), the purpose of multithreading is kind of foiled and potential processing time wasted.
   I thought the solution would be to make vis reset all unfinished portals when saving the state file in a way that allows vis to restart the calculation from scratch upon resume.
   …Hmm, now that I think about it, this might very well have been the problem with the old version to some extend. If the vis process indeed relies on a certain order/succession in which the portals are (or have to be) processed. That’s what BJP mentioned in his interpretation afaik, isn’t it?

5. Tuna Says:
   17.01.2010 20:06

   Yeah. The first priority for me was to fix the corruption of the save file. Its probably not optimal performance wise. It should still be faster than single threaded. In a case of a 16 days portal.. well yeah thats bad..

   I have another build over here that should reset all portals that are being processed before writing the save file. However I had no time to actually test it yet..

6. Tuna Says:
   17.01.2010 21:41

   I have updated my test version:

   http://user.cs.tu-berlin.de/~tuna/WVis_thread_test.zip

   It should now use all cores no matter what. I could not trigger the “portal not done” error with this one either. If someone can confirm this version should be much nicer. (patch included)

   Also this version should ensure that if you hit ctrl-c while the save file is being written your save file will not be corrupted.

7. ijed Says:
   17.01.2010 22:07

   Thanks for this.

   About other bounties – can we can contribute as well?

   I’d give my eye teeth for a proper exporter.

8. Baker Says:
   18.01.2010 02:32

   Nice!

9. s_a_j_t Says:
   18.01.2010 13:12

   ijed: Exporter of what?

### Leave a Reply

Name

Mail (will not be published)

Website