You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Asking the bitmap loader for uncompressed pixels does not get them from a DXT file #7887
When code locks a bitmap it tells the loader what kind of texture it can accept. Most of the engine says "anything". Code that has to read the pixels itself says "uncompressed only". The DDS loader does not act on that: it hands back a DXT file as compressed blocks no matter what was asked, and the only time it decodes one is when the graphics card has no DXT support at all. On any normal GPU, code that asked for plain pixels gets compressed blocks anyway. The spot is bm_lock_dds in bmpman.cpp, which ignores its flags argument.
Where it shows
#7886 makes EFF streaming animations copy each frame into their own buffer. A frame that arrives compressed cannot be copied, so the stream skips it and logs a line, and a DXT-framed EFF plays as nothing on a real GPU. Before #7886 such a stream showed its first frame and then froze on it, so neither version ever played it. None of the mods installed here stream a DXT EFF, so this is a gap rather than something players hit today, but it is the one case #7886 leaves behind.
Expected
Locking a DXT file with the "uncompressed only" request should return plain 32-bit pixels, using the decoder the engine already has for cards without DXT support.
Fix direction
In bm_lock_dds, when the caller accepts only uncompressed textures and the file is DXT, take the existing decode path and mark the result as uncompressed. The EFF stream's skip can then go. The stream is the only caller that asks for uncompressed only; the renderer asks for anything and would not change.
Further reading
#7886 (the stream change and the skip), #7885 (the related reload guard), conversion_needed in ddsutils.cpp (the existing decode decision).
Activity