windows8

Oct 22, 2012 at 8:36 PM

hi,

do you still plan to port your framework over to windows8?

Coordinator
Oct 24, 2012 at 12:15 PM

Yes, I am planning to do this.  At the moment I am trying to find the best way to support Win development without negatively impacting all of the Win7 users out there...  I will start a discussion thread to get some feedback from you guys once I have a plan together.

Oct 26, 2012 at 4:52 PM
Edited Oct 26, 2012 at 7:22 PM

What do you mean with "port over to Windows 8"? Actually, H3 works great on Windows 8, V++2012 and Windows SDK 8.0 (of course if you want use the SDK 8.0 instead the DX June SDK 2010 you must change the path of the linked libraries).

If you mean having a WinRT-Metro support on H3.... Well, that's not so difficult, but at there are some changes to do: even if WinRT is based on Win32 (doesn't matter if Ballmer & co. says it a complete new API, that's fake), the creation of the window, the handling of inputs, event.... all this must change.
 Also the code that use XNAMath must migrate to the new DirectXMath (that is something like a "XNA Math 3.0", but with different prefixes), and all the code based on D3DX must change, since D3DX is not supported on WinRT and finally no more developed by Microsoft (if I remember correctly.... but there are some new open project to replace it, like DirectXTK on directxtk.codeplex.com and DirectXTex on directxtex.codeplex.com).
GDI is also not supported in WinRT....
 All this because WinRT apps must run also on ARM socs with (more or less) the same code, and Microsoft couldn't force ARM partners to develop gfx driver for over 15 years of DirectX :p

Coordinator
Oct 26, 2012 at 9:49 PM

I am planning to expand the library to support several build profiles, such as the following:

  1. Win7 : Win32 (desktop)
  2. Win8 : Win32 (desktop)
  3. Win8 : WinRT

This will require the addition of several project files, but I think now that Win8 is here it is worth the extra effort to support.  Does anyone have any suggestion or input on how they would like to see this work?  I will most likely convert all of the projects to use the Win8 SDK instead of the DirectX SDK, simply because it has the most up to do contents.  Is there any objections to doing this?  Please give me your feedback now, as I will likely start the migration within a week or two!

 

 

Oct 27, 2012 at 10:01 AM

Migrating to Win8 SDK (and abandoning deprecated DirectX SDK along with its D3DX part) is definitely the right step, as well as introducing several separate project files for each build type. 

Oct 27, 2012 at 9:54 PM

No objections for that, no more separate installation of DXSDK is a good thing.

Note also the Chuck Walbourn on the DirectX Blog release a lot of extra stuffs, the last is an updated version Effects11 http://blogs.msdn.com/b/chuckw/

Coordinator
Dec 8, 2012 at 9:33 PM

The projects and solutions have been updated to VS2012, and is now using the Windows 8 SDK instead of the DXSDK.  Please uninstall the DXSDK if you have trouble building the projects!

Dec 10, 2012 at 7:41 AM
jzink wrote:

The projects and solutions have been updated to VS2012, and is now using the Windows 8 SDK instead of the DXSDK.  Please uninstall the DXSDK if you have trouble building the projects!

Great!

Just one note: since Windows 8 SDK, d3dcompiler_xx_.dll and d3dcsx_xx.dll are no more installed in %systemroot%\system32 (and \syswow64), so u must provide the DLLs in the bin folder, otherwise the samples won't work. Don't know why they did this, it sounds like a regression in portability...

Coordinator
Dec 19, 2012 at 11:05 AM
DarkRadeon wrote:
jzink wrote:

The projects and solutions have been updated to VS2012, and is now using the Windows 8 SDK instead of the DXSDK.  Please uninstall the DXSDK if you have trouble building the projects!

Great!

Just one note: since Windows 8 SDK, d3dcompiler_xx_.dll and d3dcsx_xx.dll are no more installed in %systemroot%\system32 (and \syswow64), so u must provide the DLLs in the bin folder, otherwise the samples won't work. Don't know why they did this, it sounds like a regression in portability...


I added a post built event to the Hieroglyph3 project that copies the DLL to the Applications\Bin folder that should take care of this issue.  Chuck Walbourn has a good description about this and instructions about how to handle it on his Games for Windows blog.