Author Topic: Changes to the smoke-parameter for buildings (and ideas around that)  (Read 1200 times)

0 Members and 1 Guest are viewing this topic.

Offline Leartin

Smoke in Simutrans is a good idea. Buildings are generally static, but if a factory is producing, it indicated that by a two-frame animation of smoke up the chimney - or similar two-frame-animation.

However, the good idea is kind of ruined by other advances Simutrans made, most importantly animation with no frame limit. With that, it's possible to have, say, an animated oilpump. Even smoke is sometimes better done as an animated frontimage - simply because there might be several chimneys, and you can only have one smoke per factory defined. Furthermore, Smoke is limited to factories only, while any building can have frontimages and animation, so using those is more consistent in the creation process.
There are still advantages to smoke - it is easier to use the same smoke in several buildings, and if it is reused, storage space in the pak format is smaller (since references are used, rather than the same thing stored individually for each building) And, of course, it's still the only thing that can be shown only if a factory works.

On that basis, I want to suggest the following changes:

1.) A new parameter "animate_when_active"
A parameter for factories, which is usually set to 0. However, if set to 1, the animation of the factory is frozen to the first frame as long as it is not productive.
Essentially, this enables animation to replace smoke as an indicator whether a factory is actually producing. Smoke can only add to a building,which would not work with the aforementioned oilpump, which would need to be visible at all time.

2.) No smoke-frame-limit
Currently, smoke only has two frames, which to me is the most important reason why I would not use it, except maybe for some blinking lights. If that was changed, I could see using it for several animations I currently use frontimages for. But there could be more:

3.) Enable smoke for all buildings
This is about smokes second ability: It is a graphic that's only referenced, not actually put in a pak-file. Most obviously, my endeavour to give most residential buildings some animated smoke in winter would greatly profit from such a possibility (if either the building or the smoke itself can be restricted to snowy winter). But I guess there are many small additions one could put in a smoke image just to have some tiny movements here and there.
Say, a smoke image with a hundred empty frames, and then a mole looks up through the floor. Could be places anywhere with some open ground, thus why not place it in several different buildings?

4.) More then one smoke per building
Most obviously, this would be nice if you have four chimneys on your coal power plant, so you could place a smoke on each. But also considering potential season-related animations (winter smoke of buildings) or rarely visible animations (mole from the ground) at some point, you would want to add some of them together.

5.) Allow the user to disable smoke
Now all these smoke-related animations are nothing but eyecandy, right? Nothing that is really needed, but could affect performance, so why do that to older computers? Well, usually there is no choice. You could hardly create a function to "disable all frontimages", since that would plainly be terrible. Stopping all animations, while working, is not ideal - imagine all these houses in winter with static smoke at their chimney. No smoke at all would be better, right? That means I either create it for nicer graphics on better PCs, or I don't, for the sake of older ones.
Now, smoke is a bit different. As said, in contrast to building animation, smoke only adds stuff to a building that already works without it. And that's how it should be: If a smoke reference is not found, it should not be replaced (nobody wants the mole to look out of the chimney), and the building should still be good, if not quite great. This is true for current smoke as well, obviously, since if not producing, factories won't have it.
So if it was disabled by the player, the gameplay would not change at all, just the graphics would not be quite as nice. And not all animation is lost - oilpumps would still pump on ;)

Offline Ters

  • Coder/patcher
  • Devotee
  • *
  • Posts: 4451
  • Total likes: 141
  • Helpful: 105
  • Languages: EN, NO
Re: Changes to the smoke-parameter for buildings (and ideas around that)
« Reply #1 on: January 23, 2017, 04:22:11 PM »
2.) No smoke-frame-limit
Currently, smoke only has two frames, which to me is the most important reason why I would not use it, except maybe for some blinking lights. If that was changed, I could see using it for several animations I currently use frontimages for.

It is difficult to see that they are animated with all the frames due to them overlapping, but there are factories in pak64 that has smoke with more than two frames. When the same smoke is used for trains, it certainly has more than two frames. There are however factories with just two, or even just one, frame smokes.

Offline Leartin

Re: Changes to the smoke-parameter for buildings (and ideas around that)
« Reply #2 on: January 23, 2017, 05:10:43 PM »
It is difficult to see that they are animated with all the frames due to them overlapping, but there are factories in pak64 that has smoke with more than two frames. When the same smoke is used for trains, it certainly has more than two frames. There are however factories with just two, or even just one, frame smokes.
It's possible the restriction was once lifted, I did not try myself - I was still under the impression it would be two for buildings and five for trains.

Offline An_dz

  • Web Admin
  • Administrator
  • *
  • Posts: 2439
  • Total likes: 221
  • Helpful: 85
  • D'oh
    • by An_dz
  • Languages: PT, EN, (it, de)
Re: Changes to the smoke-parameter for buildings (and ideas around that)
« Reply #3 on: January 23, 2017, 06:41:54 PM »
Leartin's smoke must be a new smoke type. The current smoke is simply an image that moves on the screen, Leartin's idea is to make smoke as framed animation.

Offline Ters

  • Coder/patcher
  • Devotee
  • *
  • Posts: 4451
  • Total likes: 141
  • Helpful: 105
  • Languages: EN, NO
Re: Changes to the smoke-parameter for buildings (and ideas around that)
« Reply #4 on: January 23, 2017, 06:46:20 PM »
Leartin's smoke must be a new smoke type. The current smoke is simply an image that moves on the screen, Leartin's idea is to make smoke as framed animation.

No, smoke has been animated in Simutrans since at least 2008. That's how far back I can trace the image containing smoke animations in pak64.

Offline prissi

  • Developer
  • Administrator
  • *
  • Posts: 8561
  • Total likes: 253
  • Helpful: 226
  • Languages: De,EN,JP
Re: Changes to the smoke-parameter for buildings (and ideas around that)
« Reply #5 on: January 24, 2017, 12:29:47 AM »
Smoke for factories and trains is the same. Hence those could easily have more than one frame of animation changed every 2.5 seconds. Than was introduced when raucher_t was changed into smake_t, which has been chnaged Nov 2006 (r452). The movement of the smoke is just in vertical direction, but the starting position is slightly random.

Currently factories are derived from buildings. As such each tile could have an animation independent from the other tiles, and the building does not know that it belongs to a factory. However, in principle stopping (and starting) animation is possible, one just need to remove/add the factory buildings to the animation list.

However, I am not sure the animation for factories when working goes the same way as the sound for factories when producing ...

Offline Leartin

Re: Changes to the smoke-parameter for buildings (and ideas around that)
« Reply #6 on: January 27, 2017, 09:31:29 AM »
Leartin's smoke must be a new smoke type. The current smoke is simply an image that moves on the screen, Leartin's idea is to make smoke as framed animation.

Let's say my idea is to use smoke as an excuse for a broader possibility to define animated graphics via reference, rather than normal animation/frontimage. Smoke just has a bunch of unique features, which I could see being useful elsewhere as well.

However, I am not sure the animation for factories when working goes the same way as the sound for factories when producing ...
There is sound for factories? O.O First time I hear that.

Offline prissi

  • Developer
  • Administrator
  • *
  • Posts: 8561
  • Total likes: 253
  • Helpful: 226
  • Languages: De,EN,JP
Re: Changes to the smoke-parameter for buildings (and ideas around that)
« Reply #7 on: January 27, 2017, 12:35:37 PM »
I made a patch, but after ambient sounds (waves for sea, birds for forest etc) were implemented but not used outside pak64 (or has that changed), I did not follow up on that. But it would be not too hard to add factory sounds.

Offline Leartin

Re: Changes to the smoke-parameter for buildings (and ideas around that)
« Reply #8 on: January 29, 2017, 01:47:39 PM »
I made a patch, but after ambient sounds (waves for sea, birds for forest etc) were implemented but not used outside pak64 (or has that changed), I did not follow up on that. But it would be not too hard to add factory sounds.

Maybe due to lack of documentation? Would not be the first time nobody uses a new function simply because nobody knows how, or that it even exists.

Either way, I think the obvious difference between 'animated when producing' and 'sounds when producing' is that there are already animations which could be changed to act like that. Eg. that animated bulldozer in one of pak64 factories. Sounds on the other hand would need to be found on the internet with a proper license and adjusted to fit in with other sounds, which isn't something pak-developers are familiar with in the first place.

Offline prissi

  • Developer
  • Administrator
  • *
  • Posts: 8561
  • Total likes: 253
  • Helpful: 226
  • Languages: De,EN,JP
Re: Changes to the smoke-parameter for buildings (and ideas around that)
« Reply #9 on: February 05, 2017, 05:08:51 AM »
Only playing animation when producing was trivial. Also preliminary sound support added in r8067, new parameter sound_intervall (ms) and sound_id. Needs new makeobj ...

Offline Leartin

Re: Changes to the smoke-parameter for buildings (and ideas around that)
« Reply #10 on: February 22, 2017, 09:03:05 AM »
Since this thread already exists, might as well go here:

Yesterday I played around with smoke, since I learned there is no frame limit and transparency would require some changes to smoke eventually. I used this graphic for testing purposes: http://gushh.net/blog/wp-content/uploads/2011/06/smoke_1_40_128.png

Now I can confirm that the animation works, even with 40 frames and transparencies, but I came across 2 Limits:

First the buggish one: Smoke Size. It seems like the dirty-code for smoke is still hardcoded to 64px graphics, since I got a LOT of dirt.
Spawning and Despawning rates seem to be fixed for vehicles. While industry has a parameter "smoke_speed", it did not work with vehicles. Which means quicker vehicles are stuck with generating a little smoke-puff about every tile, with 5 of them existing at any one time. Shouldn't they be somewhat connected to create one long smoke-pipe along the route - so they would need to spawn more often?

Offline Dwachs

  • DevTeam, Coder/patcher
  • Administrator
  • *
  • Posts: 4068
  • Total likes: 98
  • Helpful: 146
  • Languages: EN, DE, AT
Re: Changes to the smoke-parameter for buildings (and ideas around that)
« Reply #11 on: February 22, 2017, 11:18:52 AM »
To fix the dirty pixel bug: Can you upload a vehicle and smoke object, where this can be tested?
Parsley, sage, rosemary, and maggikraut.

Offline Leartin

Re: Changes to the smoke-parameter for buildings (and ideas around that)
« Reply #12 on: February 22, 2017, 05:03:22 PM »
Sure:
http://dl.dropbox.com/s/utn5ize8zk02moh/newsmoke.png <-- Graphic
Code: [Select]
obj=smoke
name=Steam3
image[0-40]=newsmoke.<$0/8>.<$0%8>

https://www.dropbox.com/s/vpfrfcl7x7b7gaf/smoke.Steam3.pak?dl=0 <- Pak file



Since this replaces normal smoke, pretty much any steam loco should work, eg. Adler - but the quicker the loco, the more artifacts you will see.

Offline TurfIt

Re: Changes to the smoke-parameter for buildings (and ideas around that)
« Reply #13 on: February 22, 2017, 11:22:59 PM »
First the buggish one: Smoke Size. It seems like the dirty-code for smoke is still hardcoded to 64px graphics, since I got a LOT of dirt.
Spawning and Despawning rates seem to be fixed for vehicles. While industry has a parameter "smoke_speed", it did not work with vehicles. Which means quicker vehicles are stuck with generating a little smoke-puff about every tile, with 5 of them existing at any one time. Shouldn't they be somewhat connected to create one long smoke-pipe along the route - so they would need to spawn more often?
Not hardcoded to 64, but hardcoded to expect the images don't differ in size much. Your humungous cloud broke that... Should be fixed with r8113.
Spawning is fixed to approx every 500ms, and each is limited to a life of 2500ms.

IMHO, that is way too large of a cloud, and especially if you're using alpha, that'll kill the game in early years when lots is on the map.
I did notice an anomaly where the smoke spans multithreaded rendering regions, perhaps due to how far away from the vehicle the smoke is appearing - 4 tiles, or maybe because the cloud itself is so large.

Offline Leartin

Re: Changes to the smoke-parameter for buildings (and ideas around that)
« Reply #14 on: February 23, 2017, 08:47:13 AM »
IMHO, that is way too large of a cloud, and especially if you're using alpha, that'll kill the game in early years when lots is on the map.
I did notice an anomaly where the smoke spans multithreaded rendering regions, perhaps due to how far away from the vehicle the smoke is appearing - 4 tiles, or maybe because the cloud itself is so large.

But it would kill the game looking fabulous! ;)
Yes, this is too much. But you need to know what's possible, and I learned with this test. Besides, as long as spawning is fixed, no smoke will look too good anyway, even this just looks silly on fast trains with 5 seperated clouds.

Offline Dwachs

  • DevTeam, Coder/patcher
  • Administrator
  • *
  • Posts: 4068
  • Total likes: 98
  • Helpful: 146
  • Languages: EN, DE, AT
Re: Changes to the smoke-parameter for buildings (and ideas around that)
« Reply #15 on: February 23, 2017, 04:16:00 PM »
I did notice an anomaly where the smoke spans multithreaded rendering regions, perhaps due to how far away from the vehicle the smoke is appearing - 4 tiles, or maybe because the cloud itself is so large.
This is not related to multithreading, it is a bug in the clipping stuff.
Parsley, sage, rosemary, and maggikraut.

Offline Dwachs

  • DevTeam, Coder/patcher
  • Administrator
  • *
  • Posts: 4068
  • Total likes: 98
  • Helpful: 146
  • Languages: EN, DE, AT
Re: Changes to the smoke-parameter for buildings (and ideas around that)
« Reply #16 on: February 24, 2017, 04:06:22 PM »
The problem was that certain portions of tiles were drawn twice. This is a problem if alpha transparency is involved.

I committed a fix to this problem with r8116. I am not completely sure that this did not break anything else. Please watch out for clipping errors.

These clouds are fantastic!
Parsley, sage, rosemary, and maggikraut.

Offline jamespetts

  • Simitrans-Extended project coordinator
  • Devotee
  • *
  • Posts: 14762
  • Total likes: 307
  • Helpful: 143
  • Cake baker
    • Bridgewater-Brunel
  • Languages: EN
Re: Changes to the smoke-parameter for buildings (and ideas around that)
« Reply #17 on: February 24, 2017, 04:08:38 PM »
May I ask under what license that these clouds are released and whether they might be made available under the Artistic Licence to enable their inclusion in Pak128.Britain(-Ex)?
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

Offline An_dz

  • Web Admin
  • Administrator
  • *
  • Posts: 2439
  • Total likes: 221
  • Helpful: 85
  • D'oh
    • by An_dz
  • Languages: PT, EN, (it, de)
Re: Changes to the smoke-parameter for buildings (and ideas around that)
« Reply #18 on: February 24, 2017, 05:41:02 PM »
I highly believe it's CC-BY-SA 3.0, but it's better to wait for a confirmation from Leartin.

Offline Leartin

Re: Changes to the smoke-parameter for buildings (and ideas around that)
« Reply #19 on: February 25, 2017, 06:56:45 PM »
Sorry - as I said they were a testing graphic, not intended to be actually used! I am not the creator of these clouds, they were made by GuShH.

However, there license is actually quite simple: "You may use them for private or freeware (open source only) projects. Commercial use is prohibited, please contact me regarding licensing or custom work." - that's it, completely compatible with Artistic License. Not quite compatible with CC-BY-SA.

Just use the one I linked, since they are actually 128p, rather than my resized ones from the Dropbox.

Offline TurfIt

Re: Changes to the smoke-parameter for buildings (and ideas around that)
« Reply #20 on: February 25, 2017, 07:44:16 PM »
Besides, as long as spawning is fixed, no smoke will look too good anyway, even this just looks silly on fast trains with 5 seperated clouds.
What do you suggest is required to allow it to look good?
Parameters for spawn rate? lifetime? spawning not tied to time? animation rate?
What about the fixed movement currently applied? Parameters for speed/direction of movement?  (IMHO any movement needs to be contained to the tile [or maybe a slight overrun cheat...], but I certainly don't want to see smoke hopping tiles)

Offline Leartin

Re: Changes to the smoke-parameter for buildings (and ideas around that)
« Reply #21 on: February 25, 2017, 11:12:25 PM »
What do you suggest is required to allow it to look good?
Parameters for spawn rate? lifetime? spawning not tied to time? animation rate?
What about the fixed movement currently applied? Parameters for speed/direction of movement?  (IMHO any movement needs to be contained to the tile [or maybe a slight overrun cheat...], but I certainly don't want to see smoke hopping tiles)
Lifetime is just animation rate times framecount, it is virtually the same. I'd go with lifetime for backwards compatibility, It's not required for train smoke I think, but nice to have for factory smoke.

If spawning was not tied to time, but to the distance moved, you might run into the opposite problem of what we have now - a really slow locomotive might create smoke so rarely, one cloud would be gone before the next spawns. If you go by time, but use a higher spawning rate so the smoke looks good on faster locos, it might be too thick on slower locos, and not exactly performance friendly if it draws more than needed. Especially considering that the slower the trains, the more can fit the screen, the more smoke can be on screen.
Ideally, there would be both. I'd like to define the highest allowed distance travelled before a new smoke particle spawns (eg. half of a tile), but if that distance is not travelled within a certain amount of time, spawn a particle anyways (eg. every 500ms). If something like that is too complicated, I think the next best would be a timebased spawnrate defined by the train, so quicker trains can have a higher spawnrate for the same smoke object.

The fixed movement, you mean going up a few pixels? I think that does not need to be part of the smoke behaviour at all. It can be done within the graphics themselves. If there is just one graphic, like in p64 factory smoke, it could still be defined manually with an offset. So I would scrap that as a game behaviour and put it in the pak creators hands instead, since they already have the tools to recreate it and there are generally not many different smokes per pakset,so it's reasonable to adjust to.
Since we are at it, I'd like to define the offset radius of smoke. The original is good for p64, but barely noticable in p192c. I'd rather have either none or a bigger one.


Offline TurfIt

Re: Changes to the smoke-parameter for buildings (and ideas around that)
« Reply #22 on: February 26, 2017, 04:35:40 AM »
Lifetime is just animation rate times framecount, it is virtually the same. I'd go with lifetime for backwards compatibility, It's not required for train smoke I think, but nice to have for factory smoke.
Or animation rate is framecount divided by lifetime as it currently is!


Ideally, there would be both. I'd like to define the highest allowed distance travelled before a new smoke particle spawns (eg. half of a tile), but if that distance is not travelled within a certain amount of time, spawn a particle anyways (eg. every 500ms). If something like that is too complicated, I think the next best would be a timebased spawnrate defined by the train, so quicker trains can have a higher spawnrate for the same smoke object.
Adding a spawn time and max distance moved between spawns can be done. A fast moving vehicle with a low framerate would result in missed spawns - need to not set that max distance too low, or spawn too short. I'd rather stick with the mechanism where the spawn occurs at the vehicles current position at the end of a frame, than try to calculate the spawn positions more accurately on a strict time/distance basis.


The fixed movement, you mean going up a few pixels? I think that does not need to be part of the smoke behaviour at all. It can be done within the graphics themselves. If there is just one graphic, like in p64 factory smoke, it could still be defined manually with an offset. So I would scrap that as a game behaviour and put it in the pak creators hands instead, since they already have the tools to recreate it and there are generally not many different smokes per pakset,so it's reasonable to adjust to.
Yes, I meant the fixed upward motion rate. I presume you're meaning to have multiple animation frames with different offsets? I think keeping graphics fixed, and moving in the code makes more sense. Isn't that the current proposal for the animated pedestrians?


Since we are at it, I'd like to define the offset radius of smoke. The original is good for p64, but barely noticable in p192c. I'd rather have either none or a bigger one.
Can you expand on what you mean here? Currently factory smoke has tile and pixel offsets, vehicle smoke is fixed position.

Offline Leartin

Re: Changes to the smoke-parameter for buildings (and ideas around that)
« Reply #23 on: February 26, 2017, 08:34:44 AM »
Or animation rate is framecount divided by lifetime as it currently is!
Lifetime divided by framecount, but I agree - Which is why I said I would go with lifetime

Adding a spawn time and max distance moved between spawns can be done. A fast moving vehicle with a low framerate would result in missed spawns - need to not set that max distance too low, or spawn too short. I'd rather stick with the mechanism where the spawn occurs at the vehicles current position at the end of a frame, than try to calculate the spawn positions more accurately on a strict time/distance basis.
Sorry, I don't think I understand that. You mean if the spawn happens based on travelled distance, the train may skip that exact position and no smoke would spawn? If so, tht could be a problem. Would it be any better if smoke does spawn on time, but the time shrinks shorter depending on vehicle speed? Something like up to 70km/h, it's 500ms, from 70 to 110 it's 350ms, from 110 upward it's 200ms. It could not drop any spawns if it's timebased, right?


Yes, I meant the fixed upward motion rate. I presume you're meaning to have multiple animation frames with different offsets? I think keeping graphics fixed, and moving in the code makes more sense. Isn't that the current proposal for the animated pedestrians?
Pedestrians are moving entities. There is one animation loop, which is repeated while they walk around via code.
Smoke is not a moving entity, it stays in place. The upward motion is a relic from earlier time, when neither animation nor offset were available, and it worked to animate even one-frame-smoke a tiny bit. Just take a look here:

This is the smoke I use for common buildings in winter. It's just a 3-frame repeated pattern in the frontimage of the building. Smoke in a style similar to this could be used for factories as well. except it would automatically move upward 10 pixels, so I would need to create 30 frames and change the graphic every 10 frames, and increase the offset every 3 frames as a countermeasure.
On the other hand, if those ten pixels were abandoned, the one-frame-smoke of pak64 would change it's definition from
Code: [Select]
Image[0]=ls-smoke.1.0to
Code: [Select]
Image[0-9]=ls-smoke.1.0,<$0>,0and be exactly the same as it was before. That's why the movement needs not be in the code: If you want it, it's super easy to do manually, but if you don't want it it's harder to work around it.

Can you expand on what you mean here? Currently factory smoke has tile and pixel offsets, vehicle smoke is fixed position.
Smoke spawns at slightly random positions. Very slightly, you can count the pixels with your fingers - best seen in p64 with factory smoke. I created a sheepfarm a while ago, with the word "BAA!" randomly popping up now and then. Except it's not random, it's a 30-second animation loop with 3/4 empty frames. If I could set the random offset of the smoke, I would instead use a "BAA!"-smoke at a really low spawning rate with high potential offset. Or the other way around, if I created an animation loop, like the building smoke, I might not want any offset to occur, since it breaks the animation.

Remember, "smoke" is the name of the object, not a restriction on what is allowed to do with it. The less limitations, the more possibilities. :)