Preparing for 0.990 release
I preparing the first build to be sent to the Steam for revision. I completed the most wanted feature – tutorials – and will switch to content updating. This includes integration of new nebulae and galaxies models, planet palettes and textures, and updating catalogs. Probably some fixes will be required after Steam review, which may delay the release. But the release build must be as polished as possible, this is very important, because start sales directly impacts on the overall profit during the whole lifetime of the software.
Changes since the last blog post:
This is the most important feature, which prevented me from making release on Steam two years ago. SE appears to be quite complex software for new users, so some built-in “teacher” was required. So two years ago I started to develop a simple scripting language, which will allow me to implement the tutorials. There are 7 of them: introduction to SE interface, basic controls like select and go to, free flight controls with WASD keys, time controls, the Universe map mode, the Chart mode, and the Star browser. During implementation of all these lessons I developed so large list of script commands, so I was needed the reference manual for myself. As a by-product, scipts enables creating the Overview app, and probably will lead to a new type of mods for SE – scripted tours.
More flat sea bottom makes lakes on arid planets look more interesting.
The next changes was already shown by HarbingerDawn in his last stream:
In reality, sunspots are distributed in mid latitudes on the Sun, avoiding polar regions, as well as equator:
SpaceEngine “seeds life” on a planet after generation of the planetary system, when changes atmospheric composition on the planet based on how life is developed (older planets have multicellular oxygen-producing life). But changed atmospheric composition may change the planet’s climate so hardly what it freezes out or falls into runaway greenhouse. In this case SE wipes out the life or changes its biome tor sub-glacial or aerial (if conditions are not so harsh like on Venus – moderate temperatures in clouds layer, and presence of water vapor). So Venus-like terrestrial planets or water vapor mini-neptunes may have aerial organic life, like some gas giants.
This options are helpful to search and explore real exoplanets. In this example, I found all exoplanets in a triple star systems. Entering very large search radius is safe in this case, because star browser will not generate billions of procedural stars, it will just check the star catalog.
This was actually implemented very long ago, probably even in 0.980, but I decided to finish it only now. Jets are particle-based, just like comet tails (they even uses the same class/data structure in the engine). Jets are animated, quickly swirling around. HarbingerDawn may show them in his next stream. The jet pointed to the camera is brighter and hotter than the opposite one because of relativistic blue shift due to subluminal speed of particles.
I always switch camera to “Follow” mode (with Shift-F) while piloting the ship in orbital or warp mode – this is more convenient. So now SE doing this switch automatically. You still can switch back to “Syncrot” manually (with Shift-R), if you want.
Recently I got a new 4k display (I used the 1080p TN display for 12 years!), and immediately fixed some annoying bugs/issues caused by Windows DPI scaling in SE. Now SE always renders image in a native display resolution, ignoring the scaling settings. Of course interface is too small at 4k, but this will be fixed in future updates. Also, loading window scales itself according to DPI, but with clear fonts and background texture.
Previously, stars size was not linked to display resolution, stars of the same magnitude always had the size of some constant amount of pixels. But when stretching SE window on a 4k display (or taking screenshot in 4k by resizing window on a smaller display), this lead to very small star size and apparent brightness. New option on the settings menu enables stars auto-rescaling based on window resolution, so what at 1080p stars have a size of “1”, at 2060p size of “2”, and so on.
I also made terrain LOD limiting on large resolutions. Terrain LOD is also linked to pixels, as like star size. On every display, SE attempts to render terrain textures at 1:1 pixel density (at LOD 0, the LOD -1 reduces that to 1:2, while LOD 1 improves to 2:1, like super-sampling). But at 4k screen, this means that engine needs to generate and render 4 times more textures – this is equivalent to using LOD 1 at 1080p screen. My GTX 1060 and RX 580 doesn’t very like that, so I forced to use LOD of -1. New option limits the internal LOD value based on screen resolution. It works like if you still have 1080p screen, even if your actual screen resolution is larger. By a gazing closely at textures on 4k display, you may notice what look like at LOD -1 (a bit blurry), but from a normal distance from screen they are still looks fine. The nearest terrain nodes are still have a forced 1:1 pixel density, so they will always look crisp.
Those are a long-wanted features. Displaying azimuth/height is helpful for using SE as a planetarium software before a real observations. Or just to look how high Mars will be tonight from your city.
First implementation of the geographical grid is just lines rendered above the planet’s surface (not projected onto actual terrain). Coordinate labels will be added in future.
Bugfixes: I didn’t log all fixes I making every day. Even logging fixes of noticeable bugs is not easy now, because I don’t remember if such bug existed in 0.980, or was added during this version development. Yeah, 2.5 years for a single update is too long. But it is coming to finish!
As always, you can discuss this post on the forum.