By Advanced Technology Group
Published May 4, 2012
Welcome to the Alpha release of the Xbox One XDK. This release, which includes early development hardware and software, enables exploration of the Xbox One development environment through samples and prototypes, and allows initial porting of existing Xbox 360 or Windows projects to Xbox One. Key features in this release include support for building, deploying, and debugging applications on the Xbox One Alpha Kit through Visual Studio 11 on Windows 7.
The XDK is a living system: we will deliver monthly releases with incremental feature updates to the software environment of Xbox One, including samples and technical white papers to help you make the most of these new features.
The application platform for Xbox One is 64-bit and uses DirectX 11, inspired by the Microsoft design style application model on Windows 8. You will have the best experience with this release if you iterate on porting work using a Windows build first. This white paper is intended as an overview of the recommended process for getting started with the Alpha release, with a focus on strategy and references for each of these key porting steps.
We recommend that you pursue a division of labor between porting and exploration. One part of your team should focus on updating your project to a 64-bit title based on Direct3D 11, running on Windows, and built by Visual Studio 11 Beta. The work required will vary from a few days to a few months based on the current state and size of your project.
A second part of your team should focus on prototyping against the Xbox One Alpha XDK. The Xbox One XDK provides all the functionality you need to build apps for Xbox One now, including new project templates for creating prototype projects, remote deployment of applications to the Alpha Kit, and CPU and graphics debugging through Visual Studio 11.
Depending on the level of support your studio provides for other platforms, and how proactive you’ve been in moving to Visual Studio 11 and Windows 8, your project may already be in a state that is ready for Xbox One; you may be able to skip ahead in this paper, if your project has reached one of the following stages:
You have a working 64-bit title based on Direct3D 11 and running on Windows, but you have not upgraded to Visual Studio 11 yet: skip ahead to “Port from Visual Studio 2010 to Visual Studio 11.”
You have a working Visual Studio 11 project that supports Direct3D 11 and is 64-bit: skip ahead to “Using the Xbox One Alpha Kit and XDK.”
You have built your project as a Microsoft design style app for Windows 8: skip ahead to “Microsoft design style apps and Xbox One.”
If you have an existing Xbox 360 codebase that you would like to migrate to Xbox One, there are five categories of porting work you must do to prepare your project:
Create a Windows 7 build of your project in Visual Studio 2010
Port from Direct3D 9 to Direct3D 11 rendering
Port executables from 32-bit to 64-bit
Address permanent and temporary API changes for audio, input, Kinect, and Xbox LIVE
Update your project to build in the Visual Studio 11 Beta
Some game teams maintain Windows builds of their Xbox 360 titles to support multi-platform releases, or simply to enable debugging on Windows without the use of a development kit. If your team has a Windows build, then some parts of categories 1 through 5 may already be completed.
In general, you can parallelize this porting work across your team, dividing tasks by discipline. Your rendering engineers can focus on porting the graphics stack to Direct3D 11 while your system engineers focus on moving from 32-bit to 64-bit. Likewise, if you have build engineers that maintain the overall project system, they can focus on upgrading to Visual Studio 11 Beta. If you take this approach, we recommend that you stage work in separate branches and merge after discrete chunks of work are completed. Moving from 32-bit to 64-bit, for example, can shake out a lot of instability in the build, and partial fixes will generally have cross-breaking impact.
The amount of parallelization will vary from team to team and from codebase to codebase, of course. You may find that the prospects of a titanic-sized multi-part merger are less than attractive. So, if you choose to serialize your efforts, re-order the five categories based on your perceived benefits of staging updates earlier in the process. For example, upgrading to Visual Studio 11 Beta earlier in the process will allow you to take advantage of code analysis (/analyze), to support your porting efforts, as well as the new graphics debugging that provides PIX-like functionality for all of the D3D11 API.
Visual Studio 2010 is the latest version of Visual Studio that is supported by the Xbox 360 SDK. If you have not yet upgraded your Xbox 360 project from a previous version of Visual Studio, we recommend that you upgrade now as a preliminary stage for adopting Xbox One. Ultimately, you will need to have a Visual Studio 11 project for Xbox One, but given that the Xbox 360 SDK does not yet support Visual Studio 11, we recommend that you port your Xbox 360 project to Windows 7 using Visual Studio 2010 first, then follow the rest of the steps in this white paper.
Windows 7 is required for Xbox One development. If you haven’t yet upgraded your development computer from an earlier version of Windows, now is the time to do so. The most relevant hardware and software requirements for Xbox One development are:
1.6 GHz or faster processor
4 GB or more of RAM
DirectX 11-compatible graphics card
64-bit edition of Windows 7 with Service Pack 1
At this stage of porting your project, you will also need to install:
SDK for Windows 8 Consumer Preview (standalone) on MSDN
DirectX SDK, June 2010 on Download Center
We recommend that you add to your solution a new project that is based on the EmptyProject sample in the DirectX SDK, and then migrate existing Xbox 360 files into this project. Doing so will ensure that you have the proper Visual C++ directories and build settings to build against the DirectX SDK. Repeat these steps for each static library or DLL sub-project in your project.
Once you have the necessary changes to your solution, you can attempt to build your project using the new platform configuration. Likely, you are using some Xbox-only APIs that are unsupported on Windows, and you will need to replace these with Windows equivalents.
The largest step in getting your game to run on Xbox One is to port graphics code to Direct3D 11. We recommend one of two porting strategies:
Option 1: Create an API abstraction layer that wraps access to Direct3D
Option 2: Comment out code and port incrementally, system by system
Option 1 is to create an API abstraction layer that wraps direct access to the version of the Direct3D API. The benefit of this option is that it can be used to quickly get your entire engine compiling against Direct3D 11. The down side is that it generates code that doesn’t take optimal advantage of the D3D11 API. As a result, you would need to budget time to restructure your engine once the entire porting process is complete.
The basic strategy of this option is to use a layer that abstracts all Direct3D functionality and manages Direct3D 9 and Direct3D 11 implementations through use of #ifdef. Create version-independent interface types that map to the appropriate interface when compiled for either Direct3D 9 or Direct3D 11.
For example, the abstracted type ID3DVertexBuffer maps to ID3DVertexBuffer9, when compiled for Direct3D 9, and ID3D11Buffer, when compiled for Direct3D 11. Similarly, the abstracted type FORMAT maps to D3DFMT_* and DXGI_FORMAT_*, for Direct3D 9 and Direct3D 11, respectively. With this such a layer, textures would need to be wrapped by a TEXTURE structure that manages appropriate use of resource views of surfaces and shaders. Each member function on the abstracted interfaces of the wrapper would then conditionally make the appropriate calls for Direct3D 9 or Direct3D 11.
If you implement this option, this wrapper will initially contain all of the existing Direct3D 9 code in your engine, and the porting process will then have you implement Direct3D 11 functionality alongside the Direct3D 9 equivalents. At first, simply move existing Direct3D 9 functionality in your codebase into the abstraction layer, and use ASSERT when compiling for Direct3D 11. Centralize all Direct3D types and functions in this abstraction layer; ensure this by removing all instances of #include <d3d9.h> in all other parts of your codebase. This will enable you to compile for Direct3D 9, once you are finished, and test thoroughly to eliminate defects in the wrapper. Then, compile for Direct3D 11, and iterate through the gradual process of implementing Direct3D 11 equivalents for each of the functions in the abstraction layer’s classes.
Option 2 is to comment out large swaths of code and port incrementally, system by system to Direct3D 11. The advantages and disadvantages of this option are opposite to Option 1; it may be a long time before your character and animations systems are running Direct3D 11, but the code written will likely be more optimized.
The basic strategy of this option is to comment out almost all major features of your engine. Remove large features, such as:
multisample anti-aliasing (MSAA)
skinning
shadow-maps
post-processing
screen space ambient occlusion (SSAO)
high dynamic range (HDR) imaging
particle systems and other dynamic content
render-to-texture
Then, focus on re-enabling simple rendering operations, such as background rendering or UI, with pure Direct3D 11 code-paths. Once you’ve implemented (and learned) basic rendering with Direct3D 11, move on to enabling progressively more complex systems, tackling each porting challenge sequentially.
Following is a brief list of porting considerations:
Learn Direct3D 11. You will be more successful if you first read available material on the Direct3D 11 API.
Turn on the Direct3D 11 debug layer with the D3D11_CREATE_DEVICE_DEBUG flag, and watch for descriptive error text in the debug output.
Replace all usage of D3DX.
Texture routines: For offline tooling, use the DirectXTex library. For run-time texture loading, use the DDSTextureLoader classes. Both can be found in the Xbox One XDK samples.
Math: use DirectXMath, the latest version of XNAMATH.
Effects: we recommend that you build and maintain your own system for managing shader linkage data, but you may use the Effects11 sample from the June 2010 release of the DirectX SDK as a starting place.
Shader compilation: Use the shader API directly from D3DCompile.dll instead. Shader compilation at run time in retail apps is strongly discouraged, but you are welcome to use it during development.
Shader reflection: Use D3DReflect and the ID3D11ShaderReflection interfaces.
Replace device creation with a simple hard-coded device that attaches to the HWND. Avoid using complex code for device enumeration, as demonstrated in the DXUT samples framework, because most of this code will be unnecessary and unsupported on Xbox One.
Replace Direct3D 9 textures and surfaces with Direct3D 11 resources and resource views. During initial porting, consider using a structure for texture abstraction, and remove special handling around Direct3D 9 surfaces. Later, remove the abstraction when more of your engine using Direct3D 11
Replace the resource semantics Lock and Unlock of Direct3D 9, with those for Direct3D 11: Map, Unmap, and UpdateSubResource. Static resources should be created as D3D11_USAGE_IMMUTABLE and filled with data at creation time. Dynamic resources should be created with D3D11_USAGE_DEFAULT and modified by calling UpdateSubResource.
Replace Direct3D 9 vertex declarations with Direct3D 11 input layouts, which map directly to a shader input signature. During initial porting, defer creation of input layouts until needed by a Draw call. Later, evaluate the possible shader input signatures in your engine in order to create and manage the right set of layouts to maximize reuse across Draw calls.
Replace SetShaderConstant-style functions from Direct3D 9 with constant buffers from Direct3D 11. During initial porting, create a single constant buffer that captures all expected inputs. Later, organize shader variables into constant buffers based on their frequency of update to minimize the bandwidth used for updating constant data.
Be aware that constant buffers are packed on boundary of 4 floating-point values.
Compile shaders with the shader model 4_0 profile with backward-compatible mode enabled (/Gec), and rewrite to address any warnings or errors that appear. Shader model 4_0 is recommended to ease initial porting work; future engineering can upgrade shaders to 5_0 to take advantage of its enhanced feature set.
Ensure that shader signatures match tightly and in the correct order across pipeline stages.
Replace UP Draw variants by creating large vertex and index buffers, to be used as wrappers, with the attributes D3D11_USAGE_DYNAMIC and CPU_ACCESS_WRITE; then, use Map and Unmap with MAP_WRITE_NO_OVERWRITE to write data at the current byte offset.
Replace SetRenderState calls in Direct3D 9 with state objects in Direct3D 11. During initial porting, consider caching render state then perform lazy state object creation before Draw calls. Later, move to a state object management system for state objects that maximizes reuse of identical states across Draw calls.
Replace missing texture formats with the closest Direct3D 11 equivalents. DirectXTex can assist with some format conversion, but some formats may require re-exporting from original asset data.
In builds based on Direct3D 11, be very thorough to eliminate Direct3D 9 and Direct3D 10 across your entire project, including run-time components that connect with development-time tools, such as level editors. Use of Direct3D 9 or Direct3D 10 outside the graphics engine can cause the greatest pain in the porting process.
For more detailed information, see the following resources:
Migrating to Direct3D 11 on MSDN
DirectX 11 Technology Update on Download Center
Advanced Rendering Techniques with DirectX 11 on Download Center
Best Practices for DirectX 11 Development on Download Center
When migrating existing code projects to 64-bit native platforms, the compiler and the operating system are your most powerful tools. Initially, every effort should be made to migrate your existing code base to a 64-bit edition of Windows 7 or Windows 8 and ensure that the game code and content works correctly when running on Windows in a 64-bit native environment. Individual code bugs are usually straight forward to fix, but when faced with porting a large codebase, sheer scale can quickly become a significant problem; so, leveraging all the available tools is essential. Pointer problems will often manifest as run-time issues, and at some point, you must run the built code to iteratively find classes of problems and fix them.
Following is a brief list of porting considerations:
The two general areas of concern when examining your code for 64-bit compatibility are address calculations and pointer arithmetic.
Write your code to compile cleanly with warning options /WX and /W4. Doing so will help to catch 64-bit related problems that appear as warnings at compile time but result in crashes at run time.
Use static code analysis (/analyze), a feature in Visual Studio 11.
Use Application Verifier, a tool from the Windows SDK.
Carefully examine all parts of your code that load binary files for offsets that are re-mapped to become pointers. Correcting these may require expanding the offset slots, branching file formats between platforms, or removing the offsets altogether.
When pointer sizes grow, the layout of your structures will change. As a general rule for structure layout, you should order fields by type size, with largest types first.
Be sure that allocations and skipping from structure to structure with pointer arithmetic is done by using sizeof.
Carefully examine uses of sizeof across your code-base. These are likely where pointer arithmetic is taking place, and you should eliminate any possible truncation issues.
Carefully examine memory management systems, block allocators, smart pointers, and heap compaction systems for implicit pointer conversions or truncations. These areas are likely to be the biggest sources of problems with pointer sizes.
Maintain a single codebase for both 32- and 64-bit at your own risk. The code branching necessary to serve both platforms may make the code challenging to read and keep free of defects.
Carefully examine scripting systems that bind to game engine objects written in C++ for possible issues with pointer truncation.
Use indices instead of pointers when 64 bits of precision are not needed to represent all of the values of a data field—which is quite often in game development. Indices provide better cache performance and require less memory for storage. For dynamic structures that require addressing non-contiguous memory, consider a block allocator that returns indices or takes indices to return a structure.
For more detailed information, see the following resources:
64-bit Made Easy on Random ASCII, a blog
The Xbox One XDK requires Visual Studio 11 for building, deploying, and debugging projects to the development kit. While we recommend that you move your existing project to Visual Studio 2010 as a preliminary step to porting to Xbox One, you may find that moving straight to Visual Studio 11 works better for your project. The best choice will vary by project, based on its size and the need to maintain parity with Xbox 360.
You may also decide not to upgrade projects for tools, such as your content pipeline and level editors. If you choose not to upgrade these, you will need to create separate solutions and projects to allow for Xbox One runtimes to be built and deployed fully for Xbox One. Be wary of sharing code between tools built in Visual Studio 2010 and the runtime components built in Visual Studio 11, because such sharing can lead to frustrating incompatibilities at build or execution time.
Following is a brief list of porting considerations:
Updating to use the newest C runtime may pose the biggest porting challenge for your project. Beyond simply correcting the code changes necessary to avoid new compiler warnings and errors, it is generally challenging to port a project, in pieces, to a new C runtime . This is because memory and objects allocated in a module that links to one version of the C runtime can’t be passed to a module with a different versions of the C runtime. So, plan to upgrade your entire project simultaneously, or create safe wrappers around modules that do not yet have a version that is compatible with Visual Studio 11.
Visual Studio 11 ships with a version of the Windows SDK that replaces most of the DirectX SDK. If you have an existing project in Visual Studio 11 based on the DirectX SDK (as directed earlier in “Create a Windows 7 build of your project in Visual Studio 2010”) you will need to modify the Visual C++ directories to point to the Windows SDK, instead of the DirectX SDK, for all headers and libraries.
You can target the older compiler toolset (v100) from within Visual Studio 11. When you are ready to move to the new toolset (v11), right-click the project in Solution Explorer, and then click Upgrade VC++ project to upgrade your project.
If you are migrating settings by directly modifying the .vcxproj file, ensure that you are generating unique GUIDs where appropriate.
Delete all built binaries and remove Visual Studio hidden files (.suo, .sdf) after making any project changes.
For more detailed information, see the following resources:
How to: Upgrade Visual C++ Projects to Visual Studio 11 on MSDN
Using DirectX SDK projects with the Microsoft Visual Studio 11 Ultimate Beta on MSDN (a topic in the second half of Where is the DirectX SDK?)
If you’re porting from an Xbox 360 project, you’re most likely already using the required audio and input APIs for Xbox One, XAudio2 and XInput, respectively. These APIs are also supported on Windows as source-compatible cross-platform APIs, and they can be used in your Windows builds during the initial porting effort. On the other hand, if you are porting an existing Windows game, you may be using older audio and input APIs that are not supported on Xbox One, and if so, you will need to move your game to XAudio2 and XInput.
Following is a list of porting considerations:
Replace all run-time functionality of the Microsoft Cross-Platform Audio Creation Tool (XACT) with XAudio2. XACT is no longer supported for audio development.
Replace all use of DirectInput with XInput.
Replace all use of DirectSound with XAudio2.
Comment out XINPUT2 functionality and use only the base XInput API. XInput2 is not currently supported on Xbox One.
In a future version of the Xbox One XDK, a new WinRT-based Gamepad API will be released that replaces XInput. When available, you should switch to the new API as soon as possible. However, to support ease of porting legacy projects, XInput will remain available through several more XDK releases.
For compatibility with Windows 8, XInput will remain available to shared-resource applications. (For more information, see “Exploring the new Xbox One Application Model” later in this paper.)
For more detailed information, see the following resources:
Audio Redirect: Transitioning from DirectSound to XAudio2, a white paper on GDN
XAudio2: High-Performance Considerations, a presentation from Gamefest 2010 on Download Center
Xbox LIVE is a central part of the Xbox One experience. Xbox LIVE continues to evolve in new and exciting ways, now supporting services with representational state transfer (REST) architecture across devices and using single sign-on (SSO) authentication. Xbox LIVE is not supported in the current Alpha release of the Xbox One XDK, but it will be available in an upcoming release.
To prepare for the future release of Xbox LIVE APIs for Xbox One, review the following presentations from Gamefest 2011:
Look Ma, No XLSP: The Future of Connecting to Web Resources from Your Xbox 360 Console on Download Center
Accessing Xbox LIVE Using RESTful Web Services on Download Center
Asynchronous Gaming with Xbox LIVE on Download Center
Natural user input (NUI) is also core to the Xbox One experience. If you haven’t yet spent time examining the capabilities provided by gesture and voice input, be sure to explore the current XDK, along with the following recommended talks from Gamefest 2011:
The Magic Behind Kinect on Download Center
Gesture Detection Using Machine Learning on Download Center
Making a Five Star Kinect Game on Download Center
The Xbox One Alpha Kit is the first iteration of the Xbox One platform, and as such, it provides a transitional step for a game running on Windows 7 with Direct3D 11 to a game running on Xbox One. Although we are still at the beginning of our journey with Xbox One, the Alpha Kit is intended to provide a conservative, first estimate of the hardware in the final console. Furthermore, as operating system and XDK updates become available, the Alpha Kit will enable you to take advantage of the new features of the platform and develop your Xbox One-specific code. You can prototype new game experiences that are enabled by Xbox One’s unique capabilities now, before they are fully realized on final Xbox One hardware.
The Alpha Kit, XDK, and Visual Studio 11 constitute a functioning development environment: you will be able to develop using Visual Studio 11 and deploy and test on the Alpha Kit. However, you will probably find that you don’t immediately have all the tools and functionality that you have grown accustomed to having with Xbox 360. New tools and new developer features will be released in each update to the Xbox One XDK, adding functionality that is both new and similar to Xbox 360 tools. Using the Alpha hardware and Alpha releases of the Xbox One XDK now will allow you to provide early feedback to Microsoft to help drive development of the platform based on your experience and expertise.
The Alpha Kit consists of a custom built PC, Visual Studio 11, and the Xbox One XDK. Installing the software components on your development computer is straightforward. For the most part, setting up the Xbox One Alpha Kit is like setting up a new PC, with the main difference being that you will install a new operating system. In particular, installing the Xbox One operating system is more like “re-flashing” an Xbox 360 console. Following is a summary of the steps that will get you up and running with the Xbox One Alpha hardware:
Software downloads, documentation, educational and support resources are available on Game Developer Network (GDN). If you need access, contact your developer account manager.
Download Visual Studio 11, the Xbox One XDK, and the Xbox One Recovery Utility.
Install the OS on the Alpha hardware by booting from a USB storage device that has been prepared using the Xbox One Recovery Utility. This process is analogous to re-flashing an Xbox 360 development kit using a recovery disc. After you have prepared your Recovery USB, you can use it to recover multiple Alpha Kits just as you would use a recovery disc with Xbox 360 development kits.
Install Visual Studio 11 and the Xbox One XDK on your development computer.
Use one of the Xbox One project templates to easily build and deploy your first Xbox One project.
Download the Xbox One samples from GDN.
For more detailed information, see the following resource:
Once your team has a Windows build of your project that is ready for Xbox One, and you have development kits ready for use, it’s time to start building your project for Xbox One.
There are two general approaches for adding Xbox One configurations to an existing project. The recommended approach is to create entirely new projects from the Xbox One project templates by using the New Project dialog in Visual Studio 11. Files can be then be added to the new project from the existing one manually in the Visual Studio project UI, by multi-selection in the Add Existing Item dialog, or through cuting & pasting of the appropriate <ItemGroup> elements in the project (.vcxproj) files. Each project and sub-project dependency should be migrated, choosing the appropriate project template for static libraries and DLLs. This approach ensures that you pick up the correct project options for Xbox One, but it can be more tedious to incorporate into solutions that build for several platforms already.
The second approach is to add the Xbox One platform configuration as a new build target for an existing project, and also for each dependent sub-project. The challenge of this approach is that existing project settings may be incompatible with Xbox One in ways that are not easy to troubleshoot. You also must add two files, package.appxmanifest and Xbox OneConfig.xml, with appropriate data. We recommend that you generate a comparison project via the Xbox One project templates, and carefully review settings in your main project files against it.
Following is a list of porting considerations:
The first Alpha release of the Xbox One XDK (February 2012) did not have support for the “Xbox One” platform configuration in Visual Studio. We recommend that you upgrade to the latest release of the XDK before upgrading your projects.
If you are maintaining other platforms in the same solution or project, ensure that you are migrating settings to the Xbox One platform or configuration from an existing project for a 64-bit edition of Windows.
If you are migrating settings by directly modifying the .vcxproj file, ensure that you generate unique GUIDs where appropriate.
Delete all built binaries and remove Visual Studio hidden files (.suo, .sdf) after making any project changes.
The Xbox One XDK provides a set of APIs that are largely based on Windows. We recommend that you research the new Windows Runtime (WinRT) and build your understanding for this new model of API exposure to applications. Also, familiarize yourself with the application model and process lifetime management (PLM) of Microsoft design style apps on Windows 8, on which the Xbox One model is closely based. In all educational endeavors, the Xbox One samples on Game Developer Network (GDN) are your first and best resource.
The new application model presents a porting challenge for existing applications. A number of Win32 APIs used in existing Xbox 360 and Windows applications are no longer supported and will need to be replaced with equivalents on the new platform.
The Xbox One XDK shares many of the headers with Windows, so the APIs that are available on both platforms are compatible. However, not every API that is in Windows is supported on Xbox One, and Xbox One has some APIs that are not supported in Microsoft design style apps on Windows. The mechanism used to define which API sets are supported is known as API partitioning and is similar to what Windows 8 uses to differentiate the APIs available to Microsoft design applications from those for Desktop applications.
An application indicates which family, a set of one or more partitions, it targets by defining WINAPI_FAMILY and setting it to one of the values shown in the following table.
| Value | Family |
|---|---|
| WINAPI_FAMILY_DESKTOP | Windows Desktop applications |
| WINAPI_FAMILY_APP | Microsoft design -style apps |
| WINAPI_FAMILY_TV_TITLE | Xbox One Exclusive Resource Apps |
| WINAPI_FAMILY_TV_APP | Xbox One Shared Resource Apps |
These partitions provide you flexibility to evaluate the differences in API sets between platforms. The Desktop partition (_DESKTOP) is closest to what you are familiar with either from Xbox 360 or from earlier versions of Windows. The Microsoft design style partition (_APP) reduces the Win32 and COM API sets to a more manageable and focused set that are intended for use in the contained environment of Microsoft design style apps. Xbox One diverges from these sets with two new partitions, depending on the type of Xbox One app you are building.
Following is a list of porting considerations:
When first porting your code base to Xbox One, it may be beneficial to compile for Windows Desktop applications (WINAPI_FAMILY_DESKTOP). This allows you to get your code base compiling earlier using the Xbox One XDK, enabling you to work on different areas of the engine at the same time.
Once you start targeting Xbox One Shared Resource Apps (WINAPI_FAMILY_TV_TITLE), you’ll receive compile-time errors for all of the APIs that are missing from your project. In some instances, the API has been removed and replaced with a preferred and obvious alternative. Examples of this would be the replacement of CreateFile with CreateFile2, or the need to use CreateEventEx over CreateEvent. In other cases, the feature is not yet implemented, and it will become available in a future release.
Consider creating alternate project build configurations so that you can easily switch between WINAPI_FAMILY_DESKTOP and WINAPI_FAMILY_TV_TITLE while you iterate on porting components to the new API model.
Support for WINAPI_FAMILY_DESKTOP will be removed in a future Xbox One XDK release. It is included now only to assist in early porting work and platform bring up.
Work to bring all project dependencies to WINAPI_FAMILY_TV_TITLE, including third-party libraries. Inconsistences in API family usage across the project could cause pain in the future when WINAPI_FAMILY_DESKTOP is removed. Be especially careful with static libraries and with DLLs that are shared cross-team or acquired from third-party tools and libraries vendors.
The Xbox One project templates provided in the Xbox One XDK define WINAPI_FAMILY = WINAPI_FAMILY_TV_TITLE by default. If you are building your projects outside of Visual Studio and need to target other partitions, you will need to define WINAPI_FAMILY in your build scripts.
For more detailed information, see the following resource:
As described earlier, the Xbox One application model is similar to the application model of Microsoft design style apps on Windows 8. If you have already ported your game to run as a Microsoft design style app on Windows 8, then you’ve already met all of the requirements described earlier in “Preparing your current project for Xbox One,” and you are nearly ready to target Xbox One. If you haven’t ported your game to Windows 8 and Microsoft design style, you may find it easier to port to Microsoft design style on Windows 8 first to adapt to the necessary Win32 and COM API changes as described above.
You will find a few notable differences in the traditional Win32 APIs available to Xbox One apps that are not available to Microsoft design style apps on Windows 8; these include:
Heap management (HeapCreate)
Virtual memory management (VirtualAlloc)
Threading (CreateThread)
Synchronization Primitives
For more detailed information, see the following resources:
Application Lifecycle, of Microsoft design style apps on Windows 8, on MSDN
Sample: Marble Maze, a Windows Store game in C++ and DirectX on MSDN
Now that you’ve ported your existing project, you’re ready to experience everything that Xbox One has to offer. What you’re seeing in the current release is only a glimpse of where Xbox One is headed in the coming years. Expect to see new tools and new APIs on a regular basis in updates to the Xbox One XDK, including a brand new way to connect your game with Xbox LIVE and an evolution of Kinect on a grand scale. We’re thrilled to work with you and are committed to creating the technologies you need to bring epic entertainment experiences to the Xbox universe.
To stay informed of all new developments for Xbox One, add Game Developer Network to your favorites, and visit GDN often.
We know you’ll have questions, comments and suggestions as you build the next great experience for Xbox One. We encourage you to visit the Xbox One Developer Forum on GDN and start a conversation with us.
We look forward to helping you deliver amazing experiences on Xbox One. See you there!