IRC logs for #openttd on OFTC at 2025-11-12
⏴ go to previous day
00:01:03 *** gnu_jj_ has joined #openttd
00:04:24 *** gnu_jj has quit IRC (Ping timeout: 480 seconds)
02:32:37 *** Wormnest has quit IRC (Quit: Leaving)
03:00:49 *** ChanServ sets mode: +v tokai
03:07:56 *** tokai|noir has quit IRC (Ping timeout: 480 seconds)
04:00:14 *** gnu_jj_ has quit IRC (Ping timeout: 480 seconds)
04:24:28 *** Zathras_4 has joined #openttd
04:25:22 *** Zathras has joined #openttd
04:28:46 *** Zathras_11 has quit IRC (Ping timeout: 480 seconds)
04:39:43 <DorpsGek> - Update: Translations from eints (by translators)
05:01:13 *** Flygon has quit IRC (Read error: Connection reset by peer)
05:17:11 *** tokai has quit IRC (Ping timeout: 480 seconds)
05:25:26 *** ChanServ sets mode: +v tokai
06:27:33 *** Zathras_1 has joined #openttd
06:28:06 *** Zathras_4 has quit IRC (Ping timeout: 480 seconds)
07:01:06 *** WormnestAndroid has quit IRC (Read error: Connection reset by peer)
07:01:09 *** WormnestAndroid has joined #openttd
07:01:15 *** WormnestAndroid has quit IRC (Read error: Connection reset by peer)
07:01:26 *** WormnestAndroid has joined #openttd
07:01:31 *** WormnestAndroid has quit IRC (Read error: Connection reset by peer)
07:01:43 *** WormnestAndroid has joined #openttd
09:55:32 <Borg> re.. after more thinking how to implement double zoom in in minimap.. I managed to do it quickly.. w/ minimal code changes..
09:55:43 <Borg> and it works! rendering looks proper.. but there is problem
09:56:13 <Borg> when there are some updates to main screen (vehicles running) the whole map flickers per 2 pixels... its damn weird
09:56:19 <Borg> any clues how this can be?
09:58:05 <Borg> DrawSmallMapColumn2() is pretty much the orginal.. I just account for double pixel size.. it could be done better of course (more efficient).. but if its good enough for zoom = 1 (one pass per pixel) I dont see reason to optimize it for doing 1 pass per 2 pixels..
09:58:09 <Borg> it always ended terribly
10:00:24 <Borg> ahh. ok ok.. I think I start getting it..
10:00:32 <Borg> bloody partial redrawing...
10:00:53 <Borg> calculations can be off by 1 in the middle
10:01:02 <Borg> thats why full redraw is okey.. partial is not
10:02:25 <Borg> but shouldnt happen.. we are using integers..
10:07:29 <locosage> Borg, you know cmclient has 2x and 4x minimap zoom?
10:07:55 <locosage> can just look at how it's done
10:08:27 <Borg> locosage: yeah.. but they are far far ahead of my branch
10:08:34 <locosage> I had to port some viewport drawing from jgrpp to fix update issues
10:08:34 <Borg> minimap there is heavly rewritten
10:10:01 <locosage> not that heavily really
10:10:07 <locosage> just more zoom and extra mode
10:10:30 <Borg> locosage: it is.. im working on 1.8.0 branch here.. backporting some stuff..
10:10:53 <xarick> why does it say ContentInfo is undefined but still builds?
10:10:54 <Borg> they get rid of that subscroll and subpixel thingie, good because it was awfull
10:11:23 <locosage> ugh, 1.8.0, nvm then
10:29:00 <Borg> ha at least I know where the problem is now..
10:29:09 <Borg> I made all zoom levels flicker
10:45:48 <Borg> okey enough :) one day... :)
13:20:50 <peter1138> Doesn't anyone know why 1.8.0...
13:21:26 <peter1138> Or even Does anyone...
13:22:36 *** kuhnovic has joined #openttd
13:22:36 <kuhnovic> "Everything was better back in the good old days"
13:23:25 <peter1138> I still don't see what the point of 14752, there's no performance figures still.
13:26:53 <locosage> it's a draft for now anyway
13:29:13 <locosage> also, having trouble to measure it consistently for some reason
13:29:40 <locosage> it's pretty clear compared to master ofc since it's up to 2x but between implementations gets kinda dicey
13:30:45 <kuhnovic> Which part goes 2x? The world ticks? Or do you use your own metrics?
13:31:38 <locosage> though if I run with -v null it's 2x the whole run minus game loading
13:32:58 <locosage> but -v null is very inconsistent for some reason
13:35:37 <kuhnovic> Just for fun I made a toggle so that I can change between the original game loop and just linearly looping over the tile array, which of course is super cache friendly. It does give a huge boost in World Ticks (up to 5x faster on my machine), but that's a synthetic ideal scenario. In a savegame like Wentbourne it not noticable at all, it's simply not the bottleneck.
13:36:33 <locosage> it's not the bottleneck sure, but it's still somewhat important, especially on slower machines
13:37:52 <locosage> you only get like, what, 27 ms for the frame so shaving a few is still good
13:39:54 <kuhnovic> You would also notice it when generating large maps. That does feel like Xarick-optimisation though.
13:42:30 <locosage> also when fast forwarding without limit for testing stuff
13:42:55 <locosage> but it's not a complex change and it improves every game
13:43:39 <locosage> I remember a few years ago world tick taking 1/3 of the frame time in some cases
13:43:48 <locosage> but looks like some stuff got optimized since
13:52:45 <locosage> this is the save from the MH event most players couldn't stay in due to the lag
13:52:58 <locosage> world ticks is the second largest culprit after train tics
13:53:31 <locosage> 2x on that and it could've been playable till the scheduled end of the event
13:55:13 <locosage> and yeah, my pc can do 4x on that save on master but apparently not many players have that kind of performance
13:58:37 <kuhnovic> Could you add that save to the PR? Just so we have a concrete use case
14:02:35 *** Wormnest has joined #openttd
14:07:40 <locosage> Added those saves in the pr description
14:08:10 <locosage> They're a bit extreme because of lots of water so I'm testing on wentbourne and other saves too
14:11:54 *** Borg has quit IRC (Quit: leaving)
14:13:16 <xarick> scenario editor - create flat map
14:36:43 <_glx_> flat map is rarely the best test case
14:38:21 <peter1138> Animated tile and water flooding performance was improved over time.
14:39:55 <peter1138> What is actually "cache friendly" in this thing? Seems unlikely to be actually accessing the map itself because that's still spread out.
14:44:31 <xarick> the actual cpu physical cache?
14:46:52 <locosage> It's one thing to be spread over kilobytes and another over megabytes
14:47:01 <locosage> I checked with perf, it does reduce cache misses
14:54:52 <_glx_> ok so when testing with debug build I see 40ms peaks in master while everything is under 10ms in suspendable, and with release builds it's 7ms peaks in master and under 1ms in suspendable
14:55:16 <_glx_> (for default 10k ops/tick)
15:10:19 <xarick> tons of ram usage for the same work
15:11:32 <xarick> let me experiment calling Begin on every list
15:42:56 <locosage> hm, maybe instead of trying to find balance between tile loop randomness and performance it's better to just make a setting
15:43:25 <locosage> I bet a lot of players will happily accept linear tile loop if that means they can continue playing their game a bit more
15:43:51 <locosage> maybe even some kind of performance mode in general would be a good idea
15:44:03 <locosage> just sacrifice some less important parts
15:45:41 <xarick> with lists initialized
15:47:24 <_jgr_> locosage: This is totally opaque to players, such a setting would generate user confusion more than it would help with anything
15:48:40 <kuhnovic> I agree, that is not something for the player to decide. Developers should keep the freedom to determine such things, and change them when needed.
16:10:06 <talltyler> (I renamed it to make more sense 🙂 )
16:11:38 <rito12_51026> Sorry, I didn't notice that
16:39:53 *** gelignite has joined #openttd
17:07:25 *** kuka_lie has joined #openttd
17:42:36 <xarick> deleted some merged branches
18:07:29 <peter1138> merged some deleted branches
18:08:45 <xarick> about #14753 ... how's it gonna be?
18:09:39 <xarick> the compatibility layers are a bit too specialized imo
18:09:40 <peter1138> Yeah, that's a super weird way of wording that fix (#14770)
18:10:25 <peter1138> I guess someone thought merging would use the PR's renamed title.
18:15:16 <xarick> let me test the theory GSList.BeginCompat in 15
18:34:05 <andythenorth> frozen scampi from 2020
18:42:06 *** WormnestAndroid has quit IRC (Read error: Connection reset by peer)
18:42:08 *** WormnestAndroid has joined #openttd
19:26:43 <andythenorth> is 'terrain' (1) 'land' and 'water' (2) desert, rainforest, snow etc?
19:26:55 <andythenorth> (naming things in grf compile)
20:03:01 <peter1138> Yeah, wtf is that meant to be.
20:15:32 *** Zathras_4 has joined #openttd
20:55:38 <xarick> something's still amiss
20:56:59 <andythenorth> this is for flags to build on water and land
20:58:34 <xarick> the compatibility layer does not totally replicate the behaviour of 14
20:59:07 <xarick> left: master, right: 1473'ish
21:01:39 <_jgr_> Yes, the behaviour in 14 is incorrect, that is the main point of the PR
21:02:23 <_jgr_> The change to null is an extra thing, might be better to not bother with that if it's too much hassle
21:58:20 *** Wolf01 has quit IRC (Quit: Once again the world is quick to bury me.)
22:30:05 *** keikoz has quit IRC (Ping timeout: 480 seconds)
22:37:28 <xarick> if that's the way forward, std::optional could just be 0
22:38:00 <_glx_> yeah compat script for lists are a pain, you need to redefine Next() and Begin() for all lists
22:38:20 <xarick> i think i had something, sec
22:38:29 <_glx_> doing it for base class doesn't affect derived
22:38:58 <_glx_> because squirrel just copies the members
22:40:17 <_glx_> so if you have A with a a() member, and B derived from A, then B will have a copy of a(), and redefining A::a() won't change B::a()
22:41:27 <_glx_> std::optional is cleaner
22:42:20 <_jgr_> xarick: This does not fix the behaviour in Remove, which is what this was all originally about
22:43:03 <xarick> ah, it's to be cherry picked upon the original commit some weak ago
22:46:24 <_glx_> but this one is gone now 🙂
23:00:00 *** kuka_lie has quit IRC (Quit: Lost terminal)
continue to next day ⏵
