Gokhan discusses how he used the Starter Kit as a base for learning about DirectX programming, and demonstrates how he used the Visual Studio Shader Designer to create some of the effects in his app.

• [00:00] - Gokhan and Roberto talk about the app and Gokhan's experiences with DirectX and the Starter Kit
• [10:56] - Gokhan demos the Virtual Experiment Laboratory app
• [14:32] - Behind the scenes - making a dynamic sprite with the Visual Studio Shader Designer
• [18:37] - Behind the scenes - making an animated flame with the Visual Studio Shader Designer

Come watch the Starter Kit and the Visual Studio graphics tools in action to create rich 3D user interfaces for your app.

For more information, you can find Gokhan on Twitter: @gokhansengun.

Roberto is also on Twitter: @robertos_br. Please let us know if you have an app on the Store that uses the VS 3D Starter Kit!

DrumkitX

A Windows Phone 8 port of the ​Drumkit XNA example using Direct3D and XAudio for fast graphics and low latency sample playback. This demo app lets you play percussion sounds by tapping the screen. You can record your beats, play them back later and also play drums on top of your latest recording.

---

This example has been implemented for various platforms; ​With Qt for Symbian, MeeGo Harmattan and ​JavaME for Series 40. The XNA version supporting Windows Phone 7.x can be found ​here.

Compatibility

• Compatible with Windows Phone 8 phones
• Tested with Nokia Lumia 920 and Nokia Lumia 820
• Developed with Visual Studio 2012 Express for Windows Phone 8

Here's a snip from the technical documentation

The basic structure of DrumkitX was generated with the ​Windows Phone XAML and Direct3D App wizard in Visual Studio. The following diagram is a high-level overview of the architecture:

DrumkitX is the managed component part of the solution. It is structured like a regular XAML app with pages and C# code-behind classes. In the XAML and Direct3D App template, the Direct3D content is rendered onto a DrawingSurface control that is laid out in regular XAML like any other interface element.

DrumkitXComp is the native C++ component that takes care of graphics and audio using Direct3D and XAudio2. It knows nothing of the managed component, it is only provided with a surface to draw onto.

The native component uses the ​DirectX Toolkit to simplify resource handling and drawing, specifically loading textures with DDSTextureLoader and drawing them with SpriteBatch.

...

And a snip from the solution;

Finally the app itself, which compiled and ran for me with no problems...

On the outside it's simple, but shows off a number of interesting things you can do...

In this episode, Roberto Sonnino, a software developer on the Visual Studio team, walks through creating a dice rolling app with the Starter Kit, and shows that the same code can be recompiled for Windows RT and Windows Phone 8 devices.

The accompanying walkthrough is published on the Visual C++ team blog as a three part series:

• Part 1
• Part 2
• Part 3

dx.h - A modern C++ library for DirectX programming

dx.h is a modern C++ library that aims to simplify DirectX-related development in C++.

It focuses on Direct2D but also includes support for Direct3D, DXGI, DirectWrite, the Windows Imaging Component (WIC), and the Windows Animation Manager (WAM).
dx.h is compatible with Windows 7, Windows 8 (both desktop and Windows Store projects), and Windows Phone 8. The Direct2D 1.0 subset should even work on Windows Vista.

For in-depth Direct2D training, please check out Direct2D Fundamentals. For a crash course in DirectX programming, and even more Direct2D training, check out Direct2D Fundamentals – Part 2.

dx.h was created by Kenny Kerr.

There's no carebear here, no doc's beyond the code, no diagrams, no Solutions, no help files, no compiled downloads, just code, code, code (and in the end, that's all you really need, right?)

Source

If you're a C++ DirectX'er you're probably not even gotten this far down the post have you? You're already check out the code, aren't you? 

• [00:31] Build 2013
• [01:04] #785 – Using the Visual Profiler Tool, #783 – Downloading and Installing the WPF Performance Suite (Sean Sexton), WPF Performance Suite
• [01:45] Brew 1.0 has arrived! [Found Via: The Morning Brew #1321]
• [02:23] Backbone 1.0 (Jeremy Ashkenas) [Found Via: The Morning Brew #1321]
• [02:50] Git Patterns and Anti-Patterns (Luca Milanesio)
• [04:03] Developing an app with the Visual Studio 3D Starter Kit, part 1 of 3 (Roberto Sonnino)
• [04:51] GDC 2013 Windows Developer Content Direct3D Game Templates
• [05:29] New middleware makes porting games to Windows Phone easy (Todd Brix)
• [06:06] Windows Phone Apps - Watch Your Code for Hidden Activity (Den Delimarsky)
• Channel 9 Highlight:[07:08] Build Windows 8 Apps with YUI (Jeff Burtoft)

Picks of the Week!

• Brian's Pick of the Week:[07:40] Arena.Xlsm, an RPG built using Excel, carywalkin.wordpress.com, Version 1.1, Arena.Xlsm wiki
• Clint's Pick of the Week:[08:11] Dynamic Lockscreen Changer for Windows Phone 8, Built With ASP.NET MVC and Azure Mobile Services (Clint Rutkas, Den Delimarsky)

What? No? (Well of course I know YOU have, but maybe there's a few other haven't...)

What is Fall Fury anyway?

FallFury is a 2D platformer in which the player controls a falling bear, trying to avoid obstacles, dodge missiles, and destroy monsters as the bear falls. The project incorporates several of the new Windows 8 APIs, including the accelerometer and touch as well as integrations with core OS capabilities such as settings and share charms. Additionally, the project leverages the most exacting addition to the Visual Studio development environment—hybrid application development with XAML, C++, and DirectX.

Here's the Table of Contents for the entire series;

• Fall Fury: Part 1 - Introduction
• Fall Fury: Part 2 - Shaders
• Fall Fury: Part 3 - Basic Rendering and Movement
• Fall Fury: Part 4 - XAML Interop
• Fall Fury: Part 5 - Creating Levels
• Fall Fury: Part 6 - Rendering Level Elements
• Fall Fury: Part 7 - Animations
• Fall Fury: Part 8 - Element Interaction
• Fall Fury: Part 9 - Particle System
• Fall Fury: Part 10 - Charms
• Fall Fury: Part 11 - Hardware Testing & Debugging
• Fall Fury: Part 12 - Conclusions

There's videos, code explications, stuff to download, all there...

But 12 posts can be allot to click through, especially if you want something printable or readable offline. Wouldn't it be great if all this content were available in a single PDF?

Fall Fury, the PDF

That's right! All 12 posts in the series are now available in a nicely formatted 131 page PDF!

Download and get your Teddy's on! (Wait... that doesn't sound right... um... err... um... 

Last June (wow, has it been that long?) we covered the DirectX Toolkit, DirectXTK - the DirectX Tool Kit (which can be found here, http://directxtk.codeplex.com/). Today's project uses the DirectXTK and shows you how to take it into the Windows App Store world...

Windows Store DirectX C++ Sample Base

I’ve been working on this on and off for over a year now (having essentially restarted entirely in the latter half of 2012). At last it is finished. I give you a Windows Store DirectX C++ Sample Base. It’s something you could build a game on top of. It’s something you could build a sample on top of. It passes WACK testing (or did until I reverted to the default icons anyway) and runs properly on my Surface RT as well as my other x64-based computers. It handles rotation. Lets you choose a fixed back buffer size. Includes an audio engine class, a Texture2D class, and a RenderTarget2D class. Makes use of DirectXTK. Lets you do fancy things like mixing XAML and DirectX while still using multisampling. Has a custom settings pane with premade volume controls, a privacy settings pane (you need to supply the appropriate privacy policy and any other controls you need, if any), and even an about settings pane. Shows you the basics of using XInput. Shows you the basics of doing async in C++ using the ConcRT PPL Tasks library. And it even includes Shawn Hargreaves’ cat and a Cornflower Blue background!

...The code is all very commented. Key things you’ll want to look at are App.xaml.cpp, DirectXPage.xaml.cpp, DirectXPage.xaml, and Game.cpp (which derives from DirectXBase, which you may also want to look at). Note that the descriptions of what functions do are all in the header (.H) files whereas the comments on how they do it tend to all be in the CPP files.

...You can grab the sample here: BaseWin8Direct3DApp.zip [GD: Click through to the original post and get the download link there... I didn't want to leach his traffic....]. You need to be running Windows 8 and Visual Studio Express 2012 for Windows 8 or Visual Studio 2012 Professional or above. I hope to start creating samples using this as a base to build on very soon. I’d be thrilled if others did the same. I’ll also try to include some posts about developing for the Windows Store in general (helpful links, good blogs, etc.) and about using C++.

...

Not really up to speed on C++? Michael and SyncFusion have got your back with the free [Reg-ware] ebook, C++ Succinctly.

The code sample downloaded, compiled and ran for me the first time. It's a simple sample, but that's it's intent, a simple sample to get you up and running in the DirectX Windows 8 world...

Also Blog Standards requires all blogs to post at least one cat thing a year, so now we're good for 2013...

Anyway...

Here's a snap of Solution;

As you can see, there's more here than meets the eye, putting more in place than you see in the sample app, helping you do much more than show a cat (not that there's anything wrong with that...

If you want to get started with DirectX in a Windows Store App, this sample looks like a great place to start...

• [0:34] Announcing Release of Windows Azure Media Services (Scott Guthrie)
• [1:42] Broadcast push notifications to millions of mobile devices using Windows Azure Notification Hubs (Scott Guthrie)
• [2:33] Now Available: Windows Phone SDK Update for 7.8 (Cliff Simpkins )
• [3:25] Fall Fury: Part 1 - Introduction (Den Delimarsky, Brian Peek, Clint Rutkas, Dan Fernandez, Rick Barraza )
• [5:16] Tile design guidelines for Windows Phone 8 (Shubhan Chemburkar)
• [6:08] Building the Bing apps for Windows 8 (Jigar Thakkar)
• [7:18] Building HTML5 Games for the Atari Arcade
• [8:36] Introducing SvcPerf - An End-to-End trace Analysis tool for WCF (Sajay Antony), http://svcperf.codeplex.com/
• [9:36] CODEMINE: Building a Software Analytics Platform for Collecting and Analyzing Engineering Process Data at Microsoft (Jacek Czerwonka, Nachi Nagappan, and Wolfram Schulte)
• [10:40] GoingNative 13: Visual Studio 3D Starter Kit, Meet Roberto Sonnino

Picks of the Week!

• Clint's Pick of the Week:[11:43] Everything you need to know about the Lumia 820 and 3D printing (Joel Willans)
• Dan's Pick of the Week:[13:00] Visual Studio ​Achievement​s; they're not Xbox live right? (Cheevos!)

Table of contents

[00:00] GoingNative(); //Ale and Charles talk about the status of the VC++ 2012 CTP and introduce the show's topic,  the 3D Starter kit written by our guest, C++ developer Roberto Sonnino.
[02:55] Ale and Charles interview Roberto Sonnino about his 3D Starter Kit.
[30:16] ~GoingNative();// Ale and Charles destruct the show.

Check out the article for this video at http://channel9.msdn.com/coding4fun/articles/Fall-Fury-Part-12-Conclusions

For the source code, head over to http://fallfury.codeplex.com

Check out the article for this video at http://channel9.msdn.com/coding4fun/articles/Fall-Fury-Part-11-Hardware-Testing--Debugging

For the source code, head over to http://fallfury.codeplex.com

Check out the article for this video at http://channel9.msdn.com/coding4fun/articles/Fall-Fury-Part-10-Charms

For the source code, head over to http://fallfury.codeplex.com

Check out the article for this video at http://channel9.msdn.com/coding4fun/articles/Fall-Fury-Part-9-Particle-System

For the source code, head over to http://fallfury.codeplex.com

Check out the article for this video at http://channel9.msdn.com/coding4fun/articles/Fall-Fury-Part-8-Element-Interaction

For the source code, head over to http://fallfury.codeplex.com

Check out the article for this video at http://channel9.msdn.com/coding4fun/articles/Fall-Fury-Part-7-Animations

For the source code, head over to http://fallfury.codeplex.com

Check out the article for this video at http://channel9.msdn.com/coding4fun/articles/Fall-Fury-Part-6-Rendering-Level-Elements

For the source code, head over to http://fallfury.codeplex.com

Check out the article for this video at http://channel9.msdn.com/coding4fun/articles/Fall-Fury-Part-5-Creating-Levels

For the source code, head over to http://fallfury.codeplex.com

Check out the article for this video at http://channel9.msdn.com/coding4fun/articles/Fall-Fury-Part-4-XAML-Interop

For the source code, head over to http://fallfury.codeplex.com

Check out the article for this video at http://channel9.msdn.com/coding4fun/articles/Fall-Fury-Part-3-Basic-Rendering-and-Movement

For the source code, head over to http://fallfury.codeplex.com

Check out the article for this video at http://channel9.msdn.com/coding4fun/articles/Fall-Fury-Part-2-Shaders

For the source code, head over to http://fallfury.codeplex.com

Check out the article for this video at http://channel9.msdn.com/coding4fun/articles/Fall-Fury-Part-1-Introduction

For the source code, head over to http://fallfury.codeplex.com

As previously mentioned, FallFury runs on multiple types of hardware as long as that hardware supports Windows 8. This article describes the project’s general testing and debugging process, including setting the debug configurations and remote debugging.

Check out the video for this article at http://channel9.msdn.com/Series/FallFury/Part-11-Hardware-Testing.  For a complete, offline version of this series, you may download a nicely formatted PDF of all the articles.

Remote Debug

When working on an application that targets different machines, it’s probably out of the question to install Visual Studio on each instance and move the solution from one source to another in order to run it and diagnose potential problems. Here is where Remote Tools for Visual Studio 2012 come into play. Microsoft offers you three separate builds—tools for x86 systems, x64 systems, and ARM systems—also known as Surface RT.

Once the tools are running on the machine you want to debug, you have two choices. You can either install the remote debugger as a service, allowing it to constantly run in the background, or you can use the debugger on a per-launch basis. From a developer perspective, the choice doesn’t affect how your application is executed on the remote machine. From a security perspective, however, you need to be sure that you properly configure it so that no unwanted apps are remotely deployed.

Now you can start the Remote Debugger Configuration Wizard:

This works on both the initial start-up and also any subsequent launch as a way to easily and quickly set the necessary remote debugger settings. Specifically, it is useful to configure the machine’s network settings, allowing cross-domain communications for debugging purposes.

Once the wizard is completed, launch the Remote Debugger Monitor. Notice that it lists your machine name and the port on which it’s running. This is necessary for configuring the project to send the package to a remote machine instead of the local one:

The configuration depends on the network settings on both the local machine and the subnet as a whole. For example, in some cases, and especially on domain-joined machines, remote debugging is better done with the authentication disabled. Windows Authentication is used by default.

Since FallFury is a C++ project, the configuration for a remote session is different than, say, that of a C# Windows Store application. To configure the session, right click on the project in Solution Explorer and open the Debugging section. Make sure that Remote Machine is selected as the type of debugger to launch:

Next, specify the machine name as well as whether the current session will require authentication:

If you cannot specify the machine name, use the direct IPv4 address of that computer, minus the port (unless you’ve explicitly set it to a port other than 4016, which is the assumed default). Once the source machine connects to the remote one, you will see Visual Studio performing the deployment:

Configurations

As a matter of convenience, it is always good to have different debug configurations that will define how your projects are built, especially if the project targets multiple platforms (such as ARM and x86). Visual Studio provides a Configuration Manager that can be accessed from the debug target dropdown:

FallFury includes two separate projects—the game core, and the C#-based XML reader. Both need to be explicitly associated with separate target platforms in order to be correctly debugged. For that, profiles were created for both local and remote sessions:

As with standard Debug/Release configurations, the ones shown above determine whether the project will carry debug symbols and support debugging commands. It is important to mention that as you switch configurations, you must be careful how you configure the graphic shaders. For each shader in the container folder, explicitly set the HLSL shader type and model. Otherwise the application deployment will fail:

Remote Profiling

Last but not least, when working with different hardware configurations it might be useful to perform application profiling or performance review. Fortunately, Visual Studio also provides this capability through the vsperf tool, which is already integrated in the IDE if you are using Visual Studio 2012 Professional or above.

To initiate a profiling session on a remote device, the Remote Debugger Monitor must be active. Make sure that the Remote Machine debug target is selected, and go to Analyze > Start Performance Analysis:

On the remote machine, allow the vsperf process to run with administrative privileges. Once the profiling session completes and the data is analyzed, you can review the same performance indicators as you would when having a standard application run the profiler on the local machine:

Conclusion

Testing hardware outside the boundaries of a desktop machine is often a necessity, especially if the application relies on specific sensors, such as NFC, touch, or accelerometer. The remote debugging process is fairly streamlined and intuitive, with developing a proper network configuration allowing communication between machines requiring the most significant amount of effort. If you have problems getting the debugger to work, consult this article on MSDN.

With the release of the Windows 8 operating system, applications are now able to easily integrate with each other and have a unified way to control their workflow through unique system-wide contracts called Charms. Out of the multitude of available options, FallFury leverages two charms—Share contract and Settings. This article describes how the integration is implemented.

Check out the video for this article at http://channel9.msdn.com/Series/FallFury/Part-10-Charms .  For a complete, offline version of this series, you may download a nicely formatted PDF of all the articles.

The Share Contract

When a user achieves a specific score in the game, he might decide to share it with his social circle. In Charms, that’s the purpose of the Share contract, which integrates directly with the OS.

Windows Store applications have the capability to expose their sharing capabilities and register as a share target. For example, if there is a Twitter client out, it can register itself as an app through which content can be shared. FallFury, on the other hand, acts as a consumer that aggregates existing share targets and lets the user pick the one through which he wants to let the message out:

Let’s take a look at how this process is built in the code-behind. The core is located in DirectXPage.xaml.cpp—the class responsible for XAML content manipulation in FallFury. First and foremost, you need to get the current instance of the DataTransferManager class:

auto dataTransferManager = Windows::ApplicationModel::DataTransfer::DataTransferManager::GetForCurrentView();

Consider this a proxy that allows you to pass content between your app and other Windows Store apps that are executed in the context of the same sandbox. As the instance is obtained, hook it to the DataRequested event handler that will handle the scenario where the user invoked the sharing capability:

dataTransferManager->DataRequested += ref new 
    TypedEventHandler<Windows::ApplicationModel::DataTransfer::DataTransferManager^,
    Windows::ApplicationModel::DataTransfer::DataRequestedEventArgs^>(this, &DirectXPage::OnShareDataRequested);

In the OnShareDataRequested, specify the information that goes into the sharing popup:

void DirectXPage::OnShareDataRequested(Windows::ApplicationModel::DataTransfer::DataTransferManager^ manager,Windows::ApplicationModel::DataTransfer::DataRequestedEventArgs^ params)
{
    auto request = params->Request;
    request->Data->Properties->Title = "Share Score";
    request->Data->Properties->Description = "Tell your friends how much you scored in [DEN'S PROJECT]!";
    request->Data->SetText("I just scored " + StaticDataHelper::Score.ToString() + " in [DEN'S PROJECT]! Beat me! http://dennisdel.com");
}

From that point, the control is in the user’s hand. The application cannot force the share, so unless you implement a direct API hook to a social service, the Share charm will only expose the endpoints available for sharing and will let you set the shareable content. You also don’t have to worry about the way the content will be shared—that will be handled by the target application:

You can show the popup triggered by the Share charm from your application without having the user open the Charms Bar. To do this, call the ShowShareUI method:

void DirectXPage::ShareTopScore_Selected(MenuItem^ sender, Platform::String^ params)
{
    Windows::ApplicationModel::DataTransfer::DataTransferManager::ShowShareUI();
}

This is exactly what the Share button does in the screenshot above. You should make this behavior predictable.

The Settings Charm

As you just saw, integrating basic sharing capabilities in FallFury is not too complicated. Working with settings is also a fairly easy task, though it involves some XAML work. While with sharing capabilities the work focused mostly on OS-based endpoints and application-specific popups, settings allow for full control over how they’re displayed.

For all Windows Store applications, settings should be handled via the Settings charm and not through dedicated application screens. Consider which settings that directly affect the user experience might be changed in FallFury:

• Music and SFX – the user can enable or disable music and sound effects, as well as control their volume.
• Accelerometer – depending on personal preferences, the user might decide to disable the accelerometer (it is enabled by default). The accelerometer can also be inverted—if the device is tilted to the right, the character will move to the left and vice-versa. Last but not least, even with dynamic screen rotation enabled on the device, the user can disable that rotation on the application level and lock the screen to one orientation, such as portrait or landscape.
• Character Movement – the character can be easily controlled via touch (swipe) or mouse. This behavior is enabled by default, but if the user decides to only use the mouse to direct shells, he can easily disable this feature here.

As seen in the image above, the operating system provides the basic shell used to list the possible settings. Once one option is selected, however, further UI displays are delegated to the developer.

As with the share UI, the settings UI can be shown to the user from the application and not from the Charms Bar. Here is how to do this:

void DirectXPage::Settings_Selected(MenuItem^ sender, Platform::String^ params)
{
    SettingsPane::GetForCurrentView()->Show();
}

SettingsPane is the core class that handles the settings display. It does not control how settings are stored or activated. When the main page loads, you need to make sure that you hook the current SettingsPane to a CommandRequested event handler. It will be triggered when the Settings capability is invoked:

SettingsPane::GetForCurrentView()->CommandsRequested += ref new TypedEventHandler<SettingsPane^, SettingsPaneCommandsRequestedEventArgs^>(this, &DirectXPage::OnSettingsRequested);

OnSettingsRequested is the function where the core setting selections are defined and hooked to their own event handlers:

void DirectXPage::OnSettingsRequested(Windows::UI::ApplicationSettings::SettingsPane^ settingsPane, Windows::UI::ApplicationSettings::SettingsPaneCommandsRequestedEventArgs^ eventArgs)
{
    if (m_renderer->CurrentGameState == GameState::GS_PLAYING)
            StaticDataHelper::IsPaused = true;
    
    UICommandInvokedHandler^ handler = ref new UICommandInvokedHandler(this, &DirectXPage::OnSettingsSelected);
    
        SettingsCommand^ generalCommand = ref new SettingsCommand("musicSfx", "Music & SFX", handler);
        eventArgs->Request->ApplicationCommands->Append(generalCommand);
    
    SettingsCommand^ accelerometerCommand = ref new SettingsCommand("accelerometer", "Accelerometer", handler);
    eventArgs->Request->ApplicationCommands->Append(accelerometerCommand);
    
    SettingsCommand^ charMovementCommand = ref new SettingsCommand("charMovement", "Character Movement", handler);
    eventArgs->Request->ApplicationCommands->Append(charMovementCommand);
}

Each SettingsCommand is an item in the list displayed in the settings pane. When one is selected, OnSettingsSelected is called:

void DirectXPage::OnSettingsSelected(Windows::UI::Popups::IUICommand^ command)
{
    if (command->Id->ToString() == "musicSfx")
    {
        stkMusicSfx->Width = 346.0f;
        grdSubMusicSfx->Height = m_renderer->m_renderTargetSize.Height;
        stkMusicSfx->IsOpen = true;
    }
    else if (command->Id->ToString() == "accelerometer")
    {
        stkAccelerometerSettings->Width = 346.0f;
        grdAccelerometerSettings->Height = m_renderer->m_renderTargetSize.Height;
        stkAccelerometerSettings->IsOpen = true;
    }
    else if (command->Id->ToString() == "charMovement")
    {
        stkCharacterMovement->Width = 346.0f;
        grdCharacterMovement->Height = m_renderer->m_renderTargetSize.Height;
        stkCharacterMovement->IsOpen = true;
    }

    WindowActivationToken = Window::Current->Activated += ref new WindowActivatedEventHandler(this, &DirectXPage::OnWindowActivated);
}

Looking back at OnSettingsRequested, each command has a string identifier. When a command is invoked, that string identifier is returned through the IUICommand instance in the Id property. Based on that, I decided which popups to open. Since each has a similar structure, I am going to cover the implementation of just one—Music & SFX.

Here is what the end result looks like:

The panel on the left is a Popup, with two ToggleButton controls used to enable or disable generic music and sound effects. There are also two Slider controls that are used to adjust the volume. The XAML for the above layout looks like this:

<Popup HorizontalAlignment="Right" IsLightDismissEnabled="True" x:Name="stkMusicSfx" >
    <Grid Background="Black" x:Name="grdSubMusicSfx"  Width="346">
        <Grid.Transitions>
            <TransitionCollection>
                <RepositionThemeTransition />
            </TransitionCollection>
        </Grid.Transitions>

        <Grid.RowDefinitions>
            <RowDefinition Height="120"></RowDefinition>
            <RowDefinition Height="*"></RowDefinition>
        </Grid.RowDefinitions>

        <StackPanel Grid.Row="0" Orientation="Horizontal" Margin="24,12,0,0" >
            <Button Margin="0" VerticalAlignment="Center" x:Name="dismissAudioSettings" Click="dismissAudioSettings_Click" Style="{StaticResource BackButtonStyle}"></Button>
            <TextBlock Margin="12,0,0,12" Height="Auto" VerticalAlignment="Center" Text="Music &amp; SFX" Style="{StaticResource SubheaderTextStyle}"></TextBlock>
        </StackPanel>

        <StackPanel Grid.Row="1" Margin="24,24,0,0">
            <StackPanel>
                <TextBlock Text="Music" Style="{StaticResource BodyTextStyle}"></TextBlock>
                <TextBlock  Width="346" Text="This includes the theme track and level background music." Style="{StaticResource CaptionTextStyle}" TextWrapping="Wrap" Margin="0,12,12,12" ></TextBlock>
                <ToggleSwitch x:Name="tglMusic" Toggled="tglMusic_Toggled" IsOn="{Binding ElementName=XAMLPage,Path=MusicEnabled}" Margin="-6,0,0,0"></ToggleSwitch>
            </StackPanel>

            <StackPanel Margin="0,24,0,0">
                <TextBlock Text="Music Volume" Style="{StaticResource BodyTextStyle}"></TextBlock>
                <Slider x:Name="sldMusicVolume" ValueChanged="sldMusicVolume_ValueChanged" Value="{Binding ElementName=XAMLPage,Path=MusicVolume, Mode=TwoWay}" Minimum="0" Maximum="100" Margin="0,0,12,0"></Slider>
            </StackPanel>

            <StackPanel Margin="0,24,0,0">
                <TextBlock Text="Sound Effects" Style="{StaticResource BodyTextStyle}"></TextBlock>
                <TextBlock Width="346" Text="Includes sounds played during the game (e.g. explosions)." Style="{StaticResource CaptionTextStyle}" TextWrapping="Wrap" Margin="0,12,12,12" ></TextBlock>
                <ToggleSwitch x:Name="tglSFX" Toggled="tglSFX_Toggled" IsOn="{Binding ElementName=XAMLPage,Path=SFXEnabled}" Margin="-6,0,0,0"></ToggleSwitch>
            </StackPanel>

            <StackPanel Margin="0,24,0,0">
                <TextBlock Text="SFX Volume" Style="{StaticResource BodyTextStyle}"></TextBlock>
                <Slider x:Name="sldSFXVolume" ValueChanged="sldSFXVolume_ValueChanged" Value="{Binding ElementName=XAMLPage,Path=SFXVolume, Mode=TwoWay}" Minimum="0" Maximum="100" Margin="0,0,12,0"></Slider>
            </StackPanel>

        </StackPanel>

    </Grid>
</Popup>

For every Popup instance used for settings, make sure that IsLightDismissEnabled is set to true. This allows the user to dismiss the panel with a touch outside its boundaries, just like the stock system panels. Other than that, you are working with the standard XAML control set and can include virtually anything in your settings.

Notice, that the switches and sliders are bound to internal properties, such as SFXEnabled and MusicEnabled, that perform the binding via dependency property references:

DependencyProperty^ DirectXPage::_musicEnabled = DependencyProperty::Register("MusicEnabled", 
bool::typeid, DirectXPage::typeid, nullptr);
DependencyProperty^ DirectXPage::_sfxEnabled = DependencyProperty::Register("SFXEnabled", 
bool::typeid, DirectXPage::typeid, nullptr);

The properties themselves are declared in the DirectXPage header file:

static property DependencyProperty^ SFXVolumeProperty
{
    DependencyProperty^ get() { return _sfxVolume; }
}
property int SFXVolume
{
    int get() { return (int)GetValue(SFXVolumeProperty); }
    void set(int value) 
    { 
        SetValue(SFXVolumeProperty, value);
    }
}

static property DependencyProperty^ MusicVolumeProperty
{
    DependencyProperty^ get() { return _musicVolume; }
}
property int MusicVolume
{
    int get() { return (int)GetValue(MusicVolumeProperty); }
    void set(int value) 
    { 
        SetValue(MusicVolumeProperty, value);
    }
}

Let’s take a quick look at how settings are stored. I have a class called SettingsHelper that allows me to save, read, and check if specific settings exist. Here is the implementation:

#include "pch.h"
#include "SettingsHelper.h"

using namespace Windows::Storage;
using namespace Coding4Fun::FallFury::Helpers;

SettingsHelper::SettingsHelper(void)
{
}

void SettingsHelper::Save(Platform::String^ key, Platform::Object^ value)
{
    ApplicationDataContainer^ localSettings = ApplicationData::Current->LocalSettings;
    auto values = localSettings->Values;

    values->Insert(key, value);
}

Platform::Object^ SettingsHelper::Read(Platform::String^ key)
{
    ApplicationDataContainer^ localSettings = ApplicationData::Current->LocalSettings;
    auto values = localSettings->Values;

    return values->Lookup(key);
}

bool SettingsHelper::Exists(Platform::String^ key)
{
    ApplicationDataContainer^ localSettings = ApplicationData::Current->LocalSettings;
    auto values = localSettings->Values;

    return values->HasKey(key);
}

It is clear that storage and retrieval heavily relies on the ApplicationDataContainer class, the container class for local settings that eliminates the need for the developer to create his own setting files, instead delegating this task to the OS and utilizing a centralized storage for all Windows Store applications.

A typical scenario that utilizes the class above is executed when the toggle that manages the sound effects is switched:

void DirectXPage::tglSFX_Toggled(Platform::Object^ sender, Windows::UI::Xaml::RoutedEventArgs^ e)
{
    SettingsHelper::Save("sfxEnabled", tglSFX->IsOn);
    SFXEnabled = tglSFX->IsOn;
    AudioManager::IsSFXStarted = SFXEnabled;

    if (SFXEnabled)
    {
        AudioManager::AudioEngineInstance.StartSFX();
    }
    else
    {
        AudioManager::AudioEngineInstance.SuspendSFX();
    }
}

The Boolean value above will be automatically serialized and stored. The files will be located at C:\Users\YOUR_USER_NAME\AppData\Local\Packages\PACKAGE_ID\Settings\settings.dat:

Conclusion

Implementing sharing through the OS channel in Windows 8 is extremely easy seeing as the developer does not necessarily have to worry about connecting the app to third-party API endpoints. Instead, the user controls the sharing, allowing flexibility of choice without requiring a major addition to the existing code base. It’s hard to predict which services might appear, and modifying the app to support each one of them would be next to impossible otherwise.

You can read more about settings in Windows Store applications here.

During gameplay there are scenarios during which users need to be visually notified that something has happened, such as a collision with an obstacle or an enemy shell. One way to do this is by having explosion or item breaking simulation, which brings us to the next large component in FallFury—the sprite-based particle system. It doesn’t offer as much power as a full-fledged particle system would, but it allows for effects that fit well within the overall theme and layout of the game.

Check out the video for this article at http://channel9.msdn.com/Series/FallFury/Part-9-Particle-System .  For a complete, offline version of this series, you may download a nicely formatted PDF of all the articles.

The Core

ParticleSystem is the dedicated folder in the project that contains everything needed to render multiple textures at once and displace them to create the desired effect:

A single particle carries information regarding its size, position, velocity, color shading, rotation, circular velocity, and scale. As with any other rendered entity, it has a bounding box that can be used to detect its intersection with other elements on the screen. In FallFury, this functionality is not used.

Its structure is as follows:

#pragma once
#include "pch.h"
struct Particle
{
    Particle(float2 size);
    Particle(float2 size, float4 shading);
    float2 Size;
    float2 Position;
    float2 Velocity;
    float4 Shading;
    float Rotation;
    float RotationVelocity;
    float Scale;
    bool IsWithinScreenBoundaries(float x, float y, Windows::Foundation::Rect screenBounds);
    Windows::Foundation::Rect GetBoundingBox();
};

The Particle class also happens to have two constructors—one that sets the particle to have the default shading, effectively removing the effect, and one where shading is dynamic. Note that a particle on its own doesn’t do much—it neither carries the associated texture nor has an internal loop that can be used in any given application part to display it.

The next core class is ParticleSet. It is used as a container for all the particles associated with a specific effect. For example, if I want to create flying stuffing when the bear hits an obstacle, I create a new ParticleSet instance and define the necessary particle properties:

• Lifespan – a particle set does not constantly animate. It displays the particles for a limited amount of time, and displaces them by the given velocity values, and then self-destructs.
• Texture – all particles in a ParticleSet have the same texture. Going back to the stuffing example, there is a single PNG file used to render multiple variable-sized particles on collision.
• IsAlive – this is the flag that shows whether the particle set should be rendered in the first place. If it is set to false then, regardless of the conditions, this ParticleSet instance is ignored.
• ShouldScale – this flag determines whether particles will automatically increase their scale as they are being displaced, creating the effect of a particle approaching the screen. This effect is applied to each particle in the set.

The container class is used to update the particles through the Update function:

void ParticleSet::Update(float timeDelta)
{
    float quat = _lifespan / 0.016f;
    float decrement = 1.0f / quat;
    
    if (_totalTime <= _lifespan && _isAlive)
    {
        _totalTime += timeDelta;
        
        for (auto particle = _particles.begin(); particle != _particles.end(); particle++)
        {
            if (_shouldScale)
                particle->Scale += 0.2f;
            
            particle->Shading.a -= decrement;
            particle->Position = float2(particle->Position.x + particle->Velocity.x,
                            particle->Position.y + particle->Velocity.y);
            
            if (!_shouldScale)
                particle->Rotation += particle->RotationVelocity;
        }
    }
    else
    {
        _totalTime = 0.0f;
        _isAlive = false;
    }
}

As it relies on the _isAlive flag, the Update loop is only used when the particle displacement is activated via the Activate function:

void ParticleSet::Activate(float2 position, float2 velocity, bool randomize, bool scale)
{
    for (auto particle = _particles.begin(); particle != _particles.end(); particle++)
    {
        particle->Position = position;

        if (randomize)
            particle->Velocity = float2(RandFloat(-5.0f,5.0f), RandFloat(-5.0f, 5.0f));
        else
            particle->Velocity = float2(velocity.x + RandFloat(-0.6f, 0.6f), velocity.y + RandFloat(-0.6f, 0.6f));;
    }

    _shouldScale = scale;
    _isAlive = true;
}

When a set is activated, several user-defined parameters come into play. The position is set no matter what and is used to create the source point from which the particles start appearing. The velocity, on the other hand, can be randomized between the values of -5 and 5 pixels per update loop, on both the X-axis and the Y-axis. If randomized, large amount of particles will create an explosion that starts from the center point and expands towards all quadrants. When the velocity is not randomized, it creates a triangular expansion grid on which particles deviate from the center point in one of the given directions:

When it’s time to render the particles, the sprite batch associated with the current game screen is used to pass a texture for each particle registered in the set:

void ParticleSet::Render(SpriteBatch ^spriteBatch)
{
    for (auto particle = _particles.begin(); particle != _particles.end(); particle++)
        {
        if (GamePlayScreen::Manager->IsWithinScreenBoundaries(particle->Position))
                    spriteBatch->Draw(_texture.Get(), particle->Position, PositionUnits::DIPs,
                    particle->Size * particle->Scale, SizeUnits::Pixels, particle->Shading, particle->Rotation);
        }
}

Although there is no flag check inside the Render method that would make sure that the set is alive, this can be done outside of it by calling IsAlive, which will return the flag value:

bool ParticleSet::IsAlive()
{
    return _isAlive;
}

Let’s now take a look at the class that managed the particle flow—ParticleCore.

The Particle Manager

ParticleCore is the class that manages internal particle sets, and is also the proxy for set activation, update, and rendering. Here is its structure:

#pragma once
#include "pch.h"
#include "ParticleSet.h"
#include <list>
#include <map>

class ParticleCore
{
    public:
    ParticleCore();
    ParticleCore(Coding4Fun::FallFury::Screens::GameScreenBase^);
    virtual ~ParticleCore();
    
    void CreatePreCachedParticleSets();
    void ActivateSet(Platform::String^, float2);
    void ActivateSet(Platform::String^, float2, float2);
    void ActivateSet(Platform::String^, float2, bool);
    void ActivateSet(Platform::String^, float2, float2, bool);
    void ActivateSet(Platform::String^, float2, float2, bool, bool scale);
    void Update(float);
    void Render();
    
    private:
        std::list<ParticleSet>                                                    _renderParticleSets;
        std::map<Platform::String^, ParticleSet*>                                _particleSetCache;
        std::map<Platform::String^, Microsoft::WRL::ComPtr<ID3D11Texture2D>>    _textureCache;
        Coding4Fun::FallFury::Screens::GameScreenBase^                            _screenBase;
};

As previously mentioned, set activation can be done with some omitted parameters inferred by the system, such as randomization of velocity or particle scaling, which is the reason why you see multiple overloads for ActivateSet.

ParticleCore is also the container for pre-defined sets that have specific textures and properties that are dumped in the particle set cache (internal _particleSetCache). The cache is reusable and even though sets can be activated and destroyed, the cache remains intact for the duration of the game unless explicitly reset or modified. The texture cache is an addition to the particle set cache and is used as a helper container to temporarily store the textures used for individual particles.

Taking a look under the hood at the CreatePreCachedParticleSets function, you can see multiple sets that can be used in the game, each with different properties. Here is a snippet that shows how the bear stuffing explosion set is created:

auto smallExplosionSet = new ParticleSet(_textureCache["Stuffing"], LIFESPAN);
for (int i = 0; i < 20; i++)
{
    float size = RandFloat(50.0f, 100.0f);
    Particle particle(float2(size, size));
    smallExplosionSet->AddParticle(particle);
}

Once all the particles are in place for that specific set, it is added to the global particle set cache:

_particleSetCache["SmallExplosion"] = smallExplosionSet;

The particle set cache is not explicitly used to render anything on the screen. Rather, that task is delegated to the rendering cache. When a set is activated, the cache is inspected for the given key, its Activate function is called, marking it as alive, and the set itself is pushed on the rendering stack:

void ParticleCore::ActivateSet(Platform::String^ name, float2 position, float2 velocity, bool randomize, bool scale)
{
    ParticleSet set = ParticleSet(*_particleSetCache[name]);
    set.Activate(position, velocity, randomize, scale);
    _renderParticleSets.push_back(set);
}

The Render loop takes care of invoking the proper SpriteBatch drawing functions for each set that is in that stack:

void ParticleCore::Render()
{
    for (auto set = _renderParticleSets.begin(); set != _renderParticleSets.end(); ++set)
    {
        if ((*set).IsAlive())
        {
            (*set).Render(_screenBase->CurrentSpriteBatch);
        }
    }
}

Notice that, as previously mentioned, the set does not perform the life check on itself when rendering. Instead, the manager class performs this action. The same applies to the Update loop:

void ParticleCore::Update(float timeDelta)
{
    for (auto set = _renderParticleSets.begin(); set != _renderParticleSets.end();)
    {
        if ((*set).IsAlive())
        {
            (*set).Update(timeDelta);
            ++set;
        }
        else
        {
            set = _renderParticleSets.erase(set);
        }
    }
}

The textures for each set are individually loaded in the CreatePreCachedParticleSets. Each instance is internally pushed into the cache and also added to the sprite batch associated with the current game screen, where ParticleCore is used:

Loader->LoadTexture("DDS\\stuffing.dds", &_textureCache["Stuffing"], nullptr);
_screenBase->CurrentSpriteBatch->AddTexture(_textureCache["Stuffing"].Get());

Once everything is loaded, the ParticleCore is ready to go and you can use as many particles as necessary in any part of the application. In GamePlayScreen, particle sets are activated in many cases. For example, if the bear dies:

void GamePlayScreen::CheckBearHealth()
{
    if (GameBear->CurrentHealth <= 0)
    {
        m_particleSystem.ActivateSet("Buttons",GameBear->Position, true);
        GameBear->Kill();
        StopBackground();
    }
}

Conclusion

Implementing a sprite-based particle system is not complicated, but it requires depending on a number of assumptions. For example, when a particle set is created, you might consider the fact that some hardware can handle drawing only a given number of sprites at the same time. If a particle set is rendered on a desktop machine, there is no guarantee that the same set will successfully render on an ARM device. Therefore, plan accordingly. For each particle set, create a lifespan that fits the scenario without wasting resources on rendering unnecessary particles. As an additional failsafe, you might want to disable specific particle set types when a Direct3D feature level below 10.0 is detected.

During the gameplay multiple entities interact with each other to make the gaming experience what it is. The bear collides with obstacles and collects buttons, monsters shoot shells that can fly off-screen or hit the bear—all this is possible with the help of the basic collision detection techniques that are implemented in FallFury.

Check out the video for this article at http://channel9.msdn.com/Series/FallFury/Part-8-Element-Interaction . For a complete, offline version of this series, you may download a nicely formatted PDF of all the articles.

Buttons

Buttons are bonus-boosters that can be placed by the level designer anywhere on the screen in game mode. These are relatively small entities, which are displaced vertically with each cycle of the Update loop and move in the opposite direction, but with the same velocity, as the main character.

Looking at the Update function in the GamePlayScreen class, you will notice this call:

UpdateButtons();

UpdateButtons can be considered the button manager function responsible for removing the collected buttons from the rendering stack, counting them, and checking for a button collision when the bear is in close proximity. The implementation looks like this:

void GamePlayScreen::UpdateButtons()
{
    Windows::Foundation::Rect livingEntityBoundingBox = GameBear->GetBoundingBox();
    for (auto button = m_buttons.begin(); button != m_buttons.end();)
    {
        (*button)->Position.x = (*button)->PixelDiff + LoBoundX;
        (*button)->Position.y -= GameBear->Velocity.y;
        if (Geometry::IsInProximity(GameBear->Position,(*button)->Position, 100))
        {
            Windows::Foundation::Rect obstacleRect = (*button)->GetBoundingBox();
            if (livingEntityBoundingBox.IntersectsWith(obstacleRect))
            {
                AudioManager::AudioEngineInstance.StopSoundEffect(Coin);
                AudioManager::AudioEngineInstance.PlaySoundEffect(Coin);
                m_particleSystem.ActivateSet("Sparkle", (*button)->Position,float2(RandFloat(-6.0f,6.0f),RandFloat(-10.0f, -5.0f)));
                StaticDataHelper::ButtonsCollected++;
                button = m_buttons.erase(button);
            }
            else
            ++button;
        }
        else
        {
            ++button;
        }
    }
}

For performance reasons, FallFury supports composite bounding box creation as well as simple box creation. As mentioned earlier in the series, the main character is not composed of a single texture, but rather multiple sprites that are cross-positioned to create a single visual entity. To give you a better idea of what composite vs. simple boxing looks like, take a look at the images below:

The image on the left shows how each part of the bear has its own bounding box, and each will be used for collision checking. In the image on the right, the bear has a single bounding box, creating minor potential gaps, but gaining performance.

Going back to UpdateButtons, once the bounding box is obtained, I iterate through the button collection and make sure that each item is located in the proper space:

(*button)->Position.x = (*button)->PixelDiff + LoBoundX;
(*button)->Position.y -= GameBear->Velocity.y;

The constant position checks are necessary because FallFury supports dynamic orientation changes. When the user switches from portrait to landscape mode and vice-versa, rendered elements on the screen are not automatically repositioned. Setting the X position is easy as long as there is a fixed button margin (from the left side of the screen: LoBoundX) and adding it to the current LoBoundX value results in a proper X location. There is no need to do the same check on the Y-axis because the level length remains the same regardless of the current screen orientation. The adjustment made relative the Y position is bound to the bear velocity. If the bear moves slower, buttons will also scroll slower.

Given that all buttons are properly positioned, a proximity check is performed on each button passed through the loop. If the bear position is at least 100 pixels away from the current button, the corresponding bounding box is obtained and an intersect check is performed. In simple boxing mode, this is done via Windows::Foundation::Rect::IntersectsWith:

If a collision occurs, the appropriate sound effect is played and a particle set is activated to create a visual notification of the action. After the button counter is incremented, the button is removed from the local collection, effectively being removed from the rendering stack.

Power-ups

As the bear flies towards the end of the level, it might encounter bonuses to improve its ability to fight incoming enemies or protect from damage caused by enemy ammo or obstacles. The process behind displaying power-ups on the screen and determining whether there was a collision with the main character is similar to UpdateButtons.

The core function for this task is UpdatePowerups:

void GamePlayScreen::UpdatePowerups(float timeDelta)
{
    if (m_powerups.size() > 0)
    {
        for (auto powerup = m_powerups.begin(); powerup != m_powerups.end(); powerup++)
        {
            (*powerup)->Update(timeDelta);
            (*powerup)->Position.x = (*powerup)->PixelDiff + LoBoundX;
            (*powerup)->Position.y -= GameBear->Velocity.y;
        }
    }
    CheckForCollisionWithPowerups();
}

One difference you probably noticed in the snippet above is the fact that the collision check is now done through a separate function—CheckForCollisionWithPowerups:

void GamePlayScreen::CheckForCollisionWithPowerups()
{
    Powerup^ currentPowerup;
    Windows::Foundation::Rect livingEntityBoundingBox = GameBear->GetBoundingBox();
    for (auto powerup = m_powerups.begin(); powerup != m_powerups.end();)
    {
        currentPowerup = (*powerup);
        if (Geometry::IsInProximity(GameBear->Position,currentPowerup->Position, 100))
        {
            Windows::Foundation::Rect obstacleRect = currentPowerup->GetBoundingBox();
            if (livingEntityBoundingBox.IntersectsWith(obstacleRect))
            {
                AudioManager::AudioEngineInstance.PlaySoundEffect(GenericPowerup);
                GameBear->PickupPowerup(currentPowerup, &m_particleSystem);
                powerup = m_powerups.erase(powerup);
            }
            else
            ++powerup;
        }
        else
        {
            ++powerup;
        }
    }
}

If an intersection is detected between the boxed bear and the power-up texture, the current power-up is passed to the Bear instance and the appropriate type of action is selected:

void Bear::PickupPowerup(Powerup^ powerup, ParticleCore* ParticleSystem)
{
    switch (powerup->Type)
    {
        case PowerupType::PARACHUTE:
        {
            m_previousVelocity = Velocity.y;
            SetParachute(powerup->Lifespan);
            Velocity.y -= powerup->Effect;
            ParticleSystem->ActivateSet("ScalableParachute", Position, 0.0f, false, true);
            break;
        }
        case PowerupType::HEALTH:
        {
            CurrentHealth = MaxHealth;
            ParticleSystem->ActivateSet("ScalableHeart", Position, 0.0f, false, true);
            break;
        }
        case PowerupType::BUBBLE:
        {
            if (IsHelmetEnabled)
            {
                IsHelmetEnabled = false;
                DamageDivider = 1.0f;
            }
            else
            {
                DamageDivider = powerup->Effect;
            }
            IsBubbleEnabled = true;
            m_maxBubbleCounter = powerup->Lifespan;
            ParticleSystem->ActivateSet("ScalableBubble", Position, 0.0f, false, true);
            break;
        }
        // [...]
        case PowerupType::BOOMERANG:
        {
            m_weaponType = powerup->Type;
            m_weaponTexture = m_boomerangTexture;
            CurrentDamage = powerup->Effect;
            m_weaponSize = float2(225.0f, 205.0f) * 0.5f;
            ParticleSystem->ActivateSet("ScalableBoomerang", Position, 0.0f, false, true);
            break;
        }
    }
}

Depending on the power-up, textures are added to the bear model and later passed to the rendering stack (if the power-up type is PARACHUTE), some textures and capabilities are replaced (BOOMERANG), or the bear capabilities are temporarily modified (BUBBLE):

If one of the temporary power-ups is enabled n the Update loop, dedicated timers ensure that ability enhancement does not last longer than necessary. As an example, here is the snippet that controls the bubble:

if (IsBubbleEnabled)
{
    m_currentBubbleCounter += timeDelta;
    if (m_currentBubbleCounter > m_maxBubbleCounter)
    {
        IsBubbleEnabled = false;
        DamageDivider = 1.0f;
        m_currentBubbleCounter = 0.0f;
    }
}

Ammo Collisions

There are also objects that direct ammo at either the enemy or the bear. After release, each shell follows a linear path towards the target, and while the user directs the shells that originate from the bear, those released by enemy entities automatically target the bear. In this case, the ammo needs to collide with an object to either damage or kill it. When a shell is released, it is added to the general ammo collection that is later updated internally:

void GamePlayScreen::UpdateAmmo(float timeDelta)
{
    for (auto shell = m_ammoCollection.begin(); shell != m_ammoCollection.end(); shell++)
    {
        (*shell)->Update(timeDelta, &m_particleSystem);
    }
}

At this point, the rendering system does not differentiate between friendly and enemy ammo—all it knows is that each item in the collection must have a new position when a new frame is rendered. The CheckForCollisionsWithAmmo function checks for ammo collisions:

void GamePlayScreen::CheckForCollisionWithAmmo(LivingEntity^ entity)
{
    if (entity != nullptr)
    {
        Windows::Foundation::Rect livingEntityBoundingBox = entity->GetBoundingBox();
        if (entity->IsFriendly)
        {
            for (auto ammo = m_ammoCollection.begin(); ammo != m_ammoCollection.end();)
            {
                if (!(*ammo)->IsFriendly)
                {
                    Windows::Foundation::Rect ammoBoundingBox = (*ammo)->GetBoundingBox();
                    if (livingEntityBoundingBox.IntersectsWith(ammoBoundingBox))
                    {
                        m_particleSystem.ActivateSet("SmallExplosion",entity->Position, true);
                        entity->InflictDamage((*ammo)->HealthDamage);
                        GameBear->RedShade();
                        AudioManager::AudioEngineInstance.PlaySoundEffect(OuchA);
                        AudioManager::AudioEngineInstance.PlaySoundEffect(HardSoftCollision);
                        CheckBearHealth();
                        ammo = m_ammoCollection.erase(ammo);
                    }
                    else
                    {
                        ++ammo;
                    }
                }
                else
                {
                    ++ammo;
                }
            }
        }
        else
        {
            for (auto ammo = m_ammoCollection.begin(); ammo != m_ammoCollection.end();)
            {
                if ((*ammo)->IsFriendly)
                {
                    Windows::Foundation::Rect ammoBoundingBox = (*ammo)->GetBoundingBox();
                    if (livingEntityBoundingBox.IntersectsWith(ammoBoundingBox))
                    { 
                        Monster^ monster = ((Monster^)entity);
                        if (!monster->IsDead && monster->IsActive)
                        {
                            m_particleSystem.ActivateSet("SmallExplosion", entity->Position, true);
                            entity->InflictDamage((*ammo)->HealthDamage);
                            monster->RedShade();
                            monster->CheckIfAlive();
                            AudioManager::AudioEngineInstance.PlaySoundEffect(SharpSoftCollision);
                        }
                        ammo = m_ammoCollection.erase(ammo);
                    }
                    else
                    {
                        ++ammo;
                    }
                }
                else
                {
                    ++ammo;
                }
            }
        }
    }
}

When the function is called, it is usually run against an entity that is present on the screen, such as the main character. Regardless of whether the enemy or the friendly character fired the shot, the shot cannot inflict damage to its source, and that’s why the function implements the ammo-to-entity crosscheck. If the ammo collides with any shells intersecting the entity bounding box, a collision is counted and health verification is performed to ensure that the character is still alive and that the game should continue. The bear’s health is checked via CheckBarHealth:

void GamePlayScreen::CheckBearHealth()
{
    if (GameBear->CurrentHealth <= 0)
    {
        m_particleSystem.ActivateSet("Buttons",GameBear->Position, true);
        GameBear->Kill();
        StopBackground();
    }
}

That said, not all ammo will collide with entities on the screen. Some of it will go out-of-bounds, and without an explicit cleanup process in place out-of-bounds ammo is constantly re-rendered even though the end user has no way of seeing it. To avoid this, there is a helper function—CheckForOutOfBoundsAmmo:

void GamePlayScreen::CheckForOutOfBoundsAmmo()
{
    for (auto l_Iter = m_ammoCollection.begin(); l_Iter != m_ammoCollection.end(); /* nothing here */ )
    {
        if (!GamePlayScreen::Manager->IsWithinScreenBoundaries((*l_Iter)->Position))
        {
            l_Iter = m_ammoCollection.erase(l_Iter);
        }
        else
        {
            ++l_Iter;
        }
    }
}

If any shell flies outside the screen bounding box, its instance is erased from the collection and the renderer no longer worries about allocating memory for an irrelevant item. To give you an idea of how that happens, here is a snippet that shows how the RenderScreen function handles the current ammo set:

if (!m_ammoCollection.empty())
{
    for (auto shell = m_ammoCollection.begin(); shell != m_ammoCollection.end(); shell++)
    {
        if (!(*shell)->IsFriendly)
        {
            (*shell)->Render();
        }
        else
        {
            GameBear->RenderShell((*shell)->Position, (*shell)->Rotation);
        }
    }
}

Conclusion

Element interaction is a core part of the FallFury experience. Separate handlers are implemented for each of them to ensure maximum flexibility when it comes to adding or removing components without breaking major parts of the code-base. Handling is mainly accomplished in the Update loop by iterating through registered entity sets, such as ammo, and verifying whether an action should be taken. Be cautious when implementing this kind of scenario with large entities and data sets—having multiple loops running simultaneously might tax machine performance, especially on low-power configurations such as ARM.