[posila] [0.16.31] No-crop flag shifts loader belt sprites

This subforum contains all the issues which we already resolved.
Post Reply
User avatar
Deadlock989
Smart Inserter
Smart Inserter
Posts: 2528
Joined: Fri Nov 06, 2015 7:41 pm

[posila] [0.16.31] No-crop flag shifts loader belt sprites

Post by Deadlock989 »

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):

Image

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):

Image

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.
Image

User avatar
Deadlock989
Smart Inserter
Smart Inserter
Posts: 2528
Joined: Fri Nov 06, 2015 7:41 pm

Re: [16.31] No-crop flag shifts loader belt sprites

Post by Deadlock989 »

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.
Image

Rseding91
Factorio Staff
Factorio Staff
Posts: 13173
Joined: Wed Jun 11, 2014 5:23 am
Contact:

Re: [16.31] No-crop flag shifts loader belt sprites

Post by Rseding91 »

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.
If you want to get ahold of me I'm almost always on Discord.

User avatar
Deadlock989
Smart Inserter
Smart Inserter
Posts: 2528
Joined: Fri Nov 06, 2015 7:41 pm

Re: [16.31] No-crop flag shifts loader belt sprites

Post by Deadlock989 »

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.
Image

posila
Factorio Staff
Factorio Staff
Posts: 5201
Joined: Thu Jun 11, 2015 1:35 pm
Contact:

Re: [posila] [0.16.31] No-crop flag shifts loader belt sprites

Post by posila »

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.

User avatar
Deadlock989
Smart Inserter
Smart Inserter
Posts: 2528
Joined: Fri Nov 06, 2015 7:41 pm

Re: [posila] [0.16.31] No-crop flag shifts loader belt sprites

Post by Deadlock989 »

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.
Image

User avatar
eradicator
Smart Inserter
Smart Inserter
Posts: 5206
Joined: Tue Jul 12, 2016 9:03 am
Contact:

Re: [posila] [0.16.31] No-crop flag shifts loader belt sprites

Post by eradicator »

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?

Rseding91
Factorio Staff
Factorio Staff
Posts: 13173
Joined: Wed Jun 11, 2014 5:23 am
Contact:

Re: [posila] [0.16.31] No-crop flag shifts loader belt sprites

Post by Rseding91 »

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.
If you want to get ahold of me I'm almost always on Discord.

Post Reply

Return to “Resolved Problems and Bugs”