VS 2013 and/or Windows 8 support?

[John Hahn]

Hi everybody,

I've been poking around in Helium the last few days and I really like it.  I'll likely be using it (or atleast pieces of it) in some of my projects going forward.   I did notice that Helium doesn't yet support VS2013 and/or Windows 8, and I wondered what the plans are for that.

So, as you guys are probably aware, Microsoft has deprecated the d3dx library, and going forward, all future versions of the DX SDK are going to be bundled into the Windows SDK.  

I'm currently running Windows 7 with VS2013, and I was able to install the Windows 8.1 SDK on my machine, and I was able to compile and run the latest D3D11 samples from Microsoft that use the Windows 8.1 SDK.  My point is that even though it's called the Windows 8.1 SDK, it will still work fine with Windows 7 (and presumably Vista), in terms of the D3D11 part of it.  

So, it might make sense to strip out the d3dx specific stuff from Helium and change the prerequisites for Helium to require the Windows 8 SDK rather than the 2010 DX SDK, and use the DirectX Tool Kit wherever necessary to fill in the hole left by the removal of d3dx.    This way Helium will have proper support for Windows 8/Metro and VS2013.

Thanks,

John

[Geoff Evans]

Hi John!

Removing the d3dx lib would involve upgrading all the device init, draw calls, and shader reflection code to dx11.  Not a small change.  The device init probably isn't too bad (and we could ditch the lost device handling as that just doesn't exist in dx11, thankfully).  The dx9 style draw calls could probably find a new home calling into a dx11 immediate device context, and the reflection stuff I haven't looked at much.  Should you decide to undertake it I am happy to help however I can!

As for 2013, I *just* grabbed a copy and will undertake updating the premake scripts (if necessary) to get it working.  It shouldn't be too bad.  There is a chance that the version of premake already in use by helium works by just using the vs213 parameter.

Cheers,

[John Hahn]

Hi Geoff,

I just got Helium to compile and run with VS2013 and the Windows 8.1 SDK.   Here are the tweaks I did to get it to work:

1)

In all the premake .lua files I found all conditions related to "vs2012" and added support for "vs2013" to those conditions.  This way it sets up the DX SDK and d3dx library dependencies like it does with vs2012.  This is a temporary solution until I get around to removing the d3dx library references.

2)

In ProcessWin.cpp it has a call to the function GetVersionEx.  This has been deprecated in the Windows 8 SDK.

So, I changed this:

OSVERSIONINFO osvi;

memset(&osvi, 0, sizeof( OSVERSIONINFO ) );

osvi.dwOSVersionInfoSize = sizeof( OSVERSIONINFO );

::GetVersionEx(&osvi);

if ( osvi.dwMajorVersion == 6 && ( osvi.dwMinorVersion == 0 || osvi.dwMinorVersion == 1 ) ) // vista and 7

{

// windows vista and beyond somtimes have system software that attach child processes to jobs,

//  and pre-windows 8 you can only attach a process to a single job

flags |= CREATE_BREAKAWAY_FROM_JOB;

}

To this:

 

#include <VersionHelpers.h>

if ( IsWindowsVistaOrGreater() && !IsWindows8OrGreater() )

{

// windows vista and beyond somtimes have system software that attach child processes to jobs,

//  and pre-windows 8 you can only attach a process to a single job

flags |= CREATE_BREAKAWAY_FROM_JOB;

} 

3)

In fbxarch.h (part of the FBX SDK), it uses a macro called WINAPI_FAMILY_ONE_PARTITION, which has also been deprecated.  

So, I changed this:

#if defined(WINAPI_FAMILY)

#if WINAPI_FAMILY_ONE_PARTITION(WINAPI_FAMILY, WINAPI_PARTITION_APP)

#define FBXSDK_ENV_WINSTORE 1

#endif

#endif

To this:

 

#if defined(WINAPI_FAMILY) 

#if WINAPI_FAMILY_PARTITION(WINAPI_PARTITION_APP)

#define FBXSDK_ENV_WINSTORE 1

#endif

#endif

4)

There isn't currently a vs2013 version of the FBX libs, so I manually copy-pasted the vs2012 directory as follows:

C:\Program Files\Autodesk\FBX\FBX SDK\2014.2\lib\vs2012

to

C:\Program Files\Autodesk\FBX\FBX SDK\2014.2\lib\vs2013 

 

5)

I checked the perforce ftp site and they don't currently have a vs2013 binary of the p4api, and when I tried to use the vs2012 binary it threw an error about _MSC_VER being the wrong version.   So, I excluded all the PerforceX.cpp and PerforceX.h files from the Editor project and commented out all references to perforce from the editor code.  I did this in a fairly surgical way so that the editor still functions as normal, just without the P4 features.   It seems to be working ok.

Once I did all that it compiled and ran the example games and editor just fine.  It might make sense to make a new preprocessor macro called HELIUM_P4_ENABLED or something like that and conditionally include the perforce related headers based on the value of that macro and wrap the code related to the perforce editor features in a condition based on that macro.   This way P4 becomes a truly optional feature where we can disable/enable the library dependency and associated features by essentially flipping a switch.  Once they release a new version of the p4api that supports vs2013 then it won't be an issue anymore anyway, I suppose.

Thanks,

John

On Saturday, November 30, 2013 11:53:11 PM UTC-8, John Hahn wrote:

[Geoff Evans]

1)  Sounds good :)

2) How far back is VersionHelpers.h available?  I expect you are going to need to #ifdef to keep the old code in play for pre-win8.1 sdk builds.  Perhaps just use _WINVER (or _WIN_VER, I forget offhand) to gate which code block is used?  While we don't build vs2008 or vs2010 on ci.heliumproject.org, the code does currently support it.  While it might sound crazy, unless there is some architectural reason to not support those platforms, I don't think we should drop support for them if its inexpensive to preserve it.

3) We should avoid modifying the third party headers at all costs.  Consider #define-ing WINAPI_FAMILY_ONE_PARTITION in the helium code (protected by HELIUM_OS_WIN and whatever _WINVER value you used for item 1) before making include statements into the fbx sdk.  There aren't very many places where we include fbx sdk, so this should be pretty manageable.

4 and 5)  For now just add an or condition for "vs2013" and use the vs2012 lib pathing in the premake.  If we use _TARGET directly in the premake then make a local lua variable and set it to _TARGET, but then back to "vs2012" for the lib paths that don't have vs2013 builds yet.  Hope that makes sense.

Thanks!

[Geoff Evans]

I didn't quite address 5.  I want to take a look at that myself, so don't make any checkins or pull requests to address that quite yet.

[Geoff Evans]

Hey John,

I have some bandwidth to get vs2013 going in master.  My main windows instance now has 2013 so I can test it out.  I think item 1 is probably the only one that is nontrivial to redo by hand.  Have you committed changes anywhere I can merge them from? 

[Geoff Evans]

master now fully supports vs2013.  Only a single CRT is loaded into the address space, and all the code compiles and seems to run fine (on windows).