Times are UTC Toggle Colours
00:01:59 *** Vadtec has quit IRC 00:02:04 *** Vadtec has joined #openttd 00:02:57 *** sla_ro|master has quit IRC 00:05:15 *** Artea has quit IRC 00:06:16 *** Artea has joined #openttd 00:08:41 *** k-man has quit IRC 00:09:04 *** k-man has joined #openttd 00:28:13 *** Venemo has quit IRC 00:41:59 *** berndj has quit IRC 00:42:21 *** milek7 has quit IRC 00:42:21 *** milek7 has joined #openttd 00:43:04 *** berndj has joined #openttd 00:46:21 *** Timberwolf has quit IRC 00:46:27 *** Timberwolf has joined #openttd 00:56:50 *** mindlesstux has quit IRC 00:57:02 *** mindlesstux has joined #openttd 01:04:02 <DorpsGek> [OpenTTD/OpenTTD] PeterN opened pull request #8829: Fix: Scale PIP-padding the same as regular padding. https://git.io/JqLVh 01:04:50 *** innocenat_ has quit IRC 01:05:01 *** innocenat_ has joined #openttd 01:09:38 *** fnutt has quit IRC 01:09:47 *** fnutt has joined #openttd 01:11:10 <DorpsGek> [OpenTTD/OpenTTD] PeterN commented on pull request #8829: Fix: Scale PIP-padding the same as regular padding. https://git.io/JqLwW 01:20:09 *** Exec has quit IRC 01:20:13 *** Exec has joined #openttd 01:47:46 *** EmeraldSnorlax[m] has quit IRC 01:47:50 *** EmeraldSnorlax[m] has joined #openttd 01:55:53 *** gnu_jj has quit IRC 01:55:56 *** gnu_jj has joined #openttd 02:20:50 *** y2kboy23 has quit IRC 02:21:03 *** y2kboy23 has joined #openttd 02:31:51 *** Webster has joined #openttd 02:31:54 *** Hazzard has joined #openttd 02:32:09 *** SmatZ has quit IRC 02:32:36 *** SmatZ has joined #openttd 02:32:41 *** Terkhen has quit IRC 02:32:57 *** V453000 has quit IRC 02:33:06 *** Terkhen has joined #openttd 02:33:06 *** ChanServ sets mode: +o Terkhen 02:33:13 *** XeryusTC has quit IRC 02:33:29 *** Yexo has quit IRC 02:33:36 *** V453000 has joined #openttd 02:33:37 *** XeryusTC has joined #openttd 02:33:45 *** Ammler has quit IRC 02:34:01 *** Osai has quit IRC 02:34:06 *** Yexo has joined #openttd 02:34:06 *** Ammler has joined #openttd 02:34:33 *** fonsinchen has quit IRC 02:34:36 *** Osai has joined #openttd 02:35:06 *** fonsinchen has joined #openttd 02:39:37 *** m1cr0man has quit IRC 02:40:02 *** m1cr0man has joined #openttd 02:40:22 *** Wormnest has quit IRC 02:40:34 *** crem2 has quit IRC 02:40:46 *** crem2 has joined #openttd 02:44:50 *** greeter has quit IRC 02:45:23 *** greeter has joined #openttd 02:51:14 *** gregdek has quit IRC 02:51:17 *** gregdek has joined #openttd 02:53:54 *** dvim has quit IRC 02:54:06 *** dvim has joined #openttd 03:24:53 *** Flygon has joined #openttd 03:36:28 *** dwfreed has quit IRC 03:36:29 *** dwfreed has joined #openttd 03:52:18 <DorpsGek> [OpenTTD/OpenTTD] perezdidac commented on issue #8779: Add: Display referencing NewGRF set when query is used on rail, road and tram tiles https://git.io/JtpCk 03:53:45 *** ST2 has quit IRC 03:53:49 *** ST2 has joined #openttd 03:56:57 *** peter1138 has quit IRC 03:57:12 *** peter1138 has joined #openttd 03:57:12 *** ChanServ sets mode: +o peter1138 03:57:30 *** debdog has joined #openttd 04:00:52 *** D-HUND has quit IRC 04:14:01 *** patrick[m]2 has quit IRC 04:14:06 *** patrick[m]2 has joined #openttd 04:54:17 *** jinks has quit IRC 04:54:22 *** jinks has joined #openttd 04:54:49 *** karl[m]5 has quit IRC 04:54:55 *** karl[m]5 has joined #openttd 05:09:40 *** didac has joined #openttd 05:47:05 *** murr4y has quit IRC 05:47:19 *** murr4y has joined #openttd 06:38:08 *** didac has quit IRC 06:50:49 *** grag[m] has quit IRC 06:51:00 *** grag[m] has joined #openttd 06:55:13 *** JamesRoss[m] has quit IRC 06:55:17 *** JamesRoss[m] has joined #openttd 06:59:13 *** jgx has quit IRC 06:59:35 *** jgx has joined #openttd 07:01:22 *** andythenorth has joined #openttd 07:25:13 *** colde has quit IRC 07:25:16 *** colde has joined #openttd 07:25:20 *** sla_ro|master has joined #openttd 07:36:09 *** twpol has quit IRC 07:36:20 *** twpol has joined #openttd 07:42:15 *** HerzogDeXtEr has joined #openttd 07:50:41 *** heffer has quit IRC 07:50:43 *** heffer has joined #openttd 07:59:05 *** twom[m] has quit IRC 07:59:10 *** twom[m] has joined #openttd 08:01:21 *** skrzyp has quit IRC 08:01:35 *** skrzyp has joined #openttd 08:05:23 <andythenorth> Horse 2.21.1 08:05:25 <andythenorth> nice number 08:11:21 *** reldred has quit IRC 08:11:33 *** reldred has joined #openttd 08:14:02 *** snail_UES_ has quit IRC 08:25:05 *** Wolf01 has joined #openttd 08:28:36 <DorpsGek> [OpenTTD/OpenTTD] glx22 closed issue #8779: Add: Display referencing NewGRF set when query is used on rail, road and tram tiles https://git.io/JtpCk 08:28:39 <DorpsGek> [OpenTTD/OpenTTD] glx22 reopened issue #8779: Add: Display referencing NewGRF set when query is used on rail, road and tram tiles https://git.io/JtpCk 08:33:58 *** Wolf01 is now known as Guest1078 08:34:00 *** Wolf01 has joined #openttd 08:38:49 *** azubieta6 has quit IRC 08:39:13 *** azubieta6 has joined #openttd 08:40:08 *** Guest1078 has quit IRC 08:53:05 *** TrueBrain has quit IRC 08:53:09 *** TrueBrain has joined #openttd 09:03:21 *** natalie[m] has quit IRC 09:03:25 *** natalie[m] has joined #openttd 09:03:53 *** nolep[m] has quit IRC 09:03:59 *** nolep[m] has joined #openttd 09:21:00 <DorpsGek> [OpenTTD/OpenTTD] LordAro approved pull request #8813: Add display refresh rate game option https://git.io/JqtUO 09:21:42 <DorpsGek> [OpenTTD/OpenTTD] LordAro approved pull request #8829: Fix: Scale PIP-padding the same as regular padding. https://git.io/JqtUD 09:22:33 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain commented on pull request #8813: Add display refresh rate game option https://git.io/JqtU5 09:22:56 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain merged pull request #8813: Add display refresh rate game option https://git.io/JqTS1 09:24:17 <LordAro> TrueBrain: i tried to approve #8824, but GH won't let me 09:24:19 <LordAro> it's erroring 09:24:42 <DorpsGek> [OpenTTD/OpenTTD] LordAro approved pull request #8824: Codechange: remove special strings for language and resolutions https://git.io/JqtTO 09:24:48 <LordAro> oh, there it goes 09:24:52 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain dismissed a review for pull request #8824: Codechange: remove special strings for language and resolutions https://git.io/JqtTO 09:24:53 <TrueBrain> it needs a rebase anyway :) 09:24:56 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain updated pull request #8824: Codechange: remove special strings for language and resolutions https://git.io/JqLLW 09:24:58 <TrueBrain> quickest dismiss evah! 09:25:07 <LordAro> some weirdness 09:25:28 <TrueBrain> hmm, did not get an email about your last comment 09:25:29 <TrueBrain> weird 09:25:31 <TrueBrain> let me add a comment 09:26:52 <LordAro> :) 09:27:14 <TrueBrain> I am not really sure why we do own_name for the current language 09:27:17 <TrueBrain> I understood it had to do with ??? 09:27:21 <TrueBrain> but I don't really understand :D 09:27:53 <LordAro> something to do with sprite fonts? 09:28:05 <TrueBrain> which is why I understand we do "name" 09:28:10 <TrueBrain> as we can render most of them fine 09:28:14 <TrueBrain> (most, not all :P) 09:31:21 <TrueBrain> dates back to r1 09:31:36 <TrueBrain> so a "this has always been like this" doesn't work :P 09:33:53 <andythenorth> dunno why I thought this should be shared into an open source community :P 09:33:54 <andythenorth> just found it 09:33:55 <andythenorth> https://en.wikipedia.org/wiki/Sutor,_ne_ultra_crepidam 09:34:14 <TrueBrain> I guess we use international names so in the dropdown you can always see all languages 09:34:21 <TrueBrain> it is only when you click some, it becomes all ??? :D 09:34:26 <TrueBrain> not sure that is really pretty :P 09:38:06 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain updated pull request #8824: Codechange: remove special strings for language and resolutions https://git.io/JqLLW 09:38:07 <TrueBrain> LordAro: I did my best :D 09:38:20 *** andythenorth has quit IRC 09:39:21 <DorpsGek> [OpenTTD/OpenTTD] LordAro approved pull request #8824: Codechange: remove special strings for language and resolutions https://git.io/Jqtk6 09:40:07 <LordAro> TrueBrain: i assigned #8828 to you, because i'm not sure anyone else is qualified enough to be able to review it :p 09:40:20 <LordAro> seems a bit like adding more hacks on other hacks 09:40:27 <LordAro> but i suspect the proper fix is a bit more involved 09:40:37 <TrueBrain> yeah, I had the same feeling 09:40:46 <TrueBrain> and the proper solution is not that difficult, but it won't be done for 1.11 09:41:08 <TrueBrain> so I was balancing: do we want to fix this for 1.11, or just leave it as a known bug, and fix it properly (either way) in 1.12 09:41:24 <TrueBrain> basically, this whole modal-window system has to be kicked out :P 09:41:32 <TrueBrain> it is completely garbage; and I can say that, as I wrote it 09:41:50 <TrueBrain> one of those "it is not possible to update the GUI during mapgen" ... "hold my beer", situations 09:42:05 <LordAro> :) 09:42:07 <TrueBrain> but oof .. I was young and wrote shitty code :P 09:42:32 <TrueBrain> so what do you prefer? It seems rare that people hit the bug 09:43:08 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain merged pull request #8829: Fix: Scale PIP-padding the same as regular padding. https://git.io/JqLVh 09:43:28 <LordAro> leaving a known crashing bug in place seems bad 09:43:34 <LordAro> especially when the fix is so "simple" 09:43:43 <LordAro> (in terms of effort) 09:43:59 <TrueBrain> it could introduce other bugs, ofc :) 09:44:06 <LordAro> possible :) 09:44:07 <TrueBrain> and this bug has been in the game for 10+ years 09:44:08 <TrueBrain> reported once 09:44:35 *** azubieta6 has quit IRC 09:44:35 *** Wolf01 has quit IRC 09:44:35 *** jgx has quit IRC 09:44:35 *** greeter has quit IRC 09:44:35 *** y2kboy23 has quit IRC 09:44:35 *** innocenat_ has quit IRC 09:44:35 *** Gustavo6046 has quit IRC 09:44:35 *** supermop_Home has quit IRC 09:44:35 *** Smedles has quit IRC 09:44:35 *** daspork has quit IRC 09:44:38 <LordAro> oh, i didn't realise it's that old 09:44:48 *** Gustavo6046 has joined #openttd 09:44:48 <LordAro> thought it was introduced with all your recent changes :p 09:44:48 *** innocenat_ has joined #openttd 09:44:48 *** Smedles has joined #openttd 09:44:56 *** jgx has joined #openttd 09:44:59 *** azubieta6 has joined #openttd 09:45:07 *** daspork has joined #openttd 09:45:08 *** greeter has joined #openttd 09:45:09 *** Wolf01 has joined #openttd 09:45:10 <TrueBrain> well, let me confirm my statement there :D 09:45:17 *** y2kboy23 has joined #openttd 09:45:19 *** Wuzzy has quit IRC 09:46:06 <TrueBrain> I don't nearly have enough NewGRFs to close the window in time :D 09:49:46 <Wolf01> Go to content download, select all, ..., profit :P 09:51:02 <LordAro> just use the console command! 09:51:03 <LordAro> oh wait 09:52:58 <TrueBrain> found a bug while doing that 09:53:11 <TrueBrain> Downloading 1444 file(s) (-1286959301 bytes) 09:53:16 <TrueBrain> pretty sure that doens't work like that 09:53:43 <Wolf01> It should scale with size :) 09:54:01 <TrueBrain> on a positive side, it is nearly impossible to select 1444 files in 1.11 09:54:09 <TrueBrain> so it is unlikely anyone can reproduce it :P 09:55:12 <Wolf01> Just go to the 32bpp fullHD 2048x2048 text... wrong game... 09:57:50 <Wolf01> I don't remember which ones, but I'm sure that with 3-4 grf sets you can get about 1GB of download 09:58:01 <TrueBrain> zBase 09:58:02 <TrueBrain> abase 09:58:03 <TrueBrain> :P 09:58:35 <LordAro> all of V's stuff 09:58:37 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain merged pull request #8824: Codechange: remove special strings for language and resolutions https://git.io/JqLLW 09:58:47 <TrueBrain> townnames btw still use the special string hack 09:58:53 <TrueBrain> so I left something to do for who-ever comes next 09:58:54 <Wolf01> Yeah, V's stuff is crazy 10:00:05 <TrueBrain> 400 NewGRF 10:00:08 <TrueBrain> scanned in a second 10:00:37 <TrueBrain> people tell me it takes a long time, but I have a hard time reproducing that :P 10:00:50 <Wolf01> Wtf, I have a ssd and still need about 5 seconds to scan 30 grfs 10:01:09 <LordAro> that seems high 10:01:18 <TrueBrain> and this is even with a debug build .. 10:01:25 <Wolf01> Ok, maybe 3 seconds, not one for sure 10:02:01 *** khavik[m] has quit IRC 10:02:12 <Wolf01> Could it be related to the grfs themselves? 10:02:16 <TrueBrain> by the time I see the window, it is gone :P 10:02:48 <Wolf01> I'll tell you where it takes more time, I'm sure it's always the same one 10:03:18 <TrueBrain> it takes longer on 1.11 10:03:28 <TrueBrain> owh, 1.9 is not a debug build 10:03:33 <TrueBrain> (I was testing with 1.9, locally) 10:03:43 <FLHerne> TrueBrain: I should repair my old laptop and send it to you, everything would get faster :p 10:03:50 <TrueBrain> anyway .. I cannot reproduce the problem, neither on 1.11 .. so it is one of those "click at the right moment" shit :P 10:03:55 <LordAro> can't really tell with my random collection of 57 grfs 10:04:00 <Wolf01> 2 seconds (1.10, release), always on the last one added 10:04:06 <LordAro> does appear to be scanning AI tars 3 times though, which is a bit odd 10:04:22 <TrueBrain> it scans many things multiple times :P 10:05:00 <Eddi|zuHause> grf scan on startup takes about 7 seconds here 10:05:34 <TrueBrain> guess my SSD is more decent :P :P :P 10:05:42 <TrueBrain> okay, let me try a debug build on 1.9 .. 10:05:45 <Eddi|zuHause> and almost instant the second time 10:05:45 <TrueBrain> maybe that is slow enough 10:05:54 <TrueBrain> kernel caching ftw Eddi|zuHause :) 10:06:49 <Eddi|zuHause> well, let's call it "1 second", but i saw like 2 frames of the window appearing at 0% and 50% 10:07:07 <TrueBrain> it tries to do a frame every 100ms, I believe 10:09:39 <TrueBrain> so far, between 1.9 and 1.11, I could reproduce the issue once 10:09:43 <TrueBrain> I started OpenTTD 100 times 10:13:55 *** khavik[m] has joined #openttd 10:15:21 *** iarp[m] has quit IRC 10:18:16 *** skrzyp has quit IRC 10:18:29 *** skrzyp has joined #openttd 10:18:59 *** iarp[m] has joined #openttd 10:29:21 *** NGC3982 has quit IRC 10:29:33 *** NGC3982 has joined #openttd 10:36:17 <TrueBrain> LordAro: I have a really hard time reproducing it, but why I assume it was already an issue before 1.11, is because nothing really changed for the NewGRFScanner thread 10:36:30 <TrueBrain> the only real change I can think of, that we now use std::chrono to control when to redraw, instead of realtime_tick 10:36:39 <TrueBrain> the latter was .. unpredictable during scanning 10:36:46 <TrueBrain> so I can imagine it happens easier in 1.11 10:37:08 <TrueBrain> but not having a good way to reproduce this, makes it hard to validate that :D 10:38:09 *** argoneus has quit IRC 10:38:15 *** argoneus has joined #openttd 10:38:32 <LordAro> add artificial delays to newgrf scanning? 10:38:36 <TrueBrain> I tried 10:38:55 <TrueBrain> but it is very timing depending, from what I can tell 10:39:09 <TrueBrain> when the main thread is already shut down, and the newgrfscanner thread decides to update the screen 10:39:38 <TrueBrain> I will see what it takes to just remove the current modal system 10:39:53 *** floyza[m] has quit IRC 10:39:55 *** floyza[m] has joined #openttd 10:42:44 <_dp_> TrueBrain, put your openttd folder on a floppy disk :p 10:42:57 <TrueBrain> I did consider mounting a low I/O drive, yes 10:43:02 <Wolf01> _dp_ lol 10:43:08 <TrueBrain> _dp_: can you see if you can reproduce your problem with 1.9 or 1.10 btw? 10:43:40 <TrueBrain> as you seemly can reliable reproduce this on master :D 10:43:43 <DorpsGek> [OpenTTD/team] Anolitt opened issue #158: [nb_NO] Translator access request https://git.io/Jqt35 10:44:50 *** JGR has joined #openttd 10:44:53 <_dp_> well, I'm on a different pc now 10:45:01 <_dp_> but 1.10.3 fails as well 10:45:09 <_dp_> with a different assert though 10:45:17 <TrueBrain> yeah, you can also hit the reading part of AddFile :) 10:45:32 <TrueBrain> this is such dirty code, it is incredible :P 10:45:40 <TrueBrain> tnx _dp_ , at least that means my sanity is still intact :) 10:48:21 <TrueBrain> hmm .. so much code to also support the case people run without threads 10:48:23 <TrueBrain> silly :) 10:49:27 <_dp_> 1.9.3 doesn't seem to be crashing 10:50:09 <TrueBrain> awhhhh, how cute, we have code to validate if a mutex works or not 10:50:11 <_dp_> though now it's all cached and I don't have too many grfs here so have some trouble reproing it as well 10:50:14 <TrueBrain> but only for the modal window thread 10:50:20 <TrueBrain> other places just blindly assume mutexes work :D 10:50:32 <TrueBrain> _dp_: tnx, that helps :) 10:50:45 <TrueBrain> at least it is what I assumed it was (looking at the traceback and JGR's fix) 10:51:26 <TrueBrain> okay, so now we have the gameloop-threaded, which heavily depend on mutex, unconditionally 10:51:36 <TrueBrain> but modal progress can gracefully fall back :P 10:51:41 <TrueBrain> something is no longer adding up :D :D 10:52:16 <JGR> The scan thread is detached, not joinable. When the main threads exit, lots of destructors/etc are run and the rug is pulled out from under the scan thread. It's not really about drawing. 10:52:38 <JGR> I can reproduce the bug every time if I run with AddressSanitizer 10:53:15 <TrueBrain> yeah, that the NewGRFScanner thread is not properly joined on exit is a bit odd :P 10:53:22 <TrueBrain> especially as the GenerateWorld one is 10:54:18 <TrueBrain> (and one clearly copied shit from the other) 10:55:30 *** gelignite has joined #openttd 11:04:15 <TrueBrain> we should run AIs when uploading to BaNaNaS 11:04:21 <TrueBrain> these AIs that just fail to be scanned are weird :P 11:06:13 <TrueBrain> does NewGRFScanner influence the game-state? 11:13:25 <TrueBrain> I think with the gameloop-thread change, during NewGRF scanning, the game on the background just continues :D 11:13:36 <TrueBrain> pretty sure it didn't before 11:14:22 <JGR> It only populates _all_grfs 11:15:05 <TrueBrain> yeah, before the gameloop was threaded, it blocked every frame till the new NewGRF scanner update 11:15:12 <TrueBrain> so it was still ticking, but reallllyyyyy sllloowwwwlllyyyy 11:15:18 <TrueBrain> now the game just keeps running on the background 11:16:45 <TrueBrain> JGR: tnx, that was also what I found. But I learn with these things that confirmation is rather important :D 11:19:40 <TrueBrain> ah, no, the game-tick is running, but the StateGameLoop is not 11:23:32 *** Samu has joined #openttd 11:33:44 <JGR> On the scanning AI tars 3 times issue mentioned above, you can remove the superfluous rescans from AI::Uninitialize and Game::Uninitialize. I have a commit for that in my branch. 11:34:00 <TrueBrain> 3 times? lol :D 11:34:08 <TrueBrain> maybe it just wants to be sure :D 11:34:18 <LordAro> why does it rescan when uninitialising, i wonder 11:39:26 <JGR> Git blame suggests that both cases were added by a 'truebrain', we could ask the author? :P 11:39:43 <TrueBrain> the initial NoAI commit, or any specific commit? 11:40:33 *** patrick[m]2 has quit IRC 11:40:35 *** patrick[m]2 has joined #openttd 11:40:42 *** WormnestAndroid has quit IRC 11:40:55 *** WormnestAndroid has joined #openttd 11:41:12 <TrueBrain> right, lunch first, but I think we no longer need the NewGRF Scan thread 11:41:16 <TrueBrain> and that we can just do it in the game-thread 11:41:17 <JGR> The initial NoAI commit for AI::Uninitialize, Game::Uninitialize was in c99950c215/SVN 23606 11:42:33 <TrueBrain> tnx JGR , will check it out after this modal-progress stuff 11:42:43 <TrueBrain> I vague remember there were some weird quirks with AIs 11:43:25 <JGR> I've had both of those removed in my branch for 18 months and no-one has noticed or complained yet 11:43:41 <TrueBrain> it might have been to make developing easier 11:43:54 *** WormnestAndroid has quit IRC 11:44:08 *** WormnestAndroid has joined #openttd 11:44:26 <TrueBrain> pretty sure that would make it a terrible place btw 11:44:39 <TrueBrain> but I remember something there, that people wanted to keep OpenTTD running and change their AI/GS 11:44:42 <TrueBrain> and that OpenTTD picked it up 11:46:01 <TrueBrain> but my memory might be failing on me .. 11:46:05 <LordAro> that's what rescan_ai is for, no? 11:46:07 <TrueBrain> so yeah, I take the "18 months no complaints" :P 11:46:14 <TrueBrain> LordAro: depends on the timeline which was first :D 11:46:17 <LordAro> true :) 11:46:24 <TrueBrain> I would just remove the Rescans 11:47:23 <JGR> https://github.com/JGRennison/OpenTTD-patches/commit/158f063a383ed6033e3dfd29af59f5565da7848d I can PR that later if that'd be useful? 11:48:01 <TrueBrain> honestly, the original author should have done a better job at explaining what was going on 11:48:04 <TrueBrain> so I am fine with that as PR :D 11:49:19 <TrueBrain> lol .... I was trying to figure out why I didn't see the NewGRF window in my new code .. turns out, the MainLoop of the videodriver is called AFTER NewGRF scan is done 11:50:46 <TrueBrain> ugh, lunch first, why do I keep forgetting 12:02:17 *** phil[m] has quit IRC 12:02:24 *** phil[m] has joined #openttd 12:08:01 *** murr4y has quit IRC 12:08:14 *** murr4y has joined #openttd 12:10:38 <TrueBrain> ScanNewGRFFiles(_request_newgrf_scan != (NewGRFScanCallback *)1 ? _request_newgrf_scan : nullptr); 12:10:44 <TrueBrain> writing ugly code like there is no tomorroooowwwwww 12:13:45 *** hamstonkid[m] has quit IRC 12:13:48 *** hamstonkid[m] has joined #openttd 12:14:25 <TrueBrain> ignoring the ugly way I recorded this, what do you think about this: https://user-images.githubusercontent.com/1663690/110468951-493e2480-80d9-11eb-919a-b7c487b4a976.mp4 12:14:50 <TrueBrain> I drastically slowed down how long scanning takes btw, to give a more dramatic effect here :P 12:18:21 *** spnda has joined #openttd 12:23:22 *** gelignite has quit IRC 12:29:16 <JGR> Looks fine, presumably you'd still want to allow more than one GRF scanned per drawing frame though 12:29:26 <JGR> Is multithreading also still of interest? 12:30:42 <TrueBrain> it now updates the display at 60fps 12:30:58 <TrueBrain> how ever many it can updated in that time, it is allowed to update 12:31:23 <TrueBrain> (basically, only when the draw-thread requests access to the game-state, the GRF scanner gives it after the new GRF it scanned) 12:31:41 <TrueBrain> multithreading, I think that would help for many people; but I assume you did that in something like a pool of workers? 12:37:36 <TrueBrain> world generation also feels so much better this way :D 12:38:52 *** Wuzzy has joined #openttd 12:39:53 <JGR> Yes, I offloaded the MD5 calculation part to a variable size thread pool. Effectively it's just a single producer multi consumer queue with a limited backlog. 12:40:04 <TrueBrain> yeah, we can use that in more places 12:40:10 <TrueBrain> so if by any chance you made that generic: fuck yes 12:40:24 <JGR> https://github.com/JGRennison/OpenTTD-patches/commit/66b32df7cc11a73b5971f9e6aecc69259051bd9a 12:41:01 <JGR> Sadly it's not generic at present 12:41:03 <TrueBrain> okay, so ideally we want to make an abstraction there; but that can be done later :) 12:41:16 <TrueBrain> for the viewport, sorting of stuff etc, could also really use a worker pool :) 12:41:24 <TrueBrain> those are completely independent calculations 12:41:39 <TrueBrain> but that is really 1.12 work :D 12:42:54 <TrueBrain> wow, rivers take for ever to generate on a 4k map :P 12:46:50 *** WormnestAndroid has quit IRC 12:48:41 *** WormnestAndroid has joined #openttd 12:49:20 <TrueBrain> okay, genworld is a lot slower with 60fps drawing during generation :P Mainly the trees 12:49:24 <TrueBrain> always those pesky trees 12:50:30 <TrueBrain> it does, however, look amazing 12:53:23 <TrueBrain> https://user-images.githubusercontent.com/1663690/110473423-cb7d1780-80de-11eb-947c-d22d4344ea0c.mp4 12:53:33 *** WormnestAndroid has quit IRC 12:53:46 *** WormnestAndroid has joined #openttd 12:54:00 <Wolf01> Why did I read "ghostbustercontent" in the url? 12:54:55 <TrueBrain> ah, fixed the speed issue 12:55:01 <TrueBrain> just .. don't mark the whole screen dirty 12:55:30 <Wolf01> So the map generation was there but just not showing? 12:55:41 <TrueBrain> it always was showing it 12:55:50 <TrueBrain> just a lot more laggy than I have now 12:57:42 <Wolf01> Oh ok, I was generating 64x64 maps, it just hanged for seconds when starting a new game then for a frame show the generating world loading bar 12:57:53 <TrueBrain> that is still the case :P 12:57:57 <TrueBrain> now try bigger maps :) 12:58:40 <Wolf01> Yeah, stuttering a lot 12:59:44 <TrueBrain> hmm ... only aborting genworld doesn't work now .. hmmm 12:59:50 <TrueBrain> owh, I know why 13:25:22 <spnda> I like how GitHub suggests me deleting my fork after 8813 was merged.... like ????? 13:28:39 <TrueBrain> for those people who do exactly one change for a project :D 13:28:52 <TrueBrain> hmm .. _dp_ , you know a lot of things on the front of network servers 13:29:05 <TrueBrain> currently, if you do: ./openttd -D -g afilethatodesnotexst.sav 13:29:08 <TrueBrain> it loads a random new game 13:29:13 <TrueBrain> should it not instead just error out? 13:32:54 <LordAro> i'd certainly expect it to error 13:33:05 <LordAro> although... if it's also being used to define "put the savegame here"... 13:33:09 <TrueBrain> it shows an error and loads a random new map, it feels so weird 13:33:17 <TrueBrain> but I will leave it be 13:37:00 <LordAro> also, could parallelising grfscan just be as "simple" as std::for_each(std::execution::par, ...), i wonder? 13:37:20 <LordAro> including fixing all the various data races involved in that, of course 13:37:31 <TrueBrain> can that limit the amount of executions that can be done at one time? 13:37:57 <_dp_> idk what's the usecase for -D -g is 13:38:33 <_dp_> normally you don't load saves on dedicated servers, not when starting it at least 13:38:56 <TrueBrain> okay, in that case I am really not going to touch it :D 13:38:59 <TrueBrain> tnx _dp_ 13:40:29 <_dp_> I guess a plus point in making a random game is that you still have a running server that you can connect to and adjust 13:40:49 <_dp_> like if you start it on boot or smth so you don't need to go to your vps 13:41:01 <_dp_> but then again, you wouldn't run it with -g in that case 13:41:51 <_dp_> for citymania I added a config parameter to load saves 13:42:35 <_dp_> but I guess citymania is the only server that can actively switch game modes 13:44:45 <Xaroth> <_dp_> normally you don't load saves on dedicated servers, not when starting it at least <<< How about when your server crashed and you want to continue from the last save? 13:46:26 <Xaroth> without it you'd have to wait for mapgen, then manually load the save 13:46:31 <Xaroth> which sounds a bit... double 13:47:02 <TrueBrain> LordAro: the docs for ::par are not .. really .. clear :P 13:47:51 <_dp_> I mostly think of dedicated servers as ones that run unattended 13:48:04 <_dp_> if admin himself plays it's basically the same as using gui server 13:48:56 <TrueBrain> LordAro: but stackoverflow tells me you cannot limit the amount of threads in those constructs in C++17 13:49:02 <TrueBrain> which would mean it could spawn 1400 threads, in my case 13:49:05 <TrueBrain> not sure that is ideal :D 13:49:08 <_dp_> also servers rarely crash and I definitely wouldn't call it "nomal" :p 13:49:21 <peter1138> Hi 13:49:47 <TrueBrain> seems MSVC states it will do it "correctly" 13:50:33 *** hylshols7qui[m] has quit IRC 13:50:39 *** hylshols7qui[m] has joined #openttd 13:53:17 <LordAro> TrueBrain: mm, it is very "implementation defined" 13:53:27 <TrueBrain> yeah .. that always scares me a bit 13:53:28 <LordAro> i've no idea how it tends to be implemented in practice 13:53:35 <TrueBrain> but we can test that, ofc 13:53:36 <LordAro> or indeed if anyone uses it at all 13:53:48 <TrueBrain> as for sure it is less code :P 13:54:19 <Xaroth> _dp_: s/crash/shut down/ 13:54:55 <Xaroth> i.e. to update openttd version 13:59:06 <LordAro> TrueBrain: https://stackoverflow.com/q/58916068/995325 hmm 13:59:32 <TrueBrain> yeah, that is what I meant with: "but stackoverflow tells me.." :D 13:59:45 <LordAro> oh, i misread that 14:00:55 <_dp_> Xaroth, if I understood it correctly it's only about error handling in case of an incorrect savegame, corect saves should still load fine 14:01:29 <TrueBrain> LordAro: I also didn't link it, so ... yeah ... :P 14:03:11 <_dp_> and for error handling having a dedicated server prioritize startup over correctness is somewhat logical 14:03:12 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain opened pull request #8830: Add: make modal windows update more smooth https://git.io/Jqt93 14:03:23 <TrueBrain> very curious what other people think about ^^ (please test it, please break it) 14:03:59 <TrueBrain> now to see how I can run that Thread Analyzer thingy JGR was doing .. it should have solved a few 14:06:15 <TrueBrain> owh, I have warnings with clang ... 14:06:43 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain updated pull request #8830: Add: make modal windows update more smooth https://git.io/Jqt93 14:06:49 <TrueBrain> not sure if it is an "add" or a "feature" :P 14:12:10 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain commented on issue #8712: Thread safety issues detected by ThreadSanitizer https://git.io/Jt9Pk 14:13:07 <TrueBrain> you can't do InteractiveRandom() in enough places, it seems 14:14:01 *** snail_UES_ has joined #openttd 14:17:14 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain opened pull request #8831: Codechange: only run InteractiveRandom() from the draw-thread https://git.io/JqtH5 14:19:33 <TrueBrain> that leaves _cur_palette and _exit_game .. of which neither should be important, but something to fix another day :) 14:22:52 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain updated pull request #8830: Add: make modal windows update more smooth https://git.io/Jqt93 14:25:03 <TrueBrain> JGR: I went for a simpler solution to #8760, but it might be that it is only possible because of the rework I did for modals .. but I am curious if I am missing anything when I do this: https://github.com/OpenTTD/OpenTTD/pull/8830/commits/e0ad8e6ae8229d4fceb6b5041b690b3762aeeab1 14:27:45 <TrueBrain> we might want to upgrade _exit_game similar to how you did _abort_grf_scan, because ThreadSanitizer complains about it already :P 14:28:01 <peter1138> Jesus why is Thunderbird so SHIT. 14:28:27 <TrueBrain> (As in, complains in current master already) 14:32:41 *** elliot[m] has quit IRC 14:32:43 *** elliot[m] has joined #openttd 14:33:05 *** nielsm has joined #openttd 14:34:24 <TrueBrain> ugh, I keep forgetting I should also write stuff on GitHub, as information on IRC gets lost 14:35:37 *** leward[m] has quit IRC 14:35:39 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain commented on pull request #8828: Fixes for modal progress and NewGRF scan issues https://git.io/Jqt5M 14:35:40 *** leward[m] has joined #openttd 14:35:51 <TrueBrain> seems matrix finally fixed the "everyone drops at once from IRC" problem 14:35:55 <TrueBrain> now they come and go one by one :P 14:52:46 <LordAro> TrueBrain: "Slightly slower NewGRF scanning" how much slower? 15:14:29 <TrueBrain> LordAro: I also mention that :) I couldn't measure it 15:14:36 <TrueBrain> but it has to be slower, as time is spend drawing the frames 15:14:42 <TrueBrain> instead of doing the scan 15:14:54 <LordAro> should probably say that then :p 15:15:00 <TrueBrain> I did, didn't I? 15:15:00 <LordAro> might worry people otherwise 15:15:19 <LordAro> not "but not enough to be measurable" 15:15:33 <TrueBrain> "It does slow down NewGRFScan and GenerateWorld ever so slightly as it spends more time on drawing. But the slowdown is not measureable on my machines (with 700+ NewGRFs / 4kx4k map and a Debug build)." 15:15:47 <LordAro> oh, lol 15:15:51 <LordAro> it's not in the limitations section! 15:15:52 <TrueBrain> reading is hard? :P 15:16:00 <TrueBrain> I assume people read from top to bottom 15:16:04 <TrueBrain> fine I will copy/paste 15:16:49 <TrueBrain> done 15:17:01 <TrueBrain> and to estimate: a frame takes <1ms, so at most 60ms per 1000ms 15:17:13 <TrueBrain> so at most 6% decrease 15:17:23 <TrueBrain> but normally my frames are < 0.05ms 15:17:25 <TrueBrain> so ... yeah 15:18:23 <LordAro> good :) 15:18:26 <TrueBrain> @calc 1060 / 1000 15:18:26 <DorpsGek> TrueBrain: 1.06 15:18:32 <TrueBrain> yeah, 6% .. lol 15:18:34 <TrueBrain> math difficult too :P 15:19:33 <TrueBrain> I might not have found all places to mark the screen as dirty, so some graphical glitches during mapgen are possible 15:22:36 <TrueBrain> yeah, something during tree generation is not fully correct 15:22:51 <TrueBrain> the original code marked the whole screen dirty every time .. now THAT is expensive :P 15:23:02 <TrueBrain> but individual tiles are not always marked dirty correctly 15:23:21 <TrueBrain> so I am sure there will be a few more PRs over the next few months to address those 15:27:26 <TrueBrain> ha, fixed trees :D 15:27:30 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain updated pull request #8830: Add: make modal windows update more smooth https://git.io/Jqt93 15:33:37 <TrueBrain> and that fixes rocks ... 15:33:39 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain updated pull request #8830: Add: make modal windows update more smooth https://git.io/Jqt93 15:33:43 <TrueBrain> now only rivers seem to be weird sometimes 15:36:28 <LordAro> TrueBrain: i assume you've also tested bootstrap? 15:36:36 <TrueBrain> I actually did, yes :) 15:36:40 <TrueBrain> I found a weird bug 15:36:43 <TrueBrain> but it is already in master 15:36:53 <TrueBrain> when you bootstrap, it tells you "OpenGFX" is not found when it continues to load 15:37:35 <LordAro> https://github.com/OpenTTD/OpenTTD/pull/8830/commits/a83031438dd5c44e6de08635167e99f66ab2958b#diff-0b2adae169e4982264517d1b8ffc66bc9ae759e39cb0c3de89883451c8167d1bL239 seems like an odd change that doesn't quite fit with the rest of the changes 15:37:50 <TrueBrain> URL no longer works, sorry :P 15:38:11 <LordAro> :( 15:38:15 <TrueBrain> what was the line of code? 15:38:24 <TrueBrain> or file? 15:39:03 <LordAro> oh, you've done it several times 15:39:10 <LordAro> ScanNewGRFFiles -> RequestNewGRFScan 15:39:22 <TrueBrain> yes, that is the core of the change basically :) 15:39:36 <TrueBrain> RequestNewGRFScan delays the ScanNewGRFFiles till next game-tick 15:39:40 <TrueBrain> making sure it happens in the game-thread 15:39:45 <TrueBrain> as most calls are done from the draw-thread 15:39:56 <LordAro> it's missing a doc comment ;) 15:40:06 <TrueBrain> and possibly a better name; open for suggestions :) 15:40:46 *** Flygon has quit IRC 15:40:57 *** guru3 has quit IRC 15:41:11 *** guru3 has joined #openttd 15:41:47 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain updated pull request #8830: Add: make modal windows update more smooth https://git.io/Jqt93 15:41:48 <TrueBrain> now with doxygen comment, and fixed rivers :D 15:43:37 *** lastmikoi has quit IRC 15:44:16 <TrueBrain> owh, I now also know how to fix that closing the game during mapgen was acting weird 15:45:01 <LordAro> "acting weird" ? 15:45:21 <TrueBrain> well, when you abort, it hangs the screen till generation is done 15:45:22 <TrueBrain> then closes 15:45:25 <TrueBrain> when you close the window 15:45:31 <TrueBrain> X11 terminates the application after a while 15:45:35 <TrueBrain> "weird" :D 15:45:49 <TrueBrain> XIO: fatal IO error 0 (Success) on X server 15:45:50 <TrueBrain> :D 15:46:14 <Eddi|zuHause> "fatal error: success", always great 15:46:35 *** lastmikoi has joined #openttd 15:47:00 <LordAro> that is pretty weird 15:51:38 <TrueBrain> it seems to happen because the screen is gone but we haven't teared it down yet 15:51:52 <TrueBrain> basically, we are not quick enough in those cases or something 15:53:39 <TrueBrain> ah, I see why, yeah, okay, that makes sense ... /me writes some more code 15:58:22 *** supermop_Home has joined #openttd 16:00:26 <TrueBrain> hmm .. no, I keep having the issue ... no clue why :( 16:00:58 <supermop_Home> Eddi|zuHause in a formal-ish email in germany is it weird to say "I require either A) Ship to X, or B) Ship to Y"? 16:01:23 <supermop_Home> or would it be better to use a ":" and then an enumerated list 16:01:32 <Eddi|zuHause> supermop_Home: needs more context 16:02:20 <Eddi|zuHause> you wouldn't usually put "a)" and "b)" in a single line, but you could start a new line with "a)" and another one with "b)" 16:02:56 <supermop_Home> A company has sent me an invoice for some items, but without shipping (ie terms are to collect at factory in Germany). I am asking by email for them to revise the invoice to include shipping either to New York, or to a freight forwarder in germany 16:05:15 <supermop_Home> more than any other country, it seems hardest to get things shipped from germany. When i used to collect vintage Braun electronics, most sellers refused to ship outside of Germany 16:05:32 <supermop_Home> and those that would ship had much much higher prices 16:07:36 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain updated pull request #8830: Add: make modal windows update more smooth https://git.io/Jqt93 16:07:46 <TrueBrain> right, now it closes the game nicely when you abort during mapgen .. that is a lot better :P 16:07:54 <TrueBrain> now, why was bootstrap being so weird ... 16:08:24 <supermop_Home> i wonder if they will be nicer to me if i try to write in german... 16:09:15 <TrueBrain> owh, ofc ... I didn't throw away my openttd.cfg 16:09:19 <TrueBrain> as that is in another folder 16:09:19 <TrueBrain> oops 16:09:21 <TrueBrain> stupid XDG 16:10:24 <TrueBrain> PEBCAK :D 16:11:28 <TrueBrain> LordAro: okay, bootstrap works as expected :D 16:11:42 <LordAro> :) 16:11:57 <TrueBrain> that PR makes the whole experience so much different 16:12:02 <TrueBrain> starting OpenTTD feels .. less long 16:12:07 <TrueBrain> because the progress-bar goes smooth 16:12:10 <TrueBrain> it is so weird 16:13:23 <TrueBrain> _dp_: would you mind testing #8830? It should solve your problem, but I mostly wonder if you see anything else wrong, as your IO seems just slow enough to make those things visible :) 16:14:13 <TrueBrain> owh, and LordAro , I blame you I spend all day on this .. that was not my plan of the day :P :D 16:14:20 <LordAro> lol 16:22:01 *** Cursarion has quit IRC 16:22:02 *** Cursarion has joined #openttd 16:27:33 *** glx has joined #openttd 16:27:33 *** ChanServ sets mode: +v glx 16:56:22 *** Progman has joined #openttd 17:00:18 <_dp_> TrueBrain, it wasn't rly a problem but I'll try testing 17:00:42 <_dp_> also won't be back to that pc till tomorrow so can only test on an old laptop atm 17:01:19 <_dp_> and I wouldn't quite call a zfs mirror slow io, I just have too much stuff :p 17:02:38 *** Wormnest has joined #openttd 17:10:12 <TrueBrain> Never said slow, just slow enough :D 17:10:38 *** qwebirc27464 has joined #openttd 17:15:31 *** lobster has joined #openttd 17:16:04 *** qwebirc27464 has quit IRC 17:23:37 *** lobster has quit IRC 17:30:29 <glx> https://github.com/OpenTTD/OpenTTD/compare/master...glx22:menu <-- in theory it works 17:31:00 *** y2kboy23 has quit IRC 17:31:46 <glx> probably needs media installation to be handled to 17:31:53 *** Soni has quit IRC 17:31:53 <glx> *too 17:31:58 *** Soni has joined #openttd 17:33:13 *** Tulitomaatti has quit IRC 17:33:28 *** y2kboy23 has joined #openttd 17:33:28 *** Tulitomaatti has joined #openttd 17:34:44 <LordAro> glx: seems mostly reasonable 17:35:06 *** y2kboy23 has quit IRC 17:35:13 <glx> I think I forgot a ${BINARY_NAME} (based on old makefile) 17:36:58 <spnda> Uhm, what about including .vscode/ in the .gitignore? 17:37:55 <LordAro> IDE stuff should be in your global gitignore 17:38:13 <spnda> there's a global gitignore? Let me search about this 17:38:46 <glx> there's also a local per git checkout gitignore 17:39:05 *** y2kboy23 has joined #openttd 17:40:24 <glx> local is in .git/info/exclude 18:03:38 <TrueBrain> putting .vscode in global is more useful :D 18:03:41 <TrueBrain> works for all projects ;) 18:04:46 <TrueBrain> glx: while at that part of CMake, is https://github.com/OpenTTD/OpenTTD/issues/8778 an easy thing to fix too? 18:05:23 <glx> well I think it's needed for .desktop too 18:05:54 <glx> but by looking at old makefile it's not as easy :) 18:06:24 <TrueBrain> I would assume CPack has something for that 18:08:32 <TrueBrain> doesn't appear they do :P 18:08:57 *** einar[m] has quit IRC 18:08:58 *** einar[m] has joined #openttd 18:09:02 <TrueBrain> so manual install_files I guess .. 18:09:22 <glx> yeah and file by file as each one goes in a different dir it seems 18:09:51 <glx> I guess it can go in the same optional bloc 18:10:07 <glx> as I don't see a real need for icons without .desktop 18:10:43 <JGR> Window taskbars need an icon, but don't need a .desktop file 18:11:14 <JGR> I've got a patch here to copy that, but I haven't checked the .desktop or any of the other icons 18:11:55 <glx> hmm so always install icons for UNIX AND NOT APPLE 18:12:37 <glx> hmm though .desktop could also be always included for linux, independent of package tool 18:13:21 <glx> less options is better I think 18:13:29 <TrueBrain> just always install, yes :) 18:14:55 <DorpsGek> [OpenTTD/OpenTTD] ldpl commented on pull request #8830: Add: make modal windows update more smooth https://git.io/Jqqii 18:21:35 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain commented on pull request #8830: Add: make modal windows update more smooth https://git.io/JqqPq 18:21:37 <TrueBrain> tnx _dp_ :) 18:22:15 <TrueBrain> ugh, clicking Hangars SUCKS BALLS 18:22:18 <TrueBrain> I always misclick 18:22:20 <TrueBrain> they are SO weird 18:22:38 <DorpsGek> [OpenTTD/OpenTTD] DorpsGek pushed 1 commits to master https://git.io/JqqPs 18:22:39 <DorpsGek> - Update: Translations from eints (by translators) 18:22:58 *** snail_UES_ has quit IRC 18:23:09 *** snail_UES_ has joined #openttd 18:23:58 <_dp_> TrueBrain, it still counts newgrfs while staying on 100% 18:24:10 <TrueBrain> lol .. okay ... that is rather interesting :D 18:24:14 <TrueBrain> means it miscounted how many there are 18:24:22 <_dp_> somehow seems to be happening if previous check was aborted(game closed) midway 18:24:22 <glx> oups VS stopped responding 18:24:24 *** andythenorth has joined #openttd 18:24:26 <TrueBrain> will check that code; not really related to the PR, but still worth investigating :D 18:24:40 *** Wormnest_ has joined #openttd 18:24:59 <TrueBrain> we don't keep state between runs, do we? 18:25:12 <TrueBrain> need to dive into the code :D 18:25:25 *** jgx_ has joined #openttd 18:26:20 <_dp_> TrueBrain, yeah... looks like some caching/treading issue 18:26:30 <JGR> Testing 8830, I managed to trigger a crash in something else 18:26:52 <TrueBrain> it is tricky to not fall into rabbitholes constantly JGR :P 18:26:59 <TrueBrain> what part crashed? :D 18:27:39 <LordAro> you'd think OTTD was unstable or something, the way you guys keep breaking it :p 18:27:46 <peter1138> Bah, silly heating system. 18:28:00 <TrueBrain> LordAro: if you hit shit long enough hard enough, everything breaks :D 18:28:08 <peter1138> Heats the house up, but I feel cold cos the radiator is not on... Hmm. 18:28:14 <JGR> The stack trace points at ClearSystemSprites again 18:28:14 <peter1138> Maybe that's just silly me. 18:28:19 <TrueBrain> like a plane out of fuel really is at v->tile == 0 .. like .. wuth? 18:28:45 <JGR> Interestingly the crash logger triggered AddressSanitizer as well, because now it's looking at various things from the wrong thread 18:29:00 <peter1138> Is v->tile for aircraft their destination tile, rather than current tile? 18:29:48 *** frosch123 has joined #openttd 18:30:59 <TrueBrain> peter1138: with the aircraft code, anything is possible honestly :D 18:31:13 <TrueBrain> /* If vehicle is in the air, use tile coordinate 0. */ 18:31:18 *** jgx has quit IRC 18:31:19 <TrueBrain> so there is that 18:31:24 <JGR> For things like that, it's better to check every single assignment, instead of guessing 18:31:28 *** Wormnest has quit IRC 18:31:38 <LordAro> yay for variable reuse 18:32:15 <TrueBrain> an out-of-fuel crash is weird anyway 18:32:15 <andythenorth> yo 18:32:19 <TrueBrain> the plane doesn't crash in the ground 18:32:22 <TrueBrain> it stays 1 tile up 18:33:02 <TrueBrain> https://user-images.githubusercontent.com/1663690/110520011-3eea4d80-810e-11eb-809a-40e9114f9dae.png 18:33:06 <TrueBrain> I mean ... wuth? 18:33:15 <TrueBrain> see JGR , this is what I mean with rabbit holes :D 18:35:02 <JGR> On the crash logger issue, I ran into this before when messing about with the link graph threads. Trying to do a crash save from the wrong thread often goes badly. This might be more of an issue if the drawing thread has any crash issues. 18:35:21 <JGR> I added a sort of hamfisted fix for this to ask the main thread to do the save instead. 18:36:56 <DorpsGek> [OpenTTD/team] frosch123 commented on issue #156: [en_US] Translator access request https://git.io/JqIcY 18:37:12 <DorpsGek> [OpenTTD/team] frosch123 commented on issue #157: [tr_TR] Translator access request https://git.io/JqIcK 18:37:26 <DorpsGek> [OpenTTD/team] frosch123 commented on issue #158: [nb_NO] Translator access request https://git.io/Jqt35 18:37:47 <TrueBrain> for some reason, I really expect we will need a queue between the two threads to communicate via :P 18:37:54 <TrueBrain> we keep finding things that really should be done by either thread 18:38:12 <TrueBrain> and now we are just adding variables to handle the handoff :P 18:48:45 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain opened pull request #8832: Fix #8810: "aircraft out of fuel" news was looking in the wrong place https://git.io/Jqq9N 18:49:14 <TrueBrain> wow, many translations today 18:50:25 <DorpsGek> [OpenTTD/OpenTTD] LordAro approved pull request #8832: Fix #8810: "aircraft out of fuel" news was looking in the wrong place https://git.io/JqqHq 18:52:29 <DorpsGek> [OpenTTD/OpenTTD] JGRennison opened issue #8833: Crash when closing game when manually triggered NewGRF scan in operation https://git.io/JqqH8 18:52:33 <TrueBrain> _dp_: you are not wrong in what you are seeing when scanning :) 18:52:40 <TrueBrain> it remembers the last amount of NewGRFs it saw 18:52:45 <TrueBrain> and uses that as 100% 18:55:00 <TrueBrain> so I do not think there is a lot I can do about that now 18:59:05 *** aperezdc has quit IRC 18:59:08 <TrueBrain> ah, and because you exit, the new value is stored .. that is a bug I can fix 18:59:11 *** aperezdc has joined #openttd 19:02:43 <TrueBrain> JGR: I think I fixed your bug by accident too now :D 19:03:23 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain updated pull request #8830: Add: make modal windows update more smooth https://git.io/Jqt93 19:03:28 <spnda> According to my NVIDIA tools setting my FPS ingame to 144 actually makes the FPS go between 120 and 180 FPS 19:03:56 <TrueBrain> spnda: doesn't surprise me, if we miss the targets a bit yes 19:04:08 <spnda> Well ingame fps shows 143 to 145 19:04:15 <TrueBrain> the game allows some slack, so it can go a bit faster if it was a bit slower for up to 5 frames 19:04:38 <TrueBrain> the ingame fps averages it over a longer period, so if the NVIDIA tools have a high resolution, yeah, that is to be expected :) 19:05:07 <TrueBrain> we do cooperative threading basically 19:05:15 <TrueBrain> so meeting deadlines exact is really really difficult :P 19:06:34 <TrueBrain> owh, I was testing JGR's bug with "sdl" .. I should try OpenGL :D Oooppssss 19:06:45 <spnda> wow at 240Hz the FPS can sometimes go all the way up to 400FPS 19:07:01 <spnda> and yes, this is driver level performance measuring 19:07:30 <spnda> and like "hardware acceleration" is a.... weird term. We're doing 3 calls to the GPU 19:07:31 <TrueBrain> yeah, I made it so it can catch up for 5 frames if needed 19:07:40 <TrueBrain> so strictly see, it can go up to 1200FPS for a single frame :P 19:08:08 <TrueBrain> spnda: with the right calls, it makes a huge difference :D 19:08:17 <TrueBrain> I can make dirty comparisons now, but I won't :P 19:08:49 <spnda> I'm thinking about something if I actually do work on my Vulkan driver which would make this extroardinarily quick 19:09:01 <spnda> like easily hit a few hundred fps 19:09:42 <spnda> like the CPU would be the one doing nearly nothing on the render thread 19:09:54 <JGR> At some point this is diminishing returns if the rest of the game isn't fast though 19:10:23 <spnda> obviously yes, but going bonkers at something is still learning something for me, as I want to get really good at Vulkan in general 19:10:43 <spnda> and idk if OpenGL can do this, but I think it can 19:12:33 <nielsm> how much more work would it be to make a D3D output for windows now that the OGL one exists with some framework around it? 19:12:57 <spnda> DirectX 11 I guess, cause 12 is unnecessary? 19:13:30 <nielsm> 9 or 10 would work too, none of the extra new features are required I think 19:15:53 <spnda> would go 10 or 11 atleast, as 9 and older don't run natively afaik 19:16:09 <spnda> but yet again, this game is quite a thing for backwards compatibility 19:16:53 <TrueBrain> JGR: mine confirming something for me? As I cannot reproduce #8833 locally, but if you just have the NewGRF window open and close the game 19:16:57 <TrueBrain> does it crash too? 19:17:03 <TrueBrain> (before hitting the Scan button) 19:21:49 * andythenorth investigates a performance thing, got an inkling 19:22:02 <andythenorth> like...we can get these insane FPS numbers now 19:22:11 <andythenorth> but as soon as I have 100 trains in the game....nope 19:22:31 <spnda> ye, while on Debug I get atrocious FPS with many vehicles. Release is mostly fine tho 19:22:38 <LordAro> mm, it's all very well maxing the FPS out on an empty game 19:23:26 <TrueBrain> andythenorth: one problem at the time :) 19:23:28 <TrueBrain> 1.11 -> make drawing faster 19:23:30 <TrueBrain> 1.12 -> ??? 19:23:31 <TrueBrain> :D 19:23:41 <andythenorth> I want to know how much this is self-inflicted in grf 19:23:49 <TrueBrain> 90% :P 19:23:58 <Timberwolf> Lots :) 19:24:47 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain commented on pull request #8830: Add: make modal windows update more smooth and fix "closing the app" issues closely related to this. https://git.io/JqqNk 19:26:34 <LordAro> TrueBrain: why is last_newgrf_count a thing at all? 19:26:46 <TrueBrain> you ask me like I would know :P 19:26:49 <nielsm> https://github.com/OpenTTD/OpenTTD/pull/7248 this for improving performance in debug? not sure how much it does 19:27:07 <TrueBrain> if I would be to guess ... I think it is because there isn't really a way to know that number beforehand 19:27:10 <Timberwolf> I'm trying to think if there's a simple grf which supports FIRS cargos where you could add it to a game and replace all the vehicles to test how much is grf-inflicted. 19:27:16 <TrueBrain> and it is not likely the number is very different between runs 19:27:23 <TrueBrain> so it is a "as best as we can get" value 19:27:36 <Timberwolf> OpenGFX+ Trains probably doesn't have much in the way of complex callbacks? 19:27:42 <andythenorth> lol 99k FPS on a simple map 19:27:56 <LordAro> i suppose 19:28:17 <LordAro> though getting the raw file count should be pretty quick 19:28:19 <LordAro> could use that instead 19:28:36 <TrueBrain> dunno .. someone wrote this for a reason 19:28:46 <TrueBrain> I have been down rabbit holes all day, so I am not going to look into this one :) 19:29:06 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain commented on issue #8833: Crash when closing game when manually triggered NewGRF scan in operation https://git.io/JqqH8 19:29:27 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain merged pull request #8832: Fix #8810: "aircraft out of fuel" news was looking in the wrong place https://git.io/Jqq9N 19:29:30 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain closed issue #8810: "Aircraft ran out of fuel" messages point to tile 0 instead of where the aircraft is. https://git.io/JqTlw 19:29:38 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain updated pull request #8830: Add: make modal windows update more smooth and fix "closing the app" issues closely related to this. https://git.io/Jqt93 19:29:42 <LordAro> TrueBrain: can remove 1.11 milestone from #8693 now, right? 19:30:05 <TrueBrain> LordAro: up to you; if you like, I can look into a simple GUI this week 19:30:05 <DorpsGek> [OpenTTD/OpenTTD] LordAro approved pull request #8831: Codechange: only run InteractiveRandom() from the draw-thread https://git.io/Jqqhn 19:30:07 <andythenorth> so simply building 101 (non-newgrf) trains, stopped, in a depot, with all windows closed 19:30:42 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain merged pull request #8831: Codechange: only run InteractiveRandom() from the draw-thread https://git.io/JqtH5 19:30:48 <spnda> I'm looking at the OpenGL code and I don't quite understand how this really works. Is "RenderOglSprite" called for each single sprite and does it really just use the sprite and put it on the same big quad thats on screen? 19:30:51 <andythenorth> cuts game speed factor from ~3.5k to 180 19:30:55 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain updated pull request #8830: Add: make modal windows update more smooth and fix "closing the app" issues closely related to this. https://git.io/Jqt93 19:31:04 <JGR> TruBrain: On 8833, just closing the NewGRF settings window seems fine in master 19:31:09 <TrueBrain> spnda: you have to ask michi_cc :) 19:31:21 <TrueBrain> JGR: no, not closing the window. While the window is open, close the game 19:31:30 <LordAro> andythenorth: ouch 19:31:47 <spnda> michi_cc: Any rundown or docs on how the OpenGL driver works? I'm specifically looking at RenderOglSprite cause I want to change how this works for the most part. 19:31:52 <andythenorth> setting the trains going on a circle cuts game speed factor to ~80 19:31:56 <andythenorth> these are default trains 19:31:57 <LordAro> TrueBrain: well, it's no longer blocking, anyway 19:32:14 <TrueBrain> LordAro: so, if I don't get to that this week, we branch and don't do that for 1.11 :D 19:32:23 <TrueBrain> so it fully depends on how much distraction I am having :P :P 19:32:25 <TrueBrain> I like that :D 19:32:58 <LordAro> :) 19:33:05 <michi_cc> spnda: RenderOglSprite is only used for the mouse cursor and nothing else at all. 19:33:16 <spnda> michi_cc: So how are the other sprites rendered? 19:33:21 <JGR> TrueBrain: ah sorry. Yes that also crashes. 19:33:31 <TrueBrain> JGR: good, then I fixed it in my PR (I think :D) 19:33:35 <TrueBrain> tnx! 19:33:48 <TrueBrain> don't you just love, dtors that do a lot of shit, including reloading of all sprites .. 19:34:07 <TrueBrain> "I am going to close you" - "HOLD UP! I am now going to do these 1000000 things first!" 19:34:14 <andythenorth> replacing the default trains with Iron Horse trains (which do dumb shit in the graphics chain)...80x is reduced to 50x 19:34:23 <michi_cc> Like always :) OTTD has "blitters" that draw and compose everything you see into a pixel buffer. The video driver then does something to make sure the OS puts it on the screen. 19:34:48 <LordAro> a document in the repo explaining all this wouldn't be a bad thing 19:34:51 <michi_cc> OpenGL only comes into play when transfering the pixel buffer to the OS (which confusingly is what often is called blitting). 19:35:14 <spnda> ok then I'm gonna be off writing my own blitter 19:35:58 <peter1138> My OpenGL blitter from long ago used OpenGL to do the individual sprites. It was okay as long as the number of sprites was limited. 19:36:25 <peter1138> It was all immediate mode so not ideal. 19:36:27 <michi_cc> The main advantage of OpenGL as it is used for now stems from the fact that we can 1) usually omit at least one copy of the pixel buffer (the OS one), and 2) that for palette animation we don't need to update the whole pixel buffer but can instead let an OGL shader do that for us. 19:37:05 <TrueBrain> basically meaning that with OpenGL we can do away with the "Full Animation" toggle, right? :D 19:37:08 <spnda> I want to see what I can optimise in the blitter for fun, by writing a blitter that spits the data into a compute shader 19:37:11 <peter1138> OpenGL doesn't really like 30000 individual textures, maybe it's improved somewhat. 19:37:15 <michi_cc> TrueBrain: Yes, indeed. 19:38:07 <TrueBrain> LordAro: regarding #8830, I can PR 3 commits in 3 different PRs. Is that prefered? 19:38:08 <michi_cc> peter1138: Though about but not tried, but it might possibly be acceptable if the GPU supports bindless textures and direct state access. 19:39:07 <michi_cc> And at least for NVidia card you can even do instancing/multi-rendering as texture access doesn't need to be dynamically uniform. 19:39:10 <LordAro> TrueBrain: nah, i think it's fine in one 19:39:15 <LordAro> they're all more or less related 19:39:28 <TrueBrain> indeed, but it went from 1 to 3 .. :D 19:39:33 <TrueBrain> but I will leave it like it is for now 19:39:37 <peter1138> One issue of course is it completely changes OpenTTD's idea of rendering. 19:41:18 <michi_cc> peter1138: I would actually still use render-to-texture to keep the existing workflow, especially to support remaps etc. Keep two colour buffers for rgb and palette and only resolve on display (like now). 19:41:38 <TrueBrain> michi_cc: I like OpenGL; it finds weird code we had for years, and points them out with a stick :D (I am not being sarcastic; it is really nice we now detect when weird shit happens on shutdown etc) 19:42:45 <spnda> still gonna see if I my GPU has a problem with storing 30000 odd textures in its VRAM and to see if I can actually get comparable or better performance when writing the sprites with a compute shader, which in my mind should work like multi-threading on a bunch of texture cores 19:45:07 *** mjk has joined #openttd 19:45:25 <LordAro> then try it with zbase ;) 19:45:27 <peter1138> Yup. My stuff was from 2008, when I think FBOs are pretty new and unsupported. 19:45:31 <LordAro> or another large GRF 19:46:10 <peter1138> There was also the powers-of-2 thing for texture sizes, not sure if that's still a thing. 19:46:16 <mjk> Hi all! Is there an easy way to change OpenTTD's interface colors? "Black on dark lilac" etc. is really hard to read .... 19:46:56 <peter1138> Where do you find black on dark lilac? 19:47:26 <mjk> peter1138: Opening dialog: Settings 19:48:20 <peter1138> So it is. 19:48:56 <mjk> peter1138: And "black on medium-gray", as in "Game settings" is also ... uhm ... *lookingfordiplomaticwordings* ... sub-optimal for my eyes. :-} 19:49:19 <mjk> But at least better than the black on dark lilac. :} 19:49:58 <LordAro> a certain amount of it will have been inherited from TTD 19:50:11 <LordAro> could use a lighter shade of purple/grey, i suppose... 19:51:26 <mjk> Or themes/skins! %-) 19:51:45 <JGR> Also, some parts of the UI are a bit hostile to peopel with red/green colour blindness 19:51:49 <JGR> people* 19:52:11 <mjk> Hm, hm, hm ... *pondering* 19:52:14 <andythenorth> so how did I break Bananas this time? 19:52:38 <andythenorth> Iron Horse 2.21.1 is present, but client doesn't find it https://bananas.openttd.org/manager/newgrf/4341121f 19:52:51 <mjk> I'll try different video drivers, maybe one of them plays with some gamma setting or so ... 19:53:00 <spnda> andythenorth: A link to the manager is... sub-optimal 19:53:16 <andythenorth> oh yeah, the curse of being authed 19:53:38 <spnda> yeah, can't find 2.21.1 either, only 2.21.0 shows up 19:53:44 <andythenorth> try https://bananas.openttd.org/package/newgrf/4341121f 19:53:49 <FLHerne> Instead of thousands of sprites, why not texture atlases? One per grf, presumably 19:54:22 <spnda> Cause that's what older systems do (like Minecraft ew) but yes, why not 19:54:53 <spnda> From what I know it's faster to use individual sprites, but I think that was when refering to PBR textures so 4 textures per surface... 19:54:55 <FLHerne> Well, lots of people still have not-the-latest GPUs :p 19:55:39 <FLHerne> Minecraft's renderer has a lot of problems, but I'm not convinced that building texture atlases is one of them 19:55:41 *** otetede has joined #openttd 19:56:12 <spnda> for the shader community (especially OptiFine and Focal) they've said it can be quite a bottleneck 19:56:29 <spnda> but they also write shaders that can burn down a 3090 19:56:54 <FLHerne> (I don't understand how a billion-dollar game can have a renderer that's improved an order of magnitude by community hacks) 19:57:13 *** LordAro has quit IRC 19:57:14 *** LordAro has joined #openttd 19:57:18 <spnda> yeah, Sodium by Caffeine just went ahead and put a few patches on and it's like 4x as quick sometimes 19:57:57 *** gelignite has joined #openttd 19:57:58 <JGR> OpenTTD doesn't need to do anything even remotely fancy to draw a sprite, it's really a fancy memcpy. 19:58:29 <JGR> There's no perspective, zoom, shading, lighting, or anything like that 19:58:32 <DorpsGek> [OpenTTD/OpenTTD] LordAro commented on pull request #8830: Add: make modal windows update more smooth and fix "closing the app" issues closely related to this. https://git.io/JqmJd 19:58:41 <spnda> *introducing FOV for openttd* 19:58:58 <JGR> A GPU shader seems like a bit overkill 19:59:04 <LordAro> someone link that 3d ottd demo that someone made 19:59:18 <spnda> I tested that out, it was horrible 20:00:14 <spnda> how do I specify blitter with command line arguments? 20:00:36 <JGR> -b 20:00:52 <JGR> -h gives you a useful reference 20:00:54 <spnda> that was kinda obvious 20:01:02 <spnda> dumb me 20:01:46 <milek7> 3d ottd was fun 20:01:53 <milek7> too bad I had trouble getting it to run on webgl ;P 20:05:49 <DorpsGek> [OpenTTD/OpenTTD] LordAro commented on pull request #8706: Feature: rail station class name filtering https://git.io/JqmUW 20:12:21 <TrueBrain> LordAro: do we do doxygen on definition or declaration? I see a rather mix, depending on where you look :D 20:12:42 <LordAro> AI functions are always declaration 20:12:46 <LordAro> afaik everything else is definition 20:12:49 <LordAro> or should be 20:13:31 <TrueBrain> okiedok 20:13:56 <frosch123> TrueBrain: LordAro: bananas publish fails due to invalid secret. do you know something about that? 20:14:07 <TrueBrain> invalid secret? 20:14:13 <frosch123> https://github.com/OpenTTD/BaNaNaS/runs/2064430313 20:14:19 <frosch123> invalid base64 20:14:28 <TrueBrain> that is ... interesting 20:14:33 <TrueBrain> GHA upgraded to 20.04 20:14:37 <TrueBrain> which comes with AWS CLI v2 20:14:41 <TrueBrain> I thought I fixed all the issues :P 20:15:11 <TrueBrain> owh, lambda payload needs to be base64 encoded 20:16:47 <FLHerne> JGR: GPU hardware is optimised to do fancy memcpys really fast, though :p 20:17:48 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain commented on pull request #8830: Add: make modal windows update more smooth and fix "closing the app" issues closely related to this. https://git.io/Jqmtm 20:18:19 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain updated pull request #8830: Add: make modal windows update more smooth and fix "closing the app" issues closely related to this. https://git.io/Jqt93 20:18:26 <TrueBrain> LordAro: let me know if you find more doxygens in the "wrong" place :P 20:18:31 <FLHerne> One advantage is it would pretty much remove the performance cost of palette animation 20:18:32 <TrueBrain> I at least moved the GameLoopPause too 20:18:46 <FLHerne> That would be essentially free in a fragment shader 20:19:23 <FLHerne> But you'd need to upload all the changed sprite offsets to the GPU every frame 20:19:53 *** ircer[m] has quit IRC 20:20:00 *** ircer[m] has joined #openttd 20:20:32 <JGR> The new 40bpp blitter does allow for palette animation to be done in the GPU, as I understand it 20:21:18 <JGR> Presumably you'd send a command queue of sprite IDs and offsets into the GPU, same as you'd normally do for vertices or whatever 20:22:14 <JGR> On the other hand, the actual blitting stage isn't really that expensive anyway 20:22:29 <mjk> What happens when I select a start date before 1950? Will I get coaches and hot-air balloons? 20:22:33 <DorpsGek> [OpenTTD/BaNaNaS] TrueBrain opened pull request #84: Fix: [Actions] "unbreak" reload workflows by downgrading to Ubuntu 18.04 https://git.io/Jqmtz 20:22:35 <TrueBrain> frosch123: temporary fix ^^ 20:23:20 <DorpsGek> [OpenTTD/BaNaNaS] frosch123 approved pull request #84: Fix: [Actions] "unbreak" reload workflows by downgrading to Ubuntu 18.04 https://git.io/JqmtV 20:24:16 <DorpsGek> [OpenTTD/BaNaNaS] TrueBrain merged pull request #84: Fix: [Actions] "unbreak" reload workflows by downgrading to Ubuntu 18.04 https://git.io/Jqmtz 20:24:19 <JGR> I suspect that there are much lower hanging fruit to look at elsewhere as regards performance issues 20:24:49 <TrueBrain> frosch123: tnx for tracking down the issue :) 20:25:01 <TrueBrain> I don't read the info@ mailbox enough to notice these things :P 20:25:16 <frosch123> lol, i didn't do anything :p 20:25:22 <TrueBrain> link me the failure! 20:25:26 <frosch123> andy complained :) 20:25:40 <TrueBrain> I assumed bananas-api did something stupid 20:25:59 <mjk> Wow, there seems to be a possible to get older vehicles via NewGRFs, yay! 20:26:29 <TrueBrain> k, reloads complete 20:26:38 <frosch123> andythenorth: is your newgrf available now? 20:27:14 <TrueBrain> the lovely small issues you get with a dist-upgrade :D 20:29:14 <andythenorth> frosch123 yes 20:29:26 <frosch123> \o/ 20:30:12 <frosch123> now i can become a first level support engineer 20:31:42 <Eddi|zuHause> "have you tried turning it off and on again?" :p 20:36:40 <peter1138> Why did I pick up a heavy keyboard today? :( 20:36:58 * peter1138 ponders deep heat 20:38:49 <andythenorth> was it some kind of moog or klavier or something? 20:40:04 <LordAro> or a Model M 20:41:03 <spnda> I think it is very interesting how with a blitter that does nothing the background of stuff still loads, it looks so weird lol 20:45:29 *** dude[m]1 has quit IRC 20:45:35 *** dude[m]1 has joined #openttd 20:45:53 <spnda> im confused, where are screen buffers defined/stored? 20:46:01 *** labs[m] has quit IRC 20:46:07 *** labs[m] has joined #openttd 20:48:57 *** tonyfinn[m] has quit IRC 20:49:00 *** tonyfinn[m] has joined #openttd 20:49:17 <michi_cc> JGR: Indeed, the point of the 40bpp blitter is that the palette/mask overlay is only resolved on GPU drawing, which means we can skip the whole "look at all pixels" each time the palette changes. 20:51:53 *** otetede has quit IRC 20:56:45 <FLHerne> mjk: Yes, that's the answer ;-) 20:58:13 <FLHerne> mjk: There are a few vehicles available pre-1950 in the base vehicle set, but they're all still available in 1950 so nothing different 20:58:39 <FLHerne> mjk: eGRVTS has horses and carts from 17something 20:58:56 <FLHerne> There's also Early Rail and Sailing Ships for very early games 20:59:05 <FLHerne> And lots of grfs have vehicles from 1900ish 21:01:45 *** yur3shmukcik[m] has quit IRC 21:01:51 *** yur3shmukcik[m] has joined #openttd 21:02:31 <nielsm> hmm... a thought, would it perhaps be possible to multithread the tile ticks, perhaps only on large maps? like, split the map into 256x256 chunks and run those in parallel 21:03:18 <nielsm> are there any tile ticks that could run into data races there? I guess there might be 21:04:14 <nielsm> hmm... otoh, the tile ticks are made such that two neighboring tiles never update in the same tick aren't they 21:04:32 <Eddi|zuHause> @nielsm some things like industries can check larger areas 21:05:30 <Eddi|zuHause> not sure what the range on that is 21:05:34 *** mjk has quit IRC 21:06:21 <nielsm> stupid workaround: every tile that needs to do unsafe operations get pushed onto a queue and then processed in serial after all the parallel ticks are done 21:06:53 <frosch123> nielsm: tiles are too complicated, too many interdepenencies 21:07:03 <frosch123> but you can parallelize a lot of the vehicle stuff 21:07:21 <michi_cc> nielsm: BTW, doing Direct3D shouldn't be that hard now. opengl.cpp isn't really that big, and the specific win32 video part is (at last for OGL with it's very simple context creation) not that big either. 21:07:25 <frosch123> currently each vehicle is processed in sequence: compute acceleration, update movement, find paths 21:07:41 <frosch123> the acceleration part and updating of all the newgrf caches could be done in parallel 21:07:46 <nielsm> vehicles I see issues with which vehicles would be collisions and who gets to reserve a path first 21:07:57 <frosch123> only when a vehicle actually moves, it has to be sequential 21:08:36 <michi_cc> Pathfinding is complicated by the segment caches, though. 21:09:27 <frosch123> yes, pathfinding is sequential. but people complain about newgrfs 21:09:29 *** nartir[m] has quit IRC 21:09:33 *** nartir[m] has joined #openttd 21:09:47 <michi_cc> But principally you could pathfind in parallel, put the result in a queue and then deterministically move all vehicles (potentially redoing a pathfind if a previous vehicle blocked the path) in sequence. 21:11:17 <andythenorth> I still don't know if newgrfs are actually slow 21:11:46 <andythenorth> 101 Horse trains cut the FFWD rate by 50% compared to 101 default trains 21:11:55 <andythenorth> but I'm not sure it's science 21:12:02 <nielsm> it's difficult to measure the impact of newgrf's since they're so intertwined in everything 21:12:34 <nielsm> death by a thousand cuts 21:14:50 *** J0anJosep has joined #openttd 21:18:08 <DorpsGek> [OpenTTD/OpenTTD] glx22 opened pull request #8834: Add: [CMake] Install menu and media files https://git.io/JqmRJ 21:19:21 *** udo[m] has quit IRC 21:19:29 *** udo[m] has joined #openttd 21:20:25 *** pothyurf[m] has quit IRC 21:20:30 *** pothyurf[m] has joined #openttd 21:20:48 <JGR> Running stuff in parallel makes the issue of determinism and avoiding desyncs much more difficult 21:22:36 <JGR> Some things don't need to be run at all, or can be made more efficient, those should probably be tackled before putting gameloop stuff in threads 21:25:55 <Eddi|zuHause> i'd probably suggest tackling things that increase over time, like cargopackets or vehicles 21:30:17 <nielsm> I wonder how much could be won, if any, by improving data locality in the Pool<> collections, doing some more manual memory management with fixed-size allocations or similar 21:30:40 <nielsm> and perhaps also take an opportunity to clean up some of all that UB I'm pretty sure is all over those types 21:30:58 <andythenorth> do we log the stats? 21:30:58 <supermop_Home> first day of no working so I've walked up to Bryant park and back 21:33:13 *** rudolfs[m] has quit IRC 21:33:17 *** rudolfs[m] has joined #openttd 21:33:28 <JGR> It's worth using a profiling tool to see what is really expensive 21:33:31 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain approved pull request #8834: Add: [CMake] Install menu and media files https://git.io/JqmgT 21:33:54 <JGR> It's often stuff that you wouldn't have thought of 21:34:13 <glx> wow that's fast TrueBrain :) 21:34:26 <TrueBrain> and I am playing Dota :P 21:35:08 <andythenorth> my guess is that the dimensions of performance vary wildly 21:35:51 <andythenorth> what I experience as slow on a 256x256 map with 160 trains is wildly different to what a player with an 8k x 8k map seems to experience 21:37:51 <andythenorth> oh hardware acceleration flag is in master 21:38:32 <andythenorth> is that expected to be faster on macos? 21:39:29 <spnda> I think it should generally be just better 21:40:09 * andythenorth looks in commits to see what else has changed 21:41:27 <JGR> I was recently sent a slow 8K x 8K map, a major culprit turned to be very mundane parts of the tile loop, water flooding checks and snow line movement 21:41:38 <JGR> On normal size maps these are basically negligible 21:42:04 <andythenorth> tree growth? :P 21:42:30 <DorpsGek> [OpenTTD/OpenTTD] glx22 closed issue #8778: GTK theme icons no longer installed https://git.io/Jtxx1 21:42:33 <DorpsGek> [OpenTTD/OpenTTD] glx22 closed issue #8613: Desktop file no longer installed https://git.io/JtWqN 21:42:36 <DorpsGek> [OpenTTD/OpenTTD] glx22 merged pull request #8834: Add: [CMake] Install menu and media files https://git.io/JqmRJ 21:42:54 <JGR> It is related to trees as growth and the ground type depends on the snow line 21:43:03 <nielsm> yeah those specific parts of the tile loop (water, trees, bare land) should be safe to run in parallel, I think, since they don't have NewGRF and only touch one tile away 21:43:18 <nielsm> don't have NewGRF callbacks, I mean 21:43:52 <nielsm> but yes station tiles, industry tiles, town tiles, those are probably not safe to do in parallel 21:44:00 <JGR> The trouble is that various parts of the tile loop use Random() 21:44:10 <nielsm> ah yeah... 21:44:20 <JGR> Those two cases I was able to optimise fairly significantly anyway 21:44:30 *** udo[m] has quit IRC 21:44:30 *** hylshols7qui[m] has quit IRC 21:44:30 *** WormnestAndroid has quit IRC 21:44:30 *** NGC3982 has quit IRC 21:44:30 *** daspork has quit IRC 21:44:30 *** Wolf01 has quit IRC 21:44:30 *** greeter has quit IRC 21:44:42 *** NGC3982 has joined #openttd 21:44:46 *** WormnestAndroid has joined #openttd 21:44:49 <andythenorth> ok hardware acceleration: on a busy area of the map it increases FFWD performance by 100%; on an empty area of the map it's 15-20% increase 21:44:51 <nielsm> so you'd need to spawn off a separate RNG for each thread in a deterministic way 21:44:54 *** greeter has joined #openttd 21:44:57 *** udo[m] has joined #openttd 21:45:02 <andythenorth> 7x -> 15x in the first instance 21:45:06 *** Wolf01 has joined #openttd 21:45:10 <andythenorth> 34x -> 41x in the second instance 21:45:17 <andythenorth> macos etc 21:45:21 <JGR> Caching whether a water tile has water for all its neighbours make the flooding checks cheap again 21:45:48 <andythenorth> can I abuse that to detect minimum-sized water areas for industry placement? :P 21:46:04 *** daspork has joined #openttd 21:46:09 <nielsm> no 21:46:40 <nielsm> I imagine JGR is suggesting something like a 1 byte cache (8 bits, one for each surrounding tile) for a water tile, that indicates whether each surrounding tile is also water 21:46:55 <nielsm> that wouldn't help an area search 21:46:58 <andythenorth> ha ha the numbers vary depending on whether I quit photoshop or not 21:47:16 <JGR> I just used a 1 bit flag for "all neighbours are water" 21:47:26 <nielsm> even simpler 21:47:44 <andythenorth> expose to newgrf, I read that bit in a circular tile search :P 21:47:53 * andythenorth not 100% serious 21:48:17 <andythenorth> perf: opening photoshop causes the mac to switch to discrete GPU, not intel integrated 21:48:20 *** Wolf01 has quit IRC 21:48:25 <nielsm> problem with that cache is then just to keep it updated everywhere 21:48:44 <andythenorth> with intel integrated GPU, numbers for hardware acceleration 'on' are same or worse as for 'off' 21:48:50 <JGR> In my implementation the flag is allowed to be false negative, which makes the problem easier 21:49:12 <JGR> I do the same thing for things like level crossings 21:49:52 <andythenorth> we might want to advise mac laptop owners not to turn on hardware acceleration maybe 21:50:13 <andythenorth> or we could trick the mac into using the discrete GPU 21:50:32 <andythenorth> that tends to cause thermal overload and the system throttles or shuts down, so generally I am -1 to it 21:50:58 <glx> IIRC hardware acceleration is off by default on mac 21:51:24 <andythenorth> it is 21:51:48 <nielsm> does macos have any kind of flag you can query for "has an always-active fast gpu"? 21:52:01 <nielsm> (i.e. "is a desktop machine with proper cooling") 21:52:44 <andythenorth> this is for metal, so might not apply https://developer.apple.com/documentation/metal/gpu_selection_in_macos/selecting_device_objects_for_graphics_rendering 21:53:37 *** hylshols7qui[m] has joined #openttd 21:55:32 *** frosch123 has quit IRC 21:55:33 <andythenorth> https://supermegaultragroovy.com/2016/12/10/auto-graphics-switching/ 21:56:06 <andythenorth> the discrete GPU in macbooks is a massive fail currently 21:56:22 <andythenorth> combined with the CPU and other components it's 100W of cooling in an 80W enclosure 21:56:54 <andythenorth> so as soon as any dGPU workload is encountered, the thermal envelope is exceeded, and the CPU is throttled 21:57:02 <glx> smart design, but it's beautiful ;) 21:57:04 <andythenorth> down to as low as 10% 21:57:13 <andythenorth> it's dumb AF 21:57:21 <spnda> even on the M1 models? 21:57:27 <andythenorth> M1 is a whole other world 21:57:45 <spnda> thought you were talking about the M1s for a second, was confused 21:57:46 <milek7> M1 doesn't have dGPU ;p 21:58:00 <spnda> yeah true.... 21:58:03 <spnda> didnt think about that 21:58:22 *** jottyfan has joined #openttd 21:58:29 <andythenorth> this is an i9 that runs hot, with a useless AMD Radeon Pro 5500M 21:58:47 <spnda> bruh 21:58:54 <glx> i9, what did you expect ? 21:59:05 <spnda> i9 in a laptop is seriously never a good idea 21:59:08 <glx> of course it heats a lot 21:59:17 <andythenorth> and it drives a ridiculous 16" display at hidpi 21:59:20 <spnda> my i5 with watercooling gets a bit hot sometimes 21:59:25 <glx> hey could be a pentium 4 ;) 21:59:34 <andythenorth> so gaming performance is lower than on the 13" i7 with integrated intel 22:00:42 * andythenorth broken record of regrets 22:01:18 <andythenorth> anyway OpenTTD is soooooo fast now :) 22:01:28 *** jottyfan has quit IRC 22:04:08 *** nielsm has quit IRC 22:13:45 *** ^Spike^ has quit IRC 22:14:10 *** ^Spike^ has joined #openttd 22:14:50 <supermop_Home> andythenorth ship a copy of photoshop with macos build? 22:15:01 <andythenorth> o_O 22:17:46 <supermop_Home> 65 degrees here 22:18:34 <supermop_Home> off to get beer later 22:19:47 <spnda> well idk how use/manipulate the screen buffer used by the blitter. Would it be a good idea to write to a seperate buffer that the opengl driver just uses and ignores all data from the blitter? (Which btw I cannot find a reference too, this blitter/driver systems seems weird imo) 22:25:41 *** Samu has quit IRC 22:26:36 <andythenorth> sleep 22:26:37 *** andythenorth has quit IRC 22:42:49 *** jeremy[m] has quit IRC 22:42:54 *** jeremy[m] has joined #openttd 22:50:45 *** spnda has quit IRC 23:00:27 *** J0anJosep has quit IRC 23:42:12 *** Exec has quit IRC 23:48:57 *** dihedral has quit IRC 23:50:08 *** dihedral has joined #openttd 23:54:11 *** sla_ro|master has quit IRC 23:56:22 *** Progman has quit IRC