IRC logs for #openttd on OFTC at 2026-08-04
⏴ go to previous day
01:02:32 *** MinchinWeb[m] has quit IRC (Ping timeout: 480 seconds)
01:02:41 *** MinchinWeb[m] has joined #openttd
01:21:18 *** MinchinWeb[m] has quit IRC (Read error: Connection reset by peer)
01:21:34 *** MinchinWeb[m] has joined #openttd
01:46:34 *** Wormnest has quit IRC (Quit: Leaving)
03:21:06 *** Philemon has joined #openttd
03:24:31 *** Phileman has quit IRC (Ping timeout: 480 seconds)
05:18:45 *** andythenorth_ has joined #openttd
07:03:04 <_zephyris> What's your jitter strategy?
07:07:31 <peter1138> Tile-coordinate based offset.
07:10:05 <peter1138> But basically in a late game there are so many trees that staggered refreshes just end up causing everything to be redrawn.
07:15:55 <_zephyris> So mostly the rather than tile updates?
07:16:22 <_zephyris> Quite dependent on the NewGRF/animation specification then
07:20:38 <peter1138> I didn't bother to do conditional updates based on NewGRF needs, because implementing that is a lot of work if it's just going to be too slow anyway.
07:21:17 <peter1138> Vague assumption that if NewGRFs can have a refresh authors will want to use it everywhere :)
07:22:38 <peter1138> It's shame that there isn't really a way to discover if a refresh is actually needed -- you'd have to run a load of resolves before and after and that would be very slow to.
07:23:24 <peter1138> If we had a modern rendering engine you'd just be refresh the entire screen every frame and not care.
08:04:36 <peter1138> "Static analysis" of varaction changes to work out which variables are used and which values cause a visual change...
08:05:17 <_zephyris> For trees, or in general?
08:20:50 <_zephyris> Back of the envelope calculation suggests the issue is the "does this need updating" rather than draw time.
08:23:32 <peter1138> Drawing is expensive becuase every tile you draw you need to draw all the tiles behind it up to the vertical refresh -- even if the tile itself isn't that tall.
08:24:06 <peter1138> (If the tile itself "knew" how tall it was, separately from drawing, then you could mark of the viewport as dirty)
08:26:10 <_zephyris> I'm trying to calc how often trees grow and spread, that already causes a bunch of redraws
08:30:44 <peter1138> MarkTileDirtyByTile always uses MAX_TILE_EXTENT_TOP, which is massive.
08:30:59 <_zephyris> A tile with 4 trees on it, each animating twice per year (leaves<>bare), is at most 8 redraws needed per year. That's somewhere around 1/12 tile loops
08:31:09 <_zephyris> Yeah, was just looking at the dirty boxes.
08:32:04 <peter1138> Yes, With the monthly variable it will refresh 12 times a year just for graphical changes, and if the sub-tree months have jitter, then multiply that by up to 4.
08:32:12 <peter1138> It doesn't sound a lot.
08:32:27 <peter1138> But treeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeees.
08:33:20 <_zephyris> I think we're thinking about jitter in different ways(?)
08:33:40 <_zephyris> I was thinking 'only check this tile for tree animation updates every nth tile loop'
08:33:52 <_zephyris> Seems like you're jittering per tree?
08:34:46 <_zephyris> So, instead, divide by 4 for the actual number of checks.
08:39:39 <peter1138> It is every nth tile loop, but I added a tile-index offset so that it's a little bit more pseudo random. Otherwise everything gets the same delay.
08:40:05 <peter1138> And then I experimented with per-subtree jitter, to see how it looks :-)
08:42:32 <peter1138> Part of the problem is I'm fast-forwarding on empty maps so the jitter is invisible anyway :D
08:45:44 <peter1138> Also wondering about a bitset of which month transitions should trigger a refresh, but that's not very NewGRFy.
08:46:01 <peter1138> (Static analysis could figure that out)
08:50:38 <_zephyris> It'd be nice to have a newgrfy varact2, but if performance says no...
08:51:50 <_zephyris> I'm still trying to work out how often trees get redrawn from normal growth, is that often enough?
09:13:14 <peter1138> Probably, it's not the end of the world if a month is skipped.
09:17:39 <peter1138> And yes, the spreading rules probably need work...
09:18:27 <peter1138> Also, cost factor and town rating factor probably need to be thought about too.
09:18:44 <peter1138> "Oh no you cut down beautiful trees"... "wait it was brambles, never mind"
09:19:08 <_zephyris> Gameplay features? Gosh
09:20:16 <_zephyris> Flakey prelim graphics aside, looks kinda cool
09:20:32 <peter1138> I've settled on just doing it on the regular growth cycle.
09:20:52 <peter1138> No per-subtree jitter.
09:21:17 <peter1138> Tile is only marked dirty once in case of multiple changes.
09:21:26 <peter1138> (Ground, tree growth, month)
09:22:18 <peter1138> Could also have a TreeFlag for "has monthly variations" to avoid more updates.
09:22:45 <peter1138> Snowline changes will already dirty it so no issue there.
09:30:40 <_zephyris> Flag seems sensible
09:50:21 <reldred> peter1138[d]: i love this and i will pay whatever it costs
09:51:26 <andythenorth_> free to those who can afford it, very expensive to those who can't
10:01:07 <peter1138> Need to think about placement callbacks.
10:01:38 <peter1138> Do we want callbacks...
10:02:42 <peter1138> Callbacks would be at the per tree, but presumably we'd only run once for the primary tree, not for all possible layout combinations.
10:03:31 <peter1138> And that would mean sub-trees might appear where they shouldn't
10:04:18 <andythenorth_> 'reforestation programme'
10:04:38 <andythenorth_> 'sapling depletion by oversized deer population'
10:04:42 <andythenorth_> 'excess of giraffes'
10:08:05 <peter1138> Also, classes are not yet implemented nicely.
10:08:10 <peter1138> It's just a manual bitset right now.
10:12:09 <_zephyris> Does it handle snowy trees nicely?
10:13:27 <_zephyris> And, yeah, placement callbacks would be nice... Might get (computationally) expensive if it applies to tree growth through
10:15:13 <peter1138> Yeah, not sure how to handle this at the moment.
10:15:25 <peter1138> With the first tile-based approach it was much more obvious ;-)
10:16:49 <peter1138> Default snowy trees are handled automatically.
10:18:04 <peter1138> NewGRFs will need to switch based on a snowy variable.
10:18:33 <peter1138> But could potentially have partially snowy trees.
10:19:58 <_zephyris> Partially snowy would be nice. NewGRF switch is reasonable IMO
10:20:41 <_zephyris> FWIW, placement callbacks applying to tree spawning and to player placement, but not to growth, would be OK
10:21:00 <_zephyris> Trees are trees, they tend to spread
10:21:40 <_zephyris> But that conflicts with ground type (desert, rainforest) which are hard rules
10:22:12 <peter1138> Yes, just initial spawning/creation is all I was thinking.
10:22:40 <peter1138> Potentially you could look up with pseudo-random layout is going to be used.
10:22:53 <peter1138> And then test each tree in that layout.
10:23:25 <peter1138> But then you might end up with a layout that has conflicting requirements and never gets used.
10:23:57 <peter1138> (Conversely, if you only check the primary tree, you might end up with a layout that has conflicting requirements and gets placed anyway leading to weirdness?)
10:23:57 <_zephyris> Set designers can/should pick sensible class combos
10:25:30 <_zephyris> I'm not so worried. Don't want cactuses in the rainforest? Then don't put it as a tile layout class on your rainforest tree.
10:25:52 <peter1138> In TileLoop_Trees, there's a rnadom probability for dying, adding or spreading.
10:26:23 <peter1138> It might be feasible to allow NewGRF to tweak those rules.
10:26:32 <peter1138> (With a static property, not a callback)
10:28:55 <peter1138> GB(Random(), 0, 3) has 8 values, there's 3 actions, so there's a 3/8 chance of something happening.
10:29:33 <peter1138> You can slow down growth (and death) by tweaking that.
10:38:36 <_zephyris> I'm trying to remember, does growth/death depend on neighbours?
10:39:02 <_zephyris> I've said it a bit tongue in cheek before, but I really think cellular automita are the way to go for more controlled trees
10:39:11 <_zephyris> Though I think kuhnovic has other ideas 😉
10:40:30 <_zephyris> Exposing the current growth properties kinda restricts efforts to change them
10:40:44 <_zephyris> And late game trees are kinda problematic
10:40:56 <_zephyris> OTOH, NewGRF setting game behaviour is sort of a policy
10:41:15 <peter1138> Doesn't look like it depends on neighbours, there's a check stop Cactus dying off though.
10:43:02 <peter1138> Climate-specific tree behaviour is mostly just about doing the right thing for different ground types.
10:43:09 <peter1138> (Snow, desert, tropic, etc)
10:43:31 <peter1138> Rainforest tree sounds too.
10:43:50 <peter1138> And arctic snowy sounds.
10:43:55 <reldred> or the different ground types that don't have a different ground sprite
10:43:59 <reldred> oh rainforest my beloved
10:44:23 <peter1138> Mangrove trees, on water?
10:44:57 <peter1138> Not touching that :-)
10:54:14 <_zephyris> Seems odd to have an extra cacti don't die, why don't they have p=0 for dying?
10:54:21 <_zephyris> Hmm, I should look at the code again
10:54:30 <_zephyris> Had a poke a while ago, thinking about game of life
10:55:43 <peter1138> Hmm, I seem to have tanked performance on Wentbourne. 0.10x.
10:56:17 <peter1138> Possibly it's my debug per-tile-type performance accumulator killing it.
10:56:29 <peter1138> When measuring performance kills performance.
10:58:43 <reldred> measure nothing, yolo everything
10:59:55 <peter1138> I wanted to know if I was killing tree performance :)
11:06:46 <_zephyris> Hmm killing tree performance vs. tree killing performance
11:07:02 <_zephyris> performance tree killing sounds like a modern performance art piece
11:07:05 <_zephyris> I should do some work
11:08:51 <reldred> I mean chainsaw cutting competitions are a thing
11:08:58 <reldred> but usually they're just cutting rounds
11:11:42 <will_marshall_> Look up Timbersports it's a whole thing.
11:23:55 <peter1138> TreeClass Translation Table?
11:47:12 <kuhnovic> _zephyris: As long as it gets better and the map doesn't end up completely overgrown with trees then I'm all for it!
11:51:52 <_zephyris> Maybe NewGRF-set growth/spread/death is worth trying.
12:12:56 <peter1138> Hmm, currently the tree blobs that are created during world gen just pick any and every tree.
12:15:03 *** kuayueren has joined #openttd
12:23:28 <peter1138> Possible tree-options: build blobs from compatible classes instead of any tree? blob size?
12:50:14 <_zephyris> Seems like a non-NewGRF problem... But, might be nice to enhance.
13:18:16 <peter1138> Moss "trees", but only on north-facing slopes...
13:19:24 <_zephyris> Sounds like a new TileType feature to me 😉
13:19:41 <_zephyris> But accessing tile slope for a varact2 for trees would be fun
13:24:36 <peter1138[d]> Probably ought to put some rails/roads down.
13:25:57 *** Wormnest has joined #openttd
13:32:47 <andythenorth_> swamp sensitive trees
13:34:03 <_zephyris> For varact2 tree calbacks, water nearby would be great. But, expensive, IIRC the standard tool is the tile class at x/y offset for x/y -8 to 8.
13:34:33 <_zephyris> I wondered if a spiral search for distance to nearest tile matching a class would be useful in general for NewGRF callbacks
13:34:51 *** metabolist has joined #openttd
13:34:51 <metabolist> What's going on with trees these days?
13:34:58 *** kuayueren has quit IRC (Quit: left the IRC channel)
13:40:09 <peter1138> Some idiot is playing.
13:52:04 <metabolist> Trees on shaded slopes are also shaded so that you can still see the topography?
13:52:57 <_zephyris> This is peter playing with newgrf trees, and me having opinions
13:55:52 <metabolist> Maybe I'll go back to bed for another 3 years and check then!
13:57:11 <peter1138> The slopes are only 8 pixels high, the trees are much larger so will still be in sunlight :-)
14:01:26 <metabolist> Well you need to burn a lot of CPU time to calculate the average slope over a big radius then
14:18:28 <_zephyris> The "update animation state when something else changes" should be good (based on my rough count of when tree growth/death changes)
14:33:59 <metabolist> Do trees care about where they are or what trees they are with?
14:36:41 <peter1138> "Sort of" and "sort of"
14:37:16 <peter1138> _zephyris, I've just done it on the 16-cycle loop.
14:39:25 <peter1138> In that loop, there is one common path where nothing might happen 5/8 times.
14:39:51 <peter1138> So we check the animation state even in that case.
14:40:33 <peter1138> And "check the animation state" means checking if the month has changed since last time, and if it has, update the value and refresh.
14:41:06 <peter1138> So now it's simple, and probably only needs the conditional "don't do it if the NewGRF hasn't requested it" bit.
14:41:46 <metabolist> Well I should reinstall just to try some backwards trains if nothing else
14:46:18 <rito12_13> backwards trains are awesome
14:51:48 <_zephyris> NewGRF tree sounds?
14:57:27 <_zephyris> The once every 16 tree check is run from the tile loop, right?
14:58:40 <_zephyris> So that's ~100s between tree updates. 2 month dither, at vanilla game speed.
14:59:05 <_zephyris> Should visually work really well on paper
15:00:50 <peter1138> Yeah, it's perhaps just slightly too long as it could miss a month.
15:05:39 <_zephyris> Could change the loop to every 8 and halve the probabilities, but meh
16:01:51 <_zephyris> Really could do with some NewGRF feature which has the 19(?) tile slopes as a standard spriteset.
16:55:39 *** Flygon has quit IRC (Read error: Connection reset by peer)
17:00:46 <_zephyris> Lower performance impact, easier coding. But yeah.
17:03:54 <peter1138> That's not my answer of course :)
17:14:50 <_zephyris> I never came up with a good answer for tile to tile blends
17:16:33 <_zephyris> Best was dithered overlays for the edges and corners when not fully surrounded by tiles of the same type - a bit river bank-like, a bit field fence-like.
17:17:22 <_zephyris> No way to draw masked sprites, presumably. Could do it by defining a standard base game ground tile blend sprite mask, and only drawing the pixels in that mask.
17:26:12 <_zephyris> Hmm, I suspect that's how RCT2 works.
17:27:58 <rito12_13> Does `debug_level desync=3` forces more frequent desync checks?
17:48:09 <peter1138> I guess we could have tiles that limit the number of trees.
18:05:18 <peter1138> Hmm, I guess different probabilities for different climates can be handled by act7/9
18:05:35 <peter1138> Or, indeed, callbacks.
18:08:38 <_zephyris> Seems sensible to have settings for snow, desert and rainforest. Avoids really dumb behaviours a bit.
18:11:18 <rito12_13> I fail to build master now 🙁
18:18:33 <_zephyris> peter1138[d]: Was running around a park with a frisbee. In more detail, by having clear settings (eg. tree properties bitmask) for the fundamental vanilla OpenTTD behaviours it's an easy solution and soft encouragement to make tree sets work with the base climates. Let people break it via varaction2, but that's for advanced dev.
18:24:54 <LordAro> does github have a concept of merge trains yet?
18:25:07 <andythenorth_> "priority merge trains"
18:25:15 <andythenorth_> did github implement block signals?
18:25:32 <andythenorth_> it's rich vein, given green light deploys
18:25:53 <andythenorth_> if 3 out of 4 tests go green, it's "probably fine?"
18:26:07 <andythenorth_> we should implement statistical signals in OpenTTD
19:13:37 *** LordArtoo has joined #openttd
19:13:37 *** LordAro has quit IRC (Read error: Connection reset by peer)
20:21:40 *** Wolf01 is now known as Guest15036
20:27:45 *** Guest15036 has quit IRC (Ping timeout: 480 seconds)
20:34:41 <peter1138> I suppose in theory you can block access to some variables in certain places, but...
20:39:10 *** Smedles has joined #openttd
20:43:34 <_glx_> like extra safety checks for action 7/9 ?
20:44:43 <peter1138> Eh, that patch died.
20:45:03 <peter1138> Too strict or something. :)
20:48:16 <_glx_> usually the issue is when newgrf have different behaviour depending on game state when they are loaded
20:49:28 <_glx_> but even outside action 7/9 they can store things via action D
20:50:29 <peter1138> Specifically talking about 15940, which is setting speed based on cargo load, so not act 7/9 stuff.
20:50:30 <_glx_> and also patch other actions via action 6
20:51:04 <_glx_> in theory cargo load should be the same on all running clients
20:51:27 <peter1138> True. I wonder where this one is going wrong.
21:03:22 <peter1138> Hmm, ah, I guess we are preventing it from updating when it should be fine.
21:07:27 <peter1138> Dunno, only length and capacity are called out.
21:08:09 <peter1138> We do determine max_speed before CargoChanged() is called.
21:09:45 <peter1138> Any minute now, someone will open a PR to fix an obvious bug ;)
21:11:16 <Rubidium> Do we determine max_speed before CargoChanged() is called at all? Well, in the Vehicle::MarkDirty cases
21:12:43 <Rubidium> in train's ConsistChanged case max_speed is updated before CargoChanged(), but that's not called from (un)loading
21:22:28 <Rubidium> it smells like quite a big performance penalty to have to re-evaluate the consist every time something gets (un)loaded for every vehicle
21:24:27 <Rubidium> although it's already done for ships it seems
21:25:53 <peter1138> CargoChanged() doesn't touch anything seemingly relevant anyway.
21:35:21 <peter1138> Are we missing a call to ConsistChanged() when finished at a station?
21:38:44 <peter1138> Auto-refit at a station will trigger one.
21:42:28 *** Wolf01 has quit IRC (Quit: Once again the world is quick to bury me.)
22:37:57 <rito12_13> It works with any station refit
22:47:57 <peter1138> Oh was I overly specific? Station refit is not something I ever use, so I wasn't specifically differentiating between auto-refit and non-auto-refit, just refit and not refit.
continue to next day ⏵
