IRC logs for #openttd on OFTC at 2023-11-29
⏴ go to previous day
01:01:51 *** _zephyris has joined #openttd
01:01:51 <_zephyris> (I've been playing with interface scale!)
01:02:33 <peter1138> Careful it might stick.
01:05:28 <_zephyris> Only if the wind changes direction!
02:42:42 *** Wormnest has quit IRC (Quit: Leaving)
03:15:18 *** D-HUND has quit IRC (Ping timeout: 480 seconds)
05:41:14 *** esselfe has joined #openttd
06:58:06 <andythenorth> my cdist game appears to be stuck in an 'any station' next hop mode
06:58:14 <andythenorth> frankly this is a lot more fun 😛
06:58:39 <andythenorth> I suspect this savegame is pathologically broken somehow for cdist
07:00:31 <andythenorth> it isn't broken enough to just be doing point-to-point
07:00:48 <andythenorth> pax and mail are staying on vehicles over multiple hops, as expected
07:01:08 <andythenorth> I don't have huge backlogs at stations either though
08:04:25 *** _pruple has joined #openttd
08:04:25 <_pruple> off to find some newgrf truckstop inspiration 🙂
08:05:41 *** nairda00 has joined #openttd
08:09:00 *** alfagamma7 has joined #openttd
08:09:00 <alfagamma7> euro truck sim ig???/
08:12:09 <_pruple> alfagamma7: american truck sim, is it not.
08:12:29 <alfagamma7> missed it by a margin oops
08:20:44 <peter1138> Scandinavian Truck Sim
08:21:26 <peter1138> Ivan "Ironman" Stewart's Super Off Road Racing
08:55:38 <peter1138> Having to remove an assert to make something work seems like a bad sign.
08:59:23 <peter1138> Especially when it doesn't work :o
09:08:26 *** marchnex has joined #openttd
09:09:25 *** ahyangyi has joined #openttd
09:11:43 *** thelounge34 has joined #openttd
09:39:49 <peter1138[d]> src/openttd/src/settings_gui.cpp:875 783x1017 to 522x678 (300% to 200%)
09:39:49 <peter1138[d]> src/openttd/src/settings_gui.cpp:875 522x618 to 522x618 (200% to 200%)
09:39:57 <peter1138[d]> Interface scaling make up your mind
09:42:17 *** virtualrandomnumber has joined #openttd
09:42:40 *** virtualrandomnumber has quit IRC ()
09:43:19 <Rubidium> might there be some paddings that get scaled too late? Though 60 pixels worth of paddings is a bit much...
09:46:06 <peter1138> No it's actually correct. The it's because the height of the baseset descriptions is not included in the minimum size, it is calculated in a second pass (which is why there are two passes)
09:46:45 <peter1138> But it just happens to be exactly the same size after recalculating.
09:47:43 <peter1138> I think I'm getting some kind of keyboard dementia.
09:53:52 <peter1138> We could've saved so much hassle by just drawing everything at 1x and then scaling with OpenGL ;)
09:55:27 <peter1138> I wonder if "Auto-detect size" should use some relationship with main window size rather than the video driver's reported DPI.
10:23:22 <_zephyris> I noticed toyland was just using temperate river banks
10:26:36 <LordAro> rocks in the rapids should be something amusingly whimsical
10:27:58 <_zephyris> and what best ammuses your whimsy? 🙂
10:28:35 <LordAro> i was thinking some form of boiled sweet
10:28:46 <LordAro> though that'd probably just be a couple of pixels
10:33:19 <_zephyris> Toyland needs more shark fins
10:34:11 <_zephyris> I was going to remove the rocks and leave it just plain water, but some whimsy would be fun
10:36:06 <_zephyris> Or do blocks like the rocky terrain tiles
10:36:21 <peter1138> Is this for 'vanilla' or OpenGFX2?
10:37:36 <peter1138> Not that it matters too much, but there's probably a certain styling it should stick to.
10:37:58 <peter1138> i.e. borrow bits from original sprites :)
10:38:23 <_zephyris> I've already carefully copied the ground shading
10:39:42 <peter1138> Hmm, run out of cereal to snack on because... I already snacked on it :/
11:12:04 <peter1138[d]> OpenTTD: Idle Edition
11:29:48 *** APTX_ has quit IRC (Quit: Farewell)
11:39:58 <peter1138> Changing base set mid game?
11:45:46 <peter1138> "Deep Down Chemistry Lab" -- the darker side of OpenMSX?
12:06:02 <_zephyris> peter1138: Would be nice, not clear to me why you can't change baseset...
12:41:59 <peter1138> That was surprisingly less code than I anticipated.
12:50:33 <peter1138> jfs, do the intro-game viewport scrolling commands ignore the standard viewport scrolling system? It seems a bit jumpy on my system.
12:50:43 <_zephyris> 👍 I suspected it might be a simple minimum window size thing
13:00:20 <peter1138> Rise of the Triad has an epic version of Adagio for Strings (and Organ)
13:30:09 <peter1138> Been and gone, sorry.
13:30:25 * peter1138 awaits running pipelines.
13:30:34 <peter1138> await RunPipelinesAsync()
13:32:20 <peter1138> Window resizing and viewport resizing still has the "we couldn't make it any bigger when you made the interface scale bigger, but now we're going to shrink because you made the interface scale smaller" 'issue'
13:32:38 <peter1138> Although I suppose the viewport one is also a clamping error currently.
13:37:59 <peter1138> On the next pipeline will start sooner if I actually press the button to create a PR.
13:38:30 <_zephyris> peter1138: Less of an issue IMO
13:38:32 <peter1138> Maybe I should do Continuous Integration "properly"
13:38:51 <peter1138> Just commit everything to main, sure.
13:40:30 <_zephyris> I've been poking the sprite aligner BTW, thinking about whether to use 4x vs 1x offsets, step sizes for changing... I think there are issues I'm afraid.
13:41:22 <_zephyris> Key thing is that alternate sprites for each zoom level (and each bit depth) can have their own offsets - but this isn't visible.
13:41:48 <peter1138> I did tweak the window once but there wasn't concensus on how it should behave and I got sidetracked from it again.
13:42:09 <_zephyris> Fair enough, no worries.
13:42:33 <_zephyris> But it does kill some of the usability. I think this explains some of the issues I've had determening alignments.
13:42:35 <peter1138> The code checks that offsets match on loading though.
13:43:01 <_zephyris> Does it? They don't need to, right?
13:43:26 <_zephyris> My templates for ground sprites have zoom-dependent y offsets, but doesn't throw errors...
13:43:34 <peter1138> size and offsets need to match.
13:44:36 <_zephyris> Do you mean for a 8bppmask and 32bpp?
13:45:08 <peter1138> I mean for different zoom levels of the same sprite.
13:46:33 <peter1138> Did _pruple design that?
13:47:32 <peter1138> Anyway, that is still considered the same offset because the difference is less than 1 pixel at the next zoom level. (Approximately that reasoning)
13:48:39 <_pruple> yrel schmyrel, what about the off-by-one xrel? 🙂
13:52:31 <_zephyris> So here... Offsets listed in the aligner seem to be 1x zoom sprite offsets * 4 (-31, 0), but because I'm using 2x UI scaling the 2x zoom sprite is shown in the aligner, and when I change the alignments the 4x zoom sprites change in the isometric world.
13:53:57 <_zephyris> So the listed absolute offsets can always be wrong - they're not 1x alignments (you have to divide by 4), they're not the offsets for the 2x sprite shown in the UI, and the 4x sprite might have different 'starting' offsets so the absolute offset is wrong.
13:54:21 <_zephyris> (Or am I totally confused/wrong!?)
13:56:46 <_pruple> I suppose the sprite aligner was not created with the idea that you might actually provide different sprites for different zoom levels
13:57:56 <_pruple> I have 2x sprites and the numbers shown in the aligner are double the coded alignments, so the same alignment but at 4x.
13:59:58 <peter1138> If the aligner let you pick zoom level independently then there'd be no ambiguity right?
14:00:36 <_zephyris> Well, and bit depth
14:01:29 <_zephyris> _pruple: The Y offset should be -2 for this sprite at 4x, unless I messed up my templates
14:02:10 <peter1138> Hah, there's not even a way to draw 8bpp sprites if 32bpp sprites exist at the same zoom level.
14:02:38 <_pruple> OTOH, offsets should be pretty mathematically straightforward (especially if you correct the off-by-one xrel). The sprite aligner shoudn't be something grf authors need to resort to very often.
14:04:38 <_pruple> and there's always the headache/confusion that the offsets are going to change for a sprite cropped in compile, which makes it even less useful for getting actual numbers out
14:05:10 <peter1138> Whatever is cropping your sprites during compile should be adjusting the offsets.
14:05:23 <peter1138> (But cropped sprites is bad for GUI sprites)
14:05:32 <_pruple> but that means the numbers in game do not match the numbers in nfo/nml
14:06:16 <_zephyris> _zephyris: ... looks like I have messed up my templates 🙂
14:06:42 <_zephyris> Personally I make the grf witout sprite cropping when doing sprite alignemnts, then allow cropping for final grf genertion
14:08:47 <peter1138> I think you can sneak in different offsets between 8bpp and 32bpp sprites because the game only ever looks at one set.
14:09:25 <peter1138> Niche developer mode: switch blitter between 8bpp and 32bpp in game...
14:10:58 <_pruple> "should be" -124 -2. Oh no. Anyway...
14:11:49 <peter1138> Because the original baseset was -31 instead of -32.
14:13:46 <_pruple> someone should vandalise that wiki page and change it.
14:13:48 <peter1138> if (!newgrf_uses_pikkas_new_offsets && some_how_we_can_detect_this_is_a_sprite_that_is_drawn_in_a_viewport) x_offs -= 1;
14:14:03 <peter1138> _pruple, that's why I asked if it was your design... if not it's probably not the most useful :)
14:14:43 <peter1138> You could do 1x8bpp at -31 and 2x/4x32bpp at -64/-128.
14:14:50 <peter1138> They aren't going to match anyway.
14:15:55 <_pruple> my 1x8bpp ground sprites are 16x16 pixels with offsets of 0 0, just like all my other 1x8bpp sprites 😛
14:16:45 <peter1138> Actually... ❓ exists...
14:18:38 <_pruple> it's pretty conventional for 32bpp sets to just use a placeholder for the required 8bpp sprites, since they're never seen. It would be a lot of pointless work to make them pretty. 🙂
14:20:02 <peter1138> The convention was meant to be "convert to 8bpp sprites so that players can use 8bpp mode"
14:24:40 <_pruple> yeah, but who wants to use 8bpp mode, or encourage others to?
14:29:34 <_zephyris> Ah, I remember. `ceil` isn't an NML function, so you can't do `z * yrel + ceil(z * -1/2)`. I wonder if `z * yrel + z/2` works.
14:29:37 <_pruple> it'd be a huge amount of work, to create a substandard result. personally, I'm happy to forgo the miniscule potential newgrf audience who might be running hardware so old they need to use the 8bpp blitter.
14:30:51 <_zephyris> Probably 100% scriptable.
14:31:14 <_zephyris> But it is only ever likely to affect a small niche set of players
14:32:35 <peter1138> I think V had scripts to automate generating 8bpp sprites from 32bpp + mask source material.
14:37:47 <_zephyris> It'd be pretty trivial to write a grf post-processer. Decompile, grab and scale 32bpp sprites, make 8bpp using masks to grab animated/recoloured indices, recompile pointing to new 8bpp images.
14:39:49 <peter1138> Or make OpenTTD do it on the fly.
14:40:03 <peter1138> Or make OpenTTD not load 32bpp-only files.
14:40:27 <_pruple> there's no such thing as 32bpp only files
14:40:55 <_pruple> but I'm a big advocate of "don't use my grfs then" as a solution for people who don't like 32bpp graphics
14:42:10 <_glx_> people don't dislike 32bpp, they dislike mixing EZ and non EZ
14:42:39 <peter1138> Only because there's some requirement that your 16x16 placeholders have to exist.
14:51:36 <_pruple> _glx_: nah, there was some pretty strong denigration of both 32bpp and ez, particularly from certain grf authors who were worried it was a threat to the ancient laurels they rest on. And in my case, at least, it's left a pretty bitter taste to any discussion of "compatibility", and certainly no desire to accommodate 1x or 8bpp purists.
14:52:07 <andythenorth> wasn't it just me?
14:55:25 <jfs> peter1138: yeah it doesn't use the standard way for some specific reason, I think that it might be related to always doing a "smooth scroll" and not having a way to force a jump cut (in retrospect maybe I should have just added that instead)
14:55:36 *** virtualrandomnumber has joined #openttd
14:55:51 *** virtualrandomnumber has quit IRC ()
14:56:17 <peter1138> The standard scroll would need to be modified to run at the desired pace as well.
14:56:40 <peter1138> I get why it doesn't, just making I wasn't missing something :)
15:15:39 <peter1138> _zephyris, any previews of ez version available? :D
15:26:00 <brickblock19280> They are on the OpenGFX2 GitHub iirc
15:31:34 *** Flygon has quit IRC (Quit: A toaster's basically a soldering iron designed to toast bread)
15:31:46 <peter1138> Well, aligning 1x sprites is a pain because they're so small ;p
15:32:38 <peter1138> Also, internally the game does not support different offsets for different zoom levels.
15:33:09 <peter1138> Only the max-zoom offsets apply.
15:49:16 *** wallaby2 has joined #openttd
15:52:03 *** wallabra has quit IRC (Ping timeout: 480 seconds)
16:11:36 <andythenorth> Goes it throw out 1x
16:12:45 <peter1138> So you can't zoom out?
16:34:06 <_zephyris> peter1138: Only max applies(!?) So all the stuff about recommended alignments for different zoom levels ends up being ignored?
16:34:24 <_zephyris> Oh, I guess that's not the case. If the game's not using EZ sprites then it'll use the alignments for 1x
16:35:37 <_zephyris> Oh no... I feel the urge to make a test grf
16:36:16 <peter1138> The game always uses those alignments, but they are rounded out for other zoom levels.
16:36:54 <peter1138> I am probably wrong.
16:39:57 *** Wormnest has joined #openttd
16:42:25 <peter1138> The intermediate offsets are checked on load, but then thrown away. Only the max zoom offsets are used.
16:46:54 <peter1138> Problem currently is there are 2 standard for 4x 32bpp offsets now :/
16:48:06 <peter1138> Maybe we could implement a flag for -31 vs -32
16:48:40 <peter1138> When drawing a viewport sprite, -1 if not pikka-mode.
16:49:04 <peter1138> Action 14 may not be the right thing.
16:49:12 <peter1138> What's the one that sets palette etc?
16:49:24 <peter1138> There's also that depot y-offset gubbins.
16:49:50 <peter1138> Hmm, that would make offset aligner tricky to use :)
16:54:20 <frosch123> the baseset is not free to choose a groundsprite offset
16:54:32 <frosch123> halftile-foundations cut the sprites at fixed positions,
16:54:41 <frosch123> those define the center of the tiles
16:56:01 <andythenorth> did cdist change?
16:56:16 <andythenorth> it's no longer routing to specific next hops
16:56:31 <andythenorth> but it is routing over multi-hop journeys
16:58:16 <_zephyris> Right. OpenTTD definitely uses the alignment data from the 1x and 4x alternate sprite, I can deliberately misalign a 4x sprite and it looks fine at 1x.
16:59:19 <_zephyris> But, I'm getting inconsistent sprite aligner behaviour. It seems to report the 4x sprite offsets if the y offset is negative, it seems to report the 4*1x sprite offsets if the 4x y offset is positive!?
17:00:13 <frosch123> _zephyris: i think it extends the sprites with transparent pixels until all zoom levels have the same bounds
17:01:09 <_zephyris> Ohhh, hmm, which could possibly explain that funny +ve/-ve behaviour
17:01:33 <frosch123> so if 1x sprite goes from (10, 10) to (20, 20), and 4x sprite goes from (5, 15) to (15, 25), the final sprite will go from (5, 10) to (20, 25), and the displayed offsets refer to that
17:03:18 <peter1138> Oh right. I'd completely missed that PadSprites exists.
17:04:09 <peter1138> Hmm, so the -128 'notbase' set doesn't have foundation sprites yet. Did _pruple give up on it?
17:04:22 <_zephyris> So the sprite aligner absolute offsets are guaranteed to be garbled unless you have 4x sprites which have exactly 4x the dimension and 4x the offset.
17:05:28 <peter1138> I guess we could also store how much padding was added. But unequal size sprites was kind of an edge case?
17:05:55 <_zephyris> Well... every ground/infrastructure tile
17:06:34 <_zephyris> 256 x 127 is not 4x 64 x 31
17:07:39 <_zephyris> And analagous for the slopes
17:07:46 <peter1138> Ah no, because if they're not padded equaly we'd need to store ZOOM_LVL_END sets of padding information, just to show it in the aligner.
17:11:54 <_zephyris> Could just use the relative offset / zoom and the orignal (in grf file) offset?
17:13:00 <peter1138> That information is not available once it's all resized and padded.
17:13:37 <_zephyris> Storing original is equivalent to storing padding then
17:16:25 <peter1138> Once all the conversion is done there is one width, height, x_offs & y_offs. And because of the padding, my "other-zoom level offsets are not used" is not correct, they'll be included in the padding.
17:16:52 <_glx_> I may have a working solution for nightiles failures
17:20:46 <peter1138> Anything other than half-tile foundation cutting that would need to be addressed to support -128 instead of -124 offset?
17:21:07 <peter1138> I think there was one relative-offset issue that I already fixed, but I can't remember once...
17:21:33 <peter1138> Child sprites on foundations I think.
17:25:33 <peter1138> _zephyris, 4x 32bpp OpenGFX2 is looking good :D
17:41:19 <_zephyris> Thanks! I think I've found a style that works and is achievable at scale
17:49:27 <peter1138> Hmm, could do with "out" and "in" or just refering to 4x as normal. But...
17:50:02 <peter1138> Well, this is the terminology used in the settings windows so.
17:52:24 <peter1138[d]> Narrowest dropdown list?
17:57:30 <peter1138> Okay, that window could do with being resizable...
18:20:52 *** blathijs has quit IRC (Quit: WeeChat 4.0.5)
18:26:34 *** virtualrandomnumber has joined #openttd
18:28:55 *** virtualrandomnumber has quit IRC ()
18:42:37 *** virtualrandomnumber has joined #openttd
19:29:20 *** HerzogDeXtEr has joined #openttd
19:49:43 *** blathijs has joined #openttd
19:49:43 *** ChanServ sets mode: +o blathijs
19:49:55 <_pruple> peter1138: Yes, the notbase has foundations
19:50:47 <_pruple> Yes, we ran into the problem of the foundations cutting the sprite in the wrong place
19:51:15 <peter1138> Oh, right, the version I grabbed is probably old./
19:51:20 <_pruple> Yes, you fixed it for me 🙂
19:54:58 <_pruple> The version on bananas is pretty old, but it should have foundations I think. Aiming for a proper release at Christmas... Been a long time coming. :/
19:54:58 <_pruple> Gotta do real life stuff today though (on 3 hours sleep...)
19:56:55 *** truebrain has joined #openttd
19:56:55 <truebrain> nice solution _glx_ 🙂
20:07:32 *** gelignite has joined #openttd
20:19:04 <truebrain> Enjoy the stats while they last !
20:22:37 *** virtualrandomnumber has quit IRC (Quit: virtualrandomnumber)
20:29:35 <peter1138> #10623 is quite old for an approved PR ;)
20:29:46 *** gelignite has quit IRC (Quit: Stay safe!)
20:30:53 <truebrain> people wanted to wait for survey results
20:34:30 <peter1138> Ah, and that needs a release.
20:35:29 <truebrain> yup ... and I guess we should finish daylength for that first 😛
20:36:35 <truebrain> or we can be evil and release in less than a month, just saying 😛
20:39:07 <LordAro> i did wonder when the first beta was going to happen
20:41:03 <truebrain> I think we should do two things: testrun de ShipPF changes, make the code neat, and just merge it ... we don't have to understand the changes, but it "seems nice" 😛
20:41:17 <truebrain> and testrun the daylength changes, get the last reviews out, and get that in
20:41:25 <truebrain> but mostly: testrun ...... 😄
20:41:33 <truebrain> so maybe over xmas we should have 1 or 2 events to get that done
20:42:27 <truebrain> I keep hoping talltyler arranged the first, but it seems he has been busy too 😦
20:50:25 <talltyler> I can help arrange an event, but yes, busy…
20:51:04 <talltyler> I’m moving house next week (11th time in 8 years!) and all my OpenTTD time goes toward NotDaylength
20:51:23 <truebrain> it wasn't a complaint, more a "life is annoying" 😛
20:51:34 <truebrain> and good luck with the move 😄
20:53:20 <truebrain> it no loner is only a daylength milestone
20:54:56 <talltyler> Go for it, I can get it done
20:55:52 <peter1138> I play too much Doom to get things done.
20:56:27 <_glx_> and yet you multiply PRs 🙂
20:56:28 <talltyler> You make more PRs than the rest of us combined, at least recently 🙂
20:57:11 <talltyler> Okay, so as far as test games go, let's do Ship Pathfinder first and wait on NotDaylength until it's actually ready
20:57:29 <talltyler> Can we build an .exe from the PR for players to use, or does it need rebasing?
20:57:31 <truebrain> hopefully in a week or 3 I have time to actually look at your work again
20:58:29 <truebrain> talltyler: there appear to be no releases for that PR; so a rebase first is advised 🙂
20:58:35 <talltyler> I'll be traveling December 20-31 so nothing will get done during that time 🙂
20:59:06 <truebrain> pretty sure I did make a build, but I can't find it 😦
21:00:40 <talltyler> How's the weekend of December 16-17 for people to play a test game?
21:01:23 <truebrain> ah, the build failed, I asked for a rebause, kuhnovic kindly did a rebase, I never hit the release button again 😦 Sorry 😦
21:01:26 <_glx_> I think you wanted to make a build but it required a rebase
21:09:49 *** HerzogDeXtEr has quit IRC (Read error: Connection reset by peer)
21:13:30 *** nielsm has quit IRC (Ping timeout: 480 seconds)
21:13:49 *** gnu_jj has quit IRC (Ping timeout: 480 seconds)
21:19:18 <truebrain> peter1138: I promised a long time ago, but finally I started the crunch again for performance information since ... checks notes .. 2023-08 😛 So "soon" we have graphs how your changes impacted the game 🙂
21:19:44 <peter1138> I bet nothing, because I can't remember what it was.
21:20:02 <truebrain> things like flipper variables in classes
21:20:48 <truebrain> hmm .. lot of warnings ..
21:20:59 <talltyler> Speaking of PRs for 14.0, this one is still being rebased by the author, just waiting on Peter's industry vector patch (linked in the PR) 🙂
21:21:00 *** bigyihsuan has joined #openttd
21:21:00 <bigyihsuan> talltyler: boat game
21:21:25 <truebrain> nlohmann creates warnings on this build machine .. something for another day
21:22:12 <_glx_> it does on release CI too
21:22:20 <truebrain> we should fix those 🙂
21:22:34 <peter1138> Oh, let me updated that branch.
21:22:39 <_glx_> I just noticed them when testing my PR
21:30:57 <truebrain> okay, without refining which commit did it, that will come over night when data comes in, I can say that all games, across the board, use significant less memory 🙂
21:31:38 <truebrain> wentbourne went from 161MB to 131MB, which is the lowest decrease of them all
21:31:40 <peter1138> Was it the sprite cache allocated 768MB or something...
21:31:47 <truebrain> no, that is virtual memory
21:31:53 <truebrain> this measures actual memory
21:32:03 <peter1138> I know, I am turning that into another meme :)
21:32:07 <truebrain> CPU-wise, I am looking at a very flat line
21:32:27 <truebrain> peter1138: lol, it is not even a bad meme 😛
21:33:07 <truebrain> some games need 7% less CPU now to run, but those were already on the low side
21:33:26 <truebrain> on average, about 0.5% less CPU usage over the last 3 months
21:34:05 <peter1138> I remember there was something performance related that was pretty minor but show a benefit in all my tests. It then disappeared when it was turned into a PR and merged.
21:34:07 <truebrain> only 1 (!) game shows an increase in CPU .. the game with 1 big fucking town 😛
21:35:06 <truebrain> so that is a very nice result, for all the changes done in the last few months 🙂
21:35:32 <peter1138> That's a blip there though.
21:35:40 <truebrain> I will trace the exact commits that made a change, possibly detecting any commit that was a regression
21:36:17 <peter1138> Does this miss intermediate commits? Seems a very straight line.
21:36:30 <truebrain> that is what I have tried to say in 2 different ways in the last 5 minutes 🙂
21:36:49 <truebrain> but to refresh your memory (hihi), this tool I wrote bisects
21:36:51 <peter1138> See, I can understand pictures but words are hard.
21:37:04 <truebrain> so it first does the first and last date, and then starts to fill in the rest
21:37:09 <truebrain> (via bisect approach)
21:37:34 <truebrain> overview of the last 2 years or so
21:37:47 <truebrain> it shows better how much your changes impacted memory usage 🙂
21:37:49 <peter1138> That probably means a lot more compiling changes than doing it sequentially -- although if it's a clean build every time that's irrelevant.
21:38:09 <truebrain> it is a clean build, as I don't want to gamble on the compiler doing the right thing 😛
21:38:34 <truebrain> (the dotted lines are events I recorded, in case you were wondering)
21:39:18 <peter1138> Hmm, we had a CPU regression in June though.
21:39:32 <peter1138> Which coincides with a memory drop.
21:39:53 <truebrain> "Allocate enough memory to layout the strings"
21:39:56 <truebrain> is the note on that annotation
21:41:01 <truebrain> and it was only a regression for the smallest of the games
21:41:12 <truebrain> I believe I concluded that those were acceptable 😛
21:41:25 <peter1138> Oh yes, %ages don't show the full story.
21:41:48 <truebrain> also too many lines 😄
21:41:53 <truebrain> I should make an error-bar or something 😛
21:42:01 <peter1138> I wonder if it was THAT commit or one near it.
21:42:17 <truebrain> to show a zoomed-in variant on that moment
21:42:35 <peter1138> Ah, so slightly earlier.
21:43:11 <truebrain> and I only make 1 build per day btw 😛
21:43:23 <truebrain> I am not -that- crazy 😄
21:43:59 <truebrain> anyway, most opntitles went from 50MB RAM to 30MB RAM
21:44:03 <truebrain> so that is a nice improvement tbh 🙂
21:44:16 <peter1138> Okay it's probably just more use of std::string instead of C strings.
21:44:37 <peter1138> Hence why it was definitely decided not a problem :)
21:45:02 <peter1138> We saved 20MB, that does seem inconsequential :)
21:45:05 <truebrain> yeah, it is important to not look at any of this in isolation 🙂
21:45:12 <truebrain> 50 -> 30 ... that is ... nice 😄
21:45:34 <peter1138> 0.03% of my memory :D
21:45:36 <truebrain> now he can run .. 30% more OpenTTD instances!
21:46:19 <truebrain> slowly more points arrive 😛
21:46:23 <truebrain> but more details tomorrow 🙂
21:47:06 <peter1138> Thanks. This is pretty useful.
21:47:34 <truebrain> very curious if that 1 game that spikes in CPU is an actual thing, or just a measurement error 🙂
21:49:34 <truebrain> I also think I scripted this enough, that I might be able to attach this to a GitHub workflow, and run it every night against the linux-generic .. something to look into over xmas 😛
21:53:29 <LordAro> the same thought occurred to me
21:53:48 <LordAro> tricky to guarantee the same CPU though
21:53:58 <truebrain> the reason I didn't do it 3 months ago, is because new dependencies can have a big impact on performance .. so for this run, I am using the EXACT some dependencies
21:54:07 <truebrain> also the reason I am compiling it all myself
21:55:14 <truebrain> and yeah, not having the CPU can have an impact .. I am using `perf` , so it is only an issue if it is a different generation and/or Intel vs AMD
21:55:47 <truebrain> also, I still need a bit more savegames with different types of behaviour 🙂
21:56:34 <truebrain> better way of visualizing might also be good 😛
22:03:39 <peter1138> I think I've found a solution to the stumbling block of the industry-vector patch.
22:04:45 <talltyler> Are you currently running naked through the streets back to your computer, shouting "Eureka?"
22:07:04 <_glx_> too cold outside for that
22:07:32 <peter1138> Also not a mental image I need, let alone anyone else.
22:08:08 <peter1138[d]> Debug window is debugging.
22:08:22 <peter1138[d]> That's a vector that does not have 16 items in it.
22:26:59 *** keikoz has quit IRC (Ping timeout: 480 seconds)
22:36:57 *** ChanServ sets mode: +v tokai
22:43:59 *** tokai|noir has quit IRC (Ping timeout: 480 seconds)
22:47:47 <peter1138> Hmm, dunno how to add a section on the tt-wiki.
23:10:59 *** Wolf01 has quit IRC (Quit: Once again the world is quick to bury me.)
23:33:47 <_zephyris> \*Toyland induced silence\*
23:36:47 <peter1138> Can you add a little bit of rapids in the water so it doesn't look like they're randomly misplaced pixels?
23:38:36 <_zephyris> Yeah, I could add a bit of 'splash' just upstream of the rocks
23:39:03 <_zephyris> Thanks for #11518 btw, looks like a great solution.
23:39:19 <peter1138> upstream or downstream, something that makes it look like it belong there :)
23:40:12 <peter1138> #11518... hopefully. Ignoring the sprite padding revelaton...
23:41:01 <_zephyris> Very happy to test a trial build, I've got a multi-zoom level test grf for stress testing
23:41:38 <_zephyris> It looks like it should fully fix usefulness of Relative offset tweaks
23:43:05 <_zephyris> peter1138: Toyland will look better than the 'normal' climates 😉
23:51:53 <peter1138> 1824 -> 98 slots, 20064 -> 1216 bytes
23:52:10 <peter1138> 41888 -> 2302 slots, 460768 -> 26480 bytes
23:52:32 <peter1138> Hmm, what does that PR do...
23:54:32 <peter1138> 41888 -> 2302 slots, 2387616 -> 150128 bytes
23:55:42 <peter1138> Hmm, that doesn't add up.
23:55:58 <peter1138> Oh it's combined in/out
continue to next day ⏵
