28 maggio 2012 · 3 commit di 1 autore · SVN
------------------------------------------------------------------------
r2704 | helixhorned | 2012-05-28 11:15:26 -0700 (Mon, 28 May 2012) | 8 lines
On Windows, check file name case with 'sound' and 'music' CON commands.
This is done by kopen4loadfrommod'ing and immediately closing the file
(since the checker is still run from there when not ingame).
On my system, times were like 0.12 ms, 0.2 ms and 0.5 ms for each
openfrompath/findfrompath, openfrompath/Bopen and SHGetFileInfo
respectively, so it shouldn't have a too noticable impact on initial
loading times.
------------------------------------------------------------------------
r2703 | helixhorned | 2012-05-28 11:15:22 -0700 (Mon, 28 May 2012) | 7 lines
In kopen4loadfrommod, don't try g_modDir if it's the default "/".
I experienced the following on Windows XP: a few openfrompath() -->
findfrompath() calls were taking enormously long (4.5 secs) to complete, having
been passed a file name like "//bla/qwe.asd". My guess is that Windows then
tried to interpret these as a network FS path in access(), and the 4.5 secs
represents a timeout value.
------------------------------------------------------------------------
r2702 | helixhorned | 2012-05-28 11:15:19 -0700 (Mon, 28 May 2012) | 7 lines
Only check file name case when not in-game; don't warn for ALLUPPER or alllower.
The first means that the expensive (~0.5 ms) SHGetFileInfo() calls won't inter-
fere with smooth gameplay, but files that are opened only at game-time like
sounds won't be checked. The second means that there are now less false
positives, i.e. warnings about files that would be found due to the
check-all-{upper,lower} hack.
------------------------------------------------------------------------
This is done by kopen4loadfrommod'ing and immediately closing the file (since the checker is still run from there when not ingame). On my system, times were like 0.12 ms, 0.2 ms and 0.5 ms for each openfrompath/findfrompath, openfrompath/Bopen and SHGetFileInfo respectively, so it shouldn't have a too noticable impact on initial loading times.
I experienced the following on Windows XP: a few openfrompath() --> findfrompath() calls were taking enormously long (4.5 secs) to complete, having been passed a file name like "//bla/qwe.asd". My guess is that Windows then tried to interpret these as a network FS path in access(), and the 4.5 secs represents a timeout value.
The first means that the expensive (~0.5 ms) SHGetFileInfo() calls won't inter- fere with smooth gameplay, but files that are opened only at game-time like sounds won't be checked. The second means that there are now less false positives, i.e. warnings about files that would be found due to the check-all-{upper,lower} hack.