|
|
 | 10/14/08 |
Well I'm abandoning my XNA development efforts in favor of WPF/Silverlight. Primary reasons being:
- WPF/Silverlight does not have a language barrier (you can use VB, etc.)
- The distribution agility of Silverlight vs. XNA is off the chart. The Silverlight plugin does not require Windows (let alone the .NET framework). It's simply a browser plugin ala Flash, available for both Mac and Windows.
- XNA Click-once. Very cool for C# XNA developers, but the prospect of creating a Click-once VB hack/workaround/replacement for VB XNA apps really ups the proverbial "is this really worth it" ante.
- The basis of my 2D XNA engine (i.e. the matrix hierarchy, and a scripting engine (which I never covered, but basically it allows you to target any property of a specific data type and interpolate it over time)) this was all very cool indeed. And it all already exists, practically verbatim, in WPF*.
*While it's a bit satisfying to see I came up with the same solution that Microsoft did for scripting any object with time-based animation, it's also a very major /facepalm to see I've been reinventing the wheel for the past several months!
- WPF appears to be the future of Windows development, which I'd like to stay on top of for both my career and personal interest. What's more, you can totally . You can even use . No, it's not as powerful as XNA but you have to admit; the whole ordeal is rather neato.
So someday a new blog might crop up somewhere with my WPF/Silverlight stuff on it (altho for now I'm still pretty green). I still have those game ideas tucked away waiting for implementation... someday.
 | 6/20/08 |
As a potentially negative side-effect to now giving these blog posts more descriptive labels, there are now several non-XNA related topics on this blog. Namely, Off topic. Here are some Off topic links I highly suggest:
 | 6/19/08 |
In Visual Studio 2008, when trying to drag a local SQL Server CE database table onto your LINQ design surface, you receive the following error: "The selected object(s) use an unsupported data provider." This message is a little misleading, because you can in fact LINQ over your SQL Server CE database; it's just the drag & drop LINQ design surface in Visual Studio that doesn't know how to interact with SQL CE. To work around this limitation of the IDE, you can call upon Microsoft's utility to create a .dbml file (aka, a new LINQ to SQL item) on your behalf. Here's a reasonably simple way to accomplish it: In your project's solution explorer, right-click the node containing your .sdf (database) file and "Open Folder in Windows Explorer". In the resultant window, create a new text document called MakeCeLINQ.bat and edit it, entering this command: C:\"Program Files\Microsoft SDKs\Windows\v6.0a\bin\sqlmetal.exe" /dbml:CeLINQ.dbml Database.sdf Replace Database with whatever your .sdf file is called. It's important that this batch file be created in the same folder as your .sdf file, since the command is structured in such a way that assumes the .sdf file is sitting next to the batch file. Close & save MakeCeLINQ.bat, and double-click to run it. SqlMetal will create CeLINQ.dbml. In Visual Studio, click the button to show all files for your project and include your newly created CeLINQ.dbml file. Include the "MakeCeLINQ.bat" file, too - strictly speaking it's no longer required, but you may find it convenient to keep it with your project. So now you should have something like this:  You can now work with the CeLINQ object within the IDE as normal (with the ever-present exception of drag & drop functionality). If you change any of the schemas in your CE database, simply re-run the MakeCeLINQ.bat to update the CeLINQ object.
 | 6/17/08 |
I did a little project for my wife this weekend and used LINQ for the first time. Visual Basic's implementation of LINQ over XML is just about the greatest thing since sliced bread. Looking at my Web Updater, I get an xml file called the "wum" (web update manifest, which contains a list of server-side files to compare against a client for making decisions about which files to update). To read these wum.xml files in my Web Updater, I was using an XMLReader to simply parse the file in a serial fashion. Which worked fine, really; although there was not any "knowledge" of the xml document itself within the IDE or the Web Updater code, per se; the parsing routine was a bunch of XMLReader.Read statements, with the occasional variable assignment thrown in whenever certain nodes were reached. Without any prior knowledge of the XML file in question, the parsing process is not exactly intuitive to behold, let alone modify/debug. With LINQ, this task of reading the wum.xml to determine which files on the disk require an update can be accomplished in a radically different fashion. First of all, rather than simply associating a wum.xsd schema with the XMLReader's xml settings, you can drop said schema into the solution explorer / project itself and in doing so, define an XML type much in the same way you'd define any given class. With the xml schema now available to the compiler, VB provides you with "xml intellisense", allowing you to traverse an xml document in no less than xml statements such as objMyDocument.<customer>.<name>.<first>.Value and things of that nature. It's a little strange at first but pretty fantastic. This obviously injects a great deal more knowledge of the xml structure itself into the code - now someone viewing or even editing this code for the first time has a far less abstract situation on their hands. If that weren't enough of an improvement, I realized I didn't really have to serially process the wum.xml at all. I can take that XMLReader I'd been using to create an Xml.Linq.XDocument. An XDocument is basically an xml document instance but it's queryable by LINQ - so you can treat it like a database. Now I can save literally dozens of XMLReader calls & parsing effort by simply querying the XDocument Where Not IO.File.Exists OrElse IO.File.LastWriteTime <> (queryResult.LastWriteTime) and viola, an IEnumrable object of XElements matching the query are returned. In addition, the query result can be stuffed into any given appropriate class of your choosing, so you don't even have to deal with XElements in the result set if you don't want to, and then ultimately .ToList(ed) into a generic List(Of <whatever>). It's all slightly mind-blowing the first time you sit down to use it, particularly when you consolidate 50 lines of mundane XML parsing into a single LINQ query in a matter of minutes, never even having used LINQ before. Just imagine what you can do with this stuff once you actually know how to use it... pretty cool!
 | 6/14/08 |
I updated the graphics of this blog a little bit. I'd been playing around with a VB/XNA logo hybrid in photoshop so I thought I'd use it for something. I've been working very hard on my Web Updater and Wummer applications over the past 2 weeks and I haven't been able to resist putting more and more functionality into them. They're turning into things which may actually be quite useful. The Wummer will now let you split up the files you want to publish over however many different hosts you specify; so for instance if you have 3 hosts at your disposal but they're slow uploaders (eg., homebrew DSL & Cable broadband line hosting like I use for most things) the Wummer allows you to divide the publication of files amongst multiple hosts, and the manifest now groups files by host. You can also change the relative path binding of each file, so that any given number of remote URLs can map to the same local client install directory. This all required a somewhat extensive storage system for the Wummer, so I chose to use an sql server ce database, which keeps track of all the projects and files and hosts etc. of every probject you've ever published using the Wummer. In addition to being able to react property to the new manifest files, the Web Updater will now also attempt to update itself by temporarily cloning it's own executable and launching it with the Web Updater's own manifest file specified. In this way the Web Updater sort of "cheats", using a copy of itself to update itself, which I thought was cute. There are a few small but important touches to add to the Web Updater before it's ready for prime time, right now I've got the XNA Content Assistant performing updates with it and it's working pretty well, it's just not quite as elegant as I would like yet (currently there is much shutting down and restarting of programs during an update process which, while automatic and not necessarily cumbersome to the user, is unprofessional looking and some of it can be avoided). At some point I would like to consolidate all this into an "xnamachine software portal" application, which installs the prerequisites & runtimes on your PC (such as the Visual C++ redist for XNA games, .net 3.5, sql server ce, and provide convenient links to the XNA redist & DirectX web installer, which are easier for the user to just run themselves at this time). That way, there would only ever be 1 thing you would ever have to "install" from xnamachine.com in order to use anything I release. The portal would be an updatable application launchpad that provides links to whatever I make available; the Wummer, the XNA Content Assistant, templates for Visual Studio, XNA games, whatever. Such a thing would not be very difficult to make so I may go ahead with that as a software distribution plan, unless I think of some horrible drawback to doing it that way.
 | 5/24/08 |
The core of the Web Updater program is complete; it can now connect to web servers, obtain wum.xml files, validate them against a public wum schema, perform a differential check against the locally installed files on the client and download the obsolete/missing files. After downloading it can now replace the files on the client via decompression (if the wummer tool had compressed them when publishing) or, just renaming them into place. My "wummer" publishing tool is finished, save a few UI nuances, and so together they have created a functioning publish/update circuit. The Web Updater still needs a few more things; certain disaster recovery scenarios still must be accounted for, like if it can't access files it's trying to update or it's connection drops while downloading. It also still needs the ability to accept command line arguments when it runs, and finally it needs the ability to re-launch the target application it's updated. So I guess it's about 85% complete. Here it is, dutifully "updating" a bunch of nonsense files. I added the little treeview to it this evening, just for fun.
 | 5/20/08 |
So the XNA Content Assistant is largely finished and I wanted to distribute it using some kind of web update model, to make it easier for all of you to update the Assistant in the future. So I built a little update functionality into the Assistant under the Visual Studio ClickOnce model. ClickOnce is really neat and very easy to use, but unfortunately for the XNA Content Assistant it is unacceptable. The problem is that you can't effectively launch a ClickOnce application from another program e.g. via Process.Start while passing command line arguments. At best, you can submit a query string to a web-based application, but having the Assistant be entirely web based is not acceptable. The Content Assistant must be installed on the local machine and must be callable via command line with arguments. Therefore I abandoned the ClickOnce model and for the past couple days I've been crafting a web update system. This is something I will require anyway, to allow updates to my future XNA applications, so it's somewhat of an inevitable project. The Web Updater does its best to be somewhat generic; in a nutshell it just needs to know the URL of your application's "wum.xml" file (Web Updater Manifest), a simple xml file which describes the current files available on the update server (name, size, last update, etc). The Web Updater grabs the wum and checks it against whatever application it's updating on the local machine, and updates files as necessary. To that end, now I'm in the process of writing a companion tool for wum publishing called the Wummer. The Wummer is for developers, we point it at our Release folder (or, whatever you want to publish), and the Wummer uses an IO.CompressionStream to publish your application to your web host as .gz files, creating the wum.xml file for you (an otherwise tedious task). So I've been pretty busy working on all this lately, juggling work and 3 of my own little mini-projects! I believe these will all be helpful tools though and I hope to have them finished up pretty soon.
|