IRC logs for #openttd on OFTC at 2024-11-05
⏴ go to previous day
01:58:27 *** TinoDid|znc has joined #openttd
01:58:43 *** TinoDidriksen has quit IRC (Read error: Connection reset by peer)
02:21:05 *** Flygon has quit IRC (Read error: Connection reset by peer)
02:43:23 *** Wormnest has quit IRC (Quit: Leaving)
03:33:43 *** debdog has quit IRC (Ping timeout: 480 seconds)
03:49:48 *** orudge has quit IRC (Ping timeout: 480 seconds)
04:45:27 <DorpsGek> - Update: Translations from eints (by translators)
05:48:29 *** TinoDidriksen has joined #openttd
05:48:56 *** TinoDidriksen is now known as Guest8487
05:49:14 *** TinoDid|znc has quit IRC (Ping timeout: 480 seconds)
05:55:53 *** Guest8487 is now known as TinoDidriksen
06:12:08 *** keikoz has quit IRC (Ping timeout: 480 seconds)
09:55:54 <johnfranklin> github has a random connection there, sometimes it works, sometimes not
10:08:49 *** XYZ_ has quit IRC (Ping timeout: 480 seconds)
10:25:16 <truebrain> seems fine, looking at our build logs; so maybe I should have checked before commenting 😛
10:28:15 <truebrain> okay, so the `uc` was already working before 76, in 76 it was just no longer added to `i18n`. Nice 🙂
10:29:00 <truebrain> owh, I ofc also can't merge it atm .. ugh, too strict checkers 😛
10:32:35 <truebrain> Time to not do something again 🙂
10:53:52 <xarick> how do i make TicToc count the number of times it was called?
10:54:09 <peter1138> It does that itself.
10:54:28 <xarick> oh? i need to see it printed in console
10:56:00 <peter1138> It always outputs when the counter reaches max_count, so you know it has been called max_count times whenever it prints.
11:06:37 <xarick> ++this->state.total_count;
11:07:10 <xarick> uint64_t should be big enough
11:10:15 *** D-HUND is now known as debdog
11:10:17 <peter1138> You would be better off using TicToc higher up the call chain.
11:12:42 <LordAro> truebrain: i did something too!
11:13:08 <truebrain> Together we did awesome!
11:22:12 <xarick> i have a weird idea to make river generation take care of sea tiles
11:22:54 <xarick> only add them after rivers are generated
11:23:25 <xarick> DC_NO_WATER will only be bailing out on river tiles then
11:24:22 <xarick> but will get the job done
11:28:42 <xarick> 23282 Microseconds = 0.023282 Seconds... really?
11:29:16 <xarick> so you telling me RiverMakeWider is not what's slowing down river gen?
11:40:11 <peter1138> See I'm not imagining it...
11:41:33 <peter1138> (Sound needed, heh)
11:42:23 <johnfranklin> is this a gamepad?
11:42:40 <peter1138> Seems to be :/ Super low travel activation...
11:43:02 <peter1138> It's a Cherry MX Blue keyswitch. Or was. I have no idea how it can break like this.
11:45:39 <LordAro> there's something reassuring about your keyboard being as filthy as mine
11:45:54 <LordAro> i bought isopropyl and everything. haven't taken it out of the box
11:46:09 <peter1138> It's a keyboard that is used. Anyone with an immaculately clean keyboard has just bought it.
11:46:32 <peter1138> I tried IPA on a bit and it melted the texturing, so no, not doing that!
11:46:54 <xarick> FlowRiver is recursive, hmm interesting
11:47:09 <peter1138> It was 99% (allegedly) IPA, diluting it may have been sensible.
11:47:45 <peter1138> Anyway, I do occasionally remove all the keycaps and stick them in the washing machine, but haven't for a while. (No dishwasher, and that might be too hot anyway)
11:48:24 <peter1138> I think my other keyboard is actually working again now, but actually this one feels better, other than the return key.
11:48:35 <peter1138> Which is odd as they are both meant to be Cherry MX Blue.
11:49:25 <peter1138> The other one has red backlighting, so the switches are different, even though they have the same branding.
11:56:59 <peter1138> Maybe I can swap the switch with another one that doesn't get much use.
12:05:27 <xarick> how does TicToc works for recursive functions?
12:14:52 <peter1138> It will count everything again and again.
12:17:21 <xarick> adds twice as much time ?
12:22:18 <peter1138> The outer call will include all the inner calls.
12:22:26 <peter1138> Or rather, the outer calls.
12:23:11 <peter1138> 1 -> 2 -> 3. 3 will be only 3. 2 will include 2 and 3. 1 will include 1, 2 and 3. So the final result will be 1 + 2 + 3 + 2 + 3 + 3.
12:23:37 <peter1138> So don't use TicToc in a recursive function.
12:23:56 <peter1138> Or at least, not if the recursion call is inside the TicToc.
12:34:42 <xarick> FlowRiver is recursive, so... not sure it's reporting the time accurately
12:36:17 <andythenorth> going to make A Omelette
12:38:33 <talltyler> Except it’s breakfast time here
12:41:14 <peter1138> I had a Tesco cheese & onion roll.
12:50:49 <peter1138> I guess we can remove the "backport requested" tag now.
13:01:25 <peter1138> I mean remove it from PRs it's attached to. I find it unlikely we'll do a 14.2 now. 🙂
13:03:19 <LordAro> (i think we should've done a 14.2, but you're probably right)
13:12:36 <peter1138> The ship has sailed.
13:19:32 <xarick> FlowRiver is the slow function
13:19:46 <LordAro> FlowRiver is the one that actually does the work
13:19:56 <LordAro> it being slow isn't exactly surprising
13:21:23 <xarick> i thought rivermakewider was the one being slow :p
13:22:20 <LordAro> welcome to rule 1 of optimising :)
13:22:42 <_glx_> 20s in debug build with huge map size ?
13:25:57 <peter1138> All those TicTocs slowing it down 🙂
13:26:39 <_glx_> Yeah the measuring affects the experience
13:34:14 <xarick> std::set, std::list, std::advance, std::tie
13:35:42 <kuhnovic> Btw Xarick, did you see the comments on 13047 ?
13:35:55 <xarick> oh, i forgot ,let me look
13:36:24 <LordAro> only two of those stdlib things are containers...
13:36:37 <LordAro> it's like saying "what about printf" ?
13:43:35 <xarick> sometimes the flood is just adding a beach
13:43:45 <xarick> not really adding a water track
13:46:50 <peter1138> It can be improved a little bit by replacing std::set with std::unordered_set.
13:47:12 <kuhnovic> xarick: True, but better safe than sorry. A generic approach is more desirable, especially since discovering / debugging this kind of stuff is difficult.
13:47:32 <peter1138> Although that does change the randomness part.
13:47:34 <_glx_> and it's just setting a bit
13:48:29 <peter1138> Invalidation is cheap, but how costly is recreating what was invalidateD?
13:48:51 <_glx_> it's only done if the area is accessed by PF
13:57:51 <xarick> it does not like unordered_set
13:58:11 <peter1138> Usual caveat, include and StrongType
13:59:45 <peter1138> Depending on how big the std::set is it may be better to just use a vector and search it.
14:00:42 <peter1138> Because there is recursion, maybe there is an opportunity to rejig so that it uses a single data structure instead of creating a fresh one for each call.
14:01:18 <peter1138> That means analysing what is happening, not randomly replacing parts.
14:03:32 <andythenorth> GPT can automate randomly guessing
14:03:44 <andythenorth> "development by word soup"
14:05:24 <xarick> what are those defines there doing
14:06:14 <xarick> i removed them, let's see what happens
14:09:02 <xarick> oh, wait maybe they do something
14:12:20 <xarick> i can't spot any difference
14:13:31 <LordAro> they're similar enough that i'm suspicious that you've uploaded the same screenshot twice
14:20:39 <peter1138> Which defines are you refering to?
14:24:16 *** HerzogDeXtEr has joined #openttd
14:27:38 <peter1138> If you remove them, it won't compile.
14:30:25 <xarick> i removed it and repace what they were doing where they were being used
14:31:20 <xarick> (marks.find(t2) == marks.end())
14:35:26 <LordAro> xarick certified C preprocessor
14:35:50 <LordAro> tbf, they are pretty pointless macros
14:36:15 <peter1138> You have expanded the macros.
14:36:25 <peter1138> Therefore of course the macros are no longer necessary.
14:36:45 <peter1138> This is not the same thing as them doing "nothing".
14:44:02 <xarick> the else if count < 32 part is cheap
14:48:04 <xarick> [Maybe we can make a lake, 1332, 1332] 1436 us [avg: 1.1 us]
14:51:55 <_glx_> using macro (or not) has no effect on the final output as they are handled before the actual compilation start
14:55:02 <xarick> > [do while, 87557, 87557] 11363624 us [avg: 129.8 us]
15:22:33 *** Wormnest has joined #openttd
15:25:45 <johnfranklin> most relevant ads
15:58:54 <peter1138> Oh, that's why that CD won't rip. Scratch through the foil layer :S
15:59:43 <peter1138> And whipper is too strict, it has to be an exact rip or it gives you nothing.
16:03:03 <xarick> std::vector is slower, but i am unable to match the results from std::set 😦
16:09:21 <peter1139> How many items does it fill in it?
16:09:26 <_glx_> with std::vector you need to handle possible duplicates manually too
16:10:40 <_glx_> it's important to know the constraints when chosing a container
16:12:02 <_glx_> and how it's used, like random access or not, ...
16:13:06 <xarick> it's looking for a hill going down by doing a breadth first search, and that can be kinda very flat
16:13:24 <xarick> so, many many tiles can be looked on
16:13:54 <xarick> oh, it's checking collisions
16:14:29 <_glx_> might need a LandRegion pf 🙂
16:15:21 <xarick> but yeah, pretty sure this is the part that's innefficient
16:16:42 <_glx_> I'm quite sure you can't improve without full change of the algorithm
16:17:22 <xarick> im doing dumb stuff again 🙂
16:17:41 <_glx_> doing stuff on tile level will always be slow in extreme conditions
16:18:23 <xarick> oh, got no assert, so im doing well here
16:19:31 <_glx_> like searching elevation in a huge flat map
16:19:41 <xarick> set is faster than vector confirmed
16:23:11 <_glx_> makes sense if you are mostly searching
16:23:23 <mnhebi> Next you'll tell us a switch table is faster than if. :3
16:23:51 <_glx_> set is ordered so it can return early
16:23:55 <peter1138> std::set is slower then std::unordered_set, but of course there are non-stl versions that are faster still.
16:24:06 <_glx_> for vector it needs to check all elements
16:24:25 <peter1138> (Depending on the data)
16:24:49 <peter1138> But the fact there is a std::set inside a recursive process is a bit... "maybe this could be better" to me 🙂
16:25:40 <peter1138> But also, how often do you generate a 4096x4096 map for it to be a problem?
16:25:46 <peter1138> I'm going to say it's never actually a problem.
16:25:47 <xarick> std::list<TileIndex> queue;
16:26:36 <mnhebi> A list? in this memory economy?
16:27:59 <mnhebi> It'd be more efficient just have a bunch of gotos. *runs away*
16:28:11 *** gelignite has joined #openttd
16:28:57 <_jgr_> The queue is not going to be enormously long in this case
16:30:11 <_glx_> anyway first step will be global understanding of the algo
16:31:37 <_jgr_> There isn;t anything complicated happening
16:31:58 <_glx_> I mean before throwing random changes 🙂
16:34:03 <mnhebi> I really wanted to see that list replaced by a vector.
16:34:46 <_jgr_> Something like a std::queue could be a standard container for a queue
16:35:44 <peter1138> std::queue would "just work" here, but whether that improves performance is another matter.
16:36:09 <mnhebi> wouldn't a deque be better?
16:36:16 <peter1138> That's what I meant.
16:36:22 <_jgr_> A std::queue is just a wrapper around std::deque
16:41:07 <mnhebi> peter1138: sorry, I just feel like scrambling bits randomly today :3
16:41:58 <peter1138> It's fine, I meant to type it but didn't. Stupid fingers.
16:42:35 <mnhebi> now you are blaming the memory sticks when the memory controlled goofed. :D
16:52:10 <andythenorth> can we confirm this shouldn't work in nml?
16:52:10 <andythenorth> `const CABBAGE = cargo_classes: bitmask(1);`
16:52:34 <andythenorth> I didn't expect it to, my assumption is that keyword declarations can't be expanded from constants, they're not macros
16:53:37 <mnhebi> I do believe i just referenced a null reading that.
16:55:01 <peter1138> It's a constant, not a preprocessor macro.
17:46:30 *** Wormnest has quit IRC (Ping timeout: 480 seconds)
18:00:50 <mnhebi> I do believe it quite succintly says what it means there.
18:02:29 <mnhebi> what is probably happening is that you are not starting from 0
18:02:52 <mnhebi> if your vector contains 10 elements the last element is 9 not 10.
18:04:14 <mnhebi> So somewhere you are going past the highest allowable number for the end.
18:04:29 <mnhebi> thus, your subscript is out of range.
18:06:11 <xarick> I'm so stupid I can't believe it
18:07:20 <xarick> I was testing vector vs set with a release build that doesn't use asserts 😦
18:16:38 <xarick> they got the same tiles, but in different order
18:16:57 <xarick> std::set on the right, std::vector on the left
18:17:56 <xarick> is it possible to sort a vector?
18:18:23 <xarick> it's only needed to sort when attempting to make a lake, so it's after the flowdown checks
18:18:38 <_glx_> you can sort a vector, but it can be expensive
18:21:34 <xarick> std::sort(marks.begin(), marks.end()) ? just that?
18:21:54 <peter1138> I don't think the sorting actually matters, does it?
18:22:04 <belajalilija> so, likely a stupid question
18:22:35 <belajalilija> but would it be possible to get sand in other climates? i dont mean mixing climates so there's all trees, i just mean sand
18:22:48 <_glx_> I think the main reason for std::set is the duplicates handling
18:23:18 <peter1138> The code that uses it picks a random entry.
18:23:18 *** Wormnest has joined #openttd
18:24:08 <peter1138> It will pick a different random entry because it's not sorted, but it's still random. It does make reproducing the exact same sequence difficult but I don't think that's a problem.
18:25:59 <xarick> that count++ thingy isn't needed if we can just check the size or marks
19:28:30 *** HerzogDeXtEr has quit IRC (Read error: Connection reset by peer)
19:55:21 <xarick> std:vector is faster than std::list for the queue
19:55:42 <xarick> not sure how to use std::deque
19:55:59 *** Wormnest has quit IRC (Ping timeout: 480 seconds)
19:56:19 <peter1138> 1) Replace `std::list` with `std::deque`, 2) done.
20:05:09 <xarick> almost as fast as std::vector
20:06:23 <xarick> 10103100 us [avg: 115.4 us] vs 10214268 us [avg: 116.7 us]
20:08:01 <xarick> 11619286 us [avg: 132.7 us] std::list
20:08:36 <xarick> so all we can do is reduce it by 1 second and half
20:10:10 <xarick> how do i make unordered_set work?
20:20:24 <_glx_> you just need to implement std::hash<StrongType>
20:23:28 *** Wormnest has joined #openttd
20:26:52 <xarick> I can't use std::sort on an unordered_map?
20:30:27 <_jgr_> Consider what "unordered" means
20:33:31 <xarick> ``` std::vector<TileIndex::BaseType> marksunordered_set_vector(markunordered_set.begin(), markunordered_set.end());
20:33:31 <xarick> std::sort(marksunordered_set_vector.begin(), marksunordered_set_vector.end());```
20:36:56 <xarick> 5294417 us [avg: 60.5 us]
20:37:26 <xarick> final time from 21 seconds to 16
20:40:31 <xarick> let me test with assert
20:43:09 <xarick> no assert found, it's a legit improvement!
20:45:38 <xarick> those marks.clear() at the end aren't required
21:00:45 *** tokai|noir has joined #openttd
21:00:45 *** ChanServ sets mode: +v tokai|noir
21:01:35 <xarick> River_FoundEndNode has some weird coding style
21:07:34 *** tokai has quit IRC (Ping timeout: 480 seconds)
21:09:50 *** gelignite has quit IRC (Quit: Stay safe!)
21:13:48 *** nielsm has quit IRC (Ping timeout: 480 seconds)
21:23:05 <peter1139> No need to use ::BaseType with std::vector.
21:24:25 <xarick> it's a temporary vector from the unordered_set
21:24:47 <_glx_> sorting an unsorted_set makes no sense
21:25:16 <xarick> but it halfed the time inside that do while loop
21:25:38 <xarick> this sorting is done only for the lake
21:25:44 <xarick> after the do while loop
21:25:48 <peter1139> In this case it doesn't need to because the actual order of the set is not important.
21:27:28 <peter1139> std::set<TileIndex>::const_iterator cit = marks.cbegin(); std::advance(cit, RandomRange(count - 1));
21:27:39 <peter1139> This is picking a random tile from the set.
21:27:59 <peter1139> There is zero reason to sort the unordered_set just to pick a random tile.
21:28:30 <xarick> marks.size() is different than count - 1, it's not all of the set
21:29:13 <xarick> but i guess you're right
21:29:32 <xarick> it's sorting tileindexes instead of whatever got there first
21:29:51 <_jgr_> I suppose that you'd lose the seed determinism by indexing into an unsorted container like that (if anyone still cares about mapgen seedsthese days)
21:30:32 <Borg> hmm where PBS signals are stored? I extracted signalsw.grf and nsignalsw.grf and I cant seem to find them
21:30:32 <peter1139> I suspect that -1 is a bug, I don't think it's important that it always excludes the highest tile found.
21:32:09 <xarick> gonna check the Blame on that part
21:32:12 <peter1139> _jgr_, yes, that's the only reason, and generally we don't really care given different settings can change things drasticaly.
21:33:06 <xarick> i think it weird that tileindexes are sorted, std::set must have been a bad choice
21:33:48 <peter1139> It's probably because whoever wrote it had heard of std::set but not std::unordered_set.
21:34:03 <peter1139> Same reason we have std::maps that can be std::unordered_map.
21:37:43 <_glx_> std::unordered_set requires extra work for StrongType derivatives
21:38:09 <peter1139> Very minor work. It's pretty easy to implement std::hash if you want, or just use ::BaseType.
21:39:05 <_glx_> I'm testing with optional operator()
21:39:06 <peter1139> Looks like it originally used an array of bools, the same size as the map.
21:39:32 <_glx_> so it's std::unordered_set<TileIndex, TileIndex>
21:43:02 <peter1139> Code that no longer exists, don't bother looking at it.
21:44:29 <xarick> well, apparently it's doing it with sorted TileIndex
21:46:23 <_glx_> but it's doing random stuff, it randomly chose a number (i) of tiles to consider, then increases a value until i valid values are passed
21:54:57 <xarick> just wondering if all these iterations are doing the same
21:55:46 <xarick> is there gonna be an off by 1 somewhere?
22:08:31 <_glx_> no it's equivalent because the while uses --i
22:09:47 <_glx_> so +1 was needed for while(--i) loop
22:11:48 <xarick> gonna test the marksbool 🙂
22:12:45 *** Wormnest has quit IRC (Ping timeout: 480 seconds)
22:13:02 <_glx_> marks was a huge array of bools
22:14:33 <_glx_> most of them being false
22:16:34 <_glx_> so the loop was searching the Nth true in the whole array
22:18:32 <xarick> i got this monstrosity of a code
22:23:14 *** keikoz has quit IRC (Ping timeout: 480 seconds)
22:25:37 <peter1139> vector is only sorted if you sort it, or add items in sorted order.
22:26:11 <xarick> hmm the two values in question
22:28:39 <xarick> I suspect one thing...
22:30:10 <xarick> this set is supposed to keep all river tiles that have been placed from the first time the call to FlowRiver
22:31:04 <xarick> this set needs to be defined in CreateRivers
22:31:38 <xarick> and then all of FlowRiver calls add tiles to it
22:32:11 <xarick> gonna see if I'm right
22:42:20 *** Wormnest has joined #openttd
22:44:02 <Borg> damn.. I cannot replace PBS sprites..
22:44:43 <peter1139> xarick, the original FlowRiver called MemSetT near the top to ensure the list of marks was cleared. So no, it's not meant to persist them.
22:46:03 <peter1139> Action 0x5 will replace path signals, but if a railtype defines it own custom signals those are not replaced.
22:46:29 <Borg> peter1139: its all default, no custom rails etc..
22:46:37 <Borg> I guess im doing sth wrong :)
22:46:40 <Borg> what is that offset thingie?
22:47:10 <Borg> im trying to replace ONLY PBS (standard)
22:50:46 <Borg> thats definition.. I see basic 05 w/o offset
22:51:01 <Borg> anyway. digging thro table/sprites.h
22:51:07 <Borg> so.. lets try trail and error
22:53:23 *** Wolf01 has quit IRC (Quit: Once again the world is quick to bury me.)
22:53:45 <peter1139> Definitely not 5205.
22:54:08 <peter1139> static const SpriteID SPR_IMG_SIGNAL_ELECTRIC_PBS = SPR_SIGNALS_BASE + 124;
22:55:36 <Borg> but yeah.. 5205 does NOT work..
22:55:39 <peter1139> Action 0x5 does not use global IDs.
22:55:47 <peter1139> That's the entire point of Action 0x5.
22:56:34 <peter1139> static const SpriteID SPR_CANALS_BASE = SPR_SIGNALS_BASE + PRESIGNAL_SEMAPHORE_AND_PBS_SPRITE_COUNT;
22:57:21 <peter1139> Okay, 124 is... not quite right.
22:57:45 <Borg> ahh! I forgot about that tool
22:57:48 <Borg> thanks a lot :) lets see
22:58:12 <xarick> bed now, no time to debug this further today
22:59:05 <peter1139> The absolute number is not useful.
23:02:59 <peter1139> Oh, that 124 is the specific signal sprite used in the GUI, not the *first* signal sprite in the range.
23:03:15 <Borg> im close :) thanks a lot peter1139
23:03:20 <Borg> I see those sprites now in game
23:03:28 <Borg> but they are wrong (not correct aspect)
23:09:55 <Borg> holy shit :D thats stuff is complicated
23:10:02 <Borg> doing RTFS and still cant make it work
23:17:29 <peter1139> ... like in my screenshot...
23:18:43 <Borg> I made them 3 pixels shorter
23:19:01 <Borg> now they dont go above bridge
23:19:29 <_glx_> action5 type 04 has weird stuff
23:19:43 <peter1139> I don't think it does?
23:20:13 <_glx_> I mean the meaning of groups 8-14
23:24:17 <_glx_> anyway the offset for PBS in action5 type 04 is 7*16 = 112
23:25:08 *** HerzogDeXtEr has joined #openttd
23:25:32 <Borg> okey.. late here :) good nite
23:28:43 *** Borg has quit IRC (Quit: leaving)
continue to next day ⏵
