search

ValveSoftware / halflife

Half-Life 1 engine based games
Other
3.71k stars 626 forks source link

Textures with the same name do not replace each other in client's memory #2399

Open Splatt581 opened 5 years ago

Splatt581 commented 5 years ago

This creates a problem when we consistently load maps that use different textures with the same name. For example, take maps _dedust2 and _abb_bhop_and260 (link to map). They have several textures with the same name, for example SandRoad. Further:

  1. We first load map _abb_bhop_and260, executing in console map abb_bhop_and_260;
  2. Now load the _dedust2 map. Apparently from a screenshot, some textures were not replaced and remained from the previous map.

1

tschumann commented 5 years ago

In another issue there was a discussion about (I think) the engine not cleaning up texture data (and eventually running out of texture slots and crashing) - possible this is related?

metita commented 5 years ago

In another issue there was a discussion about (I think) the engine not cleaning up texture data (and eventually running out of texture slots and crashing) - possible this is related?

Probably related.

SamVanheer commented 5 years ago

In another issue there was a discussion about (I think) the engine not cleaning up texture data (and eventually running out of texture slots and crashing) - possible this is related?

The code that performs cleanup is supposed to free world textures, which is exactly this sort of data. If it's not working properly then it needs fixing.

Edit:

This happens because world textures are only freed after a new map has loaded. Since textures are stored by file name only the same name in different wads/bsps will be treated as identical.

Making world texture names use the format mapname/texturename should solve this, but this will end up removing all of the previous map's textures anyway so maybe calling GL_UnloadTextures before map loading is a better solution.