Jump to content

Recent Comments

- - - - -

First version of FlatBuffers in .NET

4: Adsense

I've committed by first alpha version of the FlatBuffers port to .NET to GitHub.

Since my last post, I decided to port the Java version to .NET as straight as I could, which means the use between Java and C# should be similar.

I ported the JavaTest buffer creation code; which looks as follows:
            var fbb = new FlatBufferBuilder(1);

            // We set up the same values as monsterdata.json:
            var str = fbb.CreateString("MyMonster");

            Monster.StartInventoryVector(fbb, 5);
            for (int i = 4; i >= 0; i--)
            var inv = fbb.EndVector();

            Monster.AddHp(fbb, (short)20);
            var mon2 = Monster.EndMonster(fbb);

            Monster.StartTest4Vector(fbb, 2);
            MyTest.Test.CreateTest(fbb, (short)10, (byte)20);
            MyTest.Test.CreateTest(fbb, (short)30, (byte)40);
            var test4 = fbb.EndVector();

            Monster.AddPos(fbb, Vec3.CreateVec3(fbb, 1.0f, 2.0f, 3.0f, 3.0,
                                                     (byte)4, (short)5, (byte)6));
            Monster.AddHp(fbb, (short)80);
            Monster.AddName(fbb, str);
            Monster.AddInventory(fbb, inv);
            Monster.AddTestType(fbb, (byte)1);
            Monster.AddTest(fbb, mon2);
            Monster.AddTest4(fbb, test4);
            var mon = Monster.EndMonster(fbb);

My test code will read a file output from C++ and assert against it being valid (readable). Then create the same buffer in .NET and run the same tests against it; exactly like the JavaTest does. My .NET version passes both sides, so it means we should be compliant to the FlatBuffer format and can achieve interop between C++ and Java.

By being in C#, this should be usable from Unity - either as code, or binary. I haven't verified this yet though.

Now that I've got a working version, I can start to address my other concerns - that it doesn't "look" nice to .NET developers ;)

What this really means is that I'll be building a reflection based serialization layer on top of this, so we can do code-first and/or transparent POCO serialization from the FlatBuffer format.


After thinking about this, there's a few things I want to look at improving. The first version was a straight port, and this works fine but sticks out in C# like a sore thumb.
  • Modify the C# code generator to create a property for get access (eg: not monster.Hp(); but monster.Hp; )
  • Change the generated C# objects to XXXReader and XXXWriter; this lets me have cleaner split of read/write concerns
  • Refactor the FlatBufferBuilder into a FlatBufferReader and a FlatBufferWriter - again, to separate the concerns a bit
  • Look into a nicer way of handling arrays/vectors
  • Build a "typemap", effectively a definition of a FlatBuffer type which can be used to serialize or code gen POCOs
  • Add the Serialization support for POCOs (mentioned above)
  • Add a MediaTypeFormatter for ASP.NET / etc to allow simple model binding with FlatBuffer format

Note: GameDev.net moderates comments.