Check out the announcement of the new XNA Creators Club Web Site on the XNA team blog.
The creators club web site has a new look and feel with several improvements. One of the coolest new features for premium members is the enabling of Community Game Publishing to Xbox Live. Sweet! Games can be submitted for peer review and, upon approval, be published to Xbox Live. You can also check out Dax Hawkin's post on Gamasutra for more details on the process.
Funny story that I really wanted to share with you all.
Moving to the XNA team has meant several changes for me. As I mentioned in my previous post, I've stepped into a Development Manager role. The Dev team has been simply awesome in making me feel welcome and helping me to get onboard.
Another change is moving to the Xbox team in the Entertainment and Devices Division. While I loved the developer division, the gamer in me is in hog heaven on the Xbox team.
Changing teams has also meant a change in work location. My new office is now located in the "Millennium" buildings down in Redmond. The new location is a little bit further away from home, and this is the farthest I've worked from "main campus". The nicest thing about my new location is that it is very close to the school that my two older daughters (Taylor 8 and Elisa 6) attend. That means I can take them to school and then head to work literally minutes away.
So that begets the funny story. Here's a conversation I had with my daughter, Taylor, on the way to school.
Taylor: Dad, why did you have to change jobs?
Me (thinking): Oh boy. How do I explain a "Re-Org", global workforce, staffing and opportunity cost?
Me: Well, if work is a "project" the project I'm working on got assigned to a different team. It was a great chance for me to find something new to work on.
Taylor: Are you a "manager" now?
Me: Yep.
Taylor: What does a manager do?
Me: LOL. Ummmm. I'm trying to figure that out. I guess I'm responsible for my new "project" and making sure that the team is running well.
Taylor: Does that mean you're "the boss" ?
Me: LOL. LOL. No. Well... technically yes. But not really. I don't "boss people around." I help provide guidance, but most of the time I just try to stay out of the way.
Taylor: So, are you like a manager at the store? Do you wear a red vest?
Me: LOL. LOL. LOL. <trying not to drive in the ditch> No no no. No red vests at Microsoft sweetheart.
Leave it to my 2nd grade daughter to totally make my day. I still laugh every time I think about it.
I guess that's worlds better than my Kindergartner Elisa's comment in regards to my expanding waist line.
Me: Do you think I'm fat honey?
Elisa: Oh no. You not fat. Well... but you do look just like Mr. Incredible. And I love you.
Mr. Incredible is cool, after all. Maybe I'll be cooler in my red vest. Sigh...
One of the most satisfying times I experience at Microsoft are immediately after a product release. And that day is today - the XNA team is proud to announce the availability of the Game Studio 3.0 CTP (Community Tech Preview) that supports both Windows and Zune. Being new to the XNA team, I obviously haven't contributed that much from this side of the fence, but it's great to see the NETCF work we did to support Zune finally make it out the door and into the hands of the game development community. I also find it totally satisfying to see the proud smiles of team members in the halls in spite of the hard work and effort that went into the release.
Check out the announcement on the XNA Team Blog for more details of the launch. I'm looking forward to seeing all of the cool, creative and quirky things that the community will produce.
Well, guess it's about time for me to post again. I was hoping to be able to post some more about Silverlight for Mobile, but those responsibilities have transferred over to some very capable new team members on the .NET Compact Framework team.
As for me, I'm currently packing up my office and heading out to my next Microsoft adventure. I'll be taking a Development Manager spot on the XNA team working on delivering the best game development experience and platform on the Xbox 360, Windows, Zune and other future platforms. I'm totally excited to get started with the stellar team over there, many that I've worked with while on the .NET Compact Framework team.
So while I'll always be a NETCF'er at heart, you can ask most of them what my main passion and interests are in computing, and they will undoubtedly point to gaming and game development.
Will be posting soon on the cool new Game Studio 3.0 stuff on the horizon.
I was really bummed knowing that I would not make it back to the Game Developer Conference (GDC) this year. I was especially disappointed knowing all of the cool announcements that we would be making around the XNA Community offerings and XNA coming to Zune.
I actually had the opportunity to see several of the games running on Zunes last week. I was pleased to how well they ran and how nice they looked! Being a Galaga fan, "Zauri" was my favorite one. There are a few screen shots here but they aren't very clear. I'll post a link when there are nicer ones.
Kudos to all my buddies on the XNA team. You guys rock!
I've always enjoyed the Christmas holiday -but as a gamer, it seems that Christmas is coming a bit early this year.
The console gamer side of me is eagerly awaiting the release of Halo 3 on the 25th. As part of the lead-up to the release, the Halo 3 Online Manual went online - and yep - it's powered by Silverlight. The Halo 3 Video Site has been up for a few weeks now, and it really shows off the hi-fidelity video capabilities of Silverlight on Windows or your Mac. I would imagine that there will be more videos posted there as the countdown to the release progresses.
The PC gamer side of me has already been treated to World in Conflict and is waiting for the release of The Orange Box. I pre-ordered the Orange Box online and have been playing the Team Fortress 2 beta for a few rounds. It's quite fun, but I'm still slower than all of you twitchers out there and still coming up to speed on all the tactics. So if you see "OysterChicken" running around, be kind to the n00b. Now, if you see OysterChicken running around on Battlefield 2... will let's just say I'm not such a n00b in that realm. :)
I can also say that our Silverlight for Mobile planning and early dev work is progressing. More on that... after I spend some time with my early presents :)
Our Product Unit Manager, Scott Holden, did a podcast at MEDC that shows the Silverlight for Mobile demo. I thought some of you will probably find it interesting.
For my small blog audience out there, I apologize that my blog has been lacking in activity over the last several months. In spite of the communication black hole, I’ve actually been quite occupied and there’s been quite a bit going on in the last several of months since XNA v1 shipped in November of 2006.
The .NET Compact Framework team has been busy. In the early quarter of 2007, we shipped Service Pack 2 for .NET Compact Framework v2.0. My favorite feature is the new version of RPM that contains the ability to snapshot and analyze objects in the managed heap; a great boon for detecting and squashing memory leaks or poorly engineered sections of code. Service Pack 2 was quite a big accomplishment considering we’re also headlong into our product development milestones for the next version of Visual Studio 2005, code named Orcas. Beat 1 shipped shortly after the service pack and our next beta is coming soon.
Fortunately, being on a great team has given me the opportunity to work on some pretty cool projects. In previous years, getting the .NET Compact Framework up and running on the Xbox 360 for the XNA v1.0 and v1.0 Refresh releases was a remarkable and rewarding experience that fell into this genre. But one of my current projects has me just as excited – very reminiscent of the early XNA work. Over the last month+, I have spent countless hours toiling over this cool new thing – Silverlight.
“Silverlight is a cross-browser, cross-platform plug-in for delivering next generation of .NET based media experiences and rich interactive applications for the Web.” Check out this cool demo…
Fox Movies
So what does this web experience have to do with the Compact Framework team? For me, it meant a countless number of long work days and longer evenings that resulted in this “labor of love.” A picture says a thousand words, so go ahead and check out the MLB demo done by Justin from MLB and Michael from Microsoft. Justin does a great job going over the Silverlight based Major League Baseball game viewer and player tracker. It looks really slick with great video, alpha blending, and nicely done graphics. At the very end he’ll whip out his fancy new Windows Mobiles 6 device and show Silverlight running a forward looking prototype of a MLB Mobile application.
MLB Mix 07 Demo
I’ve been itching to blog about this undertaking, but since this just debuted yesterday, I was not able to. Now that the cat’s out of the bag…
The demo shows a very early port of pretty much the entire Silverlight rendering engine running on Windows Mobile 6 integrated with the .NET Compact Framework. The entire application is written in C#. All of the visual elements, with the exception of the small blue hatched portion of the banner and the video thumbnails, are entirely 2D vector elements rendered from XAML. Even the MLB logo is in XAML. This allows the elements to scale nicely between the QVGA display shown in the demo and a VGA display on larger form factor Pocket PCs. The content actually works just fine in your web browser on a Mac or Windows machine running the full Silverlight framework. Kudos to the Forg Design team that put together great looking content for me to work with.
The demo video really doesn't do the content justice, so here are some screen shots..
(edited 5/7/2008 - removed pictures as links are now stale. Sorry.)
For any of you code jockeys out there who have ever been tasked with assimilating and componentizing design assets into a functioning interactive application, I now have a much better understanding of the process and challenges you face. While it was a bit of work and learning for me, I actually I actually used Microsoft Expression Design to process and create all of the XAML assets I obtained from the Frog Design team. Working on the Release Candidate of Design, it was definitely a lifesaver.
In retrospect, it seems crazy that I’ve focused an entire month of my life for a demo that appears on stage for less than a minute. It was a hard, grueling work. I am oh so thankful for a supportive team and for an even more supportive family.
Crazy – yes I would qualify it as borderline crazy. Foolish? Absolutely not. My guess is that all of my developer brethren out there who have fought with integrating a rich set of design assets into an application will immediately grasp the significance of our accomplishment.
So let’s get on with it and officially recognize the elephant in the room. When are we shipping? On what platforms will this be available? Xbox 360? Windows Mobile?
Well… as you probably guessed I can’t quite blog on that yet J It’s killing me, but when the time is right, we will make the appropriate announcements and I’ll be sure to whip up another blog entry.
Stay tuned…
It's been a long 18 months for me. A lot has happened.
19 months ago, I was approached by Mike Zintel and Scott Holden to "come back home" to the .NET Compact Framework team. I was a little hesitant at first since I was thoroughly enjoying the incubation project I was involved in at that time, but the cookie they dangled in front of me was just to scrumptious to pass up.
.NET + Xbox 360
Yeah Baby. I'm there.
And besides, it really was like coming home. I have several very good personal friends on the team. This is the first product I worked on from day zero - I was actually on the team before Mr. Zintel and Mr. Holden way back in 1999.
There have been many special days over the last 18 months...
- My oldest daughter had her 6th birthday
- My middle daugher had her 4th birthday
- My son had his 1st birthday
- And I had my... well.. let's just say I'm older now.
- Fun and exciting days at Gamefest and GDC
- There was the day I lugged a Xbox 360 Alpha Kit into DavidWr's office and said - let's make this work
- There was the day where I watched Hello World run in DavidWr's office
- There was the day when we rendered our first 3D scene on the Alpha Kit
- There was the day where I showed J our work.
- There was the day that I became the proud launch day owner of a Xbox 360 (which is still running great today) via charity auction
- I recall the days when we got up and running on Beta and Final hardware development kits
- There were days when I churned out new code
- There were bug fixing days
- The day of our "Final" build
- One more bug fixing day
- The day of our "Final" build redux
- Vacation days in Hawaii where I, along with my very best college friends, witnessed our Purdue Boilermakers Football team fall short in a wild game against the University Hawaii Warriors (I'm still hoarse from the "cheering" in that game)
- Then there was the day our product got submitted to the Xbox Certification process
- And, most relevant to this blog... Today. The day I received the email that we passed certification and are signed off on the product.
I've now worked on a second product from day zero through ship of v1. Actually, now that I consider the timeline of things, we'd have to call it day < 0.
On Monday, December 11, XNA Game Studio Express will be made available. At around the same time, you will be able to browse Xbox Live, purchase a subscription to the XNA Creator's Club and download "my baby" along with the XNA Framework right to your very own 360. I'm totally exicted to hear about and see all of your creative efforts and home brew projects.
To quote a friend, this last year has been like "trying to drink from a fire hose". I've learned a ton about game developers, game development and the game industry. I've been very fortunate to be a part of this ride we now call XNA v1.
Rest assured we are only at the start of the road - there is no shortage of things to do. After a little bit of breather, we're already planning future releases and improvements.
In closing, here's a geek high-five shout out to all my colleagues on the NETCF and XNA teams.
101
Way to go - It's been a blast!
Enough of this endless Endian junk.
On to more exciting announcments! I told you all that more details in regards to the XNA Framework would be released at GameFest over the summer. WE'RE ALMOST THERE!
GameFest starts tomorrow morning and big announcements are indeed coming over the next several hours. Here are some previews to whet your appetite...
http://blogs.msdn.com/xna/ (I mentioned at the end :)
http://letskilldave.com/archive/2006/06/29/XNA-Framework-tidbits_2E002E002E00_.aspx
http://www.gamespot.com/news/6155590.html?tag=latestnews;title;1
http://blogs.msdn.com/al_msft/archive/2006/08/13/699149.aspx
Folks - the drums are beating - the troops are forming and we're ready for battle!
More to come after the anouncements later today!
For the reader below who asked for an ASCII diagram here you go.
Let's say we have the following...
typedef struct
{
SHORT x;
SHORT y;
} FOO;
void BadCode( FOO foo)
{
foo.x = 0x0102;
foo.y = 0x0304;
InterlockedIncrement( (PLONG)&foo.x );
}
The foo struct consumes 4 bytes since each SHORT is a signed 16 bit value. On a little endian system, the byte values are laid out in memory as follows. (Remember - Least (little) signficant byte first)
0x02 (LSB of FOO.x)
0x01 (MSB of FOO.x)
0x04 (LSB of FOO.y)
0x03 (MSB of FOO.y)
InterlockedIncrement actually works on 32bit values. On little endian systems, the interlocked increment function expects the least significant byte of the 32 bit value to be at the address supplied to the interlocked function. So, in this case, the increment actually works as expected, and the result would be:
0x03 (LSB of FOO.x)
0x01 (MSB of FOO.x)
0x04 (LSB of FOO.y)
0x03 (MSB of FOO.y)
where foo.x == 0x0103 and foo.y == 0x0304.
(Also note that if we were to increment foo.x greater than 0xFFFF we would actually overflow the 2 byte SHORT and start incrementing the foo.y value. Since it is signed, similar madness would occur if we decrement the value below 0.)
Now, on a big endian system, memory is laid out as follows.
0x01 (MSB of FOO.x)
0x02 (LSB of FOO.x)
0x03 (MSB of FOO.y)
0x04 (LSB of FOO.y)
When we consider the InterlockedIncrement is 32bit on a big endian system, the fourth byte from a INT32 pointer is the least significant byte. In this case, 0x04 would actually be the least significant byte and would get incremented. After the increment memory would look like the following.
0x01 (MSB of FOO.x)
0x02 (LSB of FOO.x)
0x03 (MSB of FOO.y)
0x05 (LSB of FOO.y)
where foo.x == 0x0102 and foo.y == 0x0305.
So, the "InterlockedIncrement((PLONG)&foo.x)" is actually wrong. The cast is entirely a bad thing in this case, but we have it in there for perf and data compaction reasons.
A naive fix would be to use the address of foo.x - 2 bytes, but that would result in an unaligned pointer in this case, causing the increment to hit an alignment exception.
I fixed the problem by adding an #ifdef to the structure definition to swap the order of the fields.
typedef struct
{
#ifdef BIG_ENDIAN
SHORT y;
SHORT x;
#else
SHORT x;
SHORT y;
#endif
} FOO;
And changed the interlocked code to use the address of the FOO struct instead of the FOO.x field.
InterlockedIncrement( (PLONG)&foo )
And, of course, I was a good coding citizen and stuck a comment in explaining the madness and referring to the spot in code where we actually do the interlocked increment and decrement.
The worse endian bug yet - a definite gem for the ages.
I spent several hours tracking down a ref counting bug in one of our CLR data structures. The following code snippets are boiled down from a much more complicated structure and set of functions.
typedef struct
{
SHORT x;
SHORT y;
} FOO;
void BadCode( FOO foo)
{
InterlockedIncrement( (PLONG)&foo.x );
}
The code actually works just dandy on x86 since the address is always aligned on a 4 byte boundary and, since x86 is little endian, the address &foo.x actually refers to the LSB of x. This particular value in this case will never overflow the 2-byte signed SHORT, so this works as intended.
If you haven't alredy guessed it, on a big endian platform, this actually increments the value of foo.y. Flawlessly. Every single time. Talk about a bugger to find. I noted the problem when I finally stepped over the interlocked operation and actually noticed that the wrong field changed value in the local window of the debugger!
Now the challenge - how do we fix it? We didn't want to use 32bit values since this would eat up storage unnecessarily as this is a structure quite frequently instantiated. So to add a hack upon a hack, we flipped the fields for big endian platforms :O
And put a very large comment next to the hack. :o\
Spoooooooky.
I had the pleasure of talking with Matt Lee on the way back from GDC 2006. He's awesome. He's super personable and humble. And yet a confident giant when it comes to game development, especially on the 360.
If you haven't already caught this interview, it's definitely worth a look see.
http://arstechnica.com/articles/culture/mattlee.ars
Matt also mentioned the cool XNA Build technology in his interview.
On the development front, we're diligently plugging away at the CLR and XNA Framework. I'm soooo excited to see the progress we have made. Just leave you with 3 word in regards to the XNA Framework- "I can't wait!"
This post serves several purposes.
First, give my good buddy who just recently discovered RSS something to read about :)
Second, I was asked a "personal" question at work. Why do I not pronounce the "t" in words that end with "t". Well, any readers from Hawaii would definitely know "da ansah for tha one". It's the same reason the number 3 does not exist in Hawaii where everyone knows that a tree comes after 2. For those not born and raised in the 50th state, go ahead and check out http://en.wikipedia.org/wiki/Hawaiian_Pidgin
Correc, Indeed.
Third, XNA Framework! I can confidently say - the XNA Framework is clicking along. We're making great progress on all fronts. It's really exciting to see things pulling together as we plow through milestones, bugs, architectural decisions, etc. I look forward to the day when I can provide more specifics - and even answer questions! :)
The XNA Framework and .NET Command Language Runtime (CLR) work on XBox 360 is clicking along. We're head long into feature work, bug fixing, and performance analysis. We've made great progress on planning and implementation since we have returned from GDC. I can attest first hand, the XNA Framework team is progressing and will have some pretty cool stuff for all y'all as we march closer to the day when we can release bits.
One of the major differences we have between Xbox 360 and any of the other platforms that the .NET CLR has shipped on (Windows, Windows Mobile, and other Windows CE platforms) is the endianness of the system. The following example should illustrate.
- Consider 67305985 in base 10 = 04030201 in base 16.
-
- This value would be stored in a 4 byte integer as follows
Little Endian: 0x01 0x02 0x03 0x04
Big Endian: 0x04 0x03 0x02 0x01
Microsoft has predominantly shipped on Little Endian systems which includes the AMD and Intel family of processors. The Power PC chip that powers the XBox 360 can actually be configured to run in either little or big endian mode; the version in the XBox 360 is big endian. We actually put a LOT of effort into trying to get most of this correct in spite of only shipping on little endian systems. But as any coder will tell you, it is near impossible to get this correct for ALL components in a large and complex system like the CLR. We simply did not have any platform to do this validation on.
While compilers will do the right thing for general computation, but we potentially run into trouble when reading data from storage, over the network, from devices, etc. We need to map the source data's endianness to that of our system. Over the last several months, our stellar QA team has been working hard getting test infrastructure functional and executing an increasing number of the army of test we have for other platforms up and running against the XNA Framework.
As you can imagine, several of the tests find endian related bugs. I've squashed enough of them that I can almost smell their stench as I examine source code.
If you're a coder, read on, especially aspiring cross platform XNA Framework game devs.
I'd like to share with you one genre of endian bugs related to the System.BitConverter class that could potentially affect you.
BitConverter is comprised of a set of static functions that do exactly as the name implies - convert bits. More specifically, they convert from all of the integral value types to byte[] and vice-versa. Most applications of the BitConverter class involves symmetry such as the following
int i = BitConverter.ToInt32(byte[] inputdata);
(manipulate i)
return BitConverter.GetBytes(i);
In the case where the data never leaves the confines of your application, this actually works fine. However, the other typical use of BitConverter involves symmetry across serialization.
file.Write( BitConverter.GetBytes( inputdata ), 0, 4 );
(then later on)
byte[] inputdata = new byte[4];
file.Read( inputdata, 0, 4 )
return BitConverter.ToInt32(inputdata);
This is a potential endian bug. If the endianess of either end of the serialization does not match, the above code will fail. All methods of BitConverter accept or return byte arrays in SYSTEM endian order. The burden is on the application developer to conceive a scheme to maintain consistency across symmetric applications.
How do you know if your usage of BitConverter can run into potential endian issues?
- If your data never leaves the confines of your program, then you're safe. Sort of. We all know how feature creep, new/unforeseen requirements, and redesign of our applications utilize code in ways that were never intended. So unless you have a very good reason (performance would be one if correctly justified) I would not rely on this "safety".
- If you know the source/dest data format will ALWAYS match your system endianness then you are safe. This is often true when handing data down to devices and similar operating system calls.
- In my opinion, one should always error on the side of assuming that you will NOT be safe unless you code the safety in.
So how do you write endian safe BitConverter code? There are two things you must take note of.
- You must know the endianness of your source data. Whether reading bytes from a file, slurping bytes off of a socket, or some other source, you must know what endianness the data is in. If you're processing a well known format (JPG, ZIP, TAR, etc.) refer to the respective formats specification to determine the correct endianness. If you control generation and consumption of the data, you must choose a consistent endianness and document in your code and specifications.
- You must honor the little known (and used) BitConverter.IsLittleEndian flag to determine the underlying system endianness.
Here's the corrected file write/read sample from above.
// The file format store integral types in little endian order
if (!BitConverter.IsLittleEndian)
Array.Reverse( inputdata, 0 );
file.Write( BitConverter.GetBytes( inputdata ), 0, 4 );
(then later on)
byte[] inputdata = new byte[4];
file.Read( inputdata, 0, 4 )
// The file format store integral types in little endian order
if (!BitConverter.IsLittleEndian)
Array.Reverse( inputdata, 0 );
return BitConverter.ToInt32(inputdata);
All right. Admission time. This isn't a very nice solution. BitConverter is a bit unwieldy in this case. Okay. It kinda sucks.
One solution is as to code a EndianBitConverter class that accepts a flag on construction to control the reversing of the byte array data. You could then abstract construction of the endian aware bit converter class into a static function based on the source data.
// The file format store integral types in little endian order
EndianBitConverter littlebc = EndianBitConverter.CreateForLittleEndianData();
file.Write( littlebc.GetBytes( inputdata ), 0, 4 );
(then later on)
EndianBitConverter littlebc= EndianBitConverter.CreateForLittleEndianData();
byte[] inputdata = new byte[4];
file.Read( inputdata, 0, 4 )
return littlebc.ToInt32(inputdata);
The static method above could be implemented as follows
public class EndianBitConverter
{
public static EndianBitConverter CreateForLittleEndian()
{
return new EndianBitConverter( !BitConverter.IsLittleEndian );
}
public static EndianBitConverter CreateForBigEndian()
{
return new EndianBitConverter( BitConverter.IsLittleEndian );
}
bool swap;
private EndianBitConverter(bool swapBytes)
{
swap = swapBytes;
}
public Int32 ToInt32(byte[] data)
{
byte[] corrected;
if (swap)
{
corrected = data.Clone();
Array.Reverse( corrected, 0, 4 );
}
else
{
corrected = data;
}
int i = BitConverter.ToInt32( corrected );
}
// And similar methods for GetBytes(Int32) and all other types needed.
}
Of course, if you need more perf, you could ditch the array cloning and reversing and do the bit manipulations yourself. Just be careful for sign extension issues.
I've fixed several bugs in our source code base that do not honor the BitConverter.IsLittleEndian flag. Hopefully this post will help prevent you from falling into the same pitfalls.
