A test of resource loading in MonoGame



Loading resources into RAM on a smartphone can be a relatively slowish process. I’d been working on a card game and had both a set of 52 individual playing cards plus a sheet of 52 in one image. I have two Android phones so used the opportunity to test which is quicker loading 52 small images or one larger image. MonoGame ‘s Draw routines can copy from part of an image; you just specify the source.
In this case I was comparing loading 52 images, each 100 x 153 pixels (the four aces shown are the same images) or one image that is 1500 x 633. On the face of it, loading one image should be faster- there’s a certain overhead with loading each image so you get that x 52. But larger images can be problematic especially on devices like smartphones with less smaller amounts of RAM than desktops.
The two smartphones are both older, one is a BLU STUDIO ONE; the other a Chinese beast which shows up in Visual Studio as an Alps X27 Plus. It was bought on Ebay and claims to have 6 GB of RAm and 128 GB storage. In practice, when I tested the storage, it ran out after 12 GB! The phone only cost me £29 so I cn’t really complain…Although it claims to be Android 9.1 in the Developer information in Settings, it like the BLU seem to be running Android Lollipop. (5,1 – level 22) when plugged into my PC/Visual Studio.
I first ran the load code on the 52 images in Debug mode. Possibly not the best way to test code.
private string LoadCards()
{
Stopwatch stopWatch = new Stopwatch();
const string suits = "HCDS";
const string ranks = "A23456789TJQK";
stopWatch.Start();
int i = 0;
foreach (char c in suits)
{
int j = 0;
foreach (char r in ranks)
{
string s = @"Cards\"+r + c;
cards[i, j++] = Content.Load(s);
}
i++;
}
stopWatch.Stop();
TimeSpan ts = stopWatch.Elapsed;
string elapsedTime = String.Format("{0:00}:{1:00}:{2:00}.{3:00}",
ts.Hours, ts.Minutes, ts.Seconds,
ts.Milliseconds / 10);
return elapsedTime;
}
That is the C# code to load the 52 images. The Alps which is a newer phone took 0.28 seconds to load them. The older BLU took 0.18. Neither are great times. To load the single image I commented the code out between the two stopWatch calls (Start() and Stop()) and then added this one line.
allcards = Content.Load<Texture2D>("allcards");
The single image took 0.10 seconds on the Alps and 0.06 seconds on the BLU, both roughly three times faster loading one big image than loading all 52 images. Information like this is useful and I’ll now create my own tools for building sprite sheets of multiple images.

There are some subtle differences between it and Visual Studio Code. The main one is the not having access to the VisualStudio market place. The C/C++ template isn’t there but instead is installed by default.
Yesterday’s post reminded me of one of the joys of my youth. The Creative Computing magazines’ “BASIC Computer games” book and it’s sequel “More BASIC Computer games.” . I bought these in 1982, and they weren’t cheap then- about £20 each.
The second game is Match Three and I’d made some good progress. You can view some .mp4s from earlier this month
I’ve never dealt with a game pad (joypad etc.) before. It seems that there is no absolute mapping, it’s more like TV remote controls. There’s lots of them and they’re all different. So although SDL2 has a set of enum values for the buttons, I found that my game pad wasn’t responding to what I thought were the game keys.
I’ve used diff and merge tools since the year dot. They let you compare two files and see on what lines they differ. You can also copy individual or blocks of lines from one to the other; that’s the merge. My all-time favourite was the commercial Araxis Merge which did a three way comparison and could be controlled by COM. I did this to compare two code bases.