News:

Simutrans.com Portal
Our Simutrans site. You can find everything about Simutrans from here.

Changes to the smoke-parameter for buildings (and ideas around that)

Started by Leartin, January 23, 2017, 02:51:16 PM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

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 ;)

Ters

Quote from: Leartin on January 23, 2017, 02:51:16 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.

Leartin

Quote from: Ters on January 23, 2017, 04:22:11 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.

An_dz

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.

Ters

Quote from: An_dz 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.

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.

prissi

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 ...

Leartin

Quote from: An_dz 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.

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.

Quote from: prissi on January 24, 2017, 12:29:47 AM
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.

prissi

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.

Leartin

Quote from: prissi 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.

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.

prissi

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 ...

Leartin

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?

Dwachs

To fix the dirty pixel bug: Can you upload a vehicle and smoke object, where this can be tested?
Parsley, sage, rosemary, and maggikraut.

Leartin

Sure:
http://dl.dropbox.com/s/utn5ize8zk02moh/newsmoke.png <-- Graphic
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.

TurfIt

Quote from: Leartin on February 22, 2017, 09:03:05 AM
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.

Leartin

Quote from: TurfIt on February 22, 2017, 11:22:59 PM
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.

Dwachs

Quote from: TurfIt on February 22, 2017, 11:22:59 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.

Dwachs

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.

jamespetts

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.

An_dz

I highly believe it's CC-BY-SA 3.0, but it's better to wait for a confirmation from Leartin.

Leartin

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.

TurfIt

Quote from: Leartin on February 23, 2017, 08:47:13 AM
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)

Leartin

Quote from: TurfIt on February 25, 2017, 07:44:16 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.


TurfIt

Quote from: Leartin on February 25, 2017, 11:12:25 PM
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!


Quote from: Leartin on February 25, 2017, 11:12:25 PM
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.


Quote from: Leartin on February 25, 2017, 11:12:25 PM
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?


Quote from: Leartin on February 25, 2017, 11:12:25 PM
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.

Leartin

Quote from: TurfIt on February 26, 2017, 04:35:40 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

Quote from: TurfIt on February 26, 2017, 04:35:40 AMAdding 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?


Quote from: TurfIt on February 26, 2017, 04:35:40 AM
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
Image[0]=ls-smoke.1.0
to
Image[0-9]=ls-smoke.1.0,<$0>,0
and 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.

Quote from: TurfIt on February 26, 2017, 04:35:40 AM
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. :)

Vladki

Hello all,

I'm reviving this topic about smokes. As industry smokes were added to pak128.britain-ex, I found out that it is impossible to properly position the smokes. It seems that the code was made when there were no animations and no rotations. So If you positioned the smoke for one rotation, it will be way off in all others. The problem is in the offset being only 2D, which cannot be properly rotated. It has to be 3D to work well. I have looked at the code, it seems to be the same in standard and extended (maybe just some formatting changes). I have made a patch for extended, which you can see here: https://github.com/jamespetts/simutrans-extended/pull/81/files

The changes are these:
- removed option: smokespeed - it was not used anywhere in the code.
- smokeoffset is now the offset of chimney _base_. (0,0) is the center of the tile, (32,0) is the right corner, (0,16) is the bottom corner.
- new option: smokeheight is the height of chimney in pixels for pak64.  For pak128 it has to be divided by 2, etc.. Just like the smokeoffset. Default value is 8, which was formerly hardcoded in the code (wolke.cc).
- factory smoke is not randomised any more. It was just weird to see smoke appear sideways from chimney.
- also vehicle smokes benefit from this change. If a vehicle was climbing a slope and the map was rotated (and paused) smoke was displayed wrong, now fixed.
- smokeheight for vehicles is hardcoded to 8 (just as before, but in vehicle/simvehicle.cc).

I plan to further improve the smokes by reintroducing smoke speed and smoke randomness. At the moment they are implemented as constants in wolke.cc, but I'd like to make them into dat file options for the smoke itself. With smokespeed=0 the animation (and any movement of smoke) would be fully made in graphics. Randomness allows the smoke to wiggle a little bit in x axis. It works, but just sometimes looks weird. I'm not sure it it is really worth including. However I have no idea how to implement new options for smokes. They seem to be so simple objects that their reader/writer seems to be just some default (inherited from some simple generic object).

So please have a look, try it if you can, and tell me what you think about it.

Leartin

Awesome!

But I'm a bit concerned about the 3D coordinate, since that only works if the rotations are actually exact rotations of the same 3D building. In Pixel-Art, the easiest way to get a "rotation" is to mirror the base image and change the shading, a mirror image is not the same as an actual rotation, so the chimney would not be in the same spot.
Wouldn't it be smarter to do something like "smoke[x ]=", where x is the rotation? Hence you would be able to set individual smokes for each rotation. This would be especially useful since getting rid of randomness and (I assume) automatic rise would unlock the use of smoke in animation in general, eg. items on conveyer belts, people walking around corners, etc - all those kinds of animations that should not be visible at all when no production occurs, since seeing any frame without-motion would not make much sense. And unlike smoke, those could vary greatly between rotations.

jamespetts

I suspect that it would be better ideally to have both alternatives, since simply using a 3d co-ordinate would be much more efficient for paksets that are rendered rather than hand-drawn, although one then has to consider the amount of work necessary to create and maintain two different systems.
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.

Vladki

I must say that I have not coded in C++ for almost 15 years, so I was aiming for the simplest possible fix that will at least make the current stuff working properly.
I have not tested what it does if the industry has only 1 or 2 rotations (mirrored).

Leartin

Quote from: jamespetts on October 15, 2017, 01:15:57 PM
I suspect that it would be better ideally to have both alternatives, since simply using a 3d co-ordinate would be much more efficient for paksets that are rendered rather than hand-drawn, although one then has to consider the amount of work necessary to create and maintain two different systems.
How efficient is it, though? Even if you get the 3D coordinate directly from blender (and you should - extrapolating it from 2D renders later would be a pain) you'd still need to break down the x and y data into tiles and and position on that tile, in a coordinate system thats 45° turned (assuming you use axis parallel to tile borders in the 3D program) While that process could be automated with some tool/plugin, it would be just as easy to get the 2D coordinates for 4 rotations as getting a simutrans-3D-coordinate...

Vladki

First I must say that these are not 3D coordinates in isometric sense. The smokeoffset is in screen x,y pixels, with 0,0 being the middle of tile (for pak64 it is pixel 32,48; for pak128 = 64,96), and it is scaled by paksize/64, so the corners of tile are (32,0), (0, 16), (-32,0), (0, -16). Then the height of chimney, again in pixels divided by paksize/64. In any case it is easier to count them from the final render. However it is far from perfect. I have tested the code on rendered oil-well for pak128.britain-ex, and the base of the tower is jumping +/- 1 pixel in different rotations. Given the fact that the offset is multiplied by 2 (128/64), and during the rotation again multiplied and divided by 2, this gives us 4 pixel precision. So this low precision, gives much better chance for pixel art to end up more precise if you manage to put the chimney in the right place on all rotations. Now I also understand why adjusting the smoke on car factory was such a pain - it is not rotated but mirorred.

So, the real solution would really be either to have a separate offset for each rotation, or to get rid of smoke completely, and just make the factory animation dependent on production.

Leartin

Quote from: Vladki on October 15, 2017, 06:40:06 PM
In any case it is easier to count them from the final render.
If the base is visible. If it isn't visible, you are out of luck for an easy solution.
Quote from: Vladki on October 15, 2017, 06:40:06 PMSo, the real solution would really be either to have a separate offset for each rotation, or to get rid of smoke completely, and just make the factory animation dependent on production.
Actually, factory animation is only played during production for a while now. This works fine for something like an oil pump or a windmill that just stops in it's motion, but it's really strange to have a static smoke over a factory while it isn't producing. That's also why I'm interested in using smoke for other animations that would look strange when just stopped in motion, eg. flames, people, open octopus eyes over closed eyes when nothing happens...

Larger scale project: What if you could reference a smoke-object with the same syntax you use for images, since it is nothing but a collection of images? This would also allow for multiple smokes in one building (one per tile), different smokes depending on season, and you could play different smokes one after the other by using the animation index. While it's a bad idea to overuse that (for performance reasons) it would probably give the most options on how to use it.

Vladki

does the animation of factory just freeze, or is it reset to 1st frame? If the latter, then jsut make the 1st frame of smoke clear.

Leartin

It just freezes, and it starts out at a random frame to begin with.

Ters

Quote from: Vladki on October 15, 2017, 06:40:06 PM
So, the real solution would really be either to have a separate offset for each rotation

I think that would give artists the most amount of flexibility.

Vladki

Hello, I'm reviving this topic - I want to get the smokes right. And found some weird things about OBJECT_OFFSET_STEPS constant...

This constant is defined to be 16 at the end of simconst.h, with a comment that lots of other code would have to be changed if OBJECT_OFFSET_STEPS is changed.
In several places I found a code where something is multiplied by OBJECT_OFFSET_STEPS and immediately divided by 16. Why is that? I have a bad feeling that in some places I would need to do that (to cover the unlikely case when OBJECT_OFFSET_STEPS would not be 16, but I don't know how to find those... Either is this redundant, or would have to be added to other places, like when dealing with roadsigns and offset for left hand driving.
Can anyone shed more light on this?

simfab.cc, line 1548:

const sint8 offsetx =  ((rada->get_xy_off(rot).x+sim_async_rand(7)-3)*OBJECT_OFFSET_STEPS)/16;
const sint8 offsety =  ((rada->get_xy_off(rot).y+sim_async_rand(7)-3)*OBJECT_OFFSET_STEPS)/16;


simobj.cc, line 185

sint8 byte = (sint8)(((sint16)16*(sint16)xoff)/OBJECT_OFFSET_STEPS);
file->rdwr_byte(byte);
xoff = (sint8)(((sint16)byte*OBJECT_OFFSET_STEPS)/16);
byte = (sint8)(((sint16)16*(sint16)yoff)/OBJECT_OFFSET_STEPS);
file->rdwr_byte(byte);
yoff = (sint8)(((sint16)byte*OBJECT_OFFSET_STEPS)/16);


simroadtraffic.cc, line 180. There is a code that for versions 99.5 - 99.17 does not do this conversion.

if(file->is_version_less(99, 5)  ||  file->is_version_atleast(99, 17)) {
sint16 dummy16 = ((16*(sint16)hoff)/OBJECT_OFFSET_STEPS);
file->rdwr_short(dummy16);
hoff = (sint8)((OBJECT_OFFSET_STEPS*(sint16)dummy16)/16);
}
else {
file->rdwr_byte(hoff);
}


Then two less obvious places, where it is not divided by 16  but 4096 (>> 12) or 256 (>>8)

./obj/wolke.cc line 108, and 132
const sint8 new_yoff = base_y_off - ((insta_zeit * OBJECT_OFFSET_STEPS) >> 12);
set_yoff( base_y_off - ((insta_zeit*OBJECT_OFFSET_STEPS) >> 12) );

simvehicle.cc line 1236
wolke_t* const abgas =  new wolke_t( get_pos(), get_xoff() + ((dx * (sint16)((uint16)steps * OBJECT_OFFSET_STEPS)) >> 8), get_yoff() + ((dy * (sint16)((uint16)steps * OBJECT_OFFSET_STEPS)) >> 8) + get_hoff(), desc->get_smoke() );