Times are UTC Toggle Colours
00:00:50 <TrueBrain> owh, and CheckPaletteAnim() does different things on different drivers .. as in, the SDL variant does something completely different than the Win32 variant :) I am going to fix that :P 00:00:58 <TrueBrain> (by renaming, ofc) 00:01:49 <TrueBrain> owh, meaning to ask michi_cc , why the "buffer_locked"? What is the case it can do LockVideoBuffer twice? 00:02:06 <TrueBrain> (I do not mind; was just curious why :D) 00:02:20 <michi_cc> Something about screenshots I dimly remember. 00:02:34 <TrueBrain> ah 00:02:39 <TrueBrain> I wouldn't be surprised :D 00:03:17 <TrueBrain> aahh, yes 00:03:24 <TrueBrain> it is also set from video_driver.hpp 00:03:26 <TrueBrain> did not spot that yet 00:04:54 <TrueBrain> well, SDL also almost done .. that leaves OSX .. 00:05:06 <TrueBrain> brrrr 00:05:14 <TrueBrain> with that nightmare, I am off to bed :D 00:05:20 <TrueBrain> nice work today michi_cc , tnx for the quick fixes etc :) 00:05:45 <michi_cc> I've got a bunch of partly-done cleanup for OSX first. 00:05:55 <milek7_> well.. what could happen when using SDL also on MacOS? 00:06:23 <michi_cc> I absolutely do not want the subdriver mess there and instead do proper video drivers. 00:06:31 <TrueBrain> +1 00:06:48 <michi_cc> milek7_: Back in the day SDL was not very good on OSX. Might have become better with SDL2, but nobody tested that. 00:10:06 *** supermop_Home_ has quit IRC 00:11:32 *** Flygon has joined #openttd 00:20:09 *** andythenorth has quit IRC 00:40:08 <LordAro> TrueBrain: the magic is otherwise known as "sticking #include <algorithm> in stdafx.h" 01:48:14 *** nielsm has quit IRC 02:01:04 *** Progman has quit IRC 02:59:38 *** tokai|noir has joined #openttd 02:59:38 *** ChanServ sets mode: +v tokai|noir 03:06:05 *** debdog has joined #openttd 03:06:32 *** tokai has quit IRC 03:09:28 *** D-HUND has quit IRC 03:17:29 *** WormnestAndroid has quit IRC 03:17:39 *** WormnestAndroid has joined #openttd 03:27:29 *** glx has quit IRC 04:03:45 *** D-HUND has joined #openttd 04:05:50 *** gnu_jj has joined #openttd 04:07:08 *** debdog has quit IRC 04:14:44 *** gnu_jj has quit IRC 04:56:14 <DorpsGek> [OpenTTD/OpenTTD] Matias-Barrios opened issue #8582: Content Downloading does not work https://git.io/JtkW8 05:18:38 <DorpsGek> [OpenTTD/OpenTTD] James103 commented on issue #8582: Content Downloading does not work https://git.io/JtkW8 05:30:35 <DorpsGek> [OpenTTD/OpenTTD] Matias-Barrios commented on issue #8582: Content Downloading does not work https://git.io/JtkW8 05:57:14 *** Gustavo6046_ has joined #openttd 05:59:02 *** Gustavo6046 has quit IRC 05:59:02 *** Gustavo6046_ is now known as Gustavo6046 06:07:37 *** heffer_ has joined #openttd 06:14:58 *** heffer has quit IRC 06:43:06 *** heffer_ is now known as heffer 06:48:14 *** crem has quit IRC 07:02:18 *** WormnestAndroid has quit IRC 07:02:31 *** WormnestAndroid has joined #openttd 07:59:23 *** snail_UES_ has quit IRC 08:10:13 *** jottyfan has joined #openttd 08:12:20 *** andythenorth has joined #openttd 08:28:50 <_dp_> oh, nice signal autoremoval got merged 08:29:00 <_dp_> I totally forgot I wanted to review it xD 08:29:16 <andythenorth> signals on bridges next? 08:31:28 <_dp_> and gj JGR for spotting the settings category issue 08:32:27 <_dp_> though it's still in company category in the gui, should it mb moved to GUI->Construction to not make company any more of a mess with non-company setting? 08:34:25 <_dp_> andythenorth, how does that even work? by storing signal interval on bridge head? 08:34:34 <andythenorth> no idea 08:34:43 <andythenorth> I haven't tried it in JGR 08:35:14 * andythenorth tests 08:36:53 <andythenorth> oops, my map settings were 4096x4096 08:37:07 <andythenorth> can't use that on this mac, performance fail 08:39:07 <andythenorth> _dp_ I'm trying it, don't really understand it 08:39:15 <andythenorth> I'll ask discord later how to use it 08:39:54 *** sla_ro|master has joined #openttd 08:51:45 *** Progman has joined #openttd 08:56:11 <_dp_> I suddenly realized that citymania server patch become so non-intrusive that I can probably merge it into jgrpp without much trouble... 08:59:35 <_dp_> oh, but merging cmclient would be a royal pita, so no jgrpp on citymaina any time soon I guess xD 09:06:43 *** crem has joined #openttd 09:09:34 <DorpsGek> [OpenTTD/team] Leven-mok opened issue #127: [zh_TW] Translator access request https://git.io/JtkRP 09:11:59 <TrueBrain> @ports 09:11:59 <DorpsGek> TrueBrain: OpenTTD uses TCP and UDP port 3979 for server <-> client communication, UDP port 3978 for masterserver (advertise) communication (outbound), and TCP port 3978 for content service, a.k.a. BaNaNaS (outbound) 09:22:13 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain commented on issue #8582: Content Downloading does not work https://git.io/JtkW8 09:23:25 <TrueBrain> _dp_: how could you not have seen we merged auto-signal-remove .. you are the reason I merged it to start with! :P 09:28:30 <_dp_> TrueBrain, I was away for just 2 weeks but with this crazy developement I'm still getting surprised on what I missed xD 09:28:55 <_dp_> TrueBrain, also it was "candidate: probably not" when I last saw it :p 09:29:27 <TrueBrain> yeah, I still think it is a bullshit functionality 09:29:32 <TrueBrain> but you were clear it wasn't, so meh, what do I care :P 09:32:52 <andythenorth> it's 'fine' 09:33:31 <TrueBrain> it works as advertised and doesn't hurt new players, check! 09:35:47 <_dp_> it's a matter of a playstyle I guess, some see building stuff as entirety of the game while some prefer strategic part and see building as a bit of a nuisance 09:36:04 * andythenorth tests it 09:36:10 <andythenorth> Best Feature of 2021 09:36:12 <andythenorth> so far 09:36:46 <TrueBrain> _dp_: nah; it has more to do that this does something without letting you know explicitly. Those are often bad game designs 09:36:54 <TrueBrain> if there was some indication it did this, or that it is about to do so 09:36:58 <TrueBrain> that would be a lot more acceptable 09:37:03 <TrueBrain> just this magic POEF now your signals are gone 09:37:09 <TrueBrain> is a recipe for disaster (literally :D) 09:37:17 <andythenorth> yes, trains will crash 09:37:22 <andythenorth> but I explicitly chose to build 09:37:33 <andythenorth> the intent is signalled by clicking 'build track' 09:37:42 <andythenorth> ok, everyone gets cookies 09:37:46 <andythenorth> what next? 09:37:51 <andythenorth> signals on bridges when? 09:38:55 <TrueBrain> _dp_: but OpenTTD lacks other ways of informing users, so meh .. now it is a setting of: if you want to shoot yourself in the foot, it is fine :) We will see if/when people complain :) 09:39:04 <_dp_> well, I guess it could be implemented like highlighting the singnal and removing it on a first click and bulding track on second 09:39:07 <TrueBrain> (really, I am fine with it, to be clear; it is just a poor design, but I have nothing better :D) 09:39:17 <_dp_> but you kinda want it removed like 100% of the time, so idk 09:39:31 <TrueBrain> if the game would indicate junctions better, would already help, for example 09:39:48 <TrueBrain> or don't allow it if the signal is within reserved path 09:39:50 <TrueBrain> or .. I dunno :) 09:40:19 <TrueBrain> this is a typical "well tested" patch :) I am fine with it, I just also expect some complaints about it :) (which is also fine :P) 09:41:34 <_dp_> imo that's just details and it's kinda hard to get all the nuances right without excessive playtesting anyway 09:41:53 <_dp_> but it's a patch with a right intention since signals are a real nuisance when building 09:42:05 <TrueBrain> and those that want this functionality, are never going to do that excessive playtesting :) 09:42:11 <TrueBrain> as their focus is what you describe 09:42:18 <TrueBrain> not how anyone else might (wrongly) use it :D 09:42:26 <TrueBrain> one of the more common issues with OpenTTD :P 09:42:33 * andythenorth testing signals on bridges currently 09:42:43 <_dp_> it's quite hard to playtest stuff like that properly without it being actually merged 09:43:07 <TrueBrain> but once merged, it is hard to pick another solution :D 09:43:10 <TrueBrain> chicken-egg? :) 09:43:20 <_dp_> like, for me I need to merge it into cmclient and cmserver first and play some cb game to see how it works in a real game 09:44:31 <_dp_> also mb get used to it first, so it's not like it's just a single game is enough 09:45:46 <_dp_> normaly I do stuff like that in cmclient first with a network-compatible patch 09:46:35 <_dp_> but it wasn't my patch... also there is rarely a "second" after that since it takes rewriting stuff from scratch 09:47:12 <TrueBrain> so now it is in vanilla :P 09:47:19 <TrueBrain> and any complaints and I just tell them this story :D :D :) 09:47:23 <TrueBrain> (no, I am not :D) 09:47:44 <TrueBrain> if we paid people to develop this, I would tell them to come up with a new-player-friendly design for it 09:47:46 <TrueBrain> we don't 09:47:50 <TrueBrain> so here we are :D 09:47:53 <TrueBrain> YOLO! :) 09:48:16 *** nielsm has joined #openttd 09:49:20 *** gnu_jj has joined #openttd 09:49:28 <TrueBrain> it is just a fun example why OpenSource development is tricky. Everyone understand this is a good idea for advanced players, but everyone also understands it is not really "fun" for new players :) 09:49:44 <andythenorth> pay TrueBrain 09:49:50 <andythenorth> TrueBrain send TrueBrain a job offer 09:50:02 <TrueBrain> pretty sure OpenTTD cant pay me :D 09:50:29 <_dp_> TrueBrain, well... it's an option anyway :p 09:50:44 <_dp_> ... and settings gui is a long lost cause already :p 09:51:06 <TrueBrain> it really is 09:51:16 <TrueBrain> I wouldn't mind a PR btw to move it from one category to the other; I honestly did not validate that 09:51:50 <TrueBrain> didn't even think about what a good place for it would be :) 09:58:16 *** gnu_jj has quit IRC 10:04:52 <_dp_> well, at this point may as well kick all other non-company settings out of that category 10:06:12 <_dp_> btw, there are other similar "risky" improvements that can be done like building under vehicles for example 10:06:34 <_dp_> though for road vehicles it's probably safe 10:06:40 <_dp_> and those are the most annoying 10:12:40 <orudge> Hurrah, arm64 Windows build working now too 10:12:54 <orudge> Need to check the installer but I should have a PR for this soon too 10:13:18 <TrueBrain> nice :D Any word from the CA about the cert? 10:14:07 <orudge> Not so far 10:14:13 <orudge> Seems to be a very slow process 10:14:30 <TrueBrain> yeah .. people on the interwebz already said as much :( 10:14:36 <orudge> If there's nothing by the end of tomorrow I'll contact them again 10:15:16 *** muffindrake has joined #openttd 10:18:02 *** Flygon_ has joined #openttd 10:20:39 *** Flygon has quit IRC 10:41:32 *** gelignite has joined #openttd 10:49:58 *** jottyfan has quit IRC 10:56:45 *** Samu has joined #openttd 11:12:21 <_dp_> hm... how should I handle ip bans... show them nice kick message with reason and duration or just crash their client... xD 11:15:18 <_dp_> second option has an enticing advantage that using vpn may not be their first thought afterwards :p 11:15:53 <TrueBrain> does result in more bug-reports ;) 11:16:20 <_dp_> it's already reported so just close as dupe :p 11:20:46 <TrueBrain> glx was not wrong when he said that the NewGRF loading window is faster with OpenGL 11:20:49 <TrueBrain> which is really odd :P 11:21:18 <TrueBrain> like 5s vs 2s 11:22:07 <Samu> i found a bug in OrthogonalTileArea &OrthogonalTileArea::Expand(int rad) 11:22:43 <Samu> Expand a tile area by rad tiles in each direction 11:23:00 <Samu> it's not doing that correctly 11:23:44 <Samu> if i have tile 64,64 and i expand 6 in each direction, i get tile 58,58 and 70,70 11:24:26 <Samu> this->w = 70 - 58 = 12 and this->h = 70-58 11:24:39 <Samu> becomes 12, should be 13 11:25:05 <_dp_> Samu, do you have an empty area? 11:25:21 <TrueBrain> 58 .. 70 == 13 tiles 11:25:22 <Samu> the last tile area in the iterator is tile 69,69 11:25:47 <Samu> the last tile in the tile area iterator is tile 69,69 11:27:12 <Samu> should be 70 11:27:14 <Samu> 70,70 11:28:07 <Samu> looks like this Expand function is only used for industries 11:28:51 <_dp_> Samu, what's your area before expansion? 11:29:00 <_dp_> if it's empty (w=h=0) that's correct 11:29:20 <Samu> it's empty 11:29:33 <Samu> or should be w=1, h=1 11:29:45 <_dp_> if it's one tile area should be 1,1 ofc 11:29:54 <Samu> let me test with that size, brb 11:32:17 <Samu> interesting, it's working correctly now 11:32:27 <Samu> so I misused the function apparently 11:32:33 <TrueBrain> yippie, finally managed to clean up the palette mess in SDL :D Now I need to make commits out of this .. always a bit tricky :D 11:32:37 <Samu> 58,58 to 71,71 11:32:48 <Samu> this->w = 71-58 = 13 11:33:01 <Samu> last tile is 70,70, first tile is 58,58 11:33:22 <Samu> thx _dp_ 11:36:53 *** frosch123 has joined #openttd 11:55:09 <TrueBrain> hmm ... I start to prefer the SDL driver for Windows :D 11:55:18 <TrueBrain> it seems to be running my mouse at 144Hz instead of 30Hz or something 11:56:41 <Samu> I'm trying to make desert/rainforest convertion tiles to be scalable by map size 11:57:37 <Samu> deprecating the need for "genland.h" 11:58:24 <Samu> i've never made a change where I need to delete a file, may need help 11:58:38 <Samu> how to properly "eliminate" the file from the build 12:02:20 <nielsm> remove all references to the file from the project files, remove all #include uses of it from the source code, then delete the file 12:05:27 <andythenorth> does cb 39 run in context of cargo or station? 12:05:32 * andythenorth could work that out, oops 12:06:00 <andythenorth> nvm 12:07:07 <TrueBrain> michi_cc: found a nice difference between SDL and Win32 .. totally not related to our work btw. The Sleep() in the GameLoop slows down calls to DrawMouseCursor a lot more on Win32 than on SDL. In result, on Win32 my mouse moves at .. 30 fps? On SDL a lot quicker. The benefit? On SDL it reaches my 144Hz of my monitors 12:07:11 <TrueBrain> making it all look a lot smoother 12:07:26 <TrueBrain> if I disable the Sleep(), I get the same result on Win32 :) 12:07:47 <TrueBrain> (but that is bad for a lot of different reasons :D) 12:08:44 <TrueBrain> not sure why a 1ms sleep takes longer on Win32 over SDL 12:09:13 <nielsm> SDL probably uses a multimedia timer while the win32 driver may use the plain system sleep 12:09:27 <TrueBrain> I called CSleep in both cases, to be sure 12:09:29 <TrueBrain> same difference 12:09:36 <nielsm> hmm 12:09:50 <TrueBrain> std::this_thread::sleep_for(std::chrono::milliseconds(milliseconds)); 12:09:53 <TrueBrain> is what CSleep does 12:09:57 <TrueBrain> same compiler 12:10:05 <nielsm> something with timer resolutions possibly, which may be a per thread thing 12:10:20 <nielsm> in case SDL modifies something about that 12:10:27 <TrueBrain> I will have to debug it more in depth to get some more factuals 12:10:30 <TrueBrain> just a fun difference :D 12:11:59 <Samu> daium, a radious of 96 is super slow in 4096x4096 12:14:24 <Samu> there goes my scaling idea :( 12:17:00 <TrueBrain> I added TIC/TOC around CSleep .. Win32: 47,272,059 on average, SDL: 5,989,384 on average 12:17:05 <TrueBrain> that is a pretty high difference there :) 12:17:25 <TrueBrain> so yeah, something to do with timer resolution it seems like indeed :) 12:19:41 <_dp_> even I remember windows being weird with sleeps 12:19:51 <_dp_> and that's like 20 years ago I last touched any of it 12:22:36 <TrueBrain> I am comparing the SDL driver with Win32 driver, and you find these "fun" small differences that have no influence on the real game :) 12:22:48 <TrueBrain> like, on Win32, InteractiveRandom() is called a lot more often 12:22:55 <TrueBrain> (for every event, instead of once per loop) 12:23:36 *** iSoSyS has joined #openttd 12:23:50 <TrueBrain> code-wise, the SDL can get stuck in FF if you are FF-ing from a multiplayer game (is that possible?) and dropped in another game (very unlikely) 12:23:54 <TrueBrain> Win32 protects against that :P 12:26:45 <frosch123> does that include FF-ing to catch up with server? 12:28:01 <TrueBrain> if _fast_forward is on; it is either a case someone ran into on Win32 and fixed, or just pedanticness on the Win32s authors side :P 12:28:28 <TrueBrain> none of the other drivers have it 12:37:55 <milek7_> TrueBrain: timeBeginPeriod(1); 12:38:09 <milek7_> likely SDL does that 12:40:21 <milek7_> https://github.com/spurious/SDL-mirror/blob/e17aacbd09e65a4fd1e166621e011e581fb017a8/src/timer/windows/SDL_systimer.c#L44 12:41:55 <milek7_> and btw this was system-wide change until recently 12:42:51 <milek7_> https://randomascii.wordpress.com/2020/10/04/windows-timer-resolution-the-great-rule-change/ 12:42:56 <orudge> OpenTTD on arm64 Windows in a VM on an M1 Mac seems to work pretty well all things considered 12:43:10 <andythenorth> o_O 12:48:18 <LordAro> orudge: is it faster than andythenorth's i9? 12:48:27 <andythenorth> probably 12:48:42 <andythenorth> at least on a 4096x4096 map 12:48:49 <andythenorth> it's lolz that FFWD just doesn't on a large map 12:48:55 <andythenorth> I didn't know map size affected FPS so much 12:50:42 <DorpsGek> [OpenTTD/OpenTTD] orudge opened pull request #8583: Feature: Add ARM64 build for Windows https://git.io/JtkVj 12:51:32 <orudge> LordAro: can play around later. I suspect performance should be pretty similar to the native Mac ARM64 build. Which was considerably faster than anything Intelly I could find personally! 12:52:09 *** iSoSyS has quit IRC 12:52:13 *** arikover has joined #openttd 12:52:23 <andythenorth> iirc it's about 100x improvement in crude tests 12:52:34 <andythenorth> child is using the M1 currently so can't test 12:55:22 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain commented on pull request #8583: Feature: Add ARM64 build for Windows https://git.io/Jtkw8 12:56:07 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain commented on pull request #8583: Feature: Add ARM64 build for Windows https://git.io/Jtkw0 12:56:21 <TrueBrain> I like how one commit reads ARM64 the other arm64 :D 12:57:10 <frosch123> windows on arm64? never heard of that? is that the ms tablet? "surface" or something? 12:58:01 *** arikover` has joined #openttd 12:58:27 *** arikover has quit IRC 12:58:29 <TrueBrain> that is an interesting question: just because we can build it for releases, do we want to? :D 13:01:30 <nielsm> hmm there is an edition of windows that can run on some raspberry pi systems, iirc... 13:02:45 <frosch123> now that sounds like you want to build a binary for a system that noone has :p 13:05:53 <milek7_> there's Surface series, but HP/Lenovo/Asus/Samsung/Huawei have some devices too 13:06:27 <DorpsGek> [OpenTTD/OpenTTD] orudge commented on pull request #8583: Feature: Add ARM64 build for Windows https://git.io/JtkwF 13:08:43 <DorpsGek> [OpenTTD/OpenTTD] orudge commented on pull request #8583: Feature: Add ARM64 build for Windows https://git.io/Jtkwj 13:09:10 <DorpsGek> [OpenTTD/OpenTTD] orudge commented on pull request #8583: Feature: Add ARM64 build for Windows https://git.io/Jtkrv 13:10:42 <DorpsGek> [OpenTTD/OpenTTD] orudge updated pull request #8583: Feature: Add ARM64 build for Windows https://git.io/JtkVj 13:10:44 <TrueBrain> orudge: btw, if possible, mention which clang version it is, instead of "modern" 13:10:51 <TrueBrain> as "modern" doesn't age well :D 13:11:15 <orudge> That requires figuring out what version of clang supports it :D 13:11:24 <TrueBrain> yup ... that happens when you make these kind of changes ;) 13:11:58 <TrueBrain> we all know nobody is going to touch it for the next 5 years .. think about the future-you! :D 13:12:11 *** arikover` has quit IRC 13:14:39 <DorpsGek> [OpenTTD/OpenTTD] orudge updated pull request #8583: Feature: Add ARM64 build for Windows https://git.io/JtkVj 13:14:42 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain commented on pull request #8583: Feature: Add ARM64 build for Windows https://git.io/JtkrZ 13:15:17 <TrueBrain> sorry orudge , couldn't resist being a bit funny with my reply :P You can hit me in the face if you like :) 13:15:37 <DorpsGek> [OpenTTD/OpenTTD] orudge commented on pull request #8583: Feature: Add ARM64 build for Windows https://git.io/JtkrC 13:16:51 <TrueBrain> if you have suggestions how we can make the PR template more clear, we are mostly looking for a WHY, not a WHAT, please let us know :) 13:22:37 <DorpsGek> [OpenTTD/OpenTTD] orudge commented on pull request #8583: Feature: Add ARM64 build for Windows https://git.io/JtkrK 13:25:22 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain commented on pull request #8583: Feature: Add ARM64 build for Windows https://git.io/JtkrD 13:26:02 <DorpsGek> [OpenTTD/nml] FLHerne commented on pull request #183: Add support for recent NewGRF additions https://git.io/Jtkr9 13:39:32 *** sla_ro|master has quit IRC 13:40:39 <DorpsGek> [OpenTTD/OpenTTD] orudge updated pull request #8583: Feature: Add ARM64 build for Windows https://git.io/JtkVj 13:40:47 *** gnu_jj has joined #openttd 13:42:33 <TrueBrain> orudge: is that still WIP? As now I am confused .. didn't you add that for macOS? :D 13:42:38 <DorpsGek> [OpenTTD/OpenTTD] orudge commented on pull request #8583: Feature: Add ARM64 build for Windows https://git.io/Jtkou 13:43:32 <LordAro> orudge: neon intrinsics? 13:43:44 <orudge> TrueBrain: It should be working now :) 13:43:57 <orudge> LordAro: rough equivalent of SSE etc on ARM 13:44:07 <orudge> Whether there'd be much benefit, I'm not sure 13:44:12 <TrueBrain> orudge: but we are not testing the clang statement now, are we? As in, we produce windows binaries via MSVC, right? 13:44:17 <LordAro> ah yeah, that does sound familiar 13:44:49 <orudge> TrueBrain: for Windows, yes, it wouldn't use the clang stuff (though if you built with clang it would I suspect). I had put in the code for Mac at the same time, since I knew it was missing. 13:44:53 <orudge> Now I remembered why it was missing :) 13:44:59 <orudge> But it does work in Windows on a Mac, go figure 13:45:21 <orudge> Right, going to have to head off just now, will address any more comments later if any 13:45:35 <TrueBrain> yeah, I leave this rdtsc part for someone else :) I am a bit confused :P 13:45:41 <TrueBrain> reads to me it now adds code no target is using :D 13:46:03 <TrueBrain> but this says more about me than anything else, to be clear :D 13:49:13 <orudge> It can get used on any non-Apple clang platform 13:49:20 <orudge> Windows or Linux basically 13:49:30 <orudge> By default we use MSVC and gcc of course 13:49:39 <TrueBrain> which is Linux I guess, but that already has rdtsc code :) So I am not sure how we deal with that :D 13:49:40 <orudge> but users may not :) 13:50:07 <orudge> If gcc could support that intrinsic too one day it'd be handy 13:51:05 <TrueBrain> yeah .. our code used to be full of things that "might be handy" :D :D :) But okay, this is why someone else needs to look at this .. I don't understand enough to say it is good or not :) 13:55:45 <DorpsGek> [OpenTTD/OpenTTD] FLHerne left a comment on commit: Add: [NewGRF] Patch flag to test if inflation is on or off. https://git.io/JtkoN 13:56:00 <FLHerne> (sorry, deleted) 13:57:42 <michi_cc> TrueBrain: You assume we only have x86 Linux users? :p 13:57:42 *** DasPoseidon has joined #openttd 13:58:00 <TrueBrain> michi_cc: I do? 13:59:09 <DorpsGek> [OpenTTD/nml] FLHerne requested changes for pull request #183: Add support for recent NewGRF additions https://git.io/JtkKT 13:59:46 *** roadt_ has quit IRC 13:59:47 <TrueBrain> michi_cc: honestly, I don't even know what you are referring to :) 13:59:50 <FLHerne> frosch123: ^ reviewed 14:00:04 *** roadt_ has joined #openttd 14:00:14 <michi_cc> rdtsc code. Unless I'm missing it somewhere, we only have x86 Linux code, not generic Linux. 14:00:25 <FLHerne> How does (should?) this interact with vehicle_is_powered? 14:00:35 <TrueBrain> as I mentioned: I am confused, and that is a problem on my side. In result, I am going to leave this to others :) 14:01:01 <TrueBrain> knowing what you know and what you don't know is a valuable thing :) 14:02:00 <TrueBrain> michi_cc: #if (defined(__i386__) || defined(__x86_64__)) && !defined(RDTSC_AVAILABLE) <- that is executed on x64 isn't it? :) 14:02:19 <michi_cc> Yes, I was more thinking about MISC, RISC-V, SPARC or whatever :) 14:02:24 <michi_cc> *MIPS 14:02:35 <TrueBrain> which are indeed targets we support :P :P 14:02:37 <TrueBrain> :D 14:03:31 <orudge> I think Debian does build OpenTTD for some 14:03:34 <orudge> of those 14:03:54 <michi_cc> orudge: Is OpenGL a thing on ARM Windows? 14:05:43 <orudge> I assume so, can test 14:05:55 <milek7_> https://devblogs.microsoft.com/directx/announcing-the-opencl-and-opengl-compatibility-pack-for-windows-10-on-arm/ 14:05:58 <michi_cc> Seems, yes, but not really yes: https://devblogs.microsoft.com/directx/in-the-works-opencl-and-opengl-mapping-layers-to-directx/ 14:06:42 <michi_cc> Ah, OpenGL 3.3. See, targeting 3.2 as a general baseline wasn't a bad choice :) 14:06:50 <TrueBrain> michi_cc: :D :D 14:07:04 <TrueBrain> they are also working on OpenGL support in WSL2 ... very curious how that is going to be :) 14:07:19 <TrueBrain> (but also mapped to DirectX) 14:08:13 <michi_cc> They might even utilize the same software stack on the backend for it. 14:10:17 <TrueBrain> honestly can't wait for them to release that .. would make working on Windows even easier 14:11:58 <DorpsGek> [OpenTTD/OpenTTD] Milek7 commented on pull request #8583: Feature: Add ARM64 build for Windows https://git.io/JtkKo 14:21:31 <DorpsGek> [OpenTTD/OpenTTD] michicc commented on pull request #8583: Feature: Add ARM64 build for Windows https://git.io/JtkK7 14:29:59 <DorpsGek> [OpenTTD/OpenTTD] LordAro approved pull request #8540: Fix eeb88e8: Trains reversed while paused do not correctly update sprite bounds https://git.io/Jtk6Y 14:31:40 *** cyberjunkie[m] has left #openttd 14:32:40 *** glx has joined #openttd 14:32:40 *** ChanServ sets mode: +v glx 14:35:45 <TrueBrain> LordAro: \o/ 14:39:50 <milek7_> eh, it seems cross-platform nanosecond-precision timing is hard :P 14:40:10 <milek7_> even 14:40:49 <milek7_> even RDTSC as used currently is not entirely correct, as it doesn't check in cpuid that TSC have constant frequency 14:41:16 <glx> its main use is for local comparisons 14:41:50 <glx> at least in openttd 14:59:41 <DorpsGek> [OpenTTD/OpenTTD] orudge commented on pull request #8583: Feature: Add ARM64 build for Windows https://git.io/Jtki9 15:01:59 <DorpsGek> [OpenTTD/OpenTTD] michicc commented on pull request #8583: Feature: Add ARM64 build for Windows https://git.io/Jtkib 15:07:21 *** Flygon_ has quit IRC 15:08:48 <TrueBrain> michi_cc: pushed the first working version to my branch .. still need to check all commits and squash a few together 15:08:58 <TrueBrain> but I think it is working :D 15:10:13 <TrueBrain> pretty sure I forgot stuff and things break, but ... it-works-for-me :D 15:12:02 <michi_cc> I've got a tiny, probably windows only, fix coming in. Apparently, not setting VSync at all leads to glitches on my GPU in fullscreen. 15:12:24 <michi_cc> Interestingly it doesn't matter, if vsync is set to on or off, just that it is set at all. 15:13:07 <TrueBrain> lol 15:13:19 <TrueBrain> did you btw read in the backlog that Win32 CSleep takes a tiny bit long :P 15:13:34 <TrueBrain> I will make a separate ticket for it soon 15:13:39 <milek7_> did you see my links? 15:14:12 <TrueBrain> I did 15:14:22 <TrueBrain> owh, and I need to test 8bpp -> 32bpp blitter change 15:14:25 <TrueBrain> see if that works as intended .. 15:14:34 <michi_cc> TrueBrain: Probably https://randomascii.wordpress.com/2020/10/04/windows-timer-resolution-the-great-rule-change/ 15:14:58 <DorpsGek> [OpenTTD/OpenTTD] orudge updated pull request #8583: Feature: Add ARM64 build for Windows https://git.io/JtkVj 15:15:16 <TrueBrain> michi_cc: sounds about right 15:15:45 <TrueBrain> mouse feels really sluggish now 15:16:08 <TrueBrain> https://github.com/OpenTTD/OpenTTD/commit/81fdbd28db9d7b1b5611ec1873679f23c1650848 might interest you btw ... I DO NOT HAVE OCD! (I keep telling myself that :D) 15:17:15 <TrueBrain> and in good news, sdl_v.cpp no longer has globals; sdl_default_v.cpp does have a few left, but that is easily solved 15:17:51 <DorpsGek> [OpenTTD/OpenTTD] tpetazzoni opened issue #8584: Timetable "Start date" with shared orders setting dates in the past https://git.io/JtkPa 15:18:16 <TrueBrain> I still don't like that the last link I posted acts like it is a commit in OpenTTD upstream .. it is not 15:18:44 <michi_cc> Why the this-> change though, most code seems to use it for calling member functions? 15:18:50 <DorpsGek> [OpenTTD/OpenTTD] orudge commented on pull request #8583: Feature: Add ARM64 build for Windows https://git.io/JtkPo 15:18:54 <TrueBrain> btw, michi_cc , I would greatly appreciate it if you can look at https://github.com/TrueBrain/OpenTTD/commit/cbac32e115905b366447cc770e19722a822ef4f7, that I didn't do anything stupid. It should all look really familiar to you :) 15:19:09 <TrueBrain> michi_cc: owh, I looked it over and went for the one used least; did I miscalculate it? 15:19:34 <TrueBrain> seems I did .. I will change it to all this-> in that case :P 15:19:48 <TrueBrain> I really don't care which one :D 15:20:14 <michi_cc> The commit only removes this-> when calling the parent member function, but it is still a member function call. 15:20:30 <TrueBrain> sorry, I don't follow? 15:21:08 <michi_cc> i.e. - this->VideoDriver_Win32Base::Stop(); + VideoDriver_Win32Base::Stop(); 15:21:16 <michi_cc> But still e.g. this->DestroyContext(); 15:21:29 <TrueBrain> I just made the parent calls consistent 15:21:42 <TrueBrain> the "do this-> or not do this->" is not a discussion I want to have :P 15:21:49 <TrueBrain> but either all this-> or none, in my book :D 15:21:55 <TrueBrain> so pick one, and I will make it happen :) 15:24:18 <DorpsGek> [OpenTTD/OpenTTD] LordAro approved pull request #8583: Feature: Add ARM64 build for Windows https://git.io/JtkPd 15:24:37 <DorpsGek> [OpenTTD/OpenTTD] James103 commented on issue #8584: Timetable "Start date" with shared orders setting dates in the past https://git.io/JtkPa 15:25:52 <michi_cc> Scrolling through my win32_v, I'm only noticed one call that is missing a this->, everything else there has it. I've not look at all the other game code though right now. 15:26:16 <LordAro> this-> should be used everywhere 15:26:23 <LordAro> anywhere it is not is a mistake 15:26:23 <TrueBrain> so this-> it is :) 15:27:24 <TrueBrain> michi_cc: possibly I was just being blind :) 15:30:43 <milek7_> TrueBrain: SDL_GetWindowSurface seems intended for getting legacy structure for software blitting (sdl example calls SDL_Surface "// even with SDL2, we can still bring ancient code back") 15:30:45 <TrueBrain> okay, changed them all to this-> in SDL driver :) 15:30:53 <milek7_> it might be cleaner to use SDL_GetRendererOutputSize 15:31:22 <TrueBrain> I am a bit reluctant to change anything outside of "I am moving code", but I will put it on the list :) 15:31:54 <TrueBrain> trying really hard to avoid regressions :D 15:34:30 *** jottyfan has joined #openttd 15:35:13 <milek7_> and my nitpicky-technically-illegal-API-usage screams a bit about not using SDL_Lock/UnlockSurface without checking SDL_MUSTLOCK 15:35:24 <milek7_> *nitpicky-technically-illegal-API-usage-OCD 15:36:37 *** jottyfan has quit IRC 15:36:51 <TrueBrain> we are not using SDL_Lock? 15:37:05 <milek7_> no 15:38:15 <TrueBrain> as in, we are not using it .. so I do not understand at all what you just said 15:38:26 <TrueBrain> felt like random words :D Sorry :P It needs more context if you want us to do anything with it :) 15:38:41 <milek7_> ah, misunderstanding 15:38:45 <TrueBrain> if we are not using SDL_Lock, why should we check SDL_MUSTLOCK :P 15:38:46 <milek7_> we access surface directly 15:39:14 <milek7_> and sdl docs says "Between calls to SDL_LockSurface() / SDL_UnlockSurface(), you can write to and read from surface->pixels, using the pixel format stored in surface->format. Once you are done accessing the surface, you should use SDL_UnlockSurface() to release it. " 15:39:25 <milek7_> https://wiki.libsdl.org/SDL_LockSurface 15:39:35 <milek7_> and "Not all surfaces require locking. If SDL_MUSTLOCK(surface) evaluates to 0, then you can read and write to the surface at any time, and the pixel format of the surface will not change. " 15:39:48 <milek7_> but we neither use SDL_LockSurface nor check SDL_MUSTLOCK result 15:40:00 <TrueBrain> okay, existing problems are for another PR honestly :) 15:40:13 <TrueBrain> otherwise this will never come to any conclusion :D 15:40:41 <TrueBrain> I just moved code around, did not change the SDL flow (or rather, it should not have changed the SDL flow if I did my work properly) 15:41:51 <DorpsGek> [OpenTTD/OpenTTD] J0anJosep updated pull request #8480: Multitile depots https://git.io/JL5Hh 15:42:12 <TrueBrain> it is funny, michi_cc is now laughing, as he had the same issue with my remarks yesterday :P 15:43:03 <michi_cc> Give people a hand, and they will take the whole arm :D 15:43:19 <TrueBrain> something something scope 15:45:31 <milek7_> it's just a nitpick, doesn't really change anything on currently known sdl2 platforms ;P (but I know about it because it broke sdl1-emscripten...ugh, that wasted much time) 15:46:23 <milek7_> anyway, about previous issue: >I am a bit reluctant to change anything outside of "I am moving code", but I will put it on the list :) 15:47:03 <milek7_> I'm not talking about existing code here, it must use SDL_Surface anyway so it is fine 15:47:17 <milek7_> but about opengl variant: https://github.com/TrueBrain/OpenTTD/blob/opengl-sdl/src/video/sdl2_opengl_v.cpp#L64 15:48:09 <TrueBrain> owh, that should be SDL_GetWindowSize 15:48:54 <milek7_> I think SDL_GetRendererOutputSize is more correct 15:49:31 <TrueBrain> currently we use SDL_GetWindowSize on all other places for this 15:49:49 <milek7_> or maybe SDL_GL_GetDrawableSize 15:52:05 <TrueBrain> michi_cc: what is the best GRF to test 8bpp -> 32bpp blitter change with, any suggestions? :D 15:52:07 <milek7_> SDL_GetWindowSize won't be correct in future when we add SDL_WINDOW_ALLOW_HIGHDPI support 15:52:18 <michi_cc> zBase 15:52:30 <TrueBrain> milek7_: that is the correct wording :) And it will break other things too, as we use SDL_GetWindowSize all over the place 15:52:44 <TrueBrain> tnx michi_cc ! 15:52:52 <michi_cc> Start with ogfx and switch to zbase in the options. Possibly disabling 40bpp-anim in case you really want a 32bpp blitter. 15:53:50 <TrueBrain> hmm .. crash on finishing the download ... that doesn't sound good 15:55:31 <TrueBrain> wow .. switching ... just worked :o 15:55:50 <TrueBrain> I have to admit I was not really expecting that 15:56:20 <TrueBrain> zBase has no animation? 15:57:14 *** Gustavo6046 has quit IRC 15:59:48 <TrueBrain> hmm .. seems I am using wgl with SDL, funny :) 15:59:57 <TrueBrain> as in, wglGetProcAddress is used 16:00:00 <TrueBrain> did not expect that :D 16:00:08 <milek7_> what else it could use on windows? :P 16:01:24 <TrueBrain> owh, it is the only wgl function 16:01:25 <TrueBrain> interesting 16:04:11 <DorpsGek> [OpenTTD/OpenTTD] J0anJosep commented on pull request #8480: Multitile depots https://git.io/Jtk1R 16:06:17 <TrueBrain> michi_cc: found my way down my list: https://github.com/TrueBrain/OpenTTD/commit/34bd3a0e24756299b330312139a0689425289176 <- was this what you were asking for? 16:06:24 <TrueBrain> I didnt really understand your comment in the PR, honestly :) 16:06:33 <TrueBrain> couldn't find the commit where you changed it from egl to glX :) 16:07:36 <michi_cc> milek7_ mentioned it. Your change is yes and technically no, as you could have SDL AND some other video driver. So if SDL_GL_GetProcAddress is required, it would have to be a video driver function. 16:08:08 <milek7_> I meant to remove system #ifdefs from GetOGLProcAddress 16:08:15 <milek7_> and instead use virtual method in driver 16:09:19 <michi_cc> Well, is SDL_GL_GetProcAddress internally doing anything special? I'm not that keen on having the OpengL backend call back into the video driver frontend. 16:09:38 <TrueBrain> michi_cc: it worked fine with wgl, and by the tests the other day, also with the glX, so required seems to be a no :) 16:09:44 <milek7_> I think it's just calling wgl internally 16:09:58 <milek7_> on windows 16:10:30 <milek7_> but I think it is bit dirty to call GetProcAddress behind SDL back, as SDL knows what API is used 16:10:32 <michi_cc> Yes, in the end it must call wgl, I was just wondering if it does any pre- or post-processing. 16:11:08 <TrueBrain> https://github.com/spurious/SDL-mirror/blob/60ea77f4944ceb85b4b663b83ca2f8acf2254f8d/src/video/SDL_video.c#L3028 16:11:32 <milek7_> and defining glXGetProcAddress unconditionally on unix in our code is not entirely correct 16:11:56 <milek7_> it could fail when using pure-wayland environment 16:12:09 <milek7_> (as it should use EGL then) 16:12:56 <TrueBrain> michi_cc: the main difference seems to be that SDL_GL_GetProcAddress first tries wglGetProcAddress and if that fails uses GetProcAddress 16:13:00 <TrueBrain> inside the DLL 16:13:11 <michi_cc> For modern Linux at least I think all functions internally end up in libglvnd, no matter if glx or egl. 16:13:45 <michi_cc> But okay, to be really correct, get proc needs to be a video driver callback. 16:15:10 <TrueBrain> for X11 there are 2 flows, GL and GLES 16:15:13 <TrueBrain> the first is what you have now 16:15:18 <TrueBrain> the second it uses SDL_EGL_GetProcAddress 16:15:32 <TrueBrain> which loads a DLL (lol .. think they named that poorly) and looks up the proc there 16:15:43 <TrueBrain> the egl_dll, that is 16:16:17 <TrueBrain> seems the latter is mostly for Android 16:16:36 <TrueBrain> if that helps :) 16:17:14 <milek7_> depending on driver, you can use GLES context on desktop too 16:17:37 <TrueBrain> hence the word "mostly" 16:18:13 <milek7_> on windows, you can use that https://github.com/google/angle to translate that into DX11 16:18:56 *** Wolf01 has joined #openttd 16:18:59 <milek7_> I wanted to add GLES support after this is merged :) 16:19:00 <TrueBrain> michi_cc: if you are looking into making a callback back to the driver, maybe better to let the driver give a function to the backend on init? 16:21:27 <Samu> how do I remove a file from the project, need to see an example 16:23:34 <TrueBrain> right, my todo list: clean up header-includes (I have too many now :D), clean up some commits ... that is something for tomorrow :D 16:27:17 <milek7_> your branch is missing #include <condition_variable> 16:28:14 <DorpsGek> [OpenTTD/OpenTTD] orudge dismissed a review for pull request #8583: Feature: Add ARM64 build for Windows https://git.io/JtkPd 16:28:16 <milek7_> and warnings: https://gist.github.com/Milek7/a0d22d24f268d37bf7115d990647d8c6 16:28:17 <DorpsGek> [OpenTTD/OpenTTD] orudge updated pull request #8583: Feature: Add ARM64 build for Windows https://git.io/JtkVj 16:30:10 <DorpsGek> [OpenTTD/OpenTTD] orudge commented on pull request #8583: Feature: Add ARM64 build for Windows https://git.io/JtkMg 16:31:40 <Samu> how to properly remove the file. https://github.com/OpenTTD/OpenTTD/commit/10f72636a75b609fff6d7d805f2f2252ab0961c4 16:31:45 <Samu> need tips 16:33:10 <LordAro> have you tried removing it? 16:33:46 <andythenorth> rm -rf * . 16:33:56 * andythenorth gets kicked 16:34:47 <TrueBrain> andythenorth: yeah, please don't say that again ... you know there is a chance he might try .. 16:35:01 <andythenorth> then we learn about pasting commands from the internet 16:35:03 <andythenorth> life lessons 16:37:25 <andythenorth> hmm have I improved my GPU performance? 16:39:14 <andythenorth> Photoshop was allocated 4GB of VRAM 16:39:20 <andythenorth> which is all the VRAM 16:50:40 <glx> Samu: just delete the file, in some cases you may need to also update CMakeList.txt (but cmake will tell you if it's required) 17:02:38 <DorpsGek> [OpenTTD/website] orudge opened pull request #183: Feature: List Windows ARM64 binaries correctly, autodetect ARM64 Windows https://git.io/Jtk9e 17:04:16 <DorpsGek> [OpenTTD/website] LordAro approved pull request #183: Feature: List Windows ARM64 binaries correctly, autodetect ARM64 Windows https://git.io/Jtk9Z 17:09:51 *** sla_ro|master has joined #openttd 17:14:02 <DorpsGek> [OpenTTD/website] orudge merged pull request #183: Feature: List Windows ARM64 binaries correctly, autodetect ARM64 Windows https://git.io/Jtk9e 17:24:33 <Samu> i don't see any warning from cmake, but maybe I don't know where to look 17:24:44 <DorpsGek> [OpenTTD/website] orudge opened pull request #184: Fix: Autodetect macOS correctly https://git.io/JtkHv 17:28:25 *** Gustavo6046 has joined #openttd 17:29:50 <DorpsGek> [OpenTTD/OpenTTD] orudge opened pull request #8585: Fix: [Actions] Give Universal Mac packages the "universal" suffix https://git.io/JtkHO 17:31:17 *** Gustavo6046 has quit IRC 17:32:26 *** snail_UES_ has joined #openttd 17:41:09 <Samu> Can you spot the differences in the desert perimeter? https://i.imgur.com/XuLYhvF.png 17:41:22 <Samu> they exist, but I tried my best to minimize them 17:41:49 *** arikover has joined #openttd 17:45:06 *** arikover` has joined #openttd 17:46:38 *** Wormnest has joined #openttd 17:50:26 *** arikover has quit IRC 17:52:39 <DorpsGek> [OpenTTD/OpenTTD] michicc updated pull request #7744: Draft Feature: OpenGL video driver https://git.io/JeO8B 17:52:47 <michi_cc> Okay, enough faffing around for right now. 17:53:31 <michi_cc> TrueBrain: There was a bug affecting fullscreen toggle in that the window size was wrong after repeated toggling. Also, callback function for GetProcAddress now. 17:53:48 <michi_cc> Hmm, and maybe we can reduce the size if this a tiny bit. 17:53:58 *** Gustavo6046 has joined #openttd 17:54:29 <DorpsGek> [OpenTTD/OpenTTD] michicc opened pull request #8586: Codechange: [Win32] Window driver cleanup https://git.io/JtkdU 17:54:54 <michi_cc> TrueBrain: I've picked most of your Win32 stuff. If you want, you can tack on SDL to the new PR. 18:13:07 <DorpsGek> [OpenTTD/OpenTTD] michicc updated pull request #7744: Draft Feature: OpenGL video driver https://git.io/JeO8B 18:24:06 <TrueBrain> michi_cc: will do; and this week I will PR the cleanups of SDL too, so OpenGL becomes lovely small and simple :) 18:25:05 <michi_cc> Now on to faffing with OSX..... 18:27:03 <michi_cc> Look at AllocateBackingStore and ToggleFullscreen specifically. 18:30:39 <milek7_> btw. I'm wondering 18:30:39 <milek7_> opengl1.1 functions are exported in windows (such as eg. glEnable) in opengl32.dll and can be linked directly 18:30:39 <milek7_> but wglGetProcAddress docs make it clear that returned pointers are valid only for current context, because different drivers can be selected in runtime 18:30:39 <milek7_> yet these functions linked from opengl32.dll obviously are called the same for all possible drivers 18:30:45 <milek7_> so, how does that work? 18:35:35 <nielsm> possibly they have a shim function exported that does something appropriate? 18:35:52 <michi_cc> opengl32 will call into a driver table 18:36:23 <michi_cc> Just like e.g. libGL on Linux. The exported function all just call into a dispatch table. 18:36:37 <milek7_> but then what's the point of having wglGetProcAddress return context-specific pointer? they could just use the same facility for dynamic dispatch 18:37:17 <nielsm> performance, probably, by having slightly less indirect calls 18:38:03 <michi_cc> If wglGetProcAddress would return context-free pointers, Windows would need to know all possible extensions that could ever exists in any driver. 18:39:46 <DorpsGek> [OpenTTD/OpenTTD] DorpsGek pushed 1 commits to master https://git.io/JtkFX 18:39:47 <DorpsGek> - Update: Translations from eints (by translators) 18:40:09 <michi_cc> By directly returning pointers to the driver, new OpenGL versions and extensions can be supported without Windows updates. 18:45:52 <DorpsGek> [OpenTTD/OpenTTD] LordAro approved pull request #8586: Codechange: [Win32] Window driver cleanup https://git.io/JtkFp 18:57:14 <michi_cc> LordAro is to blame if everything explodes :) 18:57:20 <DorpsGek> [OpenTTD/OpenTTD] michicc merged pull request #8540: Fix eeb88e8: Trains reversed while paused do not correctly update sprite bounds https://git.io/JLpdb 18:57:40 <DorpsGek> [OpenTTD/OpenTTD] michicc merged pull request #8586: Codechange: [Win32] Window driver cleanup https://git.io/JtkdU 18:59:27 <LordAro> :o 19:09:06 <TrueBrain> if something goes wrong and you are smiling, you have someone else to blame! 19:16:25 <andythenorth> oh 19:16:42 <andythenorth> what if I just repaint the 'refit in depot' button to be 'liveries' and change the tool tips? 19:16:45 <andythenorth> does that work? 19:17:16 *** iSoSyS has joined #openttd 19:27:26 <andythenorth> this new interface is so much better 19:27:35 <andythenorth> just removing the 'location' buttons makes everything seem simpler 20:14:50 <Samu> what's the difference between std::list and std::map 20:15:27 <glx> https://en.cppreference.com/w/cpp/container 20:17:08 <TrueBrain> andythenorth: but but but <insert 4 pages of comments here, most related but not addressing the location button> 20:17:33 <andythenorth> I don't know what you're referring to, no idea, no clue, not the faintest or foggiest 20:17:41 <andythenorth> where would that ever happen? 20:18:59 <Samu> i think std::list is slow for what I wanna do 20:19:03 <Samu> im unsure 20:19:34 <michi_cc> More often than not you want std::vector anyway. 20:20:19 <Samu> testing std::vector 20:20:37 <Samu> i thought i couldn't use an iterator with std::vector 20:22:01 <andythenorth> I should add to my pony list 20:22:14 <andythenorth> cargo payment multiplier 20:22:50 <DorpsGek> [OpenTTD/OpenTTD] michicc commented on pull request #8578: Fix: Stopped ships shouldn't block depots https://git.io/JtkpD 20:23:03 * andythenorth wants shiny vehicles to pay more 20:26:43 <DorpsGek> [OpenTTD/OpenTTD] michicc commented on pull request #8576: Feature: Allow GameScripts to add additional text to Industry view window https://git.io/JtkhJ 20:29:12 *** Wormnest has quit IRC 20:30:06 <andythenorth> sometimes the stereo mix in OpenTTD makes me smile 20:30:20 <andythenorth> when a bunch of train whistles sound from different left / right locations 20:33:46 <Samu> is there anything faster than std::vector? 20:33:56 <Samu> i'm only iterating 20:42:14 *** ChanServ sets mode: +o orudge 20:44:43 <Samu> what does it mean qualified name is not allowed 20:47:07 <Samu> nevermind, vector will do 20:58:31 <nielsm> std::vector is the fastest there is, when you need to visit the elements in order and process most or all of them 21:00:41 <nielsm> there's some types of manipulating the collection (inserting/removing/moving around elements) that will be more efficient in other containers, but pretty much try a vector first and if it just doesn't work out then go looking for something else 21:00:45 *** argoneus has quit IRC 21:00:58 *** argoneus has joined #openttd 21:02:42 <Samu> couldn't tell much of a difference in release mode between std::list and std::vector 21:02:49 <Samu> only in debug mode 21:02:56 <Samu> they're both horribly slow in debug 21:03:07 <Samu> but still, vector was faster 21:03:31 <LordAro> MSVC containers are known to be horribly slow in debug mode 21:03:51 <LordAro> but we don't care about debug mode performance (well, barely) 21:04:58 <Samu> wanna take a peek at what I'm working on? https://github.com/OpenTTD/OpenTTD/compare/master...SamuXarick:max-desert-height 21:05:32 <Samu> the vector is at line 998 21:05:34 <nielsm> std::list is a doubly linked list, it will use much more memory per element (two pointers worth extra) and will typically be very bad for the CPU cache performance, it has some theoretical benefits in being able to insert an element into the list at any position in constant time (no need to move existing elements around in memory) but the performance loss from cold cache will often outweigh 21:05:34 <nielsm> that 21:06:42 <nielsm> std::list might make sense if your individual elements in the collection are value types (not pointers) that are individually large, and you often need to insert/remove elements from the beginning or middle of the list 21:07:09 <Samu> i don't need to remove elements 21:07:22 <Samu> only need to insert, and it doesn't matter where it goes 21:07:39 <Samu> will only need to iterate over them all 21:07:49 <nielsm> then vector is by far the best choice 21:08:56 *** crem1 has joined #openttd 21:09:00 <Samu> iterators are at line 1038 and 1059 21:10:28 <nielsm> the reason all STL containers are crazy slow in debug builds in MSVC is because the debug mode enables iterator debugging and checking, so every time you move or access an iterator it does a thorough check that you aren't violating bounds of the container and much more 21:10:45 *** crem has quit IRC 21:11:53 <nielsm> that makes everything slow, but will catch many programming errors that might not be caught by an optimized iterator before it's far too late (and then it will probably just cause silent memory corruption or wrong looping, or if you're lucky maybe just crash the program) 21:12:39 <andythenorth> nielsm hi :) 21:13:18 <Samu> this is still a costly operation 21:14:26 <Samu> I tried to make the boundaries where it checks where to place desert or rainforest, to be scallable 21:15:03 <Samu> turns out I can't scale that much, it slows down too much 21:16:01 <nielsm> try working out how many tiles you'll be working on in some concrete cases 21:16:06 <nielsm> and compare 21:16:44 <Samu> looking at the genland.h data, it had a look of a circumference of about 6 tiles radius around the center 21:17:08 <nielsm> if you're just scaling up by map size, then remember that a 4096x4096 map has 16x as many tiles as a 256x256 map 21:17:48 <TrueBrain> @calc 4096*4096/256/256 21:17:48 <DorpsGek> TrueBrain: 256 21:17:56 <Samu> for every tile in the map, it looks into the tiles inside the circumference 21:17:56 <TrueBrain> I was about to say, that can't be right :D 21:18:19 <nielsm> hmm.. yeah that's 16x on *one* edge, forgot to square 21:18:23 <Samu> becomes costly if the radius is too large 21:19:08 <Samu> this is the radius I went with: uint radius = std::min(MapLogX(), MapLogY()) - 1; 21:19:26 <Samu> ScaleByMapSize1D was horribly slow 21:20:16 <nielsm> yes, and area of a circle scaled by square of the radius, so if you double the radius you get four times as much area, and if you make the radius 16 times larger you get 256 times as much area 21:20:41 <nielsm> any geometric shape you scale will behave like that 21:22:58 <nielsm> I have no idea what exactly you're doing, and I don't have any intention of putting time into looking into it, but you probably need to find some more efficient algorithms that scale better 21:24:10 *** sla_ro|master has quit IRC 21:27:56 <Samu> I'm making circumferences that scale :p 21:27:59 <Samu> hehe 21:31:15 <Samu> I'll show you, let me take a screenshot 21:31:25 <nielsm> I'm not going to look at it 21:31:28 <Samu> :( 21:31:29 <nielsm> in fact I'm going to bed now, good night 21:31:38 <Samu> ok gn 21:31:40 <TrueBrain> sleep well nielsm :) 21:36:03 <Samu> the distance between sea and desert is this "scalable radius" I worked upon: https://i.imgur.com/DuzsRG2.png 21:38:44 *** WormnestAndroid has quit IRC 21:38:59 *** WormnestAndroid has joined #openttd 21:39:11 <DorpsGek> [OpenTTD/OpenTTD] Matias-Barrios commented on issue #8582: Content Downloading does not work https://git.io/JtkW8 21:39:30 *** nielsm has quit IRC 21:39:47 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain closed issue #8582: Content Downloading does not work https://git.io/JtkW8 21:41:55 <Samu> thicker green borders https://i.imgur.com/fLSXZ4a.png 21:45:39 *** Wolf01 has quit IRC 21:48:44 *** arikover` has quit IRC 21:54:04 *** Samu has quit IRC 21:55:15 *** Markk_ is now known as Mark 22:03:22 *** Mark is now known as markk 22:03:30 *** markk is now known as Markk 22:03:32 *** WormnestAndroid has quit IRC 22:04:03 *** WormnestAndroid has joined #openttd 22:07:01 *** frosch123 has quit IRC 22:19:09 <DorpsGek> [OpenTTD/OpenTTD] LC-Zorg commented on pull request #8566: Move "town name" selection into map generator GUI https://git.io/JtIfd 22:20:20 *** iSoSyS has quit IRC 22:22:12 *** Progman has quit IRC 22:46:56 *** andythenorth has quit IRC 22:48:57 <TrueBrain> hadn't seen frosch123 made another awesome PR :D 22:54:26 <TrueBrain> seems he has new ambition :D 23:05:34 *** supermop_Home_ has joined #openttd 23:10:28 <michi_cc> Removing "re 23:10:32 <DorpsGek> [OpenTTD/OpenTTD] michicc updated pull request #7744: Draft Feature: OpenGL video driver https://git.io/JeO8B 23:10:39 <michi_cc> dundant" commits :) 23:13:06 *** tokai has joined #openttd 23:13:06 *** ChanServ sets mode: +v tokai 23:19:55 *** tokai|noir has quit IRC