Factorio Forums

Following this: viewtopic.php?f=48&t=58875

If you use layered belt animations, you need to add the no-crop flag to make sure that the sprites are the same size in each layer for entities with both a belt animation and a structure{} field, i.e. underground belts and loaders.

The issue is that with loaders, but not undergrounds, adding no-crop shifts the main horizontal/vertical belt graphic inwards (by two pixels in normal resolution and four pixels in high resolution) away from the ending/starting patch.

Examples (vanilla loader on the left, modded 1x1 loader in the middle, underground belt on the right for comparison):

Without no-crop (belts are correctly aligned but top layer flies about chaotically depending on the cropping):



With no-crop (layers are correctly aligned with each other but for the loaders, the main belt component moves away slightly from the ending/starting patch):



I realise that is not the biggest bug in the world, and also that loaders are not officially part of the vanilla game. That said, I've spent about three hours banging my head on it, and loaders are hugely popular on the modding scene. Any advice or a quick look at how no-crop positions the belt wrongly for loaders but correctly for undergrounds would be massively appreciated.

BTW - the reason I'm doing this is (a) the great ease of generating arbitrary colours of belt and (b) it greatly saves atlas space. It's potentially an atlas saving strategy for the main game. For vanilla belts, you save 33% of the atlas space by having just two no-cropped sprite sheets which then generate the three belt colours (by tinting the top layer). If you use mods to add more belt tiers, you get more and more savings. It's two sheets for belts regardless of the number of belt tiers you have.

Deadlock989 wrote:BTW - the reason I'm doing this is (a) the great ease of generating arbitrary colours of belt and (b) it greatly saves atlas space. It's potentially an atlas saving strategy for the main game. For vanilla belts, you save 33% of the atlas space by having just two no-cropped sprite sheets which then generate the three belt colours (by tinting the top layer). If you use mods to add more belt tiers, you get more and more savings. It's two sheets for belts regardless of the number of belt tiers you have.

It's a trade off: by using layering you increase the amount of time the game has to spend rendering sprites but reduce VRAM usage.

Rseding91 wrote:It's a trade off: by using layering you increase the amount of time the game has to spend rendering sprites but reduce VRAM usage.

So is this a bad idea? Or one of those trade-offs that benefit some PC builds but disadvantage others? Would it be better for people, say, with low-VRAM laptop graphics but a decent CPU?

It's an annoying glitch in the rendering but if it's not recommended to have layered belts at all then I'll give up on the idea.

It's hard to tell. I think it doesn't matter too much, total spritesheet size of belts is quite small compared to entities with rotations or large entities with long animations like electric mining drill; at the same time even if there is 1000 belts on screen I don't think it would matter too much if belt was drawn in 2 layers instead of just one (but kovarex believes it matters, so we have not separated arrows to separate layer ourselves when upgrading belts to high-res)

Anyway, the bug reported here is fixed for next release.

posila wrote:It's hard to tell. I think it doesn't matter too much, total spritesheet size of belts is quite small compared to entities with rotations or large entities with long animations like electric mining drill; at the same time even if there is 1000 belts on screen I don't think it would matter too much if belt was drawn in 2 layers instead of just one (but kovarex believes it matters, so we have not separated arrows to separate layer ourselves when upgrading belts to high-res)

Anyway, the bug reported here is fixed for next release.

That's brilliant, many many thanks.

I think I'll add it as a default-to-off option and let punters make their own mind up.

A quick off-topic question on the topic of saving VRAM usage: How intelligent is the engine about detecting identical frames? If i have an animation that is 99 times frame_a and one time frame_b, does it allocate each frame_a or save space by only putting one frame_a into the atlas?

eradicator wrote:A quick off-topic question on the topic of saving VRAM usage: How intelligent is the engine about detecting identical frames? If i have an animation that is 99 times frame_a and one time frame_b, does it allocate each frame_a or save space by only putting one frame_a into the atlas?

There is no identical frame detection logic.