Times are UTC Toggle Colours
00:02:52 <peter1138> Silly clangd adding includes all over the place :/ 00:04:11 <DorpsGek> [OpenTTD/OpenTTD] 2TallTyler approved pull request #12167: Fix: Make link graph node borders scale with GUI https://github.com/OpenTTD/OpenTTD/pull/12167#pullrequestreview-1899114803 00:04:29 <talltyler> Oh LordAro already approved 00:04:37 <DorpsGek> [OpenTTD/OpenTTD] 2TallTyler merged pull request #12167: Fix: Make link graph node borders scale with GUI https://github.com/OpenTTD/OpenTTD/pull/12167 00:04:41 <peter1138> Damn it, another forced-death-on-exit map 😦 00:08:16 <_glx_> peter1138: that's why I rename my folder when testing 00:10:08 <LordAro> talltyler: just as well you did, i've just spent 4 hours in a pub 00:10:19 <LordAro> #responsible 00:13:24 <peter1138> _glx_: I did, and then I was just about to rename it back, but removed the wrong one. 00:13:44 <_glx_> oups 00:14:01 <_glx_> no unerase feature ? 00:14:12 <_zephyris> LordAro: Someone has to test the beer! 00:15:01 <peter1138> Never mind, wasn't anything too important in it. 00:19:31 <_zephyris> Ship pathfinder blog post looks good for tomorrow 00:19:47 <_zephyris> Does it need a Steam image? 00:20:42 <peter1138> Hmm, github API timeouts :S 00:28:55 <DorpsGek> [OpenTTD/OpenTTD] jcteotonio updated pull request #12108: Add: Portuguese Escudo currency https://github.com/OpenTTD/OpenTTD/pull/12108 00:33:36 <peter1138> Starting OpenTTD with "xinit openttd" is pretty hardcore. 00:33:47 <DorpsGek> [OpenTTD/OpenTTD] jcteotonio updated pull request #12108: Add: Portuguese Escudo currency https://github.com/OpenTTD/OpenTTD/pull/12108 00:35:00 <DorpsGek> [OpenTTD/OpenTTD] jcteotonio updated pull request #12108: Add: Portuguese Escudo currency https://github.com/OpenTTD/OpenTTD/pull/12108 00:40:12 <ajmiles> I've just realised the second plane in the main menu is the plane's shadow, but drawn as if its a normal plane. Duh 02:11:23 <talltyler> `SHADE_LIGHTEREST` 😄 02:13:13 <talltyler> https://cdn.discordapp.com/attachments/1008473233844097104/1210771383194230894/IMG_6861.png?ex=65ebc5b8&is=65d950b8&hm=0b8f72b6699d2a8cf6ade7d2598d5bada56f177a60f0acafbfe4398a52a699a5& 02:13:18 <talltyler> 😛 02:43:21 <_rei4122> xarick: Hmm... It does not occur here. 02:45:11 *** herms has quit IRC 02:48:10 *** geli has joined #openttd 02:50:36 *** Wormnest has quit IRC 02:55:30 *** gelignite has quit IRC 03:30:22 <ajmiles> Does the 8-bit anim buffer serve any purpose beyond being an optimisation? I wrote the GPU blitter initially with a 4 channel `dst` and a 1 channel `anim` buffer, but having colour encoded only the anim buffer and 0 in the dst buffer means I can't alpha blend onto the colour already laid down (as it isn't there) 03:31:09 <ajmiles> I'm wondering whether I should just get rid of the anim buffer and just deal with 32-bit dst and always convert/remap `m` to a full colour at every opportunity. 03:32:50 <ajmiles> If its only purpose was to make a CPU blitter faster, and I don't care about that, then maybe I should just rid of it. 03:55:02 *** D-HUND has joined #openttd 03:58:41 *** debdog has quit IRC 04:00:57 *** gnu_jj_ has joined #openttd 04:04:20 *** gnu_jj has quit IRC 04:16:10 *** Leopold___ has joined #openttd 04:21:16 *** Leopold_ has quit IRC 04:56:18 <DorpsGek> [OpenTTD/OpenTTD] AnthonyGithubCorner updated pull request #12164: Add: Highlight in white all pieces of company owned infrastructure in the viewport https://github.com/OpenTTD/OpenTTD/pull/12164 05:36:47 *** keikoz has joined #openttd 05:44:11 <DorpsGek> [OpenTTD/OpenTTD] AnthonyGithubCorner updated pull request #12164: Add: Highlight in white all pieces of company owned infrastructure in the viewport https://github.com/OpenTTD/OpenTTD/pull/12164 05:55:39 *** geli has quit IRC 06:02:00 *** Leopold has joined #openttd 06:02:10 *** Leopold___ has quit IRC 06:05:21 <DorpsGek> [OpenTTD/OpenTTD] AnthonyGithubCorner commented on pull request #12164: Add: Highlight in white all pieces of company owned infrastructure in the viewport https://github.com/OpenTTD/OpenTTD/pull/12164#pullrequestreview-1899224585 06:07:37 *** Leopold has quit IRC 06:08:44 *** Leopold has joined #openttd 06:10:24 *** Flygon has joined #openttd 06:18:41 *** keikoz has quit IRC 06:46:18 *** Leopold has quit IRC 06:46:22 *** Leopold has joined #openttd 07:05:47 <peter1138> Brrr, -1°C 07:10:44 *** HerzogDeXtEr has joined #openttd 07:23:17 *** keikoz has joined #openttd 07:33:14 <ajmiles> I got scrolling working 99%. I had to implement the ScrollBuffer part of the blitter, but there's still something not quite right. When I scroll near industries, it's like there's a little portal around them that scrolls on a delay, and I'm not sure what that is yet, hopefully I can figure that out after sleep. But definitely improving. Having a mouse cursor even if it's streaky on the screen 07:33:14 <ajmiles> helps a lot. https://youtu.be/gF8Z3anS2Kg?si=HZXRk9BNx-YdSrqt 07:49:04 <reldred> https://cdn.discordapp.com/attachments/1008473233844097104/1210855903621025832/image.png?ex=65ec1470&is=65d99f70&hm=93665eafd71e346395b37b973f71cb7642e7598748c3d7fbbb1663353a5e25a9& 07:49:04 <reldred> Rectangular, like 3x1 aspect ratio? It's probably something to do with the industry viewport 07:50:00 <reldred> Oooh no, that's a very different shape 08:04:55 <johnfranklin> https://cdn.discordapp.com/attachments/1008473233844097104/1210859894677307402/image.png?ex=65ec1827&is=65d9a327&hm=1638981b1c4045ca36c647c7de2aa0a1aae781b1adbc00584f8b72e49825addc& 08:10:11 *** zero2474 has joined #openttd 08:10:11 <zero2474> Newbie question: If I make some changes in only one source file, do I have to build the whole project or is there a way to just patch the changes to already built project in the build directory ? 08:12:38 *** nielsm has joined #openttd 08:15:44 *** Extrems` has joined #openttd 08:16:32 *** dwfreed_ has joined #openttd 08:18:41 *** Extrems has quit IRC 08:18:41 *** esselfe has quit IRC 08:18:41 *** dwfreed has quit IRC 08:18:41 *** Extrems` is now known as Extrems 08:20:04 <reldred> If you're using something like VS Code that's pretty much exactly what it does. 08:20:32 <reldred> Don't know about other build systems 08:20:46 <reldred> Try it without doing a make clean and see what happens. 08:56:25 <andythenorth> coffee time 09:03:49 <andythenorth> hmm this "faster" is not faster enough 09:04:01 <reldred> more fasterer 09:04:33 <andythenorth> ok STORE_TEMP is expensive in nml 09:05:12 <merni> zero2474: If you're building on Linux using cmake, once you build the first time later builds will just compile the changes 09:05:15 <andythenorth> I was diligently initialising 20 registers to a safe null value before writing to 20 **or fewer** of them with actual values 09:05:28 <andythenorth> but per variant, that's really expensive in nml processing time 09:05:36 <merni> Unless you change a lang file or some other things that trigger a full recompile 09:05:55 <andythenorth> hmm 8MB of nml removed, and 1s of compile time 09:16:07 <kuhnovic> Do I need to do anything for the blog post, or is it good to go? 09:19:37 <truebrain> Update the time plz 🙂 09:20:14 <truebrain> Owh, and we need to fix you an image for posting on Steam / socials 09:20:53 <truebrain> Maybe you can look _zephyris in the eyes while blinking pretty 09:25:21 <DorpsGek> [OpenTTD/team] michaelsmassey opened issue #522: [hi_IN] Translator access request https://github.com/OpenTTD/team/issues/522 09:27:28 *** Wolf01 has joined #openttd 09:28:27 <_zephyris> Hmm, maybe a ship maze? 09:28:46 <_zephyris> I know it's not actually very beneficial for that case, but visually good. 09:29:24 <kuhnovic> The only case where the ship pathfinder really shines is larges maps, but that doesn't make for a great screenshot 09:29:44 <kuhnovic> A ship maze with lots of ships would be nice 09:36:21 <andythenorth> ok Horse compile averaging 27s not 34s now 09:36:27 <andythenorth> that stupid palette check though 😛 09:36:48 <andythenorth> https://cdn.discordapp.com/attachments/1008473233844097104/1210883016713572382/image.png?ex=65ec2db0&is=65d9b8b0&hm=8883177a36643f72b22e73c64b2da6bab966b604446f7b8414cfac9900ed3042& 09:37:02 <andythenorth> 1.4s of complete waste that I can't prevent nmlc doing 09:37:51 <zero2474> merni: not the lang files, I'm trying to export the vehicle's timetable. 09:37:51 <zero2474> But every test build was taking around ~24mins. 09:38:08 <merni> That's way too long 09:38:41 <zero2474> im doing cmake build for RelWithDebInfo. 09:39:06 <merni> Hm, yeah... release builds are slower 09:39:12 <zero2474> oh wait is debug or release more than enough ! 09:39:14 <merni> Try a debug build 09:39:44 <merni> debug builds are slow but fine for testing 09:39:53 <zero2474> ah I see I didn't explored the build options lol. 09:40:04 <zero2474> Thanks 09:43:45 <andythenorth> ach can't just drop the palette check for nmlc 09:44:06 <andythenorth> it requires a palette for action 14, and it infers it from the spritesheets 09:44:44 <andythenorth> we know that the palette situation is generally a bit stupid 😛 09:44:49 <andythenorth> maybe we can do something better here 09:45:44 <andythenorth> https://github.com/OpenTTD/nml/blob/9b8a23f3e8bc7d786c47f8d62436d47044805ab0/nml/ast/grf.py#L39 09:45:55 <andythenorth> 'if applicable' 09:47:39 <andythenorth> palette can be defined by nfo author in action 14 (as expected) https://newgrf-specs.tt-wiki.net/wiki/Action14#GRF_palette_.28.22INFO.22_-.3E_.22PALS.22.29 09:47:52 <andythenorth> but I can't see an equivalent nml action 14 prop https://newgrf-specs.tt-wiki.net/wiki/NML:GRF 09:49:00 <andythenorth> yeah it's forced https://github.com/OpenTTD/nml/blob/9b8a23f3e8bc7d786c47f8d62436d47044805ab0/nml/ast/grf.py#L185 09:49:08 <andythenorth> not available to nml authors 09:50:52 <reldred> you can't be trusted with that much power 09:51:20 <andythenorth> url https://github.com/OpenTTD/nml/blob/9b8a23f3e8bc7d786c47f8d62436d47044805ab0/nml/main.py#L395 09:53:44 <andythenorth> my grfs set that option flag as "DEFAULT" 09:54:16 <andythenorth> which nml treats as DOS palette 09:54:37 <truebrain> E_TOO_MANY_LINKS 09:55:20 <andythenorth> they're not even nice links 09:55:41 <andythenorth> well have one more, nmlc has an internal option to not validate sprites https://github.com/OpenTTD/nml/blob/9b8a23f3e8bc7d786c47f8d62436d47044805ab0/nml/main.py#L495 09:55:56 <andythenorth> maybe I can expose that to an arg 09:57:41 <andythenorth> the logic in the following lines hurts my small brain though 09:57:57 <_zephyris> https://cdn.discordapp.com/attachments/1008473233844097104/1210888336688816188/ships-steam.png?ex=65ec32a4&is=65d9bda4&hm=92aef6c6e1d723356c5c20fe6e58dd56c0c02f165ce01998920aeeb9bde85600& 09:57:57 <_zephyris> https://cdn.discordapp.com/attachments/1008473233844097104/1210888336961576970/ships-steam.zip?ex=65ec32a4&is=65d9bda4&hm=3ccbbd16c54a45c9ac56469d3b6464ea55ad9d63ac607cffb58ade7104a9e41e& 09:57:57 <_zephyris> Silly but suitable? 09:58:41 <kuhnovic> Silly and I love it! 09:58:59 <kuhnovic> Maybe a few trees? 09:59:00 <andythenorth> 🚢 10:02:20 <andythenorth> what does `skip_sprite_processing &= outputfile.skip_sprite_checks()` do? 10:02:33 <_zephyris> https://cdn.discordapp.com/attachments/1008473233844097104/1210889497248669726/ships-steam.zip?ex=65ec33b9&is=65d9beb9&hm=4cb2afcea3756124f5b693b617b5ad749203ec1c30afa56b318e7b83fffbac32& 10:02:33 <_zephyris> https://cdn.discordapp.com/attachments/1008473233844097104/1210889497651187712/ships-steam.png?ex=65ec33b9&is=65d9beb9&hm=eea3e96f6c11c10145c419e57eb69dd08b018bf0a6618b10ce94f4e51b69508c& 10:03:03 <andythenorth> is that a bool incremental assignment? 10:04:48 <truebrain> it does `skip_sprite_processing = skip_sprite_processing & outputfile.skip_sprite_checks()` 10:04:59 <truebrain> now if we make a truth-table, we know what it does 10:05:22 <truebrain> ```true = true & true 10:05:22 <truebrain> true = true & false 10:05:22 <truebrain> true = false & true 10:05:22 <truebrain> false = false & false 10:06:03 <andythenorth> thanks 10:06:46 <kuhnovic> _zephyris: Looks great! 10:07:23 <DorpsGek> [OpenTTD/website] Kuhnovic updated pull request #296: Add: post about the new ship pathfinder https://github.com/OpenTTD/website/pull/296 10:17:48 <DorpsGek> [OpenTTD/website] TrueBrain approved pull request #296: Add: post about the new ship pathfinder https://github.com/OpenTTD/website/pull/296#pullrequestreview-1899395855 10:17:52 <truebrain> don't forget to attach it to the news post 🙂 10:24:14 <DorpsGek> [OpenTTD/nml] andythenorth opened pull request #322: Change: add forcibly_skip_sprite_processing arg option https://github.com/OpenTTD/nml/pull/322 10:24:32 <xarick> g'day 10:24:54 <kuhnovic> truebrain: How do I do that? Can I even do that :P? 10:24:55 <DorpsGek> [OpenTTD/nml] andythenorth commented on pull request #254: Change: skip realsprite palette validation step iff output is nfo AND… https://github.com/OpenTTD/nml/pull/254#issuecomment-1962321396 10:24:59 <DorpsGek> [OpenTTD/nml] andythenorth closed pull request #254: Change: skip realsprite palette validation step iff output is nfo AND… https://github.com/OpenTTD/nml/pull/254 10:25:12 <truebrain> pretty sure you are capable of dragging images in a reply and posting that, yes 10:26:21 <michi_cc[d]> Did we decide on the order for the remaining posts yet? And will Tyler remeber the daylength one? 🙂 10:26:36 <kuhnovic> You overestimate me TrueBrain 😉 10:26:42 <truebrain> talltyler: keeps dodging that question 😛 10:26:42 <kuhnovic> I'll add it 10:27:30 <michi_cc[d]> Any further comments on my sausage post? I'd like to make an imgainary checkmark on that one 🙂 10:28:20 <truebrain> won't be posted for at least another 2 weeks 😛 10:30:02 <DorpsGek> [OpenTTD/website] Kuhnovic commented on pull request #296: Add: post about the new ship pathfinder https://github.com/OpenTTD/website/pull/296#issuecomment-1962322350 10:30:06 <truebrain> YOU DID IT! 10:30:35 <kuhnovic> Not bad after 3 hours of sleep 😆 10:30:50 <truebrain> must have been very hard, drag and dropping those files 10:31:54 <truebrain> guess we might as well publish the post while we are fiddling with it 10:32:14 <DorpsGek> [OpenTTD/website] TrueBrain merged pull request #296: Add: post about the new ship pathfinder https://github.com/OpenTTD/website/pull/296 10:34:39 <kuhnovic> It was a marathon, but I'm glad I did it 10:36:56 <truebrain> bah; can't add an image after posting on Discord 10:38:20 <andythenorth> hoping someone takes pity on my nml patch 😛 10:38:34 <truebrain> haha @ _zephyris , nice 🙂 10:38:36 <michi_cc[d]> Made a reddit post. 10:38:58 <_zephyris> Hype train! 10:39:29 <truebrain> still can't believe you cannot add/modify an image after you posted something 10:39:31 <truebrain> that is silly 10:39:34 <truebrain> you can alter the whole text, but not the image 10:42:27 <kuhnovic> Oh well, now I got two announcements 🎉 11:28:03 *** herms has joined #openttd 11:32:12 <xarick> merge 11862 so that my AI becomes happy 🙂 11:33:28 <xarick> oh, 11862 is the issue, I mean 12156 11:37:00 <kuhnovic> Needs a developer review first 11:37:21 <kuhnovic> I only pretended to have that authority by commenting 😛 11:55:08 <DorpsGek> [OpenTTD/nml] glx22 commented on pull request #322: Change: add forcibly_skip_sprite_processing arg option https://github.com/OpenTTD/nml/pull/322#pullrequestreview-1899406025 11:56:09 <DorpsGek> [OpenTTD/team] glx22 commented on issue #522: [hi_IN] Translator access request https://github.com/OpenTTD/team/issues/522 12:03:41 <xarick> seriously, what is the point of this AI... https://bananas.openttd.org/package/ai/5349474e 12:04:14 <xarick> 😦 12:05:14 <xarick> https://github.com/wspxh/SignIndustries/blob/master/main.nut very sad 😐 12:11:10 <xarick> it's not even hidden from the random pool choice of AIs 12:13:26 <peter1138> What does it do.... 12:13:48 <xarick> places signs on every industry, that's all 12:14:08 <xarick> and removes when they close 12:14:52 <peter1138> xarick: Um 12:15:11 <peter1138> I suggest not downloading it 🙂 12:16:30 <xarick> there should be a rule or a scanning done on these scripts for what they can do 12:17:05 <peter1138> Mod review team? 12:17:30 <xarick> if AIVehicle.BuildVehicle is not present... tag it as "unfit" or whatever, I dunno, it's just ... me 12:17:30 <reldred> *mod*eration 12:17:53 <peter1138> Modification moderation 12:17:59 <peter1138> Modmod 12:18:36 <peter1138> talltyler: Glad you read it 🙂 12:19:00 <xarick> maybe automated tags 12:19:08 <xarick> showing what it can do, on a quick glance 12:22:07 <xarick> nevermind, just venting 12:22:11 <DorpsGek> [OpenTTD/OpenTTD] Kuhnovic opened pull request #12170: Fix #8022: Ship automatic service causes them to be stuck in a loop https://github.com/OpenTTD/OpenTTD/pull/12170 12:22:22 <kuhnovic> Lets make xarick happy 12:24:16 <xarick> nice! 12:24:28 <DorpsGek> [OpenTTD/OpenTTD] Kuhnovic commented on pull request #12170: Fix #8022: Ship automatic service causes them to be stuck in a loop https://github.com/OpenTTD/OpenTTD/pull/12170#pullrequestreview-1899420684 12:25:58 <xarick> https://bananas.openttd.org/package/ai 2024 is seeing some AI activity 12:27:26 <xarick> choochoo made a fix to something but didn't fix the ERR_UNKNOWN when building road connected to a bridge 12:28:01 <xarick> or maybe the fix needs to come from the OpenTTD side 12:28:38 *** D-HUND is now known as debdog 12:31:29 <xarick> trying to pick from a list of 500 "smiles" one that reflects my mood... 12:32:33 <xarick> yeah maybe that 12:37:08 *** gelignite has joined #openttd 12:46:28 <_glx_> truebrain: Middle ones feels very wrong 12:46:59 <truebrain> Owh, yeah, I did | 12:47:01 <peter1138> TrueBrain wrote it for |= not &= 🙂 12:47:01 <truebrain> Hihi 12:47:15 <truebrain> Clearly wasn't awake 12:47:40 <peter1138> You were just testing us. 12:47:50 <truebrain> Yes 13:04:46 <talltyler> peter1138: I'll even review it later, but last night was not a good critical-thinking hour 🙂 13:18:04 <peter1138> That is related to vague questions I asked on here a few weeks ago about lightness/brightness/shades 😄 13:18:17 <xarick> looking at 12170 13:19:16 <xarick> the problem of ship going back and forth is due to using non-pathfinder distances combined with pathfinder distances 13:19:42 <xarick> distance square 13:21:26 <xarick> it's still a birds view type of distance while pathfinder distance is the one that has the ultimate say 13:47:47 <DorpsGek> [OpenTTD/OpenTTD] 2TallTyler commented on pull request #12169: Codechange: Use functions to access colour gradients and replace magic numbers. https://github.com/OpenTTD/OpenTTD/pull/12169#pullrequestreview-1899436932 13:48:58 <DorpsGek> [OpenTTD/OpenTTD] PeterN commented on pull request #12169: Codechange: Use functions to access colour gradients and replace magic numbers. https://github.com/OpenTTD/OpenTTD/pull/12169#pullrequestreview-1899438731 13:50:30 <DorpsGek> [OpenTTD/OpenTTD] 2TallTyler commented on pull request #12170: Fix #8022: Ship automatic service causes them to be stuck in a loop https://github.com/OpenTTD/OpenTTD/pull/12170#pullrequestreview-1899438816 13:50:41 <peter1138> I was looking at that thinking... how would a static_cast here work... then I realised i was thinking of static_assert, haha. 13:50:59 <DorpsGek> [OpenTTD/OpenTTD] 2TallTyler commented on pull request #12169: Codechange: Use functions to access colour gradients and replace magic numbers. https://github.com/OpenTTD/OpenTTD/pull/12169#pullrequestreview-1899438943 13:53:08 <talltyler> Is C++ up to four different meanings for the word `static` depending on where it's used? 🙂 13:53:35 <peter1138> Only 4? 13:53:43 <talltyler> Only four that I know of 😛 13:54:12 <peter1138> Also `& 0xF` is a bit less meaningful than `% COLOUR_END` 13:56:30 <frosch123> oh dear... i received my public transport ticket id card: it features my name, but the photo of someone else :p 13:56:53 <DorpsGek> [OpenTTD/OpenTTD] Fefer-Ivan updated pull request #12163: Add: Basic autocompletion on tab for console commands https://github.com/OpenTTD/OpenTTD/pull/12163 13:57:44 <peter1138> talltyler: also I'm not really show how/if those shade values should be documented. 13:58:02 <peter1138> `SHADE_NORMAL, ///< Normal shade` is kinda redundant. 13:58:59 <peter1138> I guess it should be, for consistency. 13:59:24 <peter1138> Huh, COLOUR_ is not documented either. Hmm. 14:00:07 <truebrain> frosch123: Eeeeuuuuhhhh ... scary 14:00:39 <truebrain> Red: red 14:00:43 <truebrain> Blue: blue 14:00:45 <truebrain> 😄 14:01:17 <talltyler> Make a poem! 14:01:17 <talltyler> `Red: The colour of roses` 14:01:17 <talltyler> `Blue: The colour of violets` 14:01:19 <peter1138> Quite. 14:01:34 <peter1138> COLOUR_PURPLE, ///< Pikkabird. 14:01:41 <talltyler> Heheh 14:02:15 <talltyler> `COLOUR_ORANGE, ///< Like COLOUR_YELLOW, but it hurts your eyes` 14:02:21 <talltyler> Maybe that's just me 14:02:31 <peter1138> > Not actually orange. 14:02:42 <DorpsGek> [OpenTTD/OpenTTD] glx22 commented on pull request #12163: Add: Basic autocompletion on tab for console commands https://github.com/OpenTTD/OpenTTD/pull/12163#pullrequestreview-1899484067 14:02:55 <truebrain> `COLOUR_RED, ///< The colour as perceived by human eyes at around 700nm` 14:03:38 <talltyler> Documentation by Skynet, I like it 14:04:44 <truebrain> The difference between a dogmatic approach to documentation and a pragmatic approach to documentation; some things really do not need further explanation 🙂 14:05:23 <talltyler> Oh, and I am working on my timekeeping blog post 🙂 14:05:29 <truebrain> \o/ 14:05:46 <talltyler> Although next week is social integration according to the teaser at the end of today's post, so I have some time 🙂 14:05:50 <truebrain> so what will be the order ... social integration is next .. what did you want after michi_cc[d] ?I forgot 🙂 14:05:57 <truebrain> talltyler: but you keep saying that 😛 14:06:27 <DorpsGek> [OpenTTD/OpenTTD] jimmy-sketch opened issue #12171: [Bug]: trees and builds became transparant https://github.com/OpenTTD/OpenTTD/issues/12171 14:06:34 <talltyler> I made it possible to slow down or pause time, I have every right to apply that to real life too! 😛 14:06:38 *** Leopold has quit IRC 14:06:40 <peter1138> Uh oh 14:07:13 *** Leopold has joined #openttd 14:07:20 <DorpsGek> [OpenTTD/OpenTTD] PeterN commented on issue #12171: [Bug]: trees and builds became transparant https://github.com/OpenTTD/OpenTTD/issues/12171 14:07:29 <DorpsGek> [OpenTTD/OpenTTD] 2TallTyler commented on issue #12171: [Bug]: trees and builds became transparant https://github.com/OpenTTD/OpenTTD/issues/12171 14:07:30 <truebrain> haha, I was about to suggest the same 😛 14:07:37 <talltyler> Too slow by seconds 14:09:08 <talltyler> Anyway, truebrain asked me to put some information about time in the Help & Manuals button... what should go in there? Why does that get bundled with the game instead of being on the Wiki like other game info? 14:09:44 <talltyler> And would it be better as an expanded helptext on the Timekeeping Units setting? 14:10:28 <truebrain> pretty sure I was just revoicing a mention of someone else, but .. 😛 14:11:24 <peter1138> https://cdn.discordapp.com/attachments/1008473233844097104/1210952120111603752/image.png?ex=65ec6e0b&is=65d9f90b&hm=c0fda9b47b37b4e517122af5ff52aac30d5b7129fd638acd11e368f61aa3f3b6& 14:11:24 <peter1138> Well, I don't think that's my PR failing the annotations :S 14:11:38 <truebrain> just retry 😛 14:11:50 <truebrain> sounds like github is just having a bit of issues 🙂 14:12:41 <truebrain> talltyler: I don't think you can fit a good detailed explanation in the helptext 😛 14:13:09 <truebrain> but we do need to document somewhere what is influenced and what is not 14:13:19 <truebrain> as people will try to figure it out on their own, and will document it wrongly 14:13:26 <truebrain> so for all I care, you make a wiki page detailing how it works 14:13:34 <peter1138> I think this end boss is too hard for me 😦 14:14:20 <truebrain> did you try the "re-run jobs" button? Didn't that fix it? 14:15:40 <truebrain> it is a really odd warning; one that should really be temporary 14:16:04 <peter1138> Should be but it was happening last night too. 14:16:24 <peter1138> Re-running now 🙂 14:16:37 <truebrain> seems you did a re-run of only the failed runs yesterday? 14:16:52 <truebrain> that is not going to fix anything 14:17:00 <truebrain> as the warning is in a run that succeeded 14:17:03 <truebrain> so you need to rerun the full set 14:17:17 <truebrain> (the issue with warnings .. they are not failures) 14:17:32 <peter1138> Oh, I did the wrong rerun just now, yes. 14:17:42 <truebrain> owh, I say yesterday, but that is in US time I see 14:17:49 <truebrain> hmm, not even that 14:17:53 <truebrain> the timestamps on GitHub are weird 14:17:56 <peter1138> Yesterday I did a rerun of one of the successful-but-failed tasks, but not the other one, so it wouldn't've updated. 14:18:35 <truebrain> ah, no, times do make sense, just with reruns it gets a bit odd where to look for the actual time, lol 14:18:56 <peter1138> 🙂 14:19:15 <truebrain> So yeah, a "re-run all" should fix that failure 🙂 14:19:29 <truebrain> bit wasteful in CPU-terms, but ... warnings 😦 14:24:05 <kuhnovic> xarick: That's not the problem. The problem is that the depot is in range when doing the initial search. The ship then plans a path to the depot, enters a tile from where the depot is no longer in range. This would happen with true distances as well. After my changes the ship picks a depot and doesn't search for a new one as long as that depot exists. 14:24:11 <truebrain> michi_cc[d]: so I guess we order it like: social -> daylength -> survey -> sausage? Which means talltyler has 2 more weeks to get the blog done and proof-read. Is that doable, you think? 14:25:19 <truebrain> then a weekend nothing, to go into a full release on a monday, I guess 14:30:43 <xarick> I don't think it would happen with true distances (aka low level pathfinder costs), because it has more information of ship's current position like direction, tile, trackdirs, while distancesquare ignores any of that. 14:31:30 <xarick> if it found a path the first time, then it is already accounting for all possible ship movements to the next tiles 14:31:53 <xarick> so next day, it would still keep on finding the same path 14:40:09 <_glx_> not if it's at the limit 14:42:27 <_glx_> firefox has hard time to open the log for #12163 14:44:04 <xarick> if the cost goes past the limit the first time it is called, then there is no path found, but if the cost is within the limit, then I am like 95% sure it will stick to that path in the next days. Costs can only decrease from that point on. 14:44:35 <_glx_> but the limit is always in distance, not cost 14:47:34 <xarick> what distance are you referring to? The distance is the max pathfinder cost. 14:50:46 <michi_cc[d]> truebrain: Sounds good to me at least 🙂 14:50:50 <truebrain> _glx_: lol, yes, many errors 😛 14:51:15 <_glx_> dunno I still can't see them 14:51:26 <michi_cc[d]> You could switch daylength and survey if needed. Daylength is probably kinda the "big" feature. 14:51:53 <truebrain> I wanted to do it last, for that reason 😛 14:52:48 <truebrain> _glx_: seeing them doesn't really help. But of issues with all kinds of various stuff related to types not found, redeclared, etc etc 14:53:15 <truebrain> `‘underlying_type’ is not a member of ‘std’`, `unused parameter ‘m1’ [-Wunused-parameter]`, etc etc 14:53:27 <michi_cc[d]> Well, I'm not sad or angry if my sausage post is moved around. My think was just to not interrupt the feature diaries with some random non-feature one (that isn't really specific to OTTD 14). 14:53:57 <truebrain> I get that reasoning 14:54:17 <truebrain> guess it will depend on what is done next week, when the social is being posted 😛 14:54:33 <truebrain> _glx_: there is no stdafx.h include in the new cpp file 14:54:34 <talltyler> I wonder if we could do the sausage post on the 20th anniversary of OpenTTD? 14:54:36 <truebrain> that is where things go wrong 🙂 14:54:58 <_glx_> yeah, but strange only dedicated build is affected 🙂 14:55:04 <truebrain> talltyler: Rb suggested to do the survey post on that date 14:55:16 <truebrain> _glx_: dedicated runs without PCH 14:55:24 <truebrain> (to ensure we can still build without PCH) 14:55:25 <_glx_> oh true 14:55:56 <truebrain> talltyler: / michi_cc[d] : honestly, I don't think our readers care about any order of posts, neither what date it happens on 🙂 So it is mostly for us, what we like / enjoy 🙂 14:56:16 <xarick> using distancesquare from current ship position to depot as a max pathfinder cost is the problem. It is telling the pathfinder to search a path to the provided depot destination which is in range from a bird's eye perspective 14:56:26 <truebrain> _glx_: related, the header file is not added to the CMakeLists 🙂 14:56:39 <DorpsGek> [OpenTTD/OpenTTD] glx22 commented on pull request #12163: Add: Basic autocompletion on tab for console commands https://github.com/OpenTTD/OpenTTD/pull/12163#pullrequestreview-1899510134 14:57:55 <DorpsGek> [OpenTTD/OpenTTD] glx22 commented on pull request #12163: Add: Basic autocompletion on tab for console commands https://github.com/OpenTTD/OpenTTD/pull/12163#pullrequestreview-1899510292 15:01:50 <kuhnovic> xarick: That would only work if the fincClosestDepot function would actually return the entire path to the depot. Right now finding the closest depot and finding the path to the depot are two separate things. As long as you have that then there's a risk of the ship "losing sight" of the depot. 15:02:36 <kuhnovic> But IMO it makes much more sense to remember what depot you are heading for once you have found it 15:03:19 <xarick> that may not work if the terrain changes meanwhile 15:03:51 <_glx_> doing PF run just to find an hypothetical auto service depot seems too much 15:04:43 <xarick> automatic service at depot seems to be done this way for all vehicle types 15:04:59 <_glx_> but they are not in free space 15:05:13 <kuhnovic> _glx_: It wouldn't be an issue if the PF was fast enough 15:05:32 <xarick> it's fast, it's under a limit 15:05:40 <xarick> the max penalty cost 15:06:25 <xarick> ~20 tiles i think 15:06:33 <xarick> or used to be 20 tiles 15:06:47 <_glx_> 20 tiles in water is a lot of possible paths 15:07:25 <kuhnovic> Ships also check for service every economy day, which roughly amounts to once for each tile for typical ship speeds. Seems excessive to me. 15:07:52 <xarick> that's how automatic service works 🙂 15:08:50 <xarick> if you check the other vehicle types, it does the same 15:09:07 <_glx_> yes but their paths are more limited 15:09:20 <kuhnovic> The regular low level PF is to slow for this at this point. I have a patch with a BFS search and some tricks to avoid checking which trackdirs are available, which is relatively heavy when doing it for lots of tiles. It is a lot faster, but needs further testing. 15:10:14 <_glx_> every new water tile opens 3 new possible ways 15:10:26 <_glx_> it grows very fast 15:10:47 <kuhnovic> xarick: This is something I do need to look at a bit closer. That might be a problem for #12170 15:11:35 <_glx_> and it's the reason why buoys were needed, the number of nodes can go very high very quick 15:11:45 <xarick> i don't think it's slow at such low limits, such as ~20 tiles equivalent of costs it doesn't even need to use the high level pathfinder, too short of a distance, it would use the low level pathfinder 15:12:11 <kuhnovic> _glx_: Yup, but you can check at the tile level instead of exit dir level. A tile can only have one piece of water, not more. That's actually one of the reasons that water regions are possible. 15:12:41 <_glx_> final PF cost might be small, but the number of paths to test and discard can be huge 15:13:35 <kuhnovic> My BFS search is tile based, so only 25% of what yapf would use. 15:14:04 <_glx_> with a specific implementation yes, I'm talking general low level 15:14:30 <kuhnovic> Yes, many symmetric paths. It grows exponentially 15:16:06 *** nielsm has quit IRC 15:17:51 <xarick> https://cdn.discordapp.com/attachments/1008473233844097104/1210968843069956156/image.png?ex=65ec7d9e&is=65da089e&hm=6f69eec684ecedfafbb485da719bca2e2a731bf96b7aaf3cf05798e89322c5f7& 15:17:51 <xarick> 20 tiles worth of distance: 15:17:58 <xarick> are you saying this is slow? 15:18:07 <_glx_> on water it is 15:18:13 <xarick> 😐 15:19:26 <_glx_> especially if it's done very often 15:19:46 <kuhnovic> _glx_: Just to make sure we're talking about the same thing here: you don't have to do a PF run for each depot. A* without heuristic can be used to expand until a depot is found, or bail out if there are no more nodes within a certain search distance. Same for BFS. 15:21:48 <_glx_> specific implementation optimised for the depot search yes, but I don't think it was Xarick's intention here 🙂 15:22:06 <kuhnovic> The reason I went for a BFS is that you can just treat each tile as 1 extra distance traveled. No need to keep nodes sorted, no keeping parents. Much more lightweight compared to A*, but only relevant if you don't know where your target is. And it has other drawbacks, there is no silver bullet. 15:23:09 <kuhnovic> _glx_: Hehe no, I think he once implemented a for-all-depots-run-low-level-PF. Granted, that was in a draft PR. 15:24:44 <xarick> it's still a valid approach, it's functional in my view, but it was done in 1 go, instead of multiple commits, and that's why I shied away 15:25:25 <_glx_> it works yes, but it's very expensive 15:25:45 <xarick> expensive for large distances, but not for this situation 15:26:07 <xarick> but okay 15:27:23 <xarick> Kuhnovic avoids the large distances by imposing a max distance 15:27:39 <xarick> 6 regions i think 15:28:19 <xarick> I made no such restrictions 😦 15:30:37 <kuhnovic> IMO it makes no sense for ships to look for a depot on the other side of the map if they need to service. In the past there was an unofficial limit for this, which was YAPF hitting the node limit haha 15:31:43 <kuhnovic> The high level pathfinder is fast enough to search the entire map for depots if you wanted it to 15:31:46 <DorpsGek> [OpenTTD/OpenTTD] 2TallTyler opened pull request #12172: Fix fd9e72a: Helptext for timekeeping unit setting erroneously refers to vehicle movement https://github.com/OpenTTD/OpenTTD/pull/12172 15:33:43 <kuhnovic> Your solution is a O(n) one: you need to do a PF run for every depot. The computational burden grows linearly with the number of depots. That's what you want to avoid. 15:36:07 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain approved pull request #12172: Fix fd9e72a: Helptext for timekeeping unit setting erroneously refers to vehicle movement https://github.com/OpenTTD/OpenTTD/pull/12172#pullrequestreview-1899519752 15:36:12 <xarick> the method you're referring is the part where it finds a region with multiple depots? 15:37:08 <xarick> I can remove that part if it's really what I must do 15:37:24 <xarick> I was trying to make it accurate 15:37:45 <kuhnovic> xarick: I'm referring to running a PF for each depot 15:38:32 <truebrain> (And yes talltyler , I know I put it on Discord, but I also know it wasn't my text 😛 ) 15:38:33 <xarick> it doesn't run a PF for each depot, it runs a low level PF for each entry point the region is accessed to whatever depot it finds 15:38:50 <merni> truebrain: I think I was at least partially responsible :P 15:38:53 <xarick> which at that time, we know it exists 15:38:55 <kuhnovic> It's a balancing act between accuracy and performance. And it's not trivial, otherwise it would have been done already 😁 15:39:16 <kuhnovic> (gotta go now, more PF talk later!) 15:39:23 <xarick> ^_^ 15:39:26 <truebrain> merni: It is just funny .. if he can blame me, he does, otherwise it is "someone I wouldn't mention" .. I see a clear pattern 😛 15:40:10 <merni> looks like nielsmh was the one who first introduced the idea of vehicle movement there though... I am guilt-free :P 15:40:36 <truebrain> And that is the most important thing! 15:41:19 <truebrain> If something goes wrong and you are smiling .. you have someone else to blame! 15:43:31 *** urdh has quit IRC 16:09:21 <DorpsGek> [OpenTTD/OpenTTD] 2TallTyler merged pull request #12172: Fix fd9e72a: Helptext for timekeeping unit setting erroneously refers to vehicle movement https://github.com/OpenTTD/OpenTTD/pull/12172 16:16:02 <LordAro> i blame truebrain for the thing going wrong 16:16:12 <LordAro> whatever the thing is, i can't tell from scrollback 16:17:52 *** urdh has joined #openttd 16:19:15 <Eddi|zuHause> it is usually a safe bet to do that. 16:19:51 <Eddi|zuHause> i think they're talking about #12172? 16:27:42 *** SigHunter has quit IRC 16:29:31 <truebrain> LordAro: I love you too 16:30:21 *** SigHunter has joined #openttd 16:30:30 <talltyler> truebrain: That's because you're the CEO of OpenTTD, right? 😛 16:30:56 <talltyler> (I am not trying to establish or follow a pattern, to be clear 🙂 ) 16:31:05 <truebrain> You failed 😛 16:31:07 <truebrain> 😄 16:36:13 <talltyler> Heheh 16:36:31 <talltyler> Hmm, I wonder where in this blog post I should mention cargo production scaling... 16:36:51 <talltyler> It is really separate from "make time go slower" but is one of the other things people like about Daylength 16:37:24 <merni> it is not "make time go slower" but "make <X> go slower" where X is factories 16:37:28 <talltyler> Maybe I will mention it right after I mention Daylength 16:37:29 <merni> or whatever 16:38:00 <peter1138> Well. 16:38:06 <peter1138> Something crashed, probably GPU drivers :S 16:39:44 *** Wormnest has joined #openttd 16:41:30 <peter1138> I misread Timekeeping as Beekeeping.... 16:41:40 <talltyler> Bzzz 🐝 16:42:51 <truebrain> talltyler: Just make it its own section? 🙂 16:44:08 <talltyler> Good idea 🙂 16:54:41 <andythenorth> oh I failed on black as well 16:54:48 <andythenorth> and flake8 16:54:50 <andythenorth> oops 16:56:34 <andythenorth> _glx_: if I've understood nml main.py correctly, my patch should only be skipping palette validation, so `--no-palette-validation` might be appropriate arg name? 16:57:39 <_glx_> makes more sense yes 16:58:54 <peter1138> There we go, I social-media'd the blog post. 16:59:01 <peter1138> (Didn't get around to it for the others, sorry!) 17:04:05 <DorpsGek> [OpenTTD/nml] andythenorth updated pull request #322: Change: add forcibly_skip_sprite_processing arg option https://github.com/OpenTTD/nml/pull/322 17:04:34 <andythenorth> hmm 17:04:45 <andythenorth> ok so if I don't blacken nml/main.py the checks fail 17:05:07 <andythenorth> but if I do blacken it, I get a large diff on lines that having nothing to do with my PR, which won't be approved 17:05:16 <andythenorth> marvin moment? 🙂 17:05:34 <DorpsGek> [OpenTTD/website] 2TallTyler opened pull request #307: Add: Blog post about timekeeping in OpenTTD 14 https://github.com/OpenTTD/website/pull/307 17:05:35 <peter1138> Due to a blacken update? 17:05:39 <andythenorth> unclear 🙂 17:05:51 <andythenorth> I think nml is only selectively blackened or something 17:06:23 <peter1138> Might be worth a separate PR to just rerun blacken. 17:07:01 <andythenorth> I *believe* that some of it is deliberately not blackened, to preserve formatting 17:07:23 <merni> I thought the whole point of black was to not think about formatting 17:08:10 <andythenorth> it is, but I remember nml has exceptions somewhere 17:08:39 <DorpsGek> [OpenTTD/OpenTTD] 2TallTyler opened pull request #12173: Update: Developer credits https://github.com/OpenTTD/OpenTTD/pull/12173 17:08:51 <andythenorth> think the clue is in the history https://github.com/OpenTTD/nml/commit/72bc37a0622c9c8fb79cb55c3e16fe9345c866b8 17:09:21 <andythenorth> ok I have `black, 24.2.0` 17:09:38 <andythenorth> looks like we had 23.1 last time https://github.com/OpenTTD/nml/commit/e0be2090b96c4972fab9988ac8a6835ea1cc2832 17:10:49 <andythenorth> black has no arg to specify the black version, do I need to pip downgrade maybe? 17:11:03 <merni> probably 17:12:35 <andythenorth> hmm still a giant diff with 23.1 17:13:00 <andythenorth> https://gist.githubusercontent.com/andythenorth/9197b2836691bb1c4431019a6c2a28ff/raw/988bc4144d8cb1e407de952cd16cff07b61482a9/gistfile1.txt 17:13:11 <truebrain> set your linelength 🙂 17:13:34 <andythenorth> -l 120? 17:14:21 <truebrain> lol @ talltyler ; Time Lord .. lol 17:14:39 <DorpsGek> [OpenTTD/nml] andythenorth updated pull request #322: Change: add forcibly_skip_sprite_processing arg option https://github.com/OpenTTD/nml/pull/322 17:15:53 <DorpsGek> [OpenTTD/nml] andythenorth commented on pull request #322: Change: add --no-palette-validation optional arg https://github.com/OpenTTD/nml/pull/322#pullrequestreview-1899542226 17:19:14 <_glx_> you can also just run `make black` 🙂 17:19:22 <_glx_> it handles the args 17:19:31 <andythenorth> thanks 17:20:15 <xarick> lalala 17:23:07 <andythenorth> I've got in a bit of a squeeze with nmlc 17:23:19 <andythenorth> I have grfs that now want to use nmlc built from multiple PRs 17:23:22 <andythenorth> including https://github.com/OpenTTD/nml/pull/309 17:23:36 <andythenorth> I guess I could merge them all into some branch 17:24:55 <DorpsGek> [OpenTTD/OpenTTD] AdminChucky commented on issue #11336: [Bug]: Missing servers on server listing https://github.com/OpenTTD/OpenTTD/issues/11336 17:26:25 <DorpsGek> [OpenTTD/website] zephyris commented on pull request #307: Add: Blog post about timekeeping in OpenTTD 14 https://github.com/OpenTTD/website/pull/307#pullrequestreview-1899543438 17:27:40 <DorpsGek> [OpenTTD/nml] glx22 commented on pull request #322: Change: add --no-palette-validation optional arg https://github.com/OpenTTD/nml/pull/322#pullrequestreview-1899543353 17:28:05 <_glx_> it's easy to make errors in python 17:28:30 <truebrain> SAST FTW? 17:28:51 <truebrain> more typing! 17:28:51 <truebrain> 🙂 17:30:24 <andythenorth> oh 🙂 I thought find-and-replace had got those in my editor sorry 17:34:55 <DorpsGek> [OpenTTD/nml] andythenorth updated pull request #322: Change: add --no-palette-validation optional arg https://github.com/OpenTTD/nml/pull/322 17:45:10 <ajmiles> ajmiles: peter1138 What's your view on this? 17:45:41 <ajmiles> I see there are blitters without 'anim', but I don't know if they're visually deficient in some way or just slower than the 40b ones? 17:47:36 <peter1138> They don't support palette animation. 17:48:30 <peter1138> Palette animation can be turned on and off. When doing all the blitting in software there's a minor improvement to not handling the palette animation buffer when palette animation is turned off. 17:49:19 <ajmiles> And sorry for the basic questions, but how does palette animation manifest in the game? If a blitter doesn't support doing it, what looks different? 17:49:55 <truebrain> the seas are static 17:49:57 <truebrain> instead of animated 17:50:06 <truebrain> one of the easiest to observe 17:50:36 <truebrain> just start the game in your non-development video driver and enable/disable animation in-game 🙂 17:50:51 <peter1138> https://cdn.discordapp.com/attachments/1008473233844097104/1211007347561070642/Screencast_from_2024-02-24_17-50-30.webm?ex=65eca17b&is=65da2c7b&hm=3ad0ff5ede21a32e7df623e610874d8791d04cda3964b0233cdf7fab45d5c738& 17:51:06 <peter1138> Hmm, video compression hides it a bit. 17:51:24 <truebrain> seeing it in-game yourself is best to understand what it is, honestly 🙂 17:51:49 <peter1138> When you know what you're looking for 🙂 17:51:53 <ajmiles> OK, let me take some of the anim blitters out the list and have a look now I know what I'm looking for! 17:52:19 <peter1138> https://cdn.discordapp.com/attachments/1008473233844097104/1211007716932190238/image.png?ex=65eca1d3&is=65da2cd3&hm=b9c88975fe8974df3e3f9b8d1a6edf0cb75e1c55be09d36f160db99095d4d438& 17:52:24 <peter1138> This option turns it on & off. 18:00:01 <xarick> I feel so sad to undo so much of the work I had accomplished 18:00:23 <ajmiles> https://cdn.discordapp.com/attachments/1008473233844097104/1211009745834475681/OpenTTD_20240218-master-m15be383b93_2024-02-24_17-58-53.mp4?ex=65eca3b6&is=65da2eb6&hm=8b387ff9192094178ec87d2f4843f29389d85c5f06a292703e82f19996ba0663& 18:00:23 <ajmiles> Looks like I've managed to get it working for only some runway lights... somehow 18:01:51 <truebrain> lol, mouse artifacts ... I have seen that way too often 🙂 18:02:18 <ajmiles> My implementation of DrawMouseCursor doesn't capture and restore what's under the mouse right now 18:02:33 <peter1138> That happens when the tile is redrawn -- it's use the current state of the palette animation, but not actually doing palette animation. 18:02:39 <DorpsGek> [OpenTTD/OpenTTD] SamuXarick updated pull request #10544: Fix #5713: Use pathfinder to find closest ship depot https://github.com/OpenTTD/OpenTTD/pull/10544 18:02:53 <xarick> this was just a rebase 18:03:10 <xarick> now I'm gonna undo 😦 18:03:15 <xarick> the complexity 18:03:20 <ajmiles> peter1138: Yeah, I'm going to have to find where palette animation is "done" to understand what I've missed 18:03:58 <peter1138> When copying the backbuffer to screen you probably need a shader to handle the 8bpp anim buffer there. 18:05:02 <ajmiles> I have what I thought was a copy of the OpenGL shaders for the end of frame draw. It runs in 3 modes MODE_REMAP, MODE_PALETTE and MODE_PROGRMA 18:05:50 <truebrain> OpenGL uses shaders for that, `remap_program` if I remember correctly 18:05:53 <truebrain> it is applied every frame 18:06:11 <truebrain> https://github.com/OpenTTD/OpenTTD/blob/master/src/video/opengl.cpp#L1051 18:06:33 <ajmiles> https://cdn.discordapp.com/attachments/1008473233844097104/1211011300587601990/image.png?ex=65eca529&is=65da3029&hm=5dcaadac16a34c6b8f185cd10349070501b91ed6c32c15cafc43405a16e6d77f& 18:06:33 <ajmiles> Right. I have this 18:07:23 <ajmiles> But that's not actually animating the anim buffer, that's just remapping it to RGB. I think what I must be missing is the action taken to update the anim buffer with the new 'm' value for animating things like the lights 18:07:38 <peter1138> The anim buffer isn't updated. 18:07:54 <peter1138> The rgb value that m maps to is altered. 18:08:49 <ajmiles> That's the 256 entry palette I call palette? 18:08:51 <truebrain> the 8bpp days, where that was the cheapest way to animate stuff 😄 18:10:00 <peter1138> Not sure. 18:10:13 <peter1138> I'm a bit confused by the idea of shader modes at this point. 18:10:36 <peter1138> Don't you have different shaders for doing different things? 18:10:43 <ajmiles> That was just my way to collapse 3 shaders into 1 18:10:59 <peter1138> Hmm 18:11:06 <ajmiles> The shader is short enough that there was no need to compile 3 different versions and pick which one to use 18:12:12 <peter1138> What is frameIndex here? 18:12:18 <ajmiles> Just when it's an even or odd frame 18:13:13 <ajmiles> The CPU writes directly to the current frame's palette without copying it over to the GPU. So the CPU writes to one copy and the GPU reads from the other, so it just ping pongs every other frame 18:13:37 <peter1138> Okay, so concurrency safety. 18:13:40 <ajmiles> Yep 18:14:17 <ajmiles> https://cdn.discordapp.com/attachments/1008473233844097104/1211013243644940429/ZoomAirport.mp4?ex=65eca6f8&is=65da31f8&hm=1959c04b709513f2f1ed299996941768d9fa1daab174c693e4bcc2e1a70d6044& 18:14:17 <ajmiles> At a sufficient level of zoom, it works 18:14:34 <truebrain> it just appears to work 😉 18:14:45 <peter1138> And is this shader a separate part of the process from blitting sprites? 18:14:52 <peter1138> (Because it should be) 18:15:03 <ajmiles> Yes, it's the final event of the frame 18:15:17 <ajmiles> That palette applies to everything on the screen at the end of the frame 18:15:34 <truebrain> from what I can see from your animations, the sea is not animating 18:15:46 <ajmiles> That's true 18:15:46 <truebrain> so most likely parts of the airport are just redrawn often enough to give the illusion of animation 18:15:53 <truebrain> but it is not actual the palette animation we are talking about 18:16:27 <peter1138> The two stages of palette animation 😄 18:16:40 <peter1138> Initial drawing and then updating. 18:16:42 <ajmiles> BlitterParams 'bp' comes with its own 'remap' array each time a sprite is drawn. Is that a different remap (and remap array) to what happens at the end of the frame? 18:16:54 <ajmiles> Right now I do nothing to respect the BlitterParams' remap 18:16:54 <truebrain> so just so we are talking the same story: every frame a few indexes of our palette are updated with new RGB values; so the index into the palette remains the same, but the actual colour changes 18:17:04 <peter1138> Yes, that is it a different remap. 18:17:12 <ajmiles> And is it relevant to the sea animating? 18:17:23 <truebrain> that is what is the "Full animation" thing is doing 18:17:25 <peter1138> Nope. 18:17:45 <peter1138> That remap is for doing things like making vehicles appear company coloured. 18:17:57 <peter1138> (Along with lots of other uses) 18:18:10 <peter1138> But the ignoring that remap shouldn't affect palette animation. 18:18:15 <ajmiles> So the sea animates by virtue of the end-of-frame palette changing what RGB the anim buffer maps to? 18:18:21 <peter1138> Yes 18:18:37 <peter1138> As do the yellow lights on the airport. 18:18:39 <ajmiles> How do you animate the sea without everything else in the world that shares the sea's anim buffer values changing as well? 18:18:55 <truebrain> it doesn't; that palette index is going to change, whether you want to or not 18:19:02 <peter1138> The rotating radar(?) dish is of course not palette animation, and that is probably affecting why it appears to work. 18:19:05 <truebrain> so only images that want the animation, use that "colour" (read: palette index) 18:19:24 <peter1138> Yeah, all those palette indices are reserved for animation 🙂 18:19:37 <truebrain> sometimes NewGRF authors fuck up and think it is a static colour, and use it for their train or what-ever 18:19:44 <truebrain> resulting in funny animations 🙂 18:19:49 <ajmiles> OK, so if some part of a building shared the sea's anim value, that part of a building would be the same colour as the sea - but in practice, they probably don't? 18:19:50 <peter1138> Anything above 215 iirc. 18:20:28 <peter1138> Yes. It would animate as well. Like the water fountain in towns. 18:21:04 <truebrain> all this is called "animation buffer" in our blitters / video drivers, but often referred to as palette animation 18:21:19 <truebrain> (and unrelated to the remap mentioned earlier, although this also "remaps" colours .. confusing, not? 😄 ) 18:21:46 <ajmiles> The 'remap' mentioned earlier remaps anim buffer values to other anim buffer values IIRC 18:21:55 <ajmiles> (not to RGB) 18:22:07 <frosch123> ajmiles: yes, some buildings have pools on their roof, and they will use the same animated water colours 18:22:09 <truebrain> not only the anim buffer 🙂 18:22:13 <peter1138> Imagine an ancient graphics card which actually supported 8bpp mode with a palette. Back then, the palette was animated simply by changing the palette values, and the graphics card would automatically output the new values without anything else changing in memory. 18:22:44 <peter1138> ajmiles: Yes 18:22:44 <ajmiles> OK, maybe then my palette isn't updating every frame as it should 18:22:55 <peter1138> ajmiles: Also yes, although I have a patch for that 😄 18:23:05 <truebrain> OpenGL uses a texture for it, which is loaded by a shader and applied on every pixel 18:23:16 <truebrain> this texture is updated whenever the "anim buffer" is updated 18:23:29 <ajmiles> Yeah, I saw the Texture1D in there and opted to use a buffer instead 18:23:49 <rau117> ajmiles: Blue airport buildings, but red airport name? 18:24:00 <truebrain> and yes, this is a really ancient way of approaching all this, but that shows how old the game is 🙂 18:24:10 <truebrain> If we would rewrite this all, nobody would do it like this 😛 18:24:33 <ajmiles> rau117: ~~Bug~~Feature! 18:24:46 <truebrain> that btw is the other remapping not being applied, I assumed 🙂 18:25:21 <truebrain> yeah, default company colours are blue; I always forget what the default colour is 🙂 18:25:26 <ajmiles> Right. That one I *know* I'm not doing yet. Need to figure out the best way to get a 256-entry array over to the shader that I presume can potentially change with every sprite drawn 18:25:47 <ajmiles> Although presumably only the ones using the BlitterMode with 'REMAP' in the name 18:25:51 <peter1138> The game itself treats these 256-entry arrays as sprites too. 18:26:00 <peter1138> That might be a guide on how to proceed. 18:26:17 <ajmiles> Are they fully dynamic, or loaded like an asset? 18:26:43 <peter1138> (Well, not just like sprites, but they have SpriteIDs and are included in the spritecache) 18:26:45 <truebrain> btw, `ReleaseAnimBuffer` is used by OpenGL to know it has to rework the animation texture 18:26:49 <peter1138> They are loaded like an asset. 18:27:07 <peter1138> If you have remap "776" it is always the same remap. 18:27:38 <peter1138> (And I also have patches to dynamically create these, but it's still treated like an asset) 18:27:43 <ajmiles> I'm already handling the loading of all sprites and creating textures for each one at every zoom level, so I've probably inadvertantly already got them available 18:28:24 <peter1138> Probably not, they are handled differently lower down, and they don't have dimensions or offsets of course. 18:28:29 <ajmiles> Ah 18:29:59 <peter1138> So when blitting with a remap you'd need to do palette[remap[sprite.m]] instead of palette[sprite.m] 18:30:04 <_glx_> truebrain: CHIPS blinking cows 18:31:12 <truebrain> and with animation it becomes `palette[anim[remap[sprite.m]]]` I guess? 😄 18:31:32 <peter1138> No 🙂 18:31:43 <truebrain> euh, no indeed 18:31:48 <ajmiles> https://cdn.discordapp.com/attachments/1008473233844097104/1211017654324953118/image.png?ex=65ecab14&is=65da3614&hm=12c2426e4d38a169fd19ff7797c91b5b394594c322c18a68255a09a979e15b1f& 18:31:48 <ajmiles> You've reminded me of another question I had. Then I handle the encoding of sprites, some come through with only 1 valid zoom level (the first one), the other zooms are 0xCC or some other fill pattern depending on DEBUG/RELEASE and I'm not clear on how to know which ones to process 18:31:49 <truebrain> hmm, can't even write that like that 18:31:51 <truebrain> booooo 🙂 18:32:03 <ajmiles> 16384 was just my hack to pick up on the invalid size and worry about something else 18:32:11 <peter1138> all zoom levels should be valid. 18:32:17 <ajmiles> This is a font though 18:32:30 <peter1138> Ah, okay, if it's a font, then only the first zoom level is used. 18:32:46 <_glx_> 0xCC means initialised value in DEBUG 18:33:01 <_glx_> it's an MSVC thing 18:33:11 <truebrain> lol; TIL 🙂 18:33:22 <peter1138> 32bpp_optimized.cpp:309 handles this case for the sprite encoder. 18:33:27 <_glx_> forgot a wrod 18:33:40 <peter1138> For now you could do the same. 18:33:57 <peter1138> However with hardware blitting the pre-scaling is most redundant. 18:34:09 <peter1138> So how the sprites get passed to the encoder should be changed. 18:34:22 <peter1138> (Funnily enough, by fractional scaling patch does that in a way that might be suitable) 18:35:13 <DorpsGek> [OpenTTD/OpenTTD] eints-sync[bot] pushed 1 commits to master https://github.com/OpenTTD/OpenTTD/commit/ddb391407440522fdcd28f51e64f4a4ee14ee9fa 18:35:14 <DorpsGek> - Update: Translations from eints (by translators) 18:35:17 <truebrain> You are going to hit "Error: too many branches", one of these days 😛 18:35:26 <ajmiles> Are sprites always authored at ZOOM_LEVEL_NORMAL and every other zoom level is a nearest neighbour rescaling? 18:35:26 <peter1138> I don't think that's a thing :p 18:35:32 <peter1138> No. 18:35:54 <peter1138> Most common is ZOOM_LVL_OUT_4X, which is the original 1x zoom. 18:36:16 <_glx_> (yeah we have weird numbering) 18:36:35 <peter1138> The game prescales everything up because we were a bit silly and didn't want to complicate the blitters with pixel doubling on the fly... 18:36:40 <truebrain> and I guess a NewGRF author can make some zoom-levels look totally different from others, if they like? More detail etc? 18:36:53 <_glx_> and they do 18:36:55 <peter1138> They can, yes. 18:37:25 <peter1138> With hardware scaling it's possible to still use those but not fabricate anything. 18:37:28 <ajmiles> At some point I imagine I'll want to load only the levels that the sprite author has authored and have the hardware point filter magnify any levels more zoomed-in that the most zoomed in level provided 18:37:30 <_glx_> that's why zooming looks ugly when you mix non EZ with EZ 18:37:32 <peter1138> (I think) 18:37:55 <ajmiles> EZ standing for? 18:38:01 <peter1138> Did I ever push the fractional sprite scaling anywhere... 18:38:03 <peter1138> Extra Zoom 18:38:32 <truebrain> I just keep reading it as "easy" 😛 18:40:59 <_zephyris> If only they were EZ to draw 18:45:32 <peter1138> Remember that day we dropped PNG support 😄 18:45:37 <ajmiles> https://cdn.discordapp.com/attachments/1008473233844097104/1211021126306631791/Recording_2024-02-24_184522.mp4?ex=65ecae50&is=65da3950&hm=1ea16ad6a3cf338aa71f43afc044e0839e7ecfb7f5f542f3ac34a36c3e115f53& 18:45:37 <ajmiles> Yeah, not seeing much animation going on in this palette 18:47:08 <j_n> good to see mouse cursor is working (kind of) 18:47:09 <peter1138> Pretty 18:47:29 <ajmiles> Just having something to be able to click with is a relief... 18:48:28 <xarick> I need costs! there's no way around it 18:48:34 <xarick> the high level pathfinder needs to return costs 19:02:38 *** Leopold has quit IRC 19:02:47 <andythenorth> oh checks passed on this 🙂 https://github.com/OpenTTD/nml/pull/322 19:05:13 <ajmiles> https://cdn.discordapp.com/attachments/1008473233844097104/1211026057919209472/Recording_2024-02-24_190448.mp4?ex=65ecb2e7&is=65da3de7&hm=5d527e72690103e29392dc49293851295697867d7734d817925186d224e6393a& 19:05:13 <ajmiles> 1 step forward, 1 step back 19:07:17 <truebrain> hmm, animation ..... 🙂 19:07:57 *** Leopold_ has joined #openttd 19:12:31 <peter1138> Perfect. Ship it! 19:39:22 <ajmiles> OK, fixed all that nonsense. Palette animation works correctly and nothing smears 19:39:56 *** Leopold_ has quit IRC 19:40:39 *** Leopold_ has joined #openttd 19:42:22 <ajmiles> Trying to comply with how a blitter is expected to work isn't straightforward. Last night I was trying to implement the `ScrollBuffer` functionality which I assume is there to just move the dst/anim contents around rather than having to reblit the entire screen 19:42:36 <peter1138> Yup. 19:43:36 <ajmiles> https://cdn.discordapp.com/attachments/1008473233844097104/1211035723067559986/image.png?ex=65ecbbe8&is=65da46e8&hm=8d0cfb6c97664a78f352cd571d80fababb924f074dd907ef03948fee5a0810e6& 19:43:36 <ajmiles> I came up with a way to do in-place scrolling of those buffers on the GPU, but I've got some shearing which is probably my fault but I can't rule out the possibility that I've scrolled properly but then the relevant parts of the screen weren't repainted correctly 19:44:17 <ajmiles> Oh yes, that was what I was going to ask. ScrollBuffer takes many of its arguments by reference like there's an expectation that the blitter is going to modify them and pass back new values, but it wasn't clear how? 19:46:30 <peter1138> Yes, gfx.cpp:93 19:47:33 <peter1138> Seems to be that ScrollBuffer may scroll something other than requested, and so the parameters are updated so that MakeDirty() can be called correctly. 19:48:06 <ajmiles> Yeah that's how it seemed, though I couldn't understand why a blitter would scroll something other than what it was asked to 19:48:24 <peter1138> Might explain the glitches though. 19:48:26 <ajmiles> If you're given a box and told to scroll it N pixels, well, that area is dirty now 19:49:05 <ajmiles> What's bugging me is that the shearing only seems to occur on/around towns and industries, not on the terrain 19:49:39 <peter1138> Might be related to tiles that update at the same tile. 19:49:51 <peter1138> Well, not "same" time, but straight after. 19:51:09 <ajmiles> So, maybe I made a faulty assumption. Any sprite blit requests I buffer up and deal with at the end of the frame, whereas ScrollBuffer I issue when asked to. So if the order of operations is: 19:51:09 <ajmiles> 1) [Draw a load of sprites] 19:51:09 <ajmiles> 2) Then scroll 19:51:09 <ajmiles> I'll have that backwards 19:51:32 <ajmiles> If the order of operations can be: 1) Draw some sprites, 2) Scroll, 3) Draw more sprites. I'm even more wrong/screwed 19:52:31 <peter1138> I'm not sure on that either 🙂 19:53:00 <peter1138> I would assume the scroll is done, and then the tiles that were obscured should now be drawn, after the scroll is complete. 20:01:20 <ajmiles> Looks like there's 3 scrolls too, split into Left, Middle and Right corresponding to where the little status bar is at the bottom of the screen 20:07:32 <peter1138> So it's possible we could use separate buffers for each window, and then scrolling only ever moves the whole viewport. 20:07:38 <peter1138> I also... have a patch for that. 20:08:28 <ajmiles> It had crossed my mind to ask for a mode that redraws the whole screen every frame 20:08:49 <ajmiles> Forget about dirty rects, scrolling etc. Just do what any normal game would do and start afresh each frame 20:09:26 <peter1138> Any normal 3D game, yes. 20:09:57 <ajmiles> And any 2D ones built this side of the invention of GPU acceleration 😄 20:10:03 <peter1138> You can do that. But it could be quite slow. 20:10:36 <peter1138> Game state is not organised in a way that is organised for graphical display. 20:10:42 <ajmiles> I'd like to work within the parameters of the way the game works right now though, at least where feasible 20:11:47 <peter1138> Especially when zoomed out, there is a LOT of game state to process. 20:13:18 <peter1138> Framerate drops from 170fps to 10fps if I redraw the whole screen every frame 🙂 20:13:25 <peter1138> (When zoomed out) 20:14:05 <ajmiles> But how much of that extra 94ms is spent actually blitting it all - a cost that could be near-zero to the CPU in this world? 20:14:19 <ajmiles> (not a question I'm looking for an answer to) 20:14:56 <peter1138> For each tile visible that game executes a function that that checks how the tile should be drawn. 20:15:35 <peter1138> This will look up the state of the tile, work out what it is, look up tile layouts and add sprites to draw. 20:16:24 <peter1138> It will also check for vehicles on each tile, query what they should look like, and add those sprites to draw. 20:16:50 <peter1138> And then it needs to sort all those sprites into the correct order for drawing. 20:17:01 <peter1138> (That might be doable with Z-buffer with GPU acceleration) 20:17:24 <peter1138> And then it draws the sprites, loading on demand if necessary, etc etc. 20:17:29 <peter1138> There's quite a lot to do 🙂 20:17:31 <ajmiles> Heh, yes, also crossed my mind. I don't use one right now, but there's enough Z values in a 32bpp ZBuffer to give every sprite its own Z if we wanted 20:17:44 <DorpsGek> [OpenTTD/website] stormcone commented on pull request #307: Add: Blog post about timekeeping in OpenTTD 14 https://github.com/OpenTTD/website/pull/307#pullrequestreview-1899562699 20:18:37 <peter1138> Ctrl-I will (with the existing blitters at least) highlight which screen areas are being drawn. 20:20:21 <peter1138> (That doesn't necessarily match the tiles that are being queried though) 20:21:10 <peter1138> Modern games would remember the drawing state between frames, perhaps in chunks. 20:23:27 <peter1138> e.g. send a list of sprites and positions for a small region into a buffer, and then just have 1 call to draw that buffer. 20:23:41 <peter1138> If any tile in that buffer changes state, then the buffer is updated. 20:24:10 <peter1138> The future eh... such magic. 20:24:36 <_glx_> it's partly done that way, but with CPU blitting 20:25:01 <_glx_> only changed stuff is repaint 20:25:12 <peter1138> No, that's a completely different approach 🙂 20:25:16 <ajmiles> https://cdn.discordapp.com/attachments/1008473233844097104/1211046208781688852/image.png?ex=65ecc5ac&is=65da50ac&hm=427a32467a13126bddfc517dd864b022bc451ecf7ea02b1b85606ac5c13cdd08& 20:25:16 <ajmiles> GPUs... they'll never catch on. 20:25:51 <peter1138> nVidia is pivoting to this AI bullshit. Gaming GPU is barely anything to them now. 20:26:20 <ajmiles> Yep. Leaving AMD to play catchup 20:27:44 <andythenorth> ajmiles: just blame FIRS for that, it's the cause of most OpenTTD problems 🙂 20:28:02 <ajmiles> Name names. Who do I send the bill to? 😄 20:28:06 <_glx_> nah FIRS and GS/AIs 20:28:12 <andythenorth> especially FIRS GS 20:28:46 <xarick> good old Intel vs AMD 20:29:44 <_glx_> oh and I think the blue on the buildings is not supposed to stay blue 🙂 20:30:02 <peter1138> That's just recolouring not being implemented yet 20:30:25 <xarick> https://cdn.discordapp.com/attachments/1008473233844097104/1211047505312350208/image.png?ex=65ecc6e1&is=65da51e1&hm=1bf55a19bdde5dceeb263c0ad288f747ce06f46a5948cea8807e7e6f6a144697& 20:30:25 <xarick> testing cool stuff again 20:30:30 <ajmiles> It's next on my list after the shearing/scrolling doesn't look awful 20:30:45 <_glx_> this industry is a good test case for both recolour and anim 🙂 20:47:54 <andythenorth> _glx_: yolo merge? 🙂 https://github.com/OpenTTD/nml/pull/322 20:49:26 <DorpsGek> [OpenTTD/OpenTTD] jcteotonio updated pull request #12108: Add: Portuguese Escudo currency https://github.com/OpenTTD/OpenTTD/pull/12108 20:50:48 <DorpsGek> [OpenTTD/OpenTTD] jcteotonio updated pull request #12108: Add: Portuguese Escudo currency https://github.com/OpenTTD/OpenTTD/pull/12108 20:51:03 <DorpsGek> [OpenTTD/nml] glx22 approved pull request #322: Change: add --no-palette-validation optional arg https://github.com/OpenTTD/nml/pull/322#pullrequestreview-1899565828 20:53:46 <DorpsGek> [OpenTTD/nml] glx22 merged pull request #322: Change: add --no-palette-validation optional arg https://github.com/OpenTTD/nml/pull/322 20:55:26 <andythenorth> thanks 20:55:57 *** kamnet has joined #openttd 20:55:58 <kamnet> So since I've missed the development, how fast can ships go now? 21:06:37 <xarick> https://cdn.discordapp.com/attachments/1008473233844097104/1211056613478113421/image.png?ex=65eccf5c&is=65da5a5c&hm=5af8d33c8a7f1d5889883ad7e1d86586fd49a551f523d63d568efa5d2f6dd8af& 21:06:37 <xarick> I have a hard time believing this... 21:08:26 <peter1138> kamnet: Ekranoplans 21:09:53 <kamnet> https://tenor.com/view/excellent-happy-mr-burns-simpsons-satisfied-gif-16091269 21:11:01 <xarick> well, it's debloated and using the same leash as Kuhnovic's, but still... I didn't expect it to be faster 21:12:16 <kamnet> And I just now saw Zephery's announcement. My list of things I'm never going to get around to doing keeps growing shorter 🙂 21:13:13 <xarick> I need to verify ships are really finding their depots 21:15:16 <xarick> oh, of course not 21:15:23 <xarick> i forgot something 21:15:35 <_glx_> it's fast but does nothing ? 21:15:38 <xarick> must multiply by YAPF_TILE_COST 21:17:01 <_zephyris> kamnet: Something like 20,000 mph I think... Word for speed in mph*3.2. I wonder if something would break if you actually coded that. 21:17:03 <xarick> YAPF_TILE_LENGTH i mean 21:17:36 <_zephyris> And acceleration can be 255 times normal ship acceleration! 21:17:55 <xarick> Kuhnovic uses distance based on number of tiles, I use the pathfinder distance, and that's 100 per tile 21:20:18 <xarick> a max cost of 80, that would mean... less than a tile, lol 21:22:10 *** dwfreed_ is now known as dwfreed 21:26:15 <peter1138> Instant deceleration 😄 21:29:20 <xarick> https://cdn.discordapp.com/attachments/1008473233844097104/1211062328464769064/image.png?ex=65ecd4af&is=65da5faf&hm=4c60e9cdf4673d2ff70d4bb73e08adce857241538e7b3bb1b7dc592c2df4ea5a& 21:29:27 <xarick> now that makes sense 21:29:31 <xarick> it's slower 21:30:41 <xarick> ships seem to be finding depots, but 80.... I mean, my AI uses a depot right in the middle of a route, and some routes are ~200 tiles appart 21:30:52 <xarick> I don't think all my ships can find depots 21:31:16 <xarick> half of 200 is ~100 21:31:24 <xarick> 80 is less than 100... hmm 21:32:23 <xarick> do i have to use buoys because of that limited range? 21:32:27 <xarick> sad 21:33:16 <peter1138> <https://github.com/OpenTTD/OpenTTD/compare/master...PeterN:OpenTTD:fractional-interface-sprites> 21:33:20 <peter1138> Such silly code 21:34:04 <peter1138> xarick: as long as it passes near the depot enroute it should find it, no? 21:35:24 <xarick> no, because it's coming from the orderlist 21:35:49 <xarick> when it leaves the docks, it calculates nearest depot with a limit of 80 21:35:52 <peter1138> Oh, go to nearest depot order rather than just finding a depot. 21:36:41 <peter1138> Stupid question but could a go to nearest depot order cache a depot? 21:37:25 <peter1138> Hmm, when to invalidate a cache might be a problem. 21:37:26 <xarick> if it was an automated order, it would be ... _settings_game.pf.yapf.maximum_go_to_depot_penalty / YAPF_TILE_LENGTH 21:37:34 <_glx_> would be simpler to make a fixed depot order 🙂 21:37:38 <xarick> aka 20 21:38:26 <peter1138> Anyway, isn't the new high level pathfinder designed to make path finding quicker... I'm missing something. 21:38:43 <xarick> yeah, that's what I thought! no buoys needed! 21:38:56 <xarick> but now I need buoys 21:39:03 <xarick> to find closest ship depot? 21:39:08 <_glx_> it is for proper destinations, but "closest depot" is not a real destination 21:40:13 <michi_cc[d]> ajmiles: Late to the game here 🙂 Are you basically collapsing blitter and video driver? 21:40:21 <_glx_> and for now we don't really have a fast PF specialised in depot search on water 21:40:55 <peter1138> Store the nearest reachable depot on the map 😉 21:40:56 <michi_cc[d]> The current OpenGL video driver is part of a two step process, and it might or might not make sense to keep it like that. Absolutely not sure which approach is better though 🙂 21:41:22 <xarick> I could use a proper destination indeed, but that just means it's no longer doing a ClosestShipDepot call, it's going to do a normal pf call 21:41:25 <peter1138> Store the nearest reachable depot for each region. 21:41:55 <_glx_> nearest depends on where you enter 🙂 21:42:07 <michi_cc[d]> Current rendering process: Draw to to offscreen framebuffer, render FB to onscreen, applying palette mapping and overlaying mouse cursor sprite. 21:42:10 <ajmiles> michi_cc[d]: I'm not sure if collapsing them is necessary what I'd call it as the concept of "Blitter" and "VideoDriver" still exist, but certainly the VideoDriver is taking on all the responsibility of blitting. The blitter just passes along requests to the video driver 21:42:56 <ajmiles> VideoDriver now has functions like `EnqueueDrawRect` and `EnqueueBlitSprite` which take similar parameters to `blitter->[those functions];` 21:43:12 <michi_cc[d]> My personal feel is that unless you want to rewrite a lot more of the drawing code, having a framebuffer/texture in between fits a lot better to the assumed drawing model 21:43:33 <michi_cc[d]> Like the stuff where you can apply a palette remap (not animation) to a screen rect. 21:44:10 <xarick> https://cdn.discordapp.com/attachments/1008473233844097104/1211066064125829140/image.png?ex=65ecd82a&is=65da632a&hm=f4f6921927595b520df6117508ca78b3817612fa1a3375470a420ad4ea6d79a1& 21:44:10 <xarick> this is reasonable 21:44:19 <ajmiles> It's still very much a two stage process in the sense that I'm blitting to "off screen" dst/anim and then compositing with palette remapping as a final step to the swap chain 21:44:44 <xarick> let me try now with an unlimited leash, brb 21:44:45 <michi_cc[d]> I even though about basically doing a compositing window manager and render each window to its own offscreen texture. Not really coded anything for that as _cur_dpi is very global and I had no mood to try to untangle that 🙂 21:45:09 <peter1138> I have a patch for that 😉 21:45:23 <_jgr_> I've done a bit of work on making various rendering-related thigns less global 21:45:30 <_glx_> if we can have windows non continuously calling DrawString 😉 21:45:44 <peter1138> That was my plan, yeah. 21:45:50 <_jgr_> I'm doing sprite sorting and blitting in separate threads 21:46:00 <peter1138> I didn't get as far as rewriting how dirtying works though, so it's slow. 21:46:07 <_glx_> because DrawString is super slow 21:46:10 <michi_cc[d]> ajmiles: Current drawing code assumes a persistent back buffer. Whether that is a good fit for a fully accelerated blitter is left as an excerise to the reader 😛 21:46:30 <peter1138> Hmm, where is it. 21:46:50 <michi_cc[d]> peter1138: If you can find it somewhere, I'd love to have a look at it. 21:47:01 <ajmiles> dst/anim are persistent, although why would the back buffer need to remain persistent? 21:47:10 <peter1138> It's only a couple of weeks old, should be able to 🙂 21:47:41 <michi_cc[d]> Well back buffer for the OpenGL video driver means the offscreen texture. For some other blitters it might be the real window surface. 21:47:51 <_glx_> peter1138: that's the old thing, you should now say "I have a branch for that" 😉 21:48:26 <michi_cc[d]> But if you have a persistent buffer, you should at least be able to use the same mouse cursor drawing as the opengl video driver so you don't need to do any screen restoring. 21:48:49 <peter1138> <https://github.com/OpenTTD/OpenTTD/compare/master...PeterN:OpenTTD:surface> 21:49:03 <ajmiles> Yeah, I think I looked at it and decided I'd need to go around and setup the whole cursor cache thing 21:50:07 <peter1138> ^ Very much WIP, of course. Surprisingly little change. 21:50:11 <michi_cc[d]> Well, if you already create textures in the blitter, you can probably just get that from the blitter for the cursor. The OpenGL cursor cache is just because the blitters are not storing the sprites as an OpenGL texture. 21:50:37 <peter1138> But marking things dirty does not do the right thing, it still goes via screen blocks. 21:51:45 <peter1138> Oh, looks like I only touched 32bpp_base, that would explain the lack of much code 🙂 21:52:20 <peter1138> Heh, and debug code in there for another issue. 21:53:07 <peter1138> Also the buffer allocation would need to be rewritten to actually use GPU buffers if that would become a thing. 21:54:33 <michi_cc[d]> Yeah, it needs a compositor class. Default implementation would just hand out memory blocks and do software copying. OpenGL/GPU video driver would override that to hand out offscreen textures per surface. 21:55:56 <peter1138> Also blitter calls should probably take a surface, with any coordinates passed as parameters, instead of using this award "rely on a random pointer being correct" method. 21:56:04 <ajmiles> OK, I've validated my fear that scrolling and drawing sprites are interleaved. It scrolls the left third of the screen, then renders sprites there. Then the middle third, then draw sprites there. Then finally the right side and the sprites there. 21:56:24 <ajmiles> That probably explains a lot of the shearing I'm seeing 21:56:34 <peter1138> Getting the correct pitch would be simpler that way. 21:56:47 <xarick> https://cdn.discordapp.com/attachments/1008473233844097104/1211069239889240074/image.png?ex=65ecdb1f&is=65da661f&hm=53d5cfd9b9874de3e27b35faa2392b3e83fd4ac475f0a6930916172f806ba426& 21:56:47 <xarick> unlimited range 21:56:52 <xarick> kek 21:56:54 <xarick> I win 21:57:42 <xarick> there are 70k ships in this savegame 21:57:56 <xarick> and i dunno how many ship depots 21:58:04 <peter1138> Have you tried any non-worst-case scenarios? 21:58:42 <peter1138> Things that seem very slow with your extreme cases are often quite acceptable in normal games. 21:59:24 <xarick> I got a save for that, a simple 1 depot, 1 ship on a 4k map 21:59:26 <xarick> let me test 21:59:35 <peter1138> I mean a normal save, not just one 🙂 21:59:42 <peter1138> 4k map is not very representative either. 22:00:06 <michi_cc[d]> ajmiles: Don't look at the newspaper window then 🙂 It draws everything and then uses GfxFillRect to overlay a anim/palette remap onto it that is special-coded in the 32bpp blitters to also affect RGB colors. 22:00:33 <michi_cc[d]> And all that just so you can have a year-appropriate bw newspaper image 🙂 22:00:44 <xarick> i also have a small map 64x64 with multiple depots 22:00:52 <xarick> about 4 depots 22:00:56 <ajmiles> Working newspaper is so far down the list of things to get working right now :awesome: 22:01:06 <xarick> 1 ship, but it's a maze like tiny 64x64 map 22:01:59 <peter1138> xarick: I just download a Reddit Server 1 game 🙂 22:02:22 <xarick> oh, is that how you get your test samples 🙂 22:02:34 <peter1138> Hmm, okay, Current one isn't very good for ships. 😦 22:02:39 <peter1138> Not always. 22:02:56 <peter1138> There's Wentbourne of course. And that 4kx4k save of yours that I lost. 22:03:19 <xarick> oh, wentbourne needs to switch breakdowns on 22:03:22 <xarick> let's try 22:05:10 <xarick> oh actually no need to enable breakdowns 22:05:48 <peter1138> I also test with smaller maps (e.g. 512x512) with some AIs. 22:06:00 <peter1138> Not exactly how players play, but... 22:06:42 <xarick> waiting for 1000 calls 22:07:12 <xarick> > [2024-02-24 22:06:59] dbg: [misc:0] [FindClosestReachableShipDepot, 1000] 81388 us [avg: 81.4 us] 22:07:12 <xarick> > [2024-02-24 22:06:59] dbg: [misc:0] [FindClosestShipDepot, 1000] 203579 us [avg: 203.6 us] 22:07:27 <xarick> this is with the unlimited range 22:07:29 <xarick> on both 22:07:47 <xarick> not sure if that's cheating 22:07:52 <xarick> since it favours my approach 22:09:08 <peter1138> What's the default range 80? 22:09:11 <xarick> yes 22:09:30 <peter1138> You could measure the performance of that too. 22:09:34 <xarick> 80 for his, 8000 equivalent for mine 22:10:11 <peter1138> And perhaps count how many result in no depot, because of the range limit. 22:10:23 <xarick> oh, that I'm not sure how to do 22:10:27 <xarick> with TicToc? 22:10:48 <peter1138> Not with TicToc. 22:13:45 <ajmiles> https://cdn.discordapp.com/attachments/1008473233844097104/1211073504988893316/Recording_2024-02-24_221234.mp4?ex=65ecdf18&is=65da6a18&hm=70c484ed687dbe2d0e4cc2f2473433014c1d9f05038d46c0e49912acc8cfffe7& 22:13:45 <ajmiles> OK, got it. Interleaving scrolls and sprite drawing fixed the shearing around towns/industries. 22:13:59 <peter1138> Nice music 22:14:10 <ajmiles> Ah sorry, didn't realise it picked that up 22:14:47 <peter1138> Open a window in the middle of the screen and scroll the viewport behind it. That's another good test of it. 22:15:28 <peter1138> Your "left third, middle third, right third" corresponds to the toolbar/statusbar. 22:16:20 <ajmiles> https://cdn.discordapp.com/attachments/1008473233844097104/1211074155831758949/Recording_2024-02-24_221609.mp4?ex=65ecdfb3&is=65da6ab3&hm=9e6b302fd72798a8ad75e799b81dc1dcdf448162790b9ab66753516042adb74e& 22:16:20 <ajmiles> Like that? 22:22:07 <xarick> waiting for 1000 22:24:18 <peter1138> Yup, that's the one. 22:26:07 <ajmiles> I'm done, right? 22:27:09 <ajmiles> https://cdn.discordapp.com/attachments/1008473233844097104/1211076881986621500/image.png?ex=65ece23d&is=65da6d3d&hm=d32a6cb562c4e9bb31c7ab3ad64391395f490d4c5d17f753133fa2dfc85b7282& 22:27:09 <ajmiles> Unless of course you try and draw a line... 22:27:58 <ajmiles> This is where I find out you want *diagonal* lines as well as vertical/horizontal ones 22:30:21 <peter1138> Yes. 22:30:33 <peter1138> A vertical/horizontal line is just a rectangle 😉 22:31:09 <ajmiles> Can we not just have the players turn their head until the diagonal line is vertical? 22:31:32 <peter1138> But for lines you should be able to just draw... a line? 22:31:46 <peter1138> Or at least a pair of triangles... 22:32:11 <peter1138> Just needs to be done in the right colour 🙂 22:32:14 <ajmiles> Is there a prescribed pattern for line rasterisation that matters? Does it have to match what today's blitters do exactly, or is a GPU line primitive close enough? 22:32:49 <peter1138> GPU line primitive should be fine I think./ 22:33:12 <peter1138> Nobody is expecting a pixelized line . 22:33:30 <michi_cc[d]> Diagonals lines are graphs and the link graph overlay I think. Don't think anyone would notice a different there. 22:33:49 <peter1138> Also: the current line drawing code is broken for even-width vertical/horizontal lines. They are not used much. 22:34:27 <michi_cc[d]> I think the bigger problem for GPU line primitves is that you want different thicknesses. 22:34:52 <ajmiles> Yeah, I just spotted the 'width' parameter... 22:34:59 <ajmiles> Two triangles it'll have to be 22:36:05 <ajmiles> Although in the interest of getting to the things that matter the most, I will probably just single pixel wide line prim everything for now 22:36:37 <ajmiles> I need to tackle the fact that alpha blending isn't going to work 22:37:43 <ajmiles> Oh, I've remembered one other question I had. Sprites can have RGBAM channels - do any need all 5? If so, I'll need to split RGBA off from M when that happens 22:38:03 <DorpsGek> [OpenTTD/OpenTTD] PeterN opened pull request #12174: Fix d3c673e: Don't defer OnResize() after ReInit() https://github.com/OpenTTD/OpenTTD/pull/12174 22:38:18 <michi_cc[d]> Yes, the M channel can be used to apply e.g. a company color remap to a RGB pixel. 22:38:29 <ajmiles> That also has alpha? 22:38:39 <michi_cc[d]> It is allowed at least. 22:38:48 <michi_cc[d]> No idea if anybody *used* it. 22:38:55 <peter1138> If it's possible, it's used. 22:40:21 <michi_cc[d]> But I don't think any of the 32bpp blitters actually handle that correctly in all cases as they resolve the M when doing alpha blending, so any further palette animation will not affect the pixel anymore. 22:40:28 <peter1138> There's also some weird blending possible that ends up darkening the remapped pixel. 22:40:49 <michi_cc[d]> 40bpp blitter is a bit different as it won't resolve the M channel until the video driver gets to it. 22:41:16 <ajmiles> I'm largely modelling what I'm doing after 40bpp-anim 22:42:00 <peter1138> Water slopes use palette animation along with darkening via the RGB parts to get darker/brighter palette animation. 22:44:01 <peter1138> https://cdn.discordapp.com/attachments/1008473233844097104/1211081125644996648/Screencast_from_2024-02-24_22-43-39.webm?ex=65ece631&is=65da7131&hm=b6c779b8700563eab7a5ee3e37c97186e51abbe3f18b5c7be779598a2d29fcbf& 22:44:01 <peter1138> It's magic which I didn't think worked, but it does 😄 22:44:19 <peter1138> (But it's not alpha channel) 22:45:56 <ajmiles> And in OpenTTD terminology, CRASH_REMAP refers literally to crashed vehicles? 22:46:13 <_glx_> it remaps with grey scale 22:46:26 <_glx_> primarily for crashed vehicles 22:46:26 <peter1138> Yes, it's a special case to draw crashed vehicles in a all dark grey. 22:46:33 <michi_cc[d]> Yeah, there's two different things. RGB can always be used to "tune" the M color (i.e. that shader blend formula) and still keep the palette animation. 22:46:58 <peter1138> (In original 8bpp mode that just a regular palette remap, but they don't work with 32bpp sprites, so we added the special case) 22:47:37 <_glx_> yeah in 8bpp you just change the RGB value for a given index 22:47:47 <michi_cc[d]> It can also be used to apply a M -> M remap (for stuff like company colours). That one happens at blitting time and is fixed. This remap can also be on a partially transparent pixel. 22:48:23 <peter1138> The contortions we've done to continue supporting the mostly 8bpp graphics 😄 22:48:40 <michi_cc[d]> So alpha blending with M is a blitter things, and palette animations a video driver thing where there is no more alpha. 22:50:01 <michi_cc[d]> The one limitation of the 32bpp blitters is that if you apply alpha blending to a M color, it will be converted to RGB and you loose the possibility to later do palette animation. The 40bpp blitters keeps the M as long as possible. 22:50:13 <michi_cc[d]> Water slopes are opaque, so this limitation does not apply. 22:51:09 <ajmiles> That was the mistake I made earlier today when the water animation wasn't working. As I was going through it, I saw less and less need for the anim buffer at all, I could just resolve M to RGB at blit-time and deal only with DST. 22:51:32 <ajmiles> Alas, the water was then static because it had an M of 0 and a valid RGB in DST 22:52:22 <ajmiles> So 'anim' is back and retained as long as it is for the 40bpp blitter 22:52:32 <peter1138> Nice 22:52:52 <ajmiles> But any hope I had that I could alpha blend is now gone, I can't alpha blend onto colours that are represent only as dst=0, anim=m 22:53:34 <ajmiles> It's almost like there's a reason there isn't already a GPU blitter 22:54:24 <peter1138> Maybe resolve M to RGB at blit-time as well? Then you can alpha blend onto that. 22:55:04 <ajmiles> How do I then decide whether to respect RGB or M at the end? 22:56:10 <michi_cc[d]> If there's an M, the current opengl shader apply the remap, which is basically something close to "take colour from M and lightness from RGB". 22:56:52 <michi_cc[d]> Well, not really lightness or value (i.e. HSV/HSL), but something similar. 22:56:55 <_glx_> IIRC M typically contains company colours and company colours 2 23:02:36 <xarick> https://cdn.discordapp.com/attachments/1008473233844097104/1211085803308974170/image.png?ex=65ecea8c&is=65da758c&hm=73c6ea3d7990cb9a02a1b3220ca8d708fb0d9f4d2a28bca4b09111183fb05113& 23:02:36 <xarick> mediocre debugging skills! 23:02:59 <xarick> i fail more 23:03:04 <xarick> than kuhnovic 23:03:11 <xarick> at 80/8000 23:04:15 <xarick> what explanation do i have for this... 23:06:10 <xarick> one possibility is cost of curves 23:07:00 <xarick> tile costs, turn costs, aqueduct costs, everything is accounted for in that 8000 23:09:33 <xarick> need to test with unlimited range 23:15:10 *** keikoz has quit IRC 23:16:10 <xarick> kek... 23:16:33 <xarick> https://cdn.discordapp.com/attachments/1008473233844097104/1211089311168991272/image.png?ex=65ecedd0&is=65da78d0&hm=6cbf7b366b4bea20c6af51b53481fcadfd68efcd069907a75423cf24c82e08b7& 23:16:33 <xarick> not sure why I tested this... 23:16:37 <xarick> 0 fails 23:16:40 <xarick> obviously 23:22:03 *** Wolf01 has quit IRC 23:23:41 <xarick> my bed is waiting for me, cyas goodnight 23:44:44 *** tokai|noir has joined #openttd 23:44:44 *** ChanServ sets mode: +v tokai|noir 23:51:36 *** tokai has quit IRC