IRC logs for #openttd on OFTC at 2024-03-29
β΄ go to previous day
01:22:42 *** Wormnest_ has joined #openttd
01:31:35 <johnfranklin> How does Andy's Child #1 regard their gaming PC now after using it for three months?
01:36:37 *** Wormnest_ has quit IRC (Quit: Leaving)
02:30:34 *** ChanServ sets mode: +v tokai
02:37:56 *** tokai|noir has quit IRC (Ping timeout: 480 seconds)
02:39:44 *** Eddi|zuHause2 has joined #openttd
02:44:12 *** Eddi|zuHause has quit IRC (Ping timeout: 480 seconds)
03:21:34 *** debdog has quit IRC (Ping timeout: 480 seconds)
04:02:09 *** jinks has quit IRC (Remote host closed the connection)
04:41:24 <DorpsGek> - Update: Translations from eints (by translators)
04:45:51 <merni> glx22viaGitHub: Ah, right... `font` outputs as "sprite" when the sprite font is in use, but you can't actually set it that way
04:46:34 <merni> Means the output of `font` is technically ambiguous if you have another font called "sprite", since it could be either that or the actual sprite font
06:56:07 <silent_tempest> Like it would display as "Sprite, Regular"?
06:56:15 <silent_tempest> I would expect...
06:56:30 <silent_tempest> Not ideal in any case
07:59:19 <ahyangyi> As opposed to "Sprite, Zero Sugar"?
08:19:09 <rau117> rau117: What is the chance that suggestion to move the buttons will be noticed and implemented before 14.0?
08:19:09 <rau117> Will it be accepted if posted as [suggestion]: on GitHub (non-existent category made of [bug]: ), or is the only way out is to rely on the forum?
08:22:39 *** Eddi|zuHause2 is now known as Eddi|zuHause
08:22:51 <Eddi|zuHause> no, suggestions don't go on github, only real changes
08:22:52 <jfs> 14.0 is most likely in 3 days and it's unlikely a change like that would be included on that short a deadline
08:22:53 <merni> Before 14.0, no chance. 14.0 will be out on Monday.
08:24:01 <merni> Github discussion might work
08:25:12 <rau117> eh, okay, since thereβs no reason to be in a hurry, Iβll go to the forum, thanks for the answer.
08:25:12 <rau117> *It seemed to me that the change would be super-simple to implement so it probably can be done in couple of hours or even minutes*
08:25:54 <jfs> the fastest way to get a change done is to make it yourself, yes
08:26:57 <reldred> things however are rarely as simple as they seem
08:28:19 <merni> And even small features can introduce bugs. Hence the need for the "feature freeze" before a release
08:30:21 <silent_tempest> I've been looking around in the source. I can't figure out where the ./media/basesets/openttd.grf file comes from
08:30:53 <silent_tempest> I gather it's some kind of archive for sprites? Maybe also it includes the OpenTTD fonts as well?
08:31:21 <silent_tempest> How was it made? I can't find any cmake or script to make it?
08:31:26 <Eddi|zuHause> no, the font is in the baseset (e.g. opengfx)
08:31:37 <Eddi|zuHause> .grf files are compiled with grfcodec
08:31:39 <merni> Made with grfcodec like any other grf
08:32:38 <Eddi|zuHause> openttd.grf has some random additional sprites that weren't in the original TTD
08:33:11 <Eddi|zuHause> like, for entirely new features that needed a button.
08:34:57 <silent_tempest> No github repo for that binary?
08:35:15 <silent_tempest> I found a download link on the openttd but it says it's from 2016?
08:35:27 <Eddi|zuHause> the sources for the openttd.grf are in the main repo
08:35:58 <merni> Nobody made an grfcodec release to update the binary on the site it seems
08:36:11 <merni> But the repo has the code
08:36:35 <silent_tempest> Yeah it was on the second page of repos... OpenTTD has 2 pages of repos and i didn't notice that
08:36:40 <Eddi|zuHause> media/basesets/openttd/ has the sources for openttd.grf
08:37:22 <jfs> anyway, that's where the build rules for openttd.grf are
08:38:19 <Eddi|zuHause> but like i said, things like the font are in a separate repo (like opengfx, or any other flavour of baseset)
08:39:46 *** trey032040 has joined #openttd
08:40:21 <rau117> Discord Moderator: we have spam here, please help
08:41:01 <merni> In a few other channels too
08:41:18 <silent_tempest> I've been annoyed by the order the font size types in this enum:
08:41:48 <silent_tempest> If it was just the enum order I would be less annoyed but it also uses that order to loop over and sometimes print
08:42:29 <silent_tempest> I tried just fixing the enum but it did not go well the old openttd.grf file
08:42:49 <silent_tempest> I initially forgot to fix the FS_BEGIN = FS_NORMAL
08:43:03 <silent_tempest> But even after fixing that mistake my fonts are now reveresed in the UI Lol
08:43:08 <jfs> just leave it be, treat it like opaque constants
08:43:31 <jfs> and if you want to present things in a different order then make an array of the ordering you want
08:43:47 <Eddi|zuHause> making such a change comes with crazy amounts of historic baggage. you don't want to deal with that
08:44:00 <silent_tempest> Yeah I am noticing that...
08:44:39 <silent_tempest> Without know how hard it was going to be I figured it would be worth it... And it continues to get more and more not worth it Lol
08:44:44 <Eddi|zuHause> basically, this order was decided 30 years ago, before this project even started
08:44:49 <jfs> `static const FontSize font_sizes_display_order[] = { FS_SMALL, FS_NORMAL, FS_LARGE };`
08:45:01 <silent_tempest> Related but an easier change. Rename "FS_NORMAL" to "FS_MEDIUM"
08:45:13 <jfs> and then loop over that array to display your stuff
08:46:09 <Eddi|zuHause> silent_tempest: that's just changing for change's sake and will probably be rejected.
08:46:36 <merni> Well... not sure. Other places do call it medium
08:46:54 <jfs> if you use a static array to control the ordering, you can also make that an array of a small struct that contain additional data for the processing of each one
08:47:55 <Eddi|zuHause> merni: maybe. but then you need to frame it in some more general "make things more consistent" context.
08:47:57 <silent_tempest> Sometimes it's called normal and other times it gets called Medium
08:49:24 <silent_tempest> I'll look at it tomorrow for consistentency
09:02:57 <merni> Hm, the "use traditional sprite font" setting only overrides the default font, not all fonts
09:09:24 <merni> That doesn't seem to be right, though by a reading of InitFonCache
09:14:39 <truebrain> You know you can't delete things from the IRC side, right? π
09:15:10 <truebrain> (sorry, just pulling your leg π Happens if you name your president after me π )
09:16:04 <merni> I was just stupid and thought "LoadFreeTypeFont" meant LoadSpriteFont
09:16:11 <merni> truebrain: Not a president yet :P
09:16:23 <truebrain> You are not stupid; the code is very hard to follow for any sane human
09:17:21 <Eddi|zuHause> i've never seen a sane human anywhere near this part of the internet
09:26:35 *** HerzogDeXtEr has joined #openttd
09:28:05 <merni> So, does it make sense to use the sprite font if that setting is on, even if some other font is chosen in settings/console?
09:28:28 <merni> Otherwise, if you already have a custom font set, enabling that setting for sprite font does nothing until you reset to the default font first
09:28:37 <merni> Of course, fallback for missing characters should be retained...
09:33:17 <merni> Hmm, does this mean fallback is not working somehow, or not triggered properly?
09:33:23 <merni> (this is from 14.0-RC3)
09:34:56 <xarick> oh, I missed the release of RC3
09:35:43 <merni> `[2024-03-29 15:05:16] dbg: [fontcache:0] Font is missing glyphs to display char 0xBB5 in medium font size`
09:37:21 <merni> shouldn't that trigger fallback?
09:40:44 <merni> bah, forget this. Finish current pr for now, look at default font setting and broken fallback later
09:52:51 <rau117> reldred: well... I don't know... copy one line and move anther⦠looks very simple to me
09:52:51 <rau117> *and although for me now it will be 100 hours in a row of attempts to fix the laptop and run modern visual studio on it...*
09:53:41 <merni> If you can run mingw or wsl that may be easier
09:54:16 <truebrain> rau117: you really have to stop this behaviour, and consider this a warning. If you really think it is "that easy", learn how to program and do it yourself. You also don't bring your car to the shop and tell them: owh, this should be very simple, you just have to move this one thing and you should be done. It does not go over well. Either learn how to do it yourself, or stop telling us "it is
09:58:46 <rau117> truebrain: Okay, okay, I'm sorry. Itβs just that code already, but I stupidly have nowhere to compile it.
09:59:00 <truebrain> Don't make a "you issue" our issue; tnx
10:00:13 <jfs> if you put effort into learning to set up a development environment and learning to use it, we will also (generally) be helpful with that and answer questions about it
10:01:03 <jfs> everyone who has contributed to OpenTTD so far have had to learn from somewhere, and it all starts with a personal desire to help improve the game
10:08:52 <locosage> it truly isn't hard to change though
10:08:55 <rau117> jfs: thanks, but I have a very clear and direct problem - my Windows is too old and broken, fixing it will take some time, probably I cannpt fix it in time for the 14.0 release.
10:08:55 <rau117> I'm not sure that I'll have time to fix everything before the game's release. And if there is no rush, then the problem can be postponed... for some unknown time.
10:08:55 <locosage> but not sure I like it
10:12:29 <andythenorth> locosage: breaks gestalt
10:12:34 <andythenorth> there's no obvious grouping
10:12:55 <reldred> locosage: yeah not a fan
10:15:32 <rau117> It wasn't the best idea, but it requires a minimum of changes.
10:15:32 <rau117> A better solution would be to put these buttons in a manage list, but this is a little(?) more difficult to implement.
10:15:39 <truebrain> rau117: Lol, and just moments later you do it again. I am not sure in how many ways you need to be told this, but stop it. You are again guilt tripping us in doing your work. Stop doing that, it is annoying. We don't work for you, we don't owe you anything.
10:16:17 <peter1138> Set things up ready for 14.1 π
10:16:20 <truebrain> If you would ask, that is fine. But this constant: "owh no, it is simple, it would take you less time than me" really has to stop
10:16:48 <peter1138> (Given the number of existing backport request PRs, pretty sure there'll be a 14.1)
10:16:58 <truebrain> peter1138: You sound surprised π
10:17:09 <truebrain> as we always remind ourselves at this point in the release, this 1 year cycle is annoying π
10:17:17 <locosage> ever considered no releasing on 1st of april? xD
10:17:59 <rau117> truebrain: I thought it wasn't the best idea to ask for something like βI have the code, compile it for me pleaseβ
10:18:09 <truebrain> That would be even worse, yes
10:18:21 <truebrain> We are not puppets etc
10:18:25 <locosage> you can make github compile it for you with actions
10:18:28 <truebrain> "Dance for me monkey"
10:18:46 <truebrain> There, now you can compile your own code
10:19:35 <locosage> yeah, that would be even simpler I guess...
10:20:25 <truebrain> peter1138: oof, that list is bigger than I expected π
10:20:51 <peter1138> Yeah. Even if all added before 14.0, that suggests there's bound to be something else missed.
10:21:15 <truebrain> well, I kinda take it as a positive thing; means this release actually has a lot of changes π
10:21:50 <Eddi|zuHause> but openttd is dying, and the devs never make any changes
10:22:05 <truebrain> If you don't play the game, you are not allowed to developer for it, I read the other day
10:25:21 <locosage> there is some logic in that :p
10:26:06 <peter1138> Considering that was about the survey, it had the extra connotation that if you don't know how others play should shouldn't be a dev...
10:27:16 <peter1138> Eddi|zuHause: Not only do we not make changes, we refuse them.
10:27:32 <truebrain> just look at 12349! π
10:30:48 <reldred> those mean horrible openttd devs, kicked my dog and called my mother rude words
10:31:54 <truebrain> And she deserved it!
10:33:25 <truebrain> ugh; I should go to the shop to buy some lunch
10:37:52 <peter1138> I'm still on coffee time. I went shopping last night but forgot to pick up anything for breakfast this morning.
10:43:52 <reldred> it's well past dinner time here but I just ordered from a new vietnamese place near me
10:44:30 <Eddi|zuHause> peter1138: yeah, that's what i meant to write
10:49:00 <peter1138> Oh look at Windows being different there...
10:49:54 <andythenorth> Eddi|zuHause: pitchforks
10:50:37 <merni> I just ate mcdonalds for the first time in many years
10:51:01 <merni> They sure pack a lot of calories in a small space
10:51:05 <Eddi|zuHause> i haven't dared entering a mcdonalds since they switched to electronic ordering
10:51:25 <merni> do you want my location or something
10:51:25 <truebrain> you are at mcdonalds, I hope π
10:51:31 <truebrain> you didn't ate the building π
10:51:33 <merni> Well no, I ordered delivery
10:52:22 <truebrain> (or worse, the person .. brrrr)
10:53:01 <truebrain> right .... shopping ...
10:58:19 <locosage> indian mcdonalds is quite different from the western one
10:58:25 <peter1138> merni: My condolences.
10:58:44 <locosage> doesn't even fit the usual junk but edible motto
10:58:50 <merni> locosage: Indeed, they have many vegetarian options (one of which I had) and in general a lot of Indianised stuff
10:58:55 <merni> locosage: It's still that though
10:59:39 <merni> I'm sure some americans would be shocked at the idea of a burger shop with no beef :P
10:59:44 <locosage> I wouldn't call that edible π
10:59:50 <locosage> still way too much spice in some stuff xD
10:59:53 <reldred> Maccas here is great. I love it.
11:00:10 <merni> locosage: Eh, no. Some of them are explicitly spicy, the others don't have any spicy stuff in
11:00:18 <reldred> Is the best way I could describe it.
11:00:20 <merni> Most or all the things are junk though
11:07:00 <Eddi|zuHause> there's plenty of ways you could make a burger with like, pork, or chicken, or fish, or...
11:07:24 <merni> So that's what they do :)
11:07:54 <merni> And potatoes too for that matter... it probably tastes very unlike an actual meat burger but for someone who has never had one of those it's fine
11:08:13 <Eddi|zuHause> the original "hamburger" probably was pork, before they americanized it
11:08:20 <merni> no need for all that lab-grown meat stuff when you're dealing with people who have been vegetarian from birth :)
11:09:15 <Eddi|zuHause> i feel like germany is much more pork based than the rest of the western world
11:41:08 <peter1138> Bah, who came up with this spec π
11:42:12 <peter1138> House var 66 uses 16 bits to return the local house id, but puts the "is it the same newgrf" data into bits 8-9, leaving bits 10-15 empty.
11:42:13 *** Smedles has joined #openttd
11:42:24 <peter1138> That means local house id is limited to 8 bits.
11:43:03 <andythenorth> in grf v9 all 'vars' will actually be packed into other vars
11:43:04 *** Smedles has joined #openttd
11:44:07 <Eddi|zuHause> 256 houses ought to be enough for anyone
11:44:32 <peter1138> If those 2 bits were placed at the top it would... just work π
11:44:45 <locosage> reminds me of x86 spec where values are sometimes split into 3 parts in the same register
11:44:57 <locosage> probably got even worse since 64bit
11:44:57 <Eddi|zuHause> welcome to grf specs from 20 years ago :p
11:46:38 <_jgr_> I'd be surprised if house variable 66 sees much actual use
11:47:06 <peter1138> My initial fix is to just `Clamp<uint8_t>()`
11:47:27 <Eddi|zuHause> but you can't just change/ignore parts of the spec that you *think* nobody uses
11:48:30 <_jgr_> You can add another variable/etc that has a more sensible format, leaving the old one for old GRFs
11:49:19 <Eddi|zuHause> there's loads of "short date" and "long date" vars like that
11:50:17 <locosage> one var has more range, another more precision xD
11:50:43 <locosage> and then there is cb36 with even more range
11:50:48 <Eddi|zuHause> that's because internal speed units are a giant wtf by themselves
11:51:16 <Eddi|zuHause> every vehicle type counts speed differently
11:51:55 <locosage> iirc it's quite unified nowadays
11:52:47 *** Smedles has joined #openttd
11:53:03 <Eddi|zuHause> yes, but most of the spec is from 20 years ago, based on what internally happened in the game 30 years ago
11:54:12 <peter1138> If we keep adding variables, at some point we'll need to make that 16 bit too π
11:55:34 <locosage> wasn't there some feature that ran out of 8bit vars already? xD
11:55:57 <_jgr_> Likely you'll run out of "60-7F" parameterised variables somewhere first
11:55:59 <peter1138> Loads of them are never used, just there becuase of TTDPatch.
11:56:15 <peter1138> All those low 8 bits, high 8 bits variables side by side.
11:56:52 <_jgr_> Something that could be binned in GRFv9?
11:56:56 <andythenorth> in theory we know what is actually used, if we limit to bananas grfs only?
11:59:19 <locosage> with the discord font I keep reading 4096 as 40% π
11:59:34 <peter1138> Hmm, maybe we could have a label on github for "changes savegame layout, don't merge before release"
11:59:51 <peter1138> (That one was approved but depended on another PR)
11:59:52 <Eddi|zuHause> we can just purge the 80+ var range out of the unused parts, and repurpose them
12:00:50 <Eddi|zuHause> i mean, there's nothing in the grf specs stopping that, it's just a convention
12:03:17 <peter1138> Creates a maintenance burden if you now have them there for old grf versions and not there for new grf versions.
12:04:03 <peter1138> Make variable 32 bit, and then treat the value as a kind of label.
12:23:31 <peter1138> Hmm, does anyone make L-shaped houses?
12:24:19 <peter1138> The spec has 3 flags for size, 1x2, 2x1 and 2x2. They must be combined.
12:25:09 <peter1138> This seems to mean you could use different combinations to do weird things.
12:27:49 <peter1138> π¬ π¬ π¬ π¬ π¬ π¬ π¬ π¬
12:28:08 <peter1138> But maybe there's some other limits in there that prevents this.
12:32:22 <locosage> probably not that weird :P
12:33:06 <_zephyris> Certainly doesn't sound like it would work!
12:33:38 <reldred> Iβve mucked it up by accident and it just does screwy things
12:34:55 <locosage> at leas some parts of the code seem to assume only one of those flags is used
12:35:00 <locosage> dunno if that's checked anywhere
12:38:15 <locosage> iirc 2x2 flag means it has all 4 tiles, not just right bottom one
12:38:25 <locosage> so only L shape is kind of logical option here
12:40:43 <peter1138> That is merely aligning it to a grid, not actually building it.
12:44:46 <peter1138> Nope, that's checking slopes.
12:45:46 <peter1138> It's L2438-L2441, which is where I was looking when I asked the question π
12:47:02 <locosage> well, ok, it's checking, but you're gonna get a broken house if slope check passes when it shouldn't
12:47:22 <peter1138> I never asked if it worked perfectly π
12:47:28 <peter1138> I haven't looked at removal either.
12:51:55 <peter1138> Oops, I removed doxygen, and that means cmake things it needs to rebuild the whole thing π
12:57:01 <truebrain> sccache should help for those cases π
12:57:08 <truebrain> still haven't dared to try it π
13:12:06 *** berndj-blackout has joined #openttd
13:13:15 *** gelignite has joined #openttd
13:13:45 *** berndj has quit IRC (Read error: Connection reset by peer)
13:34:18 <talltyler> First time Iβve seen pointer arithmetic in the wild, took me some time to figure out what the hell was going on π
13:36:17 <peter1138> Have you never looked at our code? π
13:40:11 *** virtualrandomnumber has joined #openttd
13:40:52 *** virtualrandomnumber has quit IRC ()
13:47:04 <peter1138> Hmm, even 1x1 is a flag.
13:50:55 <Eddi|zuHause> in "our" code the part that first confused me the most was the use of the comma operator for things like the station rating
13:51:32 <Eddi|zuHause> as in "how the fuck does that actually work, and why would a person invent this?"
13:55:23 <frosch123> write a blog "comma operator considered harmful"
13:56:14 <Eddi|zuHause> i wouldn't go that far :p
13:57:11 <Eddi|zuHause> also, i think there are probably more suitible misuses of programming techniques buried in the code that would better warrant that kind of rant :p
15:03:19 <truebrain> ugh ... ubuntu-latest can't get ICU compiled with vcpkg .. now to figure out why not π¦
15:09:42 <truebrain> `configure: WARNING: unrecognized options: --disable-silent-rules`
15:13:13 <truebrain> ah, `autoconf-archive` needed to be installed ... that took way too long for my taste to figure out π
15:35:17 *** Wormnest_ has joined #openttd
15:40:23 <truebrain> lol, never realised how much faster even 12.0 was to compile π
15:41:18 <truebrain> (about twice as quick, in case you were wondering)
15:42:59 *** gelignite has quit IRC (Quit: Stay safe!)
15:51:19 <truebrain> I think it was already slower before our switch to C++20 π
15:51:22 <truebrain> there was a reason we did PCH π
15:53:42 <peter1138> Maybe we need to move back to C
15:55:56 <_jgr_> Even with PCH, all these headers just add up to an huge amount of code
15:56:18 <truebrain> better do our include-tree, you say? π
15:56:38 <truebrain> years ago we pruned all includes that were unneeded
15:56:43 <truebrain> maybe another round would help π
15:57:27 <_jgr_> It's kind of difficult, stuff like fmt is absolutely enormous and makes a lot of includes on its own
15:58:09 <truebrain> std::fmt when? π
15:58:35 <_jgr_> Moving headers into std doesn't actually make compiles any faster π
16:01:14 <_jgr_> I can't remember where, but I was reading an article about how even innocuous includes like <string> have a non-trivial hit on compile times
16:02:08 <truebrain> So C it is! (Also the moment I stop developing for OpenTTD π )
16:02:36 <_jgr_> Patreon to buy the devs faster machines to compile on, more like :
16:02:41 <andythenorth> just compile on M series π
16:02:52 <andythenorth> oh wait, they're now all zero-dayed and have to be made much slower
16:03:08 <andythenorth> "can't have nice things"
16:03:38 <_jgr_> You can turn off the mitigations if you're not running untrusted workloads and like excitement
16:03:59 <silent_tempest> Excitement? Lol
16:07:13 <truebrain> _jgr_: I have a 7950X, and it still takes for ever; I like the idea, just not sure there actually is a CPU that would help π
16:07:46 <silent_tempest> I've not profiled the build but what is the bottleneck? At my second job some one used a ramdisk to reduce the build from 40 minutes down to like 10.
16:07:59 <andythenorth> our build is only about 1m or something
16:08:07 <silent_tempest> silent_tempest: Same CPU.
16:08:38 <merni> andythenorth: That's really fast wow
16:09:20 <silent_tempest> I don't think my laptop can do it that fast but i haven't actually timed a clean build.
16:14:35 <andythenorth> I would time it, but the macOS build is broken locally
16:17:04 <andythenorth> looks like vckpg no longer works
16:17:28 *** wensimehrp has quit IRC (Quit: User went offline on Discord a while ago)
16:17:50 <_glx_> ``` [833/834 -- 94.938]Linking CXX executable openttd.exe
16:17:50 <_glx_> [834/834 -- 95.383]Linking CXX executable openttd_test.exe
16:17:50 <_glx_> ``` 7600X clean debug build on HDD
16:17:52 <merni> if you spell it like that, it wouldn't :p
16:20:17 <andythenorth> ach guess I'll be googling "why doesn't vcpkg work on MacOS 14.4"
16:20:24 <andythenorth> it works in the compile farm?
16:21:08 <andythenorth> the vcpg failure messages are asking me to brew install missing packages
16:21:17 <andythenorth> that seems....wrong?
16:21:42 <andythenorth> ` Could not find pkg-config. Please install it via your package manager:
16:21:42 <andythenorth> brew install pkg-config`
16:22:28 <_glx_> we only install pandoc manually on CI (but I think pkg-config is preinstalled on the image)
16:22:56 <_glx_> ``` [833/834 -- 142.198]Linking CXX executable openttd_test.exe
16:22:56 <_glx_> [834/834 -- 142.284]Linking CXX executable openttd.exe
16:22:56 <_glx_> ``` 7600X clean release
16:23:10 <andythenorth> I binned my brew when I upgraded OS, I'll put pkg-config back
16:24:26 <_glx_> yeah `pkg-config 0.29.2` is in the image
16:27:23 <andythenorth> linking failed, **lots **of warnings, not sure which is the actual error
16:27:55 <andythenorth> warnings are mostly just versions of this repeating `ld: warning: object file (vcpkg_installed/arm64-osx/lib/libpng16.a[4](pngget.c.o)) was built for newer 'macOS' version (14.0) than being linked (11.0)`
16:28:38 <andythenorth> I rm-ed build dir
16:28:41 <andythenorth> does that clear it?
16:28:56 <_glx_> yeah equivalent of clearing cache
16:29:20 <andythenorth> I'll try again to be sure
16:30:53 <_glx_> ``` -DCMAKE_OSX_ARCHITECTURES=arm64 \
16:30:53 <_glx_> -DVCPKG_TARGET_TRIPLET=arm64-osx \
16:30:53 <_glx_> -DCMAKE_TOOLCHAIN_FILE=${{ runner.temp }}/vcpkg/scripts/buildsystems/vcpkg.cmake \
16:30:53 <_glx_> ``` these are important (copied from workflow, adapt to your system)
16:31:35 <_glx_> I guess the architecture is autodetected, but who knows π
16:32:49 <andythenorth> oh I can suppress the warnings I think
16:32:54 <silent_tempest> I always forget how to read the time output but 6 miuntes?
16:32:55 <andythenorth> `glx yes, you can vcpkg uninstall the libs, add an env var MACOSX_DEPLOYMENT_TARGET: 10.13 and install the libs, the env var doesn't need to be permanent, just for installing openttd deps`
16:34:13 <_glx_> hmm but that is from the time vcpkg install was manual I think, now the libs are automatically installed into build dir via cmake
16:34:31 <andythenorth> my cmake command & args: `cmake .. -DCMAKE_TOOLCHAIN_FILE=../../vcpkg/scripts/buildsystems/vcpkg.cmake -DCMAKE_OSX_ARCHITECTURES=arm64 -DVCPKG_TARGET_TRIPLET=arm64-osx -DCMAKE_BUILD_TYPE=Release`
16:35:10 <_glx_> use RelWithDebInfo (better if you have to debug it π
16:35:26 <andythenorth> is ${{ runner.temp }} just to insert the path for CF?
16:35:29 <andythenorth> or is it needed for cmake?
16:36:23 <_glx_> it's related to CI, for the full path to cvpkg toolchain
16:36:52 <_glx_> it's where we cloned vcpkg repo on CI
16:39:50 <andythenorth> `xcode-select version 2406`
16:39:55 <andythenorth> not sure what else I can check
16:40:29 <andythenorth> googling `_CGLChoosePixelFormat` doesn't return much useful
16:42:25 *** gelignite has joined #openttd
16:42:47 <_glx_> but all that should be provided by system
16:43:32 <andythenorth> I wonder if Apple silently broke something
16:43:35 <andythenorth> it was working last week
16:44:17 <_glx_> maybe be paste the output of a clean cmake run somewhere
16:45:51 <_glx_> I remember you had issues with zlib from brew doing nasty stuff
16:47:21 <andythenorth> `zlib is keg-only, which means it was not symlinked into /opt/homebrew,
16:47:21 <andythenorth> because macOS already provides this software and installing another version in
16:47:21 <andythenorth> parallel can cause all kinds of trouble.`
16:47:25 <_glx_> but cmake output looks fine
16:47:36 <andythenorth> no brew zlib installed
16:48:30 <_glx_> I used to have slow build time (but I was on FX-6100)
16:48:56 <peter1138> I'm on a Core i7 8700K which was high end. (Not top end, that was the i9...)
16:49:43 <peter1138> Just about the time that all the bugs were discovered which slowed everything down by $lots
16:52:32 <andythenorth> I could delete xcode and reinstall?
16:56:00 <peter1138> Okay, 2m41 after closing OBS.
16:57:20 <_glx_> on your system```-- Found Iconv: /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX14.4.sdk/usr/lib/libiconv.tbd
16:57:20 <_glx_> -- Found OpenGL: /usr/X11R6/lib/libGL.dylib found components: OpenGL
16:57:20 <_glx_> ```on CI ``` -- Found Iconv: /Applications/Xcode_15.2.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX14.2.sdk/usr/lib/libiconv.tbd
16:57:20 <_glx_> -- Found OpenGL: /Applications/Xcode_15.2.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX14.2.sdk/System/Library/Frameworks/OpenGL.framework found components: OpenGL
16:58:00 <_glx_> (we force xcode 15.2 on Ci because it would default to 15.0.1 which breaks builds on 12-)
16:58:45 <andythenorth> wonder hy that /usr/X11R6 is used
16:58:45 <_glx_> seems your system find the wrong opengl, and that could explain the linking errors
17:01:07 <_glx_> seems to confirm it's not the right one π
17:01:35 <silent_tempest> Do you normally compile against glx on OSX?
17:01:50 <silent_tempest> I thought you needed to use the Apple stuff? AGL I thought
17:06:04 <andythenorth> I have renamed /user/x11 and rerun cmake
17:07:34 <andythenorth> `[100%] Built target openttd_test
17:07:34 <andythenorth> make -j 19 790.16s user 44.85s system 695% cpu 2:00.09 total`
17:07:38 <_glx_> cmake doc says it should default to framework version
17:07:43 <andythenorth> wonder if anything else actually needs x11
17:08:05 <_glx_> unless there's an explicit workaround used to force x11 one
17:11:02 <_glx_> as always andy's mac does weird things π
17:11:17 <andythenorth> clean OS, clean brew, clean vcpkg, clean openttd
17:11:50 <andythenorth> I really try to avoid brew though, it's most likely something there
17:12:00 <andythenorth> or a legacy environment var?
17:12:54 <andythenorth> looking what's in path
17:14:48 <andythenorth> `/opt/X11/bin` is in path, but not `/usr/X11`
17:15:14 <_glx_> looking at documentation for `FindOpenGL` it says `On OSX FindOpenGL defaults to using the framework version of OpenGL. People will have to change the cache values of OPENGL_glu_LIBRARY and OPENGL_gl_LIBRARY to use OpenGL with X11 on OSX.` up to cmake 3.28, then in 3.29 it's ```On macOS this module defaults to using the macOS-native framework version of OpenGL. To use the X11 version of OpenGL on
17:15:14 <_glx_> macOS, one can disable searching of frameworks. For example:
17:15:14 <_glx_> if(APPLE AND X11_FOUND)
17:15:14 <_glx_> set(CMAKE_FIND_FRAMEWORK NEVER)
17:15:16 <_glx_> unset(CMAKE_FIND_FRAMEWORK)
17:15:18 <andythenorth> hmm X11 created 2016, I'm going to rm it
17:15:20 <_glx_> An end user building this project may need to point CMake at their X11 installation, e.g., with -DOpenGL_ROOT=/opt/X11.``` but that doesn't explain why it found anything in `/usr`
17:15:41 <_glx_> it really should detect the framework one
17:23:26 <andythenorth> I found an X11 path in `open /etc/paths.d`
17:34:17 <_jgr_> Speaking of dependencies, it seems that some funny business has come to light with recent versions of xz
17:35:23 <_jgr_> Doesn't look like it would affect any OpenTTD build, but interesting nonetheless
17:35:51 <andythenorth> does it steal your FTX wallet?
17:38:15 <andythenorth> did we break GS again? π
17:39:02 <_jgr_> Seems to be targeted at SSH servers
17:39:54 <andythenorth> /me reverts the FIRS commit for GSTimeMode
17:40:45 <michi_cc> truebrain: C++ modules π
17:41:05 <truebrain> would that actually help? π
17:41:28 <michi_cc> It's supposed to help all those header parse time.
17:42:07 <_jgr_> Or item 1 on hacker news π
17:46:34 <truebrain> that is a rather sophisticated attack, damn ...
17:53:02 <truebrain> michi_cc: too bad it is still marked as "partial" on GCC / Clang .. not sure what part is "ial" π
17:58:37 <frosch123> ``import std`` is rumoured to take half a second to compile on experimental gcc
17:59:15 <truebrain> I have nothing to base that one, meaning I have no clue if that is a lot or not π
17:59:43 <frosch123> well, neither have i, it's just a single sentence quote from a cppcon talk
18:01:17 <truebrain> ghehe, the 12.0 binary as stored on our CDN is slightly slower as when recompiled with latest compilers + dependencies π
18:01:25 <truebrain> like 5% slower, or something
18:01:37 <peter1138> Did we leave asserts enabled?
18:02:32 <truebrain> they are disabled with 12.0 π
18:02:45 <truebrain> we did forget with 13.0 π
18:04:25 <truebrain> okay .. I can now gather performance information via GitHub Runners .. now where to collect them, and how π
18:12:24 <truebrain> still funny how much faster / less memory 14.0 uses against 12.0, for all of the savegames I have in the performance suite π
18:28:27 <_jgr_> At some point I plan to look at it, but I haven't got round to doing anything with it yet
18:29:28 <truebrain> so I am trying to run savegames for roughtly 30s, to make sure the CPU jitter is not all that noticeable
18:29:38 <truebrain> for the titlegame of 1.0, I am already at 400,000 ticks
18:29:41 <truebrain> and it is still done within a second
18:29:47 <truebrain> some games are weird π
18:31:46 <peter1138> Hmm, std::unique_ptr with an incomplete type does not always work :S
18:34:01 <frosch123> yes, it's annoying, you have to delete/define all the special members (copy-ctor, assignment, ...) of the using classes
18:34:44 <frosch123> funnily using std::shared_ptr instead of std::unique_ptr often works. i think because its considered too complicated to inline
18:36:02 <frosch123> the underlying issue is said to be, that assiging/construcing the unique_ptr may have to call the destructor in case exceptions are thrown
18:38:45 <truebrain> hmm, I need a tool to download the NewGRFs a savegame has π
18:39:10 <frosch123> ``openttd -q <savegame>`` prints them, irrc
18:39:28 <frosch123> but yes, people asked for a console command to download dependencies
18:39:47 <truebrain> I am more thinking CLI command π
18:40:06 <truebrain> oof, the `-q` result is annoying to parse
18:40:12 <truebrain> I am so tempted to JSON-ify some of these commands ..
18:40:54 <truebrain> owh, and `-q` is buggy
18:41:00 <truebrain> they don't byte-swap the NewGRF IDs
18:41:19 <frosch123> lol, i guess noone uses it then
18:41:27 <truebrain> it is not pratical in usage, no π
18:41:42 <frosch123> not sure whether zuu or me added it
18:42:06 <truebrain> `0200434A` made me go like .. that sounds wrong π
18:42:13 <truebrain> `4A430002` is more understandable π
18:43:25 <truebrain> I do wonder why `-q` does a NewGRF scan; that too is a bit odd
18:44:39 <frosch123> truebrain: it also prints, whether they were found
18:45:11 <truebrain> I only see it print grfid, md5sum and filename?
18:45:26 <frosch123> hmm, no... why can't it just always print opriginal_md5sum
18:46:44 <frosch123> truebrain: it doesn't scan for me?
18:47:04 <frosch123> it even complains that it found none :p
18:47:18 <truebrain> I first get a long list of grf:0 debug messages that it couldn't find the NewGRF
18:47:22 <truebrain> before it tells me what NewGRFs are in the file
18:47:28 <truebrain> so something is aware of the NewGRFs that I have on disk π
18:47:43 <frosch123> the paths are from the savegame
18:47:59 <frosch123> and it complains about every single used newgrf not being found, because it did not scan π
18:48:31 <frosch123> it runs in 0.037s for me
18:48:40 <frosch123> if it would scan, it would take longer :p
18:48:59 <truebrain> well, even worse π
18:49:12 <truebrain> This whole "-q" command just doesn't make sense to me, sorry π
18:49:31 <frosch123> it's from the time, when only openttd could read savegames
18:49:58 <truebrain> well, older savegames still are π
18:50:54 <truebrain> at least I fixed the very obvious problem with -q
18:52:00 <truebrain> I am also still puzzled why the title game of 1.4 is so weird in CPU usage .. it is all over the place. Seems related to linkgraph .. but why is it acting THAT crazy ..
18:53:43 <truebrain> maybe I should compile without threads .. that might help? Let's find out
18:56:31 <truebrain> except that I cannot find any evidence that that option actually does anything π
18:59:00 <_glx_> you can check `linkgraph.distribution_XXX`, maybe it's not using manual
19:01:46 <truebrain> now I wonder what Emscripten does π
19:02:36 <truebrain> still runs without threading π
19:09:03 <truebrain> okay, so that is also no longer a viable option .. hmm
19:11:10 <frosch123> are you using the null video driver?
19:12:04 <truebrain> haha, I found good use of `-q`: `./openttd -q <savegame> 2>&1 1>/dev/null | grep "not found; checksum" | sed -r 's/.*NewGRF ([0-9A-F]+).*checksum ([0-9A-Z]+)/\1;\2/'` π Pretty sure it was not intended to be used like that, but those debug messages are useful after all π
19:12:11 <frosch123> ok, nevermind then π in case of sdl2 there is a no_threads option to disable the render-thread, which makes it more responsive in valgrind
19:12:30 <truebrain> yeah, but those threads I don't care about π
19:12:36 <truebrain> the linkgraph-threads are a bit of an issue
19:12:43 <truebrain> they create a lot of noise
19:14:18 <truebrain> (at least, that seems to be the case with 1.4)
19:14:32 <truebrain> I might just patch out linkgraph, tbh
19:14:42 <truebrain> we know it is horrible performance wise π
19:15:50 <frosch123> ``sed '/NewGRFs:/ ! D;:loop;N;b loop'`` also works to skip the header
19:16:06 <truebrain> but the information after the NewGRF is not trustworthy
19:16:10 <truebrain> so if you look close, I parse the stderr
19:16:12 <truebrain> not the stdout π
19:17:01 <truebrain> The NewGRF IDs are wrong!
19:17:13 <truebrain> I am not going to fix that in my scripting π
19:17:28 <frosch123> but you already PRed the fix
19:17:43 <truebrain> yes; but that is not going to fix any version from before tomorrow-ish π
19:17:54 <truebrain> and I kinda want to run performance tests on a bunch older π
19:18:14 <truebrain> I could in theory apply the patch, by checking dates etc; maybe some day π
19:20:01 <frosch123> ``sed '/NewGRFs:/ ! D;:loop;N;s/.*\n//;s/^\(..\)\(..\)\(..\)\(..\)/\4\3\2\1/;p;b loop'``
19:20:05 <frosch123> pff, the things you make me do
19:20:18 <truebrain> yes, but that requires date-range checks
19:20:47 <truebrain> which works for vanilla, ish, but what if someone says: he, let's run JGRPP through this system too! π
19:21:16 <truebrain> but more likely when the PR is merged I make the next nightly "special", and always use that to detect NewGRFs π
19:21:32 <truebrain> which is also a bit silly, but that is what you make me do! π
19:22:50 <truebrain> hmm, well, guess I could use 12.0 and your trick
19:23:18 <truebrain> well, it doesn't work π¦
19:23:32 <truebrain> and I do not understand that sed syntax at all π
19:23:36 <truebrain> owh, it does work, I am a peanut
19:24:02 <frosch123> i am sure i used gnu extensions
19:24:09 <frosch123> so, don't run it on your ibm mainframe
19:24:11 <truebrain> a `!` in a sed scares me
19:25:04 <frosch123> really, the ``!`` :p i think that just means you did not get to the ``N`` and the ``b``
19:25:36 <truebrain> if you don't escape a `!` properly in bash, weird shit happens π
19:26:02 <frosch123> in bash as well? i thought that was csh junk
19:26:57 <truebrain> my delete button sometimes presses twice (a lovely shitty logitech keyboard I have)
19:27:02 <truebrain> that gives sometimes interesting results when working in scripts
19:31:30 <andythenorth> articulated ships then? π
19:32:06 <truebrain> funny, the infra only accepts NewGRF IDs in lowercase π
19:35:21 <truebrain> lolz, so a lot of title games I can run for 20,000,000 ticks in 10s, but others not even 40,000 π
19:42:12 <truebrain> okay, auto-NewGRF-download should work .. and disable-threads too .. let's try again! (takes ~30 minutes .. makes testing annoying π )
19:42:14 *** wensimehrp has joined #openttd
19:42:45 <andythenorth> no, they'll never work
19:42:59 <andythenorth> "articulated" ships as in JGRPP
19:43:03 <andythenorth> and the extended grf spec
19:44:36 *** Ttech has quit IRC (Quit: Este Γ© o fim.)
19:46:03 <andythenorth> don't canals only have 90 degree turns?
19:47:47 <andythenorth> hmm no I am wrong
19:47:59 <andythenorth> ships do travel diagonally for quite a few frames
19:54:06 <andythenorth> articulated ships, but they can only be 32px long?
19:54:40 <peter1138> No idea, but to say "they'll never work" is not true.
19:55:18 <andythenorth> wondered how they'd do the rotate-on-the-spot turning thing
19:55:56 <andythenorth> oh....push-pull ships? π
19:56:23 <andythenorth> and a grf var similar to landing states for planes
19:56:28 <andythenorth> so we can have tug sprites
20:03:09 <Eddi|zuHause> ship movement is basically the same as train movement
20:03:23 <frosch123> i recall that you mostly wanted closed ships, so you did not have to draw loading stages
20:03:33 <Eddi|zuHause> imagine a water tile having all tracks built on them
20:03:45 <andythenorth> $someone has made 128px long ships though π
20:04:03 <andythenorth> these will not articulate well when rotated about a centre-point π
20:04:09 <andythenorth> who would do that?
20:05:01 <andythenorth> frosch123: 'mistakes were made'
20:16:33 *** Flygon has quit IRC (Quit: A toaster's basically a soldering iron designed to toast bread)
20:24:41 <andythenorth> maybe we should add that to the PR template
20:24:56 <andythenorth> "at any point, could we say 'mistakes were made'?"
20:30:57 <truebrain> without threading, 1.4 title game is much more stable in CPU usage π
21:16:11 *** HeyCitizen has joined #openttd
21:18:08 *** HeyCitizen has joined #openttd
21:22:22 *** HeyCitizen has joined #openttd
21:23:46 <truebrain> and ... vcpkg broke on linux
21:23:52 <truebrain> I was wondering why I could build 15 minutes ago, and not now
21:23:55 <truebrain> but vcpkg pushed an update
21:28:41 <truebrain> ofc! But this time "which commit" was easy
21:28:44 <truebrain> as it was the only one in 14 hours
21:28:54 <truebrain> but .. who merges anything on a repo like this on a Friday before a long weekend?
21:29:05 <peter1138> Downgrading zx to one from 2 years ago?
21:29:26 <truebrain> sometimes I have doubts about the sanity of vcpkg maintainers π But not my party π
21:29:51 <Eddi|zuHause> well, over here, the friday already belongs to the long weekend
21:49:36 <truebrain> `On what kind of system are you seeing this? I'll look at trying ubuntu latest...` .. these kind of replies don't make me hopeful π
21:57:49 <truebrain> hmmm, I wonder if we could checkout the last tagged version of vcpkg
21:57:55 <truebrain> maybe that gives less often these kind of issue
21:58:51 <truebrain> on the other hand, most likely only delays seeing issues π
22:08:05 <_glx_> whatever we do we will trigger issues at some point π
22:08:20 *** Tirili has quit IRC (Quit: Leaving)
22:10:36 <truebrain> and they reverted the change π
22:11:27 <truebrain> also, takes 2 lines of code to use their latest release; still might be wise, to not be the first to notice these issues π
22:16:23 <_glx_> using latest release would be similar to when we were using vcpkg from the image
22:17:11 <_glx_> some stability doesn't hurt π
22:18:08 <_glx_> and manifest mode is nice because it always use up to date versions on install
22:20:21 <_glx_> that's vcpkg in manifest mode π
22:21:07 <_glx_> libraries are installed when you run cmake
22:21:34 <_glx_> and rebuilt everytime the compiler is updated
22:21:46 <xarick> how big is the download, 1 Mbps/sec in this day and age is too slow
22:21:48 <truebrain> oof, sometimes it takes 9 tries before 5 conjunctive runs of OpenTTD are near the same cpu time.
22:21:55 <truebrain> and some savegames have that more than others
22:23:10 <Rubidium> xarick: I'd love to have your connection. Gaining 1 Mbps per second would be great ;)
22:23:29 *** nielsm has quit IRC (Ping timeout: 480 seconds)
22:23:37 <truebrain> well, especially the games where 200 ticks take 10s to run .. those are aweful ...
22:25:21 <truebrain> I am still not sure what is better .. to always run all games N ticks, or to have them run about 10s (so every savegame has a fixed amount of ticks to run, but per savegame they are different) .. hmm
22:26:00 <_glx_> 104MB uncompressed xarick
22:26:06 <xarick> Rubidium: I don't get it
22:26:34 <xarick> seems my isp is throttling me
22:26:47 <xarick> I really should be done with this ISP...
22:27:13 <xarick> can't stream at 6 Mbps for 3 hours without getting throttled
22:46:12 *** gelignite has quit IRC (Quit: Stay safe!)
22:47:13 *** Wolf01 has quit IRC (Quit: Once again the world is quick to bury me.)
23:26:57 *** tokai|noir has joined #openttd
23:26:57 *** ChanServ sets mode: +v tokai|noir
23:30:18 <truebrain> The xz compromise was months in the making .. supply chain attacks are getting serious ...
23:33:51 *** tokai has quit IRC (Ping timeout: 480 seconds)
23:37:38 <truebrain> And if this happened to one project ......
23:38:13 <truebrain> It is funny it got discovered because of an increased CPU execution time .. like .. and if that wasn't the case?
23:39:12 <truebrain> Also, imagine spending months crafting the perfect attack, only to be discovered because someone was: why is my ssh slightly slower? π
continue to next day β΅
