00:42 < bridge> <Ewan> rip... glad it got figured out
08:17 < bridge> <Assa> skipping the while loop and directly calling draw didn't do much, but works:
08:17 < bridge> <Assa> https://cdn.discordapp.com/attachments/293493549758939136/1382242384490004602/screenshot_2025-06-11_08-17-02.png?ex=684a7109&is=68491f89&hm=b6d8608be38e8855e1bf284111d08e3fc921c6aced5b452f0452b01484aea3b2&
08:19 < bridge> <Assa> how would you implement the skip if the memcopy? I could make the backend return the buffer command, and simply add it after that, but I don't think it would be clean
08:20 < bridge> <Assa> how would you implement the skip if the memcopy? I could make the backend return the buffer command, and simply add the command each frame, but I don't think it would be clean
08:39 < bridge> <Jupstar ✪> The memcpy is not in the backend
08:39 < bridge> <Jupstar ✪> It's in graphics threaded render quad
08:40 < bridge> <louis> i wanna add some entities but there aren't enough spaces inside the switch layer to fit 21 total. should i just add a new map layer type or decrease the base entity index value for switch layer :|
08:40 < bridge> <Jupstar ✪> Also you have to remove the for loop in render layers then too
08:51 < bridge> <chillerdragon> Oh no did it break our handwritten type hints?
08:53 < bridge> <chillerdragon> Ghost ping test @chillerdragon
09:10 < bridge> <syrinok> Has antiping been changed recently? I swear the prediction seems different now
09:11 < bridge> <syrinok> I'm seeing tees appear as frozen for a split second when I don't believe I have before, when almost touching freeze
09:26 < bridge> <ryozuki> im makint a mmap backed btree+
09:27 < bridge> <ryozuki> and then a kv db
09:28 < bridge> <Jupstar ✪> Yes the skin is predicted too now
09:28 < bridge> <Jupstar ✪> The movement already was
09:29 < bridge> <syrinok> Interesting
09:29 < bridge> <Jupstar ✪> What is that
09:30 < bridge> <Jupstar ✪> I've recently read about some btree+ db. Probably from you xd
09:30 < bridge> <syrinok> I'm not sure predicting the skin is an improvement in that case, what's the benefit to doing so?
09:33 < bridge> <ryozuki> key value db
09:34 < bridge> <ryozuki> with mvcc
09:34 < bridge> <ryozuki> https://en.m.wikipedia.org/wiki/Multiversion_concurrency_control
09:34 < bridge> <ryozuki> ye xd
09:51 < bridge> <syrinok> It simply makes antiping visually worse, no? 🤷‍♂️
09:52 < bridge> <TsFreeeeeeeeeddie> probably feels a tiny bit better when you drop someone in freeze at 200 ping.
09:53 < bridge> <syrinok> I'm just seeing freeze prediction errors commonly
09:54 < bridge> <TsFreeeeeeeeeddie> We might need to introduce different prediction margin for different parts
09:56 < bridge> <TsFreeeeeeeeeddie> like a 20ms offset for the skin prediction would probably feels less error-ish and still be able to feel earlier at high ping.
09:56 < bridge> <TsFreeeeeeeeeddie> Even tho it's technically predicted "wrong" if you put show different prediction at different times
09:57 < bridge> <syrinok> Ya, I could see some fine-tuning being a better overall result
10:00 < bridge> <Jupstar ✪> I'd say 50:50.
10:00 < bridge> <Jupstar ✪> 
10:00 < bridge> <Jupstar ✪> Previously I saw ppl jumping into freeze keeping their skin, now I sometimes see prediction errors.
10:06 < bridge> <TsFreeeeeeeeeddie> Bet
10:07 < bridge> <totar> I assumed it was left out on purpose because it was so easy
10:08 < bridge> <TsFreeeeeeeeeddie> Tunezone prediction isn't too complicated either when I was working on it.
10:08 < bridge> <learath2> So what happens? The tee gets too close to freeze, the skin changes but they don't really get frozen?
10:09 < bridge> <syrinok> ya like a flicker, looks odd
10:09 < bridge> <TsFreeeeeeeeeddie> I do wonder if hook or airjump was in play. If it is just free fall there is a chance it was just prediction error
10:09 < bridge> <learath2> That might be extremely annoying especially when hammerflying close to freeze or sth. You might think your partner got frozen and give up
10:10 < bridge> <syrinok> Ya, I'm thinking I'd definitely panic react in tight hammerfly sections
10:10 < bridge> <TsFreeeeeeeeeddie> You know what. Maybe.. we just don't predict if hook was used recently
10:11 < bridge> <TsFreeeeeeeeeddie> Cuz most prediction benefits when other people just falling
10:12 < bridge> <Jupstar ✪> You can argue the exact opposite too.
10:12 < bridge> <Jupstar ✪> You think he is not frozen and don't react
10:12 < bridge> <TsFreeeeeeeeeddie> :nouis: I'm out. I don't even play this game
10:13 < bridge> <Jupstar ✪> Gemer
10:13 < bridge> <TsFreeeeeeeeeddie> I was just scrolling around. I already forgot what I was here for
10:14 < bridge> <totar> https://cdn.discordapp.com/attachments/293493549758939136/1382271669669859378/2025.06.07_-_03.45.36.57.DVR.mp4?ex=684a8c4f&is=68493acf&hm=a3d01ab68a70aeec62a823110ad3f1538f59fb7a845cdb18611f7f4e18c1d21e&
10:14 < bridge> <Jupstar ✪> Now turn it off and show me how it's better to play with 300 ping
10:14 < bridge> <syrinok> I'd argue I never had an actual issue with tees not instantly showing as frozen
10:14 < bridge> <totar> you can at least tell who is alive
10:14 < bridge> <syrinok> And I've played more than 99% of the playerbase
10:15 < bridge> <TsFreeeeeeeeeddie> oh I just want to tell Lerato that our mod recruitment post in CHN was flagged and deleted by tencent. Very epic. Such funny
10:15 < bridge> <learath2> But the driver thinking the hammerer is not frozen when frozen is less catastrophic. It'll only make the driver flame the dude for not hammering and they will fail, they already really failed when the dude got frozen, it just looked wrong.
10:15 < bridge> <learath2> 
10:15 < bridge> <learath2> If I see my hammerer get frozen I'll start hammering down. Which might genuinely kill us if he wasn't really frozen and we aren't exactly on time
10:15 < bridge> <TsFreeeeeeeeeddie> oh I just wanted to tell Lerato that our mod recruitment post in CHN was flagged and deleted by tencent. Very epic. Such funny
10:15 < bridge> <syrinok> Exactly
10:16 < bridge> <learath2> This one gets worse and worse with ping. Maybe we can disable the skin prediction if the current ping is low enough?
10:16 < bridge> <syrinok> Mayhaps
10:16 < bridge> <Jupstar ✪> Just add a config to predict it or not
10:17 < bridge> <Jupstar ✪> The game feels much snappier now, I think it's overall nicer like this
10:17 < bridge> <learath2> Though then you get one weird component to antiping that changes with ping when it's supposed to make ping irrelevant. I guess a config is better so you know exactly what you are enabling
10:17 < bridge> <syrinok> I agree
10:18 < bridge> <learath2> I genuinely can't tell anything, do people actually play like this? 😄
10:18 < bridge> <totar> yes
10:19 < bridge> <Jupstar ✪> If you play gores with high pingers, you usually do up down saves
10:19 < bridge> <Jupstar ✪> Because otherwise they cannot react
10:20 < bridge> <totar> with tclient it's much more playable but I didn't have it in to record the video quickly
10:21 < bridge> <totar> actually solly might have merged it already let me check
10:21 < bridge> <Jupstar ✪> Yeah show me how you play better. I'd say I could have reacted to the save at ~5s in your video
10:21 < bridge> <Jupstar ✪> The rest would have been impossible anyway, bcs the players made bad save attempts
10:21 < bridge> <totar> I wasn't trying to play in that clip
10:21 < bridge> <totar> I will make abetter one
10:25 < bridge> <learath2> The other players teleporting around is so distracting. I probably wouldn't ever get used to playing with high ping
10:26 < bridge> <Jupstar ✪> Even tho I agree, I would really say, turning anti ping off, will not make the gameplay better
10:26 < bridge> <Jupstar ✪> It just looks nicer that you didn't react to a nice save xD
10:27 < bridge> <Jupstar ✪> Back when chile was the biggest community I often played gores with them. The ppl you play with simply have to understand how you react to certain saves, then you can also play hard or insane
10:29 < bridge> <Jupstar ✪> I really wonder why chile community just died
10:29 < bridge> <Jupstar ✪> I think no other community died like that yet
11:18 < bridge> <Assa> mona circle
11:18 < bridge> <Assa> https://cdn.discordapp.com/attachments/293493549758939136/1382287836769947730/screenshot_2025-06-11_11-18-08.png?ex=684a9b5d&is=684949dd&hm=3eab956b6454a1273ec636e22fe113c8a396dc656e561d1820af5a7d36afbf72&
11:22 < bridge> <Jupstar ✪> Dev chat in the last few days has seen more Art discussion than #showroom
11:24 < bridge> <Assa> I was able to get rid of the while loop in the backend for vulkan in general, I don't see it's purpose as the split into render count chunks already happened before
11:24 < bridge> <Assa> added a dbg_assert
11:24 < bridge> <Assa> added a dbg_assert instead
11:29 < bridge> <Jupstar ✪> Wait what? you removed the max limit?
11:29 < bridge> <Assa> yes, the chunking already happens before
11:30 < bridge> <Jupstar ✪> You mean in the frontend?
11:30 < bridge> <Assa> yes, and if you don't do it in the frontend, you crash before when allocating memory
11:31 < bridge> <Jupstar ✪> Bcs of limits of the command buffer?
11:32 < bridge> <Jupstar ✪> Or inside vulkan backend?
11:33 < bridge> <Jupstar ✪> You should be careful not mixing limits up. I prefer we keep the while in vulkan, since that limits the upload since to a single uniform buffer.
11:33 < bridge> <Jupstar ✪> 
11:33 < bridge> <Jupstar ✪> If the frontend is limited by some command buffer that is unrelated
11:34 < bridge> <Assa> I agree, that we should be careful, that's why I added a dbg_assert with the limit check instead
11:35 < bridge> <Jupstar ✪> Yeah but I think we should keep the while
11:35 < bridge> <Jupstar ✪> It does what it should in vk & ogl
11:37 < bridge> <Jupstar ✪> Also you won't get any perf from that.
11:37 < bridge> <Jupstar ✪> 
11:37 < bridge> <Jupstar ✪> The bottleneck is defs in the frontend now
11:38 < bridge> <Assa> if I remove the chunking from the frontend, I crash at `AllocCommandBufferData` with `dbg_assert(pData, "graphics: failed to allocate data (size %" PRIzu ") for command buffer", AllocSize);`
11:39 < bridge> <Jupstar ✪> Yes
11:39 < bridge> <Jupstar ✪> That's a unrelated buffer
11:40 < bridge> <Jupstar ✪> Let's say vulkan 1.5 gives higher minimum guarantees for uniform buffers,
11:40 < bridge> <Jupstar ✪> Then we'd high up the front end and the backend has to deal with the splitting
11:40 < bridge> <Jupstar ✪> since the limits for OGL & vk 1.1 won't change
11:40 < bridge> <Assa> currently we are checking against the same variable in both
11:40 < bridge> <Jupstar ✪> Doesn't matter
11:40 < bridge> <Assa> hmm okay then I'll revert it, does this limit apply to direct pushing as well?
11:41 < bridge> <Jupstar ✪> The pushing has no limit no
11:41 < bridge> <Jupstar ✪> Since it doesn't allocate anything
11:42 < bridge> <Jupstar ✪> That's also what I tried to tell you.
11:42 < bridge> <Jupstar ✪> 
11:42 < bridge> <Jupstar ✪> The frontend should only send 1 quadrenderinfo
11:42 < bridge> <Jupstar ✪> to remove the memcpy and the loop in the frontend.
11:42 < bridge> <Jupstar ✪> 
11:42 < bridge> <Jupstar ✪> The backend should simply have if push {render_all} else {while ... }
11:42 < bridge> <Jupstar ✪> Then you should see at least 2.5x the performance compared to your current FPS (with the current patch)
11:43 < bridge> <Assa> finally I am starting to understand
11:48 < bridge> <Assa> and Now I am running into my own debug assertion 😆 E assert: C:\Users\Marvin\Desktop\workspace\ddnet\src\engine\client\bac
11:48 < bridge> <Assa> and Now I am running into my own debug assertion 😆 `Draw Count to high 291, did you forget to split into chunks before?`
11:51 < bridge> <Assa> this now doubled my fps, however I still don't see the 3K you wanted
11:51 < bridge> <Assa> https://cdn.discordapp.com/attachments/293493549758939136/1382296052119375882/screenshot_2025-06-11_11-50-40.png?ex=684aa304&is=68495184&hm=ce2fb0d9db3a5a32da66405612929c8f242cf7e91f19a12f79c53ebf9e471bb1&
11:53 < bridge> <Assa> ```
11:53 < bridge> <Assa>         Cmd.m_pQuadInfo = (SQuadRenderInfo *)AllocCommandBufferData(sizeof(SQuadRenderInfo));
11:53 < bridge> <Assa>         mem_copy(Cmd.m_pQuadInfo, pQuadInfo, sizeof(SQuadRenderInfo));
11:53 < bridge> <Assa> ```
11:54 < bridge> <Assa> can I do this smarter in this case? I only copy one now, but I don't think a memcopy is the right choise here
11:54 < bridge> <Assa> can I do this smarter in this case? I only copy one now, but I don't think a memcopy is the right choice here
11:58 < bridge> <Jupstar ✪> It isn't but that will not give 500fps more xD
11:58 < bridge> <Jupstar ✪> A struct assignment is a memcpy internally
11:59 < bridge> <Jupstar ✪> So even if you add a SQuadRenderInfo the the cmd it wont change anything drastically, except the alloc logic
11:59 < bridge> <Jupstar ✪> But it didn't double it. 600 -> 1500 or not?
11:59 < bridge> <Jupstar ✪> That is around 2.5x times
11:59 < bridge> <Jupstar ✪> ^
11:59 < bridge> <Assa> more like 800 -> 1500
11:59 < bridge> <Jupstar ✪> Mh ok
11:59 < bridge> <Jupstar ✪> I can also test later, but I don't expect 3k fps on your system
12:00 < bridge> <Assa> I don't either xD I get 4.5 K only with the bg
13:14 < bridge> <teero777> when?
13:26 < bridge> <Solly (bun bun)> hello?
14:22 < bridge> <patiga> @jupeyy_keks that python web interface doesn't seem to be easy. statically linking python into pyo3 for wasm isn't really a thing people do apparently
14:34 < bridge> <Jupstar ✪> rip
14:35 < bridge> <Assa> @jupeyy_keks is vulkan the only backend with quad buffering?
14:35 < bridge> <Jupstar ✪> OGL3.3
14:35 < bridge> <Assa> then why does this not crash with ogl3.3 🤔 I only send 1 render info now
14:36 < bridge> <Jupstar ✪> https://github.com/wasix-org/cpython
14:36 < bridge> <Jupstar ✪> Isn't that pyson?
14:36 < bridge> <Assa> okay it does crash 🙈
14:37 < bridge> <Assa> okay it does crash eventually 🙈
14:37 < bridge> <Jupstar ✪> It's also possible it won't crash simply bcs in OGL there are no real allocations
14:37 < bridge> <Jupstar ✪> it's more like a storage inside the shader program
14:37 < bridge> <Jupstar ✪> I don't use uniform buffers, but uniforms there
14:38 < bridge> <patiga> but I also need to have my module compiled to wasm and somehow imported there
14:39 < bridge> <Jupstar ✪> well your module is the easiest part or not?
14:39 < bridge> <Jupstar ✪> 
14:39 < bridge> <Jupstar ✪> but i dunno any c libs any of your deps use
14:39 < bridge> <Jupstar ✪> It's probs not trivial enough xd
14:43 < bridge> <Assa> now I accidentally also improved ogl3.3 🙈
14:43 < bridge> <Jupstar ✪> The same thing won't work there
14:43 < bridge> <Jupstar ✪> If it works, then by luck. render a different quad layer with animations and it will break yours
14:44 < bridge> <Assa> yes but I only send 1 QuadInfo and set it for everything, seems to improve fps by factor 5
14:44 < bridge> <Jupstar ✪> Ah well that works yeah. The good thing is that this happens in a different thread
14:44 < bridge> <Assa> if I do animations, I fall back to default quad rendering anyway
14:44 < bridge> <Jupstar ✪> So the memcpy isn't slowing the main thread
14:45 < bridge> <Assa> yeah exactly! 😄
14:45 < bridge> <Jupstar ✪> :deen_star:
15:06 < bridge> <Assa> I am pretty sure we could optimize ogl3.3 even further:
15:06 < bridge> <Assa> ```
15:06 < bridge> <Assa>             for(size_t i = 0; i < (size_t)ActualQuadCount; ++i)
15:06 < bridge> <Assa>             {
15:06 < bridge> <Assa>                 aColors[i] = pCommand->m_pQuadInfo[0].m_Color;
15:06 < bridge> <Assa>                 aOffsets[i] = pCommand->m_pQuadInfo[0].m_Offsets;
15:06 < bridge> <Assa>                 aRotations[i] = pCommand->m_pQuadInfo[0].m_Rotation;
15:06 < bridge> <Assa>             }
15:06 < bridge> <Assa> 
15:06 < bridge> <Assa> 
15:06 < bridge> <Assa>         pProgram->SetUniformVec4(pProgram->m_LocColors, ActualQuadCount, (float *)aColors);
15:06 < bridge> <Assa>         pProgram->SetUniformVec2(pProgram->m_LocOffsets, ActualQuadCount, (float *)aOffsets);
15:06 < bridge> <Assa>         pProgram->SetUniform(pProgram->m_LocRotations, ActualQuadCount, (float *)aRotations);
15:06 < bridge> <Assa>         pProgram->SetUniform(pProgram->m_LocQuadOffset, (int)(QuadOffset + QuadOffsetExtra));
15:06 < bridge> <Assa>         glDrawElements(GL_TRIANGLES, ActualQuadCount * 6, GL_UNSIGNED_INT, (void *)((QuadOffset + QuadOffsetExtra) * 6 * sizeof(unsigned int)));
15:06 < bridge> <Assa> ```
15:06 < bridge> <Assa> 
15:06 < bridge> <Assa> But I guess we'd need a new shader? I am very unfamiliar with this
15:14 < bridge> <Jupstar ✪> With a new shader you could make it as fast as vk
15:15 < bridge> <Assa> I am looking into adding the PUSH defintion, too
15:16 < bridge> <learath2> noway, is the ogl3.3 backend getting some love again?
15:17 < bridge> <Jupstar ✪> Sure, but there are no push constants in ogl
15:17 < bridge> <Jupstar ✪> It's simply uniform there
15:17 < bridge> <Jupstar ✪> But generally OGL should be easy to do, since OGL is ez
15:18 < bridge> <Assa> can you tell me how opengl decides which pipeline to use?
15:19 < bridge> <Assa> ```
15:19 < bridge> <Assa>     CGLSLQuadProgram *pProgram = NULL;
15:19 < bridge> <Assa>     if(IsTexturedState(pCommand->m_State))
15:19 < bridge> <Assa>     {
15:19 < bridge> <Assa>         pProgram = m_pQuadProgramTextured;
15:19 < bridge> <Assa>     }
15:19 < bridge> <Assa>     else
15:19 < bridge> <Assa>         pProgram = m_pQuadProgram;
15:19 < bridge> <Assa> ```
15:19 < bridge> <Assa> Probably something like this
15:19 < bridge> <Jupstar ✪> Yes
15:20 < bridge> <Assa> ah this is not done clever, this is copy pasted, that's why I didn't understand 🥳
16:08 < bridge> <Assa> opengl 3.3
16:08 < bridge> <Assa> https://cdn.discordapp.com/attachments/293493549758939136/1382360798264823881/screenshot_2025-06-11_16-08-02.png?ex=684adf51&is=68498dd1&hm=aae7a27a27c27589297afbe25eebe0a33f4f647d875dd236b6e32748f97b15a1&
16:08 < bridge> <Assa> almost 1100 fps, but man whoever said opengl is getting some love is wrong, debugging shaders is evil
16:11 < bridge> <Assa> 36 fps -> 1100 , what a jump
16:16 < bridge> <12944qwerty> How do you learn how to use opengl or vulkan
16:18 < bridge> <Assa> well I personally once had a lecture in scientific visualization and made a render pipeline for vulkan from scratch, there is a nice youtube tutorial for it. Doing it for tw is mostly looking what others have done, comparing and transfer learning
16:19 < bridge> <Assa> apprenently I made it to chapter 10 <https://youtu.be/gxUcgc88tD4>
16:22 < bridge> <12944qwerty> Looks good, I'm saving that
16:27 < bridge> <Jupstar ✪> great, now we have mona lisa as many quads instead of a single picture with 20k fps with over 1k fps
16:28 < bridge> <Assa> just don't open it in the editor :justatest:
16:29 < bridge> <Jupstar ✪> https://cdn.discordapp.com/attachments/293493549758939136/1382366195054809259/image.png?ex=684ae458&is=684992d8&hm=4080c4c5f112ae61788bc10ce16cd183c692dacf39b0475931cf8ab1b6503e5c&
16:30 < bridge> <Jupstar ✪> 831887 quads?
16:30 < bridge> <Jupstar ✪> Is that correct? Why is it uneven
16:30 < bridge> <Assa> yeah it's the small one
16:30 < bridge> <Assa> oh it's the optimized one ^^
16:30 < bridge> <Assa> nearby pixels are collapsed to one quad, but I think only columns
16:30 < bridge> <Jupstar ✪> I get solid 6fps in that editor
16:31 < bridge> <Assa> that's 10x as much as me
16:36 < bridge> <Assa> I am already looking into integrating render layers into the editor, but I need to wait for robyts sub-component PR
17:03 < bridge> <Jupstar ✪> but the streamed versions only right?
17:03 < bridge> <Jupstar ✪> Like non-buffered
17:09 < bridge> <Assa> no, I want to buffer the unselected groups
17:09 < bridge> <Assa> and switch on demand
17:10 < bridge> <Assa> might work out, might fail in a spectacular boom :3
17:11 < bridge> <soker.one> чюпеп
17:12 < bridge> <Jupstar ✪> On bigger maps this will defs switching layers lag for a bit.. like probs less than ~100ms but still
17:23 < bridge> <Assa> wat if we had a thread making the buffering ready and then switching when it's ready? after all the blocker is in the setup time
17:23 < bridge> <Assa> what if we had a thread making the buffering ready and then switching when it's ready? after all the blocker is in the setup time
17:26 < bridge> <Jupstar ✪> That's some fair amount of complexity you want to add
17:26 < bridge> <Jupstar ✪> But if you want to try out
17:31 < bridge> <Assa> @jupeyy_keks can you review #10340? I believe the list of people who can review this is short 🙈
17:31 < bridge> <DDNet> https://github.com/ddnet/ddnet/pull/10340
17:39 < bridge> <robyt3> Also test by launching with `dbg_gfx 4` to get all validation log messages and check if there is anything new, if you haven't already
17:39 < bridge> <Assa> what do you mean by anything new?
17:39 < bridge> <Assa> compared to previously?
17:39 < bridge> <robyt3> Log messages not present without your changes, yeah
17:44 < bridge> <Assa> first thing I noticed: I forgot to push the shaders 🙈
17:46 < bridge> <Jupstar ✪> Some day xd
17:48 < bridge> <Assa> There are like a million log messages not present with my changes
17:49 < bridge> <robyt3> Output log before and after to separate files. Then remove the timestamps with regex replace. Then diff the files.
17:51 < bridge> <Jupstar ✪> Smth ~2k fps now
17:51 < bridge> <Jupstar ✪> That's still less than expected tbh
17:52 < bridge> <Assa> all differences have the `(stream)` text next to it
17:52 < bridge> <Jupstar ✪> I don't understand why tho. The shader should basically do the same as in my version of the nonanim shader
17:57 < bridge> <Assa> DDЯaceNetwork
17:58 < bridge> <Jupstar ✪> de de race
17:59 < bridge> <Assa> I don't get your review xD the first thing is for !Push, the original code with the original memcopy
18:00 < bridge> <Jupstar ✪> https://cdn.discordapp.com/attachments/293493549758939136/1382388974001066024/ddrace.mp3?ex=684af98e&is=6849a80e&hm=cc33922881d76c64b9bf20c93557c9e10b5be61653ba1b7b04b6e8f0519121bd&
18:00 < bridge> <Jupstar ✪> in the original code the memcpy happened after the addcmd
18:00 < bridge> <Jupstar ✪> https://cdn.discordapp.com/attachments/293493549758939136/1382389099784044636/image.png?ex=684af9ac&is=6849a82c&hm=9b63505a40b1c3aa528af4fcf06f74b81c96523182aac52c29e28893d09b066d&
18:01 < bridge> <Assa> ah yes nice 👍
18:08 < bridge> <louis> gonna bump this and ping u @robyt3
18:10 < bridge> <louis> i wanna implement #10339
18:10 < bridge> <DDNet> https://github.com/ddnet/ddnet/issues/10339
18:10 < bridge> <robyt3> Could you encode the information in the other tile attributes instead of adding a tile for every entity?
18:11 < bridge> <louis> i need number and delay
18:12 < bridge> <kebscs> i like the idea but 7 tiles is too much
18:12 < bridge> <louis> can i use m_Flags for switch? does that not handle rotation and whatever
18:12 < bridge> <kebscs> we will run out of tile space if every new tile needs so many bcs of different weapons
18:12 < bridge> <louis> yeah i could just do one for all weps
18:12 < bridge> <louis> then its 3 tiles. one for switch on, one for switch off, one for alternating
18:13 < bridge> <kebscs> yea
18:13 < bridge> <Assa> I know how to get rid of the laser len ones :/
18:13 < bridge> <Assa> I know how to get rid of the laser len ones :/ except one
18:13 < bridge> <kebscs> backwards compatibility 😂
18:13 < bridge> <louis> okay i'll just do 3 tiles total that makes it easier
18:14 < bridge> <Assa> there is also an issue about editions exactly for stuff like this
18:20 < bridge> <louis> i wanna make switches more playable :justatest:
19:42 < bridge> <gorp_tw> wait, does tar mean better map compression?
19:42 < bridge> <gorp_tw> can we finally avoid the 10mb complainers
19:43 < bridge> <Jupstar ✪> The problem with map compression is not compression.
19:43 < bridge> <Jupstar ✪> It's that assets are bundled with the map
19:43 < bridge> <Jupstar ✪> Like images
19:43 < bridge> <Jupstar ✪> Sounds
19:43 < bridge> <gorp_tw> ye i know but all u can do rly is compres those
19:44 < bridge> <Jupstar ✪> Sure it helps to keep a png in png format, but it will not magically make the 10mb file 500kb
19:47 < bridge> <gorp_tw> i was thinking of a similar thing, also showing on/off states more clearly for other things (but it might break drawguess in a way because its easier to cheat)
19:47 < bridge> <gorp_tw> also CP hud
19:53 < bridge> <gorp_tw> if hittable switches is considered, I think it should be a map setting and switch sounds should be a prerequisite
19:53 < bridge> <gorp_tw> otherwise it might not feel good
20:00 < bridge> <patiga> chillerdragon: halp, what is this line for and why does it even work? https://gitlab.com/ddnet-rs/twmap-py/-/blob/faeb6f4e0e2fea49db038f31472ce1d29ff11e3b/.gitlab-ci.yml#L25
20:00 < bridge> <patiga> I'm modifying the pipeline right now in the hope that I can automate releases, also for macos
20:00 < bridge> <patiga> https://gitlab.com/ddnet-rs/twmap-py/-/jobs/10322235361
20:00 < bridge> <patiga> here that line fails
20:01 < bridge> <patiga> and I'm unsure why
20:11 < bridge> <patiga> https://gitlab.com/ddnet-rs/twmap-py/-/blob/8e4e1f068ea34953a81bd9dfee9a1f7ee0078230/.gitlab-ci.yml
20:11 < bridge> <patiga> thats the new CI I'm trying to get to work
20:19 < bridge> <robyt3> The `.` is the same as `source` in a shell I think, so it execute the script in the current shell and makes its environment variables available in the parent shell
20:20 < bridge> <patiga> until now `.` was an abstract "use this" thingy, but that makes sense, thanks
20:20 < bridge> <patiga> what I don't understand tho is why that file should even exist
20:20 < bridge> <robyt3> yeah, I don't have a `~/.cargo/env` file either
20:25 < bridge> <gorp_tw> time to try making SDL game in Nelua
20:27 < bridge> <gorp_tw> should I use SDL3 or 2?
20:27 < bridge> <gorp_tw> more examples are with SDL2
20:40 < bridge> <Solly (bun bun)> sdl3 isnt that much different from sdl2
20:41 < bridge> <Solly (bun bun)> but you wont be making a very big game yo ucan switc any time
20:45 < bridge> <gorp_tw> ya okay, I wasnt sure if much changed
21:34 < bridge> <louis> wat
21:35 < bridge> <louis> true that why i think status indicator should be placeable
21:35 < bridge> <louis> i was thinking hittable switch is just another switch tile type that spawns an entity instead
21:36 < bridge> <louis> gonna design them as targets 🎯 and they'll have similar hitboxes to tees but instead have a diameter of a full tile length
21:51 < bridge> <pioooooo> I think having some conditional decal that only shows on some switch condition is great
22:06 < bridge> <kebscs> how to build with clion mingw?
22:06 < bridge> <kebscs> https://cdn.discordapp.com/attachments/293493549758939136/1382451051038380092/image.png?ex=684b335f&is=6849e1df&hm=8fde45e87a4df22a34204a1b112e1e48e469e756d97da39f0f10f21bc6d4ec60&
22:39 < bridge> <kebscs> other compiler works
22:40 < bridge> <kebscs> and theres no profiler for windows, so i guess im back to vs
23:08 < bridge> <chillerdragon> Yes what rossbit set it’s an alias for source to load the environment so that rust is in the PATH. I assume I have it from some rustup docs. If the file is not there maybe you don’t need it. Unless you fixed it already I can have a look tomorrow
23:10 < bridge> <chillerdragon> Yes what rossbit said. it’s an alias for source to load the environment so that rust is in the PATH. I assume I have it from some rustup docs. If the file is not there maybe you don’t need it. Unless you fixed it already I can have a look tomorrow
23:19 < bridge> <ar1gin> gm chat, has anyone had this issue where if you press A in any input box it erases everything and also debug menu opens every time i press shift+d?
23:20 < bridge> <ar1gin> seems like ctrl button is sticky but its not the keyboard and its exclusive to ddnet