IRC logs for #openttd on OFTC at 2024-01-18
โด go to previous day
00:00:21 <truebrain> and doesn't leave room for spacing ๐
00:02:24 <truebrain> it is LTR, it is set to en-gb, so that all checks out
00:03:23 <truebrain> I noticed; disabling AA doesn't make characters shorter ๐
00:05:22 <_glx_> yeah disabling AA just makes them less bold
00:06:32 <truebrain> when rendering with the harfbuzz utils it does look correct
00:06:36 <truebrain> so it really is something we do ๐ฆ
00:07:10 <_glx_> hey at least it means it can do it correctly
00:15:44 <truebrain> I find all kind of small bugs and issues, but none that explain this ๐
00:20:59 <truebrain> owh well, tomorrow more; first some zzz I guess ๐
00:24:23 <truebrain> I guess I should also update my harfbuzz, see if that changes anything
00:28:38 <truebrain> but as the internal hb tooling renders the font fine on my machine .. not actually sure if that matters all that much. Owh well .. I was going for some sleep I said ๐
00:32:40 <truebrain> well, there are improvements ๐
00:32:55 <truebrain> this was with Tahoma Bold, 13px?
00:33:15 <peter1138[d]> When I use 13 it is no longer bold.
00:33:27 <truebrain> but is `Table` still correct?
00:33:49 <truebrain> meh, `AI` is still not spaced correct; something else is going on here ๐
00:34:34 <truebrain> that is actually a lot better .. at least nothing creeped together anymore
00:34:43 <truebrain> the float changes might now actually hurt ๐
00:35:10 <truebrain> changing `x_advance` to `int`, revert my changes
00:35:20 <truebrain> (as the rest is all a side-effect of that being a float ๐ )
00:36:03 <truebrain> but so I really should upgrade harfbuzz, as clearly some of the issues are due to my old version
00:37:29 <truebrain> and 13px? (just because I looked at 13px all night ๐ )
00:38:17 <truebrain> just lot less wrong, but still .. wrong
00:38:30 <truebrain> owh, right, bedtime
00:39:32 <peter1138[d]> Not until this is fixed!
03:00:47 *** Wormnest has quit IRC (Quit: Leaving)
03:43:00 *** debdog has quit IRC (Ping timeout: 480 seconds)
06:21:55 *** keikoz has quit IRC (Ping timeout: 480 seconds)
07:32:12 *** ChanServ sets mode: +v tokai
07:38:45 *** tokai|noir has quit IRC (Ping timeout: 480 seconds)
08:01:24 <LordAro> peter1138[d]: ...can you do that?
08:05:21 <truebrain> if you are the license holder ..... ๐
08:06:10 <Eddi|zuHause> typical problem is figuring out whether you're actually the (only) license holder
08:06:28 <truebrain> and with studios being sold etc ....
08:06:55 <Eddi|zuHause> which is probably why we never got anywhere with the TTD license
08:07:20 <truebrain> or why I got nowhere with Dune2 ..
08:16:22 <truebrain> okay, the issue really seems to be in FreeType, more than anything else
08:25:49 <truebrain> okay, found the bug ๐
08:27:32 <truebrain> 1 line of code ... lolz
08:29:45 <truebrain> owh, but I need to know whether the font is being rendered AA or not
08:33:25 <truebrain> long story short: harfbuzz was rendering another font face than we were
08:36:57 <peter1138[d]> I... don't see how. But okay, 1 loc.
08:38:05 <truebrain> well, harfbuzz doet iets own FT_Load_Glyph
08:38:09 <truebrain> with its own loadflags
08:38:12 <truebrain> and we are "special"
08:38:17 <truebrain> and set our own loadflags too
08:38:20 <truebrain> and they do not match
08:40:08 <_zephyris> Oof, โ6ยฐC. Weather in OTTD when?
08:40:49 <peter1138[d]> And my 'smart' thermostat decided the house should be 16.5ยฐC inside.
08:41:56 <truebrain> give it a try peter1138[d] ๐
08:42:35 <LordAro> somewhere between -5 & -1, according to 3 different sources
08:44:11 <truebrain> ideally I Would make a function that returns the load-flags, but .. means I need to poke a hole in the FontCache interface, just for FreeType
08:44:15 <truebrain> also not ideal ๐
08:45:45 <peter1138[d]> GetOSHandle seems to be fontcache/layouter specific already, so you could return it along with the face there.
08:46:26 <peter1138[d]> So it is the right face, but antialias state isn't part of FT_Face.
08:46:45 <truebrain> the AA is less of an issue than the non-AA ๐
08:47:15 <truebrain> GetOSHandle is also a bit tricky to use, as `aa` is fed in a really weird place in the current interface
08:48:35 <peter1138[d]> Do you need to call `hb_ft_font_set_funcs()` though, that seems to happen inside `hb_ft_font_create_referenced()` already?
08:48:48 <truebrain> no, `_hb_ft_font_set_funs` is ๐
08:49:15 <truebrain> and no, they don't do the same ๐
08:49:20 <truebrain> that was a mindfuck on its own
08:49:21 <peter1138[d]> Seems weird they would... only half-set it up ๐ฎ
08:49:34 <truebrain> you have 2 choices: use harfbuzz interpertation of things
08:50:10 <truebrain> but I am not sure that commit matters
08:50:15 <truebrain> I can leave it out and see if it is an issue
08:51:04 <peter1138[d]> The function seems to make a copy of the FT_Face.
08:51:19 <truebrain> I was initially hoping that would also fix loadflags
08:51:51 <truebrain> I am just going to leave it out
08:52:13 <peter1138[d]> ``` * An #hb_font_t object created with hb_ft_font_create()
08:52:13 <peter1138[d]> * is preconfigured for FreeType font functions and does not
08:52:13 <peter1138[d]> * require this function to be used.```
08:52:52 <truebrain> their docs aren't the best ๐
08:53:29 <truebrain> they try, but .... lot of places saying a lot of things, in not always clear wording
08:54:14 <peter1138[d]> LOL, github, let me comment on a line that is 2 lines away from a change, please!
08:55:55 <truebrain> do I dare to send a `std::pair` via a void pointer ๐
08:56:44 <truebrain> shouldn't we use ceil in more places?
08:56:58 <truebrain> I would expect similar issues appear on other OSes too, honestly
08:57:33 <peter1138[d]> I did notice once the other day that a dropdown string was missing, but I couldn't replicate it.
08:57:36 <truebrain> Windows usees `int` too
08:57:59 <peter1138[d]> It probably depends on the font. Maybe I was testing with Tahoma ๐
08:58:31 <peter1138[d]> I don't actually know why it behaves the way it does either.
08:58:53 <truebrain> hmm .. looking at the other layouters
08:59:00 <peter1138[d]> The whole thing is missing, not just wrapped too early. Weird. Probably another bug ๐
08:59:00 <truebrain> I think I might want to revert the int->float
08:59:09 <truebrain> that means they might all be wrong, but at least it would be consistently wrong
09:00:50 <peter1138[d]> Whittling it down ๐
09:01:01 <truebrain> I rather am consistently wrong between OSes
09:01:41 <peter1138[d]> I think the comment for FONT_SCALE should be updated to reflect that this is the value that is needed as it magically matches what FreeType uses.
09:02:23 <peter1138[d]> Otherwise we will try to change it in a few years and wonder why it doesn't do the expected thing. Again. ๐
09:06:17 <peter1138[d]> Given GetOSHandle is font system specific we might want to guard against a layouter calling a wrong fontcache. But that's totally separate.
09:07:02 <truebrain> it doesn't really become pretty .. so not sure this is the right way to go ๐
09:09:28 <truebrain> fixed your comment, and going to leave it at that. If you want to give it a crack to send loadflags more cleanly to the layouter, please give it a go
09:09:37 <peter1138[d]> font->fc->GetAAState() would've been obvious, but doesn't exist ๐
09:09:40 <truebrain> but I couldn't find a nice and clean way that doesn't involve reworking most of it ๐
09:09:52 <truebrain> AA is added very oddly
09:09:55 <peter1138[d]> Yes, I think it's fine as it is given the current "API".
09:13:12 <peter1138[d]> Improvement with Arial Bold too.
09:13:17 *** pickpacket has joined #openttd
09:13:19 <truebrain> all fonts should be better ๐
09:13:33 <truebrain> the only reason OpenTTD-Sans works, I think, is because it doesn't have "monochrome" support ๐
09:19:50 <peter1138[d]> What I don't understand is why it was wrong regardless of our AA state.
09:21:00 <truebrain> because DEFAULT is also not NORMAL ๐
09:21:10 <truebrain> and HarfBuzz disables hinting
09:21:16 <peter1138[d]> Okay, "FT_LOAD_DEFAULT | FT_LOAD_NO_HINTING" is the default, so...
09:21:35 <truebrain> I believe maybe we should disable hinting too, but I saw no issues with it
09:22:53 <peter1138[d]> FT_LOAD_DEFAULT | seems to be missing the point, tbh ๐
09:33:02 <peter1138[d]> With "Tahoma, Bold" set, enter into the console the letters "refit"
09:33:43 <truebrain> screenshot or it didnt happen ๐
09:34:20 <peter1138[d]> Hinting or ligatures?
09:34:40 <truebrain> at least not something harfbuzz can be blamed, so walking awayyyyyyyy ๐
09:34:40 <peter1138[d]> It's switching "f I" to "fi" which is a ligature some fonts have.
09:35:10 <peter1138[d]> > Error: NOT_REACHED triggered at line 269 of /home/petern/src/openttd/src/gfx_layout.cpp
09:35:14 <peter1138[d]> That is kind of a problem though ๐
09:36:04 <peter1138[d]> Our cursor position stuff doesn't expect a ligature!
09:36:54 <peter1138[d]> We should probably also disable ligatures.
09:37:04 <truebrain> I cannot predict the impact of that on other languages
09:37:12 <peter1138[d]> Yeah I was just getting to that... ๐ฆ
09:37:42 <truebrain> so the crashing part sounds more of an issue, as in those languages you expect that to happen?
09:38:06 *** Flygon has quit IRC (Quit: A toaster's basically a soldering iron designed to toast bread)
09:39:14 <peter1138[d]> Yes, arabic crashes too.
09:39:26 <truebrain> you can fix this one, okay? ๐
09:39:37 <peter1138[d]> Is it a one-liner? ๐
09:39:45 <truebrain> for you to find out!
09:40:21 <pickpacket> Everything is a one-liner if you donโt use line breaks
09:44:33 <peter1138[d]> pickpacket: Genius,.
09:45:43 *** nanapipirara has joined #openttd
09:45:43 <nanapipirara> Not sure what the best way to file bug reports is (and where to find existing ones), but trucks slip under the road sprites when truckstops are placed on downward slopes like this
09:46:28 <nanapipirara> I guess the truck tile is 'lower'
09:51:39 <peter1138[d]> I don't think it's a rendering order issue.
09:57:06 <locosage> road on a foundation is a sortable sprite so it sorts above vehicle as vehicle because why wouldn't it with a vehicle bb like that
10:01:44 <peter1138[d]> It renders correctly when the building is hidden, so it's the awkward 3-way sort issue.
10:03:14 <truebrain> to the bug-tracker!
10:03:30 <peter1138[d]> (Or maybe just incorrect sorting)
10:03:37 <peter1138[d]> Yes, it's probably an existing ancient bug ๐
10:03:52 <LordAro> it's in known-bugs.txt :p
10:09:54 <locosage> peter1138[d]: I'd say it just happens to order correctly in that case as bbs here don't intersect and so can be ordered either way
10:11:47 <peter1138[d]> Break each sprite pixel down into a 3D voxel and just use a Z-buffer ๐
10:14:25 <locosage> not so much voxels, just need z layer
10:14:32 <locosage> but equally unfeasible I guess
10:33:29 <Timberwolf> Reimplement OpenTTD in the Sims 1 engine.
10:44:04 <FLHerne> I'm not sure it's possible to do right
10:44:25 <FLHerne> maybe that can be the application of highly-advanced AI technology
10:45:59 <locosage> the whole concept of using bounding boxes for sprite ordering is kind of meh
10:46:00 <FLHerne> spend ages training a model on what the "correct" order of a dozen overlapping sprites with uselessly vague bounding boxes is
10:46:36 <reldred> I kinda dug how you could define the size of a bounding box with stations at least
10:47:15 <FLHerne> yeah, but it's still a box
10:47:35 <locosage> it has great flexibility
10:47:46 <FLHerne> even worse for vehicles because it's an axis-aligned box even when the vehicle isn't
10:47:53 <locosage> but then you get road drawing over vehicle xD
10:50:51 <locosage> btw, bb is not the only thing defining sprite order, drawing order also matters
10:50:55 <_jgr_> The sprite sorting algorithm is fairly nonsensical, but all the existing assets have come to implicitly depend on its quirks
10:53:16 <locosage> it is sensible for the task it's given, it just tries to order boxes whenever it can
10:53:53 <locosage> well, except for some implementation details
10:54:42 <locosage> peter1138[d]: btw cmclient also draws road above but doesn't glitch like this
11:01:38 <peter1138[d]> Timberwolf: Running on an emulated 486 for efficiency.
11:26:27 <_zephyris> Well, I did it yesterday!
11:26:34 <_zephyris> Not in a release yet
11:27:01 <peter1138[d]> Nice. Is that "by default" or is a option we have to support and toggle...
11:27:49 <_zephyris> Currently default is old style non-tabular. Can be switched, but pitchforks.
11:27:50 <peter1138[d]> Hmm, layouting is very slow with some fonts ๐ฎ
11:28:42 <_zephyris> And yeah, I expect font layouters will have switches for kerning, ligatures, numeral style, etc.
11:29:40 <peter1138[d]> It's the same font then, not a sub-font in the same file?
11:30:10 <peter1138[d]> Not sure how pitch-forky people would be about the numbers, tbh.
11:30:40 <_zephyris> Yup, same font. OpenType(?) has various character alternate standards.
11:30:51 <_zephyris> See also lining vs old-style numerals.
11:32:25 <_zephyris> I wonder how old that "This is a TrueTrype font. This font will be used on both printer and screen." message is...
11:34:22 <_zephyris> Probably the 'correct' solution is to pass the request for tabular fonts to whatever ttf layouter/render is used
11:34:35 <_zephyris> That way any font, if it has tabular numerals, will use that alternate
11:34:53 <peter1138[d]> Yes, but the documentation on how to do that is sorely lacking.
11:35:25 <_zephyris> You surprise me ๐
11:36:22 <_zephyris> I can switch the tabular to default for the serif, and encode the proportional as the alternate
11:37:16 <peter1138[d]> It's only the medium sans font that would benefit. The large serif font does not get much use.
11:39:21 <peter1138[d]> Oh, 1 second too late :p
11:43:48 <nihues> _zephyris: about my reply on forum, not related to your ogfx2 or anything, but just to reply.... this is with 4x size (the one I use) and 3.75x, the later (or below) gives a big border/reduced icons size, making it basically too small. If I enable Bigger main toolbar it goes back normal on toolbar, but not on the window. Maybe a setting to bigger window icons too could resolve?
11:46:10 <_zephyris> The issue is that you can't provide arbitrarily scaled GUI icons, they have to be 1x, 2x or 4x. So, if you use a 3.75x GUI scale it has to use the 2x icons, and they'll sit within the large border.
11:47:30 <nihues> Ahh I see, changing to 2x works normal (but small for me), 2x+ up to 3.75x gives border, 4x no border.
11:49:09 <peter1138[d]> Such thin bevels though ๐ฎ
11:49:49 *** tycoondemon2 has joined #openttd
11:50:28 <nihues> on 4x with scale bevels looks like a 94 DOS game =p
11:50:30 <peter1138[d]> Strange how people disable that option, but I suppose that validates that adding it as an option was useful.
11:50:39 <peter1138[d]> nihues: Well... it is!
11:51:01 <peter1138[d]> See, to me that is much more legible and coherent.
11:51:14 <nihues> it's more clean/minimal without it, already accustomed
11:53:07 <peter1138[d]> Nice to see that 4x is actually usable on 4K display though.
11:53:13 <peter1138[d]> Means you can't zoom in the viewports though.
11:53:44 <_zephyris> Pixel doubling, I'm sure you had a patch for that...
11:53:50 *** tycoondemon has quit IRC (Ping timeout: 480 seconds)
11:54:05 <peter1138[d]> I remember LTT showing off some stupid size monitors a few years ago. Proably 16K or something...
11:54:27 <peter1138[d]> _zephyris: my "patch" is what we have in master ๐
11:54:50 <locosage> peter1138[d]: funnily I was probably the first to ask for it but use think bevels now
11:54:54 <locosage> I did switch monitors though....
11:55:54 <locosage> was on 27" 4k and rn use 16" 2k
11:56:00 <peter1138[d]> Only 12% (hah) of players have scale_bevels off.
11:56:11 <peter1138[d]> Although of course anyone with < 200 scaling will also have thin bevels too.
11:56:41 <locosage> considering it non-default 12 is not that few
11:57:53 <peter1138[d]> Given the usual result of these things that were clear-cut is 52/48...
11:58:30 <nihues> peter1138[d]: Only issue is font config for "industry window" or "load by cargo type", need to use some workaround to reduce line spacing/font size to be able to see it all, other then that all fine!
11:59:02 <peter1138[d]> load by cargo type... what's that?
11:59:22 <nihues> jgrr thing, on XIS/AXIS it's a lot of cargo, so a lot of lines
12:00:04 <nihues> like this... it goes to the max window size, a little higher but usable.
12:01:41 <peter1138[d]> Needs a scrollbar ๐
12:12:32 <reldred> Thick bezels give me life
12:15:39 <_zephyris> Double thickness option
12:56:43 <peter1138[d]> _jgr_: the station shadows could be blitter-specific.
13:10:11 <peter1138[d]> (Although I tested all in master with no problem)
13:18:26 <peter1138[d]> Hmm, I need a stateful SQL query... this is not going to end well.
13:21:13 <peter1138[d]> Might be "leave this bit to code" time.
13:24:53 <xarick> I triggered this type of crash again
13:25:28 <xarick> No method to create a crash.dmp available.
13:25:47 <peter1138[d]> You should scroll up and see if there any useful info in the console window.
13:25:59 <peter1138[d]> Cos just the end of it isn't.
13:33:21 <xarick> seems to be caused by NOT_REACHED
13:39:41 <xarick> it's not being helpful, doesn't break nicely into visual studio
13:39:50 <xarick> I click ok and openttd closes
13:40:23 <xarick> I wanted to see a breakpoint or something, where this is pointing at
13:40:46 <peter1138[d]> It lets you what line.
13:41:49 <xarick> yes, though I expected better integration with the debug
13:43:42 <peter1138[d]> Might be that you need to use a debug build.
13:43:46 <peter1138[d]> Not sure though.
13:44:34 <peter1138[d]> Dunno, maybe that's something else.
13:44:51 <peter1138[d]> Use VS Code and Linux. Works great here ๐
13:47:23 <xarick> I failed at costs somehow
13:51:28 <_jgr_> peter1138[d]: I can't see anything wrong with any blitter, and no-one else seems to be having a problem
14:05:13 <xarick> why is my aqueduct code so expensive ๐
14:22:23 <_glx_> xarick: That's weird because breakpad should be installed automatically when cmake runs
14:22:52 <xarick> seems to happen when NOT_REACHED is triggered
14:22:59 <xarick> but not on the other cases
14:23:02 <_glx_> Anyway when you get the crash report window you can attach debugger
14:24:03 <xarick> assert works fine, it enters debug fine
15:05:33 <Rubidium> _glx_: that automatic install is for Visual Studio (Code), right? As it didn't happen on my computer when building for Linux
15:08:15 <truebrain> it would if you run vcpkg ๐
15:08:30 <truebrain> MSVC has integrated vcpkg, so there it happens automagically ๐
15:28:57 <LordAro> gotta love a bug getting fixed after 20 yeras
15:30:01 <truebrain> LordAro: at least it was already fixed!
15:30:19 <LordAro> except i can't use 5.34+ due to other issues
15:30:42 <LordAro> a custom perl distribution is not really something i want to start doing
15:30:45 <truebrain> how hard can it be ๐
15:30:52 <truebrain> `sudo patch -p1 < ...` ๐
15:31:24 <LordAro> have you ever looked at the perl build system?
15:31:37 <LordAro> the windows people only just started automating it
15:31:45 <truebrain> I was not suggesting to build perl at all
15:32:41 <truebrain> owh, the patch is not small
15:34:26 <LordAro> ah, but the patch does involve touching some of the C internals
15:34:44 <LordAro> otherwise, yeah, i could've just copied the relevant pm files :p
15:35:10 <LordAro> actually, i think the fix for this is the reason i can't use 5.34
15:35:18 <LordAro> (unreadable files are no longer visible at all)
15:35:19 <truebrain> I am battling numpy matrix manipulation .... it is ... complicated
15:36:13 <truebrain> that is, numpy's syntax is
15:36:16 <truebrain> not the manipulation I want to do ๐
15:38:50 <truebrain> `all the input array dimensions except for the concatenation axis must match exactly, but along dimension 0, the array at index 0 has size 256 and the array at index 1 has size 1`
15:39:03 <truebrain> I was trying to extend the 256 with 1
15:39:11 <truebrain> but I guess I have my dimensions wrong or something
15:42:06 <LordAro> ooh, we could start using concepts now
15:42:14 <LordAro> concepts have better error messages, right?
15:42:29 <truebrain> OPEN THE FLOODGATES
15:42:31 <truebrain> what have I done ๐
15:43:15 <xarick> it's probably 1 line with an error, but it spews massive spam of errors
15:44:14 <talltyler> Also _zephyris those 4x catenary poles are gorgeous!
15:44:28 <truebrain> I love how #11828 is a feature ๐
15:44:34 <truebrain> but maybe `Add` is more realistic?
15:44:45 <_zephyris> I was feeling bold ๐
15:45:34 <LordAro> should probably match whatever i did for the trees
15:45:38 <_zephyris> talltyler: Well... They're geometrically correct. Which is 90% of the battle with the technical infrastructure sprites!
16:03:49 <LordAro> Full detail a bad feature?
16:04:44 <peter1138[d]> Transparency window you mean.
16:05:02 <peter1138[d]> Full detail is a TTD original, is therefore... sacred ๐
16:05:18 <LordAro> i've never thought to check whether enabling transparency/invisiblity speeds the game up like full detail does
16:05:52 *** Wormnest has joined #openttd
16:06:09 <peter1138[d]> Transparency no, invisibility "yes" but neither is going to make much difference.
16:06:24 <peter1138[d]> It's not going to affect Wentbourne ๐
16:16:29 <xarick> what's cheaper? std::pair or std::tuple, I only need 2 items
16:17:13 <_zephyris> And the survey says...
16:17:13 <_zephyris> game.settings.display_opt.FULL_DETAIL
16:22:07 <peter1138[d]> Urgh, this report building code is ugly.
16:22:24 <peter1138[d]> (I can say that because I wrote it)
16:23:26 <xarick> I'm going with std::pair
16:31:06 <LordAro> closing a TB issue without fixing it? :o
16:31:11 <LordAro> you had a good run, talltyler
16:32:34 <peter1138[d]> A dictionary of lists of dictionaries of lists seems to be the wrong data structure.
16:33:29 <peter1138[d]> C# for `std::map<key, std::vector<std::map<subkey, std::vector<value>>>>` ๐ฆ
16:35:15 <peter1138[d]> Ah, `std::map<key, std::map<subkey, std::vector<value>>>` would be slightly more sensible but not really...
16:36:04 <LordAro> std::map<std::pair<key, subkey>, std::vector<value>> ?
16:36:13 <truebrain> talltyler: by that logic, you can close all bugs ๐ Pffff ... /me logins to GitHub Admin panel ....
16:36:49 <talltyler> Well, your report was not a bug, but "I don't like this intentional behavior" ๐
16:36:58 <talltyler> The way to solve that is a PR ๐
16:37:38 <truebrain> talltyler: as I said, be careful with that reasoning, as that is a way to close (almost) all bugs ๐
16:38:23 <talltyler> Bugs are unintentional behavior. I don't find it confusing ๐
16:38:54 <truebrain> I am pretty sure it is not intentional, functional, that the error message is that far away from your mouse ๐
16:39:04 <truebrain> the code might say it is, doesn't mean it actually is wanted ๐
16:39:08 <talltyler> I have one issue to convert to a discussion, sorry for the IRC spam and momentary Discord spam (until I delete the extra messages)
16:39:14 <truebrain> as I said: be careful, it is a slippery slope ๐
16:39:23 <LordAro> it comes from an era of 640x480 screens, not 3840x2140 or whatever 4k is
16:40:09 <truebrain> talltyler: you don't find the reasoning confusing, or you don't find the bug a confusing thing?
16:40:16 <truebrain> a bit ambigious .. just so I understand you clear ๐
16:41:03 <talltyler> I don't have a hard time distinguishing between "the game is not working as intended" and "the game is working as intended but I don't like it"
16:41:33 <truebrain> so in your opinion, functional seen, it is okay if on a 4k screen I click on a tile which creates an error, an on the right bottom side of the screen the error pops up?
16:41:49 <truebrain> I didn't want to delve into this, but your opinion is confusing me more than the fact you closed the ticket ๐
16:42:09 <LordAro> "i don't like it" doesn't automatically make it an invalid bug
16:42:14 <talltyler> I do recognize that if conditions change between when the behavior is designed, and when we are experiencing it now, the original intentions are no longer correct for the current conditions
16:42:33 <LordAro> also, intentions may have been misplaced
16:42:34 <truebrain> so, I defined the current conditions .. how is that "game working as intended"? ๐
16:42:52 <truebrain> I mean, the harfbuzz bug I fixed yesterday, by the same logic, the game was working as intended
16:42:56 <truebrain> the intention was completely wrong
16:43:28 <truebrain> again, slippery slope, this kind of reasoning ๐ To be clear, I give zero fucks whether the ticket is closed or not. Just want to make sure you don't go all andy on us, and close tickets that actually have merit ๐
16:43:47 <truebrain> it is subjective, I agree ๐
16:44:52 <talltyler> Last week I converted "issues with merit" to Discussions, and you told me to close them instead ๐
16:45:17 <truebrain> no, we asked you to stop spamming our chat channels ๐
16:45:32 <truebrain> GitHub is being an ass; I completely agree with the tickets you converted ๐
16:46:11 <truebrain> anyway, there is a clear difference between: GS doesn't implement A/B/C .. that clearly is a feature request. But when behaviour is unexpected or weird, let's not be too greedy in closing (or at least, let's talk about it ๐ )
16:46:29 <truebrain> I still love you; you can keep your GitHub rights ๐
16:49:20 <talltyler> Anyway, real job time
16:53:28 <truebrain> does remind me I have to fix a dibridge issue, and look into relaying the GitHub spam ...
16:57:15 <truebrain> it starts with a `_`, it ends with a `_` ..... ๐
16:59:58 <truebrain> we will be right back!
17:02:34 <truebrain> isn't it great? Best feature evah!
17:02:35 *** michi_cc[d] has quit IRC (Remote host closed the connection)
17:02:35 *** sjiveru has quit IRC (Remote host closed the connection)
17:02:35 *** johnfranklin has quit IRC (Remote host closed the connection)
17:02:35 *** bigyihsuan has quit IRC (Remote host closed the connection)
17:02:35 *** efessel has quit IRC (Remote host closed the connection)
17:02:35 *** fverz has quit IRC (Remote host closed the connection)
17:02:35 *** nek0master_disc0rd has quit IRC (Remote host closed the connection)
17:02:35 *** brzda has quit IRC (Remote host closed the connection)
17:02:35 *** belajalilija has quit IRC (Remote host closed the connection)
17:02:35 *** mryakov has quit IRC (Remote host closed the connection)
17:02:35 *** jfs has quit IRC (Remote host closed the connection)
17:02:35 *** Planarity has quit IRC (Remote host closed the connection)
17:02:35 *** talltyler has quit IRC (Remote host closed the connection)
17:02:35 *** emperorjake has quit IRC (Remote host closed the connection)
17:02:35 *** _jgr_ has quit IRC (Remote host closed the connection)
17:02:35 *** DorpsGek_vi has quit IRC (Remote host closed the connection)
17:02:35 *** palalet has quit IRC (Remote host closed the connection)
17:02:35 *** _heresy has quit IRC (Remote host closed the connection)
17:02:35 *** kuhnovic has quit IRC (Remote host closed the connection)
17:02:35 *** andythenorth has quit IRC (Remote host closed the connection)
17:02:35 *** xarick has quit IRC (Remote host closed the connection)
17:02:35 *** peter1138[d] has quit IRC (Remote host closed the connection)
17:02:35 *** georgevb has quit IRC (Remote host closed the connection)
17:02:35 *** _zephyris has quit IRC (Remote host closed the connection)
17:02:35 *** flogeza has quit IRC (Remote host closed the connection)
17:02:35 *** lamarr has quit IRC (Remote host closed the connection)
17:02:35 *** clandry94 has quit IRC (Remote host closed the connection)
17:02:35 *** reldred has quit IRC (Remote host closed the connection)
17:02:35 *** truebrain has quit IRC (Remote host closed the connection)
17:02:35 *** tabytac has quit IRC (Remote host closed the connection)
17:02:35 *** wensimehrp has quit IRC (Remote host closed the connection)
17:02:35 *** locosage has quit IRC (Remote host closed the connection)
17:02:35 *** rau117 has quit IRC (Remote host closed the connection)
17:02:35 *** _glx_ has quit IRC (Remote host closed the connection)
17:02:35 *** merni has quit IRC (Remote host closed the connection)
17:02:35 *** yorks_andy has quit IRC (Remote host closed the connection)
17:02:35 *** nanapipirara has quit IRC (Remote host closed the connection)
17:02:35 *** frosch123 has quit IRC (Remote host closed the connection)
17:02:35 *** jeanyves_32366 has quit IRC (Remote host closed the connection)
17:02:35 *** nihues has quit IRC (Remote host closed the connection)
17:02:48 *** DorpsGek_vi has joined #openttd
17:02:54 *** truebrain has joined #openttd
17:03:25 <truebrain> was a while ago that there was a bug in dibridge ๐
17:07:05 <_glx_> yup bugs are very rare in dibridge
17:08:07 <truebrain> bunch of stable libraries, Discord and IRC libraries, that is
17:11:34 *** peter1138[d] has joined #openttd
17:11:35 <peter1138[d]> Hmm, PALETTE_BRIGHTNESS_MODIFY...
17:11:41 <peter1138[d]> What does JGRPP use that for? ๐
17:14:04 <_jgr_> peter1138[d]: Tree shading on slopes
17:15:40 <peter1138[d]> Seems like a hack. You should implement a full ray traced lighting path for that...
17:17:26 <_jgr_> We just assume that the singular light source is infinitely far away and the rays don't bounce
17:20:07 <peter1138[d]> Ah, so it's just optimized away.
17:21:56 <peter1138[d]> Disabling hinting in freetype doesn't actually affect Tahoma. Weird.
17:52:09 <peter1138[d]> Cool so it's just harfbuzz.
17:53:57 <_glx_> maybe something with GetPositions() or GetGlyphToCharMap()
17:57:01 <_glx_> uniscribe version of GetGlyphToCharMap() looks a lot more complex than icu or osx
17:57:57 <peter1138[d]> Line 504 specifically, yes.
18:02:08 <peter1138[d]> C++ is so lazy these days, you don't have to write anything yourself!
18:07:33 <Rubidium> the only caveat is that the old code takes 80% of the time C++ variant... *or* I'm doing something wrong with my test, but I thought looping from 0 to 2**31-1, calculating the last bit and adding them would be a reasonable test
18:11:38 <_jgr_> Running it in a tight loop like that will give different numbers to just calling it once here and there
18:12:20 <_jgr_> Using fewer instructions is probably better overall even if it might take a smidge longer in a tight loop
18:18:02 <xarick> I better turn that pr into a draft
18:18:07 <xarick> before someone merges ๐
18:19:44 <xarick> no bug in master, it's me :/
18:22:10 <xarick> no bug on my branch, which can only mean...
18:24:19 <xarick> my branch uses the scriptmarine version
18:27:07 <peter1138[d]> GetTileTrackStatus does a lot of checks.
18:28:51 <xarick> but I tested script and it worked there
18:29:10 <xarick> maybe I pass side and opposite_side in the wrong order
18:30:59 <xarick> `if (!AreWaterTileEdgesConnected(current_edge_tile, neighbor_edge_tile, opposite_side, side)) continue;` this feels anti-natural
18:32:32 <peter1138[d]> Mixed RTL/LTR text editing is also broken. Hm.
18:37:33 <truebrain> peter1138[d]: pfff, I fixed that last time
18:40:21 <DorpsGek> - Update: Translations from eints (by translators)
18:46:58 <truebrain> too much pruning of my branches
18:47:58 <truebrain> pfew, we have "restore" buttons
18:48:57 <xarick> GetTileTrackStatus_TunnelBridge confuses the heck out of me
18:49:21 <xarick> It needs a description
18:50:03 <_jgr_> The description is the name
18:50:18 <xarick> the DiagDirection it takes is not what I think it isa
18:51:32 <xarick> GetTunnelBridgeDirection gets me the opposite direction that is passed to it
18:51:57 <xarick> and yet, it's a valid direction apparently, one that will have tracks
18:53:10 <xarick> they are reverse, it's ... confusing, what is it taking, the direction from where to where?
18:56:26 <Rubidium> I know what I did wrong with the performance testing... not adding -O2...
19:06:11 <Rubidium> also... maybe normal "cmake .." builds should get -Og? ?
19:07:32 <peter1138[d]> JGR said that too.
19:08:36 <_jgr_> I've changed it in my branch so that `cmake ..` with no options gets you a playable build
19:40:33 <peter1138[d]> Yeah, barely a solution at all ๐
19:41:37 *** andythenorth has joined #openttd
19:49:39 <LordAro> peter1138[d]: sounds like it needs some unit tests :p
19:50:50 <andythenorth> let's eat leftovers
19:52:58 <peter1138[d]> That moment when you want a double-break.
19:55:37 *** esselfe has quit IRC (Quit: 1000โฐ Linux)
20:15:35 <andythenorth> random food report: pork loin, bombay potatoes, 3 kinds of fresh veg
20:17:02 <xarick> GetTileTrackStatus_TunnelBridge continues to baffle me
20:17:08 *** frosch123 has joined #openttd
20:17:08 <frosch123> i prefer cooked veg
20:17:40 *** nielsm has quit IRC (Ping timeout: 480 seconds)
20:22:23 <xarick> and I totally forgot what I was about to do before I stepped on the bug
20:46:12 <xarick> I remember now what I wanted to do. The question is... do I need to check for connectivity when the aqueducts aren't cross-region?
20:48:39 <Rubidium> won't they be in the same patch, when it's inner-region?
20:49:36 <xarick> yes, but it could be placed right at the edge
20:51:58 <xarick> seems that a bridge starting at the edge towards inside can have the bit & bit set on the edges and is still a valid connection
20:56:46 <xarick> I was not good at solving puzzles
20:57:21 *** esselfe has joined #openttd
20:58:26 <truebrain> Rubidium is enjoying himself with this C++20 stuff ๐
21:00:56 <peter1138[d]> Me just sad about ranges/views ๐ฆ
21:01:24 <truebrain> If return else return
21:01:32 <truebrain> Or just: if return return
21:01:43 <truebrain> Always wonder if that else is useful
21:03:03 <_glx_> usually I skip the else
21:03:30 <_glx_> kind of early return in the if
21:04:30 <truebrain> peter1138[d]: Forgot, why were ranges/view a no-go?
21:04:40 <_jgr_> Having these bit functions in the standard is nice
21:04:59 <_jgr_> I've been using GCC builtins and/or a load of ifdefs for stuff like that so far
21:06:40 <Rubidium> with `if constexpr (` it is (sadly) needed in that case. std::popcount is very picky about its types, so if you do if constexpr (std::is_enum) return popcount<underlying_type<enum>>(x); return popcount(x); It will first try to deduce the unreachable popcount with the enum if you pass it an enum, and then you got a compiler refusing to go any further :(
21:09:37 <peter1138[d]> truebrain: Don't work with clang-15.
21:09:50 <_glx_> somehow similar to #if #else #endif but at compiler level
21:12:40 <truebrain> peter1138[d]: Matrix says clang-16 indeed
21:12:55 <peter1138[d]> And clang-16 has another compile error ๐
21:14:11 <peter1138[d]> In summary... the forward declaration is ambiguous with the definition...
21:14:20 <xarick> before I get too carried away, is there any performance to be gained by going from int to uint8_t in this situation?
21:15:51 <truebrain> peter1138[d]: Lol. Clang used to be the better of the two ๐
21:17:28 <frosch123> truebrain: all the former clang supporters forked their own c++ competitor language :p
21:19:07 <frosch123> if it was even rust... but it's carbon and others
21:19:26 <truebrain> Zig, Julia, Carbon, ....
21:19:44 *** brickblock19280 has joined #openttd
21:19:44 <brickblock19280> andythenorth: I think I saw one at some point
21:19:58 <frosch123> zig competes with C, julia with python, carbon with c++, right?
21:20:17 <truebrain> I keep reading Zig is so awesome
21:20:23 <truebrain> I never looked at it
21:20:57 <truebrain> Carbon seems to be a joke, at least, nobody actually seems to assume it is serious ๐
21:22:24 <frosch123> well, at least i started learning rust ๐
21:23:00 <truebrain> Now that is a good language to learn ๐
21:24:37 <truebrain> I really enjoy how compatible Rust is .. both with other languages, with other targets, etc .. it just works
21:25:11 <peter1138[d]> That... is not what I heard.
21:25:24 <frosch123> i was impressed by cargo providing project structure, code style and even git setup ๐
21:25:46 <frosch123> oh also: the coding style is similar to python
21:25:50 <truebrain> The eco system in general is solid
21:25:55 <frosch123> so finally some convergence in the endless see
21:26:12 <truebrain> But yeah, strong (and good) templates
21:26:40 <truebrain> I had to setup a javascript project the other day .. spend 2 hours getting everything setup ... didn't write a single line of code..
21:27:54 <_jgr_> I never really understood why some JS projects insist on mountains of build tooling
21:28:18 <truebrain> Getting eslint setup requires an education
21:28:19 <_jgr_> Having dealt with that before, I try not to have any build tooling at all when I do JS now
21:28:52 <truebrain> I use Rust a lot to work in browsers. But it can't do everything yet
21:30:27 <peter1138[d]> I have thousands of hours in Rust, but... that's just a game.
21:48:42 <Rubidium> if you can tell how to apply that to gfx_type.h, then I'll bite :)
21:50:00 <truebrain> did we got this far with cleaning up endian stuff? I am shocked
21:50:18 <frosch123> ok, gfx_type.h is nasty
21:50:18 <truebrain> we have no BE targets anymore to test with
21:50:23 <truebrain> can't we just remove all BE code?
21:50:29 <frosch123> would need inline getters instead of member access
21:50:40 <truebrain> and just CMake error on any BE target?
21:50:58 <frosch123> what does the survey say? :p
21:51:06 <truebrain> we don't have any BE targets anymore ๐
21:51:22 <truebrain> it is actually in the survey, funny enough ๐
21:51:26 <frosch123> i saw some win xp in the survey
21:51:37 <truebrain> yeah, but you cannot build for any BE target ๐
21:51:43 <truebrain> MacOS is out of support so badly, it won't build
21:52:31 <truebrain> IA-64 is no more too
21:52:52 <truebrain> (although it can run LE fine too)
21:53:39 <truebrain> last CPU with BE instructions is from 2006
21:53:57 <truebrain> (I mostly just hate that we can't test BE, so PRs for it are ... "most likely correct"?
21:56:21 <truebrain> ugh, seriously, that code .. so we have `_langpack.langpack.offsets` and `_langpack.offsets` ..
21:57:25 <andythenorth> why doesn't TGP?
21:57:34 <andythenorth> this is not 'mountainous'
21:57:52 <truebrain> please take a bucket; I collect tears
21:58:38 <truebrain> if possible; but I am not picky
21:58:58 <andythenorth> freshwater tears
21:59:38 <frosch123> looks pretty moutainous for so much sea level
21:59:49 <andythenorth> how do I get some actual terrain? ๐
21:59:56 <peter1138[d]> Turn off variety
21:59:58 <andythenorth> is this variety distribution doing its thing?
22:00:12 <frosch123> high water, high smoothness
22:00:13 <peter1138[d]> It's a known shit heap... mountain killer.
22:00:27 <andythenorth> variety low -> variety off
22:00:55 <truebrain> incoming PR to remove variety?
22:00:55 <andythenorth> what a lol feature
22:01:02 <andythenorth> "we can tune it"
22:01:22 <peter1138[d]> variety tries to shape land into regions, but doesn't pay any attention to the existing height.
22:01:53 <peter1138[d]> I've always said it needed replacing but never got around to it.
22:02:31 <truebrain> I made some beautiful heightmaps today; does it help?
22:02:46 <truebrain> I also have them in Minecraft-edition
22:03:05 <frosch123> hmm, half of my apprentice applications claimed to have ai-training skills. why did noone PR an AI-based mapgen, trained on real world maps?
22:03:24 <truebrain> frosch123: honestly, that isn't even a bad idea ๐
22:04:08 <frosch123> finally ottd can have a real ai :p
22:04:50 <frosch123> is there some ai competition we could bait to try mapgen stuff?
22:05:29 <andythenorth> Alpinist is good when it works eh
22:05:44 <andythenorth> it's not reliable, but when it works, it's very good
22:06:38 <truebrain> /me waits for the inevidable: can we have a preview? ๐
22:07:28 <frosch123> ah yes, another thing that noone PRed yet for some reason
22:07:35 *** reldred has joined #openttd
22:07:35 <reldred> Train the AI on Cpt Kโs heightmaps
22:07:54 <truebrain> frosch123: so what is keeping you! ๐
22:08:48 <truebrain> ```CMake Error: Error required internal CMake variable not set, cmake may not be built correctly.
22:08:48 <truebrain> Missing variable is:
22:08:48 <truebrain> CMAKE_C_COMPILE_OBJECT```
22:09:28 <truebrain> I added a pure C file
22:09:36 <truebrain> turns out, my setup didn't have a C-compiler at the ready
22:09:42 <truebrain> our project actually doesn't have any C-files anymore
22:09:55 *** keikoz has quit IRC (Ping timeout: 480 seconds)
22:10:38 <_glx_> and we only tell " LANGUAGES CXX"
22:10:54 <_glx_> so cmake skips searching for C compiler
22:11:03 <truebrain> so I could either add C to that list, or just rename the file to cpp, as it actually is a C++ file too
22:11:45 <frosch123> oh, i miss the #ifdef __cplusplus extern "C" { boiler plate
22:11:55 <frosch123> my old job had that
22:12:02 <truebrain> I recently added that in one of my PRs, no worries ๐
22:12:20 <_glx_> that's for API headers usually
22:12:32 <truebrain> (the one with a pure C API to talk to plugins has that)
22:23:21 <truebrain> wow, it is shockingly difficult to get a random string usable for security operations in C++ ..
22:23:40 <truebrain> I was stealing code from JGRPP, but the library JGR used, uses by-now deprecated Windows API
22:24:02 <peter1138[d]> "2 hours ago" uh huh
22:24:29 <peter1138[d]> I stole come code from JGRPP earlier too. Such plague(-arism)
22:29:30 <truebrain> hmm .. `getrandom` is added in libc 2.25 ... guess there won't be a legacy linux for long ... ๐
22:30:24 <frosch123> isn't there maybe some random stuff in the curl/https stuff we link?
22:30:47 <truebrain> possibly .. still requires custom work for Windows, but that was going to be true either way
22:32:09 <truebrain> ha, called it in my approval! ๐
22:33:55 <peter1138[d]> This is why ๐
22:34:20 <frosch123> sounds like a cheat to boost your review scores: approve PRs which are rejected by the CI checks
22:35:24 <peter1138[d]> I remember seeing a PR where the repo owner required the submitted to favourite the repository ... with the PR being automatically closed if not.
22:35:50 <truebrain> "you don't like us? We don't care about you!"
22:36:22 <frosch123> weren't there oauth apps which requested the "like stuff" role?
22:36:38 <frosch123> just so they could like scammers who paid them for liking
22:44:10 *** Wolf01 has quit IRC (Quit: Once again the world is quick to bury me.)
22:46:41 <xarick> well, can't make it more performant
22:52:47 <xarick> Kuhnovic approach to his solution feels... incomplete, for lack of better words
22:52:48 <peter1138[d]> xarick: How does it look with lots of ships and averaging instead of timing one sample.
22:53:36 <xarick> and ships using orders to depots
22:54:03 <xarick> or if using orders to depot, it's the nearest depot one
22:54:54 <xarick> maybe I'll update my own AI
22:55:46 <xarick> pretty sure most AIs use go to depot orders because it was so easy to get a ship lost without it.
23:05:14 <xarick> got an openttd crash when starting AIs ๐ฆ
23:06:48 <truebrain> everything to make the commit checker happy ๐
23:08:13 <xarick> oh, crash because number of regions bug
23:08:26 <xarick> using 256 from the main menu
23:08:39 <xarick> while i'm generating a map with 65536
23:13:12 <truebrain> isn't Windows a funny boy? Failing to include `bcrypt.h` ...
23:14:31 <peter1138[d]> Anyone got a Mac to test #11835?
23:14:49 <truebrain> when it is his TZ again, you can bug Emperor
23:15:50 <reldred> peter1138[d]: watchoo need, i'm on intel here
23:15:50 <truebrain> `'MIN' macro redefined [-Wmacro-redefined]` .. tnx MacOS .. or something
23:16:32 <peter1138[d]> reldred: Just need to make sure scalable font rendering isn't messed up with it.
23:17:02 <reldred> ahh, you need me to build or have you got binaries already?
23:17:24 <reldred> I'm on my work computer, haven't setup a build env for openttd specifically.
23:17:49 <reldred> I've got vs code but doesn't mac hold a gun to your head and make you do everything with xcode?
23:21:56 <truebrain> lolz, can't find a secure random generator for Emscripten
23:35:30 <peter1138[d]> reldred: Yeah it'll need building. Hmm.
23:38:32 <truebrain> right, I will be needing a javascript call to get an actual random value in emscripten
23:38:38 <truebrain> why doesn't emscripten do that for me? I DO NOT KNOW
23:41:20 <truebrain> they do have it for Node, but not for Browsers? Odd ..
23:41:44 <truebrain> but for Node it is done via random device, which is .. odd too ๐ Owh well, custom Javascript function it is!
23:43:34 <truebrain> Owh owh owh, and I can use `span` instead of sending pointer + length! Something for tomorrow ๐
23:46:12 <reldred> peter1138[d]: I'm bored at work and mostly just supervising the minions atm, lets have a crack at it
23:47:51 <Eddi|zuHause> forum got a new "this game is 40 years old, why won't it run giant maps on my 20 year old pc?"
23:48:25 <Eddi|zuHause> well, it's more like 30 years, but whatever :p
23:50:07 <reldred> god this old mac is slow D:
23:50:20 <peter1138[d]> Is it Big Endian?
23:51:08 <truebrain> oof, that must be 12% slower then ..
23:51:32 <Rubidium> well... the current gcc run is probably a factor 12 slower than the one before that :(
23:51:46 <truebrain> try compiling 0.4.8, and enjoy how fast it could have been
23:51:48 <reldred> I was supposed to be getting an m2 mbp but it didn't end up happening -___-
23:51:52 <truebrain> I am sure that version would have run a GIGA map with ease
23:52:30 <truebrain> OEH, WE GOT YOUR SERIAL NUMBER! Let me quick report it stolen, MWHAHAHAHAHA
23:52:57 <reldred> It's my work computer. It would force them to buy me a new work computer. ๐
23:53:29 <reldred> I believe the phrase is 'don't threaten me with a good time?'
23:56:13 <andythenorth> Could have been worse
23:56:39 <andythenorth> I want a celeron
23:57:00 <reldred> To be fair I used to have a thirteenth gen intel laptop but it was some big 15" Dell thing
23:57:20 <reldred> Either way it was newer than this mbp
23:58:42 <andythenorth> Was it 12th gen celeron?
23:59:04 <peter1138[d]> 12% faster 12th gen?
23:59:51 <peter1138[d]> n5100, launched Q1'21. It's newish, it must be fine.
continue to next day โต