Yeah, I verified multiple times, they're both in the same dir...
So here's the weirdness:
The above returns an error in the watch window:
$err,hr ERROR_FILE_NOT_FOUND : The system cannot find the file specified. unsigned int
BUT this totally works FLAWLESSLY!:
How can it not find the file specified for CopyFile yet it is able to find it for LoadLibraryA?? (I triple checked it it was getting a fresh dll each time from building).
Any ideas? is this a setting I missed?
So here's the weirdness:
1 2 | CopyFile( "handmade.dll" , "handmade_temp.dll", false); Result.GameCodeDLL = LoadLibraryA( "handmade_temp.dll" ); |
The above returns an error in the watch window:
$err,hr ERROR_FILE_NOT_FOUND : The system cannot find the file specified. unsigned int
BUT this totally works FLAWLESSLY!:
1 2 3 4 | //CopyFile( "handmade.dll" , "handmade_temp.dll", false); //Result.GameCodeDLL = LoadLibraryA( "handmade_temp.dll" ); Result.GameCodeDLL = LoadLibraryA( "handmade.dll" ); |
How can it not find the file specified for CopyFile yet it is able to find it for LoadLibraryA?? (I triple checked it it was getting a fresh dll each time from building).
Any ideas? is this a setting I missed?
Who produces ERROR_FILE_NOT_FOUND? CopyFile or LoadLibrary?
The CopyFile returns the error code in this case.
Oh I fixed it, I had to set both the dll and exe debugger working directories to:
$(SolutionDir)$(Platform)\$(Configuration)\
Before they were both working in their respective PROJECT directories but outputting to $(SolutionDir)$(Platform)\$(Configuration)\.
$(SolutionDir)$(Platform)\$(Configuration)\
Before they were both working in their respective PROJECT directories but outputting to $(SolutionDir)$(Platform)\$(Configuration)\.
That couldn't have fixed that. You can set only one working directory per process. And because you are executing only one executable, the working directory matters only for exe project, not the dll project.
hahaha, ok then I guess changing the exe working directory was the only real change I did.
It took me forever to get Visual Studio to not argue with what I wanted to do...
A few of the high points are.
1. Made a C:..\Handmade\Code Folder, ..\Handmade\Data Folder, ..\Handmade\Output Folder
2. I set the output directory to C:\..\Handmade Output Foler
3. I set the intermediate directory for each project(The DLL and the EXE) to C:\..Handmade Output Folder\Win32Handmade and C:\..Handmade Output Folder\Handmade So I wouldn't get the project shares a output folder warning.
4. under options for all of the .cpp files except Win32Handmade.cpp and Handmade.cpp selected exclude from build.
5. pre build event for the dll project is to Del *.pdb from the C:\..\Handmade Output Folder..
6. I made a build.bat that just compiles the Handmade.cpp and setup a build tool, then bound that to a key on my keyboard, so I can one button rebuild.
7. I had to add the part a few posts up that checks for a PDB.LOCK in win32handmade.cpp before it will reload the DLL, then add the part from a few posts up that creates the PDB.LOCK, Compiles, then Deletes it.
I am adding code as Casey talks so I wasn't actually using the downloaded code...I setup a new project on my seconds hard drive and added all of Casey's code, re-setup the options, and it works just fine...I did that so I have something to compare to when my efforts go off the rails...
The PDB thing is really annoying but for the moment seems to work...I hope this information in one post will help, as I have struggled with it for a couple months.
Build.Bat
@echo off
mode con:cols=10 lines=1
call "D:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\vcvarsall" x64
set commoncompilerflags=-MTd -nologo -fp:fast -Gm- -GR- -EHa -Od -Oi -WX -W4 -wd4201 -wd4100 -wd4189 -wd4505 -wd4005 -DHANDMADE_INTERNAL=1 -DHANDMADE_SLOW=1 -FC -Z7
set commonlinkerflags= -incremental:no -opt:ref user32.lib gdi32.lib winmm.lib
del "C:\MS Visual Studio Projects\Handmade Output Folder"\*.pdb > NUL2> NUL
echo Lock > pdb.lock
cl %commoncompilerflags% "C:\MS Visual Studio Projects\Handmade Code Folder"\Handmade.cpp -FmHandmade.map -LD /link -opt:ref -PDB:"..\Handmade Output Folder"\handmade_%random%.pdb /OUT:"..\Handmade Output Folder"\Handmade.DLL -EXPORT:GameGetSoundSamples -EXPORT:GameUpdateAndRender
del pdb.lock > NUL2> NUL
A few of the high points are.
1. Made a C:..\Handmade\Code Folder, ..\Handmade\Data Folder, ..\Handmade\Output Folder
2. I set the output directory to C:\..\Handmade Output Foler
3. I set the intermediate directory for each project(The DLL and the EXE) to C:\..Handmade Output Folder\Win32Handmade and C:\..Handmade Output Folder\Handmade So I wouldn't get the project shares a output folder warning.
4. under options for all of the .cpp files except Win32Handmade.cpp and Handmade.cpp selected exclude from build.
5. pre build event for the dll project is to Del *.pdb from the C:\..\Handmade Output Folder..
6. I made a build.bat that just compiles the Handmade.cpp and setup a build tool, then bound that to a key on my keyboard, so I can one button rebuild.
7. I had to add the part a few posts up that checks for a PDB.LOCK in win32handmade.cpp before it will reload the DLL, then add the part from a few posts up that creates the PDB.LOCK, Compiles, then Deletes it.
I am adding code as Casey talks so I wasn't actually using the downloaded code...I setup a new project on my seconds hard drive and added all of Casey's code, re-setup the options, and it works just fine...I did that so I have something to compare to when my efforts go off the rails...
The PDB thing is really annoying but for the moment seems to work...I hope this information in one post will help, as I have struggled with it for a couple months.
Build.Bat
@echo off
mode con:cols=10 lines=1
call "D:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\vcvarsall" x64
set commoncompilerflags=-MTd -nologo -fp:fast -Gm- -GR- -EHa -Od -Oi -WX -W4 -wd4201 -wd4100 -wd4189 -wd4505 -wd4005 -DHANDMADE_INTERNAL=1 -DHANDMADE_SLOW=1 -FC -Z7
set commonlinkerflags= -incremental:no -opt:ref user32.lib gdi32.lib winmm.lib
del "C:\MS Visual Studio Projects\Handmade Output Folder"\*.pdb > NUL2> NUL
echo Lock > pdb.lock
cl %commoncompilerflags% "C:\MS Visual Studio Projects\Handmade Code Folder"\Handmade.cpp -FmHandmade.map -LD /link -opt:ref -PDB:"..\Handmade Output Folder"\handmade_%random%.pdb /OUT:"..\Handmade Output Folder"\Handmade.DLL -EXPORT:GameGetSoundSamples -EXPORT:GameUpdateAndRender
del pdb.lock > NUL2> NUL
Edited by Jeff
on
You should be able to use Visual Studios edit-and-continue so you do not have to start deleting the pdb files yourself.
The same also applies to using a batch file instead of using the solution/project to compile with msbuild/VS.
Is there any specific reasons you did choose to go this route instead of the "Visual Studio Way"?
The same also applies to using a batch file instead of using the solution/project to compile with msbuild/VS.
Is there any specific reasons you did choose to go this route instead of the "Visual Studio Way"?
He wrote
"call "D:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\vcvarsall" x64"
so I assume he wants to compile for x64 which doesn't support Edit & Continue not to mention that if you do it this way then you are not bound by the various limitations of Edit & Continue.
edit: nvm, my info was outdated
edit2: nah, I did remember right Edit&Continue for x64 applications doesn't work in Visual Studio only in the unreleased Visual Studio 2015 (you can get the Release Candidate but the RTM might still be a month or two away)
"call "D:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\vcvarsall" x64"
so I assume he wants to compile for x64 which doesn't support Edit & Continue not to mention that if you do it this way then you are not bound by the various limitations of Edit & Continue.
edit: nvm, my info was outdated
edit2: nah, I did remember right Edit&Continue for x64 applications doesn't work in Visual Studio only in the unreleased Visual Studio 2015 (you can get the Release Candidate but the RTM might still be a month or two away)
Edited by Bigpet
on
kirbasin, I had to format my hard drive, and lost the project file. I read in another topic that you would share in the GitHub but I have not found. You could again share the Visual Studio project file?
Thank you for your attention, again!
Thank you for your attention, again!
Edited by Cesar Peixoto
on
frkn
A couple notes
-Since Casey uses unity builds and whole code is just one translation unit, you need to mark the .cpp files(other than win32_handmade.cpp) as C/C++ header so the compiler doesn't try to compile them. You can do this by
Right click the file in solution explorer->Click Properties->Choose Configuration Properties/General from left panel->Set Item Type C/C++ header
I know I'm resurrecting an old thread here but dude, you're a hero.
Another resurrection, I made this:
Visual Studio setup using CMake
It's brain-dead simple to set-up - just dump a few text file at the root, and open the folder in VS... :)
Visual Studio setup using CMake
It's brain-dead simple to set-up - just dump a few text file at the root, and open the folder in VS... :)