MODEXngine. As mentioned back on August 8th, 2013, the
MODEXngineis intended to not only being a game engine with the usual graphics, audio, input handling etc, but also a cloud platform. With cell phones and tablets establishing themselves as a viable platform to target the last several years, one can no longer simply focus on the PC (Win32/Linux/Mac OSX). With mobility also comes with things that a traditional "PC" developer wouldn't run into: vastly different platform APIs, network drops, "5 minute or less" gameplay and supporting an eco-system that crosses all of those platforms. Coming at this as an enterprise developer who actively develops on virtually every platform (Windows, the Web, Android, iOS, Windows Phone and Windows Store), I feel as though I bring a fairly unique perspective of how everything can exist and bring the experience to each platform natively, putting myself in the shoes of someone who wants to develop a game for every platform, but wants full native control over the platform as opposed to an "Apache Cordova" approach in which it solves the bigger problem of quickly delivering to multiple platforms, but stalls when you have a feature that needs more native functionality (let alone speed). Another advantage I hope to bring is the ease of use. Wrapping native level calls with generic wrappers across the board, it should cut down on the issues of "how do I do that on platform XYZ", similar to how Xamarin Forms has made wrappers for iOS, Android and Windows Phone, but hopefully with less issues.
jarred at jarredcapellman dot com.
jcDBenchfor sparc/Solaris compiled with g++ 4.80. Both have 0 dependencies so just extract and run. Man pages and a true installer will come with the big 1.0 release (more on that at a later date).
jcDBenchfor mips/NetBSD. Both have 0 dependencies so just extract and run. Man pages and a true installer will come with the big 1.0 release (more on that at a later date).
jcDBenchafter running it with the "stock" Seagate Barracuda ATA IV PATA drive expecting a huge boost in performance, I was disappointed to see these results: [bash] $ ./jcDBench Running with no arguments... #----------------------------------------------- # jcDBench mips/NetBSD (0.1.47.0312) # (C)2013 Jarred Capellman # # Test Date : 3-13-2014 18:48:14 # Starting Size : 4096 # Maximum Size : 4194304 # Iterations : 100 # Filename : testfile #----------------------------------------------- # test size write read # (bytes) (MB/s) (MB/s) #----------------------------------------------- 4096 1.83MB/s 6.17MB/s 8192 3.01MB/s 10.3MB/s 16384 6.77MB/s 13.2MB/s 32768 8.5MB/s 11.4MB/s 65536 3.55MB/s 10.9MB/s 131072 3.83MB/s 11.6MB/s 262144 3.78MB/s 12.1MB/s 524288 3.87MB/s 12.4MB/s 1048576 3.9MB/s 7.47MB/s 2097152 3.91MB/s 7.56MB/s 4194304 3.93MB/s 7.58MB/s Benchmark Results Uploaded [/bash] The "stock" drive performed reads very similarly and the writes it performed considerably better than the theoretically much faster SSD. Not convinced something else was wrong, I went through the
dmesg. Low and behold:
Typed Datasetsin C# you can have clean interfaces to read and write XML files. In Windows Phone however, you do not have
Typed Datasetsso you're stuck utilizing the
XmlSerializerto read and write. To make it a little easier going back to last Thanksgiving I wrote some helper classes in my NuGet library jcWPLIBRARY. The end result within a few lines you can read and write List Collections of Class Objects of your choosing. So why continue down this path? Simple answer: I wanted it better. Tonight I embarked on a "Version 2" of this functionality that really makes it easy to keep with your existing Entity Framework knowledge, but provide the functionality of a database on a Windows Phone 8 device that currently doesn't exist in the same vain it can in a MVC, WinForm, WebForm or Console app. To make this even more of a learning experience, I plan to blog the entire process, the first part of the project: reading all of the objects from an existing file. To begin, I am going to utilize the existing
XmlHandlerclass in my existing Library. This code has been battle tested and I feel no need to write something from scratch especially since I am going to leave the existing classes in the library to not break anyone's apps or my own. First thoughts, what does a
XmlSerializerfile actually look like when written to? Let's assume you have the following class, a pretty basic class:
XmlSerializeruses the "ArrayOf" prefix on the name of the root object so when testing with sample data when writing a new Windows Phone 8 app I have to refer back - hopefully that helps someone out. Going back to the task at hand - reading data from an XML file and providing an "Entity Framework" like experience - that requires a custom LINQ Provider and another day of programming it. Stay tuned for Part 2 where I go over creating a custom LINQ Provider bound to an XML File.