Homesource Forums

Homeworld Source Editing Talk
It is currently Fri Mar 24, 2017 10:58 pm

All times are UTC - 5 hours




Post new topic Reply to topic  [ 2 posts ] 
Author Message
PostPosted: Sun Oct 03, 2010 1:32 pm 
Offline
coder
User avatar

Joined: Tue Dec 14, 2004 3:24 pm
Posts: 324
Location: UK (UTC+0)
r755 provided the option to have captured vessels repainted in the new owner's colours. I've since discovered that this is the cause of some particularly bad performance problems I'm experiencing which I attributed to poor system performance when I originally wrote the code. It appears that the inclusion of the extra textures (each ship has multiple textures, one for each colour scheme it can potentially have) overloaded the texture registry. At least that's what the debugger is telling me but I don't believe it.

TR_RegistrySize is set to 6000 which according to its associated comment is "dag nammit, this is just silly large!" so I take that to mean the chances of my overloading it are less likely. The code checking the texture entry is finding it's being handed references which are out of bounds; the debugger is claiming 263405 in one instance. That's much, much bigger than 6000 which poses two problems:

(1) I cannot believe that an additional texture for my fleet colours on every other object type in the universe, let alone just ships, adds another 250,000 textures!
(2) Even if there really are 250,000 extra textures, why am I not experiencing buffer overrun errors?

That aside, because the texture reference is out of bounds, the game attempts to reload the texture again. Doing this constantly causes the game to slow down appreciably.

I'm clearly missing something here and whilst I'll keep investigating, someone else more familiar with the texture code may be able to give me some guidance. It's possibly something to do with iColorScheme which is commented to mean "0 = no player" and r755 now makes "0 = human player". I couldn't find any code showing "0 = no player" gets tested anywhere so I was happy with my code change, but maybe that's a built-in assumption populating the registry in the first place and that's what's screwing me over (an unassigned memory value being used as-is (250,000) maybe?). For reference, it all goes pear shaped here:

Code:
Mesh.c line 1399
trMakeCurrent(((trhandle *)material->texture)[iColorScheme]);

Any hints appreciated. Thanks.

_________________
MacHomeworld | HomeworldSDL.org


Top
 Profile  
 
PostPosted: Sun Mar 27, 2011 7:44 am 
Offline
coder
User avatar

Joined: Tue Dec 14, 2004 3:24 pm
Posts: 324
Location: UK (UTC+0)
OK, the repainting of captured vessels wasn't root cause after all. It was the debug code added to trMakeCurrent() in order to identify spurious texture handles during the 64-bit testing. The debug message, coupled with the large number of ships in my 8-player game, spammed my hard drive with so much IO that the game became a slide show before eventually locking up! :D

I identified a bug in the check that meant that it was reporting texture handles as invalid when they weren't. trHandle is a compound value that consists of a palette index in the high word and the texture registry index in the low word (oh, what fun!):
Code:
#define trIndex(handle)         ((handle) & 0x0000ffff)
#define trPaletteIndex(handle)  ((handle)  >> 16)
#define trStructure(handle)     (&trTextureRegistry[trIndex(handle)])
#define trHandleMake(index, palette) (trhandle)(index | (palette << 16))
Since the entire trHandle was being compared to the max texture registry size it would report problems when certain palette indexes where set. I've fixed this in r833:
Code:
--- a/trunk/src/SDL/texreg.c
+++ b/trunk/src/SDL/texreg.c
@@ -3353,7 +3353,7 @@ void trMakeCurrent(trhandle handle)
     //GE01  Seem to be sent spurious texture handles due to the multiplayer options.
     // Print them then ignore them. :)  probably should wrap this further in build_for_debug tests.
     //
-    if (handle != TR_Invalid && handle >= TR_RegistrySize){
+    if (handle != TR_Invalid && trIndex(handle) >= TR_RegistrySize){
 #if TR_ERROR_CHECKING
         dbgMessagef("%s: sent invalid trhandle: 0x%lx", __func__, handle);
 #endif
You may want to see if the problem you were debugging before still exists as it may just have been confusion over trHandle being a compound value.

_________________
MacHomeworld | HomeworldSDL.org


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 2 posts ] 

All times are UTC - 5 hours


Who is online

Users browsing this forum: No registered users and 1 guest


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
cron
Powered by phpBB® Forum Software © phpBB Group