IRC logs for #openttd on OFTC at 2023-12-13
00:04:13 <_glx_> yeah nightly failed again
00:04:24 <_glx_> so steam still has the broken version
00:04:40 <_glx_> "/Users/runner/work/OpenTTD/OpenTTD/build-x64/_CPack_Packages/x86_64/Bundle/openttd-20231211-master-g0a8bcdd344-macos-universal/ timestamps differ by 242 seconds - check your system clock"
00:04:44 <_glx_> that's annoying
00:06:40 <DorpsGek> [OpenTTD/OpenTTD] glx22 commented on issue #11577: [Bug]: Ctrl + left click Centre view on ship depot opens a viewport centered on a power station
00:26:05 <_glx_> at least I can use git bisect πŸ™‚
00:36:24 <_glx_> git bisect says
00:49:11 <_glx_> ok I understand what happens
00:52:34 <peter1138> ExtraViewportWindow passing 0, which used to be interpreted as a tile, but now is a... vehicleid?
00:52:55 <peter1138> But then... a power plant isn't a vehicle
00:52:56 <peter1138> *shrug*
00:53:42 <peter1138> But also it's windows only, so.
00:53:50 <peter1138> Or maybe it's some combination of settings.
00:56:25 <_glx_> most likely UB
00:56:35 <_glx_> but yeah it's the 0
00:57:16 *** bryjen has quit IRC (Quit: Leaving)
01:02:43 <_glx_> hmm need to check if I didn't break anything
01:03:00 <peter1138> Hmm, I'd say pass tile to InitializeViewport, and make it handle INVALID_TILE, and then drop lines 63-78 of ExtraViewportWindow.
01:05:05 <peter1138> I can make a PR for that.
01:06:15 <_zephyris> Hmm
01:06:18 <_zephyris>
01:07:01 <_zephyris> peter1138[d]: What OS are you running? And was it Liberation Sans that overflowed nicely?
01:07:09 <peter1138> FreeSans
01:07:22 <peter1138> On Linux, so FreeType
01:12:15 <_zephyris> peter1138[d]: Free Sans Bold size 10?
01:12:53 <peter1138> Yes
01:12:54 <DorpsGek> [OpenTTD/OpenTTD] PeterN opened pull request #11578: Fix #11577: Extra viewport opened in wrong location.
01:13:55 <_glx_> I was going to TileIndex(0)
01:14:07 <_zephyris>
01:14:07 <_zephyris> No overflow... Windows 10
01:15:09 <peter1138[d]>
01:15:31 <peter1138[d]> Not really overflowing here either. Hmm.
01:16:12 <peter1138[d]>
01:16:39 <peter1138[d]> It's subtle. But yes, Windows and FreeType rendering can be different.
01:17:12 <peter1138> I have a patch for Windows that uses different geometry, let's see where that went.
01:18:16 <peter1138>
01:19:55 <peter1138> LOL just noticed that truebrain AI'd that one.
01:21:37 <DorpsGek> [OpenTTD/OpenTTD] PeterN updated pull request #10273: Fix #10151: Use otmAscent instead of otmTextMetrics.tmAscent [Windows]
01:21:49 <peter1138> No longer a year out of date :D
01:24:34 <_zephyris> Thanks, I'll have a poke
01:24:43 <_zephyris> Now sleep πŸ™‚
01:37:20 <DorpsGek> [OpenTTD/OpenTTD] glx22 approved pull request #11578: Fix #11577: Extra viewport opened in wrong location.
01:41:21 <DorpsGek> [OpenTTD/OpenTTD] github-advanced-security[bot] commented on pull request #11578: Fix #11577: Extra viewport opened in wrong location.
01:41:31 <peter1138> :o
01:41:45 <peter1138> Ah, oops :)
01:42:20 <peter1138> VehicleID 0 doesn't explain why it goes to an industry, except perhaps is vehicle id 0 doesn't exist.
01:43:39 <_glx_> when testing I had no vehicles
01:43:47 <_glx_> I can test with one
01:43:58 <peter1138> It's fine, it's clearly wrong anyway :)
01:48:31 <_glx_> oh vehicle 0 is an effect
01:48:37 <peter1138> Oh!
01:50:23 <DorpsGek> [OpenTTD/OpenTTD] PeterN dismissed a review for pull request #11578: Fix #11577: Extra viewport opened in wrong location.
01:50:26 <DorpsGek> [OpenTTD/OpenTTD] PeterN updated pull request #11578: Fix #11577: Extra viewport opened in wrong location.
01:50:31 <_glx_> the vehicle I built is at index 1
01:50:53 <peter1138> And vehicle it's a VehicleID, follow_vehicle is set, so the location override is moot.
01:50:58 <peter1138> ...
01:51:00 <peter1138> And because
01:51:34 <peter1138> This is where implicit conversions are bad.
01:51:48 <DorpsGek> [OpenTTD/OpenTTD] glx22 approved pull request #11578: Fix #11577: Extra viewport opened in wrong location.
01:52:12 <peter1138> It's not exactly undefined behaviour, it's 0 is implicitly converted to VehicleID on Windows, and implicitly converted to TileIndex on others.
01:52:37 <peter1138> I suppose this the definition of UB :)
01:55:58 <_glx_> spec is not clear on this point
01:57:18 <_glx_> I think it's (4) in <>, but it doesn't really tell what type should be selected
02:04:26 *** herms has quit IRC (Quit: bye)
02:05:45 *** herms has joined #openttd
02:13:16 <_glx_> oh of course vehicle 0 is the chimney smoke
02:13:48 <peter1138> Yup
02:14:54 <_glx_> that explains everything πŸ™‚
02:16:35 <DorpsGek> [OpenTTD/grfcodec] glx22 merged pull request #28: Add: Install, Pack (windows) and Release workflow
02:19:20 <DorpsGek> [OpenTTD/OpenTTD] PeterN merged pull request #11578: Fix #11577: Extra viewport opened in wrong location.
02:19:23 <DorpsGek> [OpenTTD/OpenTTD] PeterN closed issue #11577: [Bug]: Ctrl + left click Centre view on ship depot opens a viewport centered on a power station
03:03:38 *** Flygon has quit IRC (Quit: A toaster's basically a soldering iron designed to toast bread)
03:29:39 *** Gadg8eer[m] has quit IRC (Quit: Client limit exceeded: 20000)
03:35:45 *** Wormnest has quit IRC (Quit: Leaving)
03:39:22 *** bryjen has joined #openttd
03:55:29 *** debdog has joined #openttd
03:58:51 *** D-HUND has quit IRC (Ping timeout: 480 seconds)
04:30:49 *** keikoz has joined #openttd
04:35:04 <locosage> peter1138[d]: you can check how cmclient does 32bpp to 8
04:35:15 <locosage> it's somewhat similar to rgba-eater minus all the options
04:41:59 <locosage> <>
04:42:41 <locosage> not the best solution but for 8bpp blitter fallback should be enough
04:43:26 <locosage> lol, wtf, it is using wrong color distance...
04:44:08 <locosage> should be smth like this <>
04:44:44 <locosage> as rgb space isn't linear
04:57:15 <pandonaut> truebrain: :Sadgers:
05:47:37 *** bryjen has quit IRC (Quit: Leaving)
08:47:49 *** Deep3D has joined #openttd
09:10:51 <peter1138> Why do you convert from RGB to M for 32bpp blitters instead of 8bpp blitters?
09:17:45 <locosage> for 32bpp recolors
09:28:42 <locosage>
09:39:47 <xarick> hmm OpenTTD doesn't handle Hibernate option that well
09:40:13 <xarick> when system awakes from hibernate, there's a change that something goes wrong
09:40:16 <peter1138> OpenTTD doesn't need to handle Hibernate.
09:40:24 <xarick> it either gets stuck
09:40:33 <xarick> or crashes
09:40:34 <peter1138> That's your system not hibernating properly.
09:40:35 <xarick> or poofs
09:40:52 <LordAro> you know where crash reports are supposed to go
09:41:49 <xarick> well, yes, but this time it is stuck...
09:42:03 <xarick> unresponsive
09:42:40 <xarick> funny thing, it's using 33% of cpu
09:42:46 <peter1138> It's generally graphics card drivers not restoring state.
09:42:48 <xarick> on a 8 core
09:42:59 <LordAro> i believe you know how to attach to a process with visual studio?
09:44:27 <xarick> this is the official 13.4 OpenTTD
09:44:32 <xarick> how would I do that?
09:44:55 <LordAro> hmm, trickier indeed
09:45:15 <LordAro> but debug symbols are available
09:50:21 *** Deep3D has left #openttd
09:50:48 <xarick> oh snap, Github Desktop latest update changes the way branches are listed
09:50:57 <xarick> I can't switch to 13.4 anymore
09:53:45 <xarick> nevermind, I can on visual studio
10:00:44 <xarick> apparently i dont know how to attach debug symbols
10:01:14 *** ufo-piloot_ has joined #openttd
10:03:28 <peter1138> lol, 16MB array for palette lookups right?
10:03:45 *** ufo-piloot has quit IRC (Ping timeout: 480 seconds)
10:03:50 <peter1138> One way to make emscriptem fail again :D
10:05:46 <locosage> mine is 262k
10:06:20 <peter1138> I know.
10:07:44 <peter1138> I tried 2 bits for fun. It's actually completely usable. The 32bpp houses GRF I tested is not bad, but zBase suffers.
10:08:37 <peter1138> 256KiB is probably reasonable.
10:09:43 <locosage> what color distance are you using?
10:09:48 <peter1138> sRGB
10:10:02 <peter1138> I was already using the same as in your python.
10:10:02 <locosage> that's space not distance
10:10:07 <peter1138> Oh, sorry.
10:10:09 <peter1138> Er...
10:10:09 <locosage> r*r+g*g+b*b
10:10:16 <locosage> ?
10:10:39 <peter1138> 2/4/3 or 3/4/2
10:10:41 <peter1138> Yeah
10:11:27 <merni> locosage: discord thought * was for italic markup :p
10:11:44 <merni> oops replied to wrong post
10:12:04 <locosage> yeah, I also accidentally pressed enter too soon xD
10:13:26 <peter1138> < this page refers to it as sRGB distance.
10:21:51 <locosage> where? that page is a bit of a mess but it seems to be listing euclidean and other distances for srgb space
10:21:57 <locosage> one python uses is apparently "redmean"
10:22:45 <locosage> though I'm trying redmean in cmclient and it doesn't look that great, but maybe I'm doing smth wrong
10:25:25 <peter1138[d]>
10:25:25 <peter1138[d]> peter1138[d]:
10:26:28 <peter1138> This is 8 bits per channel (old) vs 6 bits per channel (new)
10:26:59 <peter1138> There'll be a "some" pixels there are different, but because it's still the same palette there isn't much difference.
10:27:22 <peter1138> And using a simple 6 bpc lookup is much quicker.
10:27:57 <peter1138> Hmm, does the palette change with toyland... I think it does.
10:28:14 <locosage> yep
10:28:15 <peter1138> Hmm, does the palette change with toyland... I think it does.
10:28:17 <peter1138> Oops
10:28:34 <peter1138> Although if it's just animated water then they're ignored anyway,.
10:39:40 <xarick> why isn't visual studio asking for the pdb file?
10:39:45 <xarick> or pbd
10:51:18 <xarick> okay i managed to get somewhere
10:51:36 <xarick> seems that the game is running
10:51:52 <xarick> but the videodriver isn't actually drawing
10:54:02 <ahyangyi> locosage: What is this...? Showing the zones of a town?
11:01:06 <xarick> I'm not expert enough to understand what's happening
11:04:21 <locosage> ahyangyi: yep
11:15:09 <xarick> OpenGLBackend::Paint() is never called, I need help, someone tell me what to look for, why isn't this drawing
11:15:12 *** thelounge345 has quit IRC (Ping timeout: 480 seconds)
11:25:10 *** thelounge345 has joined #openttd
11:33:13 <xarick>
11:33:13 <xarick> I have no clue what to look for... I guess it is stuck somewhere in the external code, according to the call stack. The next statement to executre is SwapBuffers but it never gets to it. I waited an hour already
11:34:59 <_glx_> It should be drawing the cursor
11:35:33 <_glx_> And that's most likely in GPU driver
11:36:38 <xarick>
11:36:38 <xarick> this is where it locked.
11:37:03 <xarick> it's been like that forever since I returned system from hibernation
11:37:15 <xarick> but the other 4 instances of openttd, are fine
11:37:30 <xarick> they returned fine
11:40:57 <peter1138> 09:40 <@peter1138> That's your system not hibernating properly.
11:40:57 <xarick> I see a lot of chrono stuff being used
11:40:59 <peter1138> 09:42 <@peter1138> It's generally graphics card drivers not restoring state.
11:41:50 <xarick> should I disable hardware acceleration instead?
11:42:44 <peter1138> If you regularly want to suspend/hibernate with OpenTTD running, sure.
11:43:30 <LordAro> it does occur to me that you probably don't even need a video driver for most of what you're doing
11:44:07 <LordAro> need a way of showing the results (do script exceptions still output to console?)
11:44:19 <xarick> GameLoop runs
11:44:28 <xarick> in another thread
11:44:31 <xarick> it's looping
11:44:36 <xarick> not stuck there
11:45:16 <peter1138> Non-accelerated graphics will be fine, becuase the OS handles restoring everything.
11:45:51 <_glx_> Broken opengl on AMD is not a first
11:46:26 <_glx_> Less frequent than intel though
11:51:00 <xarick>
11:51:00 <xarick> GameLoop takes 10 ms, it's running
11:52:05 <xarick> I see it doing all the tile loops, landscape, etc... the usual, it's just that it's not displaying it 😦
11:53:52 <_glx_> Yeah because AMD driver is stuck
11:54:15 <xarick> alright, time to disable HW accel then
11:54:52 <LordAro> i guess there's no real way to detect that the video has got stuck and kill the game?
11:59:05 <xarick> is chrono stuff based on real clock? does it account for the system being shut down for hours?
12:00:32 <xarick> or does it only account for the time system is not in hibernation state? how exactly do programs handle that
12:00:56 <LordAro> it depends which clock is being used
12:00:59 <LordAro> chrono has several
12:01:25 <LordAro>
12:02:07 <_glx_> Usually a difference between calls is used so it should be fine
12:02:48 <_glx_> Like "at least X units passed"
12:07:37 <xarick> the AMD driver was the one using 30% cpu then
12:07:46 <xarick> very funny
12:07:53 <locosage> on linux I gave up on hibernation ages ago
12:08:24 <xarick> you want to use gpu to stop using cpu cycles, and then... this
12:13:24 <xarick>
12:13:40 <xarick> sounds to me the ideal clock
12:26:37 <xarick> openttd isn't using steady_clock everywhere
12:26:41 <xarick> hmm
12:32:02 <xarick> catch2 seems to be a recent addition, it has lots of chrono stuff, what is it about?
12:35:10 <xarick> 3rd party
12:36:49 <_glx_> Ignore that, it's only for regression
13:32:54 *** Flygon has joined #openttd
13:35:59 <peter1138> Hmm, iirc the array size that killed emscripten was local scope.
13:36:08 <peter1138> So my 256KiB static scope should be fine.
13:38:27 <DorpsGek> [OpenTTD/nml] glx22 approved pull request #314: Change: Allow creating 32bpp-only NewGRFs
13:59:15 <peter1138> ^ any NML users able to make sure this doesn't blow up their builds?
13:59:19 <peter1138> I think it won't, but...
13:59:25 <peter1138> andythenorth? :D
13:59:42 <peter1138> I guess if it does it can be fixed...
13:59:43 <_glx_> regression passes, so I think it's fine
13:59:47 <peter1138> Fair.
14:00:00 <peter1138> Oh I can't merge anyway :D
14:00:42 <_glx_> yeah you are not a tooling saint
14:01:06 <_glx_> but that's easy to fix
14:03:15 <_glx_> (it's for catcodec, grfcodec, nml and osie)
14:21:42 <xarick> is it just me or OpenTTD is taking more time to build as of recently?
14:21:58 <LordAro> without numbers, yes, it's just you
14:22:35 <_glx_> during git bisect yesterday it was between 30s and 1m
14:22:59 <_glx_> and my clone is on HDD
14:22:59 <LordAro> clearly should get truebrain to record build times on his stats page as well :D
14:22:59 <xarick> how do i measure it?
14:23:23 <_glx_> I let ninja tell me on each step
14:23:27 <truebrain> LordAro: too late; not going to rebuild 2 years of binaries πŸ˜›
14:23:32 <LordAro> :p
14:23:49 <LordAro> probably wouldn't take long
14:23:51 <LordAro> :p
14:23:56 <truebrain> just a few days πŸ˜„
14:24:11 <truebrain> still want to automate it on GitHub .. webassembly is going to be the key here πŸ™‚
14:24:12 <_glx_> you can check CI workflows, the ninja magic is used for them
14:24:33 <truebrain> all I can say, compared to 6 months ago, the game builds A LOT quicker for me
14:24:36 <truebrain> like .. 5 times quicker
14:24:37 <truebrain> dunno
14:24:47 <LordAro> weird :p
14:25:00 <_glx_> oh it's very quick for me since last month πŸ™‚
14:25:23 <truebrain> see; empirical evidence shows things improved πŸ˜„
14:25:30 <xarick> the release 64 takes quite considerable time now 😦
14:25:41 <_glx_> release is always slow
14:25:41 <xarick> but i don't have numbers
14:25:46 <truebrain> 12
14:25:47 <truebrain> 56
14:25:48 <truebrain> 31
14:25:50 <truebrain> there, some numbers
14:26:06 <LordAro> truebrain: so fast
14:26:14 <truebrain> many more where that came from!
14:26:17 <LordAro> who needs /dev/random anyway
14:26:25 <LordAro> /dev/truerandom
14:26:30 <peter1138> return 4;
14:26:36 <truebrain> yes
14:26:50 <xarick> How do I measure time to build with precision? In visual studio
14:26:56 <xarick> I wanna get numbers
14:27:24 <_glx_>
14:27:24 <_glx_> and that's including many builds
14:27:41 <peter1138> truebrain, does your performance stuff track build time as well?
14:27:46 <truebrain> no
14:27:46 <peter1138> Not that it matters.
14:27:51 <peter1138> That's only an andythenorth stat.
14:27:54 <truebrain> as it doesn't matter at all πŸ˜›
14:27:59 <DorpsGek> [OpenTTD/OpenTTD] ldpl updated pull request #10538: Show the number of hidden vehicles on the button
14:28:02 <_glx_> + run to see if the bug is present, then report to bisect
14:28:12 <LordAro> it matters a bit
14:28:27 <truebrain> okay, it shouldn't take several hours to build a nightly, I give you that πŸ™‚
14:28:45 <truebrain> but a release still takes < 30 minutes
14:30:07 <_glx_> xarick: <> this should give precise enough
14:31:13 <peter1138> Anyway, it's probably slower since we used fmt everywhere, and also more uses of templates in general, e.g. drop down list items.
14:31:26 <_glx_> value to put in CMakePresets, or globally in widows config, many options
14:32:19 <_glx_> would be nice to actually get nightlies at some point, the failures are annoying
14:32:39 <_glx_> and quite random
14:32:44 <truebrain> peter1138: yeah, when it was C, it was a lot quicker πŸ˜›
14:32:57 <peter1138> Hmm, even dropping 32bpp sprites to 4 bpc before palette conversion is not too bad.
14:33:00 <peter1138> truebrain, haha yes.
14:39:50 <xarick>
14:40:00 <xarick> found timestamps option
14:42:36 <_glx_> 2 minutes, not bad
14:43:41 <xarick> i kinda swear it used to be faster
14:44:10 <_glx_> CI does it in 8m14s
14:44:52 <xarick> let me time 13.4
14:50:02 <xarick>
14:50:10 <xarick> faster
14:50:27 <peter1138> Hmm, probably best to not try to detect dummy 8bpp sprites.
14:50:52 <peter1138> 13.4 takes 11 minutes? o_O
14:51:12 <xarick> no
14:51:28 <xarick> 1m30s i think, need to do maths
14:51:30 <_glx_> it's just 20s faster
14:51:45 <peter1138> 14:35:35:840>------ Rebuild All started: Project: OpenTTD, Configuration: x64-Release ------
14:51:52 <peter1138> 14:47:08:383 [780/780] Linking CXX executable openttd.exe
14:51:57 <peter1138> That looks like 11m30 to me.
14:51:59 <LordAro> peter1138: there's two files in that gist :D
14:52:13 <peter1138> lol
14:52:29 <peter1138> Well, if you will post the whole log for no reason :D
14:53:19 <peter1138> Don't forget to do a full clean rebuild every time.
14:55:22 <xarick> 1m41s for 13.4 vs 1m59s for current master
14:55:29 <xarick> full clean?
15:00:38 <xarick> 1m39s after Clean All, for 13.4
15:00:43 <xarick> gained 2 secs
15:01:06 <_glx_> error margin
15:01:21 <_glx_> depends on disk access and stuff
15:04:59 <xarick> 1m57s after Clean All, for current master
15:05:36 <peter1138> Seems good to me.
15:07:16 <LordAro> might give some indication about why it's a whole 20s slower
15:07:45 <LordAro> "Showing 1,213 changed files with 120,831 additions and 63,450 deletions." if absolutely nothing else
15:08:53 <_glx_> so about 60000 additions to compile
15:09:50 <xarick> should I buy a 16 core cpu?
15:10:02 <xarick> for building openttd faster?
15:10:38 <peter1138> Yes, but buy it for me.
15:10:53 <peter1138> I think your full compiles are faster than mine :p
15:11:39 <truebrain> LordAro: 1500 commits .. we need a new release πŸ˜›
15:11:57 <xarick> I'm kinda waiting for AMD to release some kind of 3D cache cpu with 16 cores, but for AM4
15:12:03 <LordAro> truebrain: we really do
15:12:16 <LordAro> xarick: just get a threadripper
15:12:28 <xarick> no, I need to game too
15:12:35 <xarick> needs that 3d cache thingy
15:12:38 <LordAro> newer ones boost pretty high
15:12:39 <_glx_> ok a re-run of failed jobs fixed the nightly
15:12:48 <LordAro> "needs"
15:13:06 <_glx_> AM4 is dead
15:13:08 <LordAro> now i want to see how fast i can compile OTTD on our threadripper build servers at work
15:13:22 <LordAro> also yes, AM4 is not getting any new releases
15:13:39 <xarick> there are rumours of a 5700X3D
15:13:43 <xarick> coming in january
15:14:07 <xarick> or Q1 2024, whatever that means
15:14:29 <LordAro> huh
15:21:26 <xarick> I also plan to stream when my internet stops being bad
15:21:49 <xarick> and i prefer x264 software over amf
15:22:20 <xarick> im bad with names
15:24:06 <xarick> 529,90 € for Ryzen 9 5950X vs 299,90 € for Ryzen 7 5800X3D where I live 😦
15:27:25 <xarick> the 7950X3D goes for 649,90 € but would require a new MB, new RAM 😦 too much money
15:40:13 <LordAro> real 0m52.249s
15:40:20 <LordAro> with the threadripper 5975WX
15:40:23 <LordAro> not bad.
15:40:34 * LordAro uninstalls all the things that aren't supposed to be on that system
15:46:03 <locosage> a lot of compilation time is LTO that doesn't seem to be affected by cpu count
15:46:20 <LordAro> depends on the LTO mode, i believe
15:46:26 <LordAro> i was reading something about that the other day
15:46:56 <LordAro> for the above it looked like it was waiting on newgrf.cpp to finish compiling for several seconds before it could start linking
15:47:03 <LordAro> newgrf.cpp is big
15:47:29 <LordAro> this, i believe
15:48:38 <locosage> hm, 3m7.686s
15:48:45 <locosage> I recall it being under 1 min before...
15:52:10 *** m3henry has joined #openttd
15:52:51 <m3henry> LordAro: Have you tried using mold's LTO support?
15:53:26 <LordAro> i haven't
15:57:02 <peter1138> Damn, this 32bpp-to-8bpp works so well.
15:57:40 <locosage> drop 32bpp blitters 🀭
15:57:50 <peter1138> :D
15:57:54 <m3henry> It is rather quick
15:58:02 <andythenorth> what's fastest for nmlc?
15:58:07 <andythenorth> single core only
15:58:09 <andythenorth> python
15:58:26 <peter1138> Other than needing a hard-coded list of non-dummy 8bpp sprite IDs...
15:58:37 <andythenorth> "Checking palette of source images ... 1.3 s" wish that check wasn't there πŸ˜›
15:58:50 <peter1138> 1.3 s is terribad.
15:59:03 <peter1138> andythenorth, make 32bpp-only NewGRF, then there's no palette to check.
15:59:07 <andythenorth> it's 4% of every compile, on something pointless
15:59:17 <andythenorth> the graphics compile already enforces the palette
16:00:11 <xarick> - I'm trying to create a circular tile search, starting from further away from the center, up to the center. But this looks kinda slow
16:03:24 <xarick> maybe I should show you GetAirportMinDistanceToTown too
16:03:42 <locosage> this looks way overcomplicated
16:04:01 <locosage> also, wth is CircularTileSearch recursive
16:04:35 <locosage> ah, nvm, it's overriden
16:04:37 <locosage> stupid c++
16:05:02 <xarick> updated gist
16:09:51 <locosage> anyway, all you need to reverse CircularTileSearch is figure out starting point and reverse radius loop
16:10:31 <locosage> well, it will loop another direction that way but whatever
16:18:16 <peter1138[d]>
16:18:21 <peter1138> Automatic OzTrans mode.
16:20:09 <xarick> oh, i found something
16:21:20 <xarick>
16:21:30 <xarick> looks much simpler
16:21:47 <xarick> but it starts from the center
16:22:03 <xarick> i guess I just sort the list the opposite way
16:22:10 <xarick> and then it starts from the edge
16:26:47 <xarick> I need to make it interruptible though
16:27:00 <xarick> don't wanna perform the entire map in 1 go
16:41:06 *** m3henry has quit IRC (Quit: Page closed)
17:08:48 <peter1138> Hmm.
17:16:07 <xarick> I need somehow to store in the same variable, the tile number and the distancemanhattan
17:16:34 <xarick> because AILists
17:17:13 *** HerzogDeXtEr has joined #openttd
17:17:50 *** gelignite has joined #openttd
17:55:30 <_glx_> the only way with AIList is a tile list and you put distance as value
17:55:54 <xarick> I numbered the tiles in a circular order
17:56:56 *** Wolf01 has joined #openttd
17:59:02 <xarick> maybe I can duplicate the list, one stored the tile number, the other the distancemanhattan
18:08:07 <_glx_> you can also use squirrel types, sometimes AIList are not required
18:18:29 <xarick> I can't sort
18:20:32 <xarick>
18:20:32 <xarick> oh right...
18:20:45 <xarick> cpu valuator hates AIs
18:21:22 <_glx_> an array is sortable
18:22:28 <_glx_> no, openttd hates AIs consuming too much because that affects user experience
18:22:53 <_glx_> and valuators can't be halted
18:22:58 <xarick> and I even tried to segment it
18:23:45 <xarick> it can't call this for 4096*4
18:23:52 <xarick> times
18:27:00 <xarick> no wait, that's not even 4096 per side, it's about 500 for now
18:30:54 <xarick> let's see at which number of items does the valuator kills me
18:31:23 <_glx_> it's not the number of items, but the times needed by item
18:33:46 <xarick> what time is it based upon?
18:35:38 <andythenorth> as I found, doing things like this with GS is....unwise
18:37:11 *** nielsm has joined #openttd
18:38:22 <xarick> okay, it's a number after 16380
18:38:34 <xarick> which makes no sense
18:38:43 <DorpsGek> [OpenTTD/OpenTTD] eints-sync[bot] pushed 1 commits to master
18:38:44 <DorpsGek> - Update: Translations from eints (by translators)
18:39:55 <xarick> nevermind, it makes sense, I forgot something
18:41:00 <xarick> the first loop are the void tiles, that makes calling GetAirportMinDistanceToTown cheaper
18:41:13 <xarick> cus they're all invalid tiles, there's no perimeter to iterate
18:51:04 <xarick> crashed of the 251th tile
18:52:26 *** Wormnest has joined #openttd
18:56:19 <truebrain> peter1138[d]: this is your best work yet. Please keep it in.
18:59:44 <peter1138> Thanks.
19:08:25 <peter1138> Hmm, what to call a type that contains multiple zoom level sprites (but the same sprite)
19:10:52 <locosage> I settled on AlternativeSprites
19:11:04 <locosage> because any other thing I could think of already means something else xD
19:22:55 <DorpsGek> [OpenTTD/OpenTTD] PeterN opened pull request #11579: Fix 0a8bcdd: Scaling non-sprite fonts does not depend on _font_zoom changing.
19:23:02 <peter1138> Such testing :(
19:26:42 <locosage> btw, I actually found it pretty annoying that ttf size changes with ui scale when I was setting up my game
19:27:23 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain approved pull request #11579: Fix 0a8bcdd: Scaling non-sprite fonts does not depend on _font_zoom changing.
19:30:04 <DorpsGek> [OpenTTD/OpenTTD] PeterN opened pull request #11580: Codechange: Replace pointer to Sprite array with reference to SpriteCollection.
19:30:50 <peter1138> Hmm, now, do I keep the "detect dummy 8bpp sprites" code, or is that too klugy...
19:31:37 <peter1138> Ah ha, I remember now. I need to change the loader to tell me if 32bpp sprites are available, even if I'm asking for 8bpp sprites.
19:31:47 <peter1138> And that's why I got distracted by #11580
19:51:49 <DorpsGek> [OpenTTD/OpenTTD] PeterN merged pull request #11579: Fix 0a8bcdd: Scaling non-sprite fonts does not depend on _font_zoom changing.
19:52:11 <xarick>
19:52:11 <xarick> the spikes in the latency graph indicates a Valuate being executed.
19:52:32 <xarick> 18 ms
19:53:44 <xarick> it is valuating GetAirportMinDistanceToTown 242 times
19:53:49 <xarick> each call
19:54:22 <xarick> 243 times and I get excessive cpu valuator
19:54:47 <xarick> 18 ms doesn't even look that bad
19:57:12 <peter1138> Cool, Linux-only patches...
19:59:45 <peter1138> Oh it actually is OS-specific code :D
20:03:37 <DorpsGek> [OpenTTD/OpenTTD] PeterN updated pull request #11580: Codechange: Replace pointer to Sprite array with reference to SpriteCollection.
20:06:56 <truebrain> aren't you happy we have a good CI πŸ˜„
20:08:29 *** Tirili has joined #openttd
20:11:08 <_glx_> ah nightly built fine on first try tonight
20:11:30 <LordAro> \o/
20:18:34 <DorpsGek> [OpenTTD/OpenTTD] PeterN updated pull request #11580: Codechange: Replace pointer to Sprite array with reference to SpriteCollection.
20:18:42 <peter1138> truebrain, if only I was a good coder :o
20:19:12 <truebrain> We all have that on our wishlist
20:25:25 <peter1138> See, you want me to be a good coder too.
20:26:54 *** Wormnest has quit IRC (Ping timeout: 480 seconds)
20:30:02 <_glx_> so release build generates 23 warnings
20:31:28 <_glx_> 10 for linux in nlohmann/json.hpp
20:33:16 <_glx_> and 2 * 6 (x64 and arm64) + 1 (arm64) for macos
20:33:53 <_glx_> unused variables and the missing rdtsc
20:37:03 <_glx_> hmm weird, it would mean WITH_ASSERT is defined, but assert does nothing
20:39:25 *** virtualrandomnumber has joined #openttd
20:39:37 <_glx_> really looks like it, that's not expected
20:42:04 *** virtualrandomnumber has quit IRC ()
20:42:55 <michi_cc[d]> _glx_: Well, have you disabled asserts in cmake?
20:44:11 <_glx_> asserts should be enabled, and the warnings being in code guarded by WITH_ASSERT tends to confirm it
20:47:46 <_glx_> first ones are <> and <>
20:49:44 <_glx_> it's a release build and asserts are enabled so WITH_ASSERT is set, but then NDEBUG should also be set, and our custom assert() macro should work
20:50:37 <_glx_> unless some header re-include assert.h and breaks our own
20:51:19 <_glx_> nlohmann-json used to do that, but we handle this case
20:58:41 *** Eddi|zuHause2 has joined #openttd
20:58:45 *** Eddi|zuHause has quit IRC (Ping timeout: 480 seconds)
21:01:26 <andythenorth> was it cat?
21:01:37 <andythenorth> something about nmlc patch?
21:01:58 <peter1138> Yeah
21:02:14 <andythenorth> oof FIRS isn't 32bpp πŸ˜›
21:02:32 <peter1138> I know. But it would be useful to confirm it doesn't break your build process :)
21:06:28 *** kuhnovic has joined #openttd
21:06:28 <kuhnovic> talltyler: Late reply. I have quite some stuff going on this weekend but I might be able to free up some time πŸ™‚
21:07:51 *** Wormnest has joined #openttd
21:09:13 *** bigyihsuan has joined #openttd
21:09:13 <bigyihsuan> you know what would be great for the scenario editor? being able to manually place a river starting from a given point
21:09:13 <talltyler> kuhnovic: Here’s the event:
21:09:21 <talltyler> Hope to see you there! πŸ˜„
21:10:41 <xarick> I wanna test it with AIs
21:14:19 <_glx_> you can build the PR or use the available build
21:15:20 <DorpsGek> [OpenTTD/OpenTTD] 2TallTyler updated pull request #11428: Feature: Setting to control calendar progress speed
21:15:42 <DorpsGek> [OpenTTD/nml] andythenorth commented on pull request #314: Change: Allow creating 32bpp-only NewGRFs
21:16:35 <talltyler>
21:16:42 <andythenorth> oooooo
21:16:45 <talltyler> Ready for review πŸ˜‰
21:17:21 <andythenorth> prior PR to move terragen settings to 'advanced'? πŸ˜›
21:17:34 <andythenorth> with a subheading "may be confusing"? πŸ˜›
21:18:07 <talltyler> Terragen settings got moved a while ago?
21:18:19 <talltyler> Or do you mean Variety distribution and Smoothness?
21:18:22 <andythenorth> I mean 'Variety' and 'Smoothness' yes
21:18:22 <_glx_> button is weird
21:18:40 <talltyler> It's boolean, and I didn't want a drop-down with two items
21:19:03 <_glx_> oh freeform style
21:19:15 <andythenorth> _zephyris: am enjoying the Toyland sprite, shades of Zool, or Virus!
21:19:31 <andythenorth>
21:19:45 <talltyler> andythenorth: A separate project, is that all of these input fields support tooltips but almost all are STR_NULL. An easy thing to fix πŸ™‚
21:20:04 <talltyler> Explanation might help the "may be confusing" part
21:20:25 <truebrain> Preview landscape when?
21:22:07 <peter1138[d]> Zarch!
21:22:10 <peter1138[d]>
21:22:20 <_glx_> so if my understanding is correct, WITH_ASSERT has actually no real effect for macos release builds
21:22:48 <andythenorth>
21:22:48 <andythenorth> was it grf docks?
21:23:23 <talltyler> andythenorth: I expect you in the pathfinder test game to show us how boats are done πŸ˜„
21:24:02 <andythenorth> oof family birthday Saturday πŸ™‚
21:24:04 <talltyler> It is all boats, in fact. Trains, road vehicles, and aircraft are disabled
21:24:10 <andythenorth> add Sam πŸ˜›
21:24:13 <andythenorth> nobody will use it but eh
21:24:25 <andythenorth> did we port JGR's ship patch yet?
21:24:27 <talltyler> Sam is included, yes πŸ˜„
21:24:27 <andythenorth> multi-hold
21:24:34 <peter1138> Hmm, will BASE_DIR search other directories...
21:24:37 <andythenorth> there is a port of Sam for JGRPP
21:24:46 <andythenorth> I didn't release it yet πŸ˜›
21:24:53 <andythenorth> JGR-specific grfs eh
21:25:10 <talltyler> I'm not a fan of that pattern but eh
21:25:14 <peter1138> No, Good :)
21:26:00 *** gelignite has quit IRC (Quit: Stay safe!)
21:26:26 <_glx_> talltyler: road vehicles might be useful for last leg
21:26:38 <andythenorth> canals FTW
21:26:38 <talltyler> That's what canals are for πŸ˜‰
21:26:47 <_glx_> ah true
21:26:50 <andythenorth> it's better to lower land usually to sea level
21:26:56 <andythenorth> canals look bad and have no docks
21:27:02 <_glx_> and now we should be able to see the slopes
21:27:09 <andythenorth>
21:28:30 <talltyler> I do have a couple of useless road vehicles (capacity 1) enabled so we can station spread into towns for passenger collection, if needed
21:29:01 <peter1138> Is that just to make it look like you aren't station spreading?
21:29:54 <andythenorth> 'station spread limit 64' FTW
21:29:57 <_glx_> station spread with docks
21:30:09 <andythenorth>
21:30:09 <andythenorth> boat avoidance?
21:30:11 <_glx_> it's expensive but doable
21:30:50 <_glx_> you get cargo teleport in bonus
21:33:41 <_glx_> oh and that could test pathfinding as you could have the same dock on 2 separate water sections
21:39:15 <andythenorth> with the vanilla pathfinder, peninsulas and isthmus can really confuse it
21:39:27 <andythenorth> it's not easy to trigger but I've seen it multiple times
21:45:46 *** nielsm has quit IRC (Ping timeout: 480 seconds)
21:51:25 <peter1138[d]> andythenorth: Looks like NewGRF docks aren't needed.
21:51:55 <andythenorth> I guess the limit of one type per map is .... a limit πŸ˜›
21:53:04 <_glx_> a dock not requiring slope could be nice
21:53:50 <andythenorth> also corner slope docks πŸ™‚
21:54:24 <andythenorth> there are 6 separate docks hidden in this
21:54:28 <andythenorth>
21:54:42 <_glx_> kind of land check in the spec
21:54:43 <andythenorth> objects do a lot πŸ˜›
21:55:35 <wensimehrp> peter1138[d]: A font selector is nice, but I think that adding a function to allow players to provide their own text examples would be better.
22:28:07 *** HerzogDeXtEr has quit IRC (Read error: Connection reset by peer)
22:29:04 *** Wormnest has quit IRC (Ping timeout: 480 seconds)
22:38:56 *** Wolf01 has quit IRC (Quit: Once again the world is quick to bury me.)
22:46:47 <DorpsGek> [OpenTTD/OpenTTD] 2TallTyler opened pull request #11581: Add: Improve World Generation GUI tooltips
22:54:01 <DorpsGek> [OpenTTD/OpenTTD] 2TallTyler commented on pull request #10606: Feature: Setting to scale cargo production of towns and industries
22:54:39 <DorpsGek> [OpenTTD/OpenTTD] 2TallTyler updated pull request #10606: Feature: Setting to scale cargo production of towns and industries
22:56:10 *** Wormnest has joined #openttd
22:59:46 <DorpsGek> [OpenTTD/OpenTTD] PeterN approved pull request #11581: Add: Improve World Generation GUI tooltips
23:04:40 <DorpsGek> [OpenTTD/OpenTTD] glx22 commented on pull request #11580: Codechange: Replace pointer to Sprite array with reference to SpriteCollection.
23:06:06 <talltyler> 4 annotations found on #11428, but I sure can’t see them in the code view (and none of the build actions are complaining about them)
23:18:51 *** keikoz has quit IRC (Ping timeout: 480 seconds)
23:20:37 <xarick> `AirportGetNearestTown(as, tile, it, dist);`
23:20:37 <xarick> found another bug here
23:21:32 <xarick> if the town tile is inside the airport, the distance reported is not 0
23:24:23 <xarick> if the airport is super gigantic big, the perimeter of the airport might be closest to a town outside the perimeter than the one inside
23:25:07 *** Eddi|zuHause2 is now known as Eddi|zuHause
23:25:15 <Eddi|zuHause> there probably is a maximum size
23:26:07 <truebrain> Finding hypothetical bugs ... also a way to spend your day πŸ˜›
23:27:12 <Eddi|zuHause> we can probably conjure up more pathological cases if we consider non-rectangular airports
23:27:42 <truebrain> A 4096x4096 airport when?
23:27:56 <Eddi|zuHause> right after state machines *cough* :p
23:28:37 <xarick> what is the minimum distance between towns?
23:28:42 <truebrain> Ah, the fictive state machines for airports!
23:29:12 <xarick> gonna try to reproduce this
23:33:10 <xarick> it's 20 tiles
23:33:19 <xarick> so it's safe
23:33:28 <xarick> biggest airport right now is 9x11
23:35:32 <_glx_> talltyler: 5 actually
23:36:02 <DorpsGek> [OpenTTD/OpenTTD] PeterN updated pull request #11580: Codechange: Replace pointer to Sprite array with reference to SpriteCollection.
23:36:02 <_glx_> in a generated file
23:36:36 <_glx_> so somewhere in a .ini
23:37:57 <peter1138> Airports have state machines :D
23:38:13 <xarick> there may be something else that could end up bugged -> the noise level reported might be different, must test
23:38:16 <peter1138> The layout is a bit... meh though.
23:39:25 <DorpsGek> [OpenTTD/OpenTTD] glx22 commented on pull request #11428: Feature: Setting to control calendar progress speed
23:41:50 <DorpsGek> [OpenTTD/OpenTTD] glx22 commented on pull request #11428: Feature: Setting to control calendar progress speed
23:42:46 <Eddi|zuHause> xarick: there's not really much of the problem if the distance is "wrong", it just needs to be the same on construction and destruction.
23:47:28 <xarick>
23:47:28 <xarick> okay, it's fine too. that inner area without signs report a noise increase in town of 25, and signs report 24. There is no 24 being reported when the town is inside the airport
23:47:41 *** goddess_ishtar has joined #openttd
23:47:41 <goddess_ishtar> are "BAD FEATURES" actually, yknow, *bad* (and thus should be avoided) or just divisive?
23:48:52 <peter1138> xarick, remind me how you place an airport on top of a town.
23:49:09 <DorpsGek> [OpenTTD/OpenTTD] 2TallTyler updated pull request #11428: Feature: Setting to control calendar progress speed
23:50:07 <talltyler> Now they all have the same `new_value` parameter, hopefully that fixes it
23:50:27 <_glx_> do you really need it in both files ?
23:51:10 <xarick> the signs are placed for the northest tile of the airport only
23:53:07 <_glx_> talltyler: it doesn't <>
23:58:13 <xarick> xarick: this table tells me I should be worried
23:59:40 <xarick> that noise 25: (7) (11) (15) (19), i still fail to decipher it