Some of the features I have been working on for Galaxial over the past week, including asteroids, salvaging and rendering optimisation.
Posted by StuartMorgan on Jan 21st, 2013
Added some slight colour variations to asteroids of the same rarity (common, precious etc.) so that they are now different shades of the original colour. I think this makes them look a bit more varied and realistic. It doesnt look that different from the screenshots below, but its a lot more noticeable actually in-game.
Also created an extra asteroid set to add some more variation, so that you dont notice asteroid graphics being repeated as often.
Fine tuned the sector and galaxy background colours as some of them seemed either too bright or dull. I also re-written most of the code and the data file format so that its simpler to modify them or add extra colours through modding.
Started to create the visual effects for railguns and salvaging modules. I had to re-write most of the engine/missile trail code so that it could be used for other more general purpose effects. The railgun projectiles will leave a faint trail behind them. It's not quite finished yet so theres no screenshot of the railgun effects.
With salvaging modules fitted, a ship will be able to reclaim resources from the wreckage left over from battle. Once the salvaging module has finished working on a part of wreckage, the reclaimed resources get put into the ships cargo and they can then unload them at a colony. The player controlled ship also needs to be able to do this, so wreckage objects have to become targetable (with the mouse) for the salvaging modules to work.
This could become a problem as I dont want wreckage to become in the way when you are trying to select an enemy ship that is behind it. Smaller objects are always rendered in front of larger ones.
I will be working further on wreckage salvaging this week.
Spent a bit of time profiling and optimising the object rendering code (ships, asteroids, wreckage) now that I have finished making changes to them and made some small improvements to the overall framerate.
All the objects are rendered using the Painters Algorithm which is rather inefficient. This makes it incredibly difficult to batch objects and render them all in one go. There is a lot of texture swapping and individual draw calls for each object.
Earlier in the development of the game I experimented rendering objects using the z-buffer. It didnt work very well and introduced artifacts and sharp edges around the depth mask for each object. All objects require transparency sorting, so have to use the painters algorithm for rendering.
Although the rendering technique is rather inefficient it still runs very fast, even on the older graphics cards I tested on.
For example, I ran the stress test on an older laptop which has an Intel Celeron T3500 (2.1 ghz, 2 cores) with a Geforce 8200m (not great for gaming) and the framerate was stable between 40 and 70 FPS, depending on how zoomed out the camera is. Not so good when v-sync was turned on, as it then went down to 30.
The stress test scenario has 50 sectors with 100 ships fighting at the same time in each of them (5,000 total) Ship movement, AI and combat is simulated in full detail even when you are not in the same sector to see it.
Compared with my development computer which is 4 years old now (AMD Phenom X4 9950, Geforce GTX 260) it runs the same stress test between 110 and 220 FPS. Thats with v-sync disabled and max settings.
Older single core CPU's likely wont run Galaxial very well. Especially the games with larger galaxies that have many thousands of ships. The game is heavily multi-threaded and will benefit greatly from a (fast) 2 core or 4 core processor.
Development Blog: www.stuart-morgan.blogspot.com