IRC logs for #openttd on OFTC at 2020-06-10
⏴ go to previous day
00:29:24 *** grossing has joined #openttd
01:15:49 <DorpsGek_III> [OpenTTD/OpenTTD] vineet131 opened issue #8213: Crash while maximizing the window on first run after compilation https://git.io/JfyF0
05:41:49 <DorpsGek_III> [OpenTTD/OpenTTD] techgeeknz left a comment on commit: Cleanup: Give `SetDirtyBlocks` a more descriptive name. https://git.io/JfSJl
06:14:33 *** Wormnest has joined #openttd
06:30:59 *** m1cr0m4n has joined #openttd
06:31:43 *** lastmikoi has joined #openttd
08:11:45 *** sla_ro|master has joined #openttd
08:13:52 *** arikover has joined #openttd
08:15:05 *** andythenorth has joined #openttd
10:12:24 <DorpsGek_III> [OpenTTD/OpenTTD] techgeeknz opened pull request #8214: WIP: Refactor gfx engine's dirty block system https://git.io/JfS3n
10:14:34 *** gelignite has joined #openttd
10:15:34 <DorpsGek_III> [OpenTTD/OpenTTD] techgeeknz updated pull request #8214: WIP: Refactor gfx engine's dirty block system https://git.io/JfS3n
12:37:54 *** gelignite has joined #openttd
12:37:54 <planetmaker> I just explained that jfs and andythenorth are not the morons in one of the threads :P
12:45:28 <planetmaker> oh, that funny thread where *some guy* wants to explain that they don't understand why there is a NewGRF limit :P
12:50:08 <Timberwolf> My sarcastic side would go for, "cool, as you understand the problem why not submit a PR to fix it?" but that's probably just feeding the troll :)
12:54:12 <planetmaker> well... my reply might have included something of such salt :P
12:54:27 <planetmaker> especially as the guy stressed that he has an IT background and understands the isuse :P
13:01:43 <_dp_> planetmaker, I don't see your reply, you sure you actually posted it?
13:02:39 <planetmaker> no, I didn't. I sent a private message.
13:11:24 <planetmaker> not always good to do moderation in public :)
13:15:38 *** snail_UES_ has joined #openttd
13:28:51 *** WormnestAndroid has quit IRC
13:29:04 *** WormnestAndroid has joined #openttd
13:30:41 *** WormnestAndroid has joined #openttd
13:44:46 <andythenorth> I assumed good intent and low knowledge
13:44:53 <andythenorth> maybe I got those the wrong way around
13:45:08 <andythenorth> but it's a starting point of sorts
13:52:05 <supermop_Home> ugh remote workstation not responsive - going to have to go into the office to restart it
13:53:07 <planetmaker> I can at least confirm the latter point, judging from a follow-up reply
13:57:07 <planetmaker> just to satisfy my curiosity: on the bug tracker on github, could I, in principle, mark an issue as private or non-public in case that it contains (essential) private information?
13:57:36 <LordAro> planetmaker: i believe so
13:57:52 <planetmaker> can you show me how? I was looking for 30 minutes without success
14:00:22 <planetmaker> good that you arrived at the same place independently :)
14:00:51 <LordAro> can possibly move an issue to a private repo
14:09:20 <supermop_Home> andythenorth indeed
14:09:33 <supermop_Home> lucky for me the office is only 10 min away
15:32:33 <FLHerne> planetmaker: Do you know how JGR does it?
15:32:51 <FLHerne> I remember there was a patch that raised the limit only for local games
15:33:14 <FLHerne> But apparently you can have 255 grfs on a JGR server, so...?
15:33:23 <FLHerne> Maybe they're just not shown in the server list
15:33:43 <planetmaker> it might work, if you configure your client properly... dunnow
15:36:50 <LordAro> i don't think you can have 255 grfs on a server
15:39:28 <LordAro> which builds on a few other patches
15:45:01 <FLHerne> tbh, it seems a bit unfair to the forum guy to insist that it's technologically impractical
15:45:15 <FLHerne> when there's an existing patch for it :p
15:45:29 <LordAro> no one's said it's technologically impractical
15:45:42 <LordAro> forum guy just seems to think that people have told him that
15:59:06 <planetmaker> yes... such was not implied
16:29:54 <FLHerne> I just feel these threads always lead to browbeating the questioner with the details of the current implementation, as if that implies it's an invalid suggestion
16:30:24 <FLHerne> Obviously they know the limit currently exists, or they wouldn't ask
16:32:01 <LordAro> FLHerne: the issue is they seem very confused about *why* the limit exists, and was refusing to acknowledge anything else when explained to them
16:33:48 *** snail_UES_ has joined #openttd
16:34:05 <FLHerne> I don't think that's a fair reading
16:34:16 <planetmaker> tbh, I read it like that, too
16:34:44 <FLHerne> jfs explained it was a network limitation, questioner said networks are pretty fast these days
16:35:08 <planetmaker> jfs explained that it was a network *protocol* limitation
16:35:15 <FLHerne> Auge's post then immediately rolls out a ton of jargon to basically say "it doesn't work that way atm"
16:36:22 <FLHerne> Yes, up to there the thread is fine
16:37:10 <FLHerne> Hm, no, it's jfs with the jargon as well
16:37:16 <planetmaker> and in the follow up it was shown that the explanation was not understood at all
16:38:34 <FLHerne> Again, I don't think understanding the technical reason is really at issue
16:39:20 <andythenorth> responding to suggestions is best approached as judo
16:39:28 <FLHerne> Perhaps they don't understand it, but it's just another form of "but it doesn't work like that *now*", which is frankly a pointless response
16:39:29 <andythenorth> that didn't quite happen here
16:40:28 <nielsm> I try to always give a non-technical summary/conclusion, at least it's my intention to
16:40:34 <FLHerne> So the guy keeps reiterating that it *could* be done, at which point people start attacking him for ignoring the implementation details that aren't especially relevant
16:40:35 <nielsm> even if it's also backed up by a technical explanation
16:41:02 <FLHerne> Not sure I'm making my point clearly
16:41:37 <FLHerne> - The suggestions forum shouldn't only be for people who can write a patch to implement their suggestion
16:41:46 <FLHerne> (because that's "OpenTTD Development")
16:41:58 <andythenorth> FLHerne I know what point you're making, it's not unclear to me
16:42:36 <FLHerne> - Rejecting suggestions because the current codebase doesn't support them is silly, because it's inherently true to one extent or another
16:42:43 <nielsm> implicit in my answers was also "we know it's a problem, we know it can be fixed, we have an outline of how it can be fixed, but it's more work than anyone is willing to put in right now and is considered low priority"
16:42:53 <planetmaker> FLHerne, I don't think anyone rejected the suggestion either
16:43:12 <andythenorth> nothing is accepted or rejected in suggestions forum :)
16:43:14 <nielsm> maybe I should just have written that
16:43:42 <planetmaker> What I do believe could have been said more clearly, perhaps upfront is like "thank you for the suggestion, it's a good one, it's possible, but it needs some changes no-one did implement so far in a satisfying way"
16:43:56 <andythenorth> (I made the video years ago)
16:43:59 <planetmaker> and then the explanation with network protocol etc
16:44:06 <FLHerne> planetmaker: I think it's "Please don't try to argue network protocols if..." where it really goes wrong
16:44:07 <nielsm> what I take issue with is responses like: "many games can transfer much more data between computers than what openttd can. warcraft 3 for example have room for 8 megabytes of custom data including graphics. that is much more than openttd sends."
16:44:17 <andythenorth> oh they cut the sound :(
16:44:19 <FLHerne> They were never trying to "argue network protocols"
16:44:30 <nielsm> that indicates to me the poster is blaming the current state of openttd and past development for being bad
16:44:46 <nielsm> blaming past developers for not having done it The Correct Way from the beginning
16:45:05 <planetmaker> FLHerne, but they are like "it must be done and why isn't it?! It all goes slow because of large maps"
16:45:15 <andythenorth> yes that riled me, but if you stop a minute
16:45:17 <nielsm> s/indicates to me/reads to me as/
16:45:19 <andythenorth> they're so far from reality
16:45:25 <andythenorth> that it doesn't matter what they say
16:45:32 <andythenorth> so we give them the benefit of the doubt
16:45:39 <planetmaker> which is also quite beside the point of what he tried to argue in the first place... So it's at least failure to communicate on both sides
16:45:43 <andythenorth> it's probably a 10 year old
16:46:02 <planetmaker> tbh, when *I* read it, I thought like "c'mon... get a grip and just let it slide"
16:47:15 <planetmaker> for both, actually, jfs' answer with "please don't try to argue..." and the reply to that as well...
16:47:43 <planetmaker> if one wants to start arguing details... then one has to be able to be a bit... more willing to accept an argument
16:47:57 <planetmaker> and not take everything personally straight away
16:48:01 <andythenorth> I rarely go in suggestions forum :)
16:48:14 <andythenorth> it's the equivalent of a below-the-fold comment section
16:48:57 <andythenorth> we have to have it though
16:51:44 <Timberwolf> I think people too easily confuse "suggestions" as "tickets for development"
16:53:33 <andythenorth> it's a mismatched social contract
16:53:33 <Timberwolf> Also after 15+ years it's hard to come up with a suggestion that is novel and appropriate, but also not implementable through NewGRF and/or GS.
16:53:43 <andythenorth> Timberwolf challenge :D
16:55:40 <Timberwolf> "expose player-available feature xyz to GS" is probably the best chance of finding an agreed-useful suggestion that someone cares enough to implement :)
16:55:59 <_dp_> pfft, what I come up with is quite often not implementable :p
16:56:22 <_dp_> Timberwolf, have you actually used GS? it sucks for pretty much everything
16:56:50 <Timberwolf> Yeah, I find myself working around things a lot.
16:57:08 <andythenorth> _dp_ we should get a newsletter :)
16:57:18 <Timberwolf> It does work, but my recollection is a lot of contracts that don't quite line up between different areas.
16:57:19 <andythenorth> we're becoming a broken record
16:57:32 <andythenorth> the channel will start auto-kicking us when we type 'GS'
16:58:00 <_dp_> andythenorth, yeah, and a certain someone when he types "newgrf" :p
16:58:03 <Timberwolf> I can't remember what it was where I was getting something from one place for the Villages Is Villages economic stuff and going, "argh, why does this use a completely different format"?
16:58:57 <Timberwolf> The underlying answer is probably going to involve various combinations of "Chris Sawyer", "486", "4MB" and "data structure" in most cases.
17:02:51 <DorpsGek_III> [OpenTTD/OpenTTD] JGRennison commented on pull request #8214: WIP: Refactor gfx engine's dirty block system https://git.io/JfSoP
17:14:00 *** Wormnest has joined #openttd
17:20:11 <milek7> >pull requests submitted will be reviewed, and if good enough quality will be merged.
17:20:20 <milek7> well, do you really want to review such patchsets? ;p
17:33:28 <nielsm> narrow in scope and fixes a real problem? sure
17:33:38 *** virtualrandomnumber has joined #openttd
17:34:29 <glx> #8210 needs a review btw :)
17:41:16 <milek7> but what's real problem? 59 grfs? 64 cargos? 16 companies? all of it, none?
17:45:15 <glx> and finally only one type of train is built at the end ;)
17:57:58 <nielsm> just for the heck of it I tried adding more or less all the train newgrfs I have around, just to see what the vehicle selection would look like: https://0x0.st/iVva.mp4
17:58:06 <nielsm> I'm not sure why anyone would want to do that
18:00:36 <nielsm> not to mention the cost balancing act having multiple vehicle sets loaded is, all of them are internally balanced differently, so playing "rationally" (for maximum profit) usually one of the loaded sets will be preferrable to the rest and then the rest may as well not be there anyway
18:07:55 <planetmaker> nielsm, on a huge map with many companies, and company-limitation on which vehicles to build... it might make sense. You can also hide vehicles to make it then bearable again for the single companies
18:10:16 <_dp_> oh, I recently had an idea where it makes perfect sense actually
18:10:45 <_dp_> have like rpg server that runs about forever and takes a lot of grind to unlock stuff like new vehicles
18:11:34 <_dp_> though that will run into max company problem way sooner than into grf limit xD
18:12:15 <nielsm> so you're saying we should be working on the 250 companies patch
18:12:28 <nielsm> (a bunch of values reserved for non-company owners)
18:12:56 <_dp_> not rly, it's just another crazy idea, I have them all the time xD
18:13:11 <_dp_> though I guess having > 15 companies would be nice sometimes
18:16:57 *** hamstonkid[m] has joined #openttd
18:19:32 <glx> limit for companies used to be 8, now it's 15 because company colors and 8bits palette
18:19:39 <Eddi|zuHause> that requires fiddling with map array stuff, especially on tiles that store multiple companies (road,tram,stop)
18:19:43 <milek7> probably bitrotten because of NRT stuff
18:20:13 <nielsm> yeah roads have lots of owners
18:20:29 <glx> yeah map often use 4 bits only for owner
18:20:57 <glx> because there's only 15 companies
18:21:04 <Eddi|zuHause> you're gonna get a lot of dev vetos on making the map array bigger
18:22:00 <nielsm> the map array needs to go
18:22:24 <planetmaker> time to un-earch michi's old NewMapArray branches :P
18:22:40 <planetmaker> (or however exactly it was/is called)
18:22:59 <milek7> "m1 bit 7 and m6 bits 1..0 and m1 bits 4..0: owner"
18:23:39 <LordAro> i'm pretty sure he updated it for GH
18:33:37 *** Progman has joined #openttd
18:33:53 <Eddi|zuHause> i keep forgetting that this cargodist overlay existed
18:33:58 *** virtualrandomnumber has quit IRC
18:36:36 <_dp_> replace map array with map map :p
18:38:38 <FLHerne> Eddi|zuHause: How do you play without it?
18:38:56 <Eddi|zuHause> i haven't actually played in like 5 years
18:39:10 <milek7> yeah, it won't rebase cleanly due to NRT changes
18:40:18 <Eddi|zuHause> as much as the map array is a problem with extending the game, its rigid structure is probably the reason why the game has any performance at all, making these requests for expansion possible
18:41:45 <nielsm> the weird bitstuffing going on is imo also an impediment to understanding the code and extending with features
18:41:58 <_dp_> Eddi|zuHause, I don't think it will change performance much if player-owned stuff moves out
18:42:18 <nielsm> such as the same data sometimes being in different locations depending on the tile type
18:42:56 <planetmaker> Well, but even ownership is more than one per tile :)
18:43:23 <nielsm> owns land, owns railway track, owns road, owns tramway, owns station
18:43:37 <Eddi|zuHause> but keeping all the data in the same place might mean less than optimal space usage
18:43:45 <andythenorth> official Android port? o_O
18:43:59 <Eddi|zuHause> andythenorth: are you maintaining it?
18:44:09 <nielsm> but everything except the land itself is a thing on top of the tile, and if objects on a tile were separated out from the base land in a "stack", could make sense
18:44:14 <milek7> why even Tile and TileExtended separate?
18:44:29 <nielsm> because of powers of 2
18:44:30 <_dp_> I've no idea how people manage to play it on android
18:44:31 <Eddi|zuHause> there's really 2 parts to the android port: the build/distribution, and the UI
18:44:40 <_dp_> very not touchscreen game imo
18:45:11 <nielsm> Tile and TileExtended are separate to avoid having a 12 byte large structure, which is annoying to index into an array of
18:45:14 <Eddi|zuHause> both need to be separated out and merged independently
18:45:25 <nielsm> so instead there is an array of 8 byte structs and one of 4 byte structs
18:45:29 <milek7> but you could have 16 byte one?
18:45:45 <nielsm> yeah if the landscape was extended with another 4 bytes they could be merged
18:46:00 <Eddi|zuHause> milek7: it was decided against a 16 byte one when going from 8 bytes to 9 bytes, as that would be doubling the data
18:46:19 <milek7> I guess that separation also increases cpu cache misses
18:46:52 <Eddi|zuHause> that's probably wild speculation
18:47:23 <nielsm> I think my idea of (also) making the landscape tiled instead of a single long array will help CPU cache
18:47:49 <nielsm> since you have better proximity between row-adjacent tiles
18:48:34 <Eddi|zuHause> yes, something like 16x16 superblocks or something, but that makes finding neighbouring tiles non-trivial
18:48:53 <nielsm> yep it makes indexing weirder
18:49:39 <Eddi|zuHause> quadtree doesn't help in "for next tile in Y direction, just +256 and test for VOID"
18:50:11 <_dp_> Eddi|zuHause, is that even a thing?
18:50:20 <_dp_> and test for void can be done without any map at al
18:50:26 <Eddi|zuHause> yes, that's how it works currently
18:50:51 <Eddi|zuHause> with 256 being a variable, of course
18:52:25 <Eddi|zuHause> _dp_: the vast majority of tile operations is "go 1 tile into {+|-}{X|Y} direction". you want that to be as efficient as possible
18:53:49 *** Smedles has joined #openttd
18:54:16 <_dp_> Eddi|zuHause, that's questionable... if anything tile loop is random
18:54:39 <_dp_> and slowest part is pf anyway, so as long as it's optimized everything should be fine
18:54:51 <Eddi|zuHause> tileloop is not "random" random
18:55:37 <Eddi|zuHause> it's also mostly a (current tile)+(fixed offset) operation
18:56:23 <_dp_> Eddi|zuHause, lol, sure when tile is integer everything is offset xD
18:56:49 <Eddi|zuHause> just "fixed offset" is chosen in a way that avoids straight lines
18:57:10 <Eddi|zuHause> it's more akin to knight's movement in chess
19:03:45 <FLHerne> Eddi|zuHause: Why would you test for VOID rather than just knowing how big the map is?
19:04:23 <Eddi|zuHause> FLHerne: because that's a less expensive operation
19:05:11 <FLHerne> Really? I find that hard to believe tbh
19:05:17 <Eddi|zuHause> FLHerne: testing for VOID is just reading a memory location, whereas checking whether you crossed the map border means decomposing TileIndex into X and Y components and checking each one individually
19:05:42 <FLHerne> You've got an extra branch, but it's a really short one, and compilers are good at optimizing those into various things
19:05:58 <Eddi|zuHause> you're trading memory (one line of tiles at each end of the map) for speed
19:06:06 <Timberwolf> Branches are weird for optimisation.
19:06:21 <Timberwolf> If they're consistently the same result, they may as well not be there on a modern CPU.
19:06:36 <Timberwolf> If they aren't... it's one of the slowest things you can do.
19:07:11 <Eddi|zuHause> Timberwolf: mostly they'll nowadays just execute both branches and throw away one result once they know which branch should have been taken
19:07:58 <FLHerne> Timberwolf: I mean, simple branches tend to be optimized into a pile of SELs or so
19:08:11 <_dp_> I bet it actually depends on a context, either can be faster depending on how well it can be optimized
19:08:11 <FLHerne> And then you don't have a branch at all
19:08:23 <Eddi|zuHause> which is how we ended up with "speculative execution" abuse attacks like spectre
19:08:35 <milek7> on the other hand you have extra memory access in region somewhere kilobytes near
19:09:19 <milek7> but map size check is simple divide and bounds check (which should probably be cached as frequently used)
19:09:29 <milek7> of course all speculation :)
19:10:21 <Eddi|zuHause> well, you could go all dynamic programming on it and make a giant lookup table for (tile|direction) whether that step would take you out of the map :p
19:11:02 <Eddi|zuHause> that's 4 bits per tile
19:11:38 <Timberwolf> Must... not.. get... distracted... into.. low-level... optimisation... rabbithole.
19:11:49 <milek7> ..and another memory access
19:12:03 <Eddi|zuHause> but since that's then decoupled from the map data, it might be another cache miss
19:13:30 *** frosch123 has joined #openttd
20:10:22 <Wolf01> Ha! Late for buying lego parts, bricks&pieces reopened today for Italy
20:27:58 <nielsm> I kinda like that talk
20:29:22 *** gelignite has joined #openttd
20:32:37 <TrueBrain> glx : still expected nightly fails? (Just checking :D)
20:32:50 * andythenorth reimplements FIRS with GOTO
20:38:47 *** jottyfan has joined #openttd
20:59:27 <glx> TrueBrain: yeah, I'm waiting for #8210 approval :)
21:04:39 <DorpsGek_III> [OpenTTD/OpenTTD] techgeeknz commented on pull request #8214: WIP: Refactor gfx engine's dirty block system https://git.io/JfSDS
21:07:00 <DorpsGek_III> [OpenTTD/OpenTTD] LordAro approved pull request #8210: Revert f51e66f: creating zip bundle fails for MacOS https://git.io/JfSDF
21:10:04 <DorpsGek_III> [OpenTTD/OpenTTD] glx22 merged pull request #8210: Revert f51e66f: creating zip bundle fails for MacOS https://git.io/JfDpk
21:42:38 *** virtualrandomnumber has joined #openttd
21:45:08 *** virtualrandomnumber has quit IRC
21:57:48 *** jottyfan has joined #openttd
22:23:16 <DorpsGek_III> [OpenTTD/OpenTTD] JGRennison commented on pull request #8214: WIP: Refactor gfx engine's dirty block system https://git.io/JfS9M
22:33:43 *** WormnestAndroid has quit IRC
22:34:19 *** WormnestAndroid has joined #openttd
23:18:05 *** Smedles has joined #openttd
23:19:32 <DorpsGek_III> [OpenTTD/OpenTTD] techgeeknz commented on pull request #8214: WIP: Refactor gfx engine's dirty block system https://git.io/JfS7R
23:42:52 <DorpsGek_III> [OpenTTD/OpenTTD] techgeeknz updated pull request #8214: WIP: Refactor gfx engine's dirty block system https://git.io/JfS3n
23:59:05 <DorpsGek_III> [OpenTTD/OpenTTD] techgeeknz updated pull request #8214: WIP: Refactor gfx engine's dirty block system https://git.io/JfS3n
continue to next day ⏵
