IIRC the problem wasn't there in the release version, has anything changed since then which might cause that problem?
If you’re referring to 1.65, the answer is “almost everything”. :-)
I’ve temporarily tweaked Oolite to always use four texture-loading threads, but I’m still not seeing any corruption. I’m at a loss to explain what could be causing the problem; the thread interactions that occur are very simple.
IIRC the problem wasn't there in the release version, has anything changed since then which might cause that problem?
If you’re referring to 1.65, the answer is “almost everything”.
I’ve temporarily tweaked Oolite to always use four texture-loading threads, but I’m still not seeing any corruption. I’m at a loss to explain what could be causing the problem; the thread interactions that occur are very simple.
Hmm. Do you use some variable to tell if the thread has properly initialized the texture, thus that it can be used/transferred to the cache? Probably the problem sits there with it not being properly initialized, which would cause very different behaviour.
However, the game really runs fine on one processor and the texture problem is virtually gone - I've been playing quite some since that post with the two garbled textures. After restarting once more, that was gone and I did not encounter any garbled texture since then!
I'm a C++ programmer, quite tired with burnout, but I'm curious and sometimes it helps if someone else looks at it...do you have any instructions somewhere upon how to get the code/necessary compilers for windows? This is really a point where I'd like to have a look myself - maybe I'm lucky and can find out, what's going on. At least I do have a machine that could easily reproduce the bug while you obviously cannot, that should make things easier to debug.
Hmm. Do you use some variable to tell if the thread has properly initialized the texture, thus that it can be used/transferred to the cache? Probably the problem sits there with it not being properly initialized, which would cause very different behaviour.
Texture data is sent from the work thread to the main thread using a thread-safe many-to-many queue. The data is only placed in the queue when it is completely loaded and any scaling or mip-mapping applied. The texture object remains in a “loading” state until its data has been dequeued, and any attempt to apply the texture blocks the main thread until the texture’s data has been dequeued. No OpenGL commands are used in the worker threads.
I have been able to replicate the bug almost immediately by setting the texture loading threadCount to 4. I ran the game, let the ships parade for a few minutes and then went to the shipyard of a high-tech system (20+ ships). One of the available ships came up with the texture garbled. A thread count of 2 also resulted in the occurence of the bug.
Thanks...I downloaded the necessary stuff a few hours ago - except the source. If I'm supposed to take the source of http://prdownload.berlios.de/oolite-lin ... .1.tar.bz2 then I do have a problem, because I still get timeouts when contacting the server to initiate the download. I'll continue trying, though.
If you have downloaded Tortoise SVN as indicated, then you could simply checkout the 1.72-maintenance branch or the trunk itself by following the instructions in the Wiki page.
Hmm. Seems I may be relying on something that’s not thread-safe or otherwise broken in GNUstep, but I have no idea what. What joy.
Could it be that you use a pointer where a handle is required? Typically the stuff stays where it is...and sometimes the OS moves it to some other part of the memory?
Guess I'll have a nap before I look at the code...maybe berlioz will deliver me the files then, otherwise I'll try to obtain a copy via tortoise.
I also experienced texture corruption on ships + stations which was corrected permanently by
replacing libpng13.dll in oolite directory
with a renamed libpng-1.2.34-bin\bin\libpng3.dll from
libpng-1.2.34-1-bin.zip http://sourceforge.net/project/showfile ... e_id=16183
I strongly suspect that this and the borg star/nebula render problem are libpng related on Windows.
can libpng be updated for the next windows compilation ?
I strongly suspect that this and the borg star/nebula render problem are libpng related on Windows.
Re-enabled all cores....and no texture problem yet. Not that the game would not run smooth on a single one, but I prefer if the load is spread, as I haven't had fleet battles during that fix and was afraid of their performance impact
However, the nebulae seem to be some different problem on my machine.
The new libpng (v1.2.34) has been inserted in the Oolite source tree, SVN revisions 1966-1967. I have not seen the texture corruption bug reoccuring even after changing the texture loading threads number to 4.
