IRC logs for #openttd on OFTC at 2024-01-17
⏴ go to previous day
00:04:39 <xarick> 12% faster at being slower
00:17:32 *** Wormnest has quit IRC (Ping timeout: 480 seconds)
00:27:46 *** audunm[m] has quit IRC (Quit: Client limit exceeded: 20000)
00:50:53 *** Wormnest has joined #openttd
02:02:47 *** herms has quit IRC (Quit: bye)
03:22:52 *** Wormnest has quit IRC (Quit: Leaving)
03:44:19 *** debdog has quit IRC (Ping timeout: 480 seconds)
06:08:51 *** keikoz has quit IRC (Ping timeout: 480 seconds)
07:28:10 <rau117> _zephyris: How about changing zero to this?
07:47:43 <kuhnovic> Danes and Norwegians might get confused 😆
07:52:07 <LordAro> I would suggest the number of places where 0 & O are in the same place and it actually matters which is which is very small
07:52:15 <LordAro> the vast majority of cases it'll be obvious from context
07:52:45 <LordAro> this all started because xarick had a moment and didn't notice that you can't have 'O' in a hex number
08:04:27 <wensimehrp> There's inconsistency in the English text:
08:04:27 <wensimehrp> {COMMA}{NBSP}bag{P "" s} of sweets
08:04:27 <wensimehrp> {COMMA} batter{P y ies}
08:04:27 <wensimehrp> Why is it `{COMMA}{NBSP}` for the first line and `{COMMA}(space)` for the second line?
08:05:51 <wensimehrp> not the plural thingy
08:21:02 <peter1138[d]> Because the first one is intended to wrap between the words. The second one doesn't need to do that.
08:24:17 <peter1138[d]> (I mean, just a guess)
08:25:26 <peter1138[d]> Or this commit did some and missed a few.
08:30:49 <peter1138[d]> LordAro, steep around here.
08:31:22 <_zephyris> rau117: Programmer bias 😉 Slashed/dotted zero is a quirk of programming and technical fonts, not normal body text fonts... I'll probably add it to the monospace font though.
08:32:51 <rau117> But if it makes it easier to distinguish between zero and O, why not add it everywhere?
08:36:46 <_zephyris> It's not conventional for body text fonts, doesn't match the original sprite font, and adds confusion with theta and slashed O.
09:13:10 <peter1138[d]> Perfect coding font 😉
09:17:33 <peter1138[d]> And the difference between O and 0 is noticeable.
09:18:26 <rau117> *Well yeah, O is blue, and 0 is green-ish…*
09:28:26 <peter1138[d]> Is that an O or a 0?
09:36:31 <reldred> what the HELL are those trains
09:37:51 <peter1138[d]> Should never have allowed mixing engine sets.
09:39:15 <locosage> well, that's one "set" if you don't count vanilla
09:39:37 <locosage> and it is even used as intended :p
09:46:25 <peter1138[d]> Damn, c++20 misses std::span::const_iterator.
09:46:53 <Eddi|zuHause> we should make a xerox font that replaces all 6s by 8s and 1s by 4s or something :p
09:57:33 <peter1138[d]> Oh dear, my pc crashed
09:58:53 <peter1138[d]> Enough that keyboard LEDs stopped responding
10:08:01 <peter1138[d]> kernel/nvidia/gpu issue 😮
10:15:56 *** asymptotically2 has joined #openttd
10:20:48 *** Flygon has quit IRC (Read error: Connection reset by peer)
10:24:55 *** tycoondemon has joined #openttd
10:43:18 <peter1138[d]> 2048x16384 map is running slow because we just need to optimise things.
10:48:13 <xarick> those map sizes would only make sense if all else was also on the same scale
10:50:51 <locosage> that's like double 4k, he should've tried that in vanilla xD
10:52:01 <peter1138[d]> On a 1GHz Celeron.
10:52:11 <peter1138[d]> Sorry 12% faster, 1.1GHz.
10:52:46 *** D-HUND is now known as debdog
10:55:25 <LordAro> lol that latest response
10:55:27 <locosage> tbf world ticks don't really do that much, should be plenty of room for optimization
10:55:38 <locosage> what's the slowest part of that on jgrpp now, still water?
11:05:18 <peter1138[d]> When there's 33 million tiles... there's a lot to do.
11:09:17 <locosage> yeah, but nothing happening on the most of them
11:10:12 <locosage> don't need to tick grass tiles for example
11:10:20 <locosage> water too unless there is flood
11:10:38 <locosage> trees are a bit tricker but if made fully procedural won't need ticks too
11:18:41 <peter1138[d]> If you have a NewGRF that implements the ambient sound callback there's a .5% chance that any clear tile can play a sound. That does a silly amount of work 🙂
11:19:46 <locosage> that doesn't need to be in tile loop at all
11:19:57 <locosage> can easily emulate 5% pick with outer loop
11:20:12 <locosage> also, I suppose it only plays for visible tiles anyway?
11:20:58 <xarick> I'm bad with names... INVALID_WATER_REGION_PATCH_LABEL being 0 annoys me, because I also want 255 to be INVALID_WATER_REGION_PATCH_LABEL
11:21:02 <peter1138[d]> Yes but if it decides to play a sound it resolves the callback, then checks if the tile is visible, then starts it.
11:21:11 <peter1138[d]> But probably nobody uses that callback anyway.
11:21:54 <locosage> those checks can be reversed, only iterate visible tiles for example
11:21:58 <_jgr_> Only tiles which are actually on-screen evaluate that, surely?
11:22:01 <xarick> 0 actually means.... "no water"
11:22:06 <peter1138[d]> I guess a callback can set registers so it needs to be consistent.
11:22:21 <peter1138[d]> No, it's in the tileloop.
11:22:32 <peter1138[d]> AmbientSoundEffectCallback()
11:23:16 <peter1138[d]> trees and water call it too.
11:23:31 <locosage> oh god, still, can just randomly pick 5% of the tiles, and for invisible just run callback for the chance of registers
11:23:50 <locosage> or, tbh, just don't let in ~~lay eggs~~ set registers
11:24:10 <peter1138[d]> It's a global feature, maybe there are no temp registers.
11:24:26 <peter1138[d]> I dunno, they didn't exist when I rewrote the resolvers.
11:24:40 <_jgr_> Temp registers don't need to be preserved between callbacks
11:25:16 <peter1138[d]> I wonder if a NewGRF actually uses this callback though.
11:25:54 <_jgr_> I'm sure I've heard things like coastal noises with some GRFs
11:26:33 <_jgr_> In any case the callback isn't run if the user turned ambient sounds off
11:27:17 <peter1138[d]> locosage: Dirt and grass tiles are the same. You need to tick them to turn dirt into grass. And then maybe handle snow.
11:27:47 <locosage> yeah, that would need some extra stuff to separate those
11:27:57 <locosage> like a mask if "anything happening" on a tile
11:28:28 <xarick> isn't sound happening on a new thread?
11:28:34 <_jgr_> It doesn't matter that much how much stuff you do in that tile loop, the performance hit comes from the cache miss of looking at the tile at all
11:28:56 <peter1138[d]> xarick: Playing them, yes. Telling them to play, no.
11:29:41 <locosage> _jgr_: both matter, otherwise water wouldn't be so slow
11:29:55 <locosage> but, yeah, idea of "happening" mask is to avoid looking at the tile
11:30:02 <_jgr_> I've already reduced the cost of water flooding
11:30:29 <locosage> you did, not vanilla I think ;)
11:30:33 <_jgr_> Likewise with snow movement
11:31:44 <_jgr_> You need to look at neighbouring tiles to get the full height/slope so not doing that unnecessarily is a fairly easy win
11:34:01 <peter1138[d]> Generating that map must have taken a while.
11:38:25 <locosage> hm, wonder if there are some easy pickings in the way tile loop is run
11:38:42 <locosage> like maybe sort tiles before running loop procs
11:39:43 <locosage> unfortunately sorting isn't exactly cheap, but doesn't need full sort either, just group by proximity
11:41:08 <peter1138[d]> Sorting means you need to make a list.
11:41:40 <locosage> making list isn't that expensive, especially statically sized
11:41:49 <_jgr_> The tile loop is in a pseudo random order, and you're not going to visit so many tiles in one tick that there would be any significant clustering
11:41:52 <locosage> and it's array not list rly
11:42:59 <locosage> _jgr_: yeah, maybe, page size is 4k iirc? with 256 mean distance that isn't many hits...
11:43:18 <locosage> and map array is like 10 bytes per tile or smth
11:43:32 <_jgr_> It's more about cache lines than pages
11:43:59 <_jgr_> Though TLB misses are also an issue
11:44:32 <locosage> well, idk what that is but I remember 4k contant in this context for some reason xD
11:45:00 <locosage> may be some hopelessly outdated knowledge tbh
11:45:38 <locosage> ugh, I'm having windows phone flashbacks
11:45:50 <locosage> no math soprocessor, sorting 20k floats was a challenge xD
11:47:04 <_jgr_> Looking at my branch I did put in a prefetch for the next tile, not sure how much difference that really makes though
11:56:20 <locosage> oh, btw, and no one will likely even notice of only a small area is looped with lfsr and then repeated ;)
11:57:01 <locosage> can probably even do some like prime-number sized chunk of memory so there is no obvious pattern
11:58:12 <xarick> is it okay codestyle to use two callback functions?
11:58:44 <peter1138[d]> FindVehiclesWithOrder() uses 3...
11:59:31 <xarick> just not sure if what I have in mind is gonna work
12:00:42 <xarick> Kuhnovic has a Visit function which looks for all connected adjacent water regions
12:01:16 <xarick> but I needed a function that looks just at the connected adjacent region that the pf found as neighbour
12:03:27 <xarick> i'm looking if I should adapt the original function
12:03:38 <xarick> to also accept only 1 neighbour
12:03:46 <xarick> or make my own function
12:12:11 <xarick> there's something wrong with current master
12:12:25 <xarick> just look at vehicles behaviours
12:14:26 <xarick> not my branchs fault, something broke vehicles, they have no idea where to go
12:20:44 <xarick> look at the bus, look at the hovercraft, then look at the helicopter
12:22:26 <LordAro> bug in the usual please
12:31:59 <peter1138[d]> Classic example of "well it compiles"
12:33:36 <peter1138[d]> Things only turn clockwise...
12:43:32 <peter1138[d]> So it's the changes in the C++20 commit, but not actually the change to C++20.
12:44:43 <peter1138[d]> Oh, It's missing a bracket, lol
13:02:28 <FLHerne> bikeshed - IMO braces are {} and () are brackets or parentheses or whatever?
13:04:40 <peter1138[d]> Parenthesis is American English.
13:05:06 <merni> but even in BrE I've never seen () as braces
13:05:16 <merni> occasionally "round brackets"
13:05:24 <peter1138[d]> Yeah I meant brackets but brain not working I guess.
13:34:05 <xarick> why am I getting this warning
13:35:13 <peter1138[d]> You're probably building with asserts disabled.
13:35:25 <xarick> yes, was gonna check release
13:35:56 <peter1138[d]> In that screenshot, it's only used in the assert. You've disabled the assert so it's not actually used.
13:41:23 <_glx_> enclose the declaration with WITH_ASSERT
13:41:37 <peter1138[d]> Or add [[maybe_used]]
13:42:19 <peter1138[d]> Or comment it out fo testing 😄
13:42:28 <_glx_> but release have assert enabled by default IIRC
13:44:23 <_glx_> unless you have -DOPTION_USE_ASSERTS=OFF in your config files
13:44:40 <xarick> I turned off because of ticc tocc
13:52:55 <xarick> nice, no more warnings
13:55:23 <_zephyris> The formal terms are generally parentheses `()`, brackets `[]`, and braces `{}`. In common British English, I'd say it's bracket `()` and square bracket `[]`.
13:55:43 <_zephyris> FLHerne: The formal terms are generally parentheses `()`, brackets `[]`, and braces `{}`. In common British English, I'd say it's bracket `()` and square bracket `[]`.
13:58:39 <xarick> NE and NW have the loop iterating from 0 and ascending
13:59:22 <xarick> NE and SW, the i replaces the x coordinate
14:00:21 <xarick> SW and SE have the loop iterating from WATER_REGION_EDGE_LENGTH - 1 and descending
14:00:38 <xarick> NW and SE, the i replaces the y coordinate
14:06:29 <xarick> gonna ask my friend bing chat
14:06:52 <xarick> oh, he goes by another name now, Copilot
14:13:52 <xarick> holy crap, the dude is good!
14:17:20 <xarick> directly copy pasted from Copilot
14:31:03 <merni> That's your reminder that these "AI"s are just hallucination generators
14:31:22 <merni> It knows what is "likely", not what is "right"
14:32:34 <xarick> 2 and 4 are dealt with
14:32:41 <xarick> 1 and 3 got me worried
14:33:38 <xarick> "if unique_labels gets large." hmm by large, how much does he mean?
14:35:06 <xarick> there can be about 32 neighbours per diagdir, 128 unique labels
14:35:27 <xarick> is this large enough to consider unordered_set?
14:40:41 <xarick> not even sure if 128 can be technically achievable
14:42:28 <xarick> there can be 16 aqueducts crossing the edge, each one going to a different region
14:43:12 <xarick> and then there can be 16 ship depots at the edge of the neighbour region, each one occupying 1 patch
14:43:23 <xarick> but if there are ship depots, there can't be aqueducts
14:43:37 <xarick> so maybe a 64 technical limit
14:45:07 <xarick> or 96 if interleaving water patches
14:47:32 <xarick> oh, right... aqueducts can't cross over other aqueducts
14:47:55 <xarick> the other sides would have less neighbours
14:57:37 <peter1138[d]> Adjacent aqueducts can only link to the same neighbour.
14:59:16 <xarick> they get their own patch
14:59:50 <xarick> same neighbour region though, but different patches
15:02:35 <xarick> unless of course, the water is connected
15:24:47 <xarick> it's a bit of a rabbit hole
15:25:09 <xarick> or leave it to Kuhnovic?
15:27:02 <xarick> the assumption that if there's only 1 water patch on both regions goes down the drain. That is eliminated, which then leaves WaterRegion member number_of_patches useless. That is eliminated too.
15:28:10 <truebrain> peter1138[d]: tnx for fixing my inability to program 😄
15:28:30 <truebrain> Stupid precedence of operators 😛
15:37:02 <peter1138[d]> I was getting excited that I could use ranges/views... but clang 15 is buggy and doesn't work with them 😦
15:39:53 <LordAro> ranges are scary anyway
15:40:16 <peter1138[d]> Red becomes green.
15:40:57 <peter1138[d]> Works with GCC, not with Clang15 😦
15:43:28 <peter1138[d]> Although to be honest iterating _sorted_cargo_array is most probably fine anyway, and doesn't need filters.
15:44:01 <peter1138[d]> Some things just get done in a different order.
15:53:25 <peter1138[d]> truebrain: It was funny, I was thinking there was some behaviour change due to C++20... but no 🙂
15:53:53 <truebrain> Just my incompetence 😄
16:08:51 <xarick> it's a perfectly good function for this purpose, do I duplicate it?
16:12:03 <xarick> ok i'll deal with them
16:13:03 <peter1138[d]> Oh, Debian does have clang 16... Hmm.
16:13:19 <peter1138[d]> Pretty sure it didn't when I was installing clang...
16:14:19 *** Wormnest has joined #openttd
16:15:59 <peter1138[d]> Move it (or bits of it) and make the API method call it.
16:16:08 <peter1138[d]> I imagine you don't need the tile checks.
16:16:29 <xarick> variable 'highest_assigned_label' set but not used, that is false, it's being used
16:17:18 <xarick> it's inside the for loop
16:19:40 <xarick> oh I see what they mean...
16:20:15 <xarick> it serves no purpose anymore
16:29:29 <xarick> where do I put AreWaterTilesConnected?
16:34:06 <peter1138[d]> Somewhere watery.
16:39:10 <peter1138[d]> ```gfx_layout.h:149:109: error: use of overloaded operator '<' is ambiguous (with operand types 'const std::stack<TextColour, std::vector<TextColour>>' and 'const std::stack<TextColour, std::vector<TextColour>>')
16:39:10 <peter1138[d]> if (lhs.state_before.colour_stack != rhs.state_before.colour_stack) return lhs.state_before.colour_stack < rhs.state_before.colour_stack;```
16:50:53 <LordAro> computer crashing definitely getting worse, that's about the 5th today
16:55:37 <LordAro> "the Dijkstra A* algorithm" hmm.
17:02:13 <peter1138[d]> Hmm, feels like -5°C to -7°C.
17:02:28 <peter1138[d]> Either I need a lot of layers, or I stay in 😮
17:31:18 *** Wormnest has quit IRC (Ping timeout: 480 seconds)
17:37:25 <locosage> LordAro: well, bfs, dijkstra and a* are all variations of pretty much the same algorithm
17:37:36 <locosage> dijkstra adds weight, a* adds heuristic
17:37:44 <LordAro> i've never heard it described like that though
17:40:27 <locosage> yeah, afaik a* doesn't have anything to do with Dijkstra other than being based on his algorithm
17:42:23 *** Wormnest has joined #openttd
17:54:35 <xarick> I first thought water_regions.cpp was a good place, but that's inside pathfinder folder... feels weird to have a script include a pathfinder file
18:08:20 <xarick> I'm really worried about performance
18:09:24 <xarick> the loss of "1 patch on both regions" assumption is gonna have an impact for sure
18:10:35 <LordAro> no point worrying until you can show it's actually an issue
18:11:30 <LordAro> "an impact" can range from 1 CPU cycle (i.e. nanoseconds) to waiting for a network server to respond to a request
18:11:38 <xarick> oh snap, didn't remove the include
18:20:04 <xarick> considering the vast majority of the regions in the ocean has 1 patch.... it's considerable, but ok, let me test
18:24:39 <talltyler> Maybe test before opening a PR
18:26:21 <xarick> maybe that "has cross-region aqueduct" will have another purpose
18:26:53 <xarick> oh, nevermind... it won't
18:27:15 <xarick> or will it?... need to think
18:27:49 <xarick> if it happens at the edge, then the aqueduct is garanteed to be cross region
18:30:13 <peter1138[d]> Other than that the comparison on gfx_layout.h:149, clang-16 compiles okay.
18:32:19 <xarick> debuglevel yapf=9 doesn't give a report about ms 😦
18:36:38 *** Wormnest has quit IRC (Ping timeout: 480 seconds)
18:40:00 <peter1138[d]> You should compare with and without.
18:40:03 <DorpsGek> - Update: Translations from eints (by translators)
18:43:27 <_glx_> us are more precise than ms
18:44:37 <xarick> gonna check what I can do
18:45:14 <_glx_> Anyway that's the kind of tests you should do before opening the PR 🙂
18:45:54 <xarick> heh, didn't think much of it until I was actually done
18:46:19 <peter1138[d]> Of course, being fast is not useful if it's completely wrong.
18:47:58 <xarick> just wondering if there are any other special cases than aqueducts
18:48:25 <xarick> i though about ship depots in perpendicular positions
18:48:51 <xarick> but there's no connection to the edge in this situation, bit is not set
18:50:25 *** gelignite has joined #openttd
18:57:32 <xarick> it's even worse on my version
18:57:52 <xarick> that's what happens when going from 16 bits to 32 bits
19:00:27 <xarick> the one with 236 ms is due to the actual implementation of finding nearest depot
19:00:51 <xarick> it doesn't know where it is, it starts BFS
19:08:49 <LordAro> i feel like i read a thing recently that said source_location was Bad(tm)
19:11:36 <LordAro> can't use it with constexpr, basically
19:12:46 *** Wormnest has joined #openttd
19:15:08 <peter1138[d]> Or MacOS it seems.
19:16:12 <Rubidium> MacOS'll probably work, if we change the runner to macos-13... but that's in beta so not the best thing to do right now.
19:19:48 <frosch123> LordAro: reads more like "can't use with sizeof()", don't think that's a concern for us, we are not embedded
19:25:33 <peter1138[d]> Hmm, there's an operator<=> in there 😄
19:38:01 <frosch123> i checked stl_stack.h
19:38:21 <frosch123> it complains about declaration and implementation
19:38:31 <frosch123> line 122 is the declaration for the implementation at 410
19:39:17 <frosch123> i can't reproduce this on godbolt though
19:59:22 <peter1138[d]> Does not crash for me. Hmm.
20:00:51 <peter1138[d]> The stacktrace doesn't look helpful.
20:06:59 *** Wormnest has quit IRC (Ping timeout: 480 seconds)
20:08:38 <frosch123> NWidgetCore::IsLowered is called for this=nullptr
20:10:18 <frosch123> yeah, someone made a bad copy&paste refactoring
20:11:59 <_glx_> can't find symbols when opening the dmp
20:15:07 <peter1138[d]> We should remember to do commits like this straight before making a full release ;D
20:15:40 <Rubidium> we did good here, we waited until after the beta :)
20:20:33 <_glx_> ah no it's an official build, weird MSVC doesn't find the symbols
20:27:12 <LordAro> ooh, a new response from 56independent
20:30:35 <peter1138[d]> (nullptr)->IsLowered() doesn't crash for me. Hmm.
20:30:37 <xarick> not quite as good as the original
20:30:50 <LordAro> peter1138[d]: that's exciting
20:31:46 <_glx_> hmm dmp from #11801 opens fine, I guess I tried too early for #11819 (it's from todays nightly)
20:31:49 <LordAro> hmm, £700 for new CPU/MB/RAM
20:33:38 <LordAro> especially as i spent a similar amount on flights & hotel yesterday
20:33:54 <LordAro> but computer's crashed 5 times today, it does seem to be getting worse
20:34:24 <xarick> feels like I need to specialize the whole function to make it faster
20:36:31 <truebrain> frosch123: Lol .. "oops"
20:36:55 <_zephyris> In file included from /home/richard/openttd/src/settingsgen/settingsgen.cpp:10:
20:36:55 <_zephyris> /home/richard/openttd/src/settingsgen/../stdafx.h:73:10: fatal error: span: No such file or directory
20:36:55 <_zephyris> 73 | #include <span>
20:36:55 <_zephyris> compilation terminated.
20:36:57 <_zephyris> Can anyone give me a hint how I'm being dumb?
20:37:12 <_glx_> truebrain: how long is the delay between build and symbols availability ?
20:38:29 <LordAro> _zephyris: maybe rerun cmake?
20:39:39 <truebrain> So far this C++20 stuff is going great! 😛
20:40:18 <truebrain> _glx_: Will check in a sec
20:41:28 <_zephyris> LordAro: Hmm, didn't help. I've rerun `sudo apt build-dep openttd`, which did pick up some changes, and `cmake ..` finished with no errors...
20:41:57 <_glx_> cmake should re-run by itself
20:42:04 <peter1138[d]> What libstdc++ is installed?
20:42:15 <peter1138[d]> (Or rather, -dev)
20:42:16 <LordAro> ^ the obvious answer is that the compiler/stdlib is too old
20:42:27 <LordAro> but i'd expect cmake to error if that were the case
20:42:35 <_glx_> cmake would faild on c++20 detection I hope
20:44:16 <_glx_> truebrain: BTW it's fine for yesterday's nightly
20:44:40 <truebrain> `‘<unnamed>.MidiFile::DataBlock::realtime’ may be used uninitialized [-Wmaybe-uninitialized]`
20:44:42 <truebrain> at least a new warning
20:45:17 <truebrain> _glx_: `65A82A1Cfe5000` .. look at the capatilization here
20:45:29 <truebrain> capital A and C, but lowercase f and e
20:45:50 <truebrain> that is some unusual way of doing that 😛
20:46:05 <truebrain> on yhe symbol server it is called `65A82A1CFE5000`
20:46:18 <truebrain> and ofc, as a sane human, the symbol server is case sensitive
20:46:56 <peter1138[d]> Is it title-casing those letters...
20:48:20 <_glx_> `'crash20240116195857.dmp' (Minidump) : Chargé 'J:\Symbols\openttd.exe\65A6D7201041000\openttd.exe'. Les symboles ont été chargés.`
20:48:31 <_glx_> of course it's fine for yesterday's
20:48:39 <_glx_> no letters in this part
20:48:40 <_zephyris> peter1138[d]: `libstdc++.so.6 (libc6,x86-64) => /lib/x86_64-linux-gnu/libstdc++.so.6` - I'll just do a blanket upgrade and hopefully it'll solve it.
20:49:05 <LordAro> (.6 is a "major version" and hasn't changed in years)
20:49:15 <peter1138[d]> dpkg -l | grep libstdc++ | grep dev
20:50:02 <truebrain> ```The signature of a PDB identifier is uppercase, but the age is lowercase.
20:50:02 <truebrain> The timestamp of a PE identifier is uppercase, but the size is lowercase.```
20:50:30 <truebrain> can I please get some money from the donation funds to fly to Microsoft HQ and slap someone around for a bit
20:50:35 <truebrain> just for my and their sanity?
20:50:48 <truebrain> (slapping around with a trout, ofc; nothing illegal or criminal)
20:53:19 <truebrain> they really hate casing
20:53:40 <truebrain> on which you can enable case sensitivity
20:54:16 <truebrain> okay, seems to be an upstream issue with `dump_syms`
20:54:31 <truebrain> now I need an official source that says how MS does this, as Sentry is not actually an official source 🙂
20:56:51 <truebrain> owh, I know how I can just fix this easily
20:57:18 *** gelignite has quit IRC (Quit: Stay safe!)
20:57:37 <_glx_> no consistency at all with lower/upper
20:57:43 <_zephyris> peter1138[d]: `ii libstdc++-9-dev:amd64 9.4.0-1ubuntu1~20.04.2`
20:58:29 <_glx_> span comes from compiler I think
20:58:49 <peter1138[d]> libstdc++-12-dev:amd64: /usr/include/c++/12/span
20:59:19 <truebrain> it is funny how disconnected C++ versions are from the header-files 😛
20:59:44 <truebrain> for example, clang-13 accepts C++20 fine, but its header-files utterly fail on C++20
21:00:07 <truebrain> I assumed there would be some validation for that, but it seems not
21:00:25 <peter1138[d]> So Ubuntu 20.04 has a fairly old libstdc++ it seems.
21:01:26 <_jgr_> Ubuntu 20.04 uses gcc 9
21:01:36 <_glx_> CI uses an even older linux for legacy (with gcc10)
21:01:40 <_jgr_> You can install a newer gcc separately, but it's a bit of a faff
21:02:00 <peter1138[d]> libstdc++-10-dev seems to exist, not sure if that'll help.
21:02:46 <_zephyris> Presumably just upgrade to Ubuntu 22 then
21:02:50 <LordAro> _jgr_: gcc-10 is in ubuntu repos
21:03:13 <LordAro> but if willing, upgrading to ubuntu 22 is probably best
21:04:14 <peter1138[d]> Such inconsiderate developers 🙂
21:04:32 <peter1138[d]> Straight-line ship pathfinding eh?
21:04:50 <_zephyris> I'll do the upgrade, its a virtual machine (far too much of a noob to be trusted with linux as a primary os!)
21:05:13 <peter1138[d]> Easy to take a backup then 🙂
21:05:21 <truebrain> should we add a check in CMake for this stuff?
21:06:32 <truebrain> std::span -> GCC 10 or clang-libc++-7
21:07:15 <_glx_> but the 20 in cmake is supposed to check that
21:07:39 <_jgr_> Alternatively you could put an #ifdef, with `using span = std::span` if it's there, or use the one in core if it isn't
21:07:39 <truebrain> no, GCC 9 already has basic C++20 stuff
21:07:59 <truebrain> _jgr_: I kinda removed the one in core 😛
21:09:02 <_jgr_> I know, but that doesn't mean that it's irretrievable
21:09:20 <truebrain> I so want to make jokes now 😛 But yeah 🙂
21:09:36 <truebrain> _glx_: try downloading the symbols again
21:10:13 <truebrain> /me hopes the 404 is not cached 😄
21:11:13 <_glx_> and the callstack is useless 🙂
21:11:15 <xarick> I can't do better than this
21:11:23 <truebrain> _glx_: well, for that I cannot be blamed! 😛
21:11:41 <_glx_> ```> openttd.exe!ExceptionHandler(_EXCEPTION_POINTERS * ep) Ligne 341 C++
21:11:41 <_glx_> [Des frames sont manquantes, aucun binaire chargé pour SogouPY.ime]
21:11:58 <xarick> but overall a 1100 us more
21:12:44 <truebrain> I btw now on the symbol server uppercase that part of the URL for incoming request; as we store them always in full uppercase, they magically match now
21:12:52 <truebrain> worked out for the other OSes too, they are also in full uppercase
21:12:57 <truebrain> bit of luck there 🙂
21:13:04 <xarick> why do I have a feeling TrueBrain has me on ignore?
21:13:54 <truebrain> it might shock you, but my world doesn't evolve around yours
21:16:41 <_glx_> xarick: well 1100us is 1.1ms
21:17:09 <xarick> from 3000 to 4100 it's a bad increase
21:18:03 *** Wolf01 has quit IRC (Quit: Once again the world is quick to bury me.)
21:18:09 <_glx_> depending on how often it happens it might be negligeable
21:19:37 <wensimehrp> I set the music volume to 0, but the music is still playing. Is that a bug?
21:20:08 <truebrain> can you still hear it?
21:20:32 <truebrain> would be weird if that wouldn't be a bug, would it? 😄
21:21:02 <_glx_> could be the used base set
21:21:21 <truebrain> okay, that sounded more snarky than intended, lol
21:21:43 <_glx_> midi is a pain to work with 🙂
21:22:06 <truebrain> anyway, if 0 isn't muted, that is unexpected; so to the bugtracker with you! 😛
21:22:42 <wensimehrp> _glx_: Yeah I think so. I switched to orginal_windows and the problem disappears
21:23:25 <_glx_> music volume is not absolute, it's hard to handle properly
21:23:39 <truebrain> we can just make that at 0 it mutes, not?
21:23:48 <truebrain> I mean, it is an easy treshold?
21:24:08 <truebrain> anyway, please make a bug-report, as otherwise it will be lost in the void called chat 😛
21:26:07 <peter1138[d]> We'd much rather it be lost in the bug tracker 🙂
21:34:07 <truebrain> so I now have 2 developers cleaning up after me .. a 3rd means revoking commit rights, right? 😛
21:34:26 <truebrain> in my defense, they all start with `for (uint c ....)`
21:36:30 <truebrain> owh, I can just close it: not reproduceable! 😛
21:37:08 <_glx_> not sure we can do anything, we actually tell directmusic to set volume to 0 for all channels
21:37:29 <_glx_> and documentation is hard to find
21:37:34 <wensimehrp> I think the author or the base music set would respond in a day or so.
21:37:41 <truebrain> wensimehrp: mind adding your OS in the ticket? Kinda missing atm 🙂
21:38:18 <truebrain> _glx_: maybe we can just stop playing the music, while "continuing" or something weird 😛
21:38:56 <_glx_> dmusic is kinda out of support in MS documentation
21:40:47 <peter1138[d]> We set per-channel volumes.
21:41:01 <peter1138[d]> Maybe we should we master volume instead.
21:44:01 <_glx_> I don't know if it's possible
21:45:32 <peter1138[d]> Also there are two MIDI drivers for Windows. That's greedy 😄
21:45:43 <peter1138[d]> Why would it not be possible?
21:45:57 <truebrain> what `-d` level to use to see fonts being loaded?
21:45:58 <peter1138[d]> Main issue is you can't tell if it's supported.
21:47:10 <truebrain> hmm, fontcache, I guess, but that isn't loading what I wrote in my config
21:47:39 <wensimehrp> Interesting... No problem with Linux this time
21:48:10 <_glx_> yeah it's a different driver
21:49:29 <peter1138[d]> What is "Touhou"
21:50:00 <peter1138[d]> (Baseset apparently... but not found on abanananananananas)
21:50:21 <truebrain> he wrote that in the ticket? 😄
21:51:30 <wensimehrp> peter1138[d]: That's a custom base music set
21:51:36 <truebrain> okay, so if a font is not found, on Linux you get no report about it ignoring your setting? Hmm
21:51:58 <peter1138[d]> Just remove fonts.
21:51:59 <peter1138[d]> And remove text.
21:52:08 <peter1138[d]> it can all be done with hotkeys.
21:52:11 <peter1138[d]> It'll be 12% faster.
21:52:16 <_glx_> looking at source, it seems win32 and dmusic are almost identical
21:52:54 <truebrain> peter1138[d]: didn't I once make a patch for you that fixed all bugs in the game? By removing the whole source code and leaving an empty main function? 😛 😄
21:54:15 <_glx_> could it be this baseset using more that 16 channels ?
21:55:11 <peter1138[d]> No, it's not possible.
21:55:42 <_glx_> anyway it might be an issue at windows level too
21:56:47 <peter1138[d]> I can't inspect the MIDI itself because it's a custom music baseset not on bananas 😉
21:58:00 <peter1138[d]> It could be using CC 39/40 which is also channel volume, but 14 bit instead of 7 bit.
21:59:02 <peter1138[d]> Oh not sure, it's 7 and 39, 7 gets adjusted but there's no real need to adjust 39.
21:59:36 <peter1138[d]> If it is used then the volume could be between 0 and 1... so probably not that.
22:01:18 <truebrain> changing AA in Game Options doesn't set the screen to dirty 😄
22:01:48 <truebrain> why can I not toggle AA if I have traditional sprite font selected but have a config that uses another TTF?
22:02:43 <peter1138[d]> Oh yeah, I have a patch for that (toggling) 🙂
22:02:54 <truebrain> please PR it; otherwise I will have to write it myself 😛
22:04:21 <truebrain> the AA button is just funny. I can toggle it on, click sprite font, and nothing changes. But I can't toggle AA off again, as you can only toggle it if sprite font is not selected 😄
22:04:25 <truebrain> I think we have to rethink those buttons a bit
22:04:53 <truebrain> also the header is `Interface size`, which is now a lie 🙂
22:05:47 <peter1138[d]> MIDI CC 120 is channel mute, but I don't think there's much support for that.
22:07:05 *** keikoz has quit IRC (Ping timeout: 480 seconds)
22:08:16 *** Wormnest has joined #openttd
22:09:57 <truebrain> okay, harfbuzz just doesn't support hinting or rasterization
22:11:09 <peter1138[d]> We use freetype for rasterization anyway.
22:11:28 <peter1138[d]> But harfbuzz appears to have issues with rounding, and just rounds down.
22:12:09 <truebrain> how do you conclude that? (out of interest of learning this stuff)
22:12:47 <peter1138[d]> Some random thread I read somewhere, and it was related to the A being something like 794 instead of 800 units wide.
22:12:52 <peter1138[d]> (Or whatever the numbers were)
22:13:49 <_zephyris> Oh, interesting. I was surprised that a 0.6% error lost a pixel!
22:14:17 <truebrain> but don't we feed harfbuzz with those positioning .. hmm
22:19:28 <truebrain> okay, partially it is related to mixing int and float
22:19:45 *** nielsm has quit IRC (Ping timeout: 480 seconds)
22:19:53 <peter1138[d]> Yeah, I guess it could be US rounding badly 😄
22:20:07 <truebrain> yeah ... `advance` is a float, stored in an int
22:20:14 <truebrain> fixing that makes it looks a lot better already
22:20:16 <truebrain> but doesn't fix all issue
22:21:09 <xarick> when to const and when not to const? I never get it
22:23:27 <peter1138[d]> That is so weird.
22:23:51 <peter1138[d]> Is it expecting us to do sub-pixel rendering?
22:24:24 <truebrain> no; the space left+right is fine, it is just all right, and not left+right
22:25:39 <peter1138[d]> Btw have you tried `font "Tahoma,"` ?
22:25:47 <_glx_> xarick: when you return a pointer it might be const, but for normal numbers there's no need
22:25:52 <truebrain> this is Tahoma? Or what do you mean?
22:26:08 <peter1138[d]> Or `font "Arial,"`
22:26:15 <_glx_> wasn't the issue with bold ?
22:26:25 <truebrain> no, it is an issue all around
22:27:02 <truebrain> but my solution isn't really great; but it is a rounding issue, it seems
22:29:39 <truebrain> so our layouter does everything in floats; and when it is being rendered, they are all casted to an integer
22:29:47 <truebrain> as ofc we can't do sub-pixel rendering 🙂
22:30:07 <truebrain> but harfbuzz works in a raster of 64 in width
22:30:28 <truebrain> so it feels there it goes a tiny bit wonly
22:30:42 <truebrain> when I add something between 0.1 and 0.2 to the x-offset, things look a lot better all of a sudden
22:33:12 <_glx_> "It reflects the language support claimed by the compiler, but it does not necessarily imply complete conformance to that standard" <-- so useful when a compiler says I'm ok with c++20 but it might no fully support
22:33:41 <truebrain> none support it "fully" yet, which might be part of the issue there 😄
22:33:45 <peter1138[d]> > HarfBuzz lets you specify the degree subpixel precision you want through a scaling factor. You can set horizontal and vertical scaling factors on the font by calling hb_font_set_scale(font, x_scale, y_scale).
22:34:08 <truebrain> yeah, it is set to 64 atm
22:34:12 <truebrain> maybe that is just a bit much for us
22:34:31 <truebrain> well, it is `fontSize * 64` atm
22:34:43 <peter1138[d]> Seems to be 64 * fontsize, so I don't know what it's expecting...
22:35:05 <truebrain> its rasteris 64, so any multiple of that, was my thinking
22:39:48 <peter1138[d]> Changing that doesn't really seem to affect anything as far as I can tell.
22:41:11 <peter1138[d]> Tahoma Bold is so weird. It loses all boldness at certain sizes.
22:41:20 <_glx_> looks like we'll still need to use fmt
22:41:22 <truebrain> it is a very old and broken font 😛
22:42:05 <peter1138[d]> Yeah, it's built for when 8 or 10 pixel high text was still normal.
22:43:01 <truebrain> funny, a GitHub search tells me almost nobody uses `hb_font_set_scale`
22:43:07 <truebrain> but as you mentioned, it doesn't seem to do anything anyway
22:43:54 <peter1138[d]> If I set scale to 0, 0 then toggling between sprite font and OpenTTD-Sans has almost exactly the same layout.
22:44:22 <peter1138[d]> But it doesn't do much to Tahoma!
22:44:55 <peter1138[d]> Hmm, what if it's removed.
22:45:19 <peter1138[d]> Removed uses some default then.
22:45:42 <truebrain> I think as long as you stay in the 64 raster, it doesn't really matter
22:45:49 <truebrain> so only with really big font sizes I imagine it matters
22:45:52 <peter1138[d]> I don't know what that means 🙂
22:46:04 <peter1138[d]> But 0, 0 is good for OpenTTD-Sasns.
22:46:25 <truebrain> the old OpenTTD-Sans, or the fixed version?
22:46:34 <peter1138[d]> The current version.
22:46:38 <truebrain> that already looks good here?
22:47:01 <truebrain> Except for the `W`, I see no difference between sprite-font and OpenTTD-Sans 😛
22:49:41 <truebrain> how can I easily switch between fonts .. hmmm
22:51:19 <_zephyris> Looks a bit like kerning is enabled in master and disabled in 0, 0
22:52:23 <truebrain> peter1138[d]: odd, can't really reproduce that result
22:54:11 <peter1138[d]> Question about hb_font_set_scale which doesn't really answer...
22:54:34 <peter1138[d]> That suggests it's related to EM, nothing about fontsize * 64.
22:54:35 <xarick> that's definitely not what I experience when toggling that button
22:54:52 <peter1138[d]> _zephyris: It's meant to look like Master, righht? 🙂
22:55:08 <truebrain> just a bit odd that changing `set_scale` has no effect
22:56:14 <peter1138[d]> Ah, that says fontsize * 64.
22:56:39 <_zephyris> peter1138[d]: Yup, looks perfect. Character rendering looks pixel perfect, and the shift in position is kerning (particularly characters following `t`, `r` and `f` being 1 px closer).
22:57:08 <peter1138[d]> Hmm, maybe I should fiddle with FONT_SCALE instead of just setting to 0 🙂
22:57:27 <truebrain> if I change FONT_SCALE, everything breaks
22:57:31 <peter1138[d]> > /** harfbuzz doesn't use floats, so we need a value to scale position with to get sub-pixel precision. */
22:57:33 <truebrain> which makes no sense, as set_scale should fix that
22:57:56 <peter1138[d]> Yes, and it makes no sense that me changing set_scale, but not changing FONT_SCALE, does NOT break it!
22:58:23 <peter1138[d]> It's like it's actually always 64.
23:01:06 <truebrain> the FontType integration calls the function already
23:02:05 <truebrain> what version of HarfBuzz have you installed?
23:02:09 <peter1138[d]> from hb_ft_font_create_referenced?
23:02:33 <truebrain> yeah, it works a bit more complicated; when the freetype changes it runs some callbacks which causes some updates
23:02:37 <truebrain> so it is a bit async
23:02:44 <truebrain> might explain the difference in behaviour 😄
23:03:27 <truebrain> but yeah, FreeType integration takes over settings the scale, basically
23:03:38 <truebrain> explains why the FONT_SCALE isn't actually configurable 🙂
23:03:51 <truebrain> `(int) (((uint64_t) ft_face->size->metrics.x_scale * (uint64_t) ft_face->units_per_EM + (1u<<15)) >> 16)`
23:03:52 <peter1138[d]> And we just happen to use 64.0 which is the same as FreeType's fiddling.
23:04:23 <truebrain> so they already do some form of rounding here
23:04:40 <peter1138[d]> I wonder why 0, 0 did something. Maybe that triggers some flag. I should just find the source...
23:05:00 <truebrain> you just linked the source 😛
23:05:17 <peter1138[d]> By "find" I mean read it and find where it is 😄
23:06:00 <truebrain> but okay, if we would render the font correctly, there should be no difference between sprite-font and TTF, I gathered from your shots?
23:06:03 <truebrain> is that what Windows is doing?
23:06:18 <peter1138[d]> No, there should be a difference due to kerning, which the sprite font can't do.
23:06:28 <peter1138[d]> Master as it is now is correct.
23:06:58 <truebrain> that last sentence does not help me at all peter1138[d] 🙂
23:07:11 <xarick> I get everything resizing when toggling
23:07:12 <truebrain> you mean the first animation you send?
23:07:28 <peter1138[d]> The first one, where it changes positions slightly, is correct for OpenTTD Sans.
23:07:44 <peter1138[d]> Zephyris has set up kerning pairs, which is impossible with the sprite font.
23:07:57 <truebrain> I don't know what kerning is 😛
23:08:03 <truebrain> I learnt all of this, and forgot about it 😄
23:08:12 <peter1138[d]> It's similar to keming...
23:09:09 <_zephyris> Context specific character spacing...
23:09:31 <truebrain> why we need to feed language to the font rendering 😛
23:09:40 <_zephyris> ... and if kerning is disabled, the sprite and TTF should be essentially identical, including character spacing
23:10:04 <_zephyris> Yeah, I think kerning tables are language-specific - I'm pretty sure the cyrillic and greek kerning need fixing.
23:10:23 <truebrain> at least I can fix Tahoma uglyness
23:10:49 <peter1138[d]> is that with adding a random value?
23:10:55 <truebrain> (broken as fuck btw, but I am starting to understand what it is doing)
23:13:08 <truebrain> just the `AI` is weird ... in 13.4 it had spacing between
23:13:20 <truebrain> but no matter what I check, I do not see that happening with harfbuzz
23:31:23 <truebrain> everything smells like a rounding issue, but I can't put my finger on where ...
23:31:31 <truebrain> although I still find odd how FreeType sets the scaling
23:40:22 <truebrain> owh, but it is the same value we were feeding it
23:44:16 <truebrain> okay .. this is a bit odd
23:44:23 <truebrain> so I have been looking at the values hb gives us
23:44:30 <truebrain> mostly, looking at Highscore Table
23:44:31 <peter1138[d]> Oh, I missed the 1<<15 🙂
23:44:43 <truebrain> the `a`, the glyph is 8 pixels wide
23:44:47 <peter1138[d]> print (this->face->size->metrics.x_scale * this->face->units_per_EM + (1 << 15)) >> 16;
23:44:49 <truebrain> but hb gives an advance of 7.7 pixels
23:45:20 <truebrain> that can't really be right, can it?
23:46:42 <truebrain> ah, no, render tells me it is 7 wide
23:47:05 <truebrain> the `T` is 6 pixels wide, but hb gives an advance of 7.9
23:48:38 <peter1138[d]> That... actually rings a bell.
23:48:48 <truebrain> if you fix one issue, you get 2 back
23:48:56 <truebrain> but what did you thinker with?
23:49:00 <peter1138[d]> That looks okay but yeah...
23:49:09 <peter1138[d]> `x_advance = ceil(glyph_pos[i].x_advance / FONT_SCALE);`
23:49:11 <truebrain> nah, all kind of weirdness here
23:49:30 <peter1138[d]> Always rounded up. So never always right.
23:49:58 <peter1138[d]> Do we need to implement sub-pixel rendering? 😄
23:50:16 <truebrain> no, this seems to be different
23:50:25 <truebrain> harfbuzz seems to overestimate the width of all characters
23:50:37 <truebrain> if I compare with the old ICU
23:50:43 <truebrain> there I see it knew the `T` was 6 pixels
23:50:49 <truebrain> but harfbuzz thinks it is more like 7
23:51:18 <peter1138[d]> This is what I get normally.
23:51:20 <truebrain> so either of two things can be wrong
23:51:24 <truebrain> either we render the font wrong
23:51:29 <truebrain> or harfbuzz reads the information wrong
23:52:09 <peter1138[d]> Don't forget that advance include inter-character spacing, which the rendered sprites don't include.
23:52:28 <peter1138[d]> (Sprite font includes it in the sprites)
23:52:46 <truebrain> with ICU you see that it very nicely adds a pixel after every character
23:53:07 <truebrain> no clue if that is actually correct
23:53:09 <peter1138[d]> According to my last screenshot it doesn't seem to 🙂
23:53:21 <truebrain> is that with the old ICU layouter?
23:53:41 <peter1138[d]> Oh! Sorry. No, HB. We still call it ICU in the code... :/
23:53:56 <truebrain> lolz, now you mention it
23:54:29 <truebrain> _glx_: would you be able to get me a screenshot of the main menu with latest OpenTTD with Tahoma Bold, 13px for "normal" font?
23:54:45 <truebrain> just so I know how Windows thinks it should look 😛
23:54:51 <truebrain> (who knows, ICU might have been wrong too)
23:55:11 <truebrain> any semi-recent master
23:55:23 <truebrain> nightly works, for example
23:57:59 <_glx_> yeah I need to translate bold 🙂
23:58:38 <truebrain> here too, like clockwork, character, 1 pixel empty, character
23:58:58 <truebrain> that is not what harfbuzz is doing 😄
23:59:38 <truebrain> so the `A` renders 9 pixels wide
23:59:46 <truebrain> Harfbuzz returns an advance of 8.9
continue to next day ⏵
