IRC logs for #openttd on OFTC at 2023-08-12
β΄ go to previous day
01:25:44 *** Wormnest has quit IRC (Quit: Leaving)
02:58:35 *** debdog has quit IRC (Ping timeout: 480 seconds)
03:33:45 *** D-HUND is now known as debdog
09:08:27 *** DorpsGek has joined #openttd
09:08:27 *** ChanServ sets mode: +o DorpsGek
09:08:30 <dwfreed> possibly ran into rejectcache if it reconnected too fast while still klined
09:08:55 <truebrain> welcome back DorpsGek π Please start logging again π
09:09:16 <truebrain> tnx dwfreed .. and I hope people will stop opening issues with unicode in it π
09:09:33 <belajalilija> this is the only active channel
09:09:38 <belajalilija> truebrain is your english good?
09:09:42 <truebrain> (that is not an invitation to anyone!)
09:10:06 <belajalilija> need help with something
09:10:19 <truebrain> never ask to ask etc etc, but Discord channel #openttd-help is very active
09:10:28 <belajalilija> its unrelated to openttd xd
09:10:41 <belajalilija> im asking here because this is the only active channel
09:10:50 <belajalilija> ill post in off topic though
09:10:56 <truebrain> yet I see many active channels on this Discord, so that comment puzzles me greatly!
09:11:14 <truebrain> this channel today has mostly been a monologue, so .. *shrug*
09:11:38 <belajalilija> idk im really tired
09:11:42 <belajalilija> posted in Discord channel #off-topic
09:22:03 <truebrain> hmm, forgot a few lines of code in that PR .. let's first make another PR, and fix that π
09:22:21 <truebrain> so hard to not miss anything when cherry-picking from a PR spanning 67 files π
10:04:52 <truebrain> talltyler: I think this is the final form of 10761 .. I don't think I can reduce the amount of `static_cast`s that remain. And type-checking seems to be working as expected. So if the other PRs I made are merged, I will rebase and undraft it. There is a bunch of templating going on, which prevents a lot of casts. So yeah, "almost there" π
11:38:46 <truebrain> michi_cc[d]: my memory can be a bit foggy, but the main reason TileIndex allowed implicit casts was due to the amount of casts needed otherwise, right?
11:39:08 <truebrain> not that I am missing some other reason I forgot about π
12:20:44 <peter1138> I'm sure it's only that one specific similar-to-but-not-/ character, for obvious reasons π
12:22:19 <FLHerne> andythenorth: can we just have diagonal bridges
12:22:31 <FLHerne> it would make flying junctions a lot easier, along with many other things
12:26:09 <alfagamma_0007> Ah diagonal bridges
12:27:02 <peter1138> Play Locomotion for that, and see how "easy" it is π
12:27:11 <_glx_> rotate a little and use diagonal tracks under normal bridge
12:28:11 <FLHerne> peter1138: Locomotion has these weird 'curve' things
12:28:46 <FLHerne> _glx_: well, yeah, but that can be an awkward limitation in some situations
12:31:16 <michi_cc[d]> truebrain: Yeah, there were (and/or are) a lot of places that used it in/for an int, and I didn't want to do a 1000+ files PR π
12:31:42 <truebrain> Yeah, okay.. I fixed that π
12:31:44 <andythenorth> FLHerne: Diagonal tunnels π
12:31:53 <alfagamma_0007> Diagonal roads
12:32:08 <alfagamma_0007> Diagonal stations
12:32:29 <alfagamma_0007> belajalilija: I think we have that?
12:32:44 <FLHerne> sort of, it's a graphics trick
12:32:54 <alfagamma_0007> My point exactly
12:32:58 <belajalilija> cliffs would be cool
12:33:33 <brickblock19280> Invisible track
12:34:00 <belajalilija> not just 1 tile things
12:35:11 <alfagamma_0007> That would require an all out recode
12:35:17 <FLHerne> I think they'd just look strange most of the time
12:35:50 <FLHerne> the current slopes are already far steeper than most real-world terrain
12:36:32 <andythenorth> Placeable mountains as objects
12:36:46 <andythenorth> Tropico has annoying immovable terrain areas
12:37:45 <FLHerne> I do wish there was a setting or whatever to prevent terraforming more than perhaps 2-3 height-levels from the original
12:38:13 <FLHerne> "This mountain range is a mild inconvenience. I shall delete it."
12:43:52 <andythenorth> Maybe it should be per tile π
12:44:14 <andythenorth> With a distribution across the map π
12:46:31 <belajalilija> andythenorth: same as transport giant
12:46:45 <belajalilija> that game had immovable steep areas and water
12:46:49 <belajalilija> but no normal hills
13:07:42 *** debdog has quit IRC (Quit: Initiating getting-the-hell-out-of-here maneuver!)
13:11:54 <FLHerne> andythenorth: very clever, bedrock type simulation
13:12:22 <FLHerne> also tall buildings can only be built on the hard-to-dig granite :p
13:12:41 <FLHerne> or are cheaper, anyway
13:32:14 <emperorjake> Or a soil budget like Cities Skylines
13:58:39 <andythenorth> So immovable mountain objects, but with also state machines built in for funiculars
13:58:49 <andythenorth> And rail tunnels
13:59:17 <andythenorth> Then we can have an object set comprising all major mountain passes of the world
14:00:30 <peter1138> I'm confused by this persistent idea of making object tiles be general purpose "any type of tile" tiles...
14:02:09 <Eddi|zuHause> then it's just called "tile"
14:05:12 <truebrain> still not sure what is better .. a `static_cast` or a `to_base_type()` function
14:05:59 <FLHerne> peter1138: the requirement to be one specific type of tile can be a bit limiting, and the object spec is probably the least annoying
14:06:56 <FLHerne> so other than some wasm-based total reinvention of how OTTD extension happens, extending the object spec to be the Universal Tile seems better than the alternatives
14:07:37 <FLHerne> (from a grf perspective; from an OTTD code perspective it's probably still a nightmare)
14:07:55 <michi_cc[d]> andythenorth: Isn't that what the radio transmitter is for? To be annoyingly in the way? π
14:08:47 <Eddi|zuHause> but from openttd's perspective there's no reason for it to be the same tile. houses, industrytiles, airporttiles and objects are all different tiles, while having very nearly identical looks from grf perspective
14:10:42 <Eddi|zuHause> ... as opposed to rail stations, which predate this and use very unconventional methods
14:12:40 <talltyler> ```} else if (_pause_mode == PM_UNPAUSED &&
14:12:40 <talltyler> TimerGameCalendar::date_fract == LinkGraphSchedule::SPAWN_JOIN_TICK - 2 &&
14:12:40 <talltyler> TimerGameCalendar::date % (_settings_game.linkgraph.recalc_interval / SECONDS_PER_DAY) == (_settings_game.linkgraph.recalc_interval / SECONDS_PER_DAY) / 2 &&
14:12:40 <talltyler> static_cast<int32_t>(TimerGameCalendar::date) % (_settings_game.linkgraph.recalc_interval / SECONDS_PER_DAY) == (_settings_game.linkgraph.recalc_interval / SECONDS_PER_DAY) / 2 &&
14:12:40 <talltyler> LinkGraphSchedule::instance.IsJoinWithUnfinishedJobDue()) {```
14:12:42 <talltyler> Does the Guinness Book of World Records have an entry for "longest conditional?" π
14:13:32 <truebrain> I like to repeat that the linkgraph scheduling code is hard to read π
14:16:34 <talltyler> Yes, somebodyβ’οΈ should really clean it up π
14:17:37 <Eddi|zuHause> could be worse, could be java code :p
14:17:38 <_jgr_> Eddi|zuHause: Of these, only objects can be arbitrarily plopped on the map in game
14:19:33 <Eddi|zuHause> _jgr_: yes, but if you want to redo non-track station tiles, or add pre-built road junctions (highways, onramps, etc.) there's no need for it to be internally the same tile type as objects.
14:21:57 <_jgr_> GRF authors will use the available tools that currently work
14:22:34 <Eddi|zuHause> that's sometimes a good thing, and sometimes a bad thing :p
14:22:55 <_jgr_> It seems silly to ask GRF authors to use things that don't exist
14:25:33 <Eddi|zuHause> i haven't followed the discussion earlier, but i was assuming it was the other way around, grf authors asking for things that don't exist
14:27:39 <Eddi|zuHause> i was recently at a draw bridge, which happened to get activated the moment i got there
14:28:01 <peter1138> Yes, this is not using objects to make things, it's proposing using objects to make things.
14:32:50 <Eddi|zuHause> i think we actually have some unused tile types in the map?
14:41:57 <truebrain> 335 vs 1269 for `template<` vs `template <` π
14:43:22 <Eddi|zuHause> remember the "type* var" vs "type *var" debate?
14:45:59 <truebrain> michi_cc[d]: if you have some time and want to read some templating stuff, mind giving #10761 a look? π
14:46:18 <truebrain> curious if you see ways to improve readability or any other aspect of it π
14:47:26 <truebrain> (and "no" is a valid answer btw π )
14:47:28 <Eddi|zuHause> also wasn't there once a problem with ">>" vs "> >"?
14:49:28 <michi_cc[d]> Yeah, >> was a problem until the grammar was changed/fixed with C++11.
14:58:48 <andythenorth> Eddi|zuHause: Itβs probably that actually
15:00:29 <andythenorth> Some of my suggestions are serious, some are not. Not sure which yet.
15:01:40 <andythenorth> I think model diaroma players are a bit under-served though, which tends to show up in requests for more roadtypes
15:04:40 <andythenorth> More ploppable things π
15:05:42 <andythenorth> How many objects can we have per tile? π
15:06:29 <brickblock19280> why not just do bgt but without anything but gfx and not limited to roads
15:07:22 <andythenorth> brickblock19280: There was never a good UI proposed
15:07:35 <andythenorth> But objects already has a UI
15:07:49 <brickblock19280> yeah why not steal the object gui
15:09:30 <truebrain> time to make another PR of something I found in 11190 .. the stuff we find π
15:27:15 <truebrain> there .. that will make 11190 a lot smaller π
15:30:01 <Eddi|zuHause> any real reason why we still keep NPF around?
15:30:13 <truebrain> you don't like rivers? π¦
15:30:36 <Eddi|zuHause> you like non-sequiturs? :p
15:54:17 <truebrain> Not falling for the rabbit hole this time! π
15:54:18 <peter1138> > We canβt connect to the server at www.policyalmanac.org.
16:01:13 *** Wormnest has joined #openttd
16:01:59 <andythenorth> If we delete NPF are we ruining the game?
16:02:17 <alfagamma_0007> andythenorth: Same question
16:02:30 <alfagamma_0007> Everyone uses YAPF anyway
16:02:43 <alfagamma_0007> Unless you are playing an extremely old save
16:02:44 <andythenorth> When do we get telemetry?
16:03:01 <alfagamma_0007> I will stop playing openttd if it gets telemetry
16:03:15 <Eddi|zuHause> "Your PC can run 262 of the top 1000 most popular games listed on PCGameBenchmark - at a recommended system level." that's kinda more than i expected :p
16:03:43 <Eddi|zuHause> i think the cpu turns 12 this year :p
16:03:56 <alfagamma_0007> Damn that's old
16:04:38 <Eddi|zuHause> i have a feeling i shouldn't try to run cities skylines 2 :p
16:04:53 <alfagamma_0007> Imagine playing that
16:05:27 <Eddi|zuHause> i did upgrade my GPU twice
16:05:33 <alfagamma_0007> I always had this question tho: is Cities Skylines playable on a linux distro?
16:05:49 <alfagamma_0007> Eddi|zuHause: Using the same cpu?
16:06:12 <_jgr_> 13 years old isn't that remarkable these days, the days of re-doing your PC every 3 years are pretty much over
16:06:25 <alfagamma_0007> I guess it's a higher spec one
16:07:08 <alfagamma_0007> 13 years is def decent for a laptop
16:07:36 <Eddi|zuHause> it's a Phenom II x6 CPU
16:07:48 <Eddi|zuHause> which was fairly new back then, but it wasn't the fastest available
16:08:13 <alfagamma_0007> *looks at specs*
16:09:09 <alfagamma_0007> Close to what I have
16:09:35 <Eddi|zuHause> dunno what that means
16:09:59 <Eddi|zuHause> you can't really compare raw cpu speed numbers between AMD and intel anyway
16:09:59 <alfagamma_0007> That's a processor as well
16:10:51 <alfagamma_0007> I hope I would be able to build my own rig eventually
16:17:14 <andythenorth> alfagamma_0007: I love these absolutist positions. Please explain what harm arises to you from telemetry?
16:24:03 <Eddi|zuHause> alfagamma_0007: anyway, playability on linux was always mostly a GPU issue, never really about CPU. but since Vulkan that's mostly fixed.
16:32:07 <peter1138> "My display is set to 150%, why does my browser display pictures at 150%?" wow π
16:32:15 *** Wormnest has quit IRC (Quit: Leaving)
17:20:30 <truebrain> tnx michi_cc[d] for review; appreciated! (and yes, casts were me being lazy)
17:25:25 <truebrain> went the extra mile for you peter1138 π
17:43:12 <alfagamma_0007> andythenorth: well
17:43:12 <alfagamma_0007> It's just that I mostly avoid telemetry
17:43:33 <alfagamma_0007> Unless I am forced to use software or products with it
17:43:44 <alfagamma_0007> Because there are no alternatives
17:44:43 <truebrain> so I guess you won't be playing 14.0. Might as well deinstall it now.
17:45:47 <alfagamma_0007> What sort of telemetry?
17:46:07 <truebrain> no no, no takebacks. You made your bed, now lay in it.
17:46:28 <alfagamma_0007> *Nervous chuckle*
17:46:52 <truebrain> owh, not so absoluut after all are we? π
17:47:47 <alfagamma_0007> As long you guys are not asking for my location
17:47:47 <alfagamma_0007> I won't mind I guess
17:48:15 <truebrain> So we went from a black/white statement `I will stop playing openttd if it gets telemetry` to "as long as you don't track my location". Funny how that works π
17:48:34 <alfagamma_0007> So true amirite
17:48:41 <peter1138> Yay, my PostgreSQL archive is no longer broken.
17:48:47 <alfagamma_0007> *Makes a fools of himself*
17:48:56 <truebrain> at least you have self-awareness π
17:49:10 <truebrain> peter1138: that sounds like a more useful thing that a broken archive π
17:49:49 <Eddi|zuHause> you can easily determine location from IP and choice of language/newgrfs...
17:49:54 <alfagamma_0007> *Crawls back slowly*
17:50:19 <alfagamma_0007> It's an open secret anyway
17:52:18 <truebrain> OpenTTD doesn't track IP addresses like that; so in that sense, the fact that one could doesn't mean one has to. Cloudflare does record location, but in such a statistical way we cannot correlate it back to a single user for our production setup
17:52:55 <truebrain> in the end, the real problem of telemetry is when it can be traced back to YOU as individual
17:53:05 <truebrain> telemetry itself is not the problem .. statistically poorly implemented telemetry is π
17:54:31 <truebrain> (and to be clear, telemetry for ad-platforms by definition want to track YOU as individual π )
17:55:10 <peter1138> Also, non-opt-in telemetry
17:56:05 <peter1138> Hmm, can I do similar streaming replication but with mariadb...
17:56:27 <truebrain> I am sure you are about to find out π π
17:57:22 <truebrain> Cloudflare caches more than 80% of the traffic for our wiki now \o/ I DID IT! π
17:57:46 <andythenorth> This anti-telemetry position always comes with a free helping of βbut telemetry must be unethicalβ eh π
17:58:03 <andythenorth> Yetβ¦life is more nuanced
17:59:22 <alfagamma_0007> No one's details are as secret and protected nowadays
18:00:12 <belajalilija> Speak for yourself
18:00:54 <talltyler> Also OpenTTD telemetry is opt-in, you can just say no π
18:01:24 <truebrain> talltyler: reapproval of 10761 pretty please? π
18:02:56 <alfagamma_0007> belajalilija: I think I did?
18:03:32 <truebrain> I played a bit, but there might be bugs hiding ofc ...
18:03:36 <truebrain> we will find out when it hits a nightly π
18:03:53 <talltyler> Woot, now I can split the calendar tomorrow π
18:04:01 <talltyler> One step closer to NoDL!
18:04:10 <truebrain> so close, I can smell it!
18:04:38 <talltyler> Are you saying I should shower? π
18:05:08 <truebrain> yes, but I didn't want to put it like that .... but now you mention it
18:05:26 <belajalilija> alfagamma_0007: Itβs a saying
18:34:46 <truebrain> Rubidium: knowing what you know now, still want to remove the link to the forum? (I am fine either way; just checking before I approve)
18:37:01 <alfagamma_0007> Badger Badger Badger
18:37:07 <belajalilija> Mushroom mushroom
18:37:47 <talltyler> Hmm, for things like `INVALID_YEAR` that are used by both economy and calendar time...is it absolutely godawful form to do "constant overloading" and have one of each type, with the same name? π€
18:38:03 <talltyler> Or do they need splitting into `INVALID_CALENDAR_YEAR` and `INVALID_ECONOMY_YEAR` ?
18:38:10 <truebrain> or make them part of the timer
18:38:17 <talltyler> That would make more sense π
18:38:32 <DorpsGek> - Update: Translations from eints (by translators)
18:43:52 <truebrain> it is so clear how we used to just say: TileIndex .. something-else .. all an integer, lets goooooo π
18:45:32 <talltyler> truebrain: Your strong typedefs are working great, VS is complaining at me about everything π
18:46:05 <truebrain> owh, just so I have said it: our strong typedefs mean: you can put almost any integer in them, and it will auto convert to the strong typedef .. but getting the value out, needs to be explicit
18:46:15 <truebrain> that is not ideal, but otherwise we have many many many many more places to fix π
18:46:41 <truebrain> so they are more: once they become a certain type, you have to use it carefully
18:46:51 <truebrain> but we have to be careful that we actually define it as that type as early as we can
18:56:30 <talltyler> Hmm, ScriptDate does `DATE_INVALID = (int32_t)::INVALID_DATE, ///< A value representing an invalid date.`, what should that reference now?
18:56:52 <truebrain> depends .. will it sometimes return one, and sometimes the other?
18:56:55 <truebrain> or always one of the two? π
18:58:21 <talltyler> They are the same, but I will have to add NewGRF and AI/GS API additions later. I think both need access to both calendar and economy dates.
18:58:38 <truebrain> they are not the same π
18:58:44 <truebrain> their value might be, but that is just luck π
18:58:57 <talltyler> I am tackling API stuff in a future PR
18:59:04 <truebrain> so yeah, `Date` would become `CalendarDate` and `EconomyDate` or something for scripts .. which requires compat work, etc etc π
18:59:18 <truebrain> I don't think you can get away with doing it in a future PR, but it can be a later commit in your PR π
18:59:19 <talltyler> Right now this is the only use of the non-member constant INVALID_DATE left, as I have changed the rest π
18:59:43 <talltyler> I will leave it for now and remove it in a later API commit
18:59:56 <truebrain> build things up .. you have seen that I do the same π
19:00:22 <truebrain> first I made a messy draft PR, which resulted in, what, 10 PRs to fix shit, to make a PR that is actually worth merging π
19:00:24 <talltyler> I'm quickly becoming overwhelmed again, as I haven't been deeply engrossed in this project since April or so and getting back up to speed is...whew, a lot
19:00:41 <truebrain> get it to compile first, is always my goal π
19:00:51 <truebrain> don't worry about all problems at the start
19:01:03 <truebrain> but yeah, script API will be "fun" π
19:01:28 <truebrain> not breaking existing AIs mostly will be fun π
19:03:00 <truebrain> I still wonder how often people actually open the Linux manual page of OpenTTD. But at least it is more up-to-date now π
19:03:34 <Rubidium> I wonder that too :D
19:04:05 <Rubidium> must say it's not the most "markup language"
19:04:43 <truebrain> I can honestly say I never ever made or edited a Linux manual file π
19:04:51 <truebrain> but looking at it ... it looks like a nightmare π
19:05:02 <Rubidium> hmm... it's too late :D I forget to write too many words
19:05:53 <Rubidium> like not doing the 'git commit --amend -a' before 'git push' :(
19:06:24 <truebrain> lol, I never ever forgot to commit before push, NEVAH
19:23:07 <Eddi|zuHause> so what's the order now? edit, save, compile, add, commit, push?
19:24:07 <Eddi|zuHause> at some point inbetween run the automatted and manual tests?
19:24:19 <Eddi|zuHause> man, programming is hard...
19:30:03 <peter1138> Remember with svn, commit before compile was a bit funny.
19:36:46 <talltyler> Now to organize all my changes into the right commits...then test to find whatever I broke!
19:59:08 <talltyler> Commits organized and rebased, let's see if it still compiles
20:01:52 <talltyler> Pushed for safekeeping, still need to test π
20:14:25 <andythenorth> Eddi|zuHause: You forgot optional rebase to tidy history / fix clown errors
20:22:40 <truebrain> talltyler: at least reviewing this is a lot easier, as you know types are correct π
20:26:02 <truebrain> sorry, not actually reviewing, just browsing through to see how the StrongTypeDef is working out
20:26:28 <talltyler> Wait, why are those wrong?
20:26:44 <truebrain> you are casting one timer to the other .. that is not really the idea now is it? π
20:27:50 <truebrain> `v->build_year += static_cast<TimerGameEconomy::Year>(ORIGINAL_BASE_YEAR);`
20:27:56 <truebrain> take that one .. that is mixing two timers π
20:28:21 <talltyler> Yes, those are intentional. I guess I could move those consts to the timer classes as wellβ¦
20:28:34 <truebrain> `a.last_accepted = static_cast<TimerGameEconomy::Date>(SlIndustryAccepted::old_last_accepted[j]);` also feels weird ..
20:28:51 <talltyler> But some casting will be needed for saveload stuff
20:28:54 <truebrain> like .. you get a Calendar timer .. and cast it to Econmy .. without any explanation π
20:29:10 <truebrain> at the very least you need to explain WHY you are casting one timer to the other
20:29:14 <truebrain> (in a comment) π
20:29:31 <talltyler> Yes, I can do that π
20:29:35 <truebrain> but one can wonder if `old_last_accepted` shouldn't just be of the other timer type to start with
20:29:41 <truebrain> as the mixing .. is what we want to prevent π
20:30:59 <talltyler> Ah, I hadnβt traced that one to see where it should be converted π
20:42:14 <truebrain> yeah, and I think for basically all casts from one timer to the other, we actually need to solve it on another level
20:42:22 <truebrain> with the excception of the temporary set-dates ofc
20:46:25 <locosage> is there any way to trigger openttd console command from external app?
20:46:40 <locosage> it doesn't even seem to be reading stdin in non-dedicated mode :(
20:46:45 <locosage> namely `reload_newgrfs`
20:47:35 <locosage> and it doesn't work in mp so there goes admin port option
20:56:08 *** HerzogDeXtEr has joined #openttd
20:56:51 *** virtualrandomnumber has joined #openttd
20:57:48 *** virtualrandomnumber has quit IRC ()
21:13:39 *** nielsm has quit IRC (Ping timeout: 480 seconds)
21:27:01 *** WhilelM has joined #openttd
21:48:53 <truebrain> talltyler: btw, you also have to do things like add an overload for `DateAtStartOfYear` (or template), etc. I know, bit annoying, but it helps in keeping track what timer sits where π
21:49:58 <truebrain> `return static_cast<TimerGameEconomy::Date>(TimerGameCalendar::ConvertYMDToDate(year, month, day));` stuff like that, shouldn't happen. But I guess you get me drift here π And if I can help, let me know!
21:50:51 <truebrain> (and if some functions are shared between the two, you most likely need something like a base-class to avoid copy/paste; but okay, first get it to work, next make it pretty π )
21:51:04 <peter1138> I did that Optimize-VHD thing. It dropped my Debian ext4 vhd from 54,887,710,720 bytes to 53,617,885,184 bytes. Technically it worked...
21:51:47 <peter1138> There's also an ext4 vhd under docker/wsl... I'm not sure why which is for what...
22:00:43 <Eddi|zuHause> is that like defragmentation? :p
22:03:53 <peter1138> I'm just rsyncing my OpenTTD source to a Linux machine, and then I'm going to delete this install...
22:04:48 <peter1138> (I pushed all my branches to another clone, but that doesn't help the millions of stashes I never cleaned up...)
22:11:35 <Eddi|zuHause> one of these days i need to run a system upgrade
22:18:14 <peter1138> Hmm, okay, so the other vhdxs are nothing to do with the Debian install.
22:18:49 <peter1138> I had docker image built with docker desktop, and then removed that, bu t it still leaves the space allocated in the vhdx... this pretty dumb :/
22:24:39 <Bouke> changes. Any suggestions on how I can try and isolate this one change? I'm now down the rabbithole of figuring out if/how to bring in `_viewport_window_cache`.
22:27:28 <peter1138> Heh, Macbook Air M2 is quite reasonably priced... until you configure a sensible amount of RAM and storage.
22:28:03 <_jgr_> However this is not the only drawing related change in my branch, and just applying that will not get you the sort of performance numbers that you posted before
22:30:39 <_jgr_> My branch also includes multi-threaded viewport rendering, which will have a quite significant effect for cases like wentbourne as you'll have a large number of redraw areas
22:33:12 <Bouke> Would that multi-threading be something worthwhile to upstream?
22:33:28 <_jgr_> Possibly, but it's non-trivial
22:35:40 <_jgr_> In general I'd suggest caution about deciding what to port just on the basis of numbers in the FPS window
22:36:58 <_jgr_> It's worthwhile to get a more details look with something like valgrind, gprof, etc
22:44:58 *** keikoz has quit IRC (Ping timeout: 480 seconds)
23:12:52 *** Wolf01 has quit IRC (Quit: Once again the world is quick to bury me.)
23:27:42 *** Flygon has quit IRC (Remote host closed the connection)
23:50:55 *** ChanServ sets mode: +v tokai
23:57:46 *** tokai|noir has quit IRC (Ping timeout: 480 seconds)
continue to next day β΅