IRC logs for #openttd on OFTC at 2025-10-22
⏴ go to previous day
00:53:58 *** Wormnest_ has quit IRC (Quit: Leaving)
01:51:09 *** tokai|noir has quit IRC (Ping timeout: 480 seconds)
01:57:56 *** ChanServ sets mode: +v tokai
02:03:26 *** herms2 has quit IRC (Quit: bye)
02:11:32 *** gnu_jj_ has joined #openttd
02:15:09 *** gnu_jj has quit IRC (Ping timeout: 480 seconds)
03:59:52 *** Zathras has joined #openttd
04:03:21 *** Zathras_11 has quit IRC (Ping timeout: 480 seconds)
05:25:32 *** Flygon has quit IRC (Read error: Connection reset by peer)
06:10:33 <pickpacket> What's the difference between "total waiting cargo" and "available waiting cargo"?
06:10:47 *** Rikests has joined #openttd
07:03:27 *** jinks_ is now known as jinks
07:58:21 <ahyangyi> _jgr_: Ah, bad news but better than what I assumed (undefined behavior)
08:41:07 <xarick> dang it, place sign used to be 1 click, now it's 2
09:19:49 <xarick> there is an innefficiency I'd like to tackle
09:20:21 <xarick> GetTileMaxZ on a TileArea
09:22:03 <xarick> I wanna make an efficient GetTileAreaMaxZ
09:22:36 <xarick> one that does not repeat TileHeight on the same tiles
09:32:47 <peter1138> Is it done often enough to warrant it?
09:33:31 <LordAro> change units as you see fit
09:35:53 <peter1138> Maybe you can consider the existing tile height test to be checking a 1x1 tile area.
09:56:53 <xarick> where do i find that test
09:57:36 <peter1138> The one you are looking at replacing...
10:15:37 <xarick> `TileArea tile_area2 = TileArea(tile, 1, 1).Expand(16);` fixes it
10:23:07 <xarick> FindSpring 3.4s to 2.7s
10:24:08 <xarick> let me try this approach for the other check above this one
10:25:18 <peter1138> For tile height you need to have 1 extra tile, so start with TileArea(tile, 2, 2), right?
10:30:49 <xarick> but then that would also add an extra to the NE and NW which I don't need 🙁
10:35:37 <peter1138> That's uh, definitely obscure coding :)
10:37:01 <peter1138> ? and ! are indirection operators, being used to write to video memory.
10:40:09 <andythenorth> kids of today eh
10:41:17 <xarick> nice, peter's method is even cleaner
10:42:25 <xarick> no need to increase w or h or clamptomap
10:46:43 <xarick> 2.779 s to 2.700 s, nice!
10:51:17 <peter1138> You should not exclude MP_VOID tiles.
10:51:38 <peter1138> At least not on the south and east sides.
10:52:08 <peter1138> One of the reasons MP_VOID tiles exist there is for the purpose of providing tile height :)
10:57:47 <xarick> using yapf as a pseudo bfs isn't all too fast 🙁
11:01:03 <xarick> findpath takes 10.416 s
11:01:46 <xarick> PfFollow node is the "bfs" part
11:03:21 <xarick> GetTileSlopeZ is called there incessantly
11:06:42 *** nebulabc has quit IRC (Remote host closed the connection)
11:06:42 *** asymptotically2 has quit IRC (Remote host closed the connection)
11:07:43 <kuhnovic> Yapf is an A* / Dijkstra pathfinder. That means you have overhead in calculating costs and keeping a binary heap so you can always get the node with the lowest cost. You don't have this overhead with a BFS, but you don't have the ability to say "this node is better than the other". You just add nodes in the right order and that's how they get processed.
11:11:07 <xarick> I mean, it's still faster than FlatSet
11:17:30 <xarick> it's a link to this image
11:18:01 <xarick> Alpinist is a problem for yapf
11:18:18 <xarick> very flat 1% sea is a problem for flatset
11:23:02 <peter1138> I'm not against replacing FlatSet there. It wasn't done as a performance optimisation, and I probably completely neglected to test that aspect.
11:24:07 <xarick> yapf uses its own Hashtable Open/Close stuff...
11:25:43 <xarick> it seems to me there's a overhead issue in initializing tons of pathfinder instances? I'm not sure
11:27:42 <xarick> this river at this height, must have initialized yapf x height times only to find a path in the next node, as it flows down the hill
11:29:02 <xarick> hmm nah... this would also occur on the master
11:29:15 <peter1138> Dear Outlook, please stop capitalising the h in https:// ...
11:34:23 <kuhnovic> A lot of yapf stuff is stored on the stack. This makes initialization pretty quick. Visual studio does show a warning about large stack usage though.
11:43:40 <andythenorth> fireside chat time
11:44:00 <andythenorth> it's possible to make a web app go faster by adding ram caches
11:44:27 <andythenorth> and it's possible to make a web app perform better under sustained heavy load by adding CPU and multiple threads or processes
11:45:13 <andythenorth> but for the actual real structure (including memory safety and security), it's plausible that more processes will cause more cache misses
11:45:21 <andythenorth> or latency picking up workload due to cold cache
11:45:48 <andythenorth> overly optimising for one dimension is highly appealing to tidy minds
11:47:31 <andythenorth> even watching it in production, and then optimising, is prone to optimising the most common case, that has pathogical performance in other reasonably common cases
11:47:37 <andythenorth> due to tradeoffs
11:47:48 <andythenorth> the moral here: how fast do rivers need to generate?
11:48:49 <peter1138> IMHO in Xarick's testing, cases 2 is not worth caring about.
11:49:32 <peter1138> But case 3 between master and #13264 is quite compelling. IIRC that's the one that "only" changes the data structure instead of algorithm.
11:50:00 <peter1138> Case 1 is mostly ignorable except for sub-tropic.
11:51:35 <peter1138> Equally, if the tile height-tile area change is dropping from 3.4s to 2.7s over the whole generation, then it's not worth it.
12:23:21 <kuhnovic> Should we add <unordered_set> to stdafx?
12:26:25 <peter1138> I would suggest unordered_map is more of a candidate.
12:27:42 <kuhnovic> Both <set> and <map> are in, it would make sense to add their unordered counterparts
12:28:30 <kuhnovic> Do you want to merge Xarick's PR or do you want to wait for more test results?
12:28:50 <xarick> hmm... is the 100% yapf toast?
12:29:25 <kuhnovic> Not if you can make it quicker 😛
12:31:00 *** nebulabc has joined #openttd
12:31:37 <xarick> it doesn't make use of std::unordered_set
12:31:47 <xarick> if that's something to worry
12:32:53 <kuhnovic> std::unordered_set is not a silver bullet. The hashmap used by yapf is surprisingly fast.
12:34:05 *** asymptotically2 has joined #openttd
12:34:10 <xarick> however, there's some advantages in relation to river connectivity. since the whole search is done inside yapf, it is always going to connect the rivers to lakes
12:34:30 <xarick> except... when rivermakewider screws some slope...
12:34:43 <xarick> but that's not yapf's fault
12:36:51 <xarick> the current way in master and PR 13264, there's 2 search methods involved, and they can disagree with the resulting paths
12:37:13 <xarick> leading to some extremely edge cases of river disconnections
12:41:47 <peter1138> kuhnovic, I can't right now but feel free to merge, it was 2 approvals now.
12:43:33 <kuhnovic> And Xarick, this doesn't mean that your yapf proposal is off the table. But it is fundamentally a different algorithm than the one that already existed. That means it needs to be looked at more thoroughly, and needs testing.
12:45:59 <kuhnovic> It can even be slower if you can show it's better than the existing algorithm. I think we all prefer a good and fast enough algorithm over one that leaves weird artifacts.
12:51:16 <xarick> btw... there is strongtype stuff added in required by std::unordered_set, not sure you noticed it.
12:51:46 <xarick> i rarely mentioned it, but hmm yeah...
12:52:09 <xarick> hash stuff or whatever requirement
12:58:52 <xarick> oh, you merged the 2 commits I had
12:59:37 <xarick> the first commit was solely for strongtype, separate from the river changes
13:00:39 <peter1138> kuhnovic, re adding includes, it's possible it slows the overall compile time down, not sure. Not that it matters too much.
13:00:56 <peter1138> I remember there was one include that just breaks compiling on some platforms :o
13:15:20 <kuhnovic> xarick: Yes squashed, keeps things a bit clean. I saw the strongtype stuff. You can use the base type as well, but what you did was nicer.
13:18:55 <kuhnovic> peter1138: This header is precompiled right? So it should only matter once...
13:26:34 <rito12_51026> Is this a correct spelling ` * @return true iff on water`?
13:27:04 <kuhnovic> iff means if-and-only-if
13:47:36 *** Rikests has quit IRC (Remote host closed the connection)
14:04:14 *** WormnestAndroid has quit IRC (Remote host closed the connection)
14:05:08 *** WormnestAndroid has joined #openttd
14:11:26 <xarick> I'm still thinking about a GetTileAreaZ
14:13:29 <xarick> Wondering about TileArea Intersects function...
14:14:40 *** Zathras_4 has joined #openttd
14:15:43 *** Wormnest has joined #openttd
14:24:35 <rito12_51026> That's funny, you're scratching your head just to improve performance a little bit, while I'm replacing implicit conversion with a while loop of explicit conversions.
14:40:08 <xarick> TileArea.Intersects doesn't do what I wanted 🙁
14:41:11 <xarick> i want points of intersection
14:41:46 <xarick> this Intersect really wants to know if an area is inside the other at some tile
14:42:15 <xarick> i was hoping for any of the corners of the ara to intersect
14:45:52 <xarick> misleading variable names...
14:47:14 <xarick> start_x, start_y, end_x, end_y
14:48:19 <xarick> left right top bottom on the openttd map is just confusing.. forces me into mental gymnastics
14:51:00 <xarick> that return is also confusing
14:53:01 <xarick> return start_x2 <= end_x1 && end_x2 >= start_x1 && start_y2 <= end_y1 && end_y2 >= start_y1
14:54:16 <xarick> the 1 and 2 are the areas
15:39:25 *** gelignite has joined #openttd
16:02:01 <xarick> wondering if i can make checking the heights of 2 tiles diagonally adjacent fater
16:02:56 <xarick> but i also need the slopes 🙁
16:03:26 <xarick> it's for RiverFlowsDown
17:55:10 <xarick> seems like I can't come up with something simple
17:56:12 <xarick> there might be a way to check heights and slopes of 2 tiles diagonally adjacent in a more performant way, but I just can't think properly
17:57:54 <xarick> the complexity comes when I want the min and max heights of each individual tile
18:00:20 <xarick> both tiles share the same 2 tile heights, but not 2 others
18:00:59 <xarick> ideally I compute the min height of the shared heights only once
18:01:38 <xarick> but this added complexity might end up crushing any hope for performance if i have to keep track which is which
18:12:14 *** Wormnest has quit IRC (Ping timeout: 480 seconds)
18:16:49 <kuhnovic> Are you sure that that is the bottleneck, or are you just guessing?
18:26:49 *** WormnestAndroid has quit IRC (Ping timeout: 480 seconds)
18:27:10 *** WormnestAndroid has joined #openttd
18:51:53 <xarick> it's not capturing RiverFlowsDown for some reason
18:52:53 <xarick> I moved RiverMakeWider to inside yapf
18:54:19 <jfkuayue> Capturing RiverFlowsInYou…
18:58:37 <locosage> btw, is there some way to remove templating junk from the StrongType and such? Makes any kind of type completely illegible in debugging and compiler errors.
19:01:39 <_jgr_> Not easily, you need to re-arrange the templates and typedefs a fair bit
19:03:44 <locosage> iteresting, but it's not just strongtype that's responsible for the junk
19:03:53 <locosage> guess I could always ask chatgpt to remove it...
19:04:43 <locosage> but it's kinda dumb that you now need llm to understand compiler errors
19:07:42 <xarick> llm = low level machine?
19:08:10 <locosage> large language model
19:25:29 <xarick> when RiverFlowsDown is outside yapf, the debugger can capture it.
19:29:20 <xarick> anyway, it's 3 seconds. This is called from PfFollowNode taking 8,5 seconds
19:30:10 <xarick> something in PfFollowNode is taking the rest of the time...
19:30:38 <xarick> CreateNewNode and AddNewNode...
19:36:02 <xarick> AddNewNode isn't tracked by the debugger 🙁
19:59:44 <xarick> so much money thrown at LLM 🙁
20:05:34 <kuhnovic> The functions were probably inlined so they don't show up any longer
20:25:08 <xarick> there's "dead code" in nodelist.hpp
20:27:58 <xarick> or currently unused as some of you say
20:29:28 <kuhnovic> You're probably talking about PopBestNode? I saw that one too
20:30:39 *** keikoz has quit IRC (Ping timeout: 480 seconds)
20:30:46 <kuhnovic> It seemed like a more efficient way of removing the best node from the open list compared to what Yapf does now. But it needs a performance comparison to see if it matters at all, and I never got around to that
20:30:53 <xarick> TotalCount, FoundBestNode, PopBestOpenNode, and ItemAt
20:31:46 <kuhnovic> AyStar probably used those, but AyStar is no more
20:36:08 <xarick> in binaryheap.hpp, these are unused: Length, Shift
20:43:15 <xarick> hashtable is confusing...
20:44:32 <xarick> I've been deleting functions, it still compiles
20:56:11 <xarick> std::priority_queue exists
20:56:16 *** WormnestAndroid has quit IRC (Read error: Connection reset by peer)
20:56:47 *** WormnestAndroid has joined #openttd
21:08:14 *** Wormnest has joined #openttd
21:12:55 *** keoz has quit IRC (Ping timeout: 480 seconds)
21:21:20 *** keikoz has quit IRC (Ping timeout: 480 seconds)
21:24:55 <kuhnovic> I looked into std::priority_queue at some point. The deal breaker was not being able to remove items that were not the best item
21:33:05 <locosage> if you don't do that often you can mark them "dead"
21:36:12 *** Wolf01 has quit IRC (Quit: Once again the world is quick to bury me.)
21:45:41 <_jgr_> It's generally more practical to just use std::push_heap and friends directly, which is what std::priority_queue uses under the hood
21:49:45 *** keoz has quit IRC (Ping timeout: 480 seconds)
22:07:48 <xarick> Find Spring in master actually takes 6,3 seconds
22:08:34 <xarick> Find Spring in mine + plus a plethora of optimizations: 2,7 seconds
22:09:56 <xarick> those 3,4 seconds I mentioned earlier today already had a few optimizations except for the FindSpring itself
22:10:09 <xarick> it's optimizations on top of optimizations
22:10:16 <peter1138> 6.3 seconds though.
22:12:25 <xarick> one of the optimizations is PR#13067 but it's compiler specific it seems
22:17:03 <xarick> i can't run the linux virtual machine anymore, microsoft updates broke it
22:17:13 <xarick> and i can't compile with clang atm
22:21:15 <xarick> is ubuntu 22.04 LTS the latest?
22:22:53 <peter1138> The latest version is 13.1.
22:23:26 <xarick> gonna see what happens
22:44:49 <xarick> i'm stuck on a blue screen, can't do anything
22:46:26 <xarick> now it's a black screen... oh well
22:47:56 <xarick> nevermind, I'm uninstalling
22:57:42 <xarick> Hyper-V is outdated is my guess...
23:00:05 <xarick> i dont want a password ffs...
23:02:16 <xarick> is this command line only?
23:02:48 <xarick> I'm disappointed already
23:02:53 <dwfreed> what version of windows are you running
23:03:20 <dwfreed> then graphical apps work
23:08:48 <_glx_> yeah it's terminal to navigate, but you can run gui apps, and they even are added to start menu
23:20:29 <xarick> how do I uninstall this?
23:23:33 <xarick> great... it's uninstallable
continue to next day ⏵
