just got back into after some time away updated to the lasted version and noticed the electronic and advanced circuits on certain transport belts was a different colour first picture is a screen shot which everything looks normal.
this picture is what i see taken with my phone.
i cant see this been anything to do with hardware because it is only this part of the factory that does it. and fps is 51 here if i move to a different area with the same amount of belts i have 60 fps.
[1.1.53] Graphics bug with electronic circuits and advanced circuits when on a transport belt
Re: [1.1.53] Graphics bug with electronic circuits and advanced circuits when on a transport belt
i noticed the right belt with electric circuits on was dark green like the ones on the left. that belt feeds electric engines so i swapped it to a different belt.
all the belts going left are connected to processing units.
hope this helps
all the other light green electric circuits dont go anywhere yet. so it seems if the belt isnt connected to anything it changes colour.all the belts going left are connected to processing units.
hope this helps
-
- Long Handed Inserter
- Posts: 77
- Joined: Tue Dec 01, 2020 6:57 pm
- Contact:
Re: [1.1.53] Graphics bug with electronic circuits and advanced circuits when on a transport belt
Greetings;
GUESS: ZOOMING ISSUE, NOT A BUG; (alias moire)
While I do not posses the utmost knowledge on the internals, this looks a lot more like a zooming artifact to me.
Consider zooming in and out? Does it follow the pattern only for the specific zoom?
If so, it is a famous anti-aliasing artifact
It is known as moire pattern [wiki] in typography;
p.s. Hmm, a better link would be aliasing wiki page it even showcases the problem in the top picture.
Off-topic part:
In Factorio you can often see parts of the picture on the screen updated in different chunks on a seemingly "random" pattern.
Easy example would be map-thumbnail updates when the tile set_tiles is run each tick in a rainbow. If the left few reds are on the chunk or render-chunk border it might be the reason. But uneven dark green lines in the picture suggest a zooming artifact.
Even if small "unfair" pixels could be substituted to the expected-average-color instead to combat the "aliasing lense", there is little point to do that. A better take would be to make thumbnails (like a few x few pixels) for smaller zoom levels and render them instead (bigger error, but more "stable" pic and possibly less pix to bitblt').
But even that is questionable since it consumes additional chunks of gpu-mem which comes at a linear small yet leap price with rainbowish belts of modded stuff.
Personally though, I do not even CARE about each item on the belt THAT much.
If it would, say, change every 4 items of same type to a single one + bg-fill it would even be easier to look at and easier to spot full belts.
But then mixed-ore setups from scenarios come in. And any additional fps drop to belt items is not worth it! We already have huuuge drops for medium-to-big blups when they are rendered (full res!) in the cursor (moderate arty train on rails is a simple testcase), so let's just spare belts as they are. It works.
Good luck :>
GUESS: ZOOMING ISSUE, NOT A BUG; (alias moire)
While I do not posses the utmost knowledge on the internals, this looks a lot more like a zooming artifact to me.
Consider zooming in and out? Does it follow the pattern only for the specific zoom?
If so, it is a famous anti-aliasing artifact
It is known as moire pattern [wiki] in typography;
p.s. Hmm, a better link would be aliasing wiki page it even showcases the problem in the top picture.
Off-topic part:
In Factorio you can often see parts of the picture on the screen updated in different chunks on a seemingly "random" pattern.
Easy example would be map-thumbnail updates when the tile set_tiles is run each tick in a rainbow. If the left few reds are on the chunk or render-chunk border it might be the reason. But uneven dark green lines in the picture suggest a zooming artifact.
Even if small "unfair" pixels could be substituted to the expected-average-color instead to combat the "aliasing lense", there is little point to do that. A better take would be to make thumbnails (like a few x few pixels) for smaller zoom levels and render them instead (bigger error, but more "stable" pic and possibly less pix to bitblt').
But even that is questionable since it consumes additional chunks of gpu-mem which comes at a linear small yet leap price with rainbowish belts of modded stuff.
Personally though, I do not even CARE about each item on the belt THAT much.
If it would, say, change every 4 items of same type to a single one + bg-fill it would even be easier to look at and easier to spot full belts.
But then mixed-ore setups from scenarios come in. And any additional fps drop to belt items is not worth it! We already have huuuge drops for medium-to-big blups when they are rendered (full res!) in the cursor (moderate arty train on rails is a simple testcase), so let's just spare belts as they are. It works.
Good luck :>
Re: [1.1.53] Graphics bug with electronic circuits and advanced circuits when on a transport belt
Thanks for the report however i am not considering this to be a bug.
Item position on belts is taken with a resolution of 1/256th of a tile and an item on belt has a standard spacing of 64/256. That means some of the items which look differently may be simply due to a difference in the item position on screen related to different item position on belt. Most likely you have some differences in counts of curved belt pieces on those lines making it look different. I am not going to fix anything here as it would force me to make curved belt inner and outer transport lines to have a length which is multiple of 64 steps while right now they have length of 106/256 and 295/256.
If you are interested, some more details are in viewtopic.php?p=554468#p554468 - using outer lane of curved belt it is possible to obtain any of the 64 shifts of an item.
Item position on belts is taken with a resolution of 1/256th of a tile and an item on belt has a standard spacing of 64/256. That means some of the items which look differently may be simply due to a difference in the item position on screen related to different item position on belt. Most likely you have some differences in counts of curved belt pieces on those lines making it look different. I am not going to fix anything here as it would force me to make curved belt inner and outer transport lines to have a length which is multiple of 64 steps while right now they have length of 106/256 and 295/256.
If you are interested, some more details are in viewtopic.php?p=554468#p554468 - using outer lane of curved belt it is possible to obtain any of the 64 shifts of an item.