Category: C#

Mobile game development progress

Mobile game development progress

Manana Banana Screenshot on AndroidDevelopment continues with the first game, which is a card game. I know the game as Top Banana, but I think that is the name of a commercial game, so for now the working title is Manana Banana. All it does currently is display the cards and backs as you can see. No photo this time, I learnt how to take snapshots on the phone (Hold down the power and Lower volume buttons at the same time) As it’s plugged in to my PC,. copying it across was not difficult.

This uses my virtual screen technology working on an 800 x 1400 virtual screen then scaling output onto the real screen which in this case on the Alps X27 Plus is 480 wide by 960 deep. As you can see I have a black rectangle at the top and the Android controls are visible at the bottom, neither of which I programmed for. I’ll get those fixed.

You play this game by clicking on the six top cards one-by-one and then tap the back of the card where you want to play that top card. So you end up with three poker hands. In this case I’d put the 7 and 9 on the top row for one pair, the two fives on the 2nd row also for a apir and the King and Jack for an Ace-high straight on the bottom row. The gap on the right will show the text of the hand so will say Pair, Pair and Ace Straight or something like that.

Next thing is making the cards clickable. That is the top six cards and the the three sets of two backs below. Once that’s done I’ll make that bit work then plug in the Jessie Chunn’s poker hand evaluation code to figure out what each hand of five cards is and more importantly give it a numeric score.

The gradient that covers the screen came from Unsplash.com.

 

How to create a big image from a number of smaller ones

How to create a big image from a number of smaller ones

Card DeckAfter the day before yesterday’s experiment showed that loading a single larger image on an Android phone is nearly three times faster than loading 52 smaller images, I decided to write a short utility program to read all the 52 individual card files and create one file with them laid out neatly in four rows of cards, one row per suite with each card running from Ace to King.

The individual card .png files were all in one folder with two letter filenames rank and suit in capitals like AS.png (Ace of spades), TH.png (Ten of Hearts and so on).

This 62 line C# program reads all 52 files into RAM in a two-dimension array cards (original name eh!) in the method LoadAllImages() then in BuildOneImage() it writes them out in the four rows into the bitmap allcards then saves them out as one .png format file.

C# makes doing this very easy. In C you would have to write your own file format handling code or use a library like libpng.

// Author D. Bolton Learncgames.com You are free to use and copy this program as you wish but please leave this line in.
using System;
using System.Drawing;
using System.Drawing.Imaging;

namespace mpics
{
    class Program
    {
        const int CardWidth = 100;
        const int CardHeight = 153;
        const string source = "your path here"; // Path to all 52 card files
        const string dest = "target file here"; // Path + filename for target .png file.
        const string suits = "HCDS";
        const string ranks = "A23456789TJQK";

        static Bitmap[,] cards = new Bitmap[13,4];
        static Bitmap allcards = new Bitmap(CardWidth * 13,CardHeight * 4);

        static void Main(string[] args)
        {
            LoadAllImages();
            BuildOneImage();
        }

        private static void BuildOneImage()
        {
            Console.WriteLine();
            var aty = 0.0f;
            using (Graphics g = Graphics.FromImage(allcards))
            {
                for (var y = 0; y < 4; y++)
                {
                    var atx = 0.0f;
                    for (int x = 0; x < 13; x++)
                    {
                        var r = new Rectangle((int)atx, (int)aty, CardWidth, CardHeight);
                        g.DrawImage(cards[x,y],r);
                        atx += CardWidth;
                    }
                    aty += CardHeight;
                }
            }
            allcards.Save(dest, ImageFormat.Png);
        }

        private static void LoadAllImages()
        {
            var i = 0;
            foreach (char c in suits)
            {
                var j = 0;
                foreach (char r in ranks)
                {
                    var s = source + r + c+".png";
                    cards[j++,i] = (Bitmap)Bitmap.FromFile(s);
                }
                i++;
            }
        }
    }
}

Don’t forget to set the source and dest path constants. This was compiled in Visual Studio 2019 and run on Windows 10. The only really important thing I found was using the Rectangle r in BuildOneImage(). If I used just atx and aty and didn’t specify the size of card then DrawImage() drew much smaller images into the bitmap. I’m not sure why as the card images when loaded from disk were 100 wide by 153 deep, the same as specified in the constants CardWidth and CardHeight.

The card images were originally downloaded from the American Contract Bridge League but were much bigger so I scaled them first to 100 x 153 pixels. There are many free playing card images on the web but these are one of the nicer sets.

A test of resource loading in MonoGame

A test of resource loading in MonoGame

Ace of ClubsAce of DiamondsAce of HeartsAce of SpadesLoading 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.