XNA High Resolution Patcher v1.0 Released

Download XNA High Resolution Patcher v1.0

This unlocks the maximum possible resolution of any XNA 4.0 game.

Stardew Valley at 4K

Dust: An Elysian Tale menu at 4K

To patch existing XNA 4.0 games, unzip to someplace on your machine.  Run HighResolutionPatcher.exe.  Drag the executable onto the window.  It will try to do three things:

- Make a backup of the executable.
- Copy RomSteady.HighResolution.dll into the folder.
- Patch the executable in place.

Then have some fun.  If the game properly enumerates available resolutions and doesn't have restrictions, you should be good to go.  "Terraria" doesn't like going over 1920x1080, so I recommend you use "RomTerraria" for that.  "Gnomoria" doesn't like going over 1920 pixels horizontally, but works fine at 1920x1440.

If you want to unlock high resolution mode in an XNA 4.0 game that you are developing, add a reference to RomSteady.HighResolution.dll and call RomSteady.HighResolution.RuntimePatcher.PatchXna() as the first line in your program's Main().

Have fun, and let me know what games you test.  I'll keep updating the list below as I test.

Compatibility List

"Dust: An Elysian Tale" works fine at 3840x2160.
"Stardew Valley" works fine at 3840x2160.
"Dead Pixels" works fine at 3840x2160, but you should patch both "Dead Pixels.exe" and "Dead Pixels Launcher.exe" to be safe.
"FEZ" works fine at 3840x2160, but there doesn't seem to be much point in it.
"Rogue Legacy" capped at 1920x1440.
"Gnomoria" capped at 1920x1440.
"GunCraft" capped at 2560x1440.

Incompatible List

"Bastion" is XNA 3.1, not XNA 4.0. That said, it already runs at 4K.
"Lucidity" is XNA 3.1, not XNA 4.0, and also runs at 4K.
"Sol Survivor" is XNA 3.1.
"The Adventures of Shuggy" is XNA 4.0, but is hardcoded to 1280x720.
"DLC Quest" is XNA 4.0, but has a hard internal cap of 2048x1536.
"Terraria" is XNA 4.0, but has a hard internal cap at 1920x1080.  Use "RomTerraria" for that instead.

Hint About Something Soon To Be Released

"Dust: An Elysian Tale" looks absolutely beautiful in 4K.

"Gnomoria" doesn't like horizontal resolutions larger than 1920, but can go tall.

These were both patched using the exact same executable.

Almost Done...

While I was working on adding high resolution support to Gnomoria, I decided that the obfuscated nature of the binary gave me a new opportunity: generalizing the hack.

I'm modifying RomTerraria so that you can add a basic version of the RomTerraria resolution hack to any XNA executable.

Mind you, I'm a bit stuck for time until I get Electric Eye out the door to all of my partners at my day job, but I'm hoping to have it done in the next week or two.  I'm using Dust: An Elysian Tail and Gnomoria as my guinea pigs.

XNA is Dead. Boo. Long Live What?

I just got home from a little teeny tiny XNA meetup in Seattle that happened to coincide with Steam Dev Days.

It was kind of a weird experience.  The biggest takeaway for me is that, at least for Microsoft platforms, the likelihood of XNA coming back from the dead is almost nil.  For enterprise software development, .NET is king and has taken the place of Visual Basic 6, but for everything else, it's either JavaScript/HTML5 or C++.  I get the feeling that Microsoft backing Unity is more a "meh, Unity gets the basics right and nobody will know about how badly they fuck up the rest until they become advanced" move than an actual strategy.

The really sad thing is that unless Microsoft steps up, XNA may live long and prosper on almost every non-Microsoft platform in existence due to Monogame.  I overheard some NDA stuff that I won't go into, but I find it really funny that there are people who are chomping at the bit to pick up what Microsoft has thrown away here.

That said, I feel my time with XNA is pretty much gone.  My interest in XNA was always related to how it would democratize game development.  Game players who learn how to make games not only end up being better gamers, they also end up being better game community members.  They know how hard it is to do X, and their brief peek behind the curtain into the inner workings of how games work let them have a better appreciation for game developers and games themselves.

However, for a platform to inspire neophyte game developers, you need support, and XNA has lost it.  It's really hard for me to remain passionate about something that's fading away.  So, where am I going to focus my efforts now?

Lua.

Lua has been used in a lot of games as a scripting language.  All game and UI logic for both Amped and Amped 2 were written in Lua, and the only reason Lua didn't get any credit in the game or manuals is that their license at the time said it was optional and legal saw no reason to provide the credit.  In addition, two of the major low-cost game engine projects targeted at neophytes are shipping with Lua bindings: Leadwerks 3.1 and FPS Creator Reloaded.

However, a lot of the public scripts that are out there are, quite frankly, shit.  Even the little hacks I've published over the last few days are shit.  If I'm going to do this right, I'm going to have to go back to first principles.

Here is my plan.  Starting this weekend, I'm going to try to write a game from scratch against Leadwerks 3.1 Indie Edition.  My goal is to use absolutely none of the scripts that ship with the engine, though.  I'm going to start from nothing and move on from there.

This will do three things.  First, it will give a ground-up point of view of what it takes to build a game using Lua with lessons that can be applied to multiple game engines.  Second, it will help me better understand what it takes to be effective with Lua.  Third, it will help me get ready to better use an engine that I backed on Kickstarter before the C++ bindings

Hopefully, this works out well for everyone.  I'll still remain involved with .NET and XNA, but even more on the periphery than before, unfortunately.

C++ 11 and Types

I've been trying to ramp up on all the language changes as part of C++ 11, and have been trying to figure out how to do something similar to XNA's Content.Load<T> as part of it, and I'm a bit stymied so far.  Let me explain.

XNA's ContentManager has a ton of features that seem like they'd work wonderfully in C++'s RAII world.  When you call .Load<T>, it first checks to see if the content has already been loaded through this particular ContentManager.  If it has, you get the cached copy back.  Otherwise, it tries to load the file, instantiates the proper type loader, caches the loaded object, then returns a reference to the object.  When ContentManager is disposed of, it handles cleaning up all of its cached objects for you.  Plus, I can keep multiple ContentManagers around: one for "common" items (characters, UX elements, etc.), and one per "level" (level-specific textures and geometry).  That way, you just dispose the level-specific content manager and start a new one up for a new level.  This pattern just screams RAII to me.  The gotcha is that each ContentManager can house multiple types.

Now at least at the moment, I'm at a loss for how to do this in a type-safe, RAII friendly manner in C++.  It's easy if I create a ContentManager per type of content to load into it (ContentManager<Texture2D>, ContentManager<LevelData>, ContentManager<BlahBlahBlah>, etc.), but then I lose the ease of working with a single object.  I could add a strongly typed reference for each type into ContentManager (ContentManager.LoadTexture2D, ContentManager.LoadLevelData, etc.), but then I lose loose coupling.  I could just keep a hash_map<string, void*> and force dynamic_cast to be used on load, but then I lose RAII cleanup of each subobject.

I'm sure there is a graceful solution to this that I just haven't found yet, but it's a fun problem space to explore.

Minor update: This weekend has taught me that I have much more to learn about the wonderful world of shared_ptr<T>.  The last major C++ codebase I worked in was a barely C++'d C codebase, so my mental model of C++ is still skewed horribly.

Games and Tools on Steam using .NET

Some of you may know that I have a near unhealthy Steam library, and I decided to spend a little time trying to figure out how many games on Steam are using the .NET Framework. I know most games are developed using native C/C++, and thanks to the popularity of Minecraft there's a growing Java contingent (like Delver and 3079), but I'll always have a soft spot for .NET.

This list is only games that use .NET in some respect.  Some games install .NET but don't appear to use it (like Batman: Arkham Origins).  Unity games are called out if they use Mono either instead of or in addition to native code libraries for logic.

This list isn't definitive, so if you know of other games on Steam that are using .NET or if I've put something on this list that shouldn't be here, please let me know by posting in the comments.

Title of Game (Game Framework/Technology)

• Adventures of Shuggy (XNA 4.0)
• AI War: Fleet Command (Unity)
• Ancients of Ooga (Windows Forms for settings app only)
• Apogee Throwback Pack (WPF for launcher only)
• Atom Zombie Smasher (Tao.OpenGL)
• Bastion (XNA 3.1)
• Borderlands 2 (WPF for launcher only.  Has XNA 4.0 linked, but doesn't appear to use it)
• Breath of Death VII (XNA 4.0)
• Cthulhu Saves the World (XNA 4.0)
• Cubemen (Unity)
• Cubemen 2 (Unity)
• Dead Pixels (XNA 4.0)
• DLC Quest (XNA 4.0)
• Dust: An Elysian Tail (XNA 4.0) 
• Fable 3 (SlimDX for video options applet only)
• Far Cry 3 (Windows Forms for Editor) 
• FEZ (MonoGame) 
• GunCraft (XNA? Need to validate)
• Hammerwatch (OpenTK)
• Lucidity (XNA 3.1)
• Magicka (XNA 3.1)
• Outlast (Unreal Engine...appears to just be C++/CLI managed hooks for debugging and editor wireup)
• Penny Arcade's On The Rain-Slick Precipice of Darkness, Episode 3 (XNA 4.0)
• Penny Arcade's On The Rain-Slick Precipice of Darkness, Episode 4 (XNA 4.0)
• Rogue Legacy (XNA 4.0)
• Sol Survivor (XNA 3.1)
• Space Engineers (SharpDX)
• Space Hulk (Unity)
• Terraria (XNA 4.0)
• The Witcher Enhanced Edition Digital Comic (Unity) 
• The Witcher 2 (C++/CLI, COM interop to handle registration, password recovery, etc.)

Title of Tool (Portion using .NET)

• Axis Game Factory (Unity)
• GameMaker (Asset compiler, development web server) 
• Music Creator 6 Touch (Fault reporter)

[Update 11/30] Added FEZ, Music Creator 6 Touch, Adventures of Shuggy, DLC Quest, Fable 3, Apogee Throwback Pack, Ancients of Ooga, Space Hulk, The Witcher Enhanced Edition, The Witcher 2.

[Update 1/16] Added GunCraft and Axis Game Factory.

XNA Hack: Create RenderTarget2D greater than 4096x4096

Problem:

XNA's HiDef profile has a maximum Texture2D size of 4096x4096.  RenderTarget2D has a backing Texture2D object, and this limitation is enforced at time of construction.

Solution:

Time to get a bit tricky with reflection.  Limitations in XNA are all stored in Microsoft.Xna.Framework.Graphics.ProfileCapabilities, an internal class.  Fortunately, they aren't constants...

In your Initialize() function...

Assembly xna = Assembly.GetAssembly(typeof(GraphicsProfile));
Type profileCapabilities = xna.GetType("Microsoft.Xna.Framework.Graphics.ProfileCapabilities", true);
if (profileCapabilities != null)
{
     FieldInfo maxTextureSize = profileCapabilities.GetField("MaxTextureSize", BindingFlags.Instance | BindingFlags.NonPublic);
     FieldInfo hidefProfile = profileCapabilities.GetField("HiDef", BindingFlags.Static | BindingFlags.NonPublic);
     if (maxTextureSize != null && hidefProfile != null)
     {
         object profile = hidefProfile.GetValue(null);
         maxTextureSize.SetValue(hidefProfile.GetValue(null), MaxTextureSize);
     }
}

Replace MaxTextureSize in the last line with whatever you feel your maximum size should be. Ideally, you'll be querying DirectX 9 and setting the value to the maximum value allowed by D3D9Caps.

Use ZIP Files To Hold Your XNA Content

Quick entry for now, more in-depth one coming soon. Requires SharpZipLib.

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using Microsoft.Xna.Framework.Content;
using ICSharpCode.SharpZipLib.Zip;
using System.IO;

namespace RomTerraria
{
  public class ZipContentManager : ContentManager
  {
      private ZipFile zipFile = null;
    
      public ZipContentManager(IServiceProvider services, string zipFile) : base(services, "")
      {
          this.zipFile = new ZipFile(zipFile);
      }

      protected override System.IO.Stream OpenStream(string assetName)
      {          
          var entry = zipFile.GetEntry(assetName.Replace('\\','/') + ".xnb");
          if (entry != null)
          {
              return zipFile.GetInputStream(entry);
          }
          return null;
      }
  }
}

Key Events in XNA 4.0

One of the top requested features for XNA since release was the ability to intercept key press events instead of just the key up/down events so that people could do text input easily.

Still can't do it in XNA 4.0, but here's a way of working around it by adding a message filter. Please be aware that they may break this in the future if they don't use Windows Forms for their form in XNA 5.

First, the keyboard filter class...

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Windows.Forms;
using System.Runtime.InteropServices;

namespace RomSteady.Xna.GameEngine.Input
{
    public class KeyboardMessageFilter : IMessageFilter
    {
        [DllImport("user32.dll")]
        static extern bool TranslateMessage(ref Message lpMsg);

        const int WM_CHAR = 0x0102;
        const int WM_KEYDOWN = 0x0100;

        public bool PreFilterMessage(ref Message m)
        {
            if (m.Msg == WM_KEYDOWN)
            {
                TranslateMessage(ref m);
            }
            else if (m.Msg == WM_CHAR)
            {
                if (KeyPressed != null)
                    KeyPressed.Invoke(this,
                        new KeyboardMessageEventArgs()
                        {
                            Character = Convert.ToChar((int)m.WParam)
                        });
            }
            return false;
        }
       
        public event EventHandler KeyPressed;
    }

    public class KeyboardMessageEventArgs : EventArgs
    {
        public char Character;
    }
}

...and now to wire it up so you can get those KeyPressed events. In your Initialize() function...

...
            var keyboardFilter = new KeyboardMessageFilter();
            keyboardFilter.KeyPressed +=
                new EventHandler(keyboardFilter_KeyPressed);
            System.Windows.Forms.Application.AddMessageFilter(keyboardFilter);
...

This code isn't flawless, but is working well enough for my purposes.

XNA and VB, One Year Later

Over the last while, I've ranted and raved about Microsoft's XNA Game Studio Express Edition not supporting Visual Basic .NET.

Now that the ZMan is updating again, I've noticed a new post about some really poor communication skills from the XNA team about VB.NET support. He links to a great XNA/VB rant from a Microsoft MVP about it.

Now, awhile back one of the Microsoft guys said that the reason VB wasn't supported on the Xbox 360 was because VB used some features of the CLR that their version of the Compact Framework didn't support. I think I finally figured out what it was, and if it's the case, we have only our older VB6 brethren to blame.

The XNA team could have easily said that you couldn't use "My" on the 360, even though it's supported in the full .NET Compact Framework. They could have easily said that the Microsoft.VisualBasic namespace couldn't be used on the 360, and we would have adapted, even though it is also supported in the full .NET Compact Framework. But remember back in 2001 when the value of True was a big deal? It does make me wonder what other "hacks" were put into the full CLR to support the older VB6 way of doing things.

I love VB.NET with a passion, but over the last couple of years I have started to lose my faith in VB's future. When you look at many of the new features that are coming into the .NET Framework, the syntax that is being used to bring these features into VB is becoming more and more tortured, and some language constructs now go against best practices. (Using "Handles" with WPF applications means that you aren't using the WeakEvent pattern, for example.)

So as a result, we're going to have to move back to the realm of VB hacking to get things done...even though we no longer have that VB hacker icon to follow. If you want to use XNA and VB, you can check out Alan Phipp's page for now, but if we want full access to the managed world, we're going to have to tell Microsoft two things. One, it's okay to let the VB6 way of doing things die, and two, .NET-capable technologies that Microsoft releases must support all languages that are supported by Visual Studio out of the box.

Teams like the XNA team and the Windows Home Server team may only have the funding to support one language, but if something like that is detected inside Microsoft, the platform evangelism teams should step up to the plate with either funding or staff to help them support the other languages. After all, language diversity doesn't mean anything if Microsoft is only going to be giving us items we can use with C#.

[XNA] Content Pipeline Pros/Cons

I downloaded Microsoft's XNA Game Studio Express Edition Beta 2 last week while I was on my trip, and I've spent the last week messing around with it, going over the documentation, etc. There's a lot to like and a lot to dislike. Here are my initial impressions.

Pros

1. Strongly-typed loading. Each asset is serialized as a binary asset, and as a result, asset loading is not only quick, it's type-safe. The larger and more complex the asset, the better this is.
2. Extensible. The content pipeline was designed to be extended in every which way possible. For most items, composite objects are going to be the the name of the game because a lot of the commonly built functionality is already embedded into the framework. If you need extra functionality above and beyond what is there, for most things it will be easy enough to add it yourself.
3. (Mostly) self-configuring. It's nice to be able to add an asset and (most of the time) have the proper settings already set on the importer/converter.

Cons

1. .XNB. Whoever had the bright idea to make everything have the same extension and have to individually rename assets inside the IDE needs to be strung up by their testicles and flogged in public. It is very common to have a model in a folder with the appropriate texture having the same base name (chair.fbx/chair.tga for example). The reason for this is because if you don't have the files in the same folder, most modelling software freaks out with the texture paths.
2. No included packed file system. True, you can subclass the ContentManager to make your own packed file system, but the time savings from loading a strongly-typed serialized file are more than offset by slow individual file access times (due to security lookups, etc.) For small projects, this isn't that big of a deal, but once you start getting into asset counts in the 4- to 5-digit range, it matters.
3. Not team-friendly. Bear with me on this one. Converting an .FBX file to a model, or a .TGA to a texture takes little to no time, but when you have custom asset importers to handle certain items (lightmaps, pathfinding precalculations, visibility), the time it takes to process these items increases by several orders of magnitude. We aren't talking seconds...we're talking hours EACH. One of the primary purposes of any asset pipeline is that this time cost is paid one time per iteration of the asset. With the current XNA Content Pipeline, each person who gets the asset is going to have to pay the time cost unless they use source control, which leads me to...
4. Not source-control friendly. Now, Visual C# Express Edition does not support source control, but you can still use an external source control solution. The nice thing is that you can eliminate the extra time costs via source control. The downside is that to get this time savings, you have to check in not only the asset and the compiled asset, but the intermediate "temp" file as well. Then to do an iteration, you have to check out all three files, do the build, and then check them in again.
5. Documentation still fairly weak. Just try finding the information you need to write an image importer inside the documentation...be prepared to delve through over a dozen help topics and even then you'll have to go through and do it by trial-and-error.
6. Plug-ins. Don't get me wrong, I love the idea of plugins. My major issue here is that they seem to have missed one of the strengths of .NET. If I create a control in a Windows Forms project, I compile and then that control is available for use in my toolbox automatically. The IDE uses reflection on the compiled assembly and lets me use the control appropriately. If I'm writing plugins as part of my game, why do I have to then reference the plugin DLL through a setting?
7. Still haven't found a way to hack it to work outside of Visual C# Express Edition. I will find a way...