ExEn Code Samples and Silverlight Features
If you’ve been following along with my ExEn project, you will know that I’ve recently started to be discovered by a much wider community of XNA developers – especially ones who are interested enough in ExEn to help fund it.
Being discovered like this has created a “good problem”: The kind of people discovering ExEn are serious developers who are likely to find ExEn extremely useful. Of course they are also shrewd and naturally sceptical – and I am asking for money on the Internet! So before they invest in ExEn they want to know exactly what they are getting.
(I’d probably be sceptical too, if I were in their position.)
After I addressed some of the more philosophical and structural issues in my last entry, I asked around for some feedback on how to best address people’s technical issues. (Without simply releasing the full source code, which would defeat the purpose.) I have created this preliminary result.
First of all, a simple code sample. This is a comparison of the MediaPlayer class from ExEn on both Silverlight and MonoTouch as well as from the latest versions of both SilverSprite and XnaTouch:
- MediaPlayer on ExEnSilver
- MediaPlayer on ExEnEmTouch
- MediaPlayer on SilverSprite
- MediaPlayer on XnaTouch
And in addition to that, I have been through the Silverlight code very carefully, line-by-line in some places, and I have been able to produce this chart comparing the features of SilverSprite with ExEnSilver (both as it is currently, and as planned for the project being funded). Click to see the full table.
(Update: I have clarified what “As Requested” means in my next post.)
I haven’t done a table for ExEn and XnaTouch on iOS yet. There is a fairly substantial amount of work involved, combing through source code and revision logs. So hopefully the Silverlight table gives you an idea of what ExEn supports on iOS (recall that I have tried to keep the two platforms in-sync). For the time being, if you wish to know the details about a particular feature on iOS, send me an email.
| Twitter
Comments
Roy Triesscheijn
Although I like your project and what you’re trying to achieve I think the graph doesn’t tell us very much because the same key-color was used for “already working” and planned. If you would compare what Exen currently has with any of the other projects, the picture might be very different. Also if you include planned for Exen, then why not include planned for the other projects :).
Still I think ExEn is a great idea, and I know you have to market it somehow! So to not just rant, maybe here’s how I think about it:
The person most likely to invest in ExEn is a person who is currently making money with a WP7 or XBLIG title that wishes to expand to other platforms. This person would like to port their game in as little time as possible with as little changes as possible without introducing bugs. So try to focus on marketing these keypoints of ExEn first :).
On a personal note I think not including the ContentPipeline (it’s marked maybe) is a big big big deal breaker. This means that converting a project is going to be extremely cumbersome, writing a new ContentManager, making sure everywhere this CM is linked. Writing special importers for Models and other stuff that doesnt have a .FromFile method, etc..
Andrew Russell
Thanks for your comment Roy.
I am afraid I do not understand your concern with my table. I have itemised both the current and planned development of ExEn – so all the information is there. Items marked “Yes” in the planned column will definitely be available once the project being funded is completed.
Items marked
Maybe“As Requested” will be done (by me) as time permits and prioritised by people actually letting me know that they need those features (as the features are rarely used). I’d like to do all of them, but I don’t want to guarantee it.(Update: I have renamed “Maybe” to “As Requested”, as people were getting the wrong idea.)
Obviously I can’t really say much about the plans of SilverSprite (although it seems to be not in active development, currently) and XnaTouch.
Regarding the Content Pipeline, I think I need to clarify. The XNB reader that SilverSprite provides can read uncompressed XNB files that are created by the content pipeline in XNA Game Studio in debug mode (none of these alternate libraries have XNB writing facilities). The main reason to have the XNB reader in a 2D game is to load SpriteFonts (none of these libraries support Model, or 3D at all for that matter).
Because Silverlight can render TrueType fonts, I did not need to load XNB sprite-fonts for my own games (on Silverlight), so I removed the reader and the bitmap font renderer to save a significant amount of space and reduce the amount of code I had to work on. Adding it back in involves essentially copy-pasting it from it back in from SilverSprite and ensuring it all works.
For loading textures and so on, you still use the ContentManager as normal. But instead of reading a compiled XNB file it automatically reads from a PNG or JPEG (or a TTF, and so on) file for you directly.
On iOS, ExEn still requires sprite-fonts, and so the XNB reader is still available there.
Michael Lindholm
Hi Andrew
I think what Roy meant was:
if you don’t difference ‘done’ with ‘planned’, there is no way of knowing how much you have created, it may very well be ALL planned features, and nothing implemented.
it was exactly what hit me when i watched your diagram, sort of gives the impression that it might be vapor-ware 😉
Anyway, I’m not as sceptical as most people seem to be, and I have been interested in this project since i first viewed your video on RocketHub.
Looking forward to see how this project progress 🙂
Andrew Russell
I must admit that I am genuinely confused by your comment.
The second column in the table is the ‘done’ column. It’s already implemented and ready to go. It is exactly what people who contribute $100 or more will receive the as soon as the funding period ends.
So if you look at both the second and third columns, anything that changes from red to green is something that I will be implementing during the ExEn development period.
(Actually – now that I look at it again – perhaps my column headings are not quite clear enough. I will change them and hopefully that will clear up some confusion.)
Sean Hammond
Hi Andrew,
I might be guessing here, but what Roy and Michael are asking for is that you use a different colour for the in-place-now versus the will-be-done column, even if it is just different shades of green or red where used, this would allow a greater clarity on a high-level zoomed out look. I was a bit confused about the table myself at first glance, but once I figured it out, it was easy enough.
I do have a question on the code examples you have provided. Between the two ExEn examples you have provided, I do notice that there is a fair amount of rewrite required, not just in the libraries but also a number of functions.
Is this to be expected for all versions of ExEn, be it Android, IOS or Mac (if you get that 2k overage, holding thumbs)?
Do you foresee a point where one can simply use the exact same code, and change the build targets as needed?
Andrew Russell
Thanks for writing, Sean. Next chance I get, I’ll go in and add some different shading for things being added, and hopefully that will clear up the confusion 🙂
If I understand correctly, your question is: How much of ExEn itself will be shared between platforms?
Basically everything that can be shared will be shared – anything internal to XNA that simply can sit on C# (eg: all the maths classes, game component classes, content management, the XNB decoder, etc) will be shared.
However XNA itself is a fairly thin wrapper over hardware. So everything that interacts with the hardware (rendering, audio, input) needs to be rewritten for each platform, with some exceptions. For example iPhone, Android and iOS all use OpenGL, and I am hoping that a fair chunk of the rendering code can be shared. Additionally audio on iPhone and Mac may be at least compatible enough that some code can be shared there.
To come at it from another direction: The big unknowns for me are input and audio on Android. Everything else is either reusable or I have a fair idea of how to proceed.
To the end-user, of course, I aim to make this as transparent as possible. Each platform has a few limitations that a developer must be aware of, but within those limitations, a developer will be able to write their game once and deploy anywhere.