Times are UTC Toggle Colours
00:25:26 <DorpsGek> [OpenTTD/OpenTTD] rubidium42 opened pull request #11514: Codechange: pass std::string references to OpenBrowser https://github.com/OpenTTD/OpenTTD/pull/11514 00:38:38 *** Flygon has joined #openttd 00:39:01 <DorpsGek> [OpenTTD/OpenTTD] PeterN approved pull request #11514: Codechange: pass std::string references to OpenBrowser https://github.com/OpenTTD/OpenTTD/pull/11514#pullrequestreview-1754192387 00:44:14 <DorpsGek> [OpenTTD/OpenTTD] zephyris opened issue #11515: [Bug]: Changing interface size can have weird effects on current zoom https://github.com/OpenTTD/OpenTTD/issues/11515 00:45:53 <DorpsGek> [OpenTTD/OpenTTD] PeterN commented on issue #11515: [Bug]: Changing interface size can have weird effects on current zoom https://github.com/OpenTTD/OpenTTD/issues/11515 01:00:53 <DorpsGek> [OpenTTD/OpenTTD] zephyris opened issue #11516: [Bug]: Changing interface size has inconsistent effects on window sizes https://github.com/OpenTTD/OpenTTD/issues/11516 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:02:34 <DorpsGek> [OpenTTD/OpenTTD] rubidium42 merged pull request #11514: Codechange: pass std::string references to OpenBrowser https://github.com/OpenTTD/OpenTTD/pull/11514 01:05:28 <_zephyris> Only if the wind changes direction! 02:15:04 <DorpsGek> [OpenTTD/grfcodec] glx22 opened pull request #28: Add: Install, Pack (windows) and Release workflow https://github.com/OpenTTD/grfcodec/pull/28 02:16:47 <DorpsGek> [OpenTTD/grfcodec] glx22 updated pull request #28: Add: Install, Pack (windows) and Release workflow https://github.com/OpenTTD/grfcodec/pull/28 02:30:14 <DorpsGek> [OpenTTD/OpenTTD] PeterN merged pull request #11511: Fix ab1a4c6c: Crash if the "No Music" set is loaded because there is no current set_index. https://github.com/OpenTTD/OpenTTD/pull/11511 02:42:42 *** Wormnest has quit IRC 03:11:55 *** debdog has joined #openttd 03:15:18 *** D-HUND has quit IRC 05:41:14 *** esselfe has joined #openttd 06:58:06 <andythenorth> https://cdn.discordapp.com/attachments/1008473233844097104/1179315333132197978/image.png?ex=657955fe&is=6566e0fe&hm=1c5a6093fba965030db9bff28330ac135b75397be3a60e51990788be1fda257b& 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> https://cdn.discordapp.com/attachments/1008473233844097104/1179316012471037952/image.png?ex=657956a0&is=6566e1a0&hm=0b1ed4ccebeec315733fe2f874e49726cdbdb0d1b7ae34632839ea3ed0c6e746& 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> https://cdn.discordapp.com/attachments/1008473233844097104/1179332019554103326/ats_20231129_143708_00.png?ex=65796588&is=6566f088&hm=60737010350dc38e0a09136befb095a237ba47b660555fc137ef2d02af407e64& 08:04:25 <_pruple> off to find some newgrf truckstop inspiration 🙂 08:05:41 *** nairda00 has joined #openttd 08:05:41 <nairda00> what game is that 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:20:56 <peter1138> 18 Wheels of Steel 08:21:26 <peter1138> Ivan "Ironman" Stewart's Super Off Road Racing 08:26:44 <_pruple> Doom 08:27:18 <peter1138> https://www.youtube.com/watch?v=Nw_cdqQHGA8 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:02:58 <andythenorth> nairda00: 2048? 09:08:26 *** marchnex has joined #openttd 09:09:25 *** ahyangyi has joined #openttd 09:09:26 <ahyangyi> Why not Road Hog? 09:10:38 *** thelounge34 has quit IRC 09:11:43 *** thelounge34 has joined #openttd 09:14:12 <DorpsGek> [OpenTTD/grfcodec] LordAro commented on pull request #28: Add: Install, Pack (windows) and Release workflow https://github.com/OpenTTD/grfcodec/pull/28#pullrequestreview-1754780484 09:17:54 *** marchnex has quit IRC 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:49 <peter1138[d]> ... 522x678 09:39:49 <peter1138[d]> ... 522x678 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:02 <peter1138> "The it's" 09:47:07 <peter1138> -The, I guess. 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:05 <_zephyris> https://cdn.discordapp.com/attachments/1008473233844097104/1179366918784819250/image.png?ex=65798609&is=65671109&hm=761fa97cb4d0547c9cce8a50c78229242d8a28d6dd123cc031d71ac539acb4e2& 10:23:05 <_zephyris> ? 10:23:22 <_zephyris> I noticed toyland was just using temperate river banks 10:26:24 <LordAro> 👍 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:44 <peter1138> Sharks 10:28:46 <LordAro> though that'd probably just be a couple of pixels 10:33:19 <_zephyris> Toyland needs more shark fins 10:33:57 <peter1138> Loch ness monsters 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:36:56 <_zephyris> This is vanilla 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:09 <_zephyris> Yeah 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]> https://cdn.discordapp.com/attachments/1008473233844097104/1179379247555563580/image.png?ex=65799184&is=65671c84&hm=9c70994e6a62dbd8ee20c1680fdca8aeb5484dbc790c5fb6b27b54d8d33d98db& 11:12:04 <peter1138[d]> OpenTTD: Idle Edition 11:29:48 *** APTX_ has quit IRC 11:29:54 *** APTX has joined #openttd 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:37 <DorpsGek> [OpenTTD/OpenTTD] PeterN opened pull request #11517: Fix #11516: Changing interface scale makes resizeable windows larger but not smaller. https://github.com/OpenTTD/OpenTTD/pull/11517 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:29:50 <LordAro> hmm 13:29:52 <LordAro> is lunch? 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:09 <peter1138> I mean for different zoom levels of the same sprite. 13:45:15 <_zephyris> Not the case for 1x/2x/4x zoom... The NML documentation recommends using diffent yrel by zoom! https://newgrf-specs.tt-wiki.net/wiki/RealSprites#zoom_level 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:50:19 <peter1138> Quite. 13:52:31 <_zephyris> https://cdn.discordapp.com/attachments/1008473233844097104/1179419626959028264/image.png?ex=6579b71f&is=6567421f&hm=82058bc329f8ff16110b15f785db656304c321d55679ce502346a0e922add4ee& 13:52:32 <_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:24 <_zephyris> Yup 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:02:58 <peter1138> Yeah but 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:21 <_pruple> yes, it does 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:07:19 <DorpsGek> [OpenTTD/grfcodec] glx22 updated pull request #28: Add: Install, Pack (windows) and Release workflow https://github.com/OpenTTD/grfcodec/pull/28 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:09:43 <_pruple> https://cdn.discordapp.com/attachments/1008473233844097104/1179423952523755530/Goness_Ridge_Transport_1971-01-18.png?ex=6579bb26&is=65674626&hm=87fc5afb3f3a7d98fb6f374007ffd64f5c17a17a6dfb018a9c426697f412f9d6& 14:10:58 <_pruple> "should be" -124 -2. Oh no. Anyway... 14:11:37 <peter1138> -31 * 4 14:11:39 <peter1138> Yeah. 14:11:49 <peter1138> Because the original baseset was -31 instead of -32. 14:13:28 <_pruple> terrible 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:30 <peter1138> ⁉️ 14:16:45 <peter1138> Actually... ❓ exists... 14:18:38 <_pruple> ❓❓ 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:20:05 <peter1138> But, eh. 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:14 <_pruple> probably 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:48:36 *** nielsm has joined #openttd 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:52:15 <_pruple> no 😛 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 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 16:11:36 <andythenorth> Goes it throw out 1x 16:12:45 <peter1138> So you can't zoom out? 16:33:33 <_zephyris> peter1138: Yeah, just grab the pre-built on github https://github.com/zephyris/opengfx2/releases/tag/v0.4 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:07 <peter1138> Nice. 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:36:57 <peter1138> Usually am. 16:39:57 *** Wormnest has joined #openttd 16:41:49 <peter1138> Nope. 16:42:25 <peter1138> The intermediate offsets are checked on load, but then thrown away. Only the max zoom offsets are used. 16:46:25 <peter1138> But anyway... 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:09 <peter1138> Action 14 it. 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:49:52 <peter1138> (Trickier) 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> https://cdn.discordapp.com/attachments/1008473233844097104/1179465799040249926/image.png?ex=6579e21f&is=65676d1f&hm=2ffb626d832bc999bf534ee3d29c92e773ba10c0732a9fb23ed1e4389667bd7e& 16:56:01 <andythenorth> did cdist change? 16:56:16 <andythenorth> it's no longer routing to specific next hops 16:56:28 <frosch123> https://github.com/OpenTTD/OpenTTD/blob/master/src/rail_cmd.cpp#L2060 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:58:16 <frosch123> https://newgrf-specs.tt-wiki.net/wiki/RealSprites#zoom_level <- the vertical offsets are described here. i am not sure about the horizontal ones 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!? 16:59:22 <_zephyris> I'm confusd 17:00:06 <peter1138> Hmm. 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:17:58 <peter1138> \o/ 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:16 <peter1138> ... what... 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:48:08 <DorpsGek> [OpenTTD/OpenTTD] PeterN opened pull request #11518: Feature: (-tte) Add zoom level buttons to sprite aligner. https://github.com/OpenTTD/OpenTTD/pull/11518 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]> https://cdn.discordapp.com/attachments/1008473233844097104/1179479992489492670/image.png?ex=6579ef57&is=65677a57&hm=c3d6662eee62a23e259b0400d86afe193f756e7c0ebe41623de6b9ba2ca3994c& 17:52:24 <peter1138[d]> Narrowest dropdown list? 17:57:30 <peter1138> Okay, that window could do with being resizable... 18:02:39 <DorpsGek> [OpenTTD/OpenTTD] PeterN updated pull request #11518: Feature: (-tte) Add zoom level buttons to sprite aligner. https://github.com/OpenTTD/OpenTTD/pull/11518 18:09:57 <DorpsGek> [OpenTTD/OpenTTD] glx22 opened pull request #11519: Fix: Nightly build failures for macos and linux https://github.com/OpenTTD/OpenTTD/pull/11519 18:12:07 <DorpsGek> [OpenTTD/OpenTTD] LordAro approved pull request #11519: Fix: Nightly build failures for macos and linux https://github.com/OpenTTD/OpenTTD/pull/11519#pullrequestreview-1755921822 18:20:52 *** blathijs has quit IRC 18:26:34 *** virtualrandomnumber has joined #openttd 18:27:08 <_zephyris> Ooh 18:28:55 *** virtualrandomnumber has quit IRC 18:42:37 *** virtualrandomnumber has joined #openttd 19:07:57 <peter1138> Hmm 19:29:20 *** HerzogDeXtEr has joined #openttd 19:42:52 *** Wolf01 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:00:04 <DorpsGek> [OpenTTD/OpenTTD] ldpl commented on pull request #11489: Feature: Randomize direction of rail vehicle on build based on probability callback. https://github.com/OpenTTD/OpenTTD/pull/11489#issuecomment-1832616156 20:00:07 <DorpsGek> [OpenTTD/OpenTTD] glx22 merged pull request #11519: Fix: Nightly build failures for macos and linux https://github.com/OpenTTD/OpenTTD/pull/11519 20:07:33 *** gelignite has joined #openttd 20:19:04 <truebrain> https://github.blog/changelog/2023-11-29-upcoming-changes-to-repository-insights/ 20:19:04 <truebrain> Enjoy the stats while they last ! 20:21:31 *** gnu_jj has joined #openttd 20:22:29 <LordAro> disappointing 20:22:37 *** virtualrandomnumber has quit IRC 20:24:24 *** Mac[m] has joined #openttd 20:27:26 <truebrain> indeed 20:28:36 <peter1138> Googlifying? 20:29:36 <peter1138> #10623 is quite old for an approved PR ;) 20:29:46 *** gelignite has quit IRC 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:51:39 <talltyler> Thanks 😄 20:52:34 <talltyler> If you haven't seen it yet, I have a milestone for NotDaylength PRs: https://github.com/OpenTTD/OpenTTD/milestone/6 20:53:19 <truebrain> it no loner is only a daylength milestone 20:53:36 <truebrain> MWHAHAHAHAHA 20:53:37 <truebrain> 😄 20:53:41 <talltyler> Fine by me! 😄 20:54:31 <truebrain> I am also rather tempted to add https://github.com/OpenTTD/OpenTTD/pull/10409 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:07 <talltyler> kuhnovic: Can you rebase https://github.com/OpenTTD/OpenTTD/pull/10543 so we can set up a test game, to try this out? If you haven't read above, we'd like to release it in 14.0 sometime in the next few months. 😄 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 21:13:30 *** nielsm has quit IRC 21:13:49 *** gnu_jj has quit IRC 21:19:12 <peter1138> Hmm 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:20:59 <talltyler> https://github.com/OpenTTD/OpenTTD/pull/10541 21:21:00 *** bigyihsuan has joined #openttd 21:21:00 <bigyihsuan> talltyler: boat game 21:21:24 <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:04 <truebrain> ~20% on average 21:31:08 <peter1138> :o 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:34:48 <truebrain> https://cdn.discordapp.com/attachments/1008473233844097104/1179535963458916472/image.png?ex=657a2378&is=6567ae78&hm=dde5f7bce049ca3a80d77c041cf15a4074b9cf99a1bdad9e353920469baa649b& 21:34:48 <truebrain> to show a picture 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:37 <peter1138> Excellent. 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:08 <truebrain> (via bisect approach) 21:37:34 <truebrain> https://cdn.discordapp.com/attachments/1008473233844097104/1179536658060824717/image.png?ex=657a241e&is=6567af1e&hm=60a8937585b22121a1ec1a77d836bba7ce666d8a162eced14088e1fe075c7c8d& 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:10 <truebrain> https://cdn.discordapp.com/attachments/1008473233844097104/1179537815361564793/image.png?ex=657a2531&is=6567b031&hm=c60999526fdfbedb0fb404d29c22f7fcaf0484dde4ce2f5eed3db9d23bcba5ec& 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:16 <peter1138> Yes I know that :) 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:45:41 <truebrain> "he" 21:45:42 <truebrain> 😄 21:46:19 <truebrain> https://cdn.discordapp.com/attachments/1008473233844097104/1179538862138200124/image.png?ex=657a262b&is=6567b12b&hm=6b8e9e2964f7fb414de286a2c2a41acb54cdb11d0a14143eecc32abf94cd95e4& 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:30 <LordAro> the same thought occurred to me 21:53:48 <LordAro> tricky to guarantee the same CPU though 21:53:57 <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:05 <LordAro> aye 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:04:50 *** keikoz has joined #openttd 22:06:21 <peter1138> Well. 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]> https://cdn.discordapp.com/attachments/1008473233844097104/1179544352079499445/image.png?ex=657a2b48&is=6567b648&hm=cb16034c81480a04c937e26a2efe982967d7aee54122fe8b2875f4048cc55bad& 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 22:36:57 *** tokai has joined #openttd 22:36:57 *** ChanServ sets mode: +v tokai 22:40:13 <DorpsGek> [OpenTTD/OpenTTD] PeterN merged pull request #11489: Feature: Randomize direction of rail vehicle on build based on probability callback. https://github.com/OpenTTD/OpenTTD/pull/11489 22:43:59 *** tokai|noir has quit IRC 22:47:47 <peter1138> Hmm, dunno how to add a section on the tt-wiki. 23:10:59 *** Wolf01 has quit IRC 23:30:39 <_zephyris> https://cdn.discordapp.com/attachments/1008473233844097104/1179565116556071012/image.png?ex=657a3e9f&is=6567c99f&hm=64bcf5c7c518be71d578dd2a11fa67b67912c97848b894ab86f852b09c901ecb& 23:30:39 <_zephyris> ? 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:51:55 <peter1138> Hmm. 23:52:10 <peter1138> 41888 -> 2302 slots, 460768 -> 26480 bytes 23:52:32 <peter1138> Hmm, what does that PR do... 23:53:02 <peter1138> 2 -> 25 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