chronoclast

Recursion in Linq

2011-09-23T15:59:00.001-06:00

Being able to traverse a tree structure can be very handy, or flatten a tree to a list. Linq doesn't offer this out of the box, but it's a fairly straightforward extension to add.

/// <summary>
/// Recusively traverse a tree structure
/// </summary>
/// <typeparam name="T"></typeparam>
/// <param name="collection"></param>
/// <param name="childrenSelector">Child navigation property on T</param>
/// <returns>Flattened collection</returns>
public static IEnumerable<T> Traverse<T>(this IEnumerable<T> collection, Func<T, IEnumerable<T>> childrenSelector)
{
    foreach (var item in collection)
    {
        yield return item;

        var children = childrenSelector(item);

        if (children != null)
        {
            foreach (var child in Traverse(children, childrenSelector))
            {
                yield return child;
            }
        }
    }
}

The source is pretty much straight from here, with an extra check against null children collections.

Entry Extensions

2011-07-07T14:14:00.000-06:00

Entity Framework 4.1 CodeFirst is quite a bit of fun to use, but tucks away some of the useful database functionality. One useful thing is to know if a property on a database entry has been changed since it was loaded. DbEntityEntry exposes OriginalValues and CurrentValues, but actually comparing the two can be streamlined with Expressions.

DbEntityEntry.PropertyChanged

public static class DbEntityEntryExtensions
{
    /// <summary>
    /// Determine if a property has changed since being loaded.
    /// <remarks>
    /// If comparing a property that is a sub-object against another instance, it will always throw true (changed).
    /// Complex properties should implement IEquatable to properly handle how equality is determined.
    /// </remarks>
    /// </summary>
    /// <typeparam name="TEntity"></typeparam>
    /// <typeparam name="TProperty"></typeparam>
    /// <param name="entity"></param>
    /// <param name="expression"></param>
    /// <returns></returns>
    public static bool PropertyChanged<TEntity, TProperty>(this DbEntityEntry<TEntity> entity, Expression<Func<TEntity, TProperty>> expression)
        where TEntity : class
    {
        var name = ((MemberExpression)expression.Body).Member.Name;

        return !entity.CurrentValues.GetValue<TProperty>(name).Equals(entity.OriginalValues.GetValue<TProperty>(name));
    }
}

Determining if a loaded POCO property has changed is pretty easy:

var o = MyDbContext.TestClasses.Find(1);
o.Id = 2;

var changed = MyDbContext.Entry(o).PropertyChanged(c => c.Id);   // True

This works fine for primitive types such as int, string and float. However, if your property is another object, it won't work. This is because at it's heart, we're calling Equals.


class TestClass
{
    public int Id { get; set; }
}

var a = new TestClass { Id = 1 };
var b = new TestClass { Id = 1 };

var equal = a.Equals(b);  // False!

To show this with EF 4.1...


class TestClass
{
    public int Id { get; set; }
    public AssociationClass Association { get; set; }
}

class AssociationClass
{
    public int Id { get; set; }
}

// Assume that the stored o.Association has an ID of 1
var o = var o = MyDbContext.TestClasses.Find(1);

// Set to a new, identical instance of the class
o.Association = new AssociationClass { Id = 1 };

// This is supposed to be false.  The database holds that TestClass:1
// is associated with AssociationClass:1.  However, since the objects
// are different, Equals will return false, and PropertyChanged will
// return true - thinking that the association has changed.
var changed = MyDbContext.Entry(o).PropertyChanged(c => c.Association);   // True (wrong)

There is probably a way to check if the property is an association and check possible entity keys, but that's for another time.

EntitySystems Part 3: EntityCollections

2011-04-19T21:50:00.001-06:00

In part one we looked at the base for an Entity and EntityManager. In there we can create new entities and compose them of components. In part 2, we looked at actually storing components by their type.

When viewing an Entity System as a relational database, the component types are single table with the entity id as the primary key. Then entity represents a single joined row across multiple tables. Systems that consume entities will often rely on multiple component types. We could reference the component collections but that would require a lot of duplicate checking in each system to ensure that an entity contained all types it was looking for. Better to create a new type that tracks this for us.

EntityCollection

public sealed class EntityCollection : IEnumerable
{
    readonly EntityManager _manager;

    readonly Type[] _filter;
    readonly int _hashCode;

Each collection is composed a collection of types, so the first step is to store all of these types. These are used to make the hashcode for the collection. More explained in a bit.

    readonly SortedSet _sortedEntities;
    readonly Dictionary _entities;
    readonly IComparer _comparer;

To store entities in the collection, we use two different internal collections. An entity collection has two big requirements - O(1) lookup and sorting. The sorted collections in C# don't offer O(1) lookup time and a plain Dictionary can't be sorted. The solution - use two collections. Dictionary offers the fastest lookup and SortedSet offers the most consistent insert speed. The comparer is just that - an optional custom comaprer for sorted entries (think z-indexed sprites, etc...)

internal EntityCollection(EntityManager entityManager, Type[] types)
{
    _sortedEntities = new SortedSet();
    _hashCode = EntityCollection.GetHashCode(types, null);

    // Check that all types are really components
    if (!types.All(t => typeof(EntityComponent).IsAssignableFrom(t)))
    {
        throw new Exception("Type is not of IComponent - cannot filter.");
    }

    _manager = entityManager;
    _entities = new Dictionary();
    _filter = types;

    // Add any existing entites
    foreach (var entity in _manager)
    {
        if (MatchesFilter(entity))
        {
            Add(entity);
        }
    }
}

internal EntityCollection(EntityManager entityManager, Type[] types, Func comparer)
    : this(entityManager, types)
{
    // 
    var lambdaComparer = new Engine.Tools.LambdaComparer(comparer);

    _sortedEntities = new SortedSet(lambdaComparer);
    _hashCode = EntityCollection.GetHashCode(types, lambdaComparer);
}

internal EntityCollection(EntityManager entityManager, Type[] types, IComparer comparer)
    : this(entityManager, types)
{
    _sortedEntities = new SortedSet(comparer);
    _hashCode = EntityCollection.GetHashCode(types, comparer);
}

internal bool MatchesFilter(Entity entity)
{
    return _filter.All(t => entity.Is(t));
}

The constructor and most of the manipulations are internal. EntityCollections are not meant to be added to and removed from by the game classes. Systems that consume EntityCollection should only be iterating the collection. Use the EntityManager to manipulate entities - they will be automatically added/removed from EntityCollections.

Upon creation, the entity collection will search every entity and determine if it fits into the collection. Later as new entites are created or components removed, the EntityManager is responsible for notifiying collections about updates.

Seems like a good point to discus creating the hash code.

public static int GetHashCode(Type[] types, IComparer comparer)
{
    var hashCode = 0;

    // Hashcode is build off the filters, independent of their order
    for (int i = 0; i < types.Length; i++)
        hashCode += types[i].GetHashCode();

    // Add on comparer hashcode if set - comparers should overload their
    // own GetHashCode to return a unique constant.
    hashCode += (comparer == null) ? 0 : comparer.GetHashCode();

    return hashCode;
}

Different consumers of EntityCollections may draw upon the same types. Rather than have multiple collections representing the same types, we provide a mechanism to cache them in the EntityManager (where they're built). The hash code is built from the types being monitored as well as the comparer.

public delegate void EntityAddHandler(Entity entity);
public delegate void EntityRemoveHandler(Entity entity);

Systems consuming the collection like to be notified when the collection changes.

internal bool Add(Entity entity)
{
    // Check if the collection already contains this
    if (_entities.ContainsKey(entity.Id))
        return;

    // Ensure that the entity matches the filter
    if (!MatchesFilter(entity))
        return false;

    _entities.Add(entity.Id, entity);
    _sortedEntities.Add(entity);

    if (_entities.Count != _sortedEntities.Count)
        throw new Exception("EntityCollection internal collections don't match.  Probably a bad comparer for SortedSet.");

    // Notify any listeners that a new entity was added
    if (OnEntityAdd != null)
    {
        OnEntityAdd(entity);
    }
}
internal void Remove(Entity entity)
{
    // Check if the collection actually contains the entity
    if (!_entities.ContainsKey(entity.Id))
        return;

    // Notify any listeners that an entity was removed
    if (OnEntityRemove != null)
    {
        OnEntityRemove(entity);
    }

    _sortedEntities.Remove(entity);
    _entities.Remove(entity.Id);
}

Finally, Add and Remove do just that as well as notifiy any listeners. Notification is used to create or release resources or do extra initialization such as loading assets

There's a few more utility functions to be found in the full source.

EntityManager

The EntityManager needs to have a few changes made to be able to present EntityCollections. First, add the internal collection storage and add two internal functions to handle collections.

readonly Dictionary _collections;

internal void RemoveFromCollections(Entity e)
{
    // Remove entity from any collections
    foreach (var collection in _collections.Values)
    {
        collection.Remove(e);
    }
}

internal void RemoveFromCollections(Entity e, Type t)
{
    // Remove entity from any collections
    foreach (var collection in _collections.Values)
    {
        if (collection.ContainsType(t))
        {
            collection.Remove(e);
        }
    }
}

Second, we actually call these where appropriate.

public Entity Create(IEnumerable components)
{
    ...
    AddToCollections(e);
    ...
}
public void Remove(Entity entity)
{
    RemoveFromCollections(entity);     // Call this one first
    Components.Remove(entity.Id);
    _entities.Remove(entity.Id);
}

And lastly, we need way to actually get the collections.

public EntityCollection Get(params Type[] componentTypes)
{
    var hashCode = EntityCollection.GetHashCode(componentTypes);

    if (!_collections.ContainsKey(hashCode))
    {
        _collections.Add(hashCode, new EntityCollection(this, componentTypes));
    }

    return _collections[hashCode];
}

public EntityCollection Get(Type[] componentTypes, IComparer comparer)
{
    var hashCode = EntityCollection.GetHashCode(componentTypes, comparer);

    if (!_collections.ContainsKey(hashCode))
    {
        _collections.Add(hashCode, new EntityCollection(this, componentTypes, comparer));
    }

    return _collections[hashCode];
}

Using Collections

public MySystem(EntityManager manager)
{
    // Get the EntityCollection
    var entities = _entites = manager.Get(
        typeof(Foo),
        typeof(Bar));

    entities.OnEntityAdd += LoadComponent;
    entities.OnEntityAdd += UnloadComponent;
}

public void Draw(GameTime gameTime)
{
    foreach (var entity in _entities)
    {
        // Draw
    }
}

public void LoadComponent(Entity e)
{
    e.As().Texture = _contentManager.Load(e.As().AssetName);
}

public void UnloadComponent(Entity e)
{
    // Unload component
}

Consuming collections is pretty straight forward. The filter is created, events set, and it's good to go.

Sorted Collection Speeds

2011-01-04T21:30:00.006-07:00

C# and .Net offer a couple different sorted classes. Arrays can be sorted, sure, but I'm looking at ones that offer some form of insertion sort. For this, I'm looking at these three classes:

Collection	Insert(Random)	Insert(Sorted)	Remove	Indexed Fetch
SortedDictionary	O(log n)	O(log n)	O(log n)	O(log n)
SortedList	O(n)	~O(log n) ?	O(n)	O(log n)
SortedSet	O(log n)	O(log n)	O(log n)	-

Runs

SortedDictionary and SortedList using custom comparer

          Runs    Dictionary    SortedDict    SortedList     SortedSet
Insert
         50000    26,668          460,026      3,823,552     210,012
         60000    33,335          566,699      5,513,648     253,347
         70000    53,336          683,372      7,717,108     326,685
         80000    53,336          863,382     12,737,395     340,019
         90000    50,002          896,718     13,194,088     410,023
        100000    83,338        1,066,728     19,034,422     460,026
        110000    90,005        1,156,733     22,917,977     526,697
        120000    90,005        1,306,741     27,244,891     650,037
Fetch
         50000    13,334        313,351       293,350
         60000    13,334        550,031       363,354
         70000    16,667        506,695       463,359
         80000    23,334        570,032       520,029
         90000    26,668        666,705       610,034
        100000    26,668        753,376       703,373
        110000    30,001        870,049       796,712
        120000    30,002        976,722       896,718

Part of the problem comparing all these collections is that don't compare in the same way. SortedDictionary and SortedList both default to comparing unique keys. If you can guarantee each item in the collection has a unique sorting key, then they work great. If you require more complicated sorting, such as comparing against a non-unique value within the TValue, then you add in the extra overhead of storage and lookup of the base collection. SortedSet works better for comparing TValues.

SortedDictionary and SortedList using default key sorter (insert in order)

          Runs    Dictionary    SortedDict    SortedList     SortedSet
Insert
         50000        30,003       246,691       130,005       160,013
         60000        33,336       356,702       126,679       273,360
         70000        36,670       353,368        73,340       310,031
         80000        56,672       413,374        80,008       416,708
         90000        66,673       466,713        90,009       486,715
        100000        70,007       503,383       103,343       576,724
        110000        80,008       553,388       113,344       666,733
        120000       103,343       646,731       180,018       653,398
Fetch
         50000        10,001       123,345        73,340
         60000        13,334       160,016        90,009
         70000        16,668       186,685       106,677
         80000        16,668       233,356       130,013
         90000        20,002       246,691       140,014
        100000        20,002       266,693       156,682
        110000        23,335       310,031       190,019
        120000        23,335       330,033       190,019

Using the default key comparer in order, SortedList performs optimally.

SortedDictionary and SortedList using default key sorter (insert in reverse order)

          Runs    Dictionary    SortedDict    SortedList     SortedSet
Insert

         50000        30,000       273,333    23,233,332       210,000
         60000        30,000       293,333    28,999,999       276,666
         70000        46,666       350,000    29,679,999       343,333
         80000        50,000       433,333    60,493,330       370,000
         90000        50,000       526,666    49,526,662       500,000
        100000        56,666       560,000    79,496,663       600,000
        110000        56,666       716,666   114,516,661       640,000
        120000        63,333       753,333    98,069,995       720,000
Fetch

         50000        10,000       123,333        73,333
         60000        13,333       150,000        93,333
         70000        13,333       176,666       106,666
         80000        20,000       200,000       123,333
         90000        20,000       243,333       140,000
        100000        23,333       263,333       153,333
        110000        26,666       293,333       173,333
        120000        30,000       323,333       186,666

Do the same run only with reversed keys and SortedList falls apart. SortedDictionary is most consistent with key comparisons (SortedSet still comparing values in these runs).

Notes

These are an average of three runs each. I'm not sure if I'm doing something wrong for the SortedList inserts or not - it's way above everything else. Otherwise for purely random data inserts, SortedSet seems to be the most consistent. If the data is mostly pre-sorted, then SortedList will beat them all, but then bombs with random data. Indexed fetch isn't available for SortedSet so it's not shown. SortedDictionary and List both perform and scale similarly with a custom comparer.

Repository for test code

Entity Systems Part 2: Components

2010-12-24T22:14:00.005-07:00

Entities are essentially disconnected collections of components. Or as disconnected as possible. Some components depend on others to mean anything in game, but can be processed individually. We should start looking at how components are stored and associated with entities.

It's useful to think of each component type having it's own database table. Each row then is an instance of that component type. The primary key is the entity key.

Components are just data containers so there's no standard functionality across all of them. The only functionality they should contain are things like operator overloads, type conversions, or internal data manipulation (getters, setters). A few will have events to indicate that a value has crossed a threshold for example an OnDied event when int Health == 0

I've found it useful for the component to have on small bit of common functionality - the owner. My original design was an empty interface, but this didn't provide a link back to the owning entity unless the component type specified it. I added an abstract base that implemented this.

IEntityComponent

public interface IEntityComponent
{
    ulong Owner { get; set; }
}

EntityComponent

public abstract class EntityComponent : IEntityComponent
{
    private ulong _owner;

    public virtual ulong Owner
    {
        get
        {
            return _owner;
        }
        set
        {
            if (_owner == 0)
                _owner = value;
            else
                throw new FieldAccessException("Cannot reset component to different entity.");
        }
    }
}

And that's it. Just an interface so our component managers can enforce some semblance of type control.

IComponentManager

This is really the meat of components - holding and manipulating typed collections. I use a base interface to make it easier to swap out different implementations.

interface IComponentManager : IEnumerable<Type>
{
    void Add<T>(ulong entityId, T o) where T : EntityComponent;
    void Add(ulong id, IEnumerable components);

    void Remove(ulong id);
    bool Remove<T>(ulong id) where T : EntityComponent;

    T Get<T>(ulong id) where T : EntityComponent;

    bool Contains(ulong id, Type t);
}

The interface specifies the functionality to add components singly or as a list. It can remove a whole entity or a single type from an entity. Finally, it can retrieve components.

This is not meant to be a forward facing class. It's designed to be internal to the EntityManager. It provides the mechanisms for the entities to report about themselves.

Default ComponentManager

The default ComponentManager is mostly just a wrapper for a dictionary that conforms to the interface.

internal class ComponentManager : IComponentManager
{
    ...

    Dictionary<Type, Dictionary<ulong, EntityComponent>> _components;

    ...
}

Conclusion

Everything up till now has been fairly straightforward. Things get more complicated when we start creating systems that require multiple component types. To put it in SQL terms again, how do we write a JOIN query? Well, that's for part 3.

Entity Systems Part 1: Entity and EntityManager

2010-12-24T15:26:00.003-07:00

The current state can be found in changeset e73319ab32fd.

Entity

First things first, an entity is essentially an id number. There are a few useful utility functions that can be encapsulated inside of it, but embedding too many will cause problems down the line. Most of this is duplicated in C# from Adam Martin's post here.

Entities know where to find the component store to add and retrieve associated components. Arguments can be made about storing basic things like position and orientation in the entity, but as will be shown later, systems don't hold references to entities, just lists of components to operate on.

/// <summary>
/// Basic entity class.  Consists of an id and a list of components.  Ideally it
/// should only be an id, but it's useful to be able to know what components it
/// is built of and to find them quickly.
/// </summary>
public class Entity
{
    readonly ulong _id;

    public ulong Id
    {
        get
        {
            return _id;
        }
    }

    /// <summary>
    /// Static instance of the entity manager.  Entities should be able to add 
    /// themselves to the manager on creation - saves having to remember to do this.
    /// </summary>
    public static EntityManager EntityManager { get; set; }
        
    public Entity(ulong id)
    {
        _id = id;

        if (EntityManager == null)
            throw new ArgumentNullException("Entity manager cannot be null.");

        EntityManager.Add(this);
    }

    /// <summary>
    /// Add a new component to the entity
    /// </summary>
    /// <typeparam name="T"></typeparam>
    /// <param name="component"></param>
    /// <returns></returns>
    public Entity Add<T>(T component) where T : IComponent
    {
        EntityManager.Components.Add(Id, component);
        return this;
    }

    /// <summary>
    /// Return this as a component
    /// </summary>
    /// <typeparam name="T"></typeparam>
    /// <returns></returns>
    public T As<T>() where T : IComponent
    {
        return EntityManager.Components.Get<T>(Id);
    }
}

EntityManager

The manager is responsible for creating and tracking loaded entities and assigning them ids. Entity ids are transient - rebuilt every load. Template ids persist between game runs. Currently I have two Get<T> functions that aren't implemented - still thinking if those are actually needed or not. Leaning towards no. Not show here are the details of the ComponentManager - that's another long post.

public class EntityManager
{
    static ulong _nextAvailableId;

    Dictionary<ulong, Entity> _entities;

    /// <summary>
    /// Store of all loaded components, indexed by type and entity id
    /// </summary>
    public ComponentManager Components { get; set; }

    public Entity this[ulong index]
    {
        get
        {
            // TODO: Should we be doing this?
            // If we're looking for a non-existant entity, go ahead and add it
            if (!_entities.ContainsKey(index))
            {
                Add(new Entity(index));
            }

            return _entities[index]; 
        }
    }

    public EntityManager()
    {
        _entities = new Dictionary<ulong, Entity>();
        _nextAvailableId = 0;
        Components = new ComponentManager();

        // Check that entities know this is the manager
        if (Entity.EntityManager == null)
        {
            Entity.EntityManager = this;
        }
    }

    /// <summary>
    /// Return all entities containing a particular type of component
    /// </summary>
    /// <typeparam name="T"></typeparam>
    /// <returns></returns>
    public IEnumerable<Entity> Get<T>() where T : IComponent
    {
        throw new NotImplementedException();
    }

    /// <summary>
    /// Return all entities containing all of the parameter types
    /// </summary>
    /// <typeparam name="T"></typeparam>
    /// <returns></returns>
    public IEnumerable<Entity> Get(params Type[] componentTypes)
    {
        throw new NotImplementedException();
    }

    /// <summary>
    /// Add an existing entity to this
    /// </summary>
    /// <param name="entity"></param>
    public void Add(Entity entity)
    {
        if (!_entities.ContainsKey(entity.Id))
        {
            _entities.Add(entity.Id, entity);
        }
    }

    /// <summary>
    /// Create and return a new entity
    /// </summary>
    /// <returns></returns>
    public Entity Create()
    {
        _nextAvailableId++;

        // Ensure that the next available id is, in fact, available
        while (_entities.ContainsKey(_nextAvailableId))
        {
            _nextAvailableId++;
        }

        return new Entity(_nextAvailableId);
    }

    /// <summary>
    /// Remove an entity
    /// </summary>
    /// <param name="entity"></param>
    public void Remove(Entity entity)
    {
        Components.Remove(entity.Id);
        _entities.Remove(entity.Id);
    }

    /// <summary>
    /// Remove an entity
    /// </summary>
    /// <param name="entity"></param>
    public void Remove(ulong id)
    {
        Components.Remove(id);
        _entities.Remove(id);
    }
}

Currently entity id's are just ulong's incremented for every entity. Theoretically it's possible to reach the max, but even creating one new entity every millisecond, it would take over 500,000,000 years to reach the max. ulong's are really big. Even just a plain int would give us 2,147,483,647 possibilities (positive ints only).

Sample Usage

_manager = new EntityManager();

_manager.Create()
    .Add<Transform>(new Transform() { })
    .Add<Renderable>(new Renderable() { });

var transform = _manager[1L].As<Transform>();

Nothing really special here - most of the work is done in the ComponentManager. That's coming up next.

Entity System Test Project

2010-12-18T23:15:00.002-07:00

Entity Systems are a great way to build up game objects, but a significant thought shift from traditional OOP inheritance trees. Simply getting started is one of the bigger challenges as well as being aware of, and avoiding, functionality creep into entity and component objects.

Much has been written on entity systems, although most of it is at a very high level overview of what they are. There are some examples in a few books, but I'm cheap. Browsing the net though, here's a quick list of some of the best examples and most helpful collections:

Scott Bilas's 2002 GDC Presentation - From 2002, but still very relevant. He discusses the the advantages of entity systems (game objects as he calls them) and a few details of how they implemented them in Dungeon Siege.
Adam Martin's series on ES - Parts 2, 3, and 5 are especially good foundation material. There's a lot to absorb here.
Adam Martin again implements ES on Android - some create implementation details. Much more explained in the comments.
Amit's Epic Game Programming Links - Here's where I got started into this. Also, he has a lot of other wonderful things.

Step 1

I plan on stepping away from OTD for a little while here. It has a ton of code behind it, a lot which has been sitting there for over a year without refactoring. I'm starting a much smaller project to focus on entity systems for a while as well as clean up some of my engine code.

Amoebal

Source code is up on BitBucket. It's still very, very early, but a decent foundation to build on. Further posts will detail the process of creating an entity system in XNA and C# as well as try to explain my reasoning behind a few things.

Questions to deal with

How will lists of components be sent to systems? Big dictionaries?
How will component types be cached and then pruned? Entities can register components on add

Mesh Levels

2010-12-11T15:22:00.004-07:00

Got some various debugging info in place and finally decided to get some stats on the various levels of the map build.

Build Data
Level	Cells	Avg. Distance	Time (ms)
0	12	1.051462	56
2	92	0.396275	243
4	252	0.2403322	1264
6	492	0.1721796	3594
8	812	0.1340831	11187
10	1212	0.1097718	19649
12	1692	0.09291888	34545

The cells increase at a slight exponential rate while the time at a much steeper rate. The generating code could be a lot more optimal, and the vast majority of this time is spent in the mesh generate. Each cell is locally subdivided down three levels. There are probably a lot of optimizations that could be run, and a couple of the loops could be consolidated. Over time I've managed to optimize most loops to just n * n.neighbors. I've opted more for understandable code (as much as possible) vs highly optimized loops. Considering that all of this is done once at compile time, it's not a big deal really.

Graphs

Cells

Time

Distance

IEnumerable.ToString()

2010-12-03T09:45:00.004-07:00

One useful thing is to be able to concatenate IEnumerable's into a string for printing. A couple extension methods take care of this.

public static string ToString<T>(this IEnumerable<T> collection)
{
    return collection.ToString(",");
}

public static string ToString<T>(this IEnumerable<T> collection, string separater)
{
    return String.Join(",", collection);
}

public static string ToString<T>(this IEnumerable<T> collection, Func<T, object> field) where T : class
{
    return collection.ToString(",", field);
}

public static string ToString<T>(this IEnumerable<T> collection, string separater, Func<T, object> field) where T : class
{
    return String.Join(separater, collection.Select(field));
}

But couldn't we just use String.Join as the extension methods are? Sure, but this is more fun and provides a more logical response to ToString() as well as more control over objects with anonymous functions.

var testList = new List<SimpleObject>()
{
    new SimpleObject() { Id = 1, Name = "asdf" },
    new SimpleObject() { Id = 2, Name = "qwer" },
    new SimpleObject() { Id = 3, Name = "zxcv" },
};
var s = testList.ToString<SimpleObject>(",", c => c.Id);

One caveat, the base IEnumerable.ToString() is still there, and simple prints out something like System.Collections.Generic.... Not what we expect. To call the basic extension method, we have to specify it with the type parameter:

var fail = testList.ToString();  // Ruh-roh!
var works = testList.ToString<SimpleObject>();  // Woot!

Rabbit Hole

2010-10-26T21:18:00.002-06:00

Well, almost 4 months later and a ton of work and I think it's time to scrap cell blending.

Heightmaps still work and I will probably keep those, but getting cell blending to look good will take just too much work. Leaving the art style simpler will help preserve the board game feel. Cell borders may get some rounding if I can figure out an easy way.

Edit:

Nope, not scrapping texture blending. Looks much better if the influence radius is set smaller. Screenshots later as I'm working on loading heightmaps from the saved map file. Oceans will have a sandy texture on the grid and a separate inner sphere for the actual water.

Entity Framework and Max Field Length

2010-10-08T16:41:00.006-06:00

Being able to check the maximum length of an entity field can be incredibly useful. Later, I'll be exploring how to automatically validate entity lengths, but for the moment we just need to find them. Worry about using them for later post.

Entity Framework 4 Data Models, edmx files, provide all the database metadata, but it takes a bit of finding. First, you need a valid ObjectContext. I'm using the Repository/UnitOfWork pattern and my UnitOfWork acts as a wrapper around the ObjectContext that gets passed into the repositories. At the moment the functionality to check length is in the UnitOfWork, but can reasonably be moved anywhere that has access to the database context, such as the repository base. Might make more sense there even.

Anyways, to the code. There are several examples around the web and they provided starting points on where to find the correct metadata. In the end, the code is actually quite short.

/// <summary>
/// Find the maximum length of an entity field in this context
/// </summary>
/// <param name="field"></param>
/// <returns></returns>
public int Length<TEntity>(string field)
{
    var item = Context.MetadataWorkspace.GetItem<EntityType>(typeof(TEntity).FullName, DataSpace.CSpace);
    return (int)item.Properties[field].TypeUsage.Facets["MaxLength"].Value;
}

I leave error checking to be handled by the caller. The only errors that should be thrown are if the Context is invalid, ArgumentExceptions if you send an invalid entity, field name, or perhaps most importantly, you try to run this against a non-string type like int or bool.

To explain a bit of the code, you need access to the MetadataWorkspace. I believe that ADO.Net and Linq to SQL all create this object and provide access to it one way or another. From there, you can get EntityType metadata. Other examples online pulled all the entities, but that isn't really necessary. The GetItem function works fine. If the TEntity typ is invalid, this function will throw an error. Once we have the EntityType item, we have the full info about that particular tracked entity, and within the Properties, we can get field data. There are other Facets available depending on the data type. Strings contain these:

Nullable
DefaultValue
MaxLength
Unicode
FixedLength

So it would be pretty easy to rework this function to provide any one of those meta values.

The TEntity type should be a valid model type tracked by the context, and the field is just a property name. There's probably some fancy-dancy reflection way to eliminate the string here, but I haven't found it yet.

Calling the function looks something like this:

int length = _unitOfWork.Length<User>("UserName");

Again, placing this in the UnitOfWork might not make the best sense. Perhaps in a Repository which contains an actual ObjectSet would be a bit safer.

It should be noted that for other data types, int, bool, floats, etc., different Facets are available, and for some, trying to reference MaxLength will result in an exception being thrown. More information about the actual field type can be found in EntityType.Properties([field]).TypeUsage.EdmType. Greater error checking can, and probably shoud, be put in place.

LINQ and IEquality

2010-09-17T11:19:00.007-06:00

Linq provides several handy set functions - Union, Except, and Intersect. They even provide a way to override how equality comparisons are done by declaring a concrete IEqualityComparer.

When working with POCO objects though, it is quite cumbersome to have to provide comparers for every object. True, they could all implement an interface and go through a generic comparer, but a much easier option would be to allow anonymous functions to be defined. We need two things - a comparer class that takes delegates and some Linq extensions to make use of this.

Thankfully, Brendan Enrick already implemented a comparer that takes anonymous functions and runs them in IEqualityComparer.Equals()

/// <summary>
/// Generic equality comparer allowing lambda expressions
/// </summary>
/// <typeparam name="T"></typeparam>
/// <see cref="http://csharpfeeds.com/post/10941/LINQ_Your_Collections_with_IEqualityComparer_and_Lambda_Expressions.aspx"/>
public class LambdaComparer<T> : IEqualityComparer<T>
{
    private readonly Func<T, T, bool> _comparer;
    private readonly Func<T, int> _hash;

    public LambdaComparer(Func<T, T, bool> comparer) : this(comparer, o => o.GetHashCode())
    { }

    public LambdaComparer(Func<T, T, bool> comparer, Func<T, int> hash)
    {
        if (comparer == null)
            throw new ArgumentNullException("comparer");
        if (hash == null)
            throw new ArgumentNullException("hash");

        _comparer = comparer;
        _hash = hash;
    }

    public bool Equals(T a, T b)
    {
        return _comparer(a, b);
    }

    public int GetHashCode(T o)
    {
        return _hash(o);
    }
}

Now we can call this as so:

myCollection.Intersect(otherCollection, new LambdaComparer<PocoType>((a, b) => a.Id == b.Id));

Having to declare a new LambdaComparer every time can be further simplified by adding some new Linq extensions that handle creating a new LambdaComparer for us.

public static class LinqExtensions
{
    public static IEnumerable<T> Except<T>(this IEnumerable<T> first,  IEnumerable<T> second, Func<T, T, bool> comparer)
    {
        return first.Except(second, new LambdaComparer<T>(comparer));
    }

    public static IEnumerable<T> Union<T>(this IEnumerable<T> first, IEnumerable<T> second, Func<T, T, bool> comparer)
    {
        return first.Union(second, new LambdaComparer<T>(comparer));
    }

    public static IEnumerable<T> Intersect<T>(this IEnumerable<T> first, IEnumerable<T> second, Func<T, T, bool> comparer)
    {
        return first.Intersect(second, new LambdaComparer<T>(comparer));
    }

    public static IEnumerable<T> Distinct<T>(this IEnumerable<T> first, Func<T, T, bool> comparer)
    {
        return first.Distinct(new LambdaComparer<T>(comparer));
    }
}

This further simplifies the call and makes it a bit more elegant. We can do sets based on aribitary fields without having to declare a whole new comparison class.

myCollection.Intersect(otherCollection, (a, b) => a.Id == b.Id);
myCollection.Union(otherCollection, (a, b) => a.Name == b.Name);

Epiphanies

2010-08-25T10:55:00.005-06:00

So after four months of ever-so-slowly moving forward on cell blending, I had finally see the light at the end of the tunnel. Just in time to have a sudden inspiration on how to do it all easier (sort of).

The goal: enable heightmap and texture blending between cells.
It sounds innocent enough - just fine affected mesh vertices and blend away! Four months of slow work (broken by countless TF2 sessions and some monumental Minecraft bases), and I've finally got step 1 working. There's still some clean-up work on step 1, but that'll be easier and the motivation is now returning.

The problems: The previous major version did a couple things wrong. I got heightmapping and texturing working over the entire sphere using a Miller projection. This had potential, but lacked in several areas: the 'hexness' of the map was lost and it required a very, very high resolution texture to look decent.

I wanted to maintain the hex feel of the map, yet be able to blend heightmaps to create continuous mountain ranges, sea beds, and other land features. Each cell has the potential to align differently in UV space meaning that seams wouldn't match up easily like a flat 2d grid. The first idea was to add more texture channels to each mesh vertex:

Base cell UV's
Neighbor channel 1 (neighbors 1 & 3)
Neighbor channel 2 (neighbors 2 & 4)
Neighbor channel 3 (neighbors 3 & 6)
Optional detail channel 1 (micro detail - bumpmap, etc...)
Optional detail channel 2 (macro, miller projection - color shifts, shading...)

Then to write the HLSL shader to handle the custom vertex format...

Then to write all the testing tools to ensure that the mesh is being build correctly...

The testing tools allowed me to achieve a nice unwrap of the icosahedron mesh and from there to write a 2d-map importer... This step turned out very useful. I can open up Photoshop, set an indexed color palette, and draw the map over the top of an exported unwrap of the cell points, then read it back into the game.

Finally, the blending step. The problem lies in that each cell is independently textured. This will ensure better resolution when zoomed in without massive textures and help to maintain the hex board game feel. The first plan went something like this:

Create base cells
Build base UV coordinates as a single large hexagon or pentagon
Find and sort neighbor cells
Start building render mesh
- Subdivide each cell for the render mesh.
- Lookup neighbor mesh vertices 'affected' by each cell vertex.
- Take affected vertices appropriate texture channel (each vertex has 4+ texture channels - base, neighbor 1, 2, and 3) and align to the cell edge. This is the part that proved to take the longest and I've still got the texture blending ahead.

The epiphany here is to incorporate polar coordinates for better affected vertex lookup and UV texturing. Hexes bordered by a pentagon have some alignment issues with the pentagons along neighbor seams due to the pentagon's having different base angles. Switching to building mesh UV's off polar coordinates will solve this issue as well as some of the slight texture warping that will occur.

Edit:

Scrap that, polar's didn't work for helping with UV mapping. Things get too funky around the poles.

Random Picture

ASP.Net MVC ImageActionLink

2010-08-04T15:11:00.002-06:00

The default Html.ActionLink() only takes text, and I like doing icons often to save space for for aesthetics. Here's a simple helper that takes the image url and action as the only required parameters and C# 4.0's fancy new optional parameters for the rest. Doing all the various method overloads for ActionLink sounded like overkill.

/// <summary>
/// Returns an anchor element to the virtual path of the specified action with an image for the content
/// </summary>
/// <param name="html"></param>
/// <param name="imageUrl"></param>
/// <param name="action"></param>
/// <param name="altText"></param>
/// <param name="controllerName"></param>
/// <param name="routeValues"></param>
/// <param name="htmlAttributes"></param>
/// <returns>MvcHtmlString</returns>
public static MvcHtmlString ImageActionLink(
    this HtmlHelper html, 
    string imageUrl, 
    string action, 
    string altText = null, 
    string controllerName = null, 
    object routeValues = null,
    IDictionary<string, object> imageHtmlAttributes = null,
    IDictionary<string, object> htmlAttributes = null)
{
    MvcHtmlString link = html.ActionLink(
        "[replace_me]", 
        action, 
        controllerName, 
        routeValues, 
        htmlAttributes);

    TagBuilder builder = new TagBuilder("img");
    builder.MergeAttributes(imageHtmlAttributes);
    builder.MergeAttribute("src", imageUrl);
    if (altText != null)
        builder.MergeAttribute("alt", altText);
   
    return MvcHtmlString.Create(
        link.ToString().Replace(
            "[replace_me]",
            builder.ToString(TagRenderMode.SelfClosing))
    );
}

XNA 4 Beta

2010-08-02T18:47:00.003-06:00

Microsoft's been pushing Windows Phone 7 development quite hard for the past few months. The XNA and Silverlight teams have been pushing out news, examples and generally evangelizing it. I don't have much interest in phone development yet, but the latest version of the Windows Phone 7 SDK included the XNA beta (and is the only place to download it). The team's been hard at work updating XNA for greater cross-platform development and cleaning up some of the oddities in the API. In switching OTD over to the beta, I found a fair number of issues that either haven't been implemented or just moved somewhere new. I actually gave up after a while and started up a new dummy project to walk through the basics and start from a cleaner code base.

Changes

This is by no means a comprehensive list, but a short list of things that I've encountered and my solutions (if any) so far.

Content folder is now a separate project by default. Cool, this works, no problem here.
BasicEffect no longer uses SetParameter, but rather all parameters are properties.

BasicEffect

Shawn Hargreaves talks about two changes to Basic Effect:

Rendering Sample

Below is a simple object generated from the pipeline and consists of just a VertexBuffer and IndexBuffer. We reference the BasicEffect and Graphics Device statically. View, World, and Projection are much simpler as properties now. Within the effect pass loop, we no longer begin() and end() the effect and passes, but only Apply() each pass at the start. Less code for less mistakes.

The way vertex and index buffers are set on the device has changed as well to a simpler interface. Vertex buffers contain the information of their contained format and a single stream has only on vertex type. We set the length now by number of vertices and indices rather than byte sizes. The call to set the vertex buffer is much simpler.

class Sphere
{
    public VertexBuffer Vertices;
    public IndexBuffer Indices;

     public void Draw(Matrix view, Matrix projection)
     {
         // Set shader projections
         Core.BasicEffect.View = view;
         Core.BasicEffect.World = Matrix.Identity;
         Core.BasicEffect.Projection = projection;

         // Set vertex and index buffers on the device
         Core.GraphicsDevice.SetVertexBuffer(Vertices);
         Core.GraphicsDevice.Indices = Indices;

         foreach (EffectPass pass in Core.BasicEffect.CurrentTechnique.Passes)
         {
             pass.Apply();

             Core.BasicEffect.GraphicsDevice.DrawIndexedPrimitives(
                 PrimitiveType.TriangleList,
                 0,
                 0,
                 Vertices.VertexCount,
                 0,
                 Indices.IndexCount / 3);
         }
     }
 }

Content Pipeline

When building vertex buffers in the pipeline, a few things have changed here as well. Since vertex formats are now embedded in the buffer object, it takes an extra bit of initialization. A new class, VertexBufferContent is now needed.

VertexBufferContent

Building the VertexBufferContent is pretty simple since the information is available in the vertex format - we just need to loop through the VertexElements.

// Generate the VertexDeclarationContent from the VertexElements in our format
VertexDeclarationContent vdc = new VertexDeclarationContent();
foreach (VertexElement ve in VertexPositionColor.VertexDeclaration.GetVertexElements())
{
    vdc.VertexElements.Add(ve);
}

// Set the declaration fors the buffer
Vertices.VertexDeclaration = vdc;

Code

Here's the whole pipeline object that gets processed.

public class SphereContent
{
    public VertexBufferContent Vertices;
    public IndexCollection Indices;

    public SphereContent(int subdivisionLevel)
    {
        Vertices = new VertexBufferContent();
        Indices = new IndexCollection();

        // Generate the vertices
        List<VertexPositionColor> vertices;
        List<int> indices;
        Generate(out vertices, out indices);

        // Generate the VertexDeclarationContent from the VertexElements in our format
        VertexDeclarationContent vdc = new VertexDeclarationContent();
        foreach (VertexElement ve in VertexPositionColor.VertexDeclaration.GetVertexElements())
        {
            vdc.VertexElements.Add(ve);
        }

        // Set the declaration fors the buffer
        Vertices.VertexDeclaration = vdc;

        // Write to the vertex buffer
        Vertices.Write<VertexPositionColor>(
            0, 
            VertexPositionColor.VertexDeclaration.VertexStride, 
            vertices
        );

        // Add indices
        Indices.AddRange(indices);
    }

    private void Generate(out List<VertexPositionColor> vertices, out List<int> indices)
    {
        // Magic!
    }
}

More coming as I explore further.

Dictionary Stuff

2010-07-31T17:59:00.002-06:00

Serialization

Most of the C# Generics are XML serializable. Dictionary, however, is not. It can be extended with IXmlSerializable.

Paul Welter's Example

Yield and State Machine

2010-07-28T12:03:00.001-06:00

Interesting post about Yield as a state machine.

Shadow Coding

ASP.Net Helper Extensions

2010-07-27T16:57:00.009-06:00

Been a while since I've put anything up here, so just tossing a few simple things here.
Helper Extensions! Holy cow things things are nice! Some of these aren't terribly well tested yet, and there should be more coming.

Capitalize

Found this somewhere where I can't remember. Acts like php's ucwords() function in that it takes a string "foo bar" and returns "Foo Bar"

public static string Capitalize(this String s)
{
    return s.ToCharArray().Aggregate(
        string.Empty,
        (working, next) =>
        {
            if (working.Length == 0 && next != ' ')
            {
                return next.ToString().ToUpper();
            }
            else if (working.EndsWith(" "))
            {
                return working + next.ToString().ToUpper();
            }
            else
            {
                return working + next.ToString();
            }
        });
}

Even/Odd

Simple enough and useful for zebra striping tables.

public static bool Even(this int i)
{
    return (i & 1) == 0;
}

public static bool Odd(this int i)
{
    return (i & 1) == 1;
}

Newlines

Useful for displaying input from textareas

/// 
/// Replace line breaks with <br /> tags and encode the output.
/// 
/// 
public static string Nl2br(this HtmlHelper html, string text)
{
    return html.Encode(text).Replace(Environment.NewLine, "<br />");
}

Alka-Seltzer added to spherical water drop in microgravity

2010-06-03T10:37:00.000-06:00

Cool stuff in space!

KeyedCollection

2010-04-28T21:03:00.003-06:00

System.Collections.ObjectModel.KeyedCollection is an interesting class, but with one drawback: it serializes in XNA's IntermediateSerializer, but doesn't deserialize. There're ways to write a custom serializer for this class, but I chose a little bit different route - making my own that doesn't need a custom serializer.

Advantages

Different methods can be exposed between the pipeline and runtime versions. This can help make the collection immutable if desired.
Hides methods that may not be needed at runtime like adding and removing elements.
Provides regular for loop access for speed.

Disadvantages

Extra complexity of a new class
Have to re-implement any methods

Code

This is an abstract base class that serves solely as a container, provides an iterator, and a method of accessing by key.

abstract class KeyedCollection<T> : IEnumerable<T>
{
    #region Internal Data

    [ContentSerializer]
    private List<T> _collection;

    /// <summary>
    /// Keyed lookup: <Key, Collection Index>
    /// </summary>
    [ContentSerializer]
    private Dictionary<int, int> _lookup;

    #endregion;

    #region Properties

    /// <summary>
    /// Indexer
    /// </summary>
    /// <param name="index"></param>
    /// <returns></returns>
    [ContentSerializerIgnore]
    public T this[int index]
    {
        get
        {
            return _collection[_lookup[index]];
        }
    }

    /// <summary>
    /// Number of elements in the collection
    /// </summary>
    [ContentSerializerIgnore]
    public int Count
    {
        get
        {
            return _collection.Count;
        }
    }

    #endregion;

    /// <summary>
    /// Constructor
    /// </summary>
    public KeyedCollection()
    {
        _collection = new List<T>();
        _lookup = new Dictionary<int, int>();
    }

    /// <summary>
    /// Find the neighbor at the given keyed index.
    /// </summary>
    /// <param name="index"></param>
    /// <returns></returns>
    public T Key(int index)
    {
        return _collection[_lookup[index]];
    }

    #region IEnumerable

    /// <summary>
    /// Enumerator
    /// </summary>
    /// <returns></returns>
    public IEnumerator<T> GetEnumerator()
    {
        foreach (T element in _collection)
        {
            yield return element;
        }
    }

    IEnumerator IEnumerable.GetEnumerator()
    {
        return GetEnumerator();
    }

    #endregion;
}

Pipeline compiler directives already included too! It's a bit sparse for now, but a start.

Icons!

2010-04-28T09:25:00.006-06:00

Social Networking Icons

p.yusukekamiyamane Fugue Icons

A huuuuuge set of general purpose icons. Not as ubiquitous as the famfamfam icons.

FamFamFam Silk

Entirely ubiquitous now - you see these everywhere.
Silk Companion 1

Shaders!

2010-04-16T11:26:00.003-06:00

Learning some HLSL as the plan requires sometime more than what BasicEffect can handle. It doesn't do multiple diffuse textures per vertex. The plan is still very theoretical, and I'm not sure if I'm even smart enough to make it happen.

The screenshots before are simply a Miller projection wrapped around the grid. This means however that the texture border's don't line up to the grid borders. What I want is a more 'cellular' look and feel to it, along with a height map.

Cell Influence

foreach (neighbor in neighbors)
{
    foreach (vertex in neighbor.Vertices)
    {
        Calculate distance and then cell's influence on this vertex
        Cell.NeighborVertices[ neighbor.Index ].Add( Vertex, Influence );
    }
}

Now, we have a list of neighbor vertices that the cell has influence over. The distance and amount can be adjusted like a drawing brush - soft or hard brush. In this step, the neighbor vertices should be given a UV channel that lines up with the cell.

Blended Textures and UV Channels

Each vertex will have a minimum of three UV coordinates as it will have at most, three cell textures to blend (cell brushes shouldn't extend beyond one neighbor). Add in another texture channel or two for normal maps or detail overlays (just a tiled Miller wrap) and soon, every vertex has 5 UV channels. Currently I'm focusing on the first 3.

Paged textures will allow multiple textures to be used and not have to create channels in every cell for each texture. Each neighbor lookup will have assigned to a channels 1 or 2. Then just alternate channels for each neighbor. Except the 12 pentagons... Yeah, going to have to figure out something different there...

Height Maps

The current screenshots show a simple height-map retrieved from the diffuse texture. When moving to a more cellular approach, this kind of height-mapping won't be satisfactory. Instead, a series of small height-maps can be loaded and applied to cells individually. Using the neighbor influence lookup, the map can spill over and scale down into neighboring cell.

Some Screen Shots

2010-04-04T21:52:00.000-06:00

Borders still working. Have it set to wrap a Miller projection to the grid. There's a nasty seem on the back side to figure out. This isn't quite the ultimate goal though - I want a blended grid, not a single texture over the mesh. Height-mapping is working though.

Options:

Texture Splatting: more limited textures due to the blending mask. Might need a bit different type of unwrap?
Just leave the cell edges: easy, but doesn't look as nice

Spherical Coordinates in XNA

2010-03-07T18:13:00.004-07:00

OTD uses a globe based board. As such, spherical coordinates can be useful. The aim is to eventually be able to load a terrain map from a 2D image file. While I have a ways to go before that, I do have a utility class for managing spherical coordinates. Taking from DirectX's Vector2 and Vector3, I settled on Polar3 as a short yet descriptive stuct name.

Spherical coordinates need three basic elements - the azimuth phi, Φ; elevation theta θ; and a radius, R. Φ runs between 0 and 2π. θ however presents some choices. We can set one of the poles to be 0 and the other π, or set the equator to 0 and the poles to be +/- π/2. I haven't gotten far enough to determine which is the best way, leaving the north pole at 0 appears to be the easiest option when dealing with rotations. We'll see in practice though. Two properties for latitude and longitude can be set up that handle as expected.

Another thing to remember is which direction is up. The equations over at wikipedia and elsewhere place up as the Z axis. However, the default in XNA is Y axis, so Cartesian conversions need to account for this.

/// <summary>
/// Spherical Coordinate
/// </summary>
/// <see cref="http://en.wikipedia.org/wiki/Spherical_coordinates"/>
/// <see cref="http://www.radicalcartography.net/?projectionref"/>
public struct Polar3 : IEquatable<Polar3>
{
    /// <summary>
    /// Angle in the Right, Forward plane
    /// </summary>
    public float Phi;

    /// <summary>
    /// Angle around the Up axis
    /// </summary>
    public float Theta;

    /// <summary>
    /// Radius
    /// </summary>
    public float R;

    #region Latitude and Longitude Properties

    /// <summary>
    /// Latitude in radians
    /// -pi/2 <= theta <= pi/2
    /// </summary>
    public float Latitude
    {
        get
        {
            return MathHelper.PiOver2 - Theta;
        }
    }

    /// <summary>
    /// Longitude in radians
    /// 0 <= phi < 2pi
    /// </summary>
    public float Longitude
    {
        get
        {
            return Phi + (float)Math.PI;
        }
    }

    #endregion;


    #region Constructors

    public Polar3(float theta, float phi, float r)
    {
        Theta = theta;
        Phi = phi;
        R = r;
    }

    #endregion;

    #region Operators

    /// <summary>
    /// Equals
    /// </summary>
    /// <param name="value1"></param>
    /// <param name="value2"></param>
    /// <returns></returns>
    public bool Equals(Polar3 other)
    {
        return ((this.Theta == other.Theta) &&
            (this.Phi == other.Phi) &&
            (this.R == other.R));
    }

    /// <summary>
    /// Equality Operator
    /// </summary>
    /// <param name="value1"></param>
    /// <param name="value2"></param>
    /// <returns></returns>
    public static bool operator ==(Polar3 value1, Polar3 value2)
    {
        return value1.Equals(value2);
    }

    /// <summary>
    /// Inequality Operator
    /// </summary>
    /// <param name="value1"></param>
    /// <param name="value2"></param>
    /// <returns></returns>
    public static bool operator !=(Polar3 value1, Polar3 value2)
    {
        return !value1.Equals(value2);
    }

    /// <summary>
    /// Get the object hashcode
    /// </summary>
    /// <returns></returns>
    public override int GetHashCode()
    {
        return Theta.GetHashCode() + Phi.GetHashCode() + R.GetHashCode();
    }

    #endregion;

    #region 2D Map Projections

    /// <summary>
    /// Returns the xy Miller projection
    /// </summary>
    /// <see cref="http://en.wikipedia.org/wiki/Miller_cylindrical_projection"/>
    /// <returns></returns>
    public Vector2 ProjectMiller()
    {
        Vector2 xy = new Vector2();

        xy.X = Longitude;
        
        /*
         * (5/4) * ln( tan( pi/4 + 2theta/5 ) )
         */
        xy.Y = Latitude * 2 / 5;
        xy.Y = xy.Y + MathHelper.PiOver4;
        xy.Y = (float)Math.Log( Math.Tan(xy.Y) );
        xy.Y = xy.Y * 1.25f;

        return xy;
    }

    #endregion;

    /// <summary>
    /// Create a polar coordinate from a cartesian vector.
    /// </summary>
    /// <param name="vector"></param>
    /// <returns></returns>
    public static Polar3 CreateFromVector(Vector3 vector)
    {
        /*
         * DirectX defines up as (0,1,0), so we need to move some coords around.
         * Theta becomes the vertical angle against the Y axis
         * Phi becomes the horizontal angle in the XZ plane.
         */
        Polar3 coordinate = new Polar3(
            (float)Math.Acos(vector.Y / vector.Length()),
            (float)Math.Atan2(vector.X, vector.Z),
            vector.Length()
            );
        return coordinate;
    }

    /// <summary>
    /// To String
    /// </summary>
    /// <returns></returns>
    public override string ToString()
    {
        return (String.Format("(Theta:{0}, Phi:{1}, R:{2}, Lat:{3}, Long:{4})", Theta, Phi, R, Latitude, Longitude));
    }
}

Map Projections

ProjectMiller() returns 2D coordinate when using a Miller projection. It needs a little bit of work still, but the coordinates appear to be sound (just needs some offsetting) to map to a 2D image.

Other projections such as Mercator and Mollweide could be added as well.

Notes

Currently all the available values (Phi, Theta) and properties (Latitude, Longitude) are in radians. Given that all other C# functions use radians, this seemed the simplest.

Simple Settings Manager for XNA

2010-02-27T23:49:00.005-07:00

Being able to load settings into a game is a must. There are a number of ways to accomplish this. My current method works well enough for now, although it needs a bit of work in a few areas. I accomplish this by creating a series of settings classes that can be serialized into XML and back again at run time using my simple serializer.

Settings Manager

public class SettingsManager
{
    const string Extension = ".xml";
    const string Directory = "Content\\Settings\\";

    /// <summary>
    /// Loaded settings - Not currently implemented
    /// </summary>
    //SerializableDictionary<string, SettingsBase> _settings;

    /// <summary>
    /// Constructor
    /// </summary>
    public SettingsManager()
    {
    }

    /// <summary>
    /// Load a settings file
    /// </summary>
    public T Load<T>()
    {
        Type t = typeof(T);
        return Load<T>(t.Name);
    }

    /// <summary>
    /// Attempt to load a settings file.  If not found, it will
    /// load a new, default instance of the settings class.
    /// </summary>
    public T Load<T>(string name)
    {
        try
        {
            return Serializer.Read<T>(
                SettingsManager.Directory + 
                name +
                SettingsManager.Extension);
        }
        catch (Exception e)
        {
            e = null;
            Type t = typeof(T);
            return (T)Activator.CreateInstance(t);
        }
    }

    /// <summary>
    /// Save a settings object
    /// </summary>
    /// <typeparam name="T"></typeparam>
    public void Save<T>(T o)
    {
        Type t = typeof(T);
        Save<T>(o, t.Name);
    }

    /// <summary>
    /// Save a settings object
    /// </summary>
    /// <typeparam name="T"></typeparam>
    /// <param name="file_name"></param>
    public void Save<T>(T o, string name)
    {
        Serializer.Write<T>(
            o,
            SettingsManager.Directory + name + SettingsManager.Extension);
    }
}

The basic idea is that we can load and save settings files either based on an arbitrary name or, for simplicity, the settings class Type.Name. This is still a rough class - it assumes a lot about the settings files being loaded such as the files being serializable. I currently have a simple class that settings files inherit from:

Settings Base

[Serializable]
public abstract class SettingsBase
{
}

More functionality could be added here such as a Save() function that allowed settings objects to save themselves via the SettingsManager. The only special thing in this class is adding the [Serializable] tag at the top to ensure that all inheriting objects get this.

Simple Settings Example

public class PlayerSettings : SettingsBase
{
    public int Id;
    public string Name;

    public PlayerSettings()
    {
        Id = 1;
        Name = "Spartacus";
    }
}

Now, the settings manager can be used to load/save this.

// Load default settings
PlayerSettings ps = settingsManager.Load<PlayerSettings>();

// Change something
ps.Name = "Hercules";

// Save with default name
settingsManager.Save<PlayerSettings>(ps);

Future Improvements

SettingsManager does not ensure that loaded files inherit from SettingsBase at all.
SettingsManager does not track previously loaded settings files. Tracking and storing loaded files would prevent costly file IO, deserialization and reflection.
Settings classes assume that the constructor will set the default settings.