Times are UTC Toggle Colours
00:09:36 *** APTX has joined #openttd 00:37:12 <DorpsGek> [OpenTTD/OpenTTD] PeterN commented on issue #13854: [Bug]: Recoloured 32bpp sprites seem to lose their alpha channel https://github.com/OpenTTD/OpenTTD/issues/13854 00:47:04 <peter1138> Probably ought to sleep. 01:00:00 *** Flygon has joined #openttd 02:31:08 *** Wormnest has quit IRC 03:10:35 *** WormnestAndroid has quit IRC 03:10:36 *** WormnestAndroid has joined #openttd 03:10:53 *** WormnestAndroid has joined #openttd 03:11:08 *** WormnestAndroid has joined #openttd 03:59:00 *** D-HUND has joined #openttd 03:59:30 *** geizeskrank has quit IRC 04:02:23 *** debdog has quit IRC 04:03:03 *** geizeskrank has joined #openttd 04:16:27 *** D-HUND is now known as debdog 04:24:11 <DorpsGek> [OpenTTD/OpenTTD] goingafk commented on issue #13714: [Bug]: Numeric value in bank construction failure message is not localized https://github.com/OpenTTD/OpenTTD/issues/13714 05:12:40 *** keikoz has joined #openttd 05:41:01 <DorpsGek> [OpenTTD/OpenTTD] Release workflow was not successful https://github.com/OpenTTD/OpenTTD/actions/runs/13962529065 06:52:43 *** keikoz has quit IRC 07:56:05 *** keikoz has joined #openttd 08:00:03 <DorpsGek> [OpenTTD/OpenTTD] LordAro commented on issue #13714: [Bug]: Numeric value in bank construction failure message is not localized https://github.com/OpenTTD/OpenTTD/issues/13714 08:50:59 *** mindlesstux has quit IRC 08:51:25 *** mindlesstux has joined #openttd 08:56:25 *** mindlesstux has quit IRC 08:57:02 <DorpsGek> [OpenTTD/OpenTTD] PeterN opened pull request #13855: Codechange: Use emplace_back instead of push_back. https://github.com/OpenTTD/OpenTTD/pull/13855 08:57:13 *** mindlesstux has joined #openttd 09:00:30 <peter1138> Hmm 09:01:44 <peter1138> So previously to use emplace_back I've had to ensure there was a suitable constructor. Apparently there isn't the case here. I don't know what's different. 09:10:42 <xarick> hi 09:11:05 <xarick> power went off... that was the end of my tests 09:11:43 <peter1138> I need to reboot my server at some point, it has 648 days uptime. 09:14:37 <xarick> there was thunder and heavy winds and rain 09:14:47 <xarick> what a weak place 09:18:28 <xarick> 5.5 GB ram used to load the savegame 09:22:15 <xarick> let's see if i can load this in debug mode 09:23:08 <xarick> what would happen if i tried to load this on a 32 bit openttd? 09:25:58 <xarick> https://cdn.discordapp.com/attachments/1008473233844097104/1352211556909191178/image.png?ex=67dd30a6&is=67dbdf26&hm=c20124ff63d6fcff430354f9a7da6206bf76b1fa3c9bb92cee2357a3ddf60ec3& 09:26:44 <xarick> and now it's unloading some from ram 09:27:16 <xarick> https://cdn.discordapp.com/attachments/1008473233844097104/1352211885860196393/image.png?ex=67dd30f4&is=67dbdf74&hm=0ef7a7deee36951d44031c04949e9469cb8ea392db7f9c005999abc0941b351c& 09:28:44 <xarick> https://cdn.discordapp.com/attachments/1008473233844097104/1352212251829997588/image.png?ex=67dd314b&is=67dbdfcb&hm=c6e9ce7700f7d5c524c503df0784a323244ef13ed282870bf8482a0efe7a418d& 09:28:44 <xarick> and... it loaded 09:29:16 <xarick> ~74k-ish trains 09:45:49 *** jfkuayue has joined #openttd 09:45:49 <jfkuayue> Lol, platform change announcement 3 mins before departure 09:57:03 <peter1138> Yeah, you won't be able to use that much RAM there :) 10:03:02 <xarick> ScriptList::FillList is the heaviest function 10:03:15 <xarick> ScriptVehicleList_Group::ScriptVehicleList_Group 10:03:51 <xarick> oh... right, it's iterating all vehicles 10:08:10 <xarick> let me look at all pools, see if any limit was reached 10:08:46 <peter1138> That's why the valuator filter constructor thing was added. 10:09:22 <peter1138> Although with that many vehicles it will still take time. 10:17:14 <xarick> https://cdn.discordapp.com/attachments/1008473233844097104/1352224459968483379/image.png?ex=67dd3caa&is=67dbeb2a&hm=74fe59395ab2e644abff2b909eb8c97cd9e0022c075a4c2e028f09e2bf749fe5& 10:18:31 <xarick> impressed by orderlist 10:18:47 <xarick> really good usage of shared orders I bet 10:19:24 <DorpsGek> [OpenTTD/OpenTTD] zephyris commented on issue #13854: [Bug]: Recoloured 32bpp sprites seem to lose their alpha channel https://github.com/OpenTTD/OpenTTD/issues/13854 10:23:43 *** HerzogDeXtEr has joined #openttd 10:28:29 <DorpsGek> [OpenTTD/OpenTTD] nielsmh commented on discussion #13498: RFC: Inter-Company Permissions https://github.com/OpenTTD/OpenTTD/discussions/13498 10:37:05 <DorpsGek> [OpenTTD/OpenTTD] nielsmh commented on issue #13714: [Bug]: Numeric value in bank construction failure message is not localized https://github.com/OpenTTD/OpenTTD/issues/13714 10:44:26 <DorpsGek> [OpenTTD/OpenTTD] PeterN commented on issue #13854: [Bug]: Recoloured 32bpp sprites seem to lose their alpha channel https://github.com/OpenTTD/OpenTTD/issues/13854 10:45:40 <xarick> can vehicles with shared orders be in different groups? 10:46:57 <DorpsGek> [OpenTTD/OpenTTD] zephyris commented on issue #13854: [Bug]: Recoloured 32bpp sprites seem to lose their alpha channel https://github.com/OpenTTD/OpenTTD/issues/13854 11:07:54 <DorpsGek> [OpenTTD/OpenTTD] PeterN commented on issue #13854: [Bug]: Recoloured 32bpp sprites seem to lose their alpha channel https://github.com/OpenTTD/OpenTTD/issues/13854 11:08:47 <LordAro> _zephyris: iirc -d1 lists the blitter used 11:09:37 <peter1138> videodriver = "sdl:no_mouse_capture" 11:09:47 <peter1138> That's why I don't get 40bpp-anim :) 11:10:49 <peter1138> Hmm 11:11:09 *** peter1138[d] has joined #openttd 11:11:09 <peter1138[d]> https://cdn.discordapp.com/attachments/1008473233844097104/1352238026406891580/image.png?ex=67dd494c&is=67dbf7cc&hm=a66007f1074feab8ab3983fdba048821faa2d83d1a318e8b0be7657213464c35& 11:11:12 <peter1138[d]> This is not right 🙂 11:12:01 <peter1138> So the line does something. 11:14:22 <peter1138> Might need to be an else. 11:14:46 <peter1138> Nope. 11:15:33 <peter1138> What if we shouldn't be looking at *anim at all, becuase it's make to be greyscale. 11:16:01 <peter1138> Nope. 11:17:17 <peter1138> Okay, well whatever, it's a 40bpp-anim opengl-only issue. 11:18:35 <_zephyris> https://cdn.discordapp.com/attachments/1008473233844097104/1352239900082307193/image.png?ex=67dd4b0b&is=67dbf98b&hm=4564543a7aa4cb524d95370a89129a32036dc27185904b63a55c4c84edb5036d& 11:18:35 <_zephyris> I'm super confused... The auto-selected blitter is 32bpp-anim (as you'd expect). Buggy. Manually set 32bpp-anim in the config, no bug. 11:19:45 <peter1138> [2025-03-20 11:19:30] dbg: [driver:1] Successfully loaded blitter '32bpp-anim' 11:19:49 <peter1138> [2025-03-20 11:19:31] dbg: [driver:1] Switching blitter from '32bpp-anim' to '40bpp-anim'... 11:20:11 <peter1138> You are a probably not looking at the second line which will be further down. 11:23:25 <_zephyris> 👍 11:23:32 <_zephyris> 40bpp-anim 11:24:59 <_zephyris> Crap, can't do 40bpp-anim with WSL 11:25:29 <peter1138> It's a combination of 32bpp/8bpp/alpha and colour mapping rect not having the right information. 11:30:19 <peter1138> There's some funky shit going on with compositing. 11:31:42 <peter1138> e.g. _frag_shader_sprite_blend_150 knows about the crash palette, but not the b&w palette 11:34:44 <peter1138> (I have no idea what sets the 'crash' variable there.) 11:35:52 <_zephyris> Is it something about a double recolour? 11:36:24 <_zephyris> The background being recoloured to company colour, then grey. The face just being recoloured grey? 11:36:40 <peter1138> Kinda. 11:37:01 <peter1138> You know how sloped rivers can have palette animation despite being shaded? 11:37:13 <_zephyris> Yeah... 11:37:13 <peter1138> It's related to that. 11:41:50 <peter1138> The blitter stores the RGBA, and the animated pixel index, and the shader does magicc to it. 11:42:08 <peter1138> DrawColourMappingRect dosn't take account ofd that magic. 11:47:26 <xarick> group vehicle lists again? 11:49:11 <xarick> shall i revisit this? 11:50:38 <peter1138> No. 11:51:11 <_zephyris> `if (*anim == 0) *udst = MakeGrey(*udst);` vs. `*udst = MakeGrey(*udst);`? 11:52:01 <xarick> 😄 11:54:17 <_zephyris> Oh, sorry, missed the other differences 11:55:07 <_zephyris> But the river slope shading works in all the 32bpp shaders afaik 12:01:15 <peter1138> Yeah, I didn't mean that's the problem, I mean the system that allows that is part of the reason why this issue is appearing. 12:03:59 <xarick> https://cdn.discordapp.com/attachments/1008473233844097104/1352251322732384326/image.png?ex=67dd55ae&is=67dc042e&hm=813651db8fc957da6014636e0eb4db00af3680f26a5b79cdd0d48a40d0b1b4d4& 12:03:59 <xarick> a group vehicle list build from 2024 still faster than current 15.0-beta1 12:09:01 <xarick> ugh so much has changed, can't properly rebase this quickly 12:09:42 <_zephyris> I can rephrase my question... 12:11:09 <_zephyris> Err, maybe I can't 12:12:01 <_zephyris> I'm confused why the 40bpp_anim blitter has extra code for handling (presumably) animated pixels in the newspaper remap when they should just be recoloured to non-animated grey? 12:12:49 <peter1138> The anim buffer actually contains the 8bpp palette index, whether it's animated or not. 12:13:25 <DorpsGek> [OpenTTD/OpenTTD] frosch123 updated pull request #13811: Fix: NewGRF string interpolation did not process all string parameters, if certain string control codes were present. https://github.com/OpenTTD/OpenTTD/pull/13811 12:14:41 <DorpsGek> [OpenTTD/OpenTTD] PeterN approved pull request #13811: Fix: NewGRF string interpolation did not process all string parameters, if certain string control codes were present. https://github.com/OpenTTD/OpenTTD/pull/13811#pullrequestreview-2702478187 12:22:47 <xarick> https://cdn.discordapp.com/attachments/1008473233844097104/1352256056411029616/image.png?ex=67dd5a17&is=67dc0897&hm=c9924ec0525cbb951ac19aebf55bd123c652a8e91ef9f26e3a44bf8e6f702a30& 12:22:47 <xarick> hmm 12:24:29 <xarick> too much conflicts 12:24:46 <xarick> okay... lunch, afk 12:43:42 <peter1138> 11:50 < peter1138> No. 13:28:36 <xarick> the simple act of loading a savegame 13:28:39 <xarick> https://cdn.discordapp.com/attachments/1008473233844097104/1352272630140633241/image.png?ex=67dd6987&is=67dc1807&hm=941ca33c5b8f095d528e4acbe403ed5436a4c71385adcd10e3ca0a58b5fff854& 13:32:15 <xarick> https://cdn.discordapp.com/attachments/1008473233844097104/1352273535737008221/image.png?ex=67dd6a5e&is=67dc18de&hm=f8a6e68f843e1799d0fffd0b8a9bc36f2f44738af495c33b903dce3c6f3e1de8& 13:32:15 <xarick> hot path 13:34:34 *** WormnestAndroid has quit IRC 13:34:35 *** WormnestAndroid has joined #openttd 13:37:52 <xarick> AIPLChunkHandler::Load 13:45:27 <xarick> funny, the slowest part of loading vehicle chunks was cargo packets 13:49:52 <xarick> on Train::Tick 13:50:04 <xarick> the heaviest function was CheckTrainCollision 13:50:34 <xarick> https://cdn.discordapp.com/attachments/1008473233844097104/1352278146648506459/image.png?ex=67dd6eaa&is=67dc1d2a&hm=ec17a439ef33da4b4bb063b621ddd472ba098086e6397a3441ba8ef87ae27c5f& 13:51:01 <xarick> this is looking into hashes 13:52:35 <peter1138> What's your train length again? 13:53:37 <xarick> FindTrainCollideEnum 13:53:44 <xarick> in this test it was 6 tiles 13:54:05 <peter1138> Okay, 15 companies with 5000 trains with 12 parts is 900,000 vehicles. 13:54:46 <peter1138> The hash size is 7 bits per axis, so 128x128 to 16384 buckets. 13:55:08 <peter1138> There are then, on average 54 vehicles per buckets. 13:56:01 <peter1138> But collisions occur across tiles. 13:56:06 <peter1138> So you need to check 4 buckets. 13:56:12 *** exceptik has joined #openttd 13:56:12 <exceptik> and that's without breaking the game with 100 companies 13:56:41 <peter1138> So every time a train moves, it needs to check if 216 other vehicles are in the way. 13:56:55 <peter1138> You have 75,000 trains doing this, per tick. 13:58:17 <peter1138> This algorithm was never designed for that many. 13:58:42 <xarick> https://cdn.discordapp.com/attachments/1008473233844097104/1352280192659488828/image.png?ex=67dd7092&is=67dc1f12&hm=ac7eec6336cec3aa223b207a62943ee5e48da19d2a1ebdd6e4940aa04e4feeb5& 13:58:42 <xarick> this is the hotest part 13:59:47 <exceptik> its just the most common path. not necessarily the slowest path 14:02:45 <peter1138> Increase HASH_BITS, 8 bits will reduce the collisions to 13, 9 bits will reduce to 3. 14:03:21 <peter1138> Caveats: the hash doesn't using a hash algorithm, it simply wraps the tile values. 14:03:47 <peter1138> This means that long straight lines, all aligned, will result in more collisions. 14:05:19 <peter1138> I tested something else once, I wonder what happened to that patch. 14:09:41 <xarick> testing 8 14:12:36 <xarick> 330 ms train ticks, that's better 14:12:52 <xarick> can't remember what it was before, let me check 7 bits 14:16:44 <xarick> 715 ms 14:17:02 <xarick> let's see with 9 bits 14:20:24 <xarick> 206 ms 14:20:36 <xarick> how large can HASH_BITS be? 14:25:28 <xarick> this is fantastic, changing one number and the game does faster 14:27:04 <xarick> 10 bits - 178 ms 14:31:20 <xarick> 11 bits - 171 ms 14:35:27 <xarick> 12 bits - 173 ms 14:35:31 <xarick> guess we reached the limit 14:41:37 <peter1138> I will say, that size was chosen 18 years ago. 14:41:56 <peter1138> bc 14:42:03 <peter1138> 2007 :) 14:42:46 <peter1138> Not sure how much memory I had then, no more than 2GB certainly. 14:43:01 *** Wormnest has joined #openttd 14:44:06 <peter1138> Could well have been 256-512MB. 14:45:01 *** kuhnovic has joined #openttd 14:45:01 <kuhnovic> You probably weren't running any 4K maps back then either 14:45:51 <peter1138> No, that came in 2014. 14:46:58 <peter1138> 9 bits is funny because it's larger than a complete 256x256 map. 14:47:28 * peter1138 ponders. 14:48:31 *** nielsm has joined #openttd 15:01:13 <xarick> oh, got a crash 15:01:20 <xarick> 12 bits = crash 15:01:56 <xarick> 11 bits = crash 15:02:28 <xarick> 10 bits = crash... what is going on? 15:03:36 <xarick> 9 bits = crash 15:03:43 <xarick> only 8 bits does not crash 15:05:00 <xarick> my enthusiasm is gone 15:06:49 <xarick> oh, vehicle viewport hash 15:06:53 <xarick> there's more hashes 15:07:16 <peter1138> The viewport hash is what it says it is. 15:09:48 <xarick> https://cdn.discordapp.com/attachments/1008473233844097104/1352298087049072730/image.png?ex=67dd813c&is=67dc2fbc&hm=3d94ead810ee124bc1f34043e61dca24b149b1cca99f5a21cd594c49c569ff2e& 15:09:48 <xarick> needs bigger number 15:15:31 <peter1138> Viewport hash affects drawing, so doesn't really affect the game loop time. 15:18:04 <xarick> EXCEPTION_STACK_OVERFLOW 15:20:25 <xarick> ResetVehicleHases causing this 15:20:29 <xarick> t.t 15:24:13 *** kuka_lie has joined #openttd 15:27:35 <xarick> https://cdn.discordapp.com/attachments/1008473233844097104/1352302560203243530/crash20250320152647.json.log?ex=67dd8566&is=67dc33e6&hm=e43f6d2e9410faddc584dbbacba85862aad7c66c30400389cf3855011ebd537c& 15:31:39 <peter1138> Hmm, oh, is it creating an array on the stack and then copying it... 15:36:16 <peter1138> Well, replace those ` = {}` with `.fill(nullptr)` 15:37:43 <xarick> yay, it boots 15:40:29 <xarick> tested with 11 bits, it boots 15:48:37 <xarick> https://cdn.discordapp.com/attachments/1008473233844097104/1352307856082206760/image.png?ex=67dd8a55&is=67dc38d5&hm=520f1fa6a282b629d3b96d6e9a05e5e06a9cddfe28cf7175a6ca97fda7eb195d& 15:48:37 <xarick> is that 33 Megabytes? 15:48:44 <xarick> wow 15:49:02 <xarick> even for a 64x64 map? 15:49:42 <peter1138> 11 bit hash. 15:49:42 <peter1138> Yes. 15:49:54 <peter1138> 2^(11*2)*8 = 33MiB. 15:50:07 <peter1138> For a 7 bit hash, it's 128KiB. 15:50:16 <peter1138> This is why it's stuck at 7 bits. 15:50:41 <peter1138> 8 or 9 bits are much larger but still reasonable. 15:50:48 <peter1138> But still larger than a smaller map. 15:52:11 <peter1138> You could halve the size by storing `VehicleID` instead of `Vehicle *` 15:53:06 *** _jgr_ has joined #openttd 15:53:06 <_jgr_> It would probably make more sense to not use a fixed-size hash table, instead of making it even bigger 15:57:42 <peter1138> Sure, but in terms of a simple "something to speed up Xarick's silly test" this is a quick thing he can do. 15:57:46 <peter1138> (And then find bugs in...) 16:06:53 <xarick> hmm can't do the transtition to VehicleID 😦 16:25:55 *** frosch123 has joined #openttd 16:25:55 <frosch123> Poll: do we care whether OpenGFX1 builds with gimp2? 16:25:55 <frosch123> Currently it only builds with gimp2 and fails with gimp3. We have a PR to inverse that: fail with gimp2, succeed with gimp3. 16:25:55 <frosch123> I do not fancy adding gimp version detection and conditions to the Makefile. 16:27:54 <frosch123> Is heffer still on IRC? 16:29:52 *** frosch12 has joined #openttd 16:30:09 <xarick> https://cdn.discordapp.com/attachments/1008473233844097104/1352318306882949243/image.png?ex=67dd9411&is=67dc4291&hm=cf207d8796cacc41b61f6a75862fa7ef7928ea53cc431f6268edec4758feab5d& 16:30:09 <xarick> well well! 162 ms 16:30:10 <peter1138> I don't have gimp3. 16:30:19 <frosch12> @seen heffer 16:30:31 <xarick> VehicleID and 10 bits HASH_BITS 16:30:45 <peter1138> It was only released 4 days ago, so requiring it, when Linux eco-systems don't work that way, is a bit annoying. 16:31:10 <Rubidium> I'd say, if the gimp2 -> gimp3 conversion is one or a few subsequent commits it'd be easy to just revert those commits for whatever distro needs that 16:31:23 *** frosch12 has quit IRC 16:31:55 <Rubidium> peter1138: the alternative is that there is no OpenTTD in distros that want to build everything from source 16:32:17 <Rubidium> it's already been booted from the next Debian release exactly due to that 16:32:56 <peter1138> Sure. I only say it's a bit annoying, not that it shouldn't be done. 16:48:37 <peter1138> I am unlikely to ever want to build, so never mind me :) 17:01:20 <xarick> VehicleID hashes are faster 17:01:27 <xarick> just by being VehicleID 17:06:34 <_zephyris> Doesn't _need_ gimp to build anyway, just if you want to update from the (very incomplete) multi-layer gimp sources. 17:07:00 <_zephyris> Which bit isn't built from source that debian is unhappy about? 17:09:41 <xarick> https://cdn.discordapp.com/attachments/1008473233844097104/1352328254656090233/image.png?ex=67dd9d54&is=67dc4bd4&hm=30faeaa7dd84e4e94fc8611640e60873cf9776be379de503d442f279e95e17fb& 17:09:41 <xarick> oopsie, the trains are invisible 17:11:03 *** Flygon has quit IRC 17:14:33 <xarick> oh, i tihnk i know why 17:14:55 <peter1138> If the hash is not used properly that can make it much faster, yes :) 17:17:30 <xarick> const Vehicle *v what's this? 17:17:33 <Rubidium> _zephyris: with gimp3 the build script for those gimp sources doesn't work anymore, and the rule for debian packaging is to build everything from the 'root'-source. 17:18:35 <_zephyris> Ok 17:18:49 <_zephyris> (So fonts may be an issue, if anyone notices) 17:19:22 <xarick> there's a const *v <https://github.com/OpenTTD/OpenTTD/blob/master/src/vehicle.cpp#L1183>, but line 1225 sets v to another vehicle. Is this even working? 17:22:16 <peter1138> _zephyris, should be fine, the .sfd is the source, the .ttf is the compiled output. 17:23:15 <peter1138> At some point the source requires creating by a person, source doesn't necessarily mean code. 17:23:42 <_zephyris> Fair enough... I was wondering about it not having a proper build process and being vendored into ottd though. 17:25:14 <peter1138> Hmm. 17:25:31 <peter1138> Fiddle with synths/code or ride? 17:29:09 <Rubidium> yes! :D 17:34:28 <exceptik> xarick: constant pointer vs pointer to constant 17:35:45 <DorpsGek> [OpenTTD/OpenTTD] rubidium42 approved pull request #13855: Codechange: Use emplace_back instead of push_back. https://github.com/OpenTTD/OpenTTD/pull/13855#pullrequestreview-2703590374 17:38:37 <DorpsGek> [OpenTTD/OpenTTD] PeterN opened pull request #13856: Codechange: Use template traits to define BaseSets. https://github.com/OpenTTD/OpenTTD/pull/13856 17:39:14 <DorpsGek> [OpenTTD/OpenTTD] PeterN merged pull request #13855: Codechange: Use emplace_back instead of push_back. https://github.com/OpenTTD/OpenTTD/pull/13855 17:43:07 <xarick> i fail at pointers and references 17:43:14 <xarick> probably why this doesn't work 17:45:17 <andythenorth> what is a pointer? 17:45:22 <andythenorth> isn't it just a memory location? 17:45:48 <andythenorth> I've never used them, but I assumed it was an index into either all memory, or a block of memory 17:48:56 <peter1138> xarick, each bucket contains multiple vehicles. v starts at the root bucket, and then continues to the next vehicle in the bucket, which is stored as a linked-list using the vehicle itself. 17:49:30 <peter1138> v is just a pointer, changing it doesn't change the thing that was pointing at it originally. 17:56:50 <_glx_> And it's `const` so you don't change the object pointed 18:02:22 <xarick> can't modify this to VehicleID 18:02:27 <xarick> i thought I could 18:05:49 <peter1138> So your faster VehicleID hash was... something else? 18:07:18 <xarick> yeah... 18:07:21 <xarick> my bad 18:08:06 <peter1138> Ok, my back and knees say no to cycling. 18:08:15 <peter1138> (Also should've left an hour ago if I was) 18:08:28 <xarick> I don't understand Vehicle **new_hash; stuff 18:08:46 <peter1138> It's a pointer to a pointer. 18:09:07 <peter1138> 17:49 < peter1138> v is just a pointer, changing it doesn't change the thing that was pointing at it originally. 18:09:16 <peter1138> With a pointer to a pointer, you CAN. 18:14:00 <DorpsGek> [OpenTTD/OpenTTD] rubidium42 commented on pull request #13856: Codechange: Use template traits to define BaseSets. https://github.com/OpenTTD/OpenTTD/pull/13856#pullrequestreview-2703675178 18:14:49 <frosch123> Looks like changing GetStringPtr and friends to return string_view is viable: 22 files changed, 331 insertions, 196 deletions 18:14:49 <frosch123> It just needs to stop asserting :p 18:19:46 <xarick> https://cdn.discordapp.com/attachments/1008473233844097104/1352345892728078346/image.png?ex=67ddadc2&is=67dc5c42&hm=6bd932c0d9464c8054bba41779085bd018ae5f58b1d7814f4af36c5415a82a28& 18:19:46 <xarick> i guess I only have these 2 changes to satisfy myself 18:21:14 <peter1138> +331-196 is a bit, hmm. 18:22:04 <peter1138> Hmm, compilers :D 18:22:40 <peter1138> Ah, more like platforms. 18:23:08 <xarick> how fast does this get with CheckTrainCollisions returning false 18:25:02 <xarick> https://cdn.discordapp.com/attachments/1008473233844097104/1352347217914101850/image.png?ex=67ddaefe&is=67dc5d7e&hm=f71d72e0174ddf86280ed42ed8c2b8f0c2c713cc9735ba2958750fcf83dd718c& 18:27:52 <xarick> https://cdn.discordapp.com/attachments/1008473233844097104/1352347931533119579/image.png?ex=67ddafa8&is=67dc5e28&hm=62375607967c04ad01a3aafeed917c463932c08ac34f638e6c81a11ccb2cf7c9& 18:27:52 <xarick> false collisions and 7 hash_bits 18:28:12 <xarick> so CheckTrainCollision eats performance 18:28:15 <xarick> now I know 18:29:57 <xarick> https://cdn.discordapp.com/attachments/1008473233844097104/1352348454697046036/image.png?ex=67ddb025&is=67dc5ea5&hm=349131d732cee782531d5acdc4d078bd3c89925ee5830b69b6063458fa0604a3& 18:29:57 <xarick> untouched master 18:34:59 <xarick> https://cdn.discordapp.com/attachments/1008473233844097104/1352349722098012211/image.png?ex=67ddb153&is=67dc5fd3&hm=edcf6930df461c078a50e0a9dfb2818a4b44866029180c96565f02f3cb223f7c& 18:34:59 <xarick> just 11 hash_bits 18:36:23 <xarick> PR? 😛 18:37:04 <peter1138> Hmm, coding-style wise, do I need `BaseSet<T>::NUM_FILES` or `BaseSet::NUM_FILES`. 18:37:40 <DorpsGek> [OpenTTD/OpenTTD] 2TallTyler commented on discussion #13498: RFC: Inter-Company Permissions https://github.com/OpenTTD/OpenTTD/discussions/13498 18:38:58 <xarick> you mentioned x or y would wrap back, where does that happen? 18:40:27 <xarick> from 11 to 10, the loss is negligible, to be honest 18:40:37 <xarick> 177 ms 18:42:01 *** tokai|noir has joined #openttd 18:42:01 *** ChanServ sets mode: +v tokai|noir 18:42:16 <DorpsGek> [OpenTTD/OpenTTD] PeterN updated pull request #13856: Codechange: Use template traits to define BaseSets. https://github.com/OpenTTD/OpenTTD/pull/13856 18:45:20 <xarick> error C2148: total size of array must not exceed 0x7fffffff bytes 18:45:29 <xarick> does not like 14 18:45:53 <LordAro> your system probably wouldn't like 14 18:45:54 <xarick> 13 is the max allowed 18:46:16 <peter1138> That's larger than the map anyway. 18:47:17 <andythenorth> was it lunch? 18:47:50 *** belajalilija has joined #openttd 18:47:50 <belajalilija> baby dont hurt me 18:48:25 <andythenorth> lyric confusion 18:48:47 <xarick> can I convice someone at openttd to 10 hash_bits 🙂 18:49:03 *** tokai has quit IRC 18:49:29 <peter1138> What, 10 times larger than the standard map? 18:50:33 <peter1138> 15:53 < _jgr_> It would probably make more sense to not use a fixed-size hash table, instead of making it even bigger 18:50:34 <xarick> https://cdn.discordapp.com/attachments/1008473233844097104/1352353645148241941/image.png?ex=67ddb4fa&is=67dc637a&hm=09aae8b5ae8262212718c2cb91ba29524abd348f0b4da3e494c8be919fd80128& 18:50:52 <belajalilija> andythenorth: were you going for more howard jones and not haddaway? 18:51:52 <xarick> oh, a map size based hash table? 18:56:37 <xarick> Copilot suggests me to use std::unordered_map, boost::unordered_map or std::map 18:57:01 <xarick> what is boost? 18:58:30 <andythenorth> lots of num utilities no? 18:59:51 <andythenorth> I think it mostly existed to prevent mySQL building reliably around about 2008 😛 19:00:04 <andythenorth> we had an office and "Boost is broken again" was a common thing 19:01:16 <peter1138> Yeah, don't use boost. 19:18:14 <DorpsGek> [OpenTTD/OpenTTD] PeterN updated pull request #13856: Codechange: Use template traits to define BaseSets. https://github.com/OpenTTD/OpenTTD/pull/13856 19:22:54 <Rubidium> I wonder whether just replacing the vehicle tile hash with just a simple vector indexed by tile isn't faster for maps with loads of vehicles. When searching an area, you'll only need to dereference vehicles that are definitely in the area (instead of an area with the same hash somewhere else) and the chains to skip through will be smaller as well 19:23:40 <DorpsGek> [OpenTTD/OpenTTD] PeterN updated pull request #13856: Codechange: Use template traits to define BaseSets. https://github.com/OpenTTD/OpenTTD/pull/13856 19:25:43 <DorpsGek> [OpenTTD/OpenTTD] 2TallTyler closed issue #13714: [Bug]: Numeric value in bank construction failure message is not localized https://github.com/OpenTTD/OpenTTD/issues/13714 19:25:46 <DorpsGek> [OpenTTD/OpenTTD] 2TallTyler commented on issue #13714: [Bug]: Numeric value in bank construction failure message is not localized https://github.com/OpenTTD/OpenTTD/issues/13714 19:27:44 <peter1138> Rubidium, might as well add it to the map ;-) 19:27:56 <_jgr_> A tile is 12 bytes, so using a third of that again just for an index seems a bit of a pessimisation 19:28:20 <_jgr_> Even a crummy hash table like std::unordered_map would be better 19:28:49 <peter1138> Yeah, remember this is only a problem here because he has ~900,000 trains... 19:34:36 <frosch123> Obviously you should use a k-d-tree or r-tree 19:38:52 <frosch123> Also, I was reminded of Samu, when I read this today: https://arstechnica.com/ai/2025/03/ai-coding-assistant-refuses-to-write-code-tells-user-to-learn-programming-instead/ 19:45:59 <peter1138> Hmm, this code doesn't work now anyway :o 19:52:38 <andythenorth> did your AI write it? 19:53:09 <xarick> kdtree 19:55:54 <andythenorth> peter1138: "at least 900,000"? 19:56:57 <exceptik> peter1138: Can someone imagine a multiplayer game with this chaos 😆 20:04:32 <DorpsGek> [OpenTTD/OpenTTD] michicc commented on issue #13854: [Bug]: Recoloured 32bpp sprites seem to lose their alpha channel https://github.com/OpenTTD/OpenTTD/issues/13854 20:09:19 <peter1138> Hmm. 20:10:24 <_zephyris> That was my first thought 20:11:02 <_zephyris> But because WSL doesn't work with the 40bpp blitter couldn't test. 20:12:40 <DorpsGek> [OpenTTD/OpenTTD] PeterN commented on pull request #13856: Codechange: Use template traits to define BaseSets. https://github.com/OpenTTD/OpenTTD/pull/13856#issuecomment-2741556099 20:12:49 *** Wolf01 has joined #openttd 20:13:44 *** michi_cc has joined #openttd 20:13:44 <michi_cc> _zephyris: 40bpp blitters needs enabled (and working) hardware acceleration, i.e. OpenGL. No idea if that is something to enable somegwhere in WSL. 20:14:50 <peter1138> I did try retaining alpha but with no luck. I'll try again. 20:17:04 <_zephyris> I'm confused by why the 40bpp blitter needs different handling to the 32bpp blitter here: https://github.com/OpenTTD/OpenTTD/blob/89948b941bea7f6ebc4b2d2a03d080e8630862b4/src/blitter/40bpp_anim.cpp#L381 20:18:27 <peter1138[d]> https://cdn.discordapp.com/attachments/1008473233844097104/1352375759842316408/image.png?ex=67ddc993&is=67dc7813&hm=27e4345025d90d50bed26d41314a08636aa95b97611c7bfcbb45d3352a0ed40f& 20:18:36 <peter1138[d]> Simply retaining the alpha does not work 🙂 20:19:57 <peter1138> _zephyris, basically the 40bpp blitter does something like hardware accelerated colour remapping. 20:20:12 <peter1138> It's done in shaders. 20:20:20 <peter1138> Plain 32bpp does not. 20:21:08 <_zephyris> RIght, black magic 😉 20:21:13 <pickpacket> can I find all nightly builds somewhere? The latest (from 2025-03-18) seems borked 20:21:17 <_zephyris> But I do see what you mean 20:21:23 <michi_cc> remap essentially contains the 8bpp image, so you have to look into the 8bpp blitter for comparision. 20:21:44 *** gelignite has joined #openttd 20:22:39 <pickpacket> found it 20:23:12 <michi_cc> So basically if the pixel comes from a 32bpp source, do it like the 32bpp blitter, if it is a 8bpp source, do it like the 8bpp blitter. 20:23:58 <peter1138> In this case, the source is 32bpp but with an 8bpp remap. 20:24:05 <peter1138> And then 32bpp alpha on top. 20:24:27 <peter1138> Layers of sprites (which all works fine), and then also converted to black & white (which... does not) 20:28:17 <michi_cc> I guess you can only choose where to "cheat". 32bpp blitters prefer to resolve to 32bpp and trash palette animation colours, 8bpp-only blitter has no alpha. 40bpp blitter probably has to decide on trashing either either alpha or animation somehwere. 20:29:14 *** WormnestAndroid has quit IRC 20:29:16 *** WormnestAndroid has joined #openttd 20:30:51 <xarick> `static std::unordered_map<int, Vehicle *> _vehicle_tile_hash{};` is that it? so simple... 20:30:52 <peter1138> Hmm, do we need to use RealizeBlendedColour again in DrawColourMappingRect. 21:13:34 *** kuka_lie has quit IRC 21:16:52 *** nielsm has quit IRC 21:23:36 *** Wolf01 has quit IRC 21:26:21 <xarick> oh, i need the strongtype hash thingy... i have it somewhere 21:30:48 <xarick> Vehicle *v = _vehicle_tile_hash[tile]; 21:31:45 <xarick> `static std::unordered_map<TileIndex, Vehicle *> _vehicle_tile_hash{};` - testing how slow this will be 21:33:12 <xarick> https://cdn.discordapp.com/attachments/1008473233844097104/1352394573791625348/image.png?ex=67dddb18&is=67dc8998&hm=e63e6dc7ba655007c603cd070d974a53cfdf423ded319cf5ee132a6b7c6ed8d4& 21:33:13 <xarick> meh... 21:38:17 *** gelignite has quit IRC 21:39:01 <xarick> would someone like to experiment with this savegame? 21:48:36 <xarick> https://1drv.ms/u/c/23b29f3de45f6f1f/EbogB5DCtGdNvQOlv1Ig_TAB_3w2DHw4pLb_-wnMIn92Mg 21:48:44 <xarick> is it accessible? 21:52:09 *** aperezdc has quit IRC 21:53:11 *** aperezdc has joined #openttd 21:54:54 *** HerzogDeXtEr has quit IRC 22:02:33 <xarick> oops, it was bugged 22:06:02 <xarick> is TileXY(v->x_pos, v->y_pos) the same as v->tile? 22:20:50 <peter1138> No. 22:23:37 <xarick> how do I clear null items from the unordered_set 22:24:25 <xarick> or, better... if a key is becoming null, how to remove the key 22:26:55 <xarick> is tile 0 supposed to have a vehicle? 22:27:06 *** keikoz has quit IRC 22:27:07 <xarick> animation 22:27:46 <xarick> https://cdn.discordapp.com/attachments/1008473233844097104/1352408303908425728/image.png?ex=67dde7e2&is=67dc9662&hm=9cb98c1e807c85093b3951da50016ef7a993ed432fea3e9363ecfd19b376193d& 22:27:46 <xarick> I invented this crap: 22:28:38 <xarick> and some tiles have no vehicles 22:29:07 <pickpacket> I need to add the companyID to this event: https://github.com/OpenTTD/OpenTTD/blob/master/src/script/api/script_event_types.hpp#L28 22:29:12 <xarick> wanted to somehow get rid of those keys 22:29:26 <pickpacket> because if the vehicle expires before the event is handled you can't get it 22:30:11 <pickpacket> and also I want to add the name of the company that crashed a vehicle to the news flash about it. The first thing everyone does when a vehicle crashes is to try to figure out whose it was 22:30:43 <pickpacket> anyways. Those were mostly notes to self. Off to bed now 22:30:44 <pickpacket> :) 22:37:51 <xarick> tilearea usually contains 1x2 or 2x1 or 1x1 22:38:00 <xarick> haven't yet seen a 2x2 22:38:34 <xarick> https://cdn.discordapp.com/attachments/1008473233844097104/1352411021339394160/image.png?ex=67ddea6a&is=67dc98ea&hm=54b61de4e607e00df515c90aab6ff03414f92dc180dfd598f4f1187fd3650b68& 22:38:34 <xarick> oh, got one! 22:39:34 <xarick> ah, a road vehicle 22:39:48 <xarick> they're fatter 22:43:00 <xarick> wondering if any train can get 2x2 22:44:41 <DorpsGek> [OpenTTD/OpenTTD] xJayMorex opened pull request #13857: Fix #13562: Removed cost estimation message from money cheat https://github.com/OpenTTD/OpenTTD/pull/13857 22:53:13 <peter1138> Technically ships could be, but they don't collide, so... 22:58:35 <peter1138> With trains you could maybe just look at the tile reservation state before querying the tile hash... 22:58:57 <peter1138> *path 22:59:26 <peter1138> Or not, it'll always be reserved :-) 23:00:47 <xarick> trains can also get a 2x2 area 23:00:50 <xarick> just tested 23:01:19 <xarick> COLL_DIST = 6; 23:01:21 <peter1138> Diagonals. 23:03:33 <xarick> https://cdn.discordapp.com/attachments/1008473233844097104/1352417309930557470/image.png?ex=67ddf045&is=67dc9ec5&hm=f21a04fa3a0e2e629188b6f729b49f9fe1779f2e1e98fa291baae70cfeafdfad& 23:04:09 <peter1138> Yes, so? 23:04:34 <xarick> I'm thinking 23:09:48 <xarick> wondering if this Clamp is ever needed 23:10:14 <xarick> probably not 23:10:45 <xarick> it doesn't include ships... 23:11:54 <xarick> trains and roadvehs, even with a -6/+6 can never go out of the map 23:12:10 <xarick> okay let's test without Clamp 23:14:31 <xarick> oh, probably the animation vehicle thing at tile 0 😦 23:15:37 <peter1138> Hmm, oddly cheesable final level. 23:29:15 <xarick> no asserts 23:29:23 <xarick> looks like clamp can be gone 23:35:57 <xarick> https://github.com/OpenTTD/OpenTTD/compare/master...SamuXarick:OpenTTD:vehicle-tile-hash 23:36:12 <xarick> PR? 23:36:16 <xarick> :p 23:37:23 <xarick> I don't think HASH_RES is used anywhere 23:37:56 <xarick> nevermind, it was used 23:38:05 <xarick> and I unused it