Join us at the Oolite Anniversary Party -- London, 7th July 2024, 1pm
More details in this thread.

Corrupt Texture problem

General discussion for players of Oolite.

Moderators: winston, another_commander

User avatar
JensAyton
Grand Admiral Emeritus
Grand Admiral Emeritus
Posts: 6657
Joined: Sat Apr 02, 2005 2:43 pm
Location: Sweden
Contact:

Post by JensAyton »

Screet wrote:
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.
Screet
---- E L I T E ----
---- E L I T E ----
Posts: 1883
Joined: Wed Dec 10, 2008 3:02 am
Location: Bremen, Germany

Post by Screet »

Ahruman wrote:
Screet wrote:
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.

Screet
another_commander
Quite Grand Sub-Admiral
Quite Grand Sub-Admiral
Posts: 6570
Joined: Wed Feb 28, 2007 7:54 am

Post by another_commander »

User avatar
JensAyton
Grand Admiral Emeritus
Grand Admiral Emeritus
Posts: 6657
Joined: Sat Apr 02, 2005 2:43 pm
Location: Sweden
Contact:

Post by JensAyton »

Screet wrote:
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.
another_commander
Quite Grand Sub-Admiral
Quite Grand Sub-Admiral
Posts: 6570
Joined: Wed Feb 28, 2007 7:54 am

Post by another_commander »

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.
User avatar
JensAyton
Grand Admiral Emeritus
Grand Admiral Emeritus
Posts: 6657
Joined: Sat Apr 02, 2005 2:43 pm
Location: Sweden
Contact:

Post by JensAyton »

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.
Screet
---- E L I T E ----
---- E L I T E ----
Posts: 1883
Joined: Wed Dec 10, 2008 3:02 am
Location: Bremen, Germany

Post by Screet »

another_commander wrote:
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.

Screet
another_commander
Quite Grand Sub-Admiral
Quite Grand Sub-Admiral
Posts: 6570
Joined: Wed Feb 28, 2007 7:54 am

Post by another_commander »

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.
Screet
---- E L I T E ----
---- E L I T E ----
Posts: 1883
Joined: Wed Dec 10, 2008 3:02 am
Location: Bremen, Germany

Post by Screet »

Ahruman wrote:
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.

Screet
Solas
Dangerous
Dangerous
Posts: 70
Joined: Sun Jan 04, 2009 7:26 am

Post by Solas »

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 ?
DGill
---- E L I T E ----
---- E L I T E ----
Posts: 280
Joined: Thu Jan 01, 2009 9:45 am

Post by DGill »

Nice one Solas :D

Your fix works well.
Screet
---- E L I T E ----
---- E L I T E ----
Posts: 1883
Joined: Wed Dec 10, 2008 3:02 am
Location: Bremen, Germany

Post by Screet »

Solas wrote:
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.

Screet
another_commander
Quite Grand Sub-Admiral
Quite Grand Sub-Admiral
Posts: 6570
Joined: Wed Feb 28, 2007 7:54 am

Post by another_commander »

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.
Post Reply