XNA Diaries

Game over...

2006-12-02T10:59:00Z

This blog is officially closed and will no longer be updated. New posts will be made to my new blog.

Thank you for playing

Status of XNAExtras

2006-12-02T09:30:00Z

I have been working with the legal in Microsoft to see if it is possible to convert XNAExtras into a Shared Source project (perhaps on Codeplex). There is still a bit of work to do on this, but I'm hopeful that something can be worked out. Opening it up to allow contributions from others would be wonderful since there have been many of you who have offered to help out - offers I was forced to refuse because of intellectual property concerns (sorry 'bout that).

I will not be in a position to make any official announcements here about this, but I will include a link to any official announcements on my new blog.

Leaving Microsoft...

2006-12-01T18:15:00Z

My apologies for the lack of any real content on this site for the past month or so. I've been rather busy doing non-game related activities, many of which center around making preparations to start a new job outside of Microsoft. It's been a lot of fun here the last 12 years (3 years in Outlook + 9 in Research), and I'll miss working with the great people who work here.

After today, I will no longer be able to update this blog - MSDN blogs are (quite reasonably) for use by Microsoft employees only. I've created a new blog at http://garykac.blogspot.com/, but there really isn't anything there at the moment.

I'm turning off anonymous comments (since I won't be able to approve them). I've also updated the blog settings so that emails sent to the blog-owner will be sent to my Gmail account rather than my soon-to-be-disappearing Microsoft account.

So, what's going to happen to XNAExtras? I'll be posting more on that later today...

Publications

2006-12-01T18:07:00Z

Normally, my list of publications lives on http://research.microsoft.com/~garykac, but since that page may be disappearing soon, here is a list (as of 1 December 2006 - with links to papers when available).

Publications

G.Kacmarcik, M.Gamon Obfuscating Document Stylometry to Preserve Author Anonymity, In The Joint Conference of the International Committee on Computational Linguistics and the Association for Computational Linguistics, COLING/ACL 06, Sydney, Australia, 2006. (Poster)

Abstract:

This paper explores techniques for reducing the effectiveness of standard authorship attribution techniques so that an author A can preserve anonymity for a particular document D. We discuss feature selection and adjustment and show how this information can be fed back to the author to create a new document D’ for which the calculated attribution moves away from A. Since it can be labor intensive to adjust the document in this fashion, we attempt to quantify the amount of effort required to produce the anonymized document and introduce two levels of anonymization: shallow and deep. In our test set, we show that shallow anonymization can be achieved by making 14 changes per 1000 words to reduce the likelihood of identifying A as the author by an average of more than 83%. For deep anonymization, we adapt the unmasking work of Koppel and Schler to provide feedback that allows the author to choose the level of anonymization.

G.Kacmarcik Using Natural Language to Manage NPC Dialog, In Artificial Intelligence and Interactive Digital Entertainment, AIIDE 06, Marina del Rey, California, 2006. (Poster)

Abstract:

In this document, we describe our work applying natural language (NL) technologies to improve non-player character (NPC) dialog interactions in games, specifically role-playing games (RPGs). Our approach is to adapt the standard dialog menu interaction so that the menu items are dynamically-generated during game runtime rather than scripted during development time. In our system, menu items are constructed by manipulating abstract semantic representations stored in the NPC knowledgebase, converting them into NL text, and then ranking them so that the most relevant items are placed at the top of the menu. We demonstrate our approach in the context of a small RPG.

H.Suzuki, G.Kacmarcik RefRef: A Tool for Viewing and Exploring Coreference Space, In The 5th International Conference on Language Resources and Evaluation, LREC 06, Genoa, Italy, 2006.

Abstract:

We present RefRef, a tool for viewing and exploring coreference space, which is publicly available for research purposes. Unlike similar tools currently available whose main goal is to assist the annotation process of coreference links, RefRef is dedicated for viewing and exploring coreference-annotated data, whether manually tagged or automatically resolved. RefRef is also highly customizable, as the tool is being made available with the source code. In this paper we describe the main functionalities of RefRef as well as some possibilities for customization to meet the specific needs of the users of such coreference-annotated text.

MSR RefRef (the tool described in this paper) can be downloaded here.

G.Kacmarcik, Multi-Modal Question Answering: Questions without Keyboards, In The 2nd International Joint Conference on Natural Language Processing, IJCNLP 05, Jeju Island, Republic of Korea, 2005. (Poster)

Abstract:

This paper describes our work to allow players in a virtual world to pose questions without relying on textual input. Our approach is to create enhanced virtual photographs by annotating them with semantic information from the 3D environment’s scene graph. The player can then use these annotated photos to interact with inhabitants of the world through automatically generated queries that are guaranteed to be relevant, grammatical and unambiguous. While the range of queries is more limited than a text input system would permit, in the gaming environment that we are exploring these limitations are offset by the practical concerns that make text input inappropriate.

G.Kacmarcik, Question-Answering in Role-Playing Games, In Papers from the AAAI Workshop on Question Answering in Restricted Domains, Technical Report WS-05-10, AAAI Press, Pittsburgh, Pennsylvania, pp.51-55, 2005.

Abstract:

In this paper, we give a general description of the issues associated with performing basic Question-Answering (QA) tasks against non-player characters (NPCs) within a simple role-playing game (RPG) or virtual world environment. We describe the aspects of this kind of QA system and provide an overview of our initial explorations into the implementation and evaluation of a QA system that is appropriate for RPG environments. We also introduce Keystone, a simple RPG environment that provides a small virtual world that allows different NPC controller backends to be plugged in thus allowing these systems to be evaluated in a more realistic game environment.

H.Suzuki, G.Kacmarcik, L.Vanderwende, A.Menezes, Mindnet/mnex:意味関係データベースの自動構築と解析のためのツール (Mindnet and mnex: An Environment for Exploring Semantic Space), In 言語処理学会第11回全国大会論文集 (Proceedings of the 11th Annual Meeting of the Society of Natural Language Processing), Takamatsu, Japan, 2005. (in Japanese)

Abstract:

Mindnet(マインドネット)は通常のテキストデータから、単語間の相互意味関係を直接的・自動的に抽出したデータベースであり、mnex(ネックス)はこれをさまざまな観点から表示・探索するためのウェブ・ツールである。通常のシソーラスの機能に加え、ひとつの単語の意味関係だけでなく、2単語間の意味関係を、その意味関係のタイプを指定して表示することができる。Mindnetの意味関係の抽出は、人手によることなく、構文解析による意味関係の同定と、その重みづけの２段階に分けて行われる。重みづけは、語と語を結びつける意味関係のパスに対して行われ、有用な意味関係のみを抽出することを目的としている。 Mindnetは、辞書と百科事典をソースデータに用いて、まず英語で開発されたが、現在までに日本語でも辞書と百科事典テキストにもとづいたMindnetが構築されている。

G.Kacmarcik, Making Use of Furigana, In The 1st International Joint Conference on Natural Language Processing, IJCNLP 04, Sanya, Hainan Island, China, pp.159-164, 2004.

Abstract:

An interesting aspect of written Japanese that has not been well studied is the use of furigana, or reading cues, to assist linguistic processing of text. Difficulties in processing this material have led to the situation where it is sometimes considered more convenient to simply remove the parenthetical material rather than to process it. This paper describes a system that makes use of the furigana to assist with various tasks, including segmentation, word sense disambiguation and support for OOV items. The system reports an F-measure score of 93.3% on the task of matching the base text with its furigana.

E.Brill, G.Kacmarcik, C.Brockett, Automatically Harvesting Katakana-English Term Pairs from Search Engine Query Logs, In Proceedings of the Sixth Natural Language Processing Pacific Rim Symposium, NLPRS 2001, Tokyo, Japan, pp.393-399, 2001. (Alternate link)

Abstract:

This paper describes a method of extracting katakana words and phrases, along with their English counterparts from non-aligned monolingual web search engine query logs. The method employs a trainable edit distance function to find <katakana, English> pairs that have a high probability of being equivalent. These pairs can then be used to further bootstrap training of the edit distance function, resulting in improved back-transliteration from katakana to English. In addition, this is an effective method for mining large numbers of katakana strings to enhance a bilingual lexicon. The improved edit distance function and enhanced lexicon can be used for more accurate alignment of bitexts, and for application during runtime MT and multilingual IR.

G.Kacmarcik, C.Brockett, H.Suzuki, Robust Segmentation of Japanese Text into a Lattice for Parsing, In Proceedings of the 18th International Conference on Computational Linguistics, COLING 2000, Saarbrüken, Germany, pp.390-396, 2000.

Abstract:

We describe a segmentation component that utilizes minimal syntactic knowledge to produce a lattice of word candidates for a broad coverage Japanese NL parser. The segmenter is a finite state morphological analyzer and text normalizer designed to handle the orthographic variations characteristic of written Japanese, including alternate spellings, script variation, vowel extensions and word-internal parenthetical material. This architecture differs from conventional Japanese wordbreakers in that it does not attempt to simultaneously attack the problems of identifying segmentation candidates and choosing the most probable analysis. To minimize duplication of effort between components and to give the segmenter greater freedom to address orthography issues, the task of choosing the best analysis is handled by the parser, which has access to a much richer set of linguistic information. By maximizing recall in the segmenter and allowing a precision of 34.7%, our parser currently achieves a breaking accuracy of ~97% over a wide variety of corpora.

H.Suzuki, C.Brockett, G.Kacmarcik, Using a Broad-Coverage Parser for Word-Breaking in Japanese, In Proceedings of the 18th International Conference on Computational Linguistics, COLING 2000, Saarbrüken, Germany, pp.822-827, 2000.

Abstract:

We describe a method of word segmentation in Japanese in which a broad-coverage parser selects the best word sequence while producing a syntactic analysis. This technique is substantially different from traditional statistics- or heuristics-based models which attempt to select the best word sequence before handing it to the syntactic component. By breaking up the task of finding the best word sequence into the identification of words (in the word-breaking component) and the selection of the best sequence (a by-product of parsing), we have been able to simplify the task of each component and achieve high accuracy over a wide variety of data. Word-breaking accuracy of our system is currently around 97~98%.

G.Kacmarcik, Optimizing PowerPC Code: Programming the PowerPC Chip in Assembly Language, Addison-Wesley, 1995. (ISBN 0201408392)
G.Kacmarcik, Assembly Language Programming and Optimization Techniques for the POWER Architecture, In The 8th Annual MacHack Conference - The (B)leading Edge, Ann Arbor, Michigan, pp.7-38, June 1993.

G.Kacmarcik, A Neuroethological Model of the Cockroach Escape Response, Master's Thesis, Case Western Reserve University, CAISR Technical Report TR 91-133, June 1991.
R.D.Beer, G.J.Kacmarcik, S.Chai, R.E.Ritzmann, H.J.Chiel, Ventral giant interneuron wind fields in the cockroach modeled with constrained back-propagation, Society for Neuroscience Abstracts, 17:1245, 1991.
R.D.Beer, G.J.Kacmarcik, R.E.Ritzmann, H.J.Chiel, A model of distributed sensorimotor control in the cockroach escape turn, In Advances in Neural Information Processing Systems 3, NIPS 1990, R.P.Lippmann, J.Moody, D.S.Touretzky (eds), Morgan Kaufmann Publishers, 1990.
R.D.Beer, G.J.Kacmarcik, R.E.Ritzmann, H.J.Chiel, A computer model for escape in the cockroach, Society for Neuroscience Abstracts, 16:759, 1990.

XNAExtras update

2006-12-01T18:00:00Z

This is a minor update:

Beta2 update (ContentManager)
Minor bug fix with TextBoxes not deleting their backgrounds.
Initial stab at compiling for the 360 (by #ifdef'ing references to Texture2D.FromFile so that they can be removed easily)
Temporarily remove CollisionDemo since it's acting up under beta2 (there are reports that it was acting up under beta1, but I was unable to repro them...) This demo will come back once these bugs are fixed.

BMFontGen update (1119)

2006-11-19T22:11:00Z

I had a request to add an option to expand each glyph with padding pixels, and I'm finally getting around to doing it.

To add n pixels of padding around each glyph, you can now use the glyph pad option: -gpad n. If you only want padding in the x or y direction, then you can use -gpadx or -gpady. Adding padding will not affect how the font is displayed, except that additional transparent "padding" pixels will be copied.

In general, you don't need to use these options, but they can be useful if you intend to manipulate the font bitmap in such a way that the glyphs expand in size. If you do not intend to edit the font bitmap, then you don't need to use these options.

BitmapFont update for beta2 (Finally!)

2006-11-19T02:33:00Z

As you've probably surmised from the last post, I seem to be somewhat loose in my interpretation of "later this week".

Attached is an updated version (finally!) of the BitmapFont.cs class along with its corresponding demonstration project.

Note that this update only covers the BitmapFont class, not the entire XNA Extras package. I hope to have an updated version of all the XNA Extras classes sometime "later this week"...

XNA Extras and Beta2

2006-11-02T21:11:00Z

This is a heads-up that the current release of XNA Extras requires some changes before it will work with the newly released XNA Game Studio Express Beta 2.

I'm hoping to find some time later this week (yes, I know it's already late in the week) and get an updated version up this weekend. Sorry about the delay!

Colliding sprites in XNAExtras

2006-09-24T18:00:00Z

The latest release of XNAExtras added support for sprite collisions, and allows the collision detection to be either bounding box (bbox) or pixel based. This is settable per sprite - some sprites can use bboxes and others can use pixels. The sprites will collide appropriately with each other even if they can't agree on how to do it.

Here's a simple tutorial for how to use the collision detection built into XNAExtras:

(1) Create an XSpriteManager.

m_mgrSprites = new XSpriteManager();

(2) Create an XSprite.

m_mgrSprites.AddTexture("tex", "texture.png", 64, 64);
XSprite s1 = m_mgrSprites.AddSprite("ball1", "tex");

(3) Create another XSprite so that you have something to collide with.

XSprite s2 = m_mgrSprites.AddSprite("ball2", "tex");

(4) Enable collisions for these two sprites. For bounding box collisions, use:

s1.SetCollideable(true);
s2.SetCollideable(true);

If you want pixel based collisions, use:

s1.SetCollideable(true, XSpriteManager.CollisionFlags.Pixel, 0x40);
s2.SetCollideable(true, XSpriteManager.CollisionFlags.Pixel, 0x40);

where 0x40 is the alpha value of the sprite that defines the collideable part of the sprite - any alpha value >= this value will be added to the sprite's collision mask.

(5) In your Update method, after you've moved your sprites around a bit, you can check for collisions using CheckSpriteCollisions:

List<XSpriteManager.SpriteCollision> aColl = m_mgrSprites.CheckSpriteCollisions();

This method returns a list of collisions that were detected. It returns null if there are no collisions.

(6) To handle collisions, simply walk the list of collisions and do whatever you feel is appropriate.

  if (aColl != null)
  {
    // handle the collisions
    foreach (XSpriteManager.SpriteCollision c in aColl)
    {
     // if colliding with another sprite...
     if (c.Type == XSpriteManager.CollisionType.Sprite)
     {
        // handle collision between c.Sprite and c.Sprite2
      }
    }
}

A working demo of collision detection is given in the CollisionDemo project included with the XNAExtras download.

XNAExtras build 0923 release

2006-09-24T09:50:00Z

Major addition for this version: collision detection has been added to XSpriteManager. Both bounding box and pixel based (mix-n-match sprites of different types). Also boundary collisions. These are demoed in the bouncy CollisionDemo example:

From the release notes:

(BMFontGen) Fixed bug where including undefined chars in your font -range would cause a crash
(BitmapFont) Changed loading embedded resources - now the resource name is specified in the same format as file-based resources
(BitmapFont) Fixed bug where font files wouldn't be found unless they were in a subdirectory
(TextBox) Added accessors for the text string
(XSpriteManager) Changed default FPS to 60
(XSpriteManager) Added support for collisions
(TexturePool) *Really* fixed bug in AddTexture(string,Color) where the texture wasn't being created if the GraphicsDevice already existed - the fix got lost for the last release

Thanks to redwyre, David Zakar (DMZ), Martin Szinger and Matt Moore for comments/suggestions.

You can download the 0923 build of XNAExtras here.

Mixing Natural Language into Games

2006-09-23T08:01:00Z

[I had intended to write up a small post about my project earlier, but didn't get the chance until now. Hopefully, you'll find it at least part of it interesting. -Gary]

Being in the Natural Language Processing group here in Microsoft Research, and being someone who enjoys creating and playing games, one of my interests is to explore the intersection between these two areas.

I started by experimenting with attaching semantic annotations to virtual photographs - photos taken by the player within the virtual world. The player could take a photograph and then bring the photo to an NPC in the world and have a (somewhat stunted) "conversation" about the contents of the photo. A key aspect of this work is that all of the interactions are dynamically generated during runtime - there is no scripted dialog. A basic description and overview of this work is given in "Multi-Modal Question-Answering: Questions without Keyboards" [IJCNLP 2005].

One of the problems that I encountered with this project was the high cost of creating 3D assets (where's the Content Pipeline when you need it?), so I converted to a more conventional tile-based isometric role-playing game. I still needed to create art assets, but found that it was much easier to create 2D sprites than to create models, textures and the other bits required for a decent-looking 3D world. This allowed me to focus less time on the art (which is fun, but not the key point of the game) and more on the dialog and NPC-interaction aspects of the game.

Here is a screenshot from a game demo (called "PotionMaster") showing some of the dynamically generated dialog elements (apologies for the "programmer art" ^_^):

More details about this game are given in "Using Natural Language to Manage NPC Dialog" [AIIDE 2006] and (in an earlier form) in "Question-Answering in Role-Playing Games" [AAAI 2005].

Unfortunately, I cannot release this game in its complete form. It relies on some internal-only NLP tools during runtime (to dynamically generate the NPC responses from the abstract semantic representations), and those components cannot be released (not even in binary form).

To work around this limitation, I've defined an interface between the core game engine and our dialog engine. This way I can release the game engine and keep our proprietary dialog system in-house. There may seem like no point in releasing only half of a game, but the purpose is so that other NL researchers can plug-in their own dialog systems and run situated evaluations without having to create an entire game from scratch. I've also created a very simple scripted dialog plug-in that takes the place of our internal backend (so the game will be playable).

So, that's the project in a nutshell. When XNA was released, I expanded the scope slightly so that the game code could be used as a tutorial for creating isometric games. The XNAExtras that you've seen so far are the first of these releases.

[Update: All of my papers (including those mentioned above) are listed on my research homepage.]

Separating your code and data

2006-09-17T20:15:00Z

In the previous post, I talked about creating border art and using it in your game. One problem with the approach shown is that the description of the texture contents - the sprite locations and boundaries - is stored in the game code. This means that if you want to update the border artwork for a future version of your game, you need to make parallel code modifications and then recompile.

A nicer way of doing this is to keep the description of the texture contents in a file alongside the texture. This would allow you to change the appearance of your game without needing to recompile - useful if you're programming by yourself, and crucial if you're developing the game where someone else is helping out with the artwork.

This approach is supported in the XNAExtras class library by allowing texture and sprite information to be loaded from an XML file. A simple descriptor file is:

<?xml version="1.0" encoding="UTF-8" ?>
<texinfo>
  <textures>
   <texture name="whiteball" src="white ball.png" size="64x64" />
  </textures>
  <sprites>
   <sprite name="red" tex="whiteball" pos="50,50" tint="#ff0000" />
  </sprites>
</texinfo>

This XML file creates a single sprite based on the "white ball.png" texture, adds a red tint and positions the sprite at (50,50). While perhaps a bit of overkill for this simple texture, once you start having multiple sprites in the same texture (as you should), these descriptor files can be quite useful.

To load a texture definition file into your game, simply use:

sprites.LoadSprites("spriteinfo.xml");

Where sprites is your game's XSpriteManager. If you want to interact with this sprite in your code (for example, to move it around the screen), you can ask the XSpriteManager to return a reference to it using:

XSprite s = sprites.GetSprite("red") as XSprite;

You can find working examples of LoadSprites in the TextBoxDemo and XSpritesDemo projects (included with the XNAExtras download).

To assist with creating these "texture information" files, I've created an XML Schema Definition (XSD) file that you can use to perform basic validation. This XSD file (TextureInfo.xsd) is included as part of XNAExtras and is located in the "XML Schema" directory. To use it, copy the XSD file into the same directory as your XML file and replace your

tag at the beginning of the file with the following mess:

Now if you open your XML file in a application that supports XSD (like Visual C# Express), you'll get validation squiggles. It doesn't perform a complete validation of the file, but it will catch most basic errors/typos. If you want to keep the XSD files in a separate directory, replace "textureinfo.xsd" in the "xsi:schemaLocation" attribute with a path+filename.

Beyond making your code more manageable, there's another aspect to this code/data separation that can benefit your work: Your art assets become more shareable with others. If you're thinking "Why would I want to make it easier for people to steal my art?", try to step back and think about the XNA gaming community as a whole.

While it means that others can more easily make use of your assets, it also means that you can more easily make use of the assets that others create. This sharing is crucial to developing and maintaining a thriving game development community. Yes, some people will "steal" and not give credit, but that sort of thing will happen no matter what you do (unless you don't release your game at all).

As mentioned earlier, exposing your art like this makes it much easier to be replaced/updated. While this is obviously good for you, it can also enable a modding community to build up around your game - people (even those with no programminng experience) can now take your game and make new skins without messing with the code. How cool would that be?

Creating UI border elements in XNA

2006-09-17T08:30:00Z

The XNAExtras.Border class provides a general border mechanism for UI elements. While currently only the XNAExtras.TextBox class makes use of it, future releases of XNAExtras will include Menus and perhaps some other elements that will be built on top of Borders.

When creating borders, you can use the default border graphics (e.g., those that come with the TextBox demo) or you can create your own custom graphics. This post describes what you need to do to create and use your own custom borders.

As an example, we'll make use of one of the borders included in the TextBoxDemo sample project. This project is part of the XNAExtras package, which you can download from here if you don't already have it.

The border image that we'll be examining is "border.png" - a simple 25x33 image that contains a single border. It's located in the "XNA Samples\TextBoxDemo\Content" folder and is shown in the following figure (with some markup denoting the different regions of the border image):

When designing a border image, you should think of it as 9 separate regions that need to blend together smoothly: the four corners, four edges and the center.

The four corners are typically the largest and most distinctive part of any border. The corners are never stretched or scaled when they are drawn.
The edges are drawn between two neighboring corners and stretch vertically or horizontally to make the border the correct size. As can be seen in "border.png", the edges do not need to be more than a single pixel wide or high.
The center is typically a single pixel that defines the background color for the border. The center is stretched both horizontally and vertically to match the border size.

So, now that you have a border image, what do you do with it? You can use the following code to create and display your border.

First, set up your project. This process is the same for all XNA projects that use XNAExtras.

Create a new "Windows Game (XNA)" project and add all of the XNAExtras source files to it.
Add a reference to System.Xml. To do this, right-click on the References folder in the Solution Explorer for your project. Select "Add Reference...". From the ".NET" tab, select "System.Xml" and then click the "Add" button.
Add "using XNAExtras;" to the top of your source files with the other using statements.

Now you can start adding code to the main game class. Add the following member variable to your game class:

private XSpriteManager m_sprites;

Add the following initialization code:

// create a sprite manager to manage the drawing
m_sprites = new XSpriteManager();

// load the texture that contains the border
m_sprites.AddTexture("tx_border", "border.png", 25, 33);

   // define a border type from the texture
   // (use the default settings to init the border)
   m_sprites.DefineBorder("border_def", "tx_border");

   // instantiate the border and set its size
   Border b = m_sprites.AddBorder("border test", "border_def");
   b.SetDestRect(50,50,100,100);

Add the following initialization code after the call to InitializeComponent (or place it wherever you handle device resets):

m_sprites.Reset(graphics.GraphicsDevice);

And finally, add the following to your Draw routine (between your BeginScene and your EndScene):

m_sprites.Draw();

Compile and run and you'll see a empty border on your screen. You'll need to have copied the "border.png" file into the same directory as the EXE or else the texture won't be found.

Note that the code given above uses the default parameters to define the border, which works in this example because the texture contained only this one border sprite. The left, top, right and bottom values for the border were also automatically determined by taking the image size and dividing it in half and assuming that the center was 1x1 pixels in size.

To have more control over the border creation parameters, you need to define the border using a Border.CreationParameters struct:

   Border.CreationParameters bcp = new Border.CreationParameters();
   bcp.strTexName = "tx_border";// name of texture with border
   bcp.SetLocation(0, 0);       // location of border image in texture
   bcp.SetSize(25, 33);         // size of border image
   bcp.SetEdges(12, 16, 12, 16);// size of LTRB edges in texture
   bcp.SetOrigin(4, 8);         // border position adjustment
   m_sprites.DefineBorder("border_def", bcp);

As a final comment about borders, note the SetOrigin line in the above example. This parameter is used to adjust the position of the border around the rectangle. Compare the borders in the next image:

The left column shows the border and the right column shows the same border with the content rectangle blanked out to make it easier to see. All of the rectangles are 100x100, but the bottom row used the SetOrigin method shown above to pull the border closer to the rectangle.

XNAExtras build 0916 release

2006-09-16T20:01:00Z

This release includes a bunch of small enhancements and bug fixes. The only major class addition is XSpriteGroup, which allows you to manipulate a group of sprites as a single unit.

From the release notes:

   (XML Schema) Added XML schema definition (XSD) files for bitmap and texture files
   (BMFontGen) Fixed bug where custom glyphs couldn't replace chars that didn't exist in font
   (BitmapFont) Added Dispose method
   (BitmapFont) Fixed TextBox to format the string only once
   (BitmapFont) Allow fonts to be loaded from embedded resources
   (BitmapFont/XSpriteManager) Changed GetXMLAttribute to not throw exceptions
   (XSpriteManager) Changed sprites to sort by order of creation when at the same depth
   (XSpriteBase) Added Visible property
   (XSprite) Added SetTexture method
   (XSprite) Expose sprite alpha value directly
   (TexturePool) Fixed bug in AddTexture(string,Color) where the texture wasn't being created if the GraphicsDevice already existed

Thanks to everyone (and especially to David Zakar (DMZ), redwyre and Martin Szinger) who took the time to send comments, bug reports and feature requests.

[Update: Oops! Björn points out that I forgot the link to the updated version. The link to the latest version is here.]

"But I don't want to have to worry about sprite depths..."

2006-09-15T02:34:00Z

Well, you don't have to really. Or maybe you're already dealing with depth and you don't realize it.

To recap: There are two ways of controlling sprite "depth". The first is to use the SpriteBatch.Draw methods that allow a layerDepth parameter. The second is just to draw your sprites at the same depth, but from back to front.

The layerDepth approach is nice when you have lots of sprites at different depths, or when they're changing depths regularly. You give each sprite a depth and then forget about it. This allows you to draw your objects ordered by type (first the map, then the player, then the objects, ...) as opposed to by how far they are into the screen.

The simpler approach of drawing from back to front is seen when you draw your background first, then your objects and then finish up with your overlay and UI elements. Basically, you've hardcoded your back-to-front sort order in your code. Not very flexible perhaps, but perfectly appropriate for a large number of games. And you don't have to worry about depth at all - beyond the coarse background/objects/overlay distinction.

XSpriteManager supports both approaches. If you give it a depth, the right thing will happen - and the sprites will be kept in sorted order so that they render quickly. But if you don't want to set the depth, you can just add sprites and they will be rendered in the order that they were created. By default, XSprites are drawn at depth=0.0 (which is closest to the screen).

The motivation for all this is the game that I'm working on (big surprise there, eh?). It's a basic tile-based isometric RPG which had a definite need for a class to manage all the sprites. To handle the map tiles, I wanted to put each row at a different depth and then place the player (and NPCs) at depths between the rows.

I'll try to talk more about this game once I get a few more basic classes finished up.