I'm porting the code for Caveman 3.0 from MSVS 2012 express to MSVS 2015 express

a few questions...

1. i noticed that under the project properties - general - target platform version, the only choices are 8.1 and 10. will code compiled for 8.1 run on win 7? should i care?

2. got the code compiling ok. now its time to link. it can't find winmm.lib. i was building against the win 7 SDK. should i be building gainst a newer version? again, what about backward compatibility with older versions of windows? as far as the win API calls i'm using, i think the newest is vista or later, so the code is very backward compatible. what older windows version should i worry about? win 7? anything older? although win7 just expired, i'm thinking it may be a bit soon to drop support for it until the installed base catches up.

EDIT: according to the steam hardware survey...

http://store.steampowered.com/hwsurvey/

about 34.22% of steam windows users have win 7.

guess i'd better keep win 7 support?

and my Target Platform Version defaults to 8.1 and I have no problems with compiling/running on Windows 7

that's encouraging.

i checked out the win sdk's and it seems i need to build against the win 7 sdk.

so i installed win 7 sdk and linked winMM.lib.

when compiling, i got some warnings about some cdecel type stuff in the d3d9 headers re: D3DXMATRIX!6. followed by "how to suppress new warnings".

other than that, sin, cos, atan, and abs seem to no longer be overloaded to take floats, just doubles.

and that was it. intelisense was slow as molasses, it thought my script files were c# code. a 140,000 file was uneditable. a change of file extension fixed that, and now i edit the script files in text mode.

i installed june 2010 dx9 sdk, the include dirs were already setup in the project copied from the old PC. once i installed win 7 sdk, eevrything was fine.

until....

continue saved game crashes on load, new game crashes on encounter. that's compiling with VS express 2015, not community, targeting win 8.1. multi processor linking, and runtime link gen (no incremental) were the only project setting changes.

so obviously, 2015, and the older code don't get along. i compiled with all warnings on, and only turned off treat warnings as errors when it was down to the d3d9 cdecel warnings. i forget what the exact syntax is _cdecel ? its a calling convention mod as i recall. C style? reverse order param push on stack? something like that?

the places where the game crashes are the first places it might try to use a d3dxmatrix16. i didn't bother tracing it.

so i downloaded and installed msvs2012 to the new PC (i7-6700K gtx1080). rebuilt using 2012, compile times are down from 10 secs to 1 sec. link times are down from 2+ minutes to 10-15 secs. ~150K lines of source. thats compared to a dual core AMD E300 at 1.3Ghz.

game works fine compiled with 2012.

just finished making render, animations, input, AI, movement, and turning, use a variable framerate (currently set to 60 fps). everything else in update still runs at 15Hz.

an accumulator is used, similar to fixed timestep. but it accumulates fractions of a 15Hz update every game loop. when the accumulator reaches 1, it executes one 15Hz update call, and subtracts one from the accumulator..

i'll probably make the framerate user definable. that way they can run as fast as their monitor, or slow it down a tad for a slightly slower but more consistent framerate. right now the code should handle desired_framerate values of 1 through 1000 FPS. but vsync is on. perhaps i should make vsync optional too? there's also a testing cheat to turn off the framerate limiter. but using desired_framerate scales update to the desired_framerate.

needless to say, the game is much smoother at 60 fps vs 15 fps.

should vsync be optional?

and now that its all fast and buttery smooth - now what? am i down to making better plants models? <g>.

how can i tell how much PC is required to maintain 60fps?

i haven't check the docs,but on this new PC, there's a digital readout on the MSI motherboard, says 26 right now. i think it may be current clock speed. it only hits 3.0 when running Caveman.

You can build against the Windows 8, 8.1 or 10 SDKs and set some #defines in your project (before including windows.h or any other SDK headers) to target any lower version of Windows; see https://msdn.microsoft.com/en-us/library/6sehtctf.aspx for more info. In your case:

#define WINVER 0x0601

#define _WIN32_WINNT 0x0601

And now the more recent SDK will only include up to Windows 7 stuff.

The DirectX SDK has been incorporated into the Windows SDK and D3DX has been removed since after the June 2010 SDK. I'd consider it a miracle that it worked on 2012, and certainly wouldn't expect it to work on any later version.

A trick I used in the past (in this case a DirectX 8 SDK on Visual C++ 2008) is to put the SDK include and lib directories at the bottom of their respective lists. But like I said, it's a trick, it's not guaranteed to work, and is almost certainly unsupported.

Reality is that you'll need to begin porting code away from D3DX, and how easy or difficult this is depends on how much D3DX you've used. Some tips here: https://blogs.msdn.microsoft.com/chuckw/2015/08/05/where-is-the-directx-sdk-2015-edition/

how can i tell how much PC is required to maintain 60fps?

Reality is that you'll need to begin porting code away from D3DX

yeah - i know ! <g>.

but for the moment, d3dx is built off of dx9, and you can install the DX end user runtime on win 8 and win 10 boxes and it will work just fine.

https://www.microsoft.com/en-us/download/details.aspx?id=35&nowin10

so dx9 is still an option for win 10.

but eventually i'll need to port to something newer, or start using engines.

you can always get folks to alpha test.

guess its time for another public beta! <g>.

actually, i think i'll implement the user definable desired_fps. everything is already declared as variables, all i have to do is add code to let the user enter a desired_fps, then recalc ms_per_gameloop_iteration and the update_multiplier.

ms_per_gameloop_iteration is the delta time for animations, and the limit for the framerate limiter. update_multiplier is how much the old 15Hz movement and turn rates get multiplied by, based on the desired_fps.

that way the user can specify any desired_fps, 1 thru 1000. and if its faster than the PC can do, it will slow down like a conventional lockstep loop. if its not, the game will run at that speed. this way they can choose a speed that is as fast a possible while still being a sufficiently consistent framerate for a smooth gameplay experience.

so what about vsync? let them turn it off if desired?\

will a variable framerate work with gsync etc? ti really doesn't pay any attention to vsync. it uses query_performance_counter. right now it looks like i need to convert the framerate limiter to floats or doubles. 17 ms gets me 58.9 fps, and 16 ms gets me 62.something. need a 16.some-odd ms limit.

...but for the moment, d3dx is built off of dx9, and you can install the DX end user runtime on win 8 and win 10 boxes and it will work just fine.

https://www.microsoft.com/en-us/download/details.aspx?id=35&nowin10

so dx9 is still an option for win 10.

but eventually i'll need to port to something newer, or start using engines.

Typically if I'm using D3DX (and there is some useful stuff in there that was never properly replaced, like D3DXLoadSurfaceFromSurface) what I'll do is start a loop counting down from 43 to 24, try a LoadLibrary on "d3dx_%i.dll", where %i is the loop counter, then a bunch of GetProcAddress calls to get the functions I want. I'll then copy & paste the required header stuff into one of my own headers.

This works fine on newer versions of Windows, Visual Studio and SDKs, and also has the bonus of working fine on PCs that may have different runtime versions installed.

For other stuff, like D3DXMATRIX, now really is the best time to start migrating away. Even the dogs in the streets have their own matrix library these days, and so long as it's binary-compatible with D3DMATRIX (if you're using FFP) or you can get a float* from it (for shaders) it'll work fine. Even GLM will work (interesting fact: the reverse is also true and I've used D3DXMATRIX in OpenGL code in the past). So for your math library stuff, you can migrate away without ditching the rest of D3DX.