I have been trying to follow along with the series but everyday I have to give up after 10~15 mins as I am not used to using a text editor and Casey is pretty fast. I am new to programming and prefer using Visual studio editor as it gives intellisense which makes things easier to type and navigate(just a personal preference). I want to set up the project in VS so that I set it up exactly as Casey's bat file but I am a bit overwhelmed by all the settings VS asks you to do. Is there anyone who has set up a VS project that can help me with the settings ?
I don't have VS handy right now, but instead of convincing the IDE to build the solution with the exact same settings, you can add the build.bat as an "External Tool" and run that instead. This is for some older version of VS, but it looks like it could serve as a starting point.
Thank you for the quick reply. I have been looking into that solution(makefile) as well. I found something similar in the forum but I cant even get that to work. It appears to be fairly simple to set up but when I try to compile it cannot find the win32_handmade.cpp. There appears to be some location resolution problem that I cant seem to figure out.
That sounds like the working directory isn't set correctly. From the screenshots in the article I linked, it looks like VS calls this "Initial Directory". I can't remember off the top of my head what the correct working directory for Casey's build.bat is, but I think it's either the root directory of the project (e.g. "W:\handmade") or the code subdirectory ("W:\handmade\code").
Hi, i have just created solution files for 32bit and 64bit builds and attached the solution directory to this post. Since i don't have permission to redistribute the code, i just added empty files. You can paste the code to respective files.
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
-To set the compiler and linker options easily you can use the command line options instead of setting properties one by one.
For compiler options;
Right click on project file-> Click Properties->Expand Configuration Properties/C/C++/Command Line and paste the switches you want to use to additional options textbox
For linker options;
Right click on project file-> Click Properties->Expand Configuration Properties/Linker/Command Line and paste the switches you want to use to additional options textbox
I just created this solution files so there might be mistakes. Let me know if you have any problems. Hope this helps.
Thanks to both of you I was finally able to set up a VS 2013 project. I went ahead and used frkn's solution files and project files and rest was good! I am still looking to use the .bat solution as well as it seems cleaner to set the compiler/linker options at one place but as frkn pointed out in his message we can do it in the options textbox so this will work for me for now.
Thanks for your help. Hopefully, now I will find it faster to code along with Casey and not be bogged down by trying to learn a new editor.
4 years, 10 months ago
on Dec. 20, 2014, 1:48 a.m.
I don't think it's possible to use one project for building both exe and dll, at least that's not what Visual Studio would like you to do.
Instead I just added a new project that builds DLL to my HandmadeHero solution. I moved handmade.cpp and handmade.h to that new project and made my initial project (one that builds EXE, with win32_handmade.cpp and win32_handmade.h) dependent on this new DLL project so that EXE is always built after DLL.
You should also not forget to set up configurations and project properties for this new DLL project because they will not be copied from your EXE project. When you have several projects in your solution with common compiler and linker flags it's easier to use property sheets, I guess.
As for PDB filename generation - I've spent several hours looking into this and couldn't find anything. Visual Studio $ and % macros don't provide anything suitable that can be passed to PDB name, command line textbox in project properties doesn't interpret %date% and %time% correctly so you can't just pass what Casey wrote in build.bat. So far I was able to follow Casey 1:1 in Visual Studio, but this one is a real head scratcher.
Here are my solution and project files just in case:
Didn't know you could invoke the .NET Framework like this in VS, my solution was to let the platform code copy dll+pdb into a temp dir and deleting the pdb in the $(OutDir) so the debugger would use the pdb in the temp dir. This had the downside that VS had to relink the dll every time I wanted to debug.
I've been trying to follow along in VS as well, but have been using the makefile solution instead of setting all the build settings in VS.
I've got stuck now on the dynamic code loading segment (day 022) and was going to try the multiple project in one solution method you guys are using, but I have a question:
How do you recompile the dll while you are running the debugger on the win32 exe? When I try to do this, VS always asks me if I want to stop debugging first, which defeats the point. This happens whether I use my makefile solution or have multiple projects and chose to build the dll project only.