Factorio Forums

some mods (eg: alien biomes) consume many tiles. It is nice to have variation, but it causes other problems.

I have 3 ideas that could allow more diverse surfaces within the 255 limit.
- given this a cosmetic only change, it only needs to be calculated for chunks that are being rendered on screen, i believe there can be huge shortcuts here.

1) per surface tile overrides, so that surfaces with 'alternate environments' (other planets, space, interior of factories) can say 'my grass tile here is X'
- only allows variety per surface, not inherent complexity on one surface (eg, dectorio)
- could be complicated by things which allow multiple surfaces to be seen at once (eg: train window)
- but only needs to be held for on-screen tiles, and could be done entirely GPU side as a switchout of a texture map as the player switches.
- increases startup time / time to transition to a new surface.

2a) allow a tile to have multiple variants, and a noise layer to pick which variant is rendered.
- only good for environment, but good for packing many types of desert/forest/grass/... into one tile for rendering variation (eg: alien biomes)
- only a cosmetic change, could potentially not be saved but only held for on-screen entities, at the cost of cpu usage as the user runs around.
- could be done entirely GPU side as an a function pass on the texture table.

2b) allow a tile to be created with a 'rotation / animation frame, or something' via a function call hook called when it is created. this would allow a user hook for an arbitrary function to decide what variant is needed at runtime;
- would allow player placed tiles to be much more dynamic (eg 'r to rotate' decorative tiles, so that placable decorative tiles with a direction to them or a minor color variation (dectorio/hazard concrete) can be packed in one tile
- has a runtime cost for tile placement (possibly even a runtime cost)

both of v2 varients result in more than 255 tiles needing to be rendered, i don't know where certain optimisations are done, and how much could be passed to the GPU to tweak the known texture coordinates based on an optional extra lookup step.

I would anticipate that the parameterised tiles would do something like load dyanmic tiles into the highest values first, so that the c++ level this hook is simply if tileType>normalTileCount renderTilePicture(tileFuncs[tileType]()) else render(tile[tileType])
If this is hooked into a noise generator it would require extra storage; probably a sparse array, given the tiles are sequentially walked for render it wouldn't have that many random seeks for a typical frame. or a full per-tile-in-chunk extra byte if the density of tiles was high enough, combined with the count of random seeks.

3c) provide a special noise layer just for tinting a tile tile, hooked to the rendering the same way pollution water is done.
- can only alter the colour base of a tile based on a pre-defined function
- still may require extra storage, if the color is cached - but only needs to be held for on-screen tiles, and could be done entirely GPU side as a shader.

Where would all of this information be stored? The reason the devs are refusing to increase the tile limit is because this would require more space in memory. So, as much as I’d like to have more tiles as well, unless we can find a method that doesn’t require storing anything in memory or convince them that increasing memory usage isn’t so bad these days, I don’t see this happening.

I think option 1 would not require per-tile storage, simply using a per-surface lookup table rather than a global one.
The same applies to 2a if noise functions are calculated on the fly, however I believe they're currently only executed on map generation so it wouldn't help.
2b definitely requires storing rotation information per tile.
3c would require mod-defined shaders. I'm pretty sure it's been stated the water pollution thing is very much hardcoded to be water-specific.

If noise functions could be computed on the fly, then potentially the entire terrain generation could be on-demand, and the only tiles that would need to be stored (and thus count to the 255 limit) are the ones placed manually. I could see that one happening, but only if wube themselves ran into the 255 tile limit.

All of the options will require more storage in some way, definitely in memory, but possibly also on disk, the catch is to find a storage overhead that only scales with the count of tiles of these types.
- given this a cosmetic only change, it only needs to be calculated for chunks that are being rendered on screen, this is what allows huge shortcuts here.

the fundamental limitation is that the index into the tiles, as stored in the map and several other places, can only be a byte

what is needed is a mechanism to have the some of those byte values trigger a calculation to select an alternate image variant than the core one selected

some of the above strategies will add substantial storage overhead, if materialized as a per-tile lookup that is pre-populated, even if not used.
- mitigated by a sparse array and lazy loading.

some of the above, if not carefully implemented, will have a substantial when overhead used, causing an untenable UPS impact

some of the above, if not carefully implemented, will have a substantial overhead in the rendering pipeline even if this feature is not used by any mod
- this is the core risk, as Wube would not add a cosmetic feature like this if it impacts everyone who doesn't use it
- the ability to mitigate this risk depends on how textures are referenced inside the engine, not something i know the details of - wube might just say 'nice idea, sorry, no way worth the code effort'

The memory representation of tiles surely is pretty performance critical and more lookups would definitely impact performance too.

But one option, that would cost absolutely no performance overhead would be to split Alien Biomes into multiple mods only containing a few or even just one biome each. That would allow users to consciously sacrifice a few biomes for the ability to use their favored collections of colored concrete, asphalt road and ores-as-pathing-material overhauls.

640 kB *cough* 255 tile types have to be enough for everyone.

Oktokolo wrote: ↑Mon Oct 31, 2022 7:25 pm But one option, that would cost absolutely no performance overhead would be to split Alien Biomes into multiple mods only containing a few or even just one biome each. That would allow users to consciously sacrifice a few biomes for the ability to use their favored collections of colored concrete, asphalt road and ores-as-pathing-material overhauls.

This is actually (kind of) a thing via startup options that are in the mod.

255 really isn't enough when you take into consideration everything else (there was once even a mod that added polluted variants of ground tiles, so take whatever you have and x3 at least), though.

But I get it. It would eat double the memory just pushing it one byte more, and there are already enough complaints about how they can't build even bigger. I just wish there was a better way. :/

FuryoftheStars wrote: ↑Mon Oct 31, 2022 7:39 pm I just wish there was a better way. :/

There is: Wait ten years. Chances are that doubling the demand for memory bandwidth is less a problem then...

The tile limit will be increased drastically for Space Age.
Read here for more details: viewtopic.php?p=589483#p589483

bNarFProfCrazy wrote: ↑Fri Sep 22, 2023 12:35 pm The tile limit will be increased drastically for Space Age.
Read here for more details: viewtopic.php?p=589483#p589483

*pumps fist into the air* Yeah baby!!