IRC logs for #openttd on OFTC at 2025-05-21
⏴ go to previous day
00:22:05 *** SigHunter has quit IRC (Read error: Connection reset by peer)
00:22:12 *** SigHunter has joined #openttd
02:02:02 *** herms has quit IRC (Quit: bye)
02:16:31 *** Wormnest has quit IRC (Quit: Leaving)
02:30:29 *** WormnestAndroid has quit IRC (Remote host closed the connection)
02:30:34 *** WormnestAndroid has joined #openttd
02:58:25 *** gnu_jj_ has quit IRC (Ping timeout: 480 seconds)
03:33:23 *** Zathras has joined #openttd
03:36:29 *** D-HUND has quit IRC (Ping timeout: 480 seconds)
03:36:44 *** debdog has quit IRC (Ping timeout: 480 seconds)
03:54:22 *** WormnestAndroid has quit IRC (Remote host closed the connection)
03:54:24 *** WormnestAndroid has joined #openttd
04:46:52 <DorpsGek> - Update: Translations from eints (by translators)
05:20:47 *** Flygon has quit IRC (Read error: Connection reset by peer)
06:29:36 *** felix_ has quit IRC (Ping timeout: 480 seconds)
09:21:26 <pickpacket> xarick: yes. Very much so.
09:21:33 <pickpacket> very hi, much hello
09:21:40 <pickpacket> or the other way aroun
09:34:17 <peter1138[d]> Hmm, just lots of groups, not nested groups. Nested really makes it worse.
09:34:39 <peter1138[d]> 600ms down to 340ms average though.
09:34:47 <peter1138[d]> Still unplayable but.
09:41:48 <peter1138[d]> Can AIs even nest groups? Heh
09:54:34 <peter1138[d]> I went overboard and created 50,000 nested groups.
09:56:08 <peter1138[d]> Way beyond the nesting limit, the indentation wraps around 😄
09:57:51 <peter1138[d]> Even 5,000 groups breaks.
09:58:14 <peter1138[d]> With 5,000 groups, drawing the group list window takes about 1.5 seconds in master.
10:14:01 <peter1138[d]> The GUI side still scans the list multiple times. Hmm.
10:19:14 <xarick> is there gonna be a problem if one client has vehicle tile hash size different than the server?
10:22:07 <xarick> because that alone boosts performance so much
10:22:43 <peter1138[d]> We already have rules about not using the tile hash order.
10:42:00 <xarick> eh rats, version mistmatch
10:54:40 *** michi_cc_ has quit IRC (Ping timeout: 480 seconds)
10:57:38 <xarick> 7 bits server @left vs 11 bits client @top, 7 bits client @bot
11:05:50 <xarick> gonna try optimize `RoadVehFindCloseTo` somehow
11:06:35 <xarick> it's the biggest offender so far
11:06:53 <xarick> at least, until the AI maxes out in trains
11:14:53 *** michi_cc_ has joined #openttd
11:23:14 <xarick> isn't it possible to have it iterate from the center and then expand outwards
11:24:39 <xarick> compose the hash from the first vehicle it finds near the center
11:25:39 <xarick> this seems to be only interested in the first vehicle matching that weird criteria, but it's still the one that's closest to the center
11:29:05 <peter1138[d]> What are you talking about?
11:30:55 <xarick> RoadVehFindCloseTo + FindClosestBlockingRoadVeh
11:31:50 *** WormnestAndroid has quit IRC (Remote host closed the connection)
11:31:54 *** WormnestAndroid has joined #openttd
11:43:55 <_glx_> Blocking vehicle can be very very far
11:44:49 <_glx_> The initial one, then there's a chain of blocked vehicle blocking others
11:56:29 <_glx_> Anyway it's only looking for vehicles in a small square
11:57:51 <_glx_> And in normal condition it won't find any
11:58:32 <_glx_> Unless overcrowded station with too many waiting vehicles
12:04:59 *** WormnestAndroid has quit IRC (Remote host closed the connection)
12:05:04 *** WormnestAndroid has joined #openttd
12:07:16 *** Flygon has quit IRC (Read error: Connection reset by peer)
12:11:44 <peter1138[d]> Slightly different?
12:36:14 <andythenorth> both charts have spikes
12:36:37 <andythenorth> "I see no difference"
12:52:22 <yiffgirl> how far off is 15.0 again? it's been a while
12:55:40 <talltyler> We need at least one more beta, then an RC or two
12:57:39 <yiffgirl> anything i can do to help speed things along?
13:16:16 <xarick> computex showing ddr5-10600 memory kits... insane
13:23:31 *** Extrems has quit IRC (Ping timeout: 480 seconds)
13:31:25 <peter1138[d]> Then you know what to do.
13:37:48 <xarick> that clamping feels wrong
13:37:57 <xarick> or am I missing something obvious
13:38:38 <xarick> std::max<int>(0, x + max_dist); but max_dist is already unsigned
13:41:53 <peter1138[d]> If you want to add missing `this->` do so, but don't try to rewrite the algorithm at the same time.
13:58:44 <xarick> i really am bad at describing
13:59:18 <xarick> actually that looks wrong
14:03:06 <peter1138[d]> Yeah, so what about lines 442-445?
14:23:09 *** Extrems has joined #openttd
14:40:34 <xarick> max_dist of 8, isn't that gonna imply at least 3x3 tiles?
14:41:51 <xarick> 8-8 = 0, still same tile_x ; 8+8 = 16, tile_x + 1
14:42:24 <xarick> 7-8 = -1, tile_x - 1 ; 7+8 = 15, still same tile_x
14:47:23 <xarick> moved some stuff around, probably not where the problem lies
14:47:46 <xarick> but no need to calc the diffs before the first 2 tests
14:54:34 <_glx_> moving the static arrays is useless
14:56:40 <LordAro> and the compiler will almost certainly move the assignments around
15:05:44 <xarick> oh, this is called a lot!
15:05:57 <xarick> i tested a TicToc sample of 100
15:06:07 <xarick> i guess i need 10000000 or so
15:09:26 <xarick> derp that was too much
15:10:13 <xarick> > 2025-05-21 16:09:47] dbg: [misc:0] [RoadVehFindCloseTo, 10000000] 44696515 us [avg: 4.5 us]
15:19:04 <_glx_> average shows it doesn't really matters 🙂
15:22:21 <_glx_> knowing the number of calls per tick would give more info
15:24:07 <peter1138[d]> A TicTic that hooks into the gameloop to automatically output every tick instead of a fixed number of goes would be oka.
15:59:46 <peter1138[d]> I don't mean measuring the entire gameloop 🙂
16:00:42 <xarick> number of calls per tick, hmm gonna try do this
16:00:51 *** Zathras is now known as debdog
16:11:19 <xarick> maybe I should do it on FindClosestBlockingRoadVeh?
16:15:29 <yiffgirl> hang on a sec, did the option to turn off vehicle previews make it in?
16:15:29 <yiffgirl> ... oh no, it didn't
16:16:26 <kuhnovic> yiffgirl: Whatever you do, don't do what Xarick is doing 😉
16:17:42 <yiffgirl> i like to imagine i have some level of competence.
16:21:06 <xarick> yeah, I don't know what I'm doing
16:46:07 <xarick> why was the threshold increased from 6 to 8
16:47:45 <xarick> pretty sure this impacts performance
16:48:26 <kuhnovic> I thought you knew how to run a profiler. I guess you un-learned that.
16:49:00 <xarick> oh, i only checked file history
16:49:15 <xarick> I always forget there was a PR attached to the changes
16:56:20 <xarick> ``` static const int8_t dist_x[DIR_END] = { -4, -6, -4, -1, 4, 6, 4, 1 };
16:56:20 <xarick> static const int8_t dist_y[DIR_END] = { -4, -1, 4, 6, 4, 1, -4, -6 };```
17:03:35 <xarick> it actually makes a difference
17:07:31 <peter1138[d]> Something like that, yeah.
17:21:55 <peter1138[d]> The worst case with 50,000 groups was all 50,000 nested. But that's too unrealistic 🙂
17:24:11 <xarick> are the averages also over the number of calls registered?
17:24:12 <peter1138[d]> To me, those numbers say "this is irrelevant"
17:26:04 <_glx_> yes average is per number of calls (as it was before, but now it does it by tick)
17:26:19 <xarick> great! this is awesome
17:27:10 <peter1138[d]> So add this as TicTocTick? 😄
17:27:50 <_glx_> hard part will be where to put the Tick() call
17:28:04 <peter1138[d]> Or maybe the usefulness of per-tick measurements means the regular TicToc is not needed.
17:28:12 <xarick> max_count is unused now
17:29:39 <peter1138[d]> _glx_: probably near where the regular timer system events are triggered.
17:30:08 <peter1138[d]> Depends if pause-mode matters.
17:30:47 <xarick> max_count could become the max ticks?
17:31:09 <_glx_> there's also video thread vs game thread
17:35:12 *** Wormnest has joined #openttd
17:40:13 <peter1138[d]> Ah yes, sometimes I'm measuring non-game tick stuff.
17:45:19 <xarick> I expanded functionality a little
17:48:05 <peter1138[d]> Hmm, 2 thumbs up but no comments.
17:56:46 <kuhnovic> peter1138[d]: The buttons main menu looks a bit funny when the interface scaling is set to 1.75. Much more padding on the left than on the right. Is that because the icons can't scale by non-integer amounts?
17:58:18 <peter1138[d]> It's because the icon is centred within its scaled area, and the text is centred with its scaled area.
18:01:07 <xarick> the averages are kind of meh
18:02:00 <peter1138[d]> Per tick probably a more useful metric.
18:03:05 <peter1138[d]> kuhnovic: There is also a fixed width space (scaled) between the icon and the text.
18:07:18 <kuhnovic> Hmm, the setup makes sense. It's just that the not-scaled icon gives off the appearance of additional padding that isn't present on the right...
18:07:55 <peter1138[d]> The "additional padding" is present... just it's on the right of the image itself.
18:09:06 <peter1138[d]> My non-power-of-two scaling stuff could fix this issue, but that's a marmite option.
18:10:18 <peter1138[d]> Even if we add extra hsep_indent padding to the right, it still wouldn't be equal to the sprite size difference.
18:10:55 <kuhnovic> It would need some additional magic to make it have the right size
18:11:01 <peter1138[d]> One of those "I wish we could just let OpenGL handle it" times ;D
18:11:29 <peter1138[d]> Right, and to make that balanced means stealing some of the space that the image would take up.
18:12:06 <peter1138[d]> And imho that's a no-no.
18:12:41 <peter1138[d]> In my picture it just happens to coincide and look like the hsep_indent is the same as the sprite's extra padding.
18:12:53 <peter1138[d]> But that is just coincidence.
18:13:04 <kuhnovic> Sounds like more trouble than it's worth
18:13:25 <peter1138[d]> As per my comment, centring the image in its box does look better than not doing that.
18:14:00 <peter1138[d]> Alternatively we go with drawing it differently but i'm not keep on that 🙂
18:14:03 <peter1138[d]> Also, don't try zBase.
18:15:18 <kuhnovic> You like the first screenshot in your comment best you mean?
18:16:02 <peter1138[d]> First image is aligned to the edge, second image is centre aligned in the sprite's allocated area.
18:16:34 <kuhnovic> I like the centre aligned one a lot better
18:17:19 <kuhnovic> Alright, not touching this, that's for sure
18:17:50 <peter1138[d]> Yes, it's just a limiation of non-powers-of-two sprite scaling. Not really a UI design issue, IMHO.
18:20:23 <kuhnovic> I agree. Now I just have to get my OCD to agree.
18:37:36 <peter1138[d]> Should've done a review, but, uh, yeah. I didn't.
18:41:15 <xarick> what if TicToc::Tick is whatever you want it to be?
18:41:38 <xarick> you place it wherever you seem fit
18:44:27 *** gelignite has joined #openttd
18:50:49 *** WormnestAndroid has quit IRC (Read error: Connection reset by peer)
18:50:57 *** Wormnest_ has joined #openttd
18:51:21 *** Wormnest has quit IRC (Read error: Connection reset by peer)
18:53:41 *** WormnestAndroid has joined #openttd
18:54:46 <peter1138[d]> Hmm, github bug?
18:55:18 <peter1138[d]> The "View reviewed changes" button shows the current changes, not the changes that... were reviewed.
19:00:09 *** SigHunter has joined #openttd
19:11:25 <xarick> " Improve performance of exclusive preview engine test." written like that I think of reliability %
19:15:34 <peter1138[d]> Because "reliability" is definitely one of the words in the title... or not.
19:22:12 <peter1138[d]> Hmm, still wish I could change #opcodes mid-game.
19:27:51 <xarick> oh the group changes are already in, nice
19:30:09 <peter1138[d]> Yes, if you allow it to be changed, changing it seems to work. But there is
19:30:19 <peter1138[d]> iirc, some reason why it's not allowed.
19:34:51 <xarick> solving a conflict while rebasing, just a min
19:36:33 <xarick> oops, regression failing after
19:38:23 <_jgr_> For completeness, if the ops setting is decreased, the current ops until suspend value for each squirrel VM should be clamped to be within that value as well. Other than that there isn't any reason why it wouldn't work in game.
19:46:23 <peter1138[d]> The memory limit is likely more problematic, at least if reducing it.
19:51:41 <_jgr_> A script being imminently killed off if it uses more memory than the new setting value seems like success rather than a problem to me 😛
19:52:12 *** kuka_lie has joined #openttd
20:09:42 <peter1138[d]> Yeah, true. It's only a problem for the script 🙂
20:14:36 <xarick> i forgot what vargc and vargv do
20:15:50 <peter1138[d]> C-style things you should want nothing to do with.
20:25:30 <xarick> I'm trying to speed this up
20:28:45 <peter1138[d]> Not sure if possible, but use a valuator class instead of a function. The class contains all the required state so it doesn't need to be passed via function call every time, and you only need to pass the item.
20:37:56 <xarick> oops, infinite valuate test in regression is really infinite
20:38:11 <xarick> how does openttd reaches the end of the test then?
20:46:35 <_glx_> xarick: script crashes because valuate took too long
20:46:54 <xarick> i made it not crash though
20:47:01 <xarick> so, how does it knows when to bail out
20:47:29 <peter1138[d]> Your version won't because you broke it.
20:47:42 <_glx_> it can't, it's an infinite loop, purposely done to trigger a crash
20:49:54 <xarick> in my beautiful slow valuate version, scripts are happy to use valuate without crashing, but regression test eventually ends though, is there a timer?
20:50:30 <_glx_> if ran via ctest there's a time limit for the whole run yes
20:51:19 <_glx_> because sometimes openttd crashes and shows an error box and CI needs to finish
20:51:54 *** kuka_lie has quit IRC (Quit: Lost terminal)
20:52:18 <peter1138[d]> Usually when I've done something bad with references or iterators 😄
21:01:27 <xarick> i'm trying to make slow_valuate fast
21:01:34 <xarick> i mean, as fast as it can be
21:01:58 <andythenorth> use a smaller map?
21:02:03 <andythenorth> with fewer things to valuate?
21:02:13 <_glx_> it depends on list size
21:02:16 <andythenorth> hmm I should follow good advice
21:02:24 <_glx_> it's basically a foreach
21:02:27 <andythenorth> Iron Horse compile would be half the time if it was half the trains
21:02:41 <_glx_> then there's the cost of the valuate function itself
21:05:09 <xarick> if it can be made faster, i need to know
21:05:27 <xarick> all the possible tricks
21:07:29 <_glx_> I don't think it's possible
21:10:31 *** treky97 has quit IRC (Quit: User went offline on Discord a while ago)
21:12:57 <xarick> wondering if case works
21:16:34 *** keikoz has quit IRC (Ping timeout: 480 seconds)
21:18:04 <_glx_> oh can even keep `list[item] =` actually
21:19:59 <_glx_> but SwapList should be faster than Clear+AddList I think
21:22:23 <_glx_> oh and Clear was not needed before AddList anyway, values from added list replaces values of existing items
21:22:50 <xarick> I'm worried about the sort method by the original list
21:22:51 <_glx_> but all this won't reflect in tick/ops as they are native calls
21:23:24 <_glx_> ah yes swap will transfer sort
21:24:24 <_glx_> anyway you can still remove the first AddList, and use `foreach(item, _ in this)` and remove the Clear
21:26:24 <xarick> really? isn't it going to double iterate the same items?
21:27:47 <_glx_> you iterate to original list to fill the new one, then add the new one to old list, overriding the values
21:28:32 <_glx_> no need to prefill new list or clear old list
21:29:20 <_glx_> but theses changes won't have any effect on ticks/ops
21:30:07 <_glx_> less ops, since less squirrel code
21:37:14 <_glx_> switch(vargc) might be better than the ifs
21:38:01 <xarick> not sure about the return
21:38:11 <peter1138[d]> I guess you can't just forward the args on?
21:39:13 <_glx_> and vargc/vargv have even been removed in squirrel 3 (that's why we are still on squirrel 2)
21:40:00 <xarick> 174 ticks and 889 ops same result with `this.AddList(list); return;`
21:41:12 <xarick> does parsing the commas and ";" and { } cost operations?
21:41:51 <_glx_> ops are from compiled code
21:42:53 <xarick> well I'm happy with the result, i think
21:43:06 <xarick> will do a big test with some AIs at some point
21:45:58 <xarick> yay, didn't even trigger those time sensitive changes
21:47:01 <xarick> 174 ticks and 849 ops with the openttd's valuate
21:47:41 <xarick> cost only 40 ops, that's too good to be true
21:48:09 <xarick> probably gonna cost cpu now, but at least it won't crash 🙂
21:50:02 <_glx_> AIs might go to sleep until next tick yes
21:50:24 <_glx_> if very expensive valuator on huge list
21:56:00 *** Wolf01 has quit IRC (Quit: Once again the world is quick to bury me.)
continue to next day ⏵
