Empty space between tiles in Unity

I decided to dabble with Unity recently. The first project I wanted to play required me to use tilesets and tilemaps. I ended up finding a free tileset and followed a few tutorials, but whatever I did I always ended up with weird space between my tiles. Here is how I ended up fixing the empty space between tiles in Unity.

The problem

Empty space between tiles in Unity

Empty space between tiles in Unity

While looking at the scene view, I could not see the empty space but when I was switching to the game view I saw the image on the right. Since I was spending most of my time in the scene view, it took a while before I found that things were broken.

Once I saw the issue, I played with a few settings, trying various things. Double checked my tiles, their size, the import flow. Everything looked right. The one thing I never modified was my tileset. I assumed that it was built correctly since the import showed the tiles correctly. In hindsight, I should have investigated the tileset earlier.

After quite a bit of digging, I figured that in some cases (depending on the camera, pixel rounding, and such), Unity will go and pick pixels a little bit outside of the tile, taking the pixel next to the tile from the tileset. In my case, that pixel was transparent, so I ended up with transparent pixels in my tilemap.

The Solution

Tilemap using the fixed tileset

Tilemap using the fixed tileset

After reading a few proposed solutions, and trying them, the only one that worked for me was quite simple: add a bleed around my tiles. At that point, I was still exploring and was using only one tileset with a few tiles. This made manually editing the tileset easy enough.

A few sources that I investigated

Filesystem auto-complete while using docker in WSL

Besides simply using the command line, mounting directories is quite painful when using docker on Windows. Therefore, I tend to use WSL to run my docker commands. Still, auto-complete of local file and directories (when using docker’s -v option) is quite helpful. Here is a little bit of information on getting filesystem auto-complete while using docker in WSL.

For my local setup, I use Virtual Box and Docker Toolbox to run docker in a linux VM and you can find how I linked WSL with that VM in my other post.

My final goal was to be able to do a simple:
docker run –rm -v /mnt/d/data:/data -i -t calestar/ebook-utils COMMAND
where autocomplete for local directories (/mnt/d/data) works correctly in WSL.

In order to get to that point, I needed one simple thing: have part of the Windows filesystem mounted in the same directory on both (a) the linux VM and (b) WSL. Luckily for me WSL already links to the Windows filesystem: the D: drive is automatically mounted as /mnt/d.

Next step was to get the linux VM to get access to the files in the D: drive, and have them under /mnt/d. This part is specific to VirtualBox, I’m quite certain this can be done using Hyper-V (and Docker for Windows), but I haven’t tried it.

VirtualBox configuration

VirtualBox configuration

First thing to do is open VirtualBox and find the VM that is used by docker. In order to get the name of the VM to modify, open a Windows command prompt and run docker- machine env. In the output, you will find a a value associated with DOCKER_MACHINE_NAME. You will now shutdown the VM in order to modify it. To do so, simple right-click on the VM and select Close->ACPI Shutdown and confirm that you want to shut down the VM. With the VM shutdown, right-click on it and select Settings.

In the settings page, go into the Shared Folders category. This page is where the magic happens. You will need to add a new shared folder. The folder path is the path on you Windows filesystem (D: for me). The name of the share is in fact the path on the linux VM where docker runs (/mnt/d for me).

With this configuration done, it is time to start the VM once again. To do so, select your VM from the main menu, right-click on it and select Start->Headless Start.

It might take a little bit of time before the VM is up-and-running, but it should all be working now.

Running screen in WSL

I recently started using WSL (Windows Subsystem for Linux) quite a bit and ended up needing multiple tabs opened. Right now, WSL does not support having multiple tabs natively, and I had to find an alternative. I decided to go with the good old screen but ran into some issues while running screen in Windows Subsystem for Linux.

Since screen is pre-installed in WSL (Ubuntu), I assumed that it would be working out of the box. But while trying to run it, I ended up with various errors:

The quick fix would be to run screen as root (with sudo) but that annoyed me, I really wanted to run it as my user.

After a bit of googling around, I managed to find a fix that works for me: change the directory screen uses to store its internal information. Luckily, screen allows an environment variable to control this directory: SCREENDIR. I have zero credit to take for this solution, I only googled around and found a nice little one already working 🙂

I decided to go with a simple sub-directory under my home and use that:

Remember to edit ~/.bashrc to add the export line to make this permanent!


Docker command line in WSL

Using containers and Docker is the norm for a lot of developers out there nowadays, but using it on Windows can be painful. Here is a little documentation on how I’ve been using Docker command line in WSL (Windows Subsystem for Linux).

The main problem I was having with using Docker on Windows is quite simple: Docker is basically a series of command line tools (docker, docker-compose, docker-machine, …) and the Windows command prompt is not quite nice to use.

For a while, I was using Docker from a git-bash shell. It is better than nothing, but then I needed more and more Linux tools and got quite annoyed. In order to make things easier, I decided to install Ubuntu directly on my Windows 10 machine through WSL. In order to get that installed, simply follow this tutorial.

To run Docker on Windows, you have two choices:

  1. Docker for Windows, uses Hyper-V to run a Linux VM for Docker;
  2. Docker Toolbox, uses VirtualBox to run the Linux VM for Docker

Both of these will get the job done. I had to go with Docker Toolbox for one simple reason: I don’t have a Enterprise, Professional, or Education version of Windows 10, and it is needed to get Hyper-V running.

Once you have Docker (for Windows or Toolbox) running, you should be able to use all the command line commands through the Windows command prompt or git-bash. In order to get everything running on Ubuntu you will need to do one last thing: configure your Linux environment.

The first thing you will need to get your environment up-and-running is the value of your DOCKER_HOST environment variable. To get this value, simply run echo %DOCKER_HOST%  in a Windows command prompt (or  echo $DOCKER_HOST  in a git-bash console). In my case, the value is tcp:// . This gives you the IP/Port where your Docker daemon is listening.

Armed with this value, you will need to edit your bash initialization script in your Ubuntu installation. In order to do so, simply add the following at the end of your ~/.bash_profile file:

The value associated with DOCKER_HOST is the one we got a bit earlier, and the value associated with DOCKER_CERT_PATH is a file inside your Windows user’s home directory.

You should now be able to install the docker package and use any command line tools contained in it!