As they say “This is not a fork. This is a repository of scripts to automatically build Microsoft’s vscode repository into freely-licensed binaries with a community-driven default configuration.”

Microsoft’s code includes telemetry and tracking code. The code built here is the same as Microsoft’s but with that telemetry and tracking code removed. Also it includes builds for both ARM (32 and 64-bit) which you don’t get from Microsoft.

The Docs page provides info on how to copy JSON bindings from Visual Studio Code to VSCodium. I shall be giving this a try. Much as I like the code.headmelted.com Visual Studio Code, it doesn’t appear to be updated very often whereas VSCodium seems to be built every night.

Since I got asteroids running on a Raspberry Pi, I have decided I want to incorporate the temperature in the window caption when you switch it to debug mod by pressing Tab. Currently all that does is display position info on moving objects and bounding boxes.

But if I include that code in, I want to be sure that it only works when running on a Raspberry Pi. So I need some code to identify the system. A bit of digging and I discovered the Linux uname command. That link goes to an online man page for uname.

If I run uname -a on my Ubuntu 18.04LTS I get this.

Linux david-Virtual-Machine 4.15.0-96-generic #97-Ubuntu SMP Wed Apr 1 03:25:46 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux

And on my PI.

Linux raspberrypi 4.19.97-v7+ #1294 SMP Thu Jan 30 13:15:58 GMT 2020 armv7l GNU/Linux

In fact the uname -n command gives david-Virtual-Machine on Ubuntu and raspberrypi on the PI. These are the names though names are often changeable and what if someone is running ubuntu on a PI? Yes it is a thing. But the uname -m identifies the CPU.  x86-64 on my Ubuntu and armv71 on the pi.

I did a bit of digging and found a C program on stackoverflow that will do the same as uname.

#include 
#include 
#include 
#include <sys/utsname.h>

int main(void) {

   struct utsname buffer;

   errno = 0;
   if (uname(&buffer) != 0) {
      perror("uname");
      exit(EXIT_FAILURE);
   }

   printf("system name = %s\n", buffer.sysname);
   printf("node name   = %s\n", buffer.nodename);
   printf("release     = %s\n", buffer.release);
   printf("version     = %s\n", buffer.version);
   printf("machine     = %s\n", buffer.machine);

   #ifdef _GNU_SOURCE
      printf("domain name = %s\n", buffer.domainname);
   #endif

   return EXIT_SUCCESS;
}

And this is what it outputs on a PI.

system name = Linux
node name   = raspberrypi
release     = 4.19.97-v7+
version     = #1294 SMP Thu Jan 30 13:15:58 GMT 2020
machine     = armv7l

So that bit is easy to do. Next is getting the temperature, but that’s for another blog entry…

There are four types of moving object in the games. Asteroids in four sizes from 35×35, 70×70, 140×140 and 280×280 pixels, the player’s ship (fits in 64 x 64 pixels), alien ships (also in 64 x 64)  and a bullet which is solid 3×3 pixels with the four corners empty.

As these move around the screen at 60 frames per second, they will come into contact and the collision detection has to figure out when they hit or miss.

To make it more complicated, the asteroids and player’s ship come in 24 rotations, each by 15 degrees so detection has to take that into account. The image shows an asteroid just about to hit the player’s ship.. At the bottom you can see where another asteroid has been blown up (the 50 is the score) and there’s a bullet to the right.

The detection occurs in several stages. First each object has a bounding square. This is an invisible square that just fits round each object. For the player’s ship it’s 64 x 64 and it corresponds to the sizes of each asteroid. As the image shows, the two bounding boxes overlap and it’s in this overlap rectangle that we have to check for a possible collision.

First things first. Every frame all objects are moved and we have to detect if there’s a chance of a collision. This is done by dividing the entire playing area (set in the book to 1024 x 768) into 64 x 64 pixels cells.  I chose that as a convenient size. Once the object’s new x,y location has been calculated, I determine which cells it overlaps.

The player’s ship can fit completely into one cell but most times it is either overlapping two or four cells. Even a 3 x 3 bullet will occasionally overlap two or four cells but most of the time it will fit completely in one.  The largest Asteroid (280 x 280) always overlaps five or six cells in each direction so it gets added into to 25,30 or 36 cells each frame.  The image shows the grid of 64 x 64 cells and the asteroid overlaps 25 cells, the player’s ship just overlaps 4 cells. The number is a count of the number of overlapping item in each cell.   It’s the bounding box size that determines if it overlaps which is why the top left and bottom right empty cells of the asteroid still show 1.

In each cell, I keep a list of objects that overlap that cell. The first step is scanning all cells with overlapping objects in to see if there are two or more objects overlapping in that cell. The SDL library includes a function SDL_IntersectRect()  You pass in the two bounding rectangles of overlapping objects and it returns a rectangle of the intersection, which corresponds to the overlap in the image above. If there are multiple objects in a cell e.g. four then you have to check to see if any of those (1,2), (1,3), (1,4), (2,3), (2,4), (3,4) overlap.

The next bit is what makes it pixel perfect. For every object and its rotations, I have created a mask. It’s a file of bytes with a 1 value corresponding to every coloured pixel in the object and 0 to empty pixels.

I have stretched this image to make it the same aspect ratio and it shows 0s and 1s in the player’s ship mask.

The collision detection algorithm processes the intersection rectangle and calculates where each pixel in that rectangle falls in the corresponding mask (adjusting for rotations) of each object.  If either mask pixel is 0 then no collision occurs but if both are 1 then bam!

Although I could have used a mask of bits, it was quicker to use bytes.

During development I wanted to verify that it was pixel perfect, so I disabled explosions and instead when two pixels overlapped, I output a green pixel to highlight it. The image shows the player’s ship passing through an asteroid!

Today I found out about Romu (Rotate and Multiply) random number generators. Typically I’ve been using srand() in my asteroids game, so this is well worth a look.  Their code page lists functions, so they should be easy to plugin.