Category: Other stuff

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.

 

A game development website recommendation

A game development website recommendation

Games
Image by Maria_Alberto from Pixabay

In my previous post I mentioned that I’d had to discover a lot of stuff for myself. Just before the Web came into being ie 1994-1995 I’d been working on a hexagon map based game.  I figured out how to draw hexagons, how to store a hexagon map (as a 2D grid), how to click on a map location and discover exactly which hexagon you clicked.

I still have source code that I wrote 30 years ago for the postal game Quest and likewise for the hexagon game which I called Onslaught. Both were written for a 16-bit Turbo Pascal and probably could with a bit of effort be transformed into 32-bit or 64-bit Delphi had I the time and desire, both of which I lack.  Given that Quest is still run, that’s probably not a good idea anyway! Plus I had only been writing Pascal code for a few years and my old code is far from being comprehensible!

Anyway, a lot of the wisdom and stuff that I taught myself can be found on the excellent Amit’s Game Programming Information website (particularly the hexagon stuff) and I highly recommend it if you have any desires to be a game programmer.

 

 

 

 

Playing with VSCodium

Playing with VSCodium

open-vsx.orgThere 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.

However I have found that the tasks and launch json files created from the F1 menu don’t have the C++ choices. What this means is that you have to get them from an official Visual Studio source, like Visual Studio Code installed on 64-bit Windows/Ubuntu/Mac.

I’d already done this so I used WinSCP to send them via ssh from my Windows box to the Pi. It’s a slight irritation but once you’ve got them setup it works ok. I can build applications haven’t got debugging working yet though.

There is an alternate Extensions Marketplace which has 266 items in it.  That’s a screenshot of the programming language extensions.

Creative computing games

Creative computing games

Hammurabi BASIC listYesterday’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.

Of course over the years they got lost but I bought them again a few years back. Some of the games in here are classics- A simple Star Trek game, Hammurabi, mugwump, golf, various landers. Of course they are all in BASIC but relatively easy to convert to C.

You don’t have to buy the books (they are pretty expensive on Amazon and no I’m not selling mine!) as many of the games are available online. One source is this classic BASIC games web page. Here’s another link  with more games but they are scans of the pages.

I promise I won’t be putting any more BASIC listings up. These are just an  inspiration to create small games in C or adapt these.

While at Uni in my first year, I adapted a copy of the Star Trek game adding in a whole lot of new features. It doesn’t say much about the interactive mainframe there that with just four people playing the game, the mainframe was brought to its knees!

Working on the Match Three game

Working on the Match Three game

Match three gameThe second game is Match Three and I’d made some good progress. You can view some .mp4s from earlier this month here. The first one (MatchThree) shows rotations, something I’d never realised SDL is very good at doing. Graphics are from the excellent Dutch website (it’s in English) Kenney.nl.

The second mp4 (transitions) shows some animations. And the MatchThreeDropping shows pieces both being removed (first rotating and shrinking) and pieces dropping. However it also shows a flaw.  Sometimes all the pieces move together, other times (and this is the flaw) it shows them dropping one by one- Mexican wave-like, rather than all moving together.

My original algorithm, which I am now scrapping, had a transitions table. When the space or spaces below a piece became blank, a transition was created which had start and end positions. The piece was removed from the board (a simple 2d array) and reinstated in the board when it had finished moving to the end pixel position.

I think I have a much better method now, I still use a board but each element has a pointer to a piece in a big array of piece structs. I track both the coordinates in the board (0-9,0-9) and in pixels as each piece is 64 x 64. When a space is created in the board, all the pointers are shuffled and each piece is told to move from it’s old pixel position to its new one.

The move algorithm operates purely on the all pieces in the piece array not the board. The flawed algorithm worked on both the board and transition array and was quite messy. Sometimes you have to start with a clean slate than try and fix code that is working correctly.

Fun with game pads

Fun with game pads

Gamepad ToolI’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.

But SDL2 to the rescue.  The SDL_GameController has a flexible scheme where the game pad can be setup by a text string. There’s a database of schemes available on Github. That includes a couple of tools for discerning what the setup for your game pad is. That’s one of them shown. That program from General Arcade is free and cross-platform. I downloaded and ran it on Windows with my game pad attached.

So, my controller is a NEXT SNES Controller (no surprises there) and the setup string for it is 030000001008000001e5000000000000,NEXT SNES Controller,a:b2,b:b1,back:b8,dpdown:+a1,dpleft:-a0,dpright:+a0,dpup:-a1,leftshoulder:b4,rightshoulder:b6,start:b9,x:b3,y:b0,platform:Windows.

There’s a database of these on Github and it currently has 780 odd strings. You can view it here though it’s not that great a read!

So I think the idea is, you can include that file in your application and any game that uses game pads can get the GUID from the game pad via one of the SDL calls- see this list of SDL GameController functions and load the file into memory et voila, your application can now use the game pad.

My stab at encryption in C

My stab at encryption in C

Encryption
Image by Pete Linforth from Pixabay

This is a little bit off-topic for this blog but hey it’s my blog and it is C code and I will be publishing it in full.  It’s often said that programmers should not write their own encryption software because most programmers do not have the mathematical background.  And I confess that’s me…

However, I thought I’d publish it and put it out there and someone can look at it and say, oh that’s far too easy to break, or maybe not!

The other truism with writing encryption software is that it must not depend upon the algorithm being concealed; the key yes, the algorithm no. So here’s my algorithm.

Generate a 64 byte key. This key has one property, in that it contains each of the 64 numbers 0-63. The order is scrambled. So it might start 0,1,2 but after the bytes have been shuffled (like shuffling cards in a deck) then it might have 43,9,12 and so on.  Think of it as a single row with 64 columns. This 64 byte array must be written to disk. It’s a symmetric cipher, the same key is used to encrypt and decrypt.

Take the plain text and process it in blocks of 8 bytes at a time. Split those 8 bytes into 64 individual bits and write each bit to its own stream. So after processing 64 bytes, each stream has a single byte. Now write these 64 bytes to the file but index the column by the key i.e.

for (i=0;i<64;i++)  
  write(file, data[key[i]]);  

So the first byte written would be data[43] then data[9], data[12] and so on.

So you say, that doesn’t sound very complicated. Are you sure it is encrypted?

Well consider our 64 byte key. There are 64! different ways of rearranging the 64 bytes. If I repeat some of my post from three days ago. “If you could do a million a second, it would take you 1.27×1083 seconds or 4.02×1075 years! Or to make it more meaningful it’s this large! 4.02,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000 years. That’s approaching (but still far far off) the time for the heat death of the universe which is estimated at 10100!”

Now I don’t know what methods might be used to crack it. Plus if you have some super-dooper fast hardware that can brute force it, it must have some way of recognising that the decrypted data is correct. If before encrypting it, we do a round of obscuring text, maybe something as simple as xoring the text with a repeating set of values, it’s going to make things a wee bit harder.

I welcome any comments on this and as soon as I have finished testing my program, I’ll put the source code up on Github.

A tale of two diffs

A tale of two diffs

Screenshot of devart code compareI’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.

Ten years earlier code for Base Metals (commodities trading) had been forked from Oil Trading software. There were ten years of changes to both sets of code and my job was to merge them back into one code base. I wrote a program to walk Araxis Merge through all folders of both code sets and out-put the differences, Then I could start merging where they differed. It still took about two months but I couldn’t have done it as quick without Araxis.

However most of us don’t have access to Enterprise tools, so here are two alternatives. The first is Devart’s Code Compare (that’s the image above) and the second is a free Extension for Visual Studio Code called Diff & Merge. I’ve added both to the Links to C utilities page.

New page added to Website

New page added to Website

Word Cloud
Made with WordArt

I thought it about time to add a list of curated C utilities such as compilers, IDES etc. So you’ll see that bar under the title now includes Links To C Utilities.

One of the included links is to Cheerp which is a C/C++ compiler that can output WebAssembly. One of my goals is to add a WebAssembly chapter to my first EBook, after the 2nd one on Linux is done.  I want to play my asteroids game in the browser.

I have used EmScriptem to do this but I’d like to see what other tools are available.