I use this setup:
1 project for Library with all cpp files market as text and only the handmade.cpp marked as compilation unit
1 project for win32 layer only

Then added the debug compiler flags in the settings.

I attached my solution and project files in a zip. If you add the SLN dir next to the handmade dir then all should work fine (in vs 2013)

Thanks for the help guys! This case is a bit more boring, (day 15, IO) at the point where I stopped, Casey made declaration of 3 functions in handmade.h file. However, the definition was made in win32_handmade.ccp file. I figured the DLL solve this problem, but from what I understand, the DLL is a future issue yet.
Does anyone remember how did you solve this problem of delaration in handmade.h and definition in the win32_handame.h file ??

PS. by curiosity, I uncompressed day 88 sources files in the project directory provided by kirbasin, and it worked perfectly!

Yeah I started adding the solution I attached on day 30 so I can't help you earlier there. Just make sure your codefiles are compiled only once. Because they are #included in the handmade_win32.cpp they don't need to be compilation units by themselves. Another thing could be the ordering of the includes themselves, or maybe it was just something introduced by casey and fixed later.

I believe that soon will change, is a part of file IO for debuging. I moved everything to win32 layer, and it worked perfectly! I test the "template" of kirbasin project and works fine after day 21. I believe that difficulties have been overcome!
Thank you all for the help!

Hi,

Was completing a C++ cert so am far behind (on day 11).

Read over the thread, but can't get a good sense whether or how I can set up and use only VS2013.

If someone knows for sure:

a) "now you can use Visual Studio only, starting on day #"

b) "here are the steps to prepare your VS 2013 for following along with Handmade Hero"

That would be a very nice thing! I kinda miss my good friend Mr. Intellisense.

Msft just announced that Visual Studio Code app, supposedly it's a free editor/debugger that works on Linux/Mac/Windows (it seems more light weight than the standard Visual Studio).
I'm curious to see if that makes HMH cross platform development/debugging easier...

It does not compile/debug C or C++, only highlights syntax. It's mostly for web development.

Right, I just saw that. Ah well...

While having bunch of new tools nice effort from MS, I feel that these tools are made with wrong tech. Look at this new Visual Studio Code app - it is built with Atom editor technology underneath. And Atom editor is build as Chromium desktop framework. Meaning all the logic code is running in JavaScript. So everything you write and do in VSCode, is happening in JavaScript, not native code. And I think I don't need to explain here why building development tools in JavaScript is not the best thing...

Well to be fair, VSCode seems to be aimed at web development. So it makes some sense. And it could be worse, it could be in Java :D

I am still scratching my head as well though, towards whom the Visual Studio Code is aimed. And how big of projects you are supposed to develop with it. So far I think the name is misleading, not having too much in common with the full Visual Studio yet.

Arg, I got to the .dll day so I checked out this post.

I created an extra project in solution explorer so I have a win32 project and a dll project in the solution. The exe (win32) is dependent on (dll) to build.

I copied all of the settings for compiling so the flags are the same for building in both.

Now, right now, the solution explorer shows (win32) - win32_handmade.cpp / (dll) - handmade.cpp and handmade.h. Are both unity builds and I should remove handmade.h from (dll) or it's fine as it is?

I didn't quite get the pdb file stuff - do I need to muck about in Properties->Configuration Settings->C/C++->Output files? Or is it talking about the pdb generated in Properties->Configuration Settings->Linker->Debugging?

Anything else I need to flip/set/modify?

Thanks!

Putting header file in Visual Studio doesn't do anything. It is only for your convenience - to be able double click on it and edit. You should know that header files are not compiled normally, they are #include'd in other files.

You need to do something similar as build.bat does for pdb files if you will want to use hot reloading. Otherwise debugger will lock pdb file and linker won't be able to write new pdb file when you are debugging. If you don't want, then you can leave default settings for pdb stuff.

Ok good to know! Thank you!

Oook that's weird, the VS build/run gives me the soundbuffer debug markers, but NOT the gradient and NOT the sound.

Building from command line and debugging in VS is totally fine...

I debugged the area where win32_handmade.cpp loads the handmade.dll and it fails. Is there something in the compiler/linking setup that addresses this failure?

Have you put both files - exe and dll in same directory? If dll builds in some other folder exe obviously won't be able to find it.