Download [PDF 1.26 MB]

Intel® Graphics Performance Analyzers (Intel® GPA) Platform Analyzer visualizes the execution profile of the tasks in your code on the entire platform over time, on both the CPU and GPU. This helps you understand task-based issues within your game, enabling you to optimize the compute and rendering tasks across both the CPU and GPU. Intel GPA Platform Analyzer uses trace data collected during the application run to provide a detailed analysis of how your code executes across all threads and correlates the CPU workload with that on the GPU.

Previously, we shared how to do an analysis using the Intel GPA Frame Analyzer for DirectX*. In this article we are going to do a walkthrough of how to do CPU-bound offline analysis of the workflow.

Analyzing a trace capture using the Intel® Graphics Performance Analyzers Platform Analyzer

Click Analyze Application as shown below. This feature allows you to browse the binary to the game that we want to analyze and run it. The Intel GPA monitor injects the code into the game to extract the profiling data.

1. Analyze application window

If your application is CPU bound, capture a trace so you can open in Intel GPA Platform Analyzer and do profiling for that application. If the application is GPU bound, capture a frame. If you are using Intel GPA System Analyzer, click the camera button for capturing frames or click the red record button for capturing traces. In you are using HUD shortcut keys, by default Ctrl+Shift+C is the hot key for frames and Ctrl+Shift+T is the hot key for trace capture.

We will do a trace capture to analyze using the Intel GPA Platform Analyzer as shown below.

2. Intel GPA System Analyzer

Open the Intel GPA Platform Analyzer. On the left side is a list of traces. Double-click  the latest trace captured. Once the trace opens, you will see a few different windows as shown below.

3. Intel GPA Platform Analyzer: opening the trace

Once the trace loads, the main windows displays the timeline of all the data in relationship to the time.

• At the bottom of the windows you see all the metrics that are enabled and recording while capturing the trace.

• At the center of the screen you see all of the threads that were running at the time of capture.

• At the top you see the GPU frame delimiters and CPU frame delimiters and what tasks were occurring.

Let’s focus on CPU offline analysis. Notice that the duration of the trace is around 5 seconds long. This can be modified in the profiles section of the graphics monitor.

Let’s zoom in to see the smaller section of this trace. Clicking and dragging a section (using the left mouse button and then releasing) zooms into that section. Zoom in to get three frames with the data as shown below.

4. Zooming and selecting the frames

5. Intel GPA Platform Analyzer

Now that we zoomed into the three frames, let’s look at the individual columns.

Frames column

In the frames columns you can view individual GPU and CPU frame timings. Notice that the colors correlate to the same CPU and GPU frames. For example, the CPU 112 frame is the same frame color as the GPU 112 frame.

6. Intel GPA Platform Analyzer: GPU frame

7. Intel GPA Platform Analyzer: CPU frame

We can looks at individual durations and also calculate the difference between when the CPU frame started and when the GPU frame started.

Render and GPGPU column

Everything above the dotted line is executing on the GPU. The red cross-hatched areas as shown below are the present calls. You can trace a present call from when it originates to when it is executed. You will see when a present call is executed and when the GPU frame is finished, which helps calculate the single frame latency. You can see when the present call is submitted by the CPU and when it is completed by the GPU.

8. Intel GPA Platform Analyzer: Render and GPGPU column

Threads pane

You can view when the thread was running, when the OS needed to switch the context, and when there was synchronization. In addition you can see the GPU work overlayed on the thread, which can help correlate when the GPU or the CPU is busy, identifying whether the workload is CPU bound or GPU bound. You can view each of the DirectX API calls as well as user-defined calls if available.

9. Intel Platform Analyzer: Threads column

Platform Metrics

The metrics that display here are the metrics we set up in the HUD profile. If a trace is taken using Intel GPA System Analyzer, the metrics are the ones in the Intel GPA System Analyzer at that time.

10. Intel GPA Platform Analyzer: Platform metrics column

Statistics pane

This pane will update, synchronized with your selection. Depending on what you selected, this pane displays GPU usage, OpenCL™ kernels, or tasks such as user-defined functions or DirectX calls. The pane can also identify hotspots in certain areas in the trace. For example, if you highlight a section, the statistics pane changes as shown below. You can see the task time for the selected area, the GPU time, and the GPU queue time.

11. Intel GPA Platform Analyzer: Statistics column

12. Selecting an area and the statistics pane changes

Legend area

You can turn off some of the sections to make the UI less complicated. You can clear a check box to remove that section.

13. Intel GPA Platform Analyzer: Legend pane

14. Intel GPA Platform Analyzer after unchecking Platform metrics from the legend pane

About the Author

Praveen Kundurthy works in the Intel® Software and Services Group. He has a master’s degree in Computer Engineering. His main interests are mobile technologies, Microsoft Windows*, and game development.

Intel technologies’ features and benefits depend on system configuration and may require enabled hardware, software or service activation. Performance varies depending on system configuration. Check with your system manufacturer or retailer or learn more at intel.com.

No license (express or implied, by estoppel or otherwise) to any intellectual property rights is granted by this document.

Intel disclaims all express and implied warranties, including without limitation, the implied warranties of merchantability, fitness for a particular purpose, and non-infringement, as well as any warranty arising from course of performance, course of dealing, or usage in trade.

This document contains information on products, services and/or processes in development. All information provided here is subject to change without notice. Contact your Intel representative to obtain the latest forecast, schedule, specifications and roadmaps.

The products and services described may contain defects or errors known as errata which may cause deviations from published specifications. Current characterized errata are available on request.

Copies of documents which have an order number and are referenced in this document may be obtained by calling 1-800-548-4725 or by visiting www.intel.com/design/literature.htm.

Intel and the Intel logo are trademarks of Intel Corporation in the U.S. and/or other countries.

*Other names and brands may be claimed as the property of others

© 2015 Intel Corporation.

OpenCL and the OpenCL logo are trademarks of Apple Inc and are used by permission by Khronos.

Download PDF[PDF 635KB]

4.0 Links to the Previous Chapters

Chapter 1: Overview of DirectX* 12
Chapter 2: DirectX 12 Tools
Chapter 3: Migrating From DirectX 11 to DirectX 12

4.1 Function and Usage of Multiplane Overlay

4.1.1 Introduction

Multiplane Overlays (MPO) is a new feature of WDDM1.3 (DX11.2) initially introduced in Windows 8.1, which is now extended to WDDM2.0 (DX12) in Windows 10. MPO supports using the original resolution to display gorgeous 2D art and UI elements, while drawing 3D scenes into a smaller and stretchable frame buffer. The stretching and composition of surfaces at different resolutions are automatically implemented by the system, and transparent to applications.

The major role of MPO is to allow a game to maintain a stable and appropriate frame rate under different circumstances, thereby improving the overall game experience. On one hand, the resolution almost always has a significant impact on the performance of modern games. With the popularity of high-definition 4K screens, the resolution of game window also increases. Increasing pixels also increases texture sampling and the bandwidth of render target, which brings challenges to the performance of games. Secondly, post-processing technology is increasingly used for rendering 3D scenes, which increases the complexity of a shader, so the trend will be that a trend that the cost per pixel determines games performanc. Therefore, setting the appropriate resolution is critical to maintaining game performance.

Furthermore, for games like role playing, real-time strategy and multiplayer online, rendering GUI components at the initial window resolution is also very important. For example, even on low-end platforms, players will want to text chat with teammates during game play. GUI components are mainly 2D graphics with relatively low rendering overhead, thus rendering at the window resolution can provide the best visual experience.

MPO provides a compromise solution for high-resolution display and gaming performance. Using MPO can alleviate the rapid performance degradation of games in high-resolution rendering, allowing the games to run smoothly on the majority of hardware platforms. MPO supports not only rendering GUI layer and 3D content layer in different resolutions, bu also rendering in different frame rates. For instance, for a GUI layer, just present when a change happened. It benefits to performance and power efficiency. Fiture 1 illustracts the swap chain composition of MPO.

Because MPO is a new feature of driver model, graphics driver provides the implementation of MPO to the upper-level D3D runtime or DXGI runtime. MPO can be implemented by WDDM1.3 or higher version drivers through software or by graphics hardware that uses a dedicated pipeline for the GPU in order to reduce consuming so many CPU and GPU resources, helping to further enhance game performance and lower power consumption. Intel will add hardware support for MPO in 6th generation Intel® Core™ processors (codenamed SkyLake).

Figure 1: Swap Chain Composition of Multi-Plane Overlay

4.1.2 Application scenarios

In a game, Multiplane Overlays are typically applied in the following scenarios.

1. Scenes where the performance (such as frame rate) is below a certain threshold.

   Depending on the type of the game, when the frame rate is below a certain value, the playability of the game is degraded. For example, in battle scenes where a large number of game characters appear, the frame rate of the game decreases significantly. To avoid performance degradation to the point where the game can’t be played, the game will automatically switch to the MPO rendering mode to maintain playable performance when it detects that the frame rate is lower than the threshold.

2. Scenes that release particle effects.

   In MMOG, scenes that release a large number of particle effects often result in the sudden drop in frame rate and even cause the game stuttering in severe cases, which is a common performance bottleneck in games. Rendering particle effects involves a lot of pixel filling, while rendering on a high-resolution surface has more significant impact on performance. The game will switch to MPO mode when releasing particle effects, and render the particle effects to a render target with smaller resolution to reduce the amount of pixel filling. In addition, in the fierce battle scenes, the release of a large number of particle effects leads to very dramatic changes in the screen, and thus it is difficult for the player to see the details of each frame. Therefore, the impact of MPO stretching render target on the final visual quality is almost imperceptible. Using MPO in such scenes, your game can maintain the proper frame rate while keeping the visual experience, and addressing common performance problems.

3. Rendering on mobile platforms

   Now that mobile platforms are popular gaming terminal, game developer must worry about power consumption. When the platform switches from AC power mode to battery power mode, the system performance settings could cause the CPU or GPU frequency to decrease and force the game frame rate to drop. With MPO, a game will automatically adjust the resolution of the render target without changing the window resolution to compensate for the overall performance, while reducing power consumption and allowing the game to run longer. This feature of MPO can be used to implement power-saving mode for the game. This mode is available as a game setting option for the players. For players, in the power-saving mode, slight difference on the screen is acceptable.

4. All of the above application scenarios mentioned focus on dynamically adjusting resolution to maintain FPS. In practice, it will probably be more common to just choose a fixed ratio for the duration of the game. For a 3D content layer, a natural choice for the scale ratio would be based on the device DPI. (e.g. scale = deviceDpi/96.0)

4.1.3 Sample Codes for API usage

To apply Multiplane Overlays (MPO) in a game, you first need to detect whether the software and hardware on the platform support it. The code for this is as follows:

Table 4.1: Detecting whether the hardware supports Multiplane Overlay

BOOL supportMultiPlaneOverlay = FALSE;
IDXGISwapChain* dxgiSwapChain;
IDXGIOutput* dxgiOutput;

dxgiSwapChain->GetContainingOutput(&dxgiOutput);
if (dxgiOutput)
{
IDXGIOutput2* dxgiOutput2;
dxgiOutput->QueryInterface(IID_PPV_ARGS(&dxgiOutput2));
SAFE_RELEASE(dxgiOutput);
if (dxgiOutput2)
{
supportMultiPlaneOverlay = dxgiOutput2->SupportsOverlays();
SAFE_RELEASE(dxgiOutput2);
}
}

IDXGIOutput2 : SupportsOverlays () API is used to detect whether the graphics hardware supports this feature. If it returns true, then the hardware supports this feature; if it returns false, then the hardware doesn’t support this feature, but the driver supports it using software approach. Intel Skylake platform and later processor cores will support MPO on the hardware level.

In the game initialization phase, it’s required to create a few key Multiplane Overlay API objects: such as Direct Composition device, scale transformer, foreground, background SwapChain, etc. The sample code for desktop apps is as follows:

Table 4.2: Initialization and Creation of Multiplane Overlay API Objects

IDXGIFactory2* dxgiFactory;
adapter->GetParent(IID_PPV_ARGS(&dxgiFactory));

if (dxgiFactory)
{
// Create a Direct Composition device
DCompositionCreateDevice(NULL, IID_PPV_ARGS(&m_directCompositionDevice));

     // The device creates a render target for the window
m_directCompositionDevice->CreateTargetForHwnd(
(HWND)_CORE_API->GetAppWindow(), false, &m_directCompositionTarget);

// The device creates a multi-layer view
m_directCompositionDevice->CreateVisual(&m_rootVisual);
m_directCompositionDevice->CreateVisual(&m_mainVisual);
m_directCompositionDevice->CreateVisual(&m_overlayVisual);

// The device creates a scale transformer and sets it into the main view
m_directCompositionDevice->CreateScaleTransform(&m_mainScaleTransform);
m_mainVisual->SetTransform(m_mainScaleTransform);

// When the main view is stretched, adopt the linear interpolation for filtering   		m_mainVisual->SetBitmapInterpolationMode(DCOMPOSITION_BITMAP_INTERPOLATION_MODE_LINEAR);

// Add the main view and interface view to the root view, set the root
view onto the render target
     m_rootVisual->AddVisual(m_mainVisual, FALSE, NULL);
     m_rootVisual->AddVisual(m_overlayVisual, FALSE, NULL);
m_directCompositionTarget->SetRoot(m_rootVisual);

// Prepare to create SwapChain
DXGI_SWAP_CHAIN_DESC1 swapChainDesc = { 0 };
    	swapChainDesc.Width = width; // Match the size of the window.
    	swapChainDesc.Height = height;
    	swapChainDesc.Format = DXGI_FORMAT_R8G8B8A8_UNORM;
    	swapChainDesc.Stereo = false;
    	swapChainDesc.SampleDesc.Count = 1; // Don't use multi-sampling.
    	swapChainDesc.SampleDesc.Quality = 0;
    	swapChainDesc.BufferUsage = DXGI_USAGE_RENDER_TARGET_OUTPUT;
    	swapChainDesc.BufferCount = 2;
    	swapChainDesc.SwapEffect = DXGI_SWAP_EFFECT_FLIP_DISCARD;
    	swapChainDesc.Flags = DXGI_SWAP_CHAIN_FLAG_FRAME_LATENCY_WAITABLE_OBJECT;
    	swapChainDesc.Scaling = DXGI_SCALING_STRETCH;
    	swapChainDesc.AlphaMode = DXGI_ALPHA_MODE_PREMULTIPLIED;

// DXGIFactory creates the foreground SwapChain
     hr = dxgiFactory->CreateSwapChainForComposition(
            m_HUDCommandQueue,&swapChainDesc,
            nullptr,&m_foregroundSwapChain
            );
// Bind the interface view to the foreground SwapChain
     m_overlayVisual->SetContent(m_foregroundSwapChain);

// Create the background SwapChain
     swapChainDesc.AlphaMode = DXGI_ALPHA_MODE_IGNORE;

     hr = dxgiFactory->CreateSwapChainForComposition(
            m_3DCommandQueue,&swapChainDesc,
            nullptr,&m_backgroundSwapChain
            );


// Bind the main view to the background SwapChain
     m_mainVisual->SetContent(m_backgroundSwapChain);

     m_directCompositionDevice->Commit();
     SAFE_RELEASE(dxgiFactory);
}

Note: D3D12 and D3D11 take different objects as the first argument for CreateSwapChainForComposition: D3D12 takes CommandQueue, while D3D11 takes Device.

It is recommended to use separate queues for different swapchains. The reason is that DXGI will insert waits on your behalf in order to synchronize with DWM, so using the same queue for two swapchains could result in workloads targeting one swapchain being blocked, waiting for a buffer to become available from the other swapchain.

In the game rendering process, the code logic based on MPO rendering is as follows:

Table 4.3: Multiplane Overlay-based Game Rendering Method

// According to changes in the number of frames, dynamically adjust the scale ratio of the background SwapChain
m_mainScaleTransform->SetScaleX(scaleRatio);
m_mainScaleTransform->SetScaleY(scaleRatio);
m_directCompositionDevice->Commit();

// Before rendering 3D scenes, first set the corresponding RenderTarget of the background SwapChain
//
Adjust the size of Viewport at the same time
OMSetRenderTargets(1, &m_backgroundRTV, m_backgroundDSV);
viewport.Width = foregroundSwapChain.Width / scaleRatio;
viewport.Height = foregroundSwapChain.Height / scaleRatio;
RSSetViewports(1, viewport);

// Draw 3D Scene...

// When performing full-screen post-processing, you need to change the texture sampling coordinates, control the addressing range, because the background Viewport may only partially filled the RenderTarget
VSSetConstantBuffer(scaleRatio);
// Draw Fullscreen PostProcess

// Before rendering the UI, first set the corresponding RenderTarget of the foreground SwapChain
// Adjust the size of Viewport at the same time
OMSetRenderTargets(1, &m_foregroundRTV, m_foregroundDSV);
viewport.Width = foregroundSwapChain.Width;
viewport.Height = foregroundSwapChain.Height;
RSSetViewports(1, viewport);

// Draw UI..

// Finally submit SwapChain
m_backgroundResource->SetTransitionBarrier(D3D12_RESOURCE_STATE_PRESENT);
m_foregroundResource->SetTransitionBarrier(D3D12_RESOURCE_STATE_PRESENT);

m_commandList->Close();

m_backgroundSwapChain->Present(0, 0);
m_foregroundSwapChain->Present(0, 0);

4.1.4 Summary

Multiplane Overlays is a new graphic display function on the Windows 8.1 and later platforms. Win10 platform-based DirectX 12 games can easily use the DX12 API to render Multiplane Overlays, potentially solving the problem of sudden drop in frame rate due to high-resolution rendering and high load scenes for games, enabling smooth gaming experience on the majority of hardware platforms.

Coming Soon: Link to the Following Chapter

Chapter 5: DirectX 12 Optimization

作者：Donald Kehoe

在过去的几十年中，游戏行业取得了巨大发展。 从 Pong*和Pac-Man*等让游戏玩家短暂逃离现实的简单游戏发展为魔兽世界*和使命召唤 4*这样让游戏玩家真正喜爱的复杂游戏。 娱乐软件协会 (ESA) 曾指出，如今的游戏玩家平均有 13 年的游戏经验，已经习惯于看到每款新游戏变得越来越复杂、吸引人且智能。 如今，游戏开发人员的挑战在于如何不断突破极限，开发出越来越引人注目的游戏。 计算机控制的人工智能 (AI) 已经发生了多种形式的演变，以满足测试要求。 然而，为游戏玩家设计符合其动作并促进玩家数量增长的自适应对手并非易事。 文本包含四个部分，将探讨下列重要的 AI 概念以及如何优化这些概念，使其在如今最前沿的多核处理器上顺畅运行：

• 第一部分： 设计和实施
• 第二部分： 路径搜寻和感知
• 第三部分： 战术和战略 AI
• 第四部分： 使用线程应用 AI

第一部分： 设计和实施

对于游戏行业而言，人工智能是什么？

从最基本的层面而言，“人工智能”包括模仿其他玩家或玩家所代表实体（即可以响应或付诸实践的所有游戏元素——从玩家、飞弹到健康皮卡）的行为。 关键概念是模仿行为。 也就是说，游戏行业的人工智能更加人工化，而智能程度较低。 系统既可以是基于规则的简单系统，也可以是旨在挑战玩家作为对立军队指挥官的复杂系统。

游戏行业的人工智能与传统的人工智能观点有何不同

对人工智能的传统研究旨在创建真正的智能——尽管是通过人工手段。 有些项目，如麻省理工学院 (MIT) 的Kismet* 项目，正在尝试创建一种能够进行学习、社交互动并表现情感的人工智能。 在本文撰写之时，麻省理工学院正在创建一种有幼儿教师和可喜成果的人工智能。

对于如今的游戏而言，真正的人工智能已经超出了一款娱乐软件的要求。 游戏人工智能不需要具备感受力或自我感知能力（事实上没有最好）；它不需要了解除游戏之外的任何信息。 游戏人工智能的真正目标是模仿智能行为，为玩家提供一种可信的挑战——即玩家可以克服的挑战。

游戏人工智能的目标

人工智能可以在游戏中扮演多种角色。 它可以是一套用于管理游戏世界中实体行为的一般规则。 您也可以考虑实体遵循一类人工智能的预制脚本事件。 例如在游戏 F.E.A.R* 中， 用于恐吓玩家和预示未来事件的令人毛骨悚然的小女孩就是一个预制脚本事件。 提到人工智能和游戏时，大多数人都会想到多人游戏中由电脑控制的玩家。 不过，所有这些都是人工智能能够实现的不同角色。

图 1： F.E.A.R.（Vivendi Universal）在一类人工智能中使用脚本事件

游戏人工智能的基本要素

根据人工智能要实现的角色的性质，系统需求可能非常少。 系统越复杂，人工智能的要求就越多。 基本需求无非是运行 AI 所需的处理时间。 更复杂的系统需要一些感知人工智能环境的手段，玩家行为记录和一些评估先前决策成功度的手段。

决策

人工智能背后的核心概念是决策。 为了执行这些选择，智能系统需要能够使用人工智能系统影响实体。 您可以通过“人工智能推送”或“实体推送”战略管理这一执行。

人工智能推送系统通常将人工智能系统隔离为游戏架构的独立元素。 此类战略通常采取独立线程或线程的形式，线程中的人工智能花时间计算给出游戏选项的最佳选择。 当人工智能制定决策时，这一决策将随后传播至涉及的实体。 这一方法在实时战略游戏中最有效，因为在这种游戏中，人工智能关注大局。

实体推送系统最适合包含简单实体的游戏。 在这些游戏中，实体会在其“思考”或自我更新时调用人工智能系统。 这种方法非常适合于包含大量不需要经常思考的实体的系统，如射手系统。 这一系统还可以从多线程技术中受益，但需要一些额外的计划（详情请见Orion Granatir 的多线程人工智能上的文章）。

基本感知

为了使人工智能作出有意义的决策，它需要感知周围环境的某种方式。 在较简单的系统中，这种感知可能只是对玩家实体的位置进行简单的检查。 随着系统的要求越来越苛刻，实体需要找出游戏世界的主要特点，如可行的穿行路径、提供掩护的地形和冲突地区。
设计人员和开发人员面临的挑战在于找出一种方法，以确定对智能系统至关重要的主要特点。 例如，掩护可以由关卡设计师预先确定，或可以在加载或编译地图时进行预先计算。 有些元素可以动态评估，如冲突地图和紧迫威胁。

基于规则的系统

智能系统采用的最基本形式是基于规则的系统。 这一系统延伸了“人工智能”这一术语。 一组预设行为用于确定游戏实体的行为。 对于各种行为，总体结果可以是一个虽然涉及的实际智能很少但并不明显的行为系统。
在基于规则的系统方面，Black Jack 庄家就是一个很好的例子（无论是视频 Black Jack 还是真正的 Black Jack）。 庄家遵循一个简单规则： 当牌点数为 17 或不到 17 时必须要牌。 一般玩家的看法是庄家有竞争力。 玩家会设想一个比其当前敌手更有能力的对手（除非赌场经营者公布庄家遵守的规则）。

Pac-Man 是这一系统的典型应用。 四个鬼纠缠着玩家。 每个鬼都遵循一个简单的规则集。 一个鬼一直左转，另一个一直右转，一个以随机方向转弯，最后一个转向玩家。 每个鬼的移动方向很容易弄清楚，玩家能够轻松避开他们。 但作为一个集体，这些鬼的移动方式看起来就复杂的多，相互协调配合共同寻找玩家。 事实上，检查玩家位置的只有最后一个鬼。

图 2： 控制Pac-Man鬼的规则集的直观图，其中的箭头代表将作出的“决策”。

正如本例所示，规则不需要硬编码： 规则可以基于感知到的状态（如最后一只鬼）或实体的可编辑参数。 进攻、勇气、视线范围和思考速度等变量均可以产生更多样化的实体行为，即使是在基于规则的系统中。 基于规则的系统是最简单的人工智能结构。 更复杂的智能系统基于一系列条件规则构建并由这些规则管理。 在战术游戏中，规则控制着要使用的策略。 在策略游戏中，规则控制着建造顺序和应对冲突的方式。 基于规则的系统是人工智能的基础。

有限状态机作为人工智能

有限状态机 (FMS) 是一种概念化和实施在整个生命周期中拥有不同状态的实体的方式。 “状态”可以代表实体所处的物理状态，或者也可以代表实体展示出的情感状态。 在本例中，情感状态并不是真正人工智能的情感状态，而是融入游戏环境的预定行为模型。

下面是一个人工智能系统的常见状态示例，针对一个包含隐性元素的游戏：

图 3： 典型 FSM 中的状态布局，其中的箭头表示可能的状态变化

• 闲置。在这种状态下，实体会被动地站着或沿固定路线走动。 感知水平低。 不常检查游戏玩家的声音。 只有这一实体受到攻击或“看到”玩家直接在其前面时，它的状态才会更改为较高的认知水平。
• 感知。这一实体主动寻找入侵者。 它会经常检查游戏玩家的声音，比闲置实体看得更远更宽泛。 如果这一实体注意到碍事的某物（在其检查范围之内），如打开的门、无意识的尸体和用过的弹壳等，它将变为好奇状态。
• 好奇。这一实体意识到发生了不寻常的事情。 为了证实这一行为，该实体将放弃其正常岗位或路线，移动到感兴趣的区域，如前面提到的打开的门或尸体。 如果玩家被发现，实体将变为警戒状态。
• 警戒。在这种状态下，实体已经注意到玩家并将开展追捕玩家的行动：移入攻击范围、提醒其他警卫、发出警报并寻找掩护。 当实体在敌人范围内时，它将切换到攻击状态。
• 攻击。在这种状态下，敌人已经参与到与玩家的战斗中来。 实体会在可能时攻击玩家，并在不同的攻击回合之间寻找掩护（根据攻击缓和时间或装弹时间）。 只有在消灭敌人后（恢复正常）、敌人移动到射程之外（回到警戒阶段）或实体死亡（进入死亡状态）时，实体才会离开这个状态。 如果实体的生命值很低，它可以切换为逃跑状态，这取决于特定实体的胆量。
• 逃跑。在这种状况下，实体会试图逃离战斗。 根据游戏的不同，可能会有寻找生命值或离开游戏区域的次级目标。 当实体找到生命值后，它可能会返回到警戒状态并恢复战斗力。 “离开”的实体只是删除了而已。
• 死亡。在有些游戏中，死亡状态可能不是完全闲置。 死亡或濒死的实体可能会“大声呼叫”，从而提醒附近的实体，或进入神志不清的状态，医师可使其复活（并返回到警戒状态）。

在实体系统中实施 FMS 至少有两种简单方法。 第一种是让每种状态成为一种可以检查的变量（通常通过大量的开关语句）。 第二种方法是使用函数指针（C 语言）或虚拟函数（C++ 和其他面向对象的语言）。

自适应人工智能

前面的章节讨论了如何设计融入游戏预定义事件的智能系统。 对于大多数游戏而言，只要设计缜密且对智能实体的目标有清晰的认识，这就足够了。 如果游戏需要更多的变化并为玩家提供更好、更有活力的对手，人工智能可能需要具备增长和独自适应的能力。

自适应人工智能通常用于格斗游戏和策略游戏，这些游戏具有深层次的机制和无数的游戏选项。 若要为玩家提供持续的挑战且避免玩家最终找出打败电脑的最佳策略，人工智能需要具备学习和适应的能力。

预测

有效预测对手下一步行动的能力对于自适应系统至关重要。 可以使用不同的方法，如过去模式识别（在未来的文章中介绍）或随机猜测，以确定要采取的下一步行动。

适应的一个基本方法是记录过去的决策并评估成功程度。 人工智能系统会记录一个游戏玩家在过去所做的选择。 过去的决策必须以某种方式进行评估。 （如在格斗游戏中，获得的优势或损失的生命值或时间优势可以作为成功的衡量指标。） 可以通过收集有关这种情况的更多信息来为决策提供一些背景，如相对生命值、以前的行为和关卡定位（当玩家走投无路时会采用不同的游戏方式）。

可以通过评估这些历史信息来确定以前行为的成功程度以及是否需要改变战术。 在构建过去行为列表之前，可以使用一般战术或随机行为来引导实体的行为。 这一系统可以与基于规则的系统和不同的状态相结合。

在战术游戏中，过去的历史可以决定用于对付玩家团队的最佳战术，如防守、进攻、狂暴或一些平衡的游戏方法。 在策略游戏中，可以基于玩家发现一个部队中最佳的分队组合。 在由人工智能控制玩家支持角色的游戏中，通过了解玩家的行为方式，自适应人工智能可以更好地补充玩家的自然风格。

总结

人工智能是一个复杂的研究领域。 根据游戏需求的不同，游戏行业的人工智能会采用不同的形式，从计算机控制器实体的简单规则集到更先进的自适应系统。 在游戏行业中应用人工智能概念对于提高电子娱乐产品中虚拟人物的可信度必不可少，但它并不是一个不可能的挑战。 这一系列的下一篇文章将讨论人工智能在感知和导航复杂环境方面所面临的挑战，以及如何应对这些挑战。

关于作者

Donald "DJ" Kehoe： 作为新泽西理工学院信息技术项目的导师，DJ 开拓了游戏开发领域的专业化之路，并教授该项目中有关游戏架构、编程和关卡设计的许多课程，以及集成 3D 显卡与游戏的课程。 目前他正在攻读生物医学工程博士学位，运用游戏和虚拟现实来增强神经肌肉康复的效果。

Cocos游戏开发引擎对于广大开发者来说都比较熟悉，Intel RealScene是什么呢，简单理解是一种特殊的摄像头，可以捕捉用户的手势，面部表情等，进而实现AR,VR的特殊应用，本案例通过摄像头结合Cocos引擎实现一款跑酷游戏，游戏截图如下：

图1-cocos+IntelRealScene实现的跑酷游戏

1.游戏玩法：

   1.在摄像头前坐好

   2.当游戏主角前方有障碍物或陷阱时候迅速移动头部向左，游戏主角会跳起

   3.恢复坐好状态

   （目前我的最好成绩是24秒！！！）

2.项目运行工程网盘地址：

   链接: http://pan.baidu.com/s/1ntB0kwL 密码: nzrd

3.项目源码网盘地址：

  链接: http://pan.baidu.com/s/1qWj9Iws 密码: buj6   

4.开发和运行环境要求：

         4.1 Win7以上64位操作系统

         4.2 使用了Intel F200摄像头设备

         4.3 正确安装F200驱动程序（下载在）

         4.4 安装vs2013

5.开发核心步骤

   5.1 登录www.cocos.com下载最新版的cocos引擎源码，然后安装，并创建一个新的Cocos工程（此处略过10000字，详细方法可以登录cvp.cocos.com），并使用vs打开。

   5.2. 重要，若要cocos支持RealScene设备需要加载库，可以通过属性表一次性完成该操作，在VS中找到【视图】【其他窗口】【属性管理器】，如下图：

然后找到添加属性按钮，如下图：

选择C:\Program Files (x86)\Intel\RSSDK\props

选择任意VS2010-13.Integration.MD.props 或者 VS2010-13.Integration.MT.props，

如下图：

在项目名上面右键，查看项目属性，检查是否加载成功，如下图：

我们看到包含目录和库目录中已经有了关于RSSDK的内容，说明属性文件生效，但是这时候编译工程会出现找不到lib库的错误，解决方法如下：

在库目录增加一行只想RSSDK\sample\common\lib\x64\v140

然后编译项目，ok。

6.核心编码

     6.1 在AppDelegate中启动摄像头并在独立线程中更新数据。

#include "CCStdC.h"

#include <SDKDDKVer.h>

#include <pxcsession.h>

#include <stdio.h>

#include <stdlib.h>

#include <pxcsensemanager.h>

#include <util_render.h>

#include <pxcfaceconfiguration.h>

引入以上库文件，在构造函数启动线程

AppDelegate::AppDelegate() {

std::thread t([&](){

printf("init realsence\n");

PXCSession* session = PXCSession_Create();

if (session)

{

PXCSession::ImplVersion version = session->QueryVersion();

CCLOG("SDK Version is %d.%d\n", version.major, version.minor);

session->Release();

}

//// ///////////初始化rs模块

PXCSenseManager* senseManager = PXCSenseManager::CreateInstance();

if (senseManager)

{

CCLOG("intel PXCSenseManager ok");

senseManager->EnableFace();//开启脸部识别模块 

CCLOG("intel realsence EnableFace");

if (senseManager->Init() == PXC_STATUS_NO_ERROR)

{

CCLOG("intel senseManager->Init() ok");

// 获取faceModule

PXCFaceModule* faceModule = senseManager->QueryFace();

PXCFaceData* faceData = faceModule->CreateOutput();

PXCFaceConfiguration* faceConfiguration = 

faceModule->CreateActiveConfiguration();

////设置3d跟踪模式

faceConfiguration->SetTrackingMode(

PXCFaceConfiguration::TrackingModeType::FACE_MODE_COLOR_PLUS_DEPTH);

faceConfiguration->detection.isEnabled = true;

faceConfiguration->ApplyChanges();

bool quit = false;

while (!quit)

{

// //获取跟踪的坐标

faceData->Update();

int faceNum = faceData->QueryNumberOfDetectedFaces();

if (faceNum > 0)

{

PXCFaceData::Face *trackedFace = 

faceData->QueryFaceByIndex(0);

PXCFaceData::DetectionData* detectionData = 

trackedFace->QueryDetection();

PXCRectI32 rectangle;

detectionData->QueryBoundingRect(&rectangle);

Game::x = rectangle.x;

Game::y = rectangle.y;

Game::w = rectangle.w;

Game::h = rectangle.h;

}

   senseManager->ReleaseFrame();

}

faceData->Release();

faceConfiguration->Release();

senseManager->Close();

}

else{

CCLOG("intel realsence error2");

}

senseManager->Release();

}

else{

CCLOG("intel realsence error1");

}

});

t.detach();

}

以上代码，会时时更新数据，捕获人脸的x,y,w,h在屏幕的坐标，缺省是640X360的范围，可以通过Log查看数据的变化。

     6.2 在GameScene中启动计划任务scheduleUpdate,并在每一帧处理。

void Game::update(float t)

{

//每帧保存一个点

if (allPoint.size() < 60)

{

MyPoint * newp = new MyPoint(x, y, w, h);

newp->autorelease();

allPoint.pushBack(newp);

}

else

{

MyPoint * newp = new MyPoint(x, y, w, h);

newp->autorelease();

allPoint.eraseObject(allPoint.front());

allPoint.pushBack(newp);

  int farx = (allPoint.back()->x - allPoint.front()->x);

std::string str = 

StringUtils::format("%d %d %d %d  %d", x, y, w, h, farx);

CCLOG("%s", str.c_str());

if (farx >30 && farx<200)

{

if (this->_dir == Stop)

{

this->_dir = Up;

 allPoint.clear();

}

}

}

  。。。。。。

}

这里用60个点来记录每一帧人脸坐标的变化，通过计算是否有超过40的移动来确定玩家是否跳起（这里很偷懒，可以使用的人脸的点可以达到78个点）

转变 UI — 利用今天的技术设计明天的交互界面（第一部分）

游戏开发人员利用英特尔® 实感™ 技术推动前沿开发

下载 PDF

随着各种新技术持续带来全新体验，我们与游戏相互之间的互动方式正在不断发展变化。 游戏行业总能迅速地挖掘新型交互技术的潜力。 随着接口的进化，平稳的游戏开发新时代不断涌现卓越的想法，这个行业正处于激动人心的未来的风口浪尖。 英特尔® 实感™ 技术在这样的未来中占有一席之地，它结合了一流的 3D 摄像头传感与硬件内置的高级语音识别功能。 借助英特尔® 实感™ SDK (beta)，开发人员可开始探索其潜能，提供超越传统硬件控制器的身临其境般的互动娱乐体验。

本文是有关感知计算和英特尔实感技术的第一篇文章，介绍了在工作中应用该技术的四家创新开发商提供的深刻见解。

重塑幻想世界

“我们希望使用手势控制在您和您的计算机屏幕之间的空间带来颠覆性的感觉和非凡的真实触感”，Funomena 公司的 Robin Hunicke 在讲述即将推出的采用英特尔实感技术的新游戏时说道。

基于对于游戏能够产生积极影响的鉴定信念，Hunicke 于 2013 年与人合作创办了 Funomena。 他们的目标之一是探索玩家与科技之间的情感互动限制。 “我们的游戏在一段个人转变旅程中追踪一个角色，而且受到折纸艺术的重大影响。 我们非常喜欢摄像头能够看到玩家手部位置细微变化的想法。 高保真的手势跟踪使输入更加细致入微，英特尔实感技术将支持游戏如实响应玩家在摄像头前的移动。 “我们能够使用该信息让他们实时操纵和塑造物体。”

该游戏现在仍处于保密阶段，将采用英特尔® 实感™ 3D 摄像头精确读取手势，让玩家直接连接到游戏世界，并以全新方式探索游戏的谜题和环境。 “我们一直对推动游戏所能表达的界限饶有兴趣。 但是，即便我们在打造一些挑战用户想象力的东西，我们还是积极听取用户的建议。 您将从真正意义上用手一片一片解开这个世界的奥秘，定制每一个级别，以反应您对最终世界景象的设想。”Hunicke 说道。

运动基础

以色列的 Side-Kick Games 公司已经研究动作控制器数年，包括 2D 网络摄像头（使用 PointGrab*、XTR* 和 EyeSight* 中间件）、Kinect* 和 PrimeSense*。 他们积累的知识使英特尔实感技术的采用过程变得畅通无阻。

首席运营官 Tal Raviv 解释道：我们在游戏中构建了一个动作控制器专用层，这样就能看到许多不同的中间件输入，并提供一个标准的运动控制接口。 借助这个基础架构以及我们在动作控制方面的经验，从全身、长程和短程运动控制到英特尔实感技术的过渡过程比较顺利。 英特尔实感技术接口非常直接，并具有强大的跟踪功能。 与使用其它技术相比，需要克服的难题非常少。”

在 Side-Kick 即将推出的游戏 Warrior Wave中，玩家需要用手将士兵带到安全地点，并保护他们不受敌人攻击。 该团队根据游戏中的上下文环境利用英特尔实感技术的不同功能。 “我们使用两种类型的控制。 第一种是‘剪影’，是软件开发套件的一个分支，可以让游戏‘看见’手的外形，但不‘了解’它的结构（手掌、手指、拇指）。 ‘骨骼’是软件开发套件的跟踪环节，提供有关手部结构的信息（每个指尖和手掌心的位置）。” Raviv 继续说道：“基本游戏机制使用剪影，但菜单等其它机制采用骨骼。”

Side-Kick Games 还确保该上下文环境适合应用英特尔实感技术，可以在 Warrior Wave中与现有接口技术同时实施，以提供最佳体验。 “玩家使用触摸屏操作菜单导航和激活对象，因为这是最直观的方法。 他们在游戏中使用动作控制，获得更身临其境的体验，因为他们无需受传统鼠标和触控的限制”，Raviv 说道。 “目前这个组合对玩家的效果最好。 未来，音频和动作控制的组合将对 UI 更重要，但目前动作控制的主要优势在于可玩性本身。”

遵从命令

Iridium Studios 的团队正在同时使用英特尔实感技术的动作和语音功能，为其即将推出的实时战术策略游戏 There Came an Echo提供更逼真的界面。 Iridium 的创始人Jason Wishnov说道：“过去，在实时战略游戏中领导一队人马时，您需要使用鼠标。 但在现实中，您不会在人周围画一个框，然后移动他们。 您要与他们沟通，通过语音和手势指挥。”

在 There Came an Echo中，语音命令对于提供更身临其境的逼真体验至关重要。 使用准确的语音命令创建更贴近现实生活场景的精彩游戏。 语音识别为故事讲述方面带来的益处对 Wishnov 同样重要。 “我们耗费大量时间和精力构建叙事，将这些角色打造成像具有真实动机、恐惧和性格缺陷的真人一样。 语音识别帮助从叙事意义上建立玩家与角色的关联”，Wishnov 解释道。

同时，英特尔实感 3D 摄像头的动作感应功能在游戏的战术作战环境中能够支持他们下达非语音指令。 “能够直接映射到游戏内命令的特定的军事手势也非常有趣。 例如，握拳表示出发或标记，举起手并握拳来控制士兵非常酷”，Wishnov 说道。

除了技术本身的精确性以外，确保动作控制对玩家有效的关键在于上下文环境。 “如果只因为有能力做到就硬将一套手势塞进游戏中，玩家不会知道他们为什么做某些事情，感觉不到衔接效果”，Wishnov 说道。 “要确保手势让人感觉有意义又自然，这一点非常重要。”

测量脉搏

加强了生物反馈的冒险游戏 Nevermind中的一个项目明确展示了英特尔实感 3D 摄像头的细节和精确功能。 在 Flying Mollusk即将推出的大作中，玩家扮演的角色是 Neuroprober，能够进入心理创伤受害者的思维，解决谜题，并克服大脑的防御机制，从而恢复他们的心理健康。 该游戏将使用生物反馈技术检测玩家的紧张程度。 当检测到紧张情绪时，环境会动态响应玩家的恐惧和紧张程度，随着紧张程度的提升，环境会提高挑战性和压迫感。 反之，如果玩家很放松，Nevermind会变得更柔和宽容。 Nevermind旨在通过这种方式帮助玩家意识到他们在游戏和真实世界中的紧张程度，并能够更好地加以控制。

“我一直对生物反馈和游戏功能感兴趣”，Flying Mollusk 创意总监 Erin Reynolds 说道。 她 2009 年开始研究生物反馈技术，把它作为在玩家和游戏之间建立更深层次关联的途径。 尽管存在几种生物反馈选项，却没有一种能供大多数消费者使用，但英特尔实感技术改变了这个局面。

“英特尔实感 3D 摄像头能够检测心率，我们使用该功能检测玩家的恐惧和紧张程度。 Nevermind就是基于此功能”，Reynolds 说道。 “以前，当人们玩 Nevermind时，必须在衬衫里面佩戴一个胸带。 现在借助该摄像头，玩家只需坐在电脑前开始玩。 它提供了更加无缝直观的体验。”

英特尔实感 3D 摄像头只需“看着”用户头部就能测量脉搏，打开了全新的可能性，这激发了 Reynold 的想象力。 “这意味着开发人员能够将生物反馈作为产品的一个可行环节，无论是游戏、医疗工具还是通信应用”，Reynold 说道。 “我们对这种可能性感到无比激动。”

“该摄像头的另一个生物反馈可能是情绪检测。 开发人员非常热衷于这个功能，将来玩游戏方式的变化将有无限的可能性”，英特尔实感技术产品经理 Chuck McFadden 补充道。

下一个等级

开发人员已经通过各种不同方法证明，英特尔实感技术的使用取决于游戏为玩家提供适当体验的特定需求。 英特尔实感技术的其它可能用途正在不断涌现。 我们利用自己的技术举办编程马拉松和游戏制作节活动，游走世界各地为游戏开发创造环境”，McFadden 说道。 “我们把代码和英特尔实感 3D 摄像头交给开发人员，然后任其自由发挥。”

英特尔还举办了英特尔® 实感™ 应用挑战赛 2014，McFadden 称其为“百万美元大会”，促使创新者和发明家为新技术提出更有创意的想法。 “一些想法我连做梦都想不到，例如演奏乐器的新途径”，McFadden 说道。 “看着英特尔实感技术进化到下一个等级令人欢欣鼓舞。”

“作为开发人员，我们不再局限于三十年前的接口规范”，Reynolds 说道，强调了英特尔实感技术的真正收益。 “它给我们一个机会关注当今社会的需求，并改变我们与电脑交互的方式。”

“据我所知，还没有多少人充分利用这项新技术”，Hunicke 说道，随着英特尔实感技术的推出，正在涌现新的 UI 可能性。 “我们处于尖端。 我们有能力定义那些接口的形式和未来的景象。 我们可以设定上下文环境，与用户建立情感联系，把他们带出舒适区”，Hunicke 总结道。 “我们要让他们适应未来。”

资源和更多信息

要更深入地探索英特尔® 实感™ 技术，下载面向 Windows 的英特尔实感 SDK Beta和开发人员套件，请单击此处。

阅读精英观点：为什么英特尔传感技术至关重要。

无需控制器即可翱翔天空：查看此处。

您的项目准备好进行演示了吗？ 欢迎加入英特尔® 软件创新者计划。 该计划可以为拥有前瞻性项目的开发人员提供重要支持，让他们有机会讲述和演示自己的项目。

在开发者资源中心获取入门指南。

作者：Karen Marcus

下载 PDF

Robocraft*是一个需要玩家参与构建游戏内容各个方面的在线游戏即服务。 具体而言，玩家需要构建在游戏中充当主要代理的机器人。 由于需要玩家共同打造游戏，且很多玩家都年仅 10 岁，使用较旧的技术玩 Robocraft，用户焦点一直都是 Freejam 开发人员创意流程的核心。 在开发流程早期作出的关键编程和设计决策都是为了建立用户忠诚度，鼓励尽可能多的用户访问，同时为用户提供一款视觉效果好、趣味性强的游戏。 这些决策给开发人员带来了挑战，但在实施流程的两年后，Freejam 实现了用户忠实跟随和游戏视觉效果好、趣味性强的目标。

初始阶段

Robocraft是一款 Freejam 公司于 2013 年推出的在线第三人称射击 (TPS) 游戏。 游戏需要玩家使用单独的模块来构建可相互打斗的机器人。 玩家可以组件团队，游戏目的是摧毁尽可能多的机器人对手和/或占领敌军基地。

图 1： 独特机器人的实例 - 飞机

与类似的建设游戏一样，用户内容生成极为重要。 Freejam 联合创始人兼首席技术官 Sebastiano Mandalà 解释道： “开始时，我们知道它将成为一个创新游戏，最后我们拥有 300 个不同的立方体可供玩家用来创建外观漂亮、战斗力强的独特机器人。 图 1 和图 2 显示了独特机器人的实例。

图 2： 独特机器人的实例 - 船

为了确保这一级别的用户内容生成，原始的 Robocraft五人小组必须决定哪种技术能够让他们经济实惠地进行编程。 这一团队选择了 Unity*。 Mandalà 表示：”我们没有内部引擎，这意味着我们还没有开发面向特定平台的代码。 我们就直接采用了 Unity [Technologies] 的技术，它兼容许多平台。”

Unity 符合标准；不过该团队在实现编程细节方面面临着挑战。 Mandalà 表示：“比如，屏幕上呈现的所有这些立方体对于多数显卡是非常困难的，因为专门启用了成千上万的立方体。 最后，我们不得不制定出一些对图形和物理对撞机进行批处理的方法，以确保其顺畅运行，特别是在低端计算机上的顺畅运行。

除了用户内容生成以外，这种对低端玩家技术的关照也很重要。 Mandalà 表示：“Robocraft针对 10 至 14 岁的孩子，以及青少年和成年人。 但孩子通常不会有性能强大的计算机，所以我们不得不对游戏进行特别设计，使其兼容较旧的技术。”

范围广泛的编程

为了培养忠诚的客户群，Freejam 希望使用各种计算系统的各种玩家都可以畅玩 Robocraft。 初始编程牵扯到确定旧显卡和新显卡，其中包括集成显卡和非集成显卡。 该团队目前使用 Unity 4 和 Microsoft DirectX* 9 进行游戏编程。

Mandalà 表示：“我们知道针对较新机器的编程更酷，我们可能以后专注于这个方面，目前我们希望能够完全控制较低端的机器。 例如，我们将能够用更详细的东西进行定义，如阴影和柔和阴影，以便游戏有更好的视觉效果。 这将涉及切换到 Unity 5 并创建面向 DirectX 11 或 12 的特别版。 我们将针对速度更快的机器，对已经不错的游戏进行改进。 这是一个持续过程，这是我们未来计划的一部分。 目前，Robocraft能够根据每个玩家的计算资源进行调整，检测 CPU 和 GPU 填充率等系统规格并相应运行。

图形设计

图形设计带来了更多挑战。 Mandalà 解释道： “由于玩家构建机器人，因此每个机器人都有独特的形状。 最初，借助 Unity 4，我们分别渲染了每个立方体并为其分配了相应的对撞机，但渲染和物理引擎在许多机器上运行不佳。 在有成千上万个基元的情况下，Unity 4 的性能远远不够，所以我们不得不重新设计代码，以便能够处理我们的场景。 能够在战斗过程中修改机器人的形状是另一个挑战。 在我们的新算法中，绘制调用次数大大减少，而对撞机进行了聚合和简化。 最后，我们在游戏上线之前，在设计流程中加入了这些优化。” 图 3 显示了在战斗中被摧毁的机器人的形状变化。

图 3： 被摧毁的机器人

为了针对拥有嵌入式 GPU（使用 DirectX）的计算机优化该游戏，该团队最大限度减少了绘制调用次数，对使一个机器人形成一个绘制调用的所有立方体进行了批处理。 填充率优化对于集成显卡至关重要，为了对其进行优化，该团队实施了一种算法来动态跳过被其他立方体遮挡的立方体面的渲染。 最后，该游戏充分利用了 Unity LoD 系统，以减少远离摄像头的机器人的动态部分的绘制调用次数和多边形数。

屏幕分辨率带来了一些问题。 Mandalà 表示：“屏幕分辨率与填充率相关。 近期的强大显卡可以毫无问题地处理高分辨率，但旧显卡会受到严重影响。 为了解决这个问题，我们部署了多个显卡分辨率设置，从“最快”到“极佳”到这两者之间。 在最近的显卡中，最轻模式有特别优化，而最重模式可提供更多图形细节。 图 4 显示了快速模式下的游戏。 启用了正向渲染和阴影。 最高设置中提供了延迟着色和相对后期处理效果。

图 4： 优化的屏幕分辨率

Mandalà 表示： “凭借 Unity 5 和新引擎中实施的出色优化，我们已经打算在物理和显卡方面，添加更多能够使游戏更逼真的特性。

英特尔的参与

为了确保该游戏能够在英特尔® 架构上顺畅运行，Freejam 团队在 Unity 中间件上运行 Robocraft。在 Mandalà 看来，Unity 中间件是面向英特尔® 平台的出色引擎。 他还表示：“不过，我们在游戏中引入了许多自定义优化以改进在英特尔平台上的性能，我们还一直针对 32 位系统和 64 位系统进行优化。 在不久的将来，我们将更加注重开发英特尔® 多核技术，更好地满足拥有较高端电脑的玩家的需求。

该团队还使用了许多英特尔工具，特别是用于分析和质量保证 (QA) 的工具。 Mandalà 表示：“尤其是英特尔® 图形性能分析器 [英特尔® GPA]，对于帮助我们优化性能有着非常重要的作用。 性能对我们至关重要，因为我们发现，帧速率和玩家保留率之间有很强的关联性。 我们使用英特尔 GPA 来诊断瓶颈并优化游戏，以提高帧速率和玩家保留率。”

英特尔 GPA 等工具可告知团队如何最好地优化渲染代码，但 Robocraft受限于 CPU，而非 GPU。 Mandalà 表示：“我们在 CPU 上优化，同时不妨碍 GPU 的当前任务。” 他还表示：“英特尔支持一直是一流的！ 这些工具很棒，特别是英特尔 GPA，但我的最终愿望是将 VTune 与 Unity 一起使用。

测试和开发后

该团队在扩展上线之前，通过一个包含许多反复的内部问答流程对该游戏进行了测试。 该流程包含一个面向英特尔电脑的广泛测试平台，从采用英特尔® 酷睿™ 双核处理器的电脑到采用英特尔® 酷睿™ i7 处理器的电脑。

Robocraft的游戏即服务性质使得该团队可以在一个封闭的用户环境中测试某些功能，从社区收集反馈。 社区反馈是开发流程的重要组成部分，会一直监控。

Freejam 是一个自发布 Robocraft的独立开发商。 Mandalà 表示：“我们在随着游戏的演变发展社区方面取得了良好的进展。 我们在市场中的成功是必然的，这也是因为我们与英特尔和其他方开展了密切合作，采用了 Steam* 娱乐平台，影响了全球数百万玩家。"

该团队打算改进这一游戏，包括添加新的游戏模式、创意选项、社区和社会设施以及其他元素。 虚拟现实也是该团队即将探索的领域之一。 Mandalà 表示：“我们将继续使用英特尔的平台、支持和工具进行不断开发、测试和优化，确保游戏与 CPU 和 GPU 技术的发展保持一致。 处理能力越强，游戏表现越好，“极佳”设置越好。 在未来，举个例子，我们将使用采用多线程代码的英特尔多核架构，减少游戏对 CPU 的依赖，进一步改进速度和显卡。”

Freejam 还正在与英特尔讨论如何共同努力，提高其品牌和产品在各自社区内的知名度。

未来计划

Robocraft用户社区始终是 Freejam 的重要驱动力。 Mandalà 表示：“我们始终相信这款游戏，我们的直觉告诉我们它会很好。 从我们的社区得到用户喜欢这款游戏的确认，这是一种对我们的奖励。 我们每天都与用户直接进行很多交流。 用户有时喜欢我们的游戏，有时也表示不满。 与用户保持联系可能是一件筋疲力竭的事情，但也有许多快乐。

Mandalà 表示，用户社区互动推动着游戏更新的步伐。 “我们有这些好想法，并与社区分享和讨论我们的理论。 这就是我们发展如此迅速的原因。” 技术的发展步伐在更新速度中也起到一定的作用。 Mandalà 表示：“高性能硬件的价格下降得越快，我们就可以越快地让社区用户使用更好的显卡畅玩 Robocraft，因为新架构支持更高的游戏画质设置。”

该游戏的发展意味着 Freejam 的发展。 Freejam 创立之初只有一个 5 人组成的团队，在短短两年的时间里员工人数已增加到 50 人。 Mandalà 表示，扩大规模是很有必要的，因为团队想要实现的功能有很多，但过渡具有挑战性。 这是一个好的挑战。 我们必须建立更细化的结构，这是一件有积极意义的事情。 我们还需要加大营销力度，在营销方面投入更多资源。”

所有这些增长造就了一款可靠的游戏和忠实的追随者。 Freejam team 注意到，自 Freejam 发布 Robocraft后，市场上出现了几款理念类似的游戏。 Mandalà 指出，该游戏将继续改进 “Robocraft是一种在线服务，开发还在继续。 我们已经开发了两年多了，但我们还有许多工作要做。我们的事业尚未完成！”

Mandalà 建议希望创建类似的在线游戏即服务项目的开发人员认识到，这是一项漫长、充满挑战的工作。 他表示：“希望不断开发新的内容，改进功能，鼓励健康的社区反馈循环并针对重要平台和技术开展合作。 不断分析游戏和玩家行为，试验想法，增强或改进具有最小可行产品迭代的服务。 推进获得成功的想法，反思或消除不奏效的想法。 最后，预见意外事件，获得尽可能多的数据并将这些数据与创造力和直觉融合起来，推动实现您和您的社区正在建立的游戏愿景。”

Freejam 团队非常欢迎其他开发人员与我们联系，很愿意与您当面或通过 Skype 讨论项目。 Mandalà 的 Twitter 账户为 @sebify。

总结

通过使用 Unity 和 DirectX 以及与英特尔合作，Freejam 打造了一款名为 Robocraft的游戏。它吸引着各个年龄段的玩家，适用于各种计算技术。 由于关注重点是实用性而非外观，这促使开发团队作出了与后者不同的决策。 例如，这款游戏能够兼容较旧的技术，并适应每个玩家的计算资源。 这款游戏进行了优化，以确保这些旧系统能够处理图形。 Robocraft是一项尚未完工的工作，Freejam 预计未来将有许多令人激动的游戏更新。

关于 Freejam

Freejam 由 5 个坚信一种简单游戏理念—— Robocraft的开发人员在英国朴茨茅斯创立。 他们积累在一起的传统开发经验长达 52 年，但他们完全摒弃了这些经验。 凭借出色的创意和全新的精益创业理念，他们可以自由地创新。

这一开发团队的成立是为了证明，真正令人赞叹的游戏可以通过实验和演变创建出来。 这 5 名团队成员是技能娴熟、有组织的专业游戏开发人员，他们采用了独立方式。 这个公司很小，因此能够快速响应，倾听玩家的心声，快速作出决策，尝试新事物并高效地创建游戏。 与音乐家从一个只有几个和弦的简单即兴演奏进行无拘无束的编曲一样，Freejam 团队创造了一款已发展成为佳作的游戏。

开发人员的方法依赖于与其玩家的开放透明互动，因为他们深知，如果没有玩家的意见，他们无法改进其游戏。 他们不知道 Robocraft最终将走向何方，但这正是乐趣所在。

• 网址：http://robocraftgame.com/about
• Twitter: https://twitter.com/freejamgames
• Facebook: https://www.facebook.com/freejamgames
• Steam 上的 Robocraft：http://store.steampowered.com/app/301520

作者：Confetti 首席执行官 Wolfgang Engel

随着 Windows* 10 在 7 月 29 日的发布以及第 6 代英特尔® 酷睿™ 处理器产品家族（代号 Skylake）的发布，我们现在可以更详细地探讨一下专门针对英特尔® 平台的资源绑定。

之前的文章 “Microsoft DirectX* 12 中的资源绑定简介” 介绍了 DirectX 12 中的新资源绑定方法并得出了如下结论：凭借所有这些选择，面临的挑战在于如何为目标 GPU、资源类型及其更新频率选择最理想的绑定机制。

文本介绍了如何选择不同的资源绑定机制，从而在特定的英特尔 GPU 上高效运行应用。

商业工具

若要使用 DirectX 12 开发游戏，您需要以下工具：

• Windows 10
• Visual Studio* 2013 或更高版本
• Visual Studio 附带的 DirectX 12 SDK
• 支持 DirectX 12 的 GPU 和驱动程序

概述

描述符是一个通过 GPU 特定的不透明格式描述 GPU 对象的数据块。 DirectX 12 提供了以下描述符，之前在 DirectX 11 中名为“资源视图”：

• 常量缓冲视图 (CBV)
• 着色器资源视图 (SRV)
• 无序访问视图 (UAV)
• 取样器视图 (SV)
• 渲染目标视图 (RTV)
• 深度模板视图 (DSV)
• 和其他

这些描述符或资源视图可被视为 PGU 前端使用的结构（也称为块）。 描述符的大小约为 32 到 64 字节，并保存纹理尺寸、格式和布局等信息。

描述符存储在描述符堆中，后者代表内存中的结构序列。

描述符表将偏移保存到这一描述符堆中。 它将一个连续的描述符范围映射到着色器插槽，通过一个根签名使其可用。 这个根签名还可以保存根常量、根描述符和静态采样。

图 1. 描述符、描述符堆、描述符表、根签名

图 1 显示了描述符、描述符堆、描述符表和根签名之间的关系。

图 1 描述的代码如下：

// the init function sets the shader registers
// parameters: type of descriptor, num of descriptors, base shader register
// the first descriptor table entry in the root signature in
// image 1 sets shader registers t1, b1, t4, t5
// performance: order from most frequent to least frequent used
D3D12_DESCRIPTOR_RANGE Param0Ranges[3];
Param0Ranges[0].Init(D3D12_DESCRIPTOR_RANGE_SRV, 1, 1); // t1 Param0Ranges[1].Init(D3D12_DESCRIPTOR_RANGE_CBV, 1, 1); // b1 Param0Ranges[2].Init(D3D12_DESCRIPTOR_RANGE_SRV, 2, 4); // t4-t5

// the second descriptor table entry in the root signature
// in image 1 sets shader registers u0 and b2
D3D12_DESCRIPTOR_RANGE Param1Ranges[2]; Param1Ranges[0].Init(D3D12_DESCRIPTOR_RANGE_UAV, 1, 0); // u0 Param1Ranges[1].Init(D3D12_DESCRIPTOR_RANGE_CBV, 1, 2); // b2

// set the descriptor tables in the root signature
// parameters: number of descriptor ranges, descriptor ranges, visibility
// visibility to all stages allows sharing binding tables
// with all types of shaders
D3D12_ROOT_PARAMETER Param[4];
Param[0].InitAsDescriptorTable(3, Param0Ranges, D3D12_SHADER_VISIBILITY_ALL);
Param[1].InitAsDescriptorTable(2, Param1Ranges, D3D12_SHADER_VISIBILITY_ALL); // root descriptor
Param[2].InitAsShaderResourceView(1, 0); // t0
// root constants
Param[3].InitAsConstants(4, 0); // b0 (4x32-bit constants)

// writing into the command list
cmdList->SetGraphicsRootDescriptorTable(0, [srvGPUHandle]);
cmdList->SetGraphicsRootDescriptorTable(1, [uavGPUHandle]);
cmdList->SetGraphicsRootConstantBufferView(2, [srvCPUHandle]);
cmdList->SetGraphicsRoot32BitConstants(3, {1,3,3,7}, 0, 4);

上面的源代码设置了一个有两个描述符表、一个根描述符和一个根常量的根签名。 代码还表明，根常量没有间接级别，通过 SetGraphicsRoot32bitConstants 调用直接提供。 它们被直接发送到着色器寄存器中；没有实际的常量缓冲、常量缓冲描述或绑定。 根描述符只有一个间接级别，因为它们存储指向内存的指针（描述符->内存），描述符表有两个间接级别（描述符表 -> 描述符-> 内存）。

根据其类型（如 SV 和 CBV/SRV/UAV），描述符驻留在不同的描述符堆中。 这是因为，不同硬件平台上的描述符类型尺寸非常不一致。 对于每种类型的描述符堆，也应该只有一个分配的描述符堆，因为更改描述符堆成本很高。

一般而言，DirectX 12 会预先提供 100 多万个描述符的分配，这对于整个游戏级别足够了。 先前版本的 DirectX 根据自己的情况在驱动程序中处理分配，而在 DirectX 12 中，用户可以避免在运行时进行任何分配。 这意味着，一个描述符的任何初始分配都可以从性能“方程”中取出。

注：凭借第三代英特尔® 酷睿™ 处理器（代号为 Ivy Bridge）/第四代英特尔® 酷睿™ 处理器产品家族（代码为 Haswell）以及 DirectX 11 和 Windows 显示驱动程序模型 (WDDM) 1.x 版本，资源可通过一个页表映射操作，根据命令缓冲区中引用的资源动态映射到内存之中。 这样可避免复制数据。 这种动态映射很重要，因为这些架构只为 PGU 提供 2GB 内存（英特尔® 至强® 处理器 E3-1200 v4 产品家族（代号为 Broadwell）提供更大内存）。
借助 DirectX 12 和 WDDM 2.x 版本，在必要时将资源重新映射到 GPU 虚拟地址空间已经不再可能了，因为资源在创建时必须分配一个静态虚拟地址，因此资源的虚拟地址在创建后不能更改。 即使从 GPU 内存中删除资源，它也会保留其虚拟地址，以便以后再次驻留。
因此，Ivy Bridge/Haswell 中 2 GB 的总可用内存可能会成为一个限制因素。

正如以前的文章中指出的，对于一款应用来说，完全合理的结果可能是所有绑定类型的组合：根常量、根描述符、在发布绘制调用时动态收集的描述符的描述符表，以及大型描述符表的动态索引。

不同的硬件架构会在使用根常量集和根描述符集与使用描述符表之间做出不同的性能取舍。 因此，可能需要根据硬件目标平台调整根参数和描述符表之间的比率。

预期变化模式

要了解哪些类型的变化会产生额外费用，我们必须先分析游戏引擎通常如何更改数据、描述符、描述符表和根签名。

我们从常量数据开始。 大部分游戏引擎通常在“系统内存”中存储所有常量数据。 游戏引擎将更改 CPU 访问内存中的数据，而后在帧中，整块的常量数据将复制/映射到 GPU 内存中，然后通过常量缓冲视图或根描述符由 GPU 读取。

如果常量数据通过 SetGraphicsRoot32BitConstants() 作为根常量提供，根描述符中的条目不会更改，但数据可能更改。 如果常量数据先通过 CBV == 描述符，后通过描述符表提供，则描述符不会更改，但数据可能更改。

如果我们需要多个常量缓冲视图，比如对于双重或三重缓冲渲染，CBV 或描述符可能会针对根签名中的每个帧更改。

对于纹理数据，预计纹理在启动过程中在 GPU 内存中分配。 然后将创建 SV == 描述符，存储在描述符表或静态取样器中，并在根描述符中引用。 数据和描述符或静态样品不会在这之后更改。

对于更改纹理或缓冲数据等动态数据（例如含渲染本地化文本的纹理，动画顶点缓冲或程序生成的网格），我们会分配一个渲染目标或缓冲区，提供一个 RTV 或 UAV（描述符），这些描述符此后可能不会更改。 渲染目标或缓冲区中的数据可能会更改。

如果我们需要多个渲染目标或缓冲区，比如对于双重或三重缓冲渲染，描述符可能会针对根签名中的每个帧更改。

对于下面的讨论，如果进行了以下操作，那么更改对于绑定资源至关重要：

• 更改/替换描述符表中的描述符，例如 CBV、RTV 或 上面描述的 UAV
• 更改根签名的任何条目

Haswell/Broadwell 描述符表中的描述符

在基于 Haswell/Broadwell 的平台上，更改根签名中的一个描述符表的成本相当于更改所有描述符表。 更改一个参数意味着硬件必须复制所有当前参数。 根签名中根参数的数量是任何子集变化时硬件必须进行版本控制的数据量。

注：DirectX 12 中所有其他类型的内存，如描述符堆、缓冲资源等，不由硬件进行版本控制。

换句话说，更改所有参数的成本与更改一个参数的成本大致相同（参见 [Lauritzen] 和 [MSDN]）。 不更改仍然是最省钱的方法，但没有多大作用。

注：其他硬件，比如在快/慢（溢出）根参数存储有分隔的硬件，只需对参数更改的内存区域（无论是快速区还是溢出区）进行版本控制。

在 Haswell/Broadwell 上，更改描述符表的额外成本可能来自于硬件中绑定表格的尺寸限制。

这些硬件平台上的描述符表使用“绑定表”硬件。 每个绑定表项是一个 DWORD，它可被视为描述符堆内的偏移。 64 KB 环可存储 16,384 个绑定表项。

换句话说，每个绘制调用所用的内存量取决于描述符表中索引并通过根签名引用的描述符的总数。

如果绑定表条目的 64 KB 内存用完，驱动程序将再分配 64KB 的绑定表。 这些表格之间的切换会导致管线停滞，如图 2 所示。

图 2. 管线停滞（由 Andrew Lauritzen 提供）

例如，根签名在描述符表中引用 64 个描述符。 每 256（16,384 / 64）次绘制调用发生一次停滞。

由于更改根签名被视为一种经济的方法，因此拥有描述符表中描述符数量较少的多个根签名，比拥有描述符表中描述符数量较多的根签名要好。

因此，在 Haswell/Broadwell 上，描述符表中引用的描述符数量越少越好。

这对渲染器设计意味着什么？ 如果使用描述符较少的更多描述符表，更多的根签名应增加管线状态对象 (PSO) 的数量，因为随着根签名的数量增加，PSO 的数量也需要增加，这两者之间是一对一的关系。

拥有更多的管线状态对象可能导致更多数量的着色器（在这种情况下）更加专业化，而不是提供更多功能的较长着色器（经常作为推荐）。
 

Haswell/Broadwell 上的根常量/描述符

之前我们提到，更改一个描述符表的成本和更改所有描述符表相同，此处也是如此：更改一个根常量或根描述符的成本相当于更改所有根常量或根描述符（参见 [Lauritzen]）。

根常量通过“推送常量“实施，后者是一个硬件用来预填充执行单元 (EU) 寄存器的缓冲区。 由于 EU 线程启动时数值立即可用，将常量数据存储为根常量可实现性能优势，而不要通过描述符表存储它们。

根描述符也作为”推送常量“实施。 它们只是作为常量传送到着色器的指针，通过一般的内容路径读取数据。

Haswell/Broadwell 上的描述符表与根常量/描述符

我们已经介绍了描述符表、根常量和描述符的实施方式，我们便可以回答本文的主要问题：是否一个比另一个要好呢？ 由于硬件中绑定表格的尺寸有限以及跨越这一限制所造成的潜在停滞，预计在 Haswell/Broadwell 硬件上更改根常量和根描述符更经济一些，因为它们不使用绑定表硬件。 对于根描述符和根常量，特别推荐使用 Haswell/Broadwell 硬件，以免数据更改每个绘制调用。

Haswell/Broadwell 上的静态取样器

正如先前文章中介绍的，可以通过 HLSL 根签名语言，在根签名或直接在着色器中定义取样器。 这些被称为静态取样器。

在 Haswell/Broadwell 硬件上，驱动程序将会将静态取样器放置在常规的取样器堆中。 这相当于手动将它们放在描述符中。 其他硬件在着色器寄存器中实施了取样器，因此静态取样器可直接编译到着色器中。

一般而言，静态取样器在很多平台上都应该具有优势，所以使用它们没有缺点。 在 Haswell/Broadwell 硬件上，通过增加描述符表中的描述符数量，我们更容易出现管线停滞，因为描述符表硬件只有 16,384 个插槽。

这是 HLSL 中的静态取样器的语法：

StaticSampler( sReg,
               [ filter = FILTER_ANISOTROPIC,
               addressU = TEXTURE_ADDRESS_WRAP,
               addressV = TEXTURE_ADDRESS_WRAP,
               addressW = TEXTURE_ADDRESS_WRAP,
               mipLODBias = 0.f,     maxAnisotropy = 16,
               comparisonFunc = COMPARISON_LESS_EQUAL,
               borderColor = STATIC_BORDER_COLOR_OPAQUE_WHITE,
               minLOD = 0.f, maxLOD = 3.402823466e+38f,
               space = 0, visibility = SHADER_VISIBILITY_ALL ])

大部分参数都是一目了然的，因为它们类似于 C++ 级别用途。 主要区别在于边框颜色：在 C++ 级别上，它提供一个完整的色彩范围，而 HLSL 级别仅限于不透明的白色/黑色和透明的黑色。 静态着色器的示例为：

StaticSampler(s4, filter=FILTER_MIN_MAG_MIP_LINEAR)

Skylake

Skylake 支持在一个描述符表中对整个描述符堆（约 100 万资源）进行动态索引。 这意味着，一个描述符表就足以索引所有可用的描述符堆内存。

相比以往的架构，没有必要在根签名中经常更改描述符表条目。 这也意味着，根签名的数量可以减少。 显然，不同材料将需要不同的着色器和不同的 PSO。 但这些 PSO 可以引用相同的根签名。

由于现代渲染引擎利用的着色器数量比 DirectX 9 和 11 少以便消除更改着色器和附加状态的成本，因此减少根签名和 PSO 的数量是有好处的，应该能够在任何硬件平台上实现性能优势。

结论

专注于 Haswell/Broadwell 和 Skylake，开发高性能 DirectX 12 应用的建议都依赖于底层平台。 对于 Haswell/Broadwell，描述符表中的描述符数量应保持低水平，而对于 Skylake，建议保持较高数量并减少描述符表的数量。

为了实现最佳性能，应用编程人员可以在启动期间检查硬件类型，然后选择最有效的资源绑定模式。 （有一个 GPU 检测示例，展示如何检测不同的英特尔硬件架构：https://software.intel.com/zh-cn/articles/gpu-detect-sample/) 资源绑定模式的选择将影响到系统的着色器如何编写。

关于作者

Wolfgang 是 Confetti 的首席执行官。 Confetti 是电子游戏和电影行业的先进实时图形研究与服务提供商的智囊团。 在与他人合作创立 Confetti 之前，Wolfgang 曾在 Rockstar 的核心技术组 RAGE 任职首席图形程序员超过 4 年。 他是 ShaderX和 GPU Pro系列书籍的创始人和编辑、微软最有价值专家、实时渲染相关书籍和文章的作者，以及多家网站的定期撰稿人和全球会议的定期参与者。 他参与编辑的一本书籍《ShaderX4》于 2006 年赢得了游戏开发前线名人堂奖项。 Wolfgang 还是整个行业中许多咨询委员会的成员；其中一个是微软面向 DirectX 12 的图形顾问委员会。 他还积极参与制定推动游戏行业的多项未来标准。 您还可以在 Twitter 上了解他的更多信息，帐户名为 wolfgangengel。 Confetti 的网站为 www.conffx.com

致谢

在此感谢本文的审核人员：

• Andrew Lauritzen
• Robin Green
• Michal Valient
• Dean Calver
• Juul Joosten
• Michal Drobot

参考资料和相关链接

• [Lauritzen] Andrew Lauritzen 等人， “借助英特尔显卡上的 DirectX 12 进行高效渲染”, GDC 2015
• [MSDN] MSDN, “描述符表的高级使用，”https://msdn.microsoft.com/zh-cn/library/windows/desktop/dn859250(v=vs.85).aspx
• Microsoft DirectX 博客：http://blogs.msdn.com/b/directx/
• Twitter 上的 DirectX 12： @DirectX12https://twitter.com/DirectX12
• Direct3D* 12 - 电脑上的控制台 API 效率和性能 (https://software.intel.com/zh-cn/articles/console-api-efficiency-performance-on-pcs)
• Microsoft DirectX 12 显卡培训（YouTube 频道）： https://www.youtube.com/channel/UCiaX2B8XiXR70jaN7NK-FpA

** 在性能检测过程中涉及的软件及其性能只有在英特尔微处理器的架构下才能得到优化。 诸如 SYSmark* 和 MobileMark* 等测试均系基于特定计算机系统、硬件、软件、操作系统及功能， 上述任何要素的变动都有可能导致测试结果的变化。 请参考其他信息及性能测试（包括结合其他产品使用时的运行性能）以对目标产品进行全面评估。

2014年的IDF，英特尔的CEO BK在Keynote上演示了一款体感控制的夹娃娃机，当娃娃被抓出来的时候，全场响起雷鸣般的掌声。BK在演讲上说这款产品是广州一家公司里面三个人、三天做出来的产品，是的，就是我们做的。我们是TBS(广州数娱科技)。

    很多媒体问我们是怎样想到做这样一个产品，我的回答很简单：觉得好玩。其实真正原因是我经常陪女儿玩抓娃娃机，被坑钱太多了，我考虑到经济效益问题和技术问题，需要一款改变世界的革命性产品去实现心中的渴望——在女儿面前炫耀能隔空取物抓娃娃。

    所以我去买了一台娃娃机回公司，是的，买了一台娃娃机回公司。要知道全球娃娃机有8成出自广东，所以我开车去买一台还是很容易。第二天娃娃机就送到了，我叫了工程师过来，用了一天时间把单片机的控制电路改装接上了电脑，连上我们自己开发的一款叫PIC的RealSense控制软件。。。3天后，就在朋友圈得瑟体感控制娃娃机的绝技了。后来在美国偶然机会被选上IDF KEYNOTE，产品化的伏笔就此开始。。。

    在IDF KEYNOTE后，在booth的demo中，我们两台娃娃机前面整整两天的长队没断过，虽然旁边几个booth都是在展示我们其它三款产品，但用户的热情完全被趣抓Funcap吸光了。（我们旁边展示的游戏产品上年也预装了联想的RS电脑J

    其实在演示前，我们已经将这款产品申请了发明专利，如此好的市场反馈，让我们充足信心地将其产品化。

    一个月后我们更与微信合作，接入了微信支付功能，当时微信支付还没接入过智能硬件中，得到微信团队的大力支持，2周完成接入与测试。

    到此，这款产品已经被海内外媒体称为“黑科技”娃娃机了。其中使用到的技术涵盖软件和硬件的多个领域，关键的RealSense技术是里面最“黑”的，隔空取物就是靠RealSense的手势模块实现的。我们可以三天完成原型，全靠RealSense SDK的简单易用（广告）和我们三年坚持开发RealSense的信念（非广告）。

    趣抓FUNCAP的产品化的心路历程我想下次说，因为太长篇了。。。现在趣抓FUNCAP已经产品化量产了，全国多个城市已经进驻，黑科技其实就在你身边。产品详情可以来看看www.GongZaiJi.com ，欢迎给宝贵意见mail@thebestsync.com。

本指南可帮助您使用英特尔实感软件开发套件中的英特尔® 实感™ Unity* 工具套件，将实感技术集成到您的项目中。 本指南假设您安装了支持版本的 Unity 和最新版本的英特尔实感软件开发套件，并已将英特尔实感 Unity 工具套件导入到您的开发环境中。 有关将工具套件导入 Unity 的指南请见指南的专题博客“将英特尔实感 Unity 工具套件添加至您的项目的 8 个步骤”。

创建简单的游戏对象 1. 我们将在 Hierarchy 屏幕中使用新项目开始该示例，点击 Create 按钮，然后选择 Cube， 从而添加一个 Cube 游戏对象至 Scene。
2. 在 Hierarchy 屏幕中，点击 Create 按钮，然后选择 Directional Light， 从而添加一个光源至 Scene。
3. 在 Assets 屏幕，双击文件夹图标先后展开 RSUnityToolkit 文件夹和 Actions 文件夹。
4. Actions 文件夹包含多个可应用于游戏对象的脚本。 点击 TrackingAction 脚本，然后将它拖放到 Hierarchy 屏幕的 Cube 游戏对象上。
5. 现在，在 Hierarchy 屏幕中选择 Cube，然后确认 Tracking Action (Script) 显示在 Inspector 屏幕上。
配置 Hand Tracking 6. 在默认情况下，Tracking Action 设置为 HandTracking，Virtual World Box Dimensions 的 X、Y 和 Z 值设置为 100。如果您此时玩游戏，您会看到 3D 景深摄像头的 LED 开启，这表明摄像头已激活。
7. 如果 在摄像头前面抬起手，您可能会看到 Cube 游戏对象使屏幕关闭。 这是因为 Virtual World Box Dimensions 的值设置过高。 将 Virtual World Box Dimensions 的 X、Y 和 Z 值设置为 10。
8. 在 Scene 视图中，您会注意到游戏对象周围用红色标示的 Virtual World Box 现在更为狭小。
9. 再次运行游戏。 Cube 游戏对象现在应该在更狭小的虚拟空间内更密切跟踪您的手部。
10. 您可能会注意到，Cube 游戏对象在移动时会有所抖动。 将平滑系数提高至 10（默认为 0） 可减轻这种抖动。
配置 Face Tracking 11. Cube 游戏对象可被轻易修改以跟踪用户的脸部。 找到 Inspector 窗口中的 Tracking Action，并将默认的 HandTracking 更改为 FaceTracking。
12. 运行游戏，确保您的脸部处于摄像头的视野内。 游戏对象的动作现在应可以跟踪您的脸部，并根据用户的头部动作（摇晃、倾斜和偏航）而旋转。

恭喜您，您已将英特尔® 实感™ 添加至您的 Unity 项目中！ 现在您可以继续工作，创建出色的游戏了。 希望这对您有所帮助。

链接：

Unity 4 Pro 试用版下载，

英特尔® 实感™ 软件开发套件下载

这是我之前写的了，一直保存在电脑里，现在学习写博客。希望多和大家交流，共同进步，文章中说得不好的地方请指出，谢谢！
使用Unity3D进行网络游戏开发
一.Unity3d 简介
     Unity3d是时下比较流行的一款游戏引擎，流行是因为用它做游戏很方便，无论是3d还是2d都会有非常好的效果，即便某些朋友不懂编程，也可以通过Unity自带的组件做出一些简单的诸如三维视频游戏、建筑可视化、实时三维动画等类型的小作品。在正式发布前，Unity经历的多年的开发阶段，Gooball在2005三月发布，运用了Unity的预发售版本 开发。Unity从出道到现在已有8年历史，有很多优秀的作品都是用Unity做的，诸如《神庙逃亡》、《绝代双骄》、《坦克英雄》、《将魂三国》、《梦幻国度2》、《新仙剑Online》以及《纵横无双》等。


二.网络游戏简介
  
    网络游戏又称为MMOG(Massivemultiplayeronlinegame)。通常只要某一游戏的服务器端到客户端连线玩家数量超过
1000人即可算作大型多人在线游戏，但是狭义上必须有大量玩家处于同一“游戏世界”的游戏才能称之为大型多人在线
游戏。
    目前网络游戏的分类主要如下：
     1.从使用形式上进行分类：
    浏览器形式和客户端形式。基于浏览器的游戏，也就是通常说到的网页游戏，又称为WEB游戏，它不用下载客户端，任何地方任何时间任何一台能上网的电脑快乐的游戏，尤其适合上班族。其类型及题材也非常丰富，典型的类型有角色扮演（天书奇谭）、战争策略（热血三国）、社区养成（猫游记）、SNS（开心农场）等。 而对于客户端形式这一种类型是由公司所架设的服务器来提供游戏，而玩家们则是由公司所提供的客户端来连上公司服务器以进行游戏，而现在称之为网络游戏的大都属于此类型。此类游戏的特征是大多数玩家都会有一个专属于自己的角色(虚拟身份)，而一切存盘以及游戏资讯均记录在服务端。此类游戏大部分来自欧美以及亚洲地区，这类型游戏有World of Warcraft(魔兽世界)(美)、战地之王（韩国）、EVE Online（冰岛）、战地（Battlefield）（瑞典）、信长
之野望Online(日本)、天堂2（韩国）、梦幻西游（中国）等等。

    2.从游戏种类上进行分类：

   棋牌类休闲网络游戏：即登陆网络服务商提供的游戏平台后，进行双人或多人对弈，如纸牌、象棋等，提供此类游戏的公司主要有腾讯、联众、新浪等。网络对战类游戏 ：即玩家通过安装市场上销售的支持局域网对战功能游戏，通过网络中间服务器，实现对战，如CS、星际争霸、魔兽争霸等，主要的网络平台有盛大、腾讯、浩方等。角色扮演类大型网上游戏：即RPG类，通过扮演某一角色，通过任务的执行，使其提升等级，等到宝物等，如大话西游、传奇等，提供此类平台的主要有盛大等。

   3.从游戏模式上进行分类：
     这样分类比较多，主要有：一、 MMORPG-大型多人角色扮演类游戏，如时下火爆的《DNF》《DN》《诛仙3》等。二、MMOFPS-大型多人第一人称射击游戏，如《CF》等。三、MMOKTS-大型多人及时策略游戏，这类游戏目前主要以浏览器形式发展而非客户端，如《破碎银河系》等。 四、MMODG-大型多人网络舞蹈游戏，《劲舞团》已经火了很多年了。 五、MMOMG-大型多人网络经营类游戏，这类游戏也是主要依托浏览器形式发展，如《Hattrick》等游戏。 六、MMOR-大型多人网络竞速类游戏，如《跑跑卡丁车》等游戏。 七、MMOTG-大型多人网络大亨类游戏，代表作为《网络大富翁》。 八、MMOSG-大型多人网络体育类游戏，以《街头篮球》为代表。
 
   四.网络游戏的架构：
     一、PTP(Peer-to-Peer)即在多个玩家参与的游戏中，各玩家之间采用Peer-to-Peer的直接通信方式。在网络通信服务的形式上，一般采用浮动服务器的形式，即其中一个玩家的机器既是客户端，又扮演服务器的角色，一般由创建游戏局的玩家担任服务器（主机）。很多对战型的RTS网络游戏都采用这种结构。
     二、基于游戏大厅代理的结构，通过会话大厅（lobby）结构，为不同玩家牵线搭桥，既直接管理客户端，也管理游戏局，是回合制网络游戏的常见类型
     三、网络游戏的最典型的结构是C/S结构，特别适合于多人在线游戏，如RPG，成千上万人进行同一场游戏。服务器上有完整的游戏世界模型，玩家在客户端去观察这个世界，并与之互动。C/S结 构的优点是能够充分发挥客户端计算机的处理能力，很多工作可以在客户端处理后再提交给服务器，使得客户端响应速度快。对于网络游戏来讲，这是十分关键的。 其缺点就是网络游戏的升级比较麻烦，每次升级需要客户端下载体积庞大的更新软件，然后进行安装，对于一些带宽并不是十分充足的用户而言，升级就成了游戏的梦魇。不过，良好的客户端程序框架设计完全可以避免升级时下载庞大的更新软件。比如，客户端软件可以把场景定义文件独立出来，客户端程序在运行时动态加载 场景定义文件。这样，当网络游戏的设计者发现需要增加游戏场景时，他只需要更新一个场景定义文件就可以了，当然还需要一些必需的场景资源文件，如新增加的 图像、背景音效等。


三、使用Unity开发简单的网络游戏
    网络游戏和单机游戏最大的区别就是网络游戏把单机游戏的逻辑判断移到了服务器端。当客户端向服务器发出一个请求后，比如说行走，服务器收到客户端发来的这个数据包，然后读出内容，进行逻辑判断处理，然后把结果从新返回给客户端。客户端收到服务器的回复后，开始进行屏幕渲染，于是就出现了行走的动画了。逻辑判断在服务器端，客户端只负责渲染。把逻辑放在服务器端有一个很明显的好处，就是防止第三方修改数据，即降低玩家“开挂”的可能性。使用Unity进行网络游戏开发，最好不要用Unity自带的NetworkView,选择socket更好，理由如下：（我这里借鉴A哥所总结）
  一、unity network 需要向unity的masterserver服务器注册我们的服务，而socket服务由开发者自己定义
  二、采用socket想要共享哪些数据更加灵活 而network显然是没有这么方便
  三、网络占用 socket在需要的时候 只需要传输开发者定义好的需要交互的数据即可 network则是整个的实时同步 网络占用会高出不少
  四、network是类似于p2p的客户端直连共享模式 需要nat穿透 用户的设备不一定支持。
  
    

test test test

What's New in Intel® Stress Bitstreams and Encoder 2016 R4

by Jeff McAllister, technical consulting engineer for Intel® Media Server Studio product family
 

Video is an ever-present part of our lives - and to get high-quality video content out the door, not only are the best encoders and decoders needed, but ensuring they are compliant, can handle multiple stream scenarios, and pass validation tests quickly is where the rubber - and big costs - can hit the road.

With Intel® Stress Bitstreams and Encoder (Intel® SBE), codec developers and architects can perform extensive, production-scale media validation and debug to ensure that decoders are market-ready, and significantly reduce testing cycles through a range of test inputs and tools.   

New Release: Improve Decoder Compliance, Decrease Validation Time

The most recent release of Intel® SBE delivers scalable HEVC (SHVC) and HEVC 4:0:0 (Monochrome) to improve compliance/performance tests, HEVC smoke test streams, and AVS 2.0 visual streams.

As image resolutions extend to UHD/4K and beyond, the benefits of increased quality (or decreased bandwidth to maintain a quality threshold) often come with the cost of increased algorithm and spec complexity. As a decode solution provider, this increases validation difficulty. A more complex spec means increasing test suite coverage to ensure decoder compatibility.

Intel® SBE's continuing development helps codec developers and architects ensure that decode products are ready for a wide range of codecs and spec extensions.

• Note that in Intel® Video Pro Analyzer's recent 2016 R4 release, related improvements include HEVC extension support for SHVC and Multiview, as well as AVC 10-bit support for delivering HDR content.
   

Top New Features

• Extended HEVC Stress and Syntax Streams - SHVC & Monochrome: A new set of stress (performance) and syntax (compliance) streams is added to validate HEVC decoders supporting SHVC Main (with multiple layers) and 4:4:0 (Monochrome) profiles. SHVC allows developers to deliver reliable viewing experiences by allowing adjustments to resolutions and frame rates according to changing network conditions. HEVC 4:0:0 streams cover scenarios when encoded color information is reduced to allow more efficient encoding for monochrome streams. See Figures 1 and 2 below.
   

• AVS 2.0 Visual Streams: Intel strengthens its portfolio of validation streams for AVS 2.0 (a common media format used in China). New Visual streams combine functional testing (coverage of syntax elements and decoder’s code blocks) with output designed for visual analysis.(See detail on AVS 2.0 Stress and Syntax streams in this blog: Intel Delivers AVS 2.0 Bitstreams for Efficient Decoder Validation - English - Chinese.)
   
• Significant Improvements to VP9 Streams and Tools: Smoke test coverage improved with 2x reduction of memory footprint, 100% context coverage, and new error resilience streams for Profiles 0 and 2. In the VP9 Random Encoder, a new mode allows you to control coefficient distribution by tokens, providing better coverage for custom streams.

More Information 

• Visit our product site or Media Tools site for other advanced software tools
• Read about new Intel SBE AVS 2.0 support
• View Intel SBE Overview video
• View Intel SBE Branch & Syntax Coverage video
• View Analysis Tools to Quicken Streams Testing video
   

A Solid Foundation with Intel Architecture, Media Accelerators & Software

Intel has a longterm commitment to delivering computing technologies that change the world - from cloud, data center, mobile to event the tiniest embedded sensors. And Intel is here to help with the media and broadcasting industry take the fullest advantage of Intel® architecture, providing pathways to innovation such as to next gen formats like HEVC, VP9, and other emerging standards for increased coding efficiency. Transitioning down this path is crucial for video solution providers to stay competitive and overcome bandwidth constraints as image resolutions extend to UHD/4K and beyond.