IRC logs for #openttd on OFTC at 2021-03-09
⏴ go to previous day
00:01:59 *** Vadtec has quit IRC (Server closed connection)
00:02:56 *** sla_ro|master has quit IRC ()
00:05:15 *** Artea has quit IRC (Server closed connection)
00:08:41 *** k-man has quit IRC (Server closed connection)
00:41:59 *** berndj has quit IRC (Server closed connection)
00:42:21 *** milek7 has quit IRC (Server closed connection)
00:46:21 *** Timberwolf has quit IRC (Server closed connection)
00:46:27 *** Timberwolf has joined #openttd
00:56:50 *** mindlesstux has quit IRC (Server closed connection)
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 (Server closed connection)
01:05:01 *** innocenat_ has joined #openttd
01:09:38 *** fnutt has quit IRC (Server closed connection)
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 (Server closed connection)
01:47:46 *** EmeraldSnorlax[m] has quit IRC (Server closed connection)
01:47:50 *** EmeraldSnorlax[m] has joined #openttd
01:55:53 *** gnu_jj has quit IRC (Server closed connection)
02:20:50 *** y2kboy23 has quit IRC (Server closed connection)
02:21:03 *** y2kboy23 has joined #openttd
02:30:49 *** Webster has quit IRC (Server closed connection)
02:31:37 *** Hazzard has quit IRC (Server closed connection)
02:31:51 *** Webster has joined #openttd
02:31:54 *** Hazzard has joined #openttd
02:32:09 *** SmatZ has quit IRC (Server closed connection)
02:32:41 *** Terkhen has quit IRC (Server closed connection)
02:32:57 *** V453000 has quit IRC (Server closed connection)
02:33:06 *** Terkhen has joined #openttd
02:33:06 *** ChanServ sets mode: +o Terkhen
02:33:13 *** XeryusTC has quit IRC (Server closed connection)
02:33:29 *** Yexo has quit IRC (Server closed connection)
02:33:37 *** V453000 has joined #openttd
02:33:37 *** XeryusTC has joined #openttd
02:33:45 *** Ammler has quit IRC (Server closed connection)
02:34:01 *** Osai has quit IRC (Server closed connection)
02:34:33 *** fonsinchen has quit IRC (Server closed connection)
02:35:06 *** fonsinchen has joined #openttd
02:39:37 *** m1cr0man has quit IRC (Server closed connection)
02:40:02 *** m1cr0man has joined #openttd
02:40:22 *** Wormnest has quit IRC (Quit: Leaving)
02:40:34 *** crem2 has quit IRC (Server closed connection)
02:44:50 *** greeter has quit IRC (Server closed connection)
02:45:23 *** greeter has joined #openttd
02:51:14 *** gregdek has quit IRC (Server closed connection)
02:51:17 *** gregdek has joined #openttd
02:53:54 *** dvim has quit IRC (Server closed connection)
03:36:30 *** 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 (Server closed connection)
03:56:57 *** peter1138 has quit IRC (Server closed connection)
03:57:12 *** peter1138 has joined #openttd
03:57:12 *** ChanServ sets mode: +o peter1138
04:00:52 *** D-HUND has quit IRC (Ping timeout: 480 seconds)
04:14:01 *** patrick[m]2 has quit IRC (Server closed connection)
04:14:06 *** patrick[m]2 has joined #openttd
04:54:17 *** jinks has quit IRC (Server closed connection)
04:54:49 *** karl[m]5 has quit IRC (Server closed connection)
04:54:55 *** karl[m]5 has joined #openttd
05:47:05 *** murr4y has quit IRC (Server closed connection)
06:38:08 *** didac has quit IRC (Remote host closed the connection)
06:50:49 *** grag[m] has quit IRC (Server closed connection)
06:51:00 *** grag[m] has joined #openttd
06:55:13 *** JamesRoss[m] has quit IRC (Server closed connection)
06:55:17 *** JamesRoss[m] has joined #openttd
06:59:13 *** jgx has quit IRC (Server closed connection)
07:01:22 *** andythenorth has joined #openttd
07:25:13 *** colde has quit IRC (Server closed connection)
07:25:20 *** sla_ro|master has joined #openttd
07:36:09 *** twpol has quit IRC (Server closed connection)
07:42:15 *** HerzogDeXtEr has joined #openttd
07:50:41 *** heffer has quit IRC (Server closed connection)
07:59:05 *** twom[m] has quit IRC (Server closed connection)
07:59:10 *** twom[m] has joined #openttd
08:01:21 *** skrzyp has quit IRC (Server closed connection)
08:11:21 *** reldred has quit IRC (Server closed connection)
08:11:33 *** reldred has joined #openttd
08:14:02 *** snail_UES_ has quit IRC (Quit: snail_UES_)
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:38:49 *** azubieta6 has quit IRC (Server closed connection)
08:39:13 *** azubieta6 has joined #openttd
08:40:08 *** Guest1078 has quit IRC (Ping timeout: 480 seconds)
08:53:05 *** TrueBrain has quit IRC (Server closed connection)
08:53:09 *** TrueBrain has joined #openttd
09:03:21 *** natalie[m] has quit IRC (Server closed connection)
09:03:25 *** natalie[m] has joined #openttd
09:03:53 *** nolep[m] has quit IRC (Server closed connection)
09:03:59 *** nolep[m] has joined #openttd
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:24:17 <LordAro> TrueBrain: i tried to approve #8824, but GH won't let me
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:51 <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:55 <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:28 <TrueBrain> hmm, did not get an email about your last comment
09:25:31 <TrueBrain> let me add a comment
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: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: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 (Quit: andythenorth)
09:39:20 <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:23 <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:07 <TrueBrain> but oof .. I was young and wrote shitty code :P
09:42:33 <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:59 <TrueBrain> it could introduce other bugs, ofc :)
09:44:07 <TrueBrain> and this bug has been in the game for 10+ years
09:44:34 *** azubieta6 has quit IRC (resistance.oftc.net larich.oftc.net)
09:44:34 *** Wolf01 has quit IRC (resistance.oftc.net larich.oftc.net)
09:44:34 *** jgx has quit IRC (resistance.oftc.net larich.oftc.net)
09:44:34 *** greeter has quit IRC (resistance.oftc.net larich.oftc.net)
09:44:35 *** y2kboy23 has quit IRC (resistance.oftc.net larich.oftc.net)
09:44:35 *** innocenat_ has quit IRC (resistance.oftc.net larich.oftc.net)
09:44:35 *** Gustavo6046 has quit IRC (resistance.oftc.net larich.oftc.net)
09:44:35 *** supermop_Home has quit IRC (resistance.oftc.net larich.oftc.net)
09:44:35 *** Smedles has quit IRC (resistance.oftc.net larich.oftc.net)
09:44:35 *** daspork has quit IRC (resistance.oftc.net larich.oftc.net)
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:59 *** azubieta6 has joined #openttd
09:45:07 *** daspork has joined #openttd
09:45:08 *** greeter has joined #openttd
09:45:11 <TrueBrain> well, let me confirm my statement there :D
09:45:17 *** y2kboy23 has joined #openttd
09:45:19 *** Wuzzy has quit IRC (Read error: Connection reset by peer)
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: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: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: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: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 (Server closed connection)
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:43 <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:54 *** khavik[m] has joined #openttd
10:15:21 *** iarp[m] has quit IRC (Server closed connection)
10:18:16 *** skrzyp has quit IRC (Remote host closed the connection)
10:18:59 *** iarp[m] has joined #openttd
10:29:21 *** NGC3982 has quit IRC (Server closed connection)
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:09 <TrueBrain> but not having a good way to reproduce this, makes it hard to validate that :D
10:38:09 *** argoneus has quit IRC (Server closed connection)
10:38:15 *** argoneus has joined #openttd
10:38:32 <LordAro> add artificial delays to newgrf scanning?
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 (Server closed connection)
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: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: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:49:28 <_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: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: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 (Server closed connection)
11:40:35 *** patrick[m]2 has joined #openttd
11:40:42 *** WormnestAndroid has quit IRC (Remote host closed the connection)
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 (Read error: Connection reset by peer)
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:08 <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:24 <TrueBrain> I would just remove the Rescans
11:48:01 <TrueBrain> honestly, the original author should have done a better job at explaining what was going on
11:48:05 <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 (Server closed connection)
12:02:24 *** phil[m] has joined #openttd
12:08:01 *** murr4y has quit IRC (Server closed connection)
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 (Server closed connection)
12:13:48 *** hamstonkid[m] has joined #openttd
12:14:50 <TrueBrain> I drastically slowed down how long scanning takes btw, to give a more dramatic effect here :P
12:23:22 *** gelignite has quit IRC (Quit: Stay safe!)
12:29:17 <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: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:11 <TrueBrain> so if by any chance you made that generic: fuck yes
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 (Remote host closed the connection)
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:33 *** WormnestAndroid has quit IRC (Remote host closed the connection)
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
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: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:47 <TrueBrain> seems MSVC states it will do it "correctly"
13:50:33 *** hylshols7qui[m] has quit IRC (Server closed connection)
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:32 <TrueBrain> yeah, that is what I meant with: "but stackoverflow tells me.." :D
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: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:49 <TrueBrain> not sure if it is an "add" or a "feature" :P
14:12:09 <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: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 (Server closed connection)
14:32:43 *** elliot[m] 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 (Server closed connection)
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:52 <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 <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:52 <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: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: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:33:37 <TrueBrain> and that fixes rocks ...
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:50 <TrueBrain> URL no longer works, sorry :P
15:38:15 <TrueBrain> what was the line of code?
15:39:03 <LordAro> oh, you've done it several times
15:39:10 <LordAro> ScanNewGRFFiles -> RequestNewGRFScan
15:39:23 <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 (Quit: A toaster's basically a soldering iron designed to toast bread)
15:40:57 *** guru3 has quit IRC (Server closed connection)
15:41:48 <TrueBrain> now with doxygen comment, and fixed rivers :D
15:43:37 *** lastmikoi has quit IRC (Server closed connection)
15:44:16 <TrueBrain> owh, I now also know how to fix that closing the game during mapgen was acting weird
15:45:21 <TrueBrain> well, when you abort, it hangs the screen till generation is done
15:45:25 <TrueBrain> when you close the window
15:45:31 <TrueBrain> X11 terminates the application after a while
15:45:49 <TrueBrain> XIO: fatal IO error 0 (Success) on X server
15:46:14 <Eddi|zuHause> "fatal error: success", always great
15:46:35 *** lastmikoi has joined #openttd
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: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:11:28 <TrueBrain> LordAro: okay, bootstrap works as expected :D
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: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:22:01 *** Cursarion has quit IRC (Server closed connection)
16:22:02 *** Cursarion has joined #openttd
16:56:23 *** 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 (Remote host closed the connection)
17:23:37 *** lobster has quit IRC (Ping timeout: 480 seconds)
17:31:00 *** y2kboy23 has quit IRC (Remote host closed the connection)
17:31:45 <glx> probably needs media installation to be handled to
17:31:53 *** Soni has quit IRC (Server closed connection)
17:33:13 *** Tulitomaatti has quit IRC (Server closed connection)
17:33:28 *** y2kboy23 has joined #openttd
17:33:28 *** Tulitomaatti has joined #openttd
17:34:44 <LordAro> glx: seems mostly reasonable
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:45 <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: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 (Server closed connection)
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:21:35 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain commented on pull request #8830: Add: make modal windows update more smooth https://git.io/JqqPq
18:22:15 <TrueBrain> ugh, clicking Hangars SUCKS BALLS
18:22:39 <DorpsGek> - Update: Translations from eints (by translators)
18:22:58 *** snail_UES_ has quit IRC (Read error: Connection reset by peer)
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: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 (Ping timeout: 480 seconds)
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 (Ping timeout: 480 seconds)
18:31:38 <LordAro> yay for variable reuse
18:32:15 <TrueBrain> an out-of-fuel crash is weird anyway
18:32:19 <TrueBrain> the plane doesn't crash in the ground
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: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 (Server closed connection)
18:59:09 <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: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:16 <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:06 <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:55 <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:52 <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: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:41 <andythenorth> I want to know how much this is self-inflicted in grf
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: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: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 <DorpsGek> [OpenTTD/OpenTTD] LordAro approved pull request #8831: Codechange: only run InteractiveRandom() from the draw-thread https://git.io/Jqqhn
19:30:05 <TrueBrain> LordAro: up to you; if you like, I can look into a simple GUI this week
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:54 <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: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: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: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: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: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: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:12 <LordAro> could use a lighter shade of purple/grey, i suppose...
19:51:45 <JGR> Also, some parts of the UI are a bit hostile to peopel with red/green colour blindness
19:52:11 <mjk> Hm, hm, hm ... *pondering*
19:52:14 <andythenorth> so how did I break Bananas this time?
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: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 (Server closed connection)
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:59 <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:52 <JGR> -h gives you a useful reference
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:13:56 <frosch123> TrueBrain: LordAro: bananas publish fails due to invalid secret. do you know something about that?
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 (Server closed connection)
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:20 <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: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: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:38:49 <andythenorth> was it some kind of moog or klavier or something?
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 (Server closed connection)
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 (Server closed connection)
20:46:08 *** labs[m] has joined #openttd
20:48:57 *** tonyfinn[m] has quit IRC (Server closed connection)
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 (Quit: Nettalk6 - www.ntalk.de)
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:40 <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 (Server closed connection)
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 (Quit: leaving)
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 (Server closed connection)
21:09:33 *** nartir[m] has joined #openttd
21:09:48 <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:19:21 *** udo[m] has quit IRC (Server closed connection)
21:20:25 *** pothyurf[m] has quit IRC (Server closed connection)
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 (Server closed connection)
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: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: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:20 <JGR> Those two cases I was able to optimise fairly significantly anyway
21:44:30 *** udo[m] has quit IRC (resistance.oftc.net larich.oftc.net)
21:44:30 *** hylshols7qui[m] has quit IRC (resistance.oftc.net larich.oftc.net)
21:44:30 *** WormnestAndroid has quit IRC (resistance.oftc.net larich.oftc.net)
21:44:30 *** NGC3982 has quit IRC (resistance.oftc.net larich.oftc.net)
21:44:30 *** daspork has quit IRC (resistance.oftc.net larich.oftc.net)
21:44:30 *** Wolf01 has quit IRC (resistance.oftc.net larich.oftc.net)
21:44:30 *** greeter has quit IRC (resistance.oftc.net larich.oftc.net)
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:45:02 <andythenorth> 7x -> 15x in the first instance
21:45:10 <andythenorth> 34x -> 41x in the second instance
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: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: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: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: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:53:37 *** hylshols7qui[m] has joined #openttd
21:55:32 *** frosch123 has quit IRC (Quit: be yourself, except: if you have the opportunity to be a unicorn, then be a unicorn)
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: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: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:54 <glx> i9, what did you expect ?
21:59:05 <spnda> i9 in a laptop is seriously never a good idea
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:04:08 *** nielsm has quit IRC (Ping timeout: 480 seconds)
22:13:45 *** ^Spike^ has quit IRC (Server closed connection)
22:14:10 *** ^Spike^ has joined #openttd
22:14:50 <supermop_Home> andythenorth ship a copy of photoshop with macos build?
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 (Quit: Leaving)
22:26:37 *** andythenorth has quit IRC (Quit: andythenorth)
22:42:49 *** jeremy[m] has quit IRC (Server closed connection)
22:42:54 *** jeremy[m] has joined #openttd
22:50:45 *** spnda has quit IRC (Quit: Page closed)
23:00:27 *** J0anJosep has quit IRC (Ping timeout: 480 seconds)
23:42:12 *** Exec has quit IRC (Ping timeout: 480 seconds)
23:48:57 *** dihedral has quit IRC (Server closed connection)
23:50:08 *** dihedral has joined #openttd
23:54:11 *** sla_ro|master has quit IRC ()
23:56:23 *** Progman has quit IRC (Remote host closed the connection)
continue to next day ⏵
