Afrow UK
22nd April 2003 23:34 UTC

GetFileTime
I'm using this piece of code to check whether or not the VIS Quake2 compile was successful or not.

        GetFileTime $8.bsp $0 $4
        ExecWait "$\"$INSTDIR\quake2\compilers\qvis3.exe$\" $\"$8.bsp$\"" $2
        StrCmp 0 $2 0 CompileClosed
        GetFileTime $8.bsp $0 $3
        StrCmp $3 $4 CompileFail2

So, if VIS fails, then it does not write to the bsp file ($8.bsp) therefore the last file write time should be the same. This works fine, but sometimes, even when VIS is successful, $3 and $4 are the same.

What can I do to improve this?

-Stu

virtlink
23rd April 2003 09:27 UTC

- If possible, I would delete the $8.bsp-file before compiling, then check whether it exists or not.
- When GetFileTime fails, $4 becomes empty (""), and if it fails again (for whatever reason), $3 becomes empty too. And "" == "" = true.
- I don't know what 'High DWORD' and 'Low DWORD' mean, but you could try to switch them (e.g. GetFileTime $8.bsp $4 $0)

Sunjammer
23rd April 2003 09:35 UTC

A 64 bit value can be thought of as two 32 bit values (known as DWORDS, i.e double words where a word is two bytes, e.g. 2*2*8 bits) where the top 32 bits are the high dword and the rest are the low dword :-


64......56......48......40......32......24......16......8.......0
< Byte >< Byte >< Byte >< Byte >< Byte >< Byte >< Byte >< Byte >
1111111100000000111111110000000011111111000000001111111100000000
<---------High DWORD-----------><----------Low DWORD----------->

virtlink
23rd April 2003 09:57 UTC

So the low dword contain the hours, minutes and seconds?

Sunjammer
23rd April 2003 11:21 UTC

The 64-bit value is a single number "representing the number of 100-nanosecond intervals since January 1, 1601 (UTC)." (taken from MSDN and yes internally it does use FindFirstFile now instead of GetFileTime).

So the bottom dword represents 2^32-1 == 4,294,967,295 * 100 nanoseconds since 1/1/1601 UTC. Nano means 10 raised to the power minus 9, or 0.000000001. Therefore the low DWORD represents a maximum of 4.294967196 seconds. I think from this (assuming my calculations are correct) it is the high dword you are interested in :)

My calculations also seem to indicate that the 64-bit number can represent a time upto around the year 56893 !!

((2^64-1)*100*(10^-9))-1601=~56893 !!!!!!!!!!!!!!

virtlink
23rd April 2003 14:19 UTC

I see that Microsoft looked ahead. They propably think that they'll still exist in 56.893, 54.890 years ahead. Optimistic. ;)

Thanks for the info.

Afrow UK
23rd April 2003 14:24 UTC

So, I should use...

GetFileTime $8.bsp $4 $0
        ExecWait "$\"$INSTDIR\quake2\compilers\qvis3.exe$\" $\"$8.bsp$\"" $2
        StrCmp 0 $2 0 CompileClosed
        GetFileTime $8.bsp $3 $0
        StrCmp $3 $4 CompileFail2

...instead?
(I'm taking the high DWORD output)

It would be a good idea to delete the bsp file before hand, but the purpose of VIS is to process the bsp file and add information to it. (Technically it writes info to tell Quake2 how faces shall be shown from different areas of the map at different areas. This process can take days!)
So, if I deleted the bsp, then VIS would fail because there is no bsp to read from!

I'm using a similar method to test whether or not the RAD compile has failed (RAD does map lighting, shadows, lighting colours / gradients etc)

-Stu