Changes between Version 1 and Version 2 of Ticket #14482, comment 2
- Timestamp:
- Aug 8, 2023, 9:21:29 PM (9 months ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
Ticket #14482, comment 2
v1 v2 1 Based on my analysis so far, it looks like when the common ScummVM unzip code is being called to extract a texture with special characters (in this case "puppær.dds"), the special character is being incorrectly set in the texture's name variable, leading to issues for debugging (Visual Studio shows "invalid characters in path" instead of the value) and the game itself (the texture renders as blank). When attempting to force the correct character via debugger during load , it renders correctly though so this seems like a bug with the unzip function specifically as the variable can store the value correctly. Here's how the filename shows up in the debug log when attempting to write its loaded name (special character at the 5th position in the name does not show up correctly when rendered in browser):1 Based on my analysis so far, it looks like when the common ScummVM unzip code is being called to extract a texture with special characters (in this case "puppær.dds"), the special character is being incorrectly set in the texture's name variable, leading to issues for debugging (Visual Studio shows "invalid characters in path" instead of the value) and the game itself (the texture renders as blank). When attempting to force the correct character via debugger during load within the stark engine, it renders correctly though so this seems like a bug with the unzip function specifically as the variable can store the value correctly. Here's how the filename shows up in the debug log when attempting to write its loaded name (special character at the 5th position in the name does not show up correctly when rendered in browser): 2 2 Attempting to load texture puppr.dds 3 3 4 I've narrowed it down to t he exact line causing the bug, it is definitely in the common unzip function, here the correct value cannot be stored but once it is returned to the engine it can so seems like there is a restriction on the ZipHash. If anyone has experience with the unzip function and knows more about how this works it would be helpful to find a fix.4 I've narrowed it down to to what seems like the exact line causing the bug, it is definitely in the common unzip function, here the correct value cannot be stored but once it is returned to the engine it can so seems like there is a restriction on the ZipHash. If anyone has experience with the unzip function and knows more about how this works it would be helpful to find a fix. 5 5 6 6 [[Image("BugLine.jpg")]]
