We have an amazing utility constant for `inserter_hand_stack_max_sprites` which allows us to render any amount of stacked items.
However no such constant exists for items on the belt. It's capped by the engine to 4.
The following stack has 100 items, however it only renders as 4.
The stack inserter renders properly.
[2.0.6] Missing utility constant for max belt stack size rendering.
- micromario
- Fast Inserter
- Posts: 107
- Joined: Thu Apr 05, 2018 11:53 am
- Contact:
- micromario
- Fast Inserter
- Posts: 107
- Joined: Thu Apr 05, 2018 11:53 am
- Contact:
Re: [2.0.6] Missing utility constant for max belt stack size rendering.
Can't believe this game even runs without the option of stacking items on belts like Nestle stacking human rights violations If this post hits 50 likes I will literally drink water lets change the world
-
- Burner Inserter
- Posts: 9
- Joined: Tue Jul 26, 2022 1:53 pm
- Contact:
Re: [2.0.6] Missing utility constant for max belt stack size rendering.
There is no need to build rockets. Just stack all the way to space.
Re: [2.0.6] Missing utility constant for max belt stack size rendering.
Not gonna happen, as long as I can help it, I am sorry.
From technical standpoint I strongly dislike that stacks on belts are visualised the way they are, which massively increases number of sprites rendered in factories that use belt stacking. In saves from feedback from playtesting I saw scenes with around 300k sprites, this previously happened only in scenes with high number of particles (like large turbine array) or big fight scenes ... Which is around the limit of our rendering pipeline.
Plus, it also creates problem when rendering splitters and underground belt structures, which is solved in just "good enough" way (but we still get reports about it looking bugged) for 4-tall stacks.
From technical standpoint I strongly dislike that stacks on belts are visualised the way they are, which massively increases number of sprites rendered in factories that use belt stacking. In saves from feedback from playtesting I saw scenes with around 300k sprites, this previously happened only in scenes with high number of particles (like large turbine array) or big fight scenes ... Which is around the limit of our rendering pipeline.
Plus, it also creates problem when rendering splitters and underground belt structures, which is solved in just "good enough" way (but we still get reports about it looking bugged) for 4-tall stacks.
-
- Manual Inserter
- Posts: 1
- Joined: Sun Sep 24, 2023 8:12 pm
- Contact:
Re: [2.0.6] Missing utility constant for max belt stack size rendering.
If it's that easy/possible to approach a sprite limit, is it possible for modders to limit the number of sprites rendered in a stack? For instance always rendering stacks as 2 tall even if there are 3 or 4 in the stack.
- micromario
- Fast Inserter
- Posts: 107
- Joined: Thu Apr 05, 2018 11:53 am
- Contact:
Re: [2.0.6] Missing utility constant for max belt stack size rendering.
Understandable. I suppose the only feasible solution would be to pre-bake the sets of 4 items into the atlas. From there you could construct taller stacks more efficiently by drawing four sprites at once instead of 1. This solution also would reduce the strain on the graphics pipeline in vanilla. To be honest, in my 400 hour base I was running space age on an integrated GPU. The FPS was dropping to 5-7 in some places with heavy belt stacking.
-
- Burner Inserter
- Posts: 11
- Joined: Wed Sep 06, 2023 6:26 am
- Contact:
Re: [2.0.6] Missing utility constant for max belt stack size rendering.
I'm no techie, but maybe there's an easier (for modders) solution? How about the game being able to bake a stack sprite in memory on the fly. That should be able to remove the need for modders to bake sprites, have a short loading time as you don't load all variations of sprites that you don't need and have improved FPS as you would bake the sprite in memory and render that. The only problem i see is that there's some darkness noise for the 60/s belts which can be solved by just applying the darkness dynamically over the baked sprite and another problem is variants. I haven't seen wild variant stacking yet (like the rich metals from K2 or something where you can easily see the color differences), but i'd assume it picks one variant and stacks it on top of each other, so the solution ends up being the same. Alternatively you can bake sprites and save them in a cache so they bake once and then get updated only when deleted or told to update such as on change of the game version and mod version from which the sprite was taken.
It sounds easier said than done so i'm sorry if i oversimplify something, i'm just trying to give ideas here, to help a little
It sounds easier said than done so i'm sorry if i oversimplify something, i'm just trying to give ideas here, to help a little