After a year of not using XNA creator's club and being generally morally opposed to the whole concept I decided to cancel it. Long story short this requires contacting xbox support (weeee). The only truly annoying part is how hard it is to find out this is what you must do and what the phone number is you must call.
It seems borderline unethical to not have a mechanism for canceling your account that is as easy as signing up.
It occurred to me while debugging my 3d camera that rotations are far to rotatey. R^T = R^-1 = R(-a) which means if you have a bug it can be confusing and potentially work to some degree even though really your code is completely crazy. In this case I was uploading rotations into opengl that were row major when it is in fact column major. Another amusing thing is if your rotation is several rotations such as R = r(a)r(b)r(c) then R^-1 = r(c)^-1 * r(b)^-1 * r(a)^-1 which means your rotations are now going to be done in a different order in the opposite directions.
I would also like to thank my marvell yukon network card for failing at life. It was trying to offload checksum calcs in vista but doing a worse job than my CPU. So much so that it was causing team fortess 2 to be inoperable. Luckily these things can be adjusted.
I am trying my luck with embedded IronPython 2 using the DLR so I thought I would share some of the steps to make that happen.
Prereqs:
These all come from the IronPython2 beta 1 release--and yes you need all of them. Failing to add IronPython.Modules.dll as a reference results in strange errors when trying to get the scripting engine which can be confusing.
The interface to IronPython and presumably other DLR languages is through the Microsoft.Scripting.Hosting.ScriptEngine class. There seems to be about a billion ways to get the engine here is what worked for me:
ScriptEngine engine;
engine = PythonEngine.CurrentEngine;
This gets/creates the ScriptEngine for IronPython. Next we create a Microsoft.Scripting.Hosting.ScriptScope which allows for variables to be bound on the embedder's end before the script is run. It also can be inspected after the script is run.
ScriptScope scope = engine.CreateScope();
Now all that is left is to load the script woooo. Doing this creates a Microsoft.Scripting.Hosting.ScriptSource object which can have fun things done to it.
ScriptSource source = engine.CreateScriptSourceFromFile("myScript.py");
source.Execute(scope);
This loads a script and then executes it using the scope that was created. The contents of the scope can be examined afterwards like I said which can be useful if you want to create factories that return an extended C#/CLR class that can then be used like normal.
TacticsGame game = scope.GetVariable
This gets the global "game" form the script. In order for this to work right you need to add the assembly references to your script. This can be done in two ways. First you can do it the normal way from inside the script:
import clr
clr.AddReference("MyAssembly.dll")
This works but its kind of annoying if MyAssembly.dll is actually the same assembly that the script is being hosted in or some other assembly that is known. Another way is to call engine.Runtime.LoadAssembly and feed it assemblies it should know about. See System.Reflection.Assembly for some ways of getting these assemblies.
Hopefully this works a bit better than boo did!
Beware of older XNA code using code created by the new project templates! The newer code sets the root directory of Content to "Content/" which breaks all my old code and was very confusing. Which leaves me wondering if they are going to include that as the default why not change it in the class! Blargg. Now any "game libraries" which have content that gets loaded have to worry about what the RootDirectory setting is at unless they use their own ContentManager.
Having an easily data driven method for customizing style information can be invaluable for building nice user interfaces. For special purpose user interfaces like games it is even more important. Designers need to be able to easily skin and customize different UI elements with out having to alter source code.
class Style {
public object GetValue(IStyleable target,
string propertyName);
public void SetValue(StyleSelecter selecter,
string propertyName, object value);
}
Just like in CSS a common way to refer to elements is needed. I used StyleID, a set of Classes and a Type to replicate the familiar id,class,elementType trio. This is formulated in a simple interface:
interface IStyleable {
string StyleID { get; }
ICollection<string> { get; }
string StyleType { get; }
}
A predicate for if a certain property definition applies is needed:
abstract class StyleSelector {
public abstract bool Matches(IStyleable target);
}
Every selector must at the very least support the ability to find a property by an O(n) search--this is what the Matches method is all about. Finding a property consists of a search over a list property definitions (StyleSelector,name,value). If a definition's name matches and StyleSelector.Matches is true then the search is terminated and value is returned as the value for that property.
In order for the cascading part to make any sense an ordering of property definitions needs to be defined. CSS solves this problem with the notion of specificity. Properties with more stringent criteria for being applied are allowed to float to the top and are used over the more generic definitions.
For my purposes I organize things simply by id > classes > type > *. So selectors that specify the id of its target are examined first. This conveniently allows for property searches to be culled to smaller sets that must be visited. Hashtables for each of these categories can be constructed to speed up search times so that for example (id,name) is indexed. This reduces linear searching only to custom and other miscellaneous selectors.
Aggregated selectors can be formulated based the AND logical operator. Since AND is commutative the selector can be rummaged through for any sub-selectors that are indexable. This can then be used as criteria for which index the aggregation should be inserted into. For example #myButton:hover can be inserted into the id indexing table since it contains an id selector.
I will probably post the code to this and the rest of my GUI toolkit when I am done / bored with it.
I mentioned I would talk about a domain specific language for game rules so I will but first a rant on why the term DSL is silly and some discussion on what a game rule itself will be.
Like any good acronym one day you wake up and it is as if while you were sleeping everyone got together and decided to surprise you the next day. Suddenly people realized they could make their own languages to solve specific problems and that this was now the neatest thing since sliced bread and other suitably neat cliches.
It is not that I am opposed to them. I just find it appallingly annoying how computer science and the software industry is often reduced to fads. It is as if all the people who slept through their compilers courses (really when else are you going to get a nap?) suddenly realized that this information was actually useful. DSLs don't solve all of your problems--but being smart and knowing the theory behind them will transform them into useful tools. I suggest picking up the dragon book and books on automata and language theory.
When playing games generally there is a set of rules to play by. These usually follow as consequences for some action the player does. These rules can also be the consequences of actions by other rules. Such as a player moves his piece on a board game and receives 5 points. He already has 10 and it only takes 15 to win lets say. The rule for winning was based off an action from another rule (gaining 5 points).
A game rule is action and then a consequence or more formally a predicate and some function that changes the course of game play somehow. R = (P(s),F(s)) So to apply a rule P(s) must be satisfied. Then s := F(s). Of course fashioning this into an actual usable system will require more work which I will save for next time.
While designing the class that manages my game objects the other night on a project I came across an interesting pattern. Using the visitor pattern with a mediator to add objects.
interface IRenderable {
public void DrawMe();
}
class Renderer {
public void Add(IRenderable renderable);
public void Remove(IRenderable renderable);
}
This is normal looking code for most applications. The power of being able to add random things that can be drawn is very useful. There are several problems with this first it can be important what order things are rendered when drawing 2d and 3d graphics. Also for the purposes of batching it may be very important to group like objects together.
These two problems can make things somewhat messy. Its possible to overcome them naturally. For instance we could include an integer that describes the order which renderables are to be drawn and sort them that way. For batching each renderable could queue it self up for rendering and then after a certain number of objects are in the queue or if it needs to be flushed for example if we are done rendering. Of course the batcher would have to somehow register it self with the renderer also since presumably only the renderer knows when its done drawing and any retained style buffers need to be flushed.
There is a simpler way which at first may seem silly and that is to have the objects register themselves at the request of the renderer--basically the visitor pattern.
interface IRenderable {
public void DrawMe();
public void Add(Renderer renderer);
public void Remove(Renderer renderer);
}
class Renderer {
public void AddSpecialDohicky(Dohicky dohicky);
public void RemoveSpecialDohicky(Dohicky dohicky);
public void Add(IRenderable renderable) {
renderable.Add(this);
}
public void Remove(IRenderable renderable) {
renderable.Remove(this);
}
}
This allows for all sorts of interesting behavior. Also IRenderable could still support a basic one size fits all DrawMe() call if needed. Another side effect of this is that the Dohickys don't have to actually to be implementers of IRenderable which leaves things wide open for using composition instead of inheritance.
Naturally the draw back is that the Renderer is coupled with Dohickies but it makes it much easier to add optimizations to your renderer since it for example can cross coordinate with other objects being rendered so you do not have a bunch of objects operating in a vacuum simply for the sake of proper OO design. Like everything its all a matter of trade offs.