Lately I’ve noticed a trend in games to allow players to save and play back recordings of their play upon completion of a match.  This allows players to analyze their mistakes, as well as learn new tactics and techniques from their opponents.  This feature is becoming common in all sorts of games.  You can find it in real time strategy games like StarCraft, first person shooters like Halo 3, and fighting games like Super Street Fighter 4.

In many cases, these gameplay recordings are often uploaded to a server on the internet, and are available for download by anyone.  The recordings don’t require buffering or waiting for a big download to finish.  Instead, the playback just starts right up.  How is this possible?  Great looking high definition video files are gigantic.  Also, video compression takes a huge amount of computation, so wouldn’t it slow the gameplay down to record everything?

It turns out that there’s a really simple trick.  We’re not recording video.  Instead, we just store all of the user input, and then later we can use those inputs to exactly recreate the gameplay in our game engine.  So while it looks like we’re watching a stored video, instead we’re just watching the computer playing the game using our stored inputs instead of using the game controller for input.

In this tutorial, I’ll show you a simple method that you can use to achieve gameplay recording and playback, and also list a few other uses for this technique.

What exactly do we need to record?

1.    The most obvious thing to record is the input from the players.  The standard Xbox 360 gamepad has fourteen digital buttons (4 D-Pad directions, A, B, X, Y, LB, RB, Start, Back, and pushing down on either analog stick), and six analog inputs (X and Y for both analog sticks, and left and right triggers.)
2.    If our game runs with a variable time step, we need to record the amount of time that has elapsed since our last recording.  This is simple enough, since the XNA framework provides this in the GameTime class that’s passed in to the default Update method.

Let’s take a look at how we might manage this data in our code.

Once per frame, we need to store a flag to tell us whether each of our digital buttons is held down or not.  We could store a boolean for each of the buttons, but it’s probably better to pack them down a bit more.  We can use an enumeration, declared with the Flags attribute to contain all of our digital button states.

[Flags]
public enum ButtonFlags: short{
        None = 0x0000,

        Up = 0x0001,
        Down = 0x0002,
        Left = 0x0004,
        Right = 0x0008,

        A = 0x0010,
        B = 0x0020,
        // etc.
}

Then it’s a pretty simple matter to set or check a button’s status.

        ButtonFlags buttonFlags;

To set a button pressed:

        buttonFlags |= ButtonFlags.A;

To check for a button press:

if((buttonFlags & ButtonFlags.A) != ButtonFlags.None)
{
         // button A is pressed
}

All of the analog inputs on the Xbox 360 gamepad are reported with a single floating point number.  We can also represent the amount of elapsed time in a float.  If we put all of those together in a structure, we arrive at something that looks like this:

public struct InputState
{
         public float FrameTime;
         public float LeftStickX, LeftStickY;
         public float RightStickX, RightStickY;
         public float LeftTrigger, RightTrigger;
         public ButtonFlags InputFlags;
}

And that structure is all we need to store to represent an entire frame.  That’s a whole heck of a lot smaller than a frame of video, especially in high definition.  And you can make it even smaller if you don’t need all of the inputs for your game, or if you can treat the analog inputs as digital ones.  (If you only care if a trigger is pushed, but not to what degree it’s depressed, you can move it in with the digital buttons.)

Now we need to tie recording in to our gameplay.  At the start of each Update method (once per frame), fill out an InputState, and store it away.  Then update your game normally.  If you can move your update code to a new function that takes an InputState as a parameter, it will simplify things when it comes time to play back the data.

Here’s what our Update method might look like:

protected override void Update(GameTime gameTime)
{
        if (currentState == GameState.Recording)
        {
                InputState inputState;

                SetInputState(out inputState,
                (float)gameTime.ElapsedGameTime.TotalSeconds);
                SaveInput(inputState);
                UpdateGame(inputState);
        }
}

SetInputState just checks each button, and stores whether or not it’s pressed.  SaveInput would store the information to disk, or to a temporary buffer where we could read it later.  And UpdateGame might look like this:

void UpdateGame(InputState inputState)
{
        if ((inputState.InputFlags & ButtonFlags.Left) != ButtonFlags.None)
        {
                // move player left
        }
       else if ((inputState.InputFlags & ButtonFlags.Right) != ButtonFlags.None)
        {
                // move player right
        }
}

And that’s it for recording.  Nice and easy!  Now how about the playback?  Well, that’s pretty easy too.

We’re going to need a couple of variables to keep track of where we are in the play back, and how much time has passed since we started playing.

float recordingTime = 0, playbackTime = 0;
int playbackPosition = 0;
float playbackTimeScale = 1;

The first two (recordingTime and playbackTime) are used to compare how much time has elapsed in playback versus how much time elapsed in the original recording.  We can compare them to determin when we need to move to the next frame.   playbackPosition is the frame index in the recording.  playbackTimeScale determines how fast we play back the recording.  We’ll play around with that in a second.

protected override void Update(GameTime gameTime)
{
        if(currentState == GameState.Recording)
        {
                 // see above
         }
         else if (currentState == GameState.Playback)
         {
                 playbackTime += (float)gameTime.ElapsedGameTime.TotalSeconds * playbackTimeScale;

                 while (playbackTime >= recordingTime)
                 {
                         InputState inputState;
                         ReadInputState(out inputState, playbackPosition)
                         playbackPosition++;
                         recordingTime += inputState.FrameTime;
                         UpdateGame(inputState);
                 }
        }
}

And that’s all it takes to play back our recordings.  It’s truly very simple.  If you play around with the playbackTimeScale variable you get really cool slow motion or fast forward.  (0.5f would move at half speed, where 2.0f would be double speed.)

In the included sample application, you can switch between recording and playback mode using F1 and F2 on the keyboard.  You can use the gamepad D-Pad or the keyboard arrow keys to move around.

But what else can we do with this technique?

1.    You could implement a training mode, and use a recorded playback to show the player how to use a new technique.
2.    You could use a playback in a puzzle game to show the puzzle solution if the player gets stuck and gives up.  (This was used in Professor Fizzwizzle, one of my favorite indie games.)
3.    This could be a big help in debugging.  If you find a way to crash your game, but it’s difficult to repeat, you could record the inputs and get exactly the same inputs every time.  Also, if you have very fast gameplay and you’re having trouble seeing what’s going wrong, you can slow the playback time down and see everything in super slow motion.
4.    If you’re making a gameplay trailer, but don’t have enough horsepower in your PC to capture the video (with an application like Fraps) without slowing down the game too much, you could use a playback to help.  Advance the playback 16.66 milliseconds per frame, and write out a screenshot.  Repeat that until the end of the playback.  Then you can use an external program to stitch all of the screenshots together into a 60 frame per second movie.  (Alec Holowka used a technique like this to make the HD trailer for Aquaria.)

That pretty much covers everything.  Please leave a comment if anything here is unclear or if you see a way this could be improved.  I’d love to hear what interesting uses you come up with for your playbacks.

Download sample code: PlaybackSample.zip (license)

Click Continue reading to see how!

If you look around for information on how to adjust brightness and contrast with blend states, you might find this:

Draw a full screen quad and use these color blend states:

Brightness: source = ONE, dest = ONE
Contrast: source = DESTCOLOR, dest = ZERO

While these would work, they might not be as you expect. Drawing with a 24/32bit per texel texture, the first would only allow you to adjust the brightness up from white, and the latter would only let you reduce contrast. That is probably not what people want. I suggest different settings:

Brightness: source = ZERO, dest = SOURCECOLOR
Contrast: source = DESTCOLOR, dest = SOURCECOLOR

This will allow brightness to be reduced instead of raised, and contrast can be increased as well as reduced.

So how do you actually do this in XNA 4 on Windows Phone 7?

First you will need a 1x1 texel white texture either through the content pipeline, or procedurally.

Add this member to your game class:

Texture2D whiteTexture;

In the LoadContent override method, add this to create the texture procedurally:

whiteTexture = new Texture2D(GraphicsDevice, 1, 1);
whiteTexture.SetData<Color>(new Color[] { Color.White });

You will also need a couple of integer members to hold brightness and contrast state:

int brightness;
int contrast;

Also, two blend states, one for brightness, and one for contrast:

BlendState brightnessBlend;
BlendState contrastBlend;

In the Initialize override method, we can set these other members (note that alpha blend states must match color blend states on WP7/Reach):

brightness = 255;
contrast = 128;

brightnessBlend = new BlendState();
brightnessBlend.ColorSourceBlend = brightnessBlend.AlphaSourceBlend =  Blend.Zero;
brightnessBlend.ColorDestinationBlend = brightnessBlend.AlphaDestinationBlend = Blend.SourceColor;

contrastBlend = new BlendState();
contrastBlend.ColorSourceBlend = contrastBlend.AlphaSourceBlend = Blend.DestinationColor;
contrastBlend.ColorDestinationBlend = contrastBlend.AlphaDestinationBlend = Blend.SourceColor;

Finally, in the Draw override method, after you have drawn to the screen, do the following (this assumes spriteBatch is initialized and that the default blend state is wanted next frame):

spriteBatch.Begin(SpriteSortMode.Immediate, brightnessBlend);
spriteBatch.Draw(whiteTexture, new Rectangle(0, 0, 480, 800), new Color (brightness, brightness, brightness, 255));
spriteBatch.End();

spriteBatch.Begin(SpriteSortMode.Immediate, contrastBlend);
spriteBatch.Draw(whiteTexture, new Rectangle(0, 0, 480, 800), new Color(contrast, contrast, contrast, 255));
spriteBatch.End();

GraphicsDevice.BlendState = BlendState.Opaque;

That's it, but there are a couple more things to mention. First is that the color values (the brightness and contrast integers) should be between 0 and 255, although you could use floats too. To clamp an integer between these values use:

value = Math.Max(Math.Min(value, 255), 0);

To test runtime adjustment of the brightness and contrast, I used input from the 4 quadrants of the screen. The top half adjusts brightness, the bottom contrast. The left side reduces the value and the right side increases it. To do this, add the following code to the Update override method:

foreach (TouchLocation t in TouchPanel.GetState())
{
   if (t.Position.Y <= 400)
      Adjust(t, ref brightness);
   else
      Adjust(t, ref contrast);
}

And the Adjust method (here it adjusts the value by 3 for each touch change at your pleasure, it also includes the clamping mentioned above):

private void Adjust(TouchLocation t, ref int adjustee)
{
   if (t.Position.X < 240)
      adjustee -= 3;
   else
      adjustee += 3;

   adjustee = Math.Max(Math.Min(adjustee, 255), 0);
}

You could expose this via sliders in an options page. The brightness would be particularly useful as you don't want people exiting the game to adjust screen brightness.

Matthew "BRUTAL" Randall has been playing with WP7 & XNA 4.0. He has developed a game/app called Dress Me Up.

Simple premise, yet makes good use of touch.

Check out the video on his site here

Recap

So… last time we made our strings localizable and added-in a new content manager. Today we are going to make all our content localizable, but first we should revisit and refactor “yesterday’s code”.

After publishing part one and having a good week to think about part two, I found that some of my design choices, which seemed nice, where actually at bit cumbersome.
Also the xml parsing (in BABProcessor) wasn’t as robust as I wanted it to be because I forgot about localized formats for dates and numbers.
Fixing our xml loading is easy, so let’s first fix that!

Refactoring BABProcessor

Load up your previous code, or the source code from last week and go to the BABProcessor.cs file. In the switch in our method Process we parse our version number without caring for localized number formats.
Because of this the version number “1.0” might be parsed as 10 instead of 1 on some computers. So change the code in case version to this:

Double.TryParse(node.InnerText, NumberStyles.Any, CultureInfo.InvariantCulture,out output.version);

Here we tell Double.TryParse to parse the number with an InvariantCulture, so 1.0 will always be interpreted as 1.
The next troubling line is where we parse dates. In Europe we usually write dates as 31-01-2010 (dd-mm-yyyy) but in the U.S. 01-31-2010 (mm-dd-yyyy) is more common, and in Japan they use 2010-01-31 (yyyy-mm-dd). Based on the computers local settings dates will be parsed differently,
so let’s drop down to the revision date case and change the code to this:

DateTime.TryParseExact(node.InnerText, "dd-mm-yyyy", CultureInfo.InvariantCulture, DateTimeStyles.None, out output.revision);  

Here we explicitly specify the format used for parsing the revision date in our xml file. (Of course you can change this to something of your liking).
One last thing, I forgot to delete the following line from the package case:

Dictionary<string, string> package = new Dictionary<string, string>();

You can remove this as it’s not used at all, sorry about that, I totally missed that line when doing my final checkup.
Alright so that’s it for cleaing up our BABProcessor.

Refactoring BabylonContent

We’re also going to refactor our new content manager. As I was tinkering with the code for localizing other content/assets I noticed that the code for strings was doing some extra unneeded caching.
I forgot that all content we load using our Content Manager is cached for us, so we don’t need the extra caching. (This is not the first time I forgot this).
But remembering this again allows us to make our content manger much simpler.
Remove the following lines:

private Dictionary<string, Dictionary<string, string>> packages;
language = ProperString(value);

Now replace the entire GetString method with this method:

private string GetString(string path, string package, string key, string packageLanguage)
{
	try
	{
		BABFile localization = base.Load<BABFile>(path + package + "." + packageLanguage);
        if (localization.keys.Keys.Contains(key))
        {
			return localization.keys[key];
        }
    }
	catch (ContentLoadException e){}
	//Now try to load the content using the default language
    //but only if the current language isn't the default language
    //else we would get stuck in ãn infinite loop.
    if (!packageLanguage.Equals(DEFAULTLANGUAGE))
    {
		return GetString(path, package, key, DEFAULTLANGUAGE);
    }
    else
    {
		//The string searched for couldnt be found in the
        //translated file or the default file.
        //Replace this by an exception if you want to test your game better
        return "";
    }
}

As you can see this method is a lot shorter and no longer an exception is thrown if the key doesn’t exist. It also fixes another problem I had with the GetString method, you couldn’t do this:

Content.Load<String>(@”SomePath\Package.key”);

So I fixed that in this version, nothing really new here so I’m moving on to the next subject. Add a new Load method.

public T Load<T>(string assetName, string specificLanguage)
{
	if (typeof(T) == typeof(String))
    {
		string folder = assetName.Substring(0, assetName.LastIndexOf('\\') + 1);
        string file = assetName.Substring(assetName.LastIndexOf('\\') + 1);
        string[] packageKey = file.Split('.');
        if (packageKey.Length > 1)
        {
			//we convert to object and then T because we can't convert a valuetype to a (T) directly
            return (T)(object)GetString(folder, packageKey[0], packageKey[1], specificLanguage);
        }
        else
        {
			return base.Load<T>(assetName);
		}
	}

This parses the path for us so our new GetString method works correct. Now replace the method with the signature Load(string assetName) with this one:

public override T Load<T>(string assetName)
{
	return Load<T>(assetName, language);
}

Well this means we are all done refactoring. These last changes allow us to load strings (and later on other content) in a specific language, other than the language currently set. While still having our old behaviour when someone just calls the normal Load method.

The XML file, BACFile, Importer and Processor

Just as last time we are going to define an xml format, load that xml file and process it into a special class, this time called BACFile (for Babylon Content).
Remember the general idea is that you can add in new languages fairly easy. We are going to do this by adding an xml file in every folder that contains content. We call this xml file “LocalizedContent.Language.bac”. In this xml file we specify what files are localized versions of other files. Now every time our new content manager is asked to load content it first opens the “LocalizedContent.Lanuage.bac” file (where Language is the current language, note that the content manager automatically caches these files for us). If the file can’t be loaded or if there exists no key for the given asset, we just load the asset as normal. If there is a file with a key referencing the file we want to load, we get a new filename from the key, and load that one instead.
Simple huh? Let’s first define a suitable xml-file:

<?xml version="1.0" encoding="utf-8" ?>
<XNABabylonContentFile>
  <version>1.0</version>
  <revisionDate>3-2-2010</revisionDate>
  <author>Roy Triesscheijn</author>
  <language>English</language>
  <!--Files that are already in the correct language can just reference themselves-->
  <!--Or can be left out-->
  <localization>
    <key con="Texture01" loc="Texture01"/>
  </localization>
</XNABabylonContentFile>

As you can see this file defines that for the content (con) “Texture01” the localized english version is “Texture01”.
Now because parsing and processing these .bac files is gonna be almost the same as processing the bab files from part1, I’m just going to put down the code here, with little comments. (You could also just download the sourcecode and copy BACFile.cs, BACImporter.cs and BACProcessor.cs to your project).

BACFile.cs

First we need a container, create a new class, mark it serializable and write code simmilar to this in the class body:

public string language;
public double version;
public string author;
public DateTime revision;
//Other than in the BABFile the BACFile
//doesnt store a direct translation but a string
//naming the translated file.
public Dictionary<string, string> keys;

public BACFile()
{
	keys = new Dictionary<string, string>();
}

BACImporter.cs

Now we need an importer, create a new class called BACImporter, and just copy the contents of BABImporter into the new class file. All you need to change is the class name (obviously to BACImporter). And the ContentImporter directives (register extension “.bac” instead of “.bab”, change the display name, and set defaultprocessor to “BACProcessor”.)
Keep the method Import the same, but change the error message so we know it was a babylon content file, and not a babylon string file, that was invalid.

BACProcessor.cs
Again just copy the content of BABProcessor into a new class called BACProcessor. Now change

using TOutput = XNABabylon.Importers.BABFile;

To

using TOutput = XNABabylon.Importers.BACFile;

Change the display name to “XNA Babylon .bac Processor” . Now in the method Process change the line:

TOutput output = new BABFile();

To:

TOutput output = new BACFile();

And change the lines:

if(input.GetElementsByTagName("XNABabylonStringFile").Count > 0)
{
	foreach (XmlNode node in input.GetElementsByTagName("XNABabylonStringFile")[0].ChildNodes)

To:

if (input.GetElementsByTagName("XNABabylonContentFile").Count > 0)
{
	foreach (XmlNode node in input.GetElementsByTagName("XNABabylonContentFile")[0].ChildNodes)

So almost there. Locate the case package, remove it and add this new case instead

case "localization":
//Loop trough all the keys and store the name of the original content (con)
//and name of the translated file (loc) into a dictionary
foreach (XmlNode key in node.ChildNodes)
{
    output.keys.Add(key.Attributes["con"].InnerText, key.Attributes["loc"].InnerText);
}
break;

Test our new additions to the content pipeline extension by creating the .bac file provided a bit above and adding it to your test project, make sure to set the Build Action to compile and to set the bac importer and processor. If everything is well, you should be able to compile without problems.

Adding new methods to our content manager

With all this new data available, we should update our content manager to use it. Go to BabylonContent.cs and let’s create a new method with the following signature:

private T GetContent<T>(string path, string file, string packageLanguage)

This method will function just like the GetString method. And will be very short tbh. All the code in the method body is this:

try
{
    BACFile localization = base.Load<BACFile>(path + "LocalizedContent." + packageLanguage);
    if (localization.keys.Keys.Contains(file))
    {
        return base.Load<T>(path + localization.keys[file]);
    }
}
catch(ContentLoadException e){}

//If we got to here we couldnt load the localization file or localized content
//So try to load the unlocalized/default content.
return base.Load<T>(path + file);

As you can see we do nothing more than loading the LocalizedContent.Language.bac file in the requested folder, checking if there is a key for the requested asset, if so load that one, else, or on an exception, just load the normal one.
We can use this for all content types, but that means that all content needs to take the extra steps trough localization, which would be silly if we know in advance that some piece of content doesn’t need to be localized.
We can control it ourselves by adding this method (which we do):

public T Load<T>(string assetName, bool skipLocalization)
{
	if (skipLocalization)
    {
		return base.Load<T>(assetName);
    }
    else
    {
		return Load<T>(assetName);
    }
}

But there might be some types of files that we never want to be localized (spritefonts for example). Therefor we are going to make a list of types we do want localized.
Todo this, add the folowing list and helper functions:

//Stores all the types we want our processor to handle
//Types not in this list will just be directly forwarded to the base class
private List<Type> processable;

//'Properties' for the processable list

/// <summary>
/// Add a new type to the processable list.
/// Assets of this type will now be localized
/// when loaded (if possible).
/// </summary>
public void AddProcessableType(Type t)
{
    processable.Add(t);
}

/// <summary>
/// Removes a type from the processable list
/// Assets of thys type will no longer be
/// localized when loaded.
/// </summary>
public void RemoveProcessableType(Type t)
{
    processable.Remove(t);
}

/// <summary>
/// Clears all the types from the processable
/// list. No more content will be localized
/// when loaded from now on. Until new
/// types are added via AddProcessableType(..)
/// </summary>
public void ClearProcessableTypes()
{
    processable.Clear();
}

/// <summary>
/// Returns an array of all types currently
/// in the processable list. Assets of these
/// types will be localized (if possible).
/// </summary>
public Type[] GetProcessableTypes()
{
    return processable.ToArray();
}

This way we can adjust, at runtime, what types of files should not be localized.
In the constructor add the following lines:

processable = new List<Type>();
//Add some default types that we process
processable.Add(typeof(String));
processable.Add(typeof(Texture));
processable.Add(typeof(Texture2D));
processable.Add(typeof(SoundEffect));

This way we have some sensible default types that will be localized (unless they are removed from our processable list).
All we need to do now, is adjust our Load<> function to incorporate these changes, and ofcourse we still need to add a call to our GetContent method!
Add these lines in the method with signature

public T Load<T>(string assetName, string specificLanguage)

In between the if and the else (so we get an if, else if, else).

else if (processable.Contains(typeof(T)))
{
string folder = assetName.Substring(0, assetName.LastIndexOf('\\') + 1);
string file = assetName.Substring(assetName.LastIndexOf('\\') + 1);
return (T)GetContent<T>(folder, file, specificLanguage);
}

Ah now it should all start coming togheter. Still a few checkups though. The normal (overriden) load method should look like this:

public override T Load<T>(string assetName)
{
	return Load<T>(assetName, language);
}

Okay now we have 3 Load methods, let’s recap a bit what they are for.

• 1. Load(string assetName)
• 2. Load(string assetName, bool skipLocalization)
• 3. Load(string assetName, string specificLanguage)

Okay 1 is just the normal load function. This should normally be used.
Now 2 allows us to bypass all the fancy stuff and just load the file we want, without the localization overhead (for example, for stuff that doesn’t have to be localized).
And 3 is the workhorse, it is called by 1, with as specificLanguage argument, the language currently set to the application. We can aslo call it ourselves with a language we want translation to. (For example for the title screen where we want to display instructions in multiple languages).
(note that only 1 is visible if you don’t cast to BabylonContent).

Sample project and conclusions

This time I will not go into more details in how to make a test project. Please download the source code, a test project is acompanied there. It will show you two flags, and based on the flag chosen it will show the rest of the ‘game’ in that language. It will use all 3 different Load methods to demonstrate there uses.

I think it’s fair to conclude that this way of localization is fairly easy, the amount of code we need is pretty slim. And it’s hot pluggable into any existing game. Once you h ave created new localized content it’s easy to update your game to use it. (Just update the xml file). I think this method of localization has never been applied before, but I do think it’s a valid, and efficient way.

Please download the sourcode HERE.

He talks about how to support rotating and resizing of the display on the Zune HD (which supports both landscape and portrait gaming) and then continues with more explanations.

Go read his explanations and download it to see if it could be useful for your own games.

Nick "Don't call me 'I do too much' anymore!" Gravelyn shows how you can do exactly that in his new post called Extending GamePadState.

Pie Menu

For the people who want some UI stuff in XNA, here’s a small sample that contains a Pie Menu Component, attached to a cursor. If you don’t know what a pie menu is, read about it on wikipedia.

Now, about the sample.

My PieMenu supports deep menus. Currently it is just a quick version, made in two days. Because of this, the graphics are not spectacular, and some things may not be extremely flexible right now (the parameters passed to delegates).

But as it is, each menu entry has associated with it an image, a text description, and a delegate, for the action that should be performed. The PieMenu also supports submenus, as seen in this sample.

The cursor can operate in two modes: mouse-friendly and gamepad friendly. In the mouse friendly mode, the menu options are selected with the cursor, while in gamepad friendly mode, they are selected with the left thumbstick.

The current sample contains the following menus:

• Change Gamerpic: allows navigation through a series of submenus, to select a gamerpic that will be displayed in the window
• Change Background Color: randomly chooses a new background color
• Toggle Input Mode: toggles between the mouse and gamepad friendly input modes. Default is mouse, so if you don’t have a gamepad, don’t worry.
• Exit : exits the sample.

This is just as an example. The menu can be easily customized. Also, the Cursor.ShowPieMenu() function has an overload that allows you to specify the menu that will be shown. This allows for different menus, depending on the selected object (this is NOT illustrated in this sample)

Controls:

• Gamepad A or Mouse Click : open menu, or selected submenu
• Gamepad B, or Mouse Click when no submenu selected: return to upper menu / exit menu

You can find the sample here.