The easiest things to do...


It's necessary, TARS.
Addon Developer
Jun 14, 2010
Reaction score
... Are the hardest to compute. And that truth hit me hard. So hard when I went to the barber the other day, she had a look at my hair and said "Whoa, you're losing your hair already, baldness is getting to you!" (true story). The thing was I knew that already. Because that thing made me pull my hair out.

That thing, is Tile Maker. It's an idea I have over a year and a half ago, that I started coding, and then kinda left as my interest for Orbiter lost temporarily. but now, I've been working on it and oh boy, did I not remember how hard was it.

So basically, Tile Maker is a tool that allows you to take an image, give it it's coordinates, and the tool will chop it up so that it's exactly at the locations you gave them. Easy enough, right?
Wrong. I thought that. And now when I remember going like "surely this can't be too hard", I violently facepalm. The first problem that arise is which tiles will be used? And that's actually relatively simple, you take the lat/lon coordinates of the bounds, and calculate the tile that is underneath each point. If the image is aligned with the North, and we'll assume it is to not make things anymore complicated than they are, then you only need two points to be able to define the rectangle and all the tiles it sits on. And, by extension, only two tiles to get the array of tiles in between.
So you need to have a function that given a coordinate, will return you the tile it sits on. But to do that, you need the tile definition level.
This level is the surface tile level in Orbiter. And you could either leave that option to the user, or you could go the harder way.
And in my initial thought, I wanted the tool to be used with as few clicks as possible. The best case scenario would be when you open a file in Tile Maker which has the image data as well as the coordinates, and without a single click, the tool will read the image and coordinates, and spit out the tiles already named properly and converted, along with a sample base file that contains all the tiles already defined. (Pretty cool, huh? Unfortunately we're far from here). So with that idea in mind, I had to actually come up with a way to calculate what would be the best tile level possible given the image and the coordinates. And the way I did is by calculating the resolution in °/px, and then comparing that to the resolution of a tile at each level. We then take the level with the resolution that matches most the image's resolution.

So with all that 'sorted' (I am not sure my maths even is right, so...), I went on and tackled the next problem: where to cut. It would be fine if the mage was already aligned on the Orbiter tile grid, but for 99.99999237060547% of chances (floating point precision error here), it won't.
So I need to translate that tile grid from 'Coordinates space' (if that even makes sense) to 'Image space'. Basically transform all those coordinates into pixel location values. One would say that it is easy, you take the image bounds and make everything relative to that, then multiply everything by the resolution to get the values in pixels.
I did think that, and somehow I still do. But after implementing it that way, I saw that it wasn't the good way to do it.

And that is more or less the last big challenge to overcome. I already am able to give a name on each of the tiles I am splitting (or could be able if the tiles were the right ones), create the surface base config file 'template' with the surface tiles section already filled in. The icing on the cake would be to have a DDS conversion algorithm, or use a library, or a command-line program... Well actually the icing on the cake would be to be able to split the image as accurately and as precisely as a Japanese chief preparing your sushi.

And I am waiting for this icing like waiting for the snow to arrive in the summer; I might be on the wrong side of the planet for that. :lol: