Hello, another week has passed here, with part of the team still out in Taiwan. They should be back next week, with some news of their great adventure.
With the addition of high resolution sprites we have started pushing memory limits of GPUs much harder than we originally anticipated. Currently the game requires about 2.4 GB of VRAM for sprites alone, and then it can use couple hundred megabytes more for working buffers and minimap data.
While trying to optimize rendering we learned that the issue is quite complicated, as one optimization could improve performance on one PC, and worsen it on another PC even with a similar hardware configuration. For this reason we usually make it possible to turn these optimizations on or off in graphics options.
Since the beginning, Factorio was using so called sprite atlases - which are big textures with lot of individual sprites packed into them. The advantage of using them is that we can batch rendering of sprites that are in the same atlas, and reduce the total CPU overhead of creating many draw commands for the GPU. A disadvantage is that it might be harder for the graphics driver to fit this single large texture into VRAM, as opposed to a lot of small ones.
Since high resolution sprites don’t fit into the single largest supported atlas size any more, we started to sort them into logical atlases - things that are drawn usually together are put into the same atlas. So terrain tiles, shadows, GUI graphics, icons, and recently objects that are drawn under shadows, are all separated into their own atlases. This way we can keep most of the sprite batching intact, while overall enabling us to add a greater number of larger sprites.
Another problem we can solve is related to texture sampling. When you zoom out a lot, an entity which was 256 pixels wide could be only 32 pixels wide, which means only every 8th pixel from the source sprite is drawn. This can have be problem for the GPU’s texture cache, and can cause a significant framerate drop when zooming out. To solve this, we can enable mipmaps, which are pre-downsized versions of textures, from which the GPU will select the size that is the most appropriate for current scaling factor. This is what we did for trees in 0.14 and now for terrain and decoratives in 0.16. The disadvantage is that mipmaps take up extra VRAM, and sprites can’t be as tightly packed in the atlas because they would start to ‘bleed’ into each other in the downscaled versions.
With the ever increasing amount of high-resolution textures, we have some plans to implement some stronger VRAM optimizations later on. We will have some news on these as we develop them, but one way which coincides nicely with the high-resolution update, is the splitting of sprites from their shadows.
Right now trees are kept as single sprites, with the tree and tree shadow combined. We originally thought this would be a benefit, as it would reduce the number of sprites the game has to render by half, but in the case of trees, this leads to a lot of empty space in the sprite image:
The entire orange portion is just empty pixels that the GPU has to waste time sampling, which can be quite wasteful when there are hundreds of trees partially overlapping. A second downside is that they will take a larger amount of space in the sprite atlas, meaning a greater VRAM usage.
Splitting the shadow from the sprite also has some side effects, due to the overlapping shadow sprites all being merged before being rendered. This means there will no longer be the deep black areas where the old tree shadows would layer on each other. There is some further reading on shadow rendering in FFF-42.
This helps the terrain fit more naturally with the trees, and helps keep the darkness of the shadow consistent with the other entities. But has some downsides.
By removing the deep black areas, the resulting scene tends to look more flat, and our eyes see the colors as more washed out, even though they are the same on both sides. We can counter this problem by adding deeper shadows to the sprite itself, but this only works for trees using volumetric leaves, so we are reworking all the trees to work with this new system.
As it turns out, not so many people know that we package quite a few scenarios with the game. Personally I like scenarios because allow us to explore aspects Factorio gameplay in a more focused way. While generally we aim to make a fulfilling freeplay experience, we are always looking for other interesting ideas that work within the game. If you have no idea what I am talking about, look here:
The most interesting to me, is exploring the nature of competitive Factorio. This doesn't necessarily mean fighting killing each other toxic cut-throat competition, but giving that heart-racing high-pace action that you don't really find in the rest of the game.
Already we have two scenarios with a competitive nature:
Having written and played both of these quite extensively, I have some experience in what they 'feel' like. Honestly the fact you are working against other players in a meaningful way, really does give something the freeplay doesn't. Team production has the 'hit the floor running' pace that really feels pretty nice, there is this real rush to get the furnaces down and the smelters smelting before the other teams. Since PvP has a lot of setup options and game modes to pick, how it plays can vary a lot, but in general the concept leads to some great player interactions. Perhaps the name is a misnomer in this way, but PvP scenario can also be used to set up allied teams, just playing together with separate bases and technology progression, so it isn't always combat/competitive focused.
Honestly over the last few years of playing, especially on medium to large game servers, I find the freeplay Factorio experience quite calm and relaxing, almost a little boring at some points. I am not saying I have seen it all, but there is not so much thrill to this side of the game to me any longer. For me at least, scenarios let me employ the best parts of the games design, in a way that brings back the challenge and interesting gameplay decisions.
I am also thinking of starting an 'official' Factorio MP server, so we can showcase these scenarios with some planned events. There are a few questions related to this, and scenarios in general, that I would like to put forward:
I recently added a new game mode to the PvP scenario: Production score. The concept is simple enough, you will earn points for the amount of items your factory produces, and teams will compete to earn the most points. In general I think it is quite nice, as teams can compete somewhat indirectly with one another, and victory isn't solely dependant on military power.
Part of the result of this, is that the price generator I developed can be used for other things. It is done in a general way so it will dynamically calculate new prices when mods and other things are considered, and we can use it to make nice graphs such as the following:
Speaking of scenarios, I often see some issue raised that there is no easy way to share and install scenarios. Really that is quite true for stand alone scenarios, as you will need to copy the folder into some other scenario folder which might not exist in the user directory, or you can join a server hosting the scenario already and a copy will be saved locally. These are both quite messy and unviable methods.
Thankfully there is a very easy solution, and that is to pack your scenario into a mod. This essentially solves the problem of scenario distribution, and makes it as simple as adding any other community addition to the game. There is also the system, that mods that include only locale, campaigns and scenarios, are marked as 'non-game changing'. Since it doesn't affect the state of the game, the mod is completely ignored when dealing with mod syncing, and you won't have to worry about having the mod installed or not when joining any servers.
As an example of how it can be done, I have packaged one of my pet projects as a mod, so you can see how easy it is to package scenarios into mods: Factory floor.
As always, let us know what you think on our forum.
