Factorio Forums

Truly magical edition of Friday Facts: http://www.factorio.com/blog/post/fff-42

Good to see you're making some good progress on the multiplayer

The wall's shadow is facing the wrong way anyway.

Anyway... I was pretty supprised when I first saw the sprite files that shadows weren't their own layer from the begining, so Yeah, seperating shadows of some items is a good step forward.

As for the new feature, I'm looking forward to giving it a try, it sounds like a good step forward too. Slider and editable number box, for rounded stacks, and precission respectively, good idea.

aww, why did you have to tell us about the shadow flipping on the player :/ I never noticed, and from now on, every time i change direction I will think 'that shadow is wrong'

If all shadows were removed from the game and nobody told me, I doubt I would ever notice.

jeroon wrote:aww, why did you have to tell us about the shadow flipping on the player :/ I never noticed, and from now on, every time i change direction I will think 'that shadow is wrong'

This is for you to appreciate it better once the problem will be solved : P

goertzenator wrote:If all shadows were removed from the game and nobody told me, I doubt I would ever notice.

You might think that, but shadows help to understand the geometry and height of objects without you even noticing.

Hello. I'm new to the forums, but I just wanted to see if I would be able to help at all with the shadow problem. I do not know a whole lot about programming, and I may be completely wrong with my suggestion, but I think what is going on is that whenever you programmed the game to render shadow, you programmed the area the shadow would get casted on to get darker. You might want to make it so that the whole area is covered with a sort of "blanket of gray". What I mean by this is that right now, the shadows might be saying, "This wall will cast a shadow and make the area darker by ADDING gray 2, and this wall will cast a shadow and make the same area darker by ADDING another gray 2. So, the whole area is gray 4 (The doubled shadow areas circled in red), whereas the areas around it are gray 2 (The single shadow areas)." (Here I am saying that there is an imaginary scale of grays from let's say 1-10 and each shadow added on makes the area more gray by adding 2). In order to solve this you may want to make it say something like this: "This wall will cast a shadow on this area, SETTING (not adding) it to gray 2. This other wall will cast a shadow on the same area and SET it to gray 2 (since it is already set to gray 2, it will not change). Now, All of the areas are gray 2, and the outlines are kept." I don't know if I'm completely wrong and I will sound like an idiot, but that is just how brain understands your problem. Please reply if what I just said was confusing and I need to reword it.

At the moment we are using a simple algorithm called AIMD.

Why do you care about that? Why not just use TCP and let it do all the heavy lifting for you?

The problem is the buffers. Hmm...

It's like a crowded street has much lower throughput, than a street, where the traffic flows. The same is it with TCP. You don't want to play with such a connection, cause it lags extremely.

rmedic wrote:Why do you care about that? Why not just use TCP and let it do all the heavy lifting for you?

TCP sends every packet twice (once each way), effectively cutting your bandwidth in half.

On a very unstable connection this might be ok (spamming packets until one gets through at half speed), but on a stable connection you can do better.

rmedic wrote:

At the moment we are using a simple algorithm called AIMD.

Why do you care about that? Why not just use TCP and let it do all the heavy lifting for you?

With UDP we get NAT punching basically for free. With TCP it would be more complicated. But maybe you are right and the map transfers should be built on top of TCP ... but this way it works good enough and I think future cube will solve this if needed

cube wrote:I think future cube will solve this if needed

A tip for future cube, Oculus bought and open sourced (MIT License, no commercial restrictions) RakNet, a great low level networking library designed for games. https://github.com/OculusVR/RakNet

While the post does not go into enough detail about the shadows for me to understand what you plan to do exactly, here's something of another perspective that might be useful, though i will disregard any limitations on the engine other than the 2D part.


What do I assume? Considering the top down perspective, we need to have shadows cast from tall objects onto shorter objects, but shadows cast onto tall objects need to be drawn differently to reflect the relative height of the caster and receiver. All objects in the world have a height that is known in advance (ex. power lines are the highest, belts the lowest). Finally, assume we have objects and their shadows as separate sprites. It might be possible to do the following:

As a preprocess, for all pixels in the sprites of objects, store its height from the ground. Only a few bits could be used if you discretize to a small number of height levels.
Render all shadow sprites into a separate offscreen buffer, call this the shadow buffer, in which you would need at least 1 bit per pixel to denote either shadowed or non-shadowed (though probably 8 bits in practice due to gpu restrictions).
Now render all object sprites, we use the height of the pixel to sample the shadow buffer at an offset in the direction opposite the light source (the sun). This offset will align the shadows neatly even on objects that are visibly taller than the ground.

What does it cost? Using fancy shaders, custom framebuffer, fancy texture storage formats, additional preprocessing tools.
What does this give us? Shadow buffer gives non-additive shadows, and the offset sampling gives a sense of relative height of different objects.


I just sort of thought of this at a late hour, so it's probably flawed in some way. Still, I'm curious to see if this could be attempted in the engine.

I never found any bugs myself so far, and if you didn't mentioned it I would have never noticed the shadows. I was too busy having fun.

Don't know if this has been put forward as an option yet...

For Shadow rendering,

Render the ground first,
On blank white image, render the shadows as black,
Overlay the shadow image onto the ground with a blend mode you like the look of.
Render everything else.

You won't have shadows on objects, unless you feel that those should be rendered as ground, like floors or train tracks. (Give modders the option of which later to render at)
You have all shadows exactly the same darkness, so you dont get shadow overlap issues.
The method is cheap as dirt, its just another layer of sprites, and only rendered at 1bit per pixel. And could be easily disabled for slow machines. (Could also be rendered at different scales for lower Vid Memory machines)


Cons are that you wont have shadows from the player going over some things, but you could just run a separate layer for things like power poles.

Does seperate rendering of shadows mean they will be able to react to the time of day?

no, because the shadows are still prerendered. That means, there is no data in the game to render the shadows from different directions.
In my opinion is separating shadows from the objects definitely the right way.

Other question. Have the developers ever thought about texture compression?
For example DXT or on modern OpenGL BPTC. This could be optionally enabled.

Fact_3011 wrote:no, because the shadows are still prerendered. That means, there is no data in the game to render the shadows from different directions.

But you can still flip them and stretch them. Obviously they wouldn't rotate around, but even moving on the x-axis would be a great improvement over what they are now.

Yes, this is possible, but with flipping or stretching, the shadows will no longer be correct. I don't think such an operation is useful.
On same images the difference would be very small, but a few shadows would completely fail.