Im using windows 7. I always use warning lvl 4 for my projects, Im quite used to it, and Id like to keep it this way.

I migrated a project from VS 2010 to comunity, and now I have a bunch of warnings, theyr all from windows gdi files.

Using Warning version 18 "fixes" it.

Those are from the folder windows kit/8.0/include/.. Theyr mundane things like using parameters names that are the same as the class member, etc.

Which got me thinking...from where should I be including windows includes from..Im under windows 7, and I have in the windows kit folder folders: 8.0, 8.1 and 10...I was assuming newer versions (8.1 and 10) wont produce warnings ( they just got installed with vs community)

But then I tried 8.1, and its the same thing.

From msdn Im under the impression I shouldnt use windows sdk 10 if targeting windows 7 (it doesnt even show windows 10 under the retarget sdk version option, it actually just shows 8.1..)..so I guess Im stuck with it.

Other than that all went incredibly suspiciously fine...Then I pushed play on debug mode, and frame rate is about 2 fps..e_e"

Cant really debug under vs community like that. The release version is fine...theres anything I can do to make the debug version lighter? on vs2010 the debug version took long to initialize due reading ginormous txt files only, but kept decent fps (>60 fps).. On community its not taking even half the time it takes to initialize, but ~2 fps..gotta be kidding me..Using the super "pause lots of times" profiling technique looks like its my collision system, which was also the slower thing on vs2010, but still dont see any reason to that slow down.

I have some little experience from migrating my engine from vs2010 (that I love to work with because it feels much more light weight than 2015) and the most significant change is the compiler subset. VS2010's c++ compiler is older than the newer VS2015's compiler so implements features and changes that were made last years especcially with C++11, 14 and co. Some compiler tricks may have changed and so the code may be different.

To be quite sure you could first only take a look into the disassembly from both the 2010 and 2015 version to take a look how they differ from each other. Maybe you see why or why not any of those compilers has made optimizations or not.

To identify performance leaks your most usefull option is to profile your code using some kind of "makr a point in profiler and measure how long it takes to the end" mechanism for the parts where you might think is a performance leak and then go deeper in detail.

I personally use the MSVC compiler just for development but making a non-debug version using the LLVM compiler subset. It produces more optimized code than the MSVC compilers do

From msdn Im under the impression I shouldnt use windows sdk 10 if targeting windows 7 (it doesnt even show windows 10 under the retarget sdk version option, it actually just shows 8.1..)..so I guess Im stuck with it.

This isn't the case at all. You can quite safely use a higher version SDK; just #define WINVER and friends appropriately before including any files from that SDK and you're good to go. See https://msdn.microsoft.com/en-us/library/6sehtctf.aspx for more info (and the appropriate define values).

Thats really confusing, here:
https://developer.microsoft.com/en-US/windows/downloads/windows-10-sdk

It says:

This SDK also supports building Windows apps and desktop applications for Windows 8.1, Windows Server 2012, Windows Server 2008 R2, and Windows Server 2008. For earlier versions of the Windows and Windows Phone SDKs, see the Archive page.

Also here:

https://msdn.microsoft.com/en-us/library/mt186161.aspx

It says:

In the Target Platform Version dropdown list, choose the version of the Windows 10 SDK you want to target, or choose 8.1 if you don't want to make any changes. Choose the OK button to apply the change.
Note that 8.1 in this context refers to the Windows SDK version, which is also backwardly compatible with Windows 8, Windows Server 2012, Windows 7, Windows Server 2008, and Windows Vista.

After tweaking features on the debug build, disabling RTCs (leaving RTCu instead of "both") was the only thing that changed the fps, it went even better then on vs 2010 debug. Trough thats not really a solution to anything, it basically kills major debug features from debug build.. tsc

Thats really confusing, here...

The SDK has all the pieces for several targets. You can target any of the four platforms with a pair of values mhagain linked to above, either set as values passed to the compiler or as #define in your project. You can choose Window 8.1 and later, or Server 2012 or later, or or Server 2012 R2 or later, or Windows 10. Each one adds new functionality, and you can use all the old stuff. In MSDN you'll see each function's documentation say minimum supported version of Windows.

They've also (somewhat quietly) got three versions of Windows 10. 10240 is the first, 10586 is the second, 14393 is the third. The second and third are called version 1511 and version 1607, if you weren't confused enough. :-)

Moving on:

After tweaking features on the debug build, disabling RTCs (leaving RTCu instead of "both") was the only thing that changed the fps, it went even better then on vs 2010 debug. Trough thats not really a solution to anything, it basically kills major debug features from debug build

The next thing to do is pull out the profiler. Obviously SOMETHING changed to have you drop from around 15ms per frame to around 50ms per frame.

Profile the code to measure what is actually consuming the time. It might be something in a standard library, or it might be something you didn't expect, like a ton of memory allocations or releases in a container instead of having the memory properly reserved, or perhaps something is now dumping a ton of warnings to the system event log, consuming your time processing and dumping all those strings.

Get friendly with your profiler, they'll be your best friend if you let them.

The profiler was showing mundane get functions as the most sampled ones, I wasnt making any sense out of it...Im sure it doesnt inline on debug, but that is also the case for vs 2010...tried to change from "type" to "const type &" as return value to see if anything changed, it didnt, but then enabling [inline function expansion] to [any suitable] solved the problem. Optimizing debug builds is not as pleasurable as release ones u_u