Sunday, 21 December 2014

.Net XDocument ToString() Deadlock

I have been working on a little project recently in which we was using some heavy .Net Runtime Caching of objects to reduce the strain on server resources as users access the same page over and over. We also implemented the same approach for caching the sites RSS feed. Crudely we was doing something similar to the following:

public ActionResult Feed() {
    XDocument document = null;

    if (Cache["feed"] == null) {
        document  = new XDocument(...);
        // Fill the document here...
        Cache["feed"] = document;
    } else {
        document = Cache["feed"] as XDocument;

    return Content(document.ToString(), 

The above is a stripped down example and is prone to errors in that if many users hit the method at the same time, there is no inherent locking, also the cache feed value could be ejected before it is read the second time. But we aren't here to work on that.

The issue here is the line:

return Content(document.ToString(), 

Because we were caching the XDocument and for each request calling ToString() this would lead to some untimely deadlocks on the liver servers where requests would run for hours never ending. The only solution was to kill the process and start the web site again.

After a little digging it was clear that the ToString() call being an instance method was to blame. I trudged through the source code for it and found it using several internals to iterate over the nodes to produce the string result. There is also a hint in the documentation for XDocument which states:
Any public static (Shared in Visual Basic) members of this type are thread safe. Any instance members are not guaranteed to be thread safe.
 So the solution was to simply cache the resulting ToString() rather than the XDocument, this way there is no further processing required every time a user requests this method.

public ActionResult Feed() {
    string xml = null;

    if (Cache["feed"] == null) {
        XDocument document  = new XDocument(...);
        // Fill the document here...
        Cache["feed"] = document.ToString();
    } else {
        xml = (string) Cache["feed"];

    return Content(xml, 

Sunday, 17 August 2014

MySQL Entity Framework 6 Include Performance Woes

Just a short post today, but after some pretty exhaustive performance testing with Entity Framework 6 and MySQL .NET Connector I am pretty much in the camp that .Include(...) is only ever detrimental to performance. This is down to the really poor query generation with MySQL and Entity Framework.
I have tested so far 8 parts of our current site, all different scopes of query including single record lookups, listings for a directory and more advanced filters to query on specific parameters and in each case adding Includes has increased the query times as opposed to Entity Frameworks lazy loading strategy. This seems really foreign to me but after looking at the SQL generated it is clear why MySQL has a tough time running the queries quickly. In short, stick to Lazy Loading with MySQL until the query generation in Entity Framework improves.

Friday, 4 October 2013

Here Is Terry

Haven't posted anything in a while, so here is vector Terry. Done as a design for a website and just fooling around.

Sunday, 23 June 2013

XBMC Ball Streams

A while back I posted about XBMC Hockey Streams and the plugin I developed in Python for XBMC. Well that project is still ongoing thanks to over 1,500 downloads, but say hello to it's sibling XBMC Ball Streams delivering the same experience from if your a fan of basketball and XBMC this is the plugin for you! 

Sunday, 28 April 2013

BattleShots Drinking Game Reaches 2K Downloads

Hurrah! BattleShots Drinking Game has reached a milestone of 2,000 user downloads. Some of the feedback received has been great, at some point there will be more features to come but thanks to all who have downloaded, played, shared and got merry with BattleShots Drinking game.

Saturday, 26 January 2013

BattleShots Game Architecture


The implementation of BattleShots is a little more complex than the standard android practice of creating an XML based layout and attaching events to components. To achieve a customised UI which can match a theme we have control of, we need to take charge of all drawing. This in turn severely limits the use of built in widgets for the android framework as they generally are themed with the OS version or skin in mind. Whilst they do provide theming support such as color, border, background etc. we still cannot achieve the majority of styles we want to expose from our game UI mockups.
In steps OpenGL which is the most heavily used 2d/3d graphics API at this time. Android contains a flavour of OpenGL in the form of OpenGL ES 1.0 and OpenGL ES 2.0 (ES stands for Embedded-Systems) which is optimized for mobiles, pda's and game consoles etc.
From android version 1.0 OpenGL ES 1.0 has been available. As of version 2.2 (froyo) OpenGL ES 2.0 has been available. Both make use of hardware acceleration where devices have separate GPU's which make the API very quick allowing games to achieve 60 FPS rendering (the more frames the better).
Seeing as we wanted BattleShots to be a rich UI experience we needed to go this route or our UI would be very static.

Game Architecture

Down to the mechanics of it! It is generally bad practice in any coding circle to perform application logic in the UI thread (unless it's short lived). For example you dont want to start processing a report in the UI thread as you may want the user to see a loading screen with an update on percentage completed. In this instance you would spawn a thread, update the UI every n seconds and wait for completion.
The BattleShots game architecture follows a similar approach. When the android Activity is initially created we create two objects.
  • The Updater
  • The Renderer
The Updater handles all game logic such as checking if the user pressed on a square, rotating the target reticle, animating a message on/off screen.
The Renderer handles drawing all objects to the screen.
We don't want to merge the above into one big routine as the frame rate will drop severely for devices that take a long time in the updating part.

Activity State

An android Activity has several states. See Android Activity Lifecycle for all its states (there is a good diagram on that page). The ones we are interested in are:
  • onCreate
  • onPause
  • onResume
onCreate we create a new OpenGL based view GLSurfaceView which is similar to a normal xml based view except that it expects us to render everything. Secondly we create The Renderer instance referred to above. Finally we create The Updater referred to above. Think of this event as the user starting a new game so we have to regenerate all our rendering and game logic.
onPause when the user opens a new app, goes to the home screen, receives an incoming call etc. We hijack this event to stop our updater thread from running, this conserves battery life (as we don't have a thread spinning away) and it also means the game doesnt continue updating, effectively pausing it. Basically any time our UI goes away.
onResume when the user returns to our app and it is still in memory (not been garbage collected). We hijack this event to resume our updater thread, this retains the state as we are not re-creating the objects over and over again. Basically any time our UI comes back after using it previously.

The Updater (Update Loop)

The updater (referred to in the game dev world as Update Loop or Game Loop) handles all game logic as previously stated. It has two purposes.
  • Provide a list of drawing commands to the renderer
  • Notify the UI thread of events e.g. user fired at a square
The class com.pterodactyl.battleshots.views.BoardGameUpdater is where you want to look for its implementation. It implements the Runnable interface which means it is intended to be run by a thread at some point. What we actually do in the classes run() method is force an infinite loop when the thread starts so the updater continually runs. The loop can be broken by setting the running flag to false.
Within the loop there is code to handle the number of updates per second. We don't need the updater to run at 1,000,000 times a second and the more we can sleep the thread the more battery life and cpu we save. Currently the updater thread runs at a maximum of 30 updates per second as defined by the MAX_UPDATES_PER_SECOND variable in its class. The logic within the loop handles the three following instances.
  • Hardware is fast - sleeps the thread after every loop to meet the 30 updates per second rate)
  • Hardware is just right - continually loops with no sleeping
  • Hardware is slow - it forces several updates without sleeping and without pushing updates onto the render thread as it tries to play catchup
Within a single update loop the class does four things:
  • Updates Game Objects
  • Triggers Events
  • Create Drawing Commands
  • Send Drawing Commands To Renderer
Update Game Objects the game state is updated every cycle. It creates objects for each UI instance e.g. a boat, a square, a user icon, text etc. and updates their state. Some common updates are:
  • Update the target reticle rotation value (so it spins)
  • Changes the easing value of a text background (so it animates up and down)
  • Calculates the size and position of the checkers based on screen width/height
  • Calculates the size and position text
  • Calculates the size and position of splashes and explosions
Triggers Events calls any event listeners for events in the game such as a user pressing the fire button.
Create Drawing Commands creates a single drawing command (which a class that wraps up OpenGL drawing commands). It creates objects for each UI instance and uses their state from above to position, draw, colourize etc. Some common drawing commands are:
  • Load a splash texture, position it on screen and draw it
  • Load a background texture, repeat it across the entire background and blend it with a blue gradient
  • Draw a checker using native quads and colour them in
Send Drawing Commands To Renderer passes the above commands to the renderer. Whilst this sounds easy enough it is one of the main reason's why the renderer and updater are broken into separate components. Because updating and rendering are done independently on separate threads, for us to pass information from the updater to the renderer we need to do it safely by locking the renderer and updating its command list. Locking is quite a slow process so it is only done once at the end of an update cycle.

The Renderer (Render Loop)

The renderer is quite dumb. For each rendering cycle (an infinite loop controlled by OpenGL) it locks the Drawing Command list, iterates through and draws them to the screen, finally unlocking the list. This allows for the UI to be drawn very quickly as very little logic (apart from translating coordinates or scaling) is done on this thread. This is how we achieve a high FPS.

The Update Loop + Render Loop = Game On

I have put together a diagram below to try to explain the above process visually. Hope it helps.

Saturday, 5 January 2013

BattleShots Drinking Game

Been quiet recently and as such I usually pick up a project or two I am interested in. So here comes BattleShips Drinking Game for the Android Market. The game concept is around a physical drinking game we have played on occasion so what could be better than sharing this with other people and developing and Android App in the process.

I have worked on the Android platform previously so it was nice to work on a game which some great visuals and interaction. I designed and developed the user interface, user experience, sprites and assets used in the game and got to grips with OpenGL ES 2.0 framework for hardware rendering on the Android. Although the game is two-dimensional it was nice to see the full 3D architecture of OpenGL and how I could use this in future projects.

The game makes use of several custom shaders for rendering performance and some real nice visuals. Font's appeared to be the big issue on the Android so I went down the route of implementing a Bitmap Fonts helper library with a Glyph mapping so that spacing could be managed between characters. Overall I think my implementation works really nicely and the text stands out as a key part of the Game. To see just how I implemented Bitmap Fonts in OpenGL ES 2.0 take a look at the source at BattleShots Bitmap Fonts Source the source is well documented so it should be easy to traverse. The bitmapfonts.xml file can be found there too.

Another key element of the design was that I wanted to make the game performance a crucial factor. I felt this would be handy in future projects so BattleShots is quite heavily optimized (perhaps overly so). This is discussed in more detail in a separate article I wrote on BattleShots Game Architecture please go take a look.

Finally came the marketing side, so I quickly put together a site which advertises BattleShots Drinking Game, I think it does a good job of conveying the BattleShots message.

Working with the Android framework has been a nice change again as well as following test driven development practices throughout the development of the game, this really made it easy to quickly get iterative builds up and running for users to see.

Be sure to go download the App and play with a few mates!