Log for #openttd on 10th June 2020:
Times are UTC Toggle Colours
00:02:49  *** Tirili has quit IRC
01:38:49  *** Flygon has joined #openttd
02:28:32  *** snail_UES_ has quit IRC
02:30:16  *** glx has quit IRC
02:35:11  *** debdog has joined #openttd
02:38:30  *** D-HUND has quit IRC
03:18:12  *** Wormnest has quit IRC
03:41:49  <DorpsGek_III> [OpenTTD/OpenTTD] techgeeknz left a comment on commit: Cleanup: Give `SetDirtyBlocks` a more descriptive name.
03:43:01  <DorpsGek_III> [OpenTTD/OpenTTD] techgeeknz left a comment on commit: Cleanup: Fix typos in code comments.
04:14:33  *** Wormnest has joined #openttd
04:30:59  *** m1cr0m4n has joined #openttd
04:31:14  *** lastmikoi has quit IRC
04:31:14  *** m1cr0man has quit IRC
04:31:43  *** lastmikoi has joined #openttd
04:34:04  *** skrzyp has quit IRC
04:45:09  *** keoz has joined #openttd
05:07:13  *** Wormnest has quit IRC
06:11:45  *** sla_ro|master has joined #openttd
06:13:52  *** arikover has joined #openttd
06:15:05  *** andythenorth has joined #openttd
06:43:47  <andythenorth> yo
06:57:08  <EER> o/
07:04:36  <DorpsGek_III> [OpenTTD/OpenTTD] LordAro commented on pull request #8208: Cleanup: More documentation fixes
07:08:45  *** k-man has quit IRC
07:21:40  *** k-man has joined #openttd
07:26:57  *** k-man has joined #openttd
07:29:43  *** k-man has quit IRC
07:42:35  *** k-man has joined #openttd
07:43:04  *** k-man has quit IRC
07:43:40  *** k-man has joined #openttd
08:12:24  <DorpsGek_III> [OpenTTD/OpenTTD] techgeeknz opened pull request #8214: WIP: Refactor gfx engine's dirty block system
08:14:34  *** gelignite has joined #openttd
08:15:34  <DorpsGek_III> [OpenTTD/OpenTTD] techgeeknz updated pull request #8214: WIP: Refactor gfx engine's dirty block system
09:00:31  *** gelignite has quit IRC
09:12:34  *** Samu has joined #openttd
09:52:52  *** skrzyp has joined #openttd
10:05:11  *** skrzyp has quit IRC
10:16:21  *** skrzyp has joined #openttd
10:37:38  <planetmaker> moin
10:37:54  *** gelignite has joined #openttd
10:37:54  <planetmaker> I just explained that jfs and andythenorth are not the morons in one of the threads :P
10:39:01  <LordAro> planetmaker: hmm?
10:39:40  *** Laedek has quit IRC
10: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
10: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 :)
10:54:12  <planetmaker> well... my reply might have included something of such salt :P
10:54:27  <planetmaker> especially as the guy stressed that he has an IT background and understands the isuse :P
10:55:49  *** skrzyp has quit IRC
11:01:43  <_dp_> planetmaker, I don't see your reply, you sure you actually posted it?
11:02:39  <planetmaker> no, I didn't. I sent a private message.
11:02:59  <_dp_> oh, ok
11:11:24  <planetmaker> not always good to do moderation in public :)
11:15:38  *** snail_UES_ has joined #openttd
11:28:51  *** WormnestAndroid has quit IRC
11:29:04  *** WormnestAndroid has joined #openttd
11:30:28  *** WormnestAndroid has quit IRC
11:30:41  *** WormnestAndroid has joined #openttd
11:44:46  <andythenorth> I assumed good intent and low knowledge
11:44:53  <andythenorth> maybe I got those the wrong way around
11:45:08  <andythenorth> but it's a starting point of sorts
11:52:05  <supermop_Home> ugh remote workstation not responsive - going to have to go into the office to restart it
11:53:07  <planetmaker> I can at least confirm the latter point, judging from a follow-up reply
11:56:00  <andythenorth> supermop_Home you need
11: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?
11:57:36  <LordAro> planetmaker: i believe so
11:57:52  <planetmaker> can you show me how? I was looking for 30 minutes without success
11:59:07  <LordAro> hmm, perhaps not
11:59:45  <LordAro> gitlab you can
11:59:50  <planetmaker> yep
11:59:57  <LordAro> GH you just have
12:00:22  <planetmaker> good that you arrived at the same place independently :)
12:00:51  <LordAro> can possibly move an issue to a private repo
12:09:20  <supermop_Home> andythenorth indeed
12:09:33  <supermop_Home> lucky for me the office is only 10 min away
12:14:17  *** Laedek has joined #openttd
12:42:12  *** glx has joined #openttd
12:42:12  *** ChanServ sets mode: +v glx
13:32:33  <FLHerne> planetmaker: Do you know how JGR does it?
13:32:45  <planetmaker> no
13:32:51  <FLHerne> I remember there was a patch that raised the limit only for local games
13:33:14  <FLHerne> But apparently you can have 255 grfs on a JGR server, so...?
13:33:23  <FLHerne> Maybe they're just not shown in the server list
13:33:43  <planetmaker> it might work, if you configure your client properly... dunnow
13:36:50  <LordAro> i don't think you can have 255 grfs on a server
13:36:52  <LordAro>
13:37:22  <DorpsGek_III> [OpenTTD/OpenTTD] glx22 commented on issue #8190: Mac build fails with cmake
13:39:09  <LordAro> oh wait, here it is
13:39:28  <LordAro> which builds on a few other patches
13:45:01  <FLHerne> tbh, it seems a bit unfair to the forum guy to insist that it's technologically impractical
13:45:15  <FLHerne> when there's an existing patch for it :p
13:45:29  <LordAro> no one's said it's technologically impractical
13:45:42  <LordAro> forum guy just seems to think that people have told him that
13:47:33  *** nielsm has joined #openttd
13:55:03  *** skrzyp has joined #openttd
13:59:06  <planetmaker> yes... such was not implied
14:14:31  *** spnda has joined #openttd
14:28:43  <FLHerne> Eh
14: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
14:30:24  <FLHerne> Obviously they know the limit currently exists, or they wouldn't ask
14: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
14:33:22  *** snail_UES_ has quit IRC
14:33:48  *** snail_UES_ has joined #openttd
14:34:05  <FLHerne> I don't think that's a fair reading
14:34:15  <planetmaker> tbh, I read it like that, too
14:34:44  <FLHerne> jfs explained it was a network limitation, questioner said networks are pretty fast these days
14:35:08  <planetmaker> jfs explained that it was a network *protocol* limitation
14:35:15  <FLHerne> Auge's post then immediately rolls out a ton of jargon to basically say "it doesn't work that way atm"
14:35:57  <planetmaker>
14:36:22  <FLHerne> Yes, up to there the thread is fine
14:36:51  <planetmaker> elaborates on that
14:37:10  <FLHerne> Hm, no, it's jfs with the jargon as well
14:37:16  <planetmaker> and in the follow up it was shown that the explanation was not understood at all
14:38:34  <FLHerne> Again, I don't think understanding the technical reason is really at issue
14:39:20  <andythenorth> responding to suggestions is best approached as judo
14:39:22  <andythenorth> roll with it
14: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
14:39:29  <andythenorth> that didn't quite happen here
14:40:28  <nielsm> I try to always give a non-technical summary/conclusion, at least it's my intention to
14: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
14:40:35  <nielsm> even if it's also backed up by a technical explanation
14:41:02  <FLHerne> Not sure I'm making my point clearly
14:41:15  <FLHerne> I think
14:41:37  <FLHerne>  - The suggestions forum shouldn't only be for people who can write a patch to implement their suggestion
14:41:46  <FLHerne> (because that's "OpenTTD Development")
14:41:58  <andythenorth> FLHerne I know what point you're making, it's not unclear to me
14: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
14: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"
14:42:53  <planetmaker> FLHerne, I don't think anyone rejected the suggestion either
14:43:12  <andythenorth> nothing is accepted or rejected in suggestions forum :)
14:43:14  <nielsm> maybe I should just have written that
14: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"
14:43:50  <andythenorth> Suggestions forum is just this
14:43:56  <andythenorth> (I made the video years ago)
14:43:59  <planetmaker> and then the explanation with network protocol etc
14:44:06  <FLHerne> planetmaker: I think it's "Please don't try to argue network protocols if..." where it really goes wrong
14: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."
14:44:17  <andythenorth> oh they cut the sound :(
14:44:19  <FLHerne> They were never trying to "argue network protocols"
14:44:30  <nielsm> that indicates to me the poster is blaming the current state of openttd and past development for being bad
14:44:46  <nielsm> blaming past developers for not having done it The Correct Way from the beginning
14: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"
14:45:15  <andythenorth> yes that riled me, but if you stop a minute
14:45:17  <nielsm> s/indicates to me/reads to me as/
14:45:19  <andythenorth> they're so far from reality
14:45:25  <andythenorth> that it doesn't matter what they say
14:45:32  <andythenorth> so we give them the benefit of the doubt
14: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
14:45:43  <andythenorth> it's probably a 10 year old
14:46:02  <planetmaker> tbh, when *I* read it, I thought like "c'mon... get a grip and just let it slide"
14:47:15  <planetmaker> for both, actually, jfs' answer with "please don't try to argue..." and the reply to that as well...
14: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
14:47:57  <planetmaker> and not take everything personally straight away
14:48:01  <andythenorth> I rarely go in suggestions forum :)
14:48:14  <andythenorth> it's the equivalent of a below-the-fold comment section
14:48:57  <andythenorth> we have to have it though
14:51:44  <Timberwolf> I think people too easily confuse "suggestions" as "tickets for development"
14:53:33  <andythenorth> it's a mismatched social contract
14: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.
14:53:43  <andythenorth> Timberwolf challenge :D
14: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 :)
14:55:59  <_dp_> pfft, what I come up with is quite often not implementable :p
14:56:22  <_dp_> Timberwolf, have you actually used GS? it sucks for pretty much everything
14:56:50  <Timberwolf> Yeah, I find myself working around things a lot.
14:57:09  <andythenorth> _dp_ we should get a newsletter :)
14:57:18  <Timberwolf> It does work, but my recollection is a lot of contracts that don't quite line up between different areas.
14:57:19  <andythenorth> we're becoming a broken record
14:57:32  <andythenorth> the channel will start auto-kicking us when we type 'GS'
14:57:59  <_dp_> andythenorth, yeah, and a certain someone when he types "newgrf" :p
14: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"?
14:58:57  <Timberwolf> The underlying answer is probably going to involve various combinations of "Chris Sawyer", "486", "4MB" and "data structure" in most cases.
15:02:51  <DorpsGek_III> [OpenTTD/OpenTTD] JGRennison commented on pull request #8214: WIP: Refactor gfx engine's dirty block system
15:14:00  *** Wormnest has joined #openttd
15:20:11  <milek7> >pull requests submitted will be reviewed, and if good enough quality will be merged.
15:20:20  <milek7> well, do you really want to review such patchsets? ;p
15:33:28  <nielsm> narrow in scope and fixes a real problem? sure
15:33:38  *** virtualrandomnumber has joined #openttd
15:34:29  <glx> #8210 needs a review btw :)
15:41:16  <milek7> but what's real problem? 59 grfs? 64 cargos? 16 companies? all of it, none?
15:45:15  <glx> and finally only one type of train is built at the end ;)
15: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:
15:58:06  <nielsm> I'm not sure why anyone would want to do that
16: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
16:06:37  *** iSoSyS has joined #openttd
16: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
16:10:16  <_dp_> oh, I recently had an idea where it makes perfect sense actually
16:10:45  <_dp_> have like rpg server that runs about forever and takes a lot of grind to unlock stuff like new vehicles
16:11:06  *** iSoSyS has quit IRC
16:11:34  <_dp_> though that will run into max company problem way sooner than into grf limit xD
16:12:15  <nielsm> so you're saying we should be working on the 250 companies patch
16:12:28  <nielsm> (a bunch of values reserved for non-company owners)
16:12:56  <_dp_> not rly, it's just another crazy idea, I have them all the time xD
16:13:11  <_dp_> though I guess having > 15 companies would be nice sometimes
16:16:57  *** hamstonkid[m] has joined #openttd
16:19:29  <milek7>
16:19:32  <glx> limit for companies used to be 8, now it's 15 because company colors and 8bits palette
16:19:39  <Eddi|zuHause> that requires fiddling with map array stuff, especially on tiles that store multiple companies (road,tram,stop)
16:19:43  <milek7> probably bitrotten because of NRT stuff
16:20:13  <nielsm> yeah roads have lots of owners
16:20:29  <glx> yeah map often use 4 bits only for owner
16:20:57  <glx> because there's only 15 companies
16:21:04  <Eddi|zuHause> you're gonna get a lot of dev vetos on making the map array bigger
16:22:00  <nielsm> the map array needs to go
16:22:18  <glx> stacked data per tile ;)
16:22:24  <planetmaker> time to un-earch michi's old NewMapArray branches :P
16:22:40  <planetmaker> (or however exactly it was/is called)
16:22:59  <milek7> "m1 bit 7 and m6 bits 1..0 and m1 bits 4..0: owner"
16:23:29  <planetmaker> <-- only 9 years old :P
16:23:39  <LordAro> i'm pretty sure he updated it for GH
16:31:53  <milek7> that window though..
16:31:55  <milek7>
16:32:02  <nielsm> :D
16:33:37  *** Progman has joined #openttd
16:33:53  <Eddi|zuHause> i keep forgetting that this cargodist overlay existed
16:33:58  *** virtualrandomnumber has quit IRC
16:36:36  <_dp_> replace map array with map map :p
16:38:38  <FLHerne> Eddi|zuHause: How do you play without it?
16:38:56  <Eddi|zuHause> i haven't actually played in like 5 years
16:39:10  <milek7> yeah, it won't rebase cleanly due to NRT changes
16: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
16:41:45  <nielsm> the weird bitstuffing going on is imo also an impediment to understanding the code and extending with features
16:41:58  <_dp_> Eddi|zuHause, I don't think it will change performance much if player-owned stuff moves out
16:42:18  <nielsm> such as the same data sometimes being in different locations depending on the tile type
16:42:56  <planetmaker> Well, but even ownership is more than one per tile :)
16:43:23  <nielsm> owns land, owns railway track, owns road, owns tramway, owns station
16:43:31  <nielsm> several parts to it
16:43:37  <Eddi|zuHause> but keeping all the data in the same place might mean less than optimal space usage
16:43:39  <andythenorth> meanwhile
16:43:45  <andythenorth> official Android port? o_O
16:43:59  <Eddi|zuHause> andythenorth: are you maintaining it?
16: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
16:44:14  <milek7> why even Tile and TileExtended separate?
16:44:29  <nielsm> because of powers of 2
16:44:30  <_dp_> I've no idea how people manage to play it on android
16:44:31  <Eddi|zuHause> there's really 2 parts to the android port: the build/distribution, and the UI
16:44:40  <_dp_> very not touchscreen game imo
16: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
16:45:14  <Eddi|zuHause> both need to be separated out and merged independently
16:45:25  <nielsm> so instead there is an array of 8 byte structs and one of 4 byte structs
16:45:29  <milek7> but you could have 16 byte one?
16:45:45  <nielsm> yeah if the landscape was extended with another 4 bytes they could be merged
16: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
16:46:19  <milek7> I guess that separation also increases cpu cache misses
16:46:52  <Eddi|zuHause> that's probably wild speculation
16:47:02  <milek7> yes :)
16:47:23  <nielsm> I think my idea of (also) making the landscape tiled instead of a single long array will help CPU cache
16:47:49  <nielsm> since you have better proximity between row-adjacent tiles
16:48:34  <Eddi|zuHause> yes, something like 16x16 superblocks or something, but that makes finding neighbouring tiles non-trivial
16:48:53  <nielsm> yep it makes indexing weirder
16:48:59  <_dp_> quadtree xD
16:49:39  <Eddi|zuHause> quadtree doesn't help in "for next tile in Y direction, just +256 and test for VOID"
16:50:11  <_dp_> Eddi|zuHause, is that even a thing?
16:50:20  <_dp_> and test for void can be done without any map at al
16:50:26  <Eddi|zuHause> yes, that's how it works currently
16:50:51  <Eddi|zuHause> with 256 being a variable, of course
16:51:50  *** Smedles has quit IRC
16: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
16:53:49  *** Smedles has joined #openttd
16:54:16  <_dp_> Eddi|zuHause, that's questionable... if anything tile loop is random
16:54:39  <_dp_> and slowest part is pf anyway, so as long as it's optimized everything should be fine
16:54:51  <Eddi|zuHause> tileloop is not "random" random
16:55:37  <Eddi|zuHause> it's also mostly a (current tile)+(fixed offset) operation
16:56:23  <_dp_> Eddi|zuHause, lol, sure when tile is integer everything is offset xD
16:56:49  <Eddi|zuHause> just "fixed offset" is chosen in a way that avoids straight lines
16:57:10  <Eddi|zuHause> it's more akin to knight's movement in chess
17:03:45  <FLHerne> Eddi|zuHause: Why would you test for VOID rather than just knowing how big the map is?
17:04:23  <Eddi|zuHause> FLHerne: because that's a less expensive operation
17:05:11  <FLHerne> Really? I find that hard to believe tbh
17: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
17: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
17:05:58  <Eddi|zuHause> you're trading memory (one line of tiles at each end of the map) for speed
17:06:06  <Timberwolf> Branches are weird for optimisation.
17:06:21  <Timberwolf> If they're consistently the same result, they may as well not be there on a modern CPU.
17:06:36  <Timberwolf> If they aren't... it's one of the slowest things you can do.
17: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
17:07:58  <FLHerne> Timberwolf: I mean, simple branches tend to be optimized into a pile of SELs or so
17:08:11  <_dp_> I bet it actually depends on a context, either can be faster depending on how well it can be optimized
17:08:11  <FLHerne> And then you don't have a branch at all
17:08:23  <Eddi|zuHause> which is how we ended up with "speculative execution" abuse attacks like spectre
17:08:35  <milek7> on the other hand you have extra memory access in region somewhere kilobytes near
17:09:19  <milek7> but map size check is simple divide and bounds check (which should probably be cached as frequently used)
17:09:29  <milek7> of course all speculation :)
17: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
17:11:02  <Eddi|zuHause> that's 4 bits per tile
17:11:38  <Timberwolf> Must... not.. get... distracted... into.. low-level... optimisation... rabbithole.
17:11:49  <milek7> ..and another memory access
17:12:03  <Eddi|zuHause> but since that's then decoupled from the map data, it might be another cache miss
17:13:30  *** frosch123 has joined #openttd
17:21:08  *** gelignite has quit IRC
17:47:10  *** keoz has quit IRC
17:57:37  *** urdh has quit IRC
18:02:04  *** Flygon has quit IRC
18:03:00  *** derF_C has joined #openttd
18:09:35  *** Wolf01 has joined #openttd
18:10:22  <Wolf01> Ha! Late for buying lego parts, bricks&pieces reopened today for Italy
18:13:12  *** Compu has joined #openttd
18:27:31  <nielsm>
18:27:58  <nielsm> I kinda like that talk
18:29:22  *** gelignite has joined #openttd
18:32:37  <TrueBrain> glx : still expected nightly fails? (Just checking :D)
18:32:50  * andythenorth reimplements FIRS with GOTO
18:38:47  *** jottyfan has joined #openttd
18:39:34  *** jottyfan has quit IRC
18:59:27  <glx> TrueBrain: yeah, I'm waiting for #8210 approval :)
19:04:39  <DorpsGek_III> [OpenTTD/OpenTTD] techgeeknz commented on pull request #8214: WIP: Refactor gfx engine's dirty block system
19:07:00  <DorpsGek_III> [OpenTTD/OpenTTD] LordAro approved pull request #8210:  Revert f51e66f: creating zip bundle fails for MacOS
19:08:31  *** urdh has joined #openttd
19:10:04  <DorpsGek_III> [OpenTTD/OpenTTD] glx22 merged pull request #8210:  Revert f51e66f: creating zip bundle fails for MacOS
19:42:38  *** virtualrandomnumber has joined #openttd
19:45:08  *** virtualrandomnumber has quit IRC
19:57:48  *** jottyfan has joined #openttd
20:08:20  *** SpComb has quit IRC
20:23:16  <DorpsGek_III> [OpenTTD/OpenTTD] JGRennison commented on pull request #8214: WIP: Refactor gfx engine's dirty block system
20:33:43  *** WormnestAndroid has quit IRC
20:34:14  *** jottyfan has quit IRC
20:34:19  *** WormnestAndroid has joined #openttd
20:54:22  *** nielsm has quit IRC
20:54:22  *** Gustavo6046 has quit IRC
20:55:14  *** frosch123 has quit IRC
21:09:22  *** SpComb has joined #openttd
21:15:24  *** andythenorth has quit IRC
21:16:47  *** Smedles has quit IRC
21:18:05  *** Smedles has joined #openttd
21:19:32  <DorpsGek_III> [OpenTTD/OpenTTD] techgeeknz commented on pull request #8214: WIP: Refactor gfx engine's dirty block system
21:24:26  *** arikover has quit IRC
21:33:16  *** Wolf01 has quit IRC
21:37:25  *** sla_ro|master has quit IRC
21:42:52  <DorpsGek_III> [OpenTTD/OpenTTD] techgeeknz updated pull request #8214: WIP: Refactor gfx engine's dirty block system
21:52:38  *** Samu has quit IRC
21:59:05  <DorpsGek_III> [OpenTTD/OpenTTD] techgeeknz updated pull request #8214: WIP: Refactor gfx engine's dirty block system
22:24:25  *** Markk has quit IRC
22:27:20  *** Gustavo6046 has joined #openttd
22:32:27  *** Markk has joined #openttd
22:36:53  *** WormnestAndroid has quit IRC
22:37:26  *** WormnestAndroid has joined #openttd
22:39:33  *** nielsm has joined #openttd
22:40:10  <DorpsGek_III> [OpenTTD/OpenTTD] techgeeknz updated pull request #8214: WIP: Refactor gfx engine's dirty block system
22:43:43  *** Gustavo6046 has quit IRC
22:44:04  <DorpsGek_III> [OpenTTD/OpenTTD] techgeeknz updated pull request #8214: WIP: Refactor gfx engine's dirty block system
22:49:06  <DorpsGek_III> [OpenTTD/OpenTTD] techgeeknz updated pull request #8214: WIP: Refactor gfx engine's dirty block system
22:49:47  *** Gustavo6046 has joined #openttd
22:57:37  <DorpsGek_III> [OpenTTD/OpenTTD] techgeeknz updated pull request #8214: WIP: Refactor gfx engine's dirty block system
23:00:02  *** spnda has quit IRC
23:00:05  <DorpsGek_III> [OpenTTD/OpenTTD] techgeeknz commented on pull request #8214: WIP: Refactor gfx engine's dirty block system
23:25:38  *** Progman has quit IRC
23:40:07  *** Wormnest has quit IRC
23:48:04  <DorpsGek_III> [OpenTTD/OpenTTD] techgeeknz updated pull request #8214: WIP: Refactor gfx engine's dirty block system
23:56:31  <DorpsGek_III> [OpenTTD/OpenTTD] techgeeknz commented on pull request #8214: WIP: Refactor gfx engine's dirty block system

Powered by YARRSTE version: svn-trunk