Some of the issues I have been having with XNA are starting to bug me the more I think about them. I started writing this back at xna 3.1 launch but have only gotten around to posting it now.

Lack of types

First there is no RectangleF structure! WTF?!? XNA ver 4.0 is out and it still does not have a RectangleF type. What is so special about a having a RectangleF type? It would cut down on the number of type casting that is involved especially when working with the SpriteBatch class. I am making a 2D tiled map component and for a 100x100 size map there are like over 40,000 float -> int casts that can occour per rendered frame! 100x100 map is a very small map size! Why I am casting to int is because if I don't there are half pixel issues that arrise and I get gaps between tiles if I don't perform the cast. Which is rediculous because the reason I even have these issues in the first place is because of the way the SpriteBatch class accepts input for drawing sprites.

Lets put it this way SpriteBatch accepts a Rectangle type for specifying a position to render the sprite on screen. This is one of the Draw methods on the SpriteBatch class ...

public void Draw(Texture2D texture, Rectangle destinationRectangle, Rectangle? sourceRectangle, Color color)
{
    Vector4 vector;
    vector.X = destinationRectangle.X;
    vector.Y = destinationRectangle.Y;
    vector.Z = destinationRectangle.Width;
    vector.W = destinationRectangle.Height;
    this.InternalDraw(texture, ref vector, false, ref sourceRectangle, color, 0f, ref vector2Zero, SpriteEffects.None, 0f);
}

As you can see the method stores the destinationRectangle parameter in a Vector4 type. So because my data is originally stored as floats if I use this draw method I have to cast my data to a Rectangle type that consists of integers. Then I call this method which will only turns around and stores that rectangle data back as a float! I am being forced to cast my data for no good reason simply because the xna team has not provided a RectangleF type. /facepalm /repeat  It's things like this that just drive me friggin nuts!

What in the hell kind of frackin logic would make the xna team think thay don't need RectangleF type in the xna framework is beyond me. But if it were up to me needless to say, that kind of BS would not be tolerated. A RectangleF structure should have been there since day one of XNA 1.0! Just the fact that I am having to make all these casts to int is making my code unnessesarily messy to read makes me frustrated. The only real reason I can think of to want to cast to int is if you are using DrawString and you want to enusure your text get rendered cleanly.

The ContentManager

The ContentManager.ReadAsset method is coded as protected so the only way to use it is to create a new class that inherits from the ContentManager class. Why do I want to call this method? Because It allows me to load game assest from disk again to get back a new instance of a object rather then using Content.Load<> which will cache the object after the first load call.  How hard is it to give users the option via  Load<T>(string assetName, bool doNotCache). In order for me to get around this I am using the fallowing code ...

public class ExtendedContentManager : ContentManager
{
    public ExtendedContentManager(IServiceProvider serviceProvider)
        : base(serviceProvider)
    {
    }

    public virtual T Load<T>(string assetName, bool doNotCache)
    {
        if (doNotCache)
        {
            return ReadAsset<T>(assetName, null);
        }

        return base.Load<T>(assetName);
    }
}

public static class ContentManagerExtenders
{
    public static T Load<T>(this ContentManager manager, string assetName, bool doNotCache)
    {
        if (manager is ExtendedContentManager)
        {
            return ((ExtendedContentManager)manager).Load<T>(assetName, doNotCache);
        }

        return manager.Load<T>(assetName);
    }
}

But I also have to remember to replace the content manager in my game constructor via this.Content = new ExtendedContentManager(this.Services); /shakeshead

Additionally the ContentManager does not allow you to unload individual resources. It only allows you to unload all the resources via the Unload method. This could be a very handy feature in terms of optimizing the speed when loading up a new game map. For example if the game was loading up a new map rather then unloading all the resources you could hold onto the currently loaded resources then track what resources are not required after loading the new map is complete. Then unload each individual resource that is not needed, so in terms of numbers if the next map and the previous map use 90% of the same resources that means that you could save 90% of the work required to re-read the resources off the disk. This scenario also makes sense in situations where you want the map to load dynamically as the player traverses that map.

3.1 & No Avatar support for windows

Here I am thinking wu hoo Avatars! Then 3.1 is released and I come to find out that avatars are only supported for the xbox360!  /ShakeFist /StartMakingCrudeShankFromBrokenGlass It's like come on, Really. Really? Srsly disappointing.

ICloneable shiftyness

From .net Reflector found in C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\Silverlight\v4.0\Profile\WindowsPhone\mscorlib.dll  mscorlib.dll used by windows phone 7 apps

internal interface ICloneable
{
    // Methods
    object Clone();
}

For all that is sane in this world, can someone please tell me WHY ICloneable is declared as internal for xna Windows phone 7 apps?!?!?  It's an interface. With one one method. And the people in charge declared it a internal. WTF?

*raises arms in the air dumbfounded.*

Who at Microsoft made the retarted decision to declare it as internal o.O.  The decision is just so utterly friggin stupid. You went through all the effort to write the code and make use of it. But rather then declaring it as public and maintaining increased portability between frameworks you have gone to the effort of trying to hide it. You have used it in over 100 objects from System.Drawing.Font to System.Array to System.Xml.XmlNode etc.

Imagine you work for Microsoft and your sitting in your office and you are building the Silverlight framework. Your probably not writing the framework from scratch or maybe just parts of it, so there is a lot of cut and paste and porting going on from previous .net framework implementations. Low and behold you get to the ICloneable interface.

At what point and for what possible reason could you have to change ICloneable from public to internal. Do you not understand the implications your actions will have? Was it the lead dev that made the decision? .NET frameworks have been around for ten years now, in each release there has been a conscious effort when porting and updating the framework to keep as much of the framework in tacked as possible. ICloneable has been a staple of .net since the beginning, and to have it exist in the framework as well as making use of it internally, without making it public automatically breaks compatibility for absolutely so reason. The decision to make ICloneable internal is one based on coding philosophy. And by doing that you immediately come into conflict with other peoples philosophies. Also philosophies change over time. But code doesn't. Thus it needs to be re-factored making more work for end users.  :(

If your philosify excludes the use of ICloneable then don't use it. But that doesn't mean the Microsoft dev team should impose there own coding philosophy on the masses of people that will be using the api. Introducing breaking changes because of coding philosophy is just bad mojo.

Making it public maintains compatibility and minimal re-factoring for the countless developers that will be using the framework and porting all sorts of code over to the framework. The implications of going from public to internal is drastic in my opinion. It's a brain fart. It's like a cancer in my brain. As hard as I try to come up with excuses why they declared it as internal I can't think of a single reason. As developers we deal in logic and logical systems all the time and declaring it internal is highly illogical to me. There are unspoken rules even in programming and it's like a give in that you would NOT declare ICloneable as internal.

State types lacking property setters

The decision to make setters private for various state types (GamePadState for example) is one based on coding philosophy, specifically the philosophy of the xna team. The xna team decided for everyone that they had no need for property setters on the GamePadState and other types in the xna framework.

It's not about the xna team's philosophy, it's about providing functionality for usage scenarios that the xna team CAN'T think of. No property setters on state objects are a prime example. What would be a usage scenario, game pad emulation via other devices. For example writing code that uses DirectInput to get user input from devices and mapping that input over to a GamePadState object. Any existing code that uses the xna input types can continue to do so and be oblivious that the state data is actually coming from a DirectInput device behind the scenes.

Non boolean button states

Who decided that that using a enumerator to represent a button state was a good idea?

GamePadState lastState;
var state = GamePad.GetState(PlayerIndex.One);
if (state.Buttons.A == ButtonState.Pressed)
{
    // do something
}

if (state.Buttons.A) // boolean detection would look like this
{
    // do something -> does not compile
}

// detect click
if(lastState.Buttons.A == ButtonState.Pressed & state.Buttons.A == ButtonState.Released)
{
    // clicked
}

// detect click if booleans were used
if (lastState.Buttons.A & !state.Buttons.A)
{
    // clicked -> also does not compile because ButtonState enum is not mark with [Flags] attribute
}

In the code example above you can see that xna uses a ButtonState to represent if a button is Pressed or Released. Not to mention there is twice as much code to write. Button states should have been represented by a boolean not an enumerator.

Conclusion

Everything I have mentioned is easily fixable if only there were a more direct communications line to the microsoft dev team(s). Instead we are delegated to the black hole that is MS Connect. I have posts on there from 3 years ago, yes 3 years ago! Some of my entries still are not responded to and some only get a few words back saying well look into it.

As far as I know and weather things have changed in the last few years, ms connect is not a mandatory job function for ms dev teams and is not tied into Microsoft's back end bug/feature tracking systems. It's voluntary, so who knows how often a dev team actually spends any real time there.

I get frustrated at times as you can see. It's Microsoft, it's like worse then pulling teef. *Teeth :) Xna rocks the casba but there are times I tell ya. "You wanna go to the moon!" :D Someone posted the comment "man back then domestic violence was hilarious." ROFLMAO It's funny cause it's true. :P