I ran into a problem trying to implement the live code editing feature. Everything works fine when I'm reloading the DLL at fixed time intervals. However, when I tried to use CompareFileTime something odd happens. The code detects the difference in file times, unload and reloads the DLL just fine. The last write time of the DLL is updated as well. But the next my code loops, the NewDLLWriteTime is not equal to that new DLLLastWriteTime. The code unload and load has to execute again to get a final last write time. What's even more bizarre is that the game code does not reload as a result UNLESS I'm executing it line by line in the debugger. What could possibly be writing to that DLL after the fact that would case this to happen?
Edited by Christopher McLaughlin
on
Reason: Initial post
On which day are you ?
Can you post your code that is doing the check and reloading ?
Did you try compiling Casey's code to see if you have the same problem ?
One possible problem would be that you read the dll before Visual Studio finished writing it. A somewhat similar problem is fixed in day 39 - Fixing live code loading.
Can you post your code that is doing the check and reloading ?
Did you try compiling Casey's code to see if you have the same problem ?
One possible problem would be that you read the dll before Visual Studio finished writing it. A somewhat similar problem is fixed in day 39 - Fixing live code loading.
When you calling GetFileTime are you sure you are using lpLastWriteTime and not lpLastAccessTime argument?
Are you running some weird software in background? Like anti-virus or some anti-malware or similar "security" software?
Are you running some weird software in background? Like anti-virus or some anti-malware or similar "security" software?
I just compiled Casey's code for Day 22 and it appears to have the same bug. When I recompile after changing the game state, it builds the DLL just fine but the code is not reloaded. The fix he applies on Day 39 doesn't address this problem either, it seems.
I'm not running any 3rd party antivirus or anything like that. The only thing I can think that could possibly be the cause is the hard drive itself. I used to have the whole drive compressed but I turned that feature off a while ago.
UPDATE: And indeed, moving my work to the solid state drive appears to have cleared up the issue. Something weird was going on because transferring the file said there was 1.8 GBs. But the folder wasn't even 50 MBs. Very strange stuff.
UPDATE 2: Actually the extra size was just hidden visual studio files. To me that's a surprising amount of disc space though. So I still have no idea what was happening. I'm just glad to be back on track.
I'm not running any 3rd party antivirus or anything like that. The only thing I can think that could possibly be the cause is the hard drive itself. I used to have the whole drive compressed but I turned that feature off a while ago.
UPDATE: And indeed, moving my work to the solid state drive appears to have cleared up the issue. Something weird was going on because transferring the file said there was 1.8 GBs. But the folder wasn't even 50 MBs. Very strange stuff.
UPDATE 2: Actually the extra size was just hidden visual studio files. To me that's a surprising amount of disc space though. So I still have no idea what was happening. I'm just glad to be back on track.
Edited by Christopher McLaughlin
on
Thank you!! Moving my project to a solid state drive fixed this issue for me as well. Any idea why?
Edit* Actually moving my project to a SSD didn't completely fix the problem, it only made it better. However, sometimes my live code editing doesn't work unless I spam the build.bat multiple times. Any ideas? Thanks!
Edit2* Implementing Casey's fix in episode 39 by adding the lock file and checking for it fixed the issue. It's all connected.
Edit* Actually moving my project to a SSD didn't completely fix the problem, it only made it better. However, sometimes my live code editing doesn't work unless I spam the build.bat multiple times. Any ideas? Thanks!
Edit2* Implementing Casey's fix in episode 39 by adding the lock file and checking for it fixed the issue. It's all connected.
Edited by Bouke285
on
For anyone else having this problem, I found a quick patch until I get to later episodes was to simply add a call to Sleep after the file timestamps were compared, but before the code was loaded. 30ms seems to suffice, and would hardly be noticeable unless you were somehow recompiling several times in one second.
1 2 3 4 5 | if (CompareFileTime(&NewDLLWriteTime, &Game.DLLLastWriteTime)) {
Sleep(30);
Win32UnloadGameCode(&Game);
Game = Win32LoadGameCode(SourceGameCodeDLLFullPath, TempGameCodeDLLFullPath);
}
|