I would prefer not to talk about this, and instead look into the future and forget this episode altogether. You can refer to the 1.9 beta log in the Steam Forum for a purely technical overview of how 1.9 evolved. The new track tracing system developed in June is now powering what eventually became the 1.9 final design, and that’s what matters in the end.
Major speedup in complex track editing
Since at least 1.6, and for some cases even 1.2, there have been complaints about slowness while track editing around in complex areas. A major optimization was applied back in 1.7 for stations, but the problem persisted. While hunting down a track rendering issue at the end of the 1.9 beta I noticed than in addition to the bug, the area was very slow to edit. So after fixing the bug I investigated more, and realized the track conflict checker (which test tracks hits against roads and waters) was doing a huge amount of redundant work, scaling quadratically on the amount of tracks surrounding the edited track. This was fixed into linear scaling, and a very noticeable speedup was achieved for complex track editing.
(1.10) Footprint click selection for tracks
Have you ever edited a complex junction or station approach, and had trouble making sense of which track node is which, hunting for the correct one to move or delete a particular track? In 1.10 this will be easier since tracks can now be clicked at any point to select them:
Track nodes still have click priority, so clicking a node always selects their track, ignoring any background track. But when the area is clear of nodes, you can just hover your mouse around and click when the highlighted track is the one you want.
(1.10) New line drawing system
Version 1.10 main feature is a full rebuild of the world map. My intention is to look into every map layer and not just update it to a newer dataset, but also try to improve the whole process, from the file compression to the way the map is rendered on screen.
So before I start crunching the huge map files and waiting for multiple days for results, I want to make sure the game renderer is updated and improved. One area of improvement is the map lines. Line here means any line-like feature you see on the map: roads, rivers, streams, streets, channels, region borders, paths, etc. I want this system to be able to display richer lines, in particular lines with both axis texturing (like tracks), rather than just one axis.
Instead of a special line renderer just for the map, I wanted to do a single system, capable of both rendering tracks and map lines. So one side there is the track render system, which is full featured and very precise, but takes much more memory than the map lines. And in the other are the map lines, very simple in comparison, but taking little memory. The new system must be able to render lines as detailed and precisely positioned as tracks, with correct width size and scaling, while at the same time using little memory, like the map lines.
The new system is now implemented, and map line rendering has been ported over. As an experiment I tested using a road-like texture on some of the line types:
This is just a test! I would never use such a high contrast, high saturation texture for the world map. But it shows the fact map line textures can now be textured in both axis, and although it’s not visible in the screenshot, the texturing can also preserve precise measurements of meters-per-pixel as needed for tracks. For map lines this will be optional, since some lines, like region borders, are instead better rendered as pure pixel measured lines. I expect modders will do very interesting things with this new capability.
Additionally I also reviewed how map meshes (any textured polygon on the world map, like gardens, water, forests, squares, etc.) are stored, and optimized them. The end result is a more than 50% reduction in the required GPU memory to store the geometry of any given map tile.