Factorio Forums

Soon, we will merge and release the first batch of the new icons, which will have base size 64x64 px and mipmaps.

If you are adding new prototypes by copying a base prototype and changing some values on it (for example by using table.deepcopy; which is probably the best way to add a new prototype if you don't want to make completely custom graphics), make sure you also set icon_size to size of your icon (don't rely on your icon_size being already set in the base mod), otherwise your mod won't load anymore after we change our icon sizes.

Ideally, you should clear all possible icon definitions on the copy (icon = nil, icon_size = nil, icons = nil) and define your own icon from scratch

So far we have ran into PowerCubes not being loadable with the first batch of the new icons (charger-station is not overwriting icon_size)

Is there any relevant performance penalty to just using icons= everywhere it's supported, even for single-layered icons?

eradicator wrote: ↑

Wed Jun 05, 2019 11:30 am

Is there any relevant performance penalty to just using icons= everywhere it's supported, even for single-layered icons?

Runtime-wise, there is no difference between the definitions for single-layered icons. Multi-layered ones, can be heavy on rendering (including render prepare, which is serial with update) ... if used for items that are shown on belts or in alt-mode in large quatities. E.g. making ores multilayered should raise some eyebrows.

I don't know what would be performance difference between parsing plain icon definition and layered icon definition in Lua. (probably not much)

I thought about making mipmaps available only for the layered icon definition and converting all base icons to it, but that would break even mods that correctly overwrite both icon and icon_size, but don't think of clearing icons to nil.

posila wrote: ↑

Wed Jun 05, 2019 12:03 pm

Runtime-wise, there is no difference between the definitions for single-layered icons.

That is very reassuring to know, thanks :).

posila wrote: ↑

Wed Jun 05, 2019 12:03 pm

Multi-layered ones, can be heavy on rendering (including render prepare, which is serial with update) ... if used for items that are shown on belts or in alt-mode in large quatities. E.g. making ores multilayered should raise some eyebrows.

Couldn't that be solved by pre-composing the final icon on startup? Icons aren't that large so the VRAM would be bearable? Would be great for using a mask to make every ore-variation a slightly different color shade, or similar ore-graphics generation.

eradicator wrote: ↑

Wed Jun 05, 2019 12:25 pm

Couldn't that be solved by pre-composing the final icon on startup? Icons aren't that large so the VRAM would be bearable? Would be great for using a mask to make every ore-variation a slightly different color shade, or similar ore-graphics generation.

It could, but better it could be an external tool that we don't have to bugfix and otherwise maintain. Like an image editor. I think it is bad as it is that we have content pipeline embedded in the game and keep building sprite atlases on player computers, essentially having to load everything into memory on the startup, so I am up for as little preprocessing steps as possible.

My body is ready

posila wrote: ↑

Wed Jun 05, 2019 2:01 pm

eradicator wrote: ↑

Wed Jun 05, 2019 12:25 pm

Couldn't that be solved by pre-composing the final icon on startup? Icons aren't that large so the VRAM would be bearable? Would be great for using a mask to make every ore-variation a slightly different color shade, or similar ore-graphics generation.

It could, but better it could be an external tool that we don't have to bugfix and otherwise maintain. Like an image editor. I think it is bad as it is that we have content pipeline embedded in the game and keep building sprite atlases on player computers, essentially having to load everything into memory on the startup, so I am up for as little preprocessing steps as possible.

I can totally understand your desire for wanting to keep the code-base clean. But from a modders perspective the layering is a really awesome feature for dynamicalls generating things based on other mods content that i know nothing about. Doing it in an image editor would be impossible. So i'm very greatful that it exists.

I also have belts with barrels on them ;).

eradicator wrote: ↑

Wed Jun 05, 2019 3:58 pm

I can totally understand your desire for wanting to keep the code-base clean. But from a modders perspective the layering is a really awesome feature for dynamicalls generating things based on other mods content that i know nothing about. Doing it in an image editor would be impossible. So i'm very greatful that it exists.

+1

I want GLSL shaders for my graphics. I said before in a thread that it was for prototype stage, but I've changed by mind. I want it for prototype and runtime. Real-time ray marching displays inside Factorio? Real-time animated icons? Turn Factorio into 3D? Why not?

Posila, do you accept bribes to change your mind?

Back to topic (to other things, I might respond in the hue thread)... in the end, we'll release just new ore icons + new ore item pictures with variations; so the change is not so dramatic and hopefully won't break any mods.

posila wrote: ↑

Thu Jun 06, 2019 9:44 pm

Back to topic (to other things, I might respond in the hue thread)... in the end, we'll release just new ore icons + new ore item pictures with variations; so the change is not so dramatic and hopefully won't break any mods.

So no mipmaps yet?

Deadlock989 wrote: ↑

Thu Jun 06, 2019 10:00 pm

So no mipmaps yet?

The icon mipmap definition will be in the engine, but will be used just for the ores in the base game. Mods will be able to start using it.

Nice one. Good times.

Another "minor" change related to icons.

I was visited by a prophet who gave me vision of a future, so in hopes to save my soul, I decided to limit number of picture variations that will be loaded from item prototype to number of 16.

Bang go my plans to have 720 variations of pebble in 0.5 degree rotations on belts.

You mean 1280 variations, all with 720 rotations each, right?