Log for #openttd on 17th January 2021:
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
05:18:38  <DorpsGek> [OpenTTD/OpenTTD] James103 commented on issue #8582: Content Downloading does not work
05:30:35  <DorpsGek> [OpenTTD/OpenTTD] Matias-Barrios commented on issue #8582: Content Downloading does not work
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
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
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_>
12:41:55  <milek7_> and btw this was system-wide change until recently
12:42:51  <milek7_>
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
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
12:56:07  <DorpsGek> [OpenTTD/OpenTTD] TrueBrain commented on pull request #8583: Feature: Add ARM64 build for Windows
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
13:08:43  <DorpsGek> [OpenTTD/OpenTTD] orudge commented on pull request #8583: Feature: Add ARM64 build for Windows
13:09:10  <DorpsGek> [OpenTTD/OpenTTD] orudge commented on pull request #8583: Feature: Add ARM64 build for Windows
13:10:42  <DorpsGek> [OpenTTD/OpenTTD] orudge updated pull request #8583: Feature: Add ARM64 build for Windows
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
13:14:42  <DorpsGek> [OpenTTD/OpenTTD] TrueBrain commented on pull request #8583: Feature: Add ARM64 build for Windows
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
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
13:25:22  <DorpsGek> [OpenTTD/OpenTTD] TrueBrain commented on pull request #8583: Feature: Add ARM64 build for Windows
13:26:02  <DorpsGek> [OpenTTD/nml] FLHerne commented on pull request #183: Add support for recent NewGRF additions
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
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
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.
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
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_>
14:05:58  <michi_cc> Seems, yes, but not really yes:
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
14:21:31  <DorpsGek> [OpenTTD/OpenTTD] michicc commented on pull request #8583: Feature: Add ARM64 build for Windows
14:29:59  <DorpsGek> [OpenTTD/OpenTTD] LordAro approved pull request #8540: Fix eeb88e8: Trains reversed while paused do not correctly update sprite bounds
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
15:01:59  <DorpsGek> [OpenTTD/OpenTTD] michicc commented on pull request #8583: Feature: Add ARM64 build for Windows
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
15:14:58  <DorpsGek> [OpenTTD/OpenTTD] orudge updated pull request #8583: Feature: Add ARM64 build for Windows
15:15:16  <TrueBrain> michi_cc: sounds about right
15:15:45  <TrueBrain> mouse feels really sluggish now
15:16:08  <TrueBrain> 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
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
15:18:54  <TrueBrain> btw, michi_cc , I would greatly appreciate it if you can look at, 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
15:24:37  <DorpsGek> [OpenTTD/OpenTTD] James103 commented on issue #8584: Timetable "Start date" with shared orders setting dates in the past
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_>
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
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:
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
16:06:17  <TrueBrain> michi_cc: found my way down my list: <- 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>
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 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
16:28:16  <milek7_> and warnings:
16:28:17  <DorpsGek> [OpenTTD/OpenTTD] orudge updated pull request #8583: Feature: Add ARM64 build for Windows
16:30:10  <DorpsGek> [OpenTTD/OpenTTD] orudge commented on pull request #8583: Feature: Add ARM64 build for Windows
16:31:40  <Samu> how to properly remove the file.
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
17:04:16  <DorpsGek> [OpenTTD/website] LordAro approved pull request #183: Feature: List Windows ARM64 binaries correctly, autodetect ARM64 Windows
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
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
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
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?
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
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
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
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
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
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
18:57:40  <DorpsGek> [OpenTTD/OpenTTD] michicc merged pull request #8586: Codechange: [Win32] Window driver cleanup
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>
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
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
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?
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:
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
21:39:30  *** nielsm has quit IRC
21:39:47  <DorpsGek> [OpenTTD/OpenTTD] TrueBrain closed issue #8582: Content Downloading does not work
21:41:55  <Samu> thicker green borders
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
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
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

Powered by YARRSTE version: svn-trunk