Friday Facts #42

Regular reports on Factorio development.
slpwnd
Factorio Staff
Factorio Staff
Posts: 1835
Joined: Sun Feb 03, 2013 2:51 pm
Contact:

Friday Facts #42

Post by slpwnd »

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

TheWombatGuru
Long Handed Inserter
Long Handed Inserter
Posts: 57
Joined: Tue Jul 08, 2014 10:01 am
Contact:

Re: Friday Facts #42

Post by TheWombatGuru »

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

User avatar
bobingabout
Smart Inserter
Smart Inserter
Posts: 7351
Joined: Fri May 09, 2014 1:01 pm
Contact:

Re: Friday Facts #42

Post by bobingabout »

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.
Creator of Bob's mods. Expanding your gameplay since version 0.9.8.
I also have a Patreon.

jeroon
Filter Inserter
Filter Inserter
Posts: 351
Joined: Sun Jan 26, 2014 10:18 am
Contact:

Re: Friday Facts #42

Post by jeroon »

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' :P

goertzenator
Inserter
Inserter
Posts: 30
Joined: Thu Feb 20, 2014 8:59 pm
Contact:

Re: Friday Facts #42

Post by goertzenator »

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

Albert
Factorio Staff
Factorio Staff
Posts: 55
Joined: Tue Apr 09, 2013 5:35 pm
Contact:

Re: Friday Facts #42

Post by Albert »

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' :P
This is for you to appreciate it better once the problem will be solved : P

kovarex
Factorio Staff
Factorio Staff
Posts: 8078
Joined: Wed Feb 06, 2013 12:00 am
Contact:

Re: Friday Facts #42

Post by kovarex »

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.

Praetorian_Gaming
Manual Inserter
Manual Inserter
Posts: 1
Joined: Fri Jul 11, 2014 6:23 pm
Contact:

Re: Friday Facts #42

Post by Praetorian_Gaming »

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.

rmedic
Manual Inserter
Manual Inserter
Posts: 1
Joined: Fri Jul 11, 2014 6:32 pm
Contact:

Re: Friday Facts #42

Post by rmedic »

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?

User avatar
ssilk
Global Moderator
Global Moderator
Posts: 12888
Joined: Tue Apr 16, 2013 10:35 pm
Contact:

Re: Friday Facts #42

Post by ssilk »

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.
Cool suggestion: Eatable MOUSE-pointers.
Have you used the Advanced Search today?
Need help, question? FAQ - Wiki - Forum help
I still like small signatures...

User avatar
DaveMcW
Smart Inserter
Smart Inserter
Posts: 3699
Joined: Tue May 13, 2014 11:06 am
Contact:

Re: Friday Facts #42

Post by DaveMcW »

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.

User avatar
cube
Former Staff
Former Staff
Posts: 1111
Joined: Tue Mar 05, 2013 8:14 pm
Contact:

Re: Friday Facts #42

Post by cube »

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 :)
I have no idea what I'm talking about.

JamesOFarrell
Filter Inserter
Filter Inserter
Posts: 402
Joined: Fri May 23, 2014 8:54 am
Contact:

Re: Friday Facts #42

Post by JamesOFarrell »

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

Kikkers
Fast Inserter
Fast Inserter
Posts: 109
Joined: Sun Jun 22, 2014 8:45 pm
Contact:

Re: Friday Facts #42

Post by Kikkers »

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.

Zequez
Long Handed Inserter
Long Handed Inserter
Posts: 64
Joined: Sat May 03, 2014 2:59 am
Contact:

Re: Friday Facts #42

Post by Zequez »

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.

Silverware
Manual Inserter
Manual Inserter
Posts: 1
Joined: Sat Jul 12, 2014 3:52 am
Contact:

Re: Friday Facts #42

Post by Silverware »

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.

Rahjital
Filter Inserter
Filter Inserter
Posts: 435
Joined: Thu May 29, 2014 10:44 am
Contact:

Re: Friday Facts #42

Post by Rahjital »

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

Fact_3011
Burner Inserter
Burner Inserter
Posts: 14
Joined: Tue Jun 24, 2014 11:41 am
Contact:

Re: Friday Facts #42

Post by Fact_3011 »

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.

Rahjital
Filter Inserter
Filter Inserter
Posts: 435
Joined: Thu May 29, 2014 10:44 am
Contact:

Re: Friday Facts #42

Post by Rahjital »

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.

Fact_3011
Burner Inserter
Burner Inserter
Posts: 14
Joined: Tue Jun 24, 2014 11:41 am
Contact:

Re: Friday Facts #42

Post by Fact_3011 »

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.

Post Reply

Return to “News”