00:20 < bridge> <louis> are there any good issues
00:20 < bridge> <kebscs> accounts, 128 player support
00:21 < bridge> <kebscs> this <https://github.com/ddnet/ddnet/issues/10275>
00:33 < bridge> <Assa> wth 1400 changes due to tolower
00:57 < bridge> <justabutterflier> it is question for @heinrich5991 with  bad grammar and pronunciation: https://www.youtube.com/watch?v=YMqeIS1ImOw&feature=youtu.be
02:20 < bridge> <pluskz> why top5team does not work on my server? (/top command works)
02:41 < bridge> <pluskz> i get this error on f2:
02:41 < bridge> <pluskz>  sql: show team top5 failed: (prepare:stmt:1055): Expression #4 of SELECT list is not in GROUP BY clause and contains nonaggregated column 'll.Server' which
02:41 < bridge> <pluskz>  sql: [148] show team top5 failed on all databases
03:15 < bridge> <kebscs> There was pr recently that updated it, maybe you merged wrong
03:16 < bridge> <pioooooo> Have you enabled some strict mode of mysql
03:33 < bridge> <pluskz> i have that pr merged already
03:33 < bridge> <louis> too fat for me 😭
03:33 < bridge> <louis> i try implementing a feature i always wanted ig
08:01 < bridge> <keli_1> why is Deen always offline
08:02 < bridge> <Ewan> Busy man
08:07 < bridge> <gorp_tw> man
08:07 < bridge> <gorp_tw> https://cdn.discordapp.com/attachments/293493549758939136/1381877358201540658/image.png?ex=68491d14&is=6847cb94&hm=0d7ffcd370c6063dd7619a08c32726f00a3f431061062233b1924becde966fc2&
08:07 < bridge> <gorp_tw> @mpft you weren't kidding
08:07 < bridge> <gorp_tw> can we please come up with some sort of db caching  thing
08:08 < bridge> <gorp_tw> not able to repro rn but ive had it take minutes before
08:08 < bridge> <Ewan> yeah it’s no good
08:10 < bridge> <keli_1> It seems like Deen hasn't been online for almost a week now. It's too painful for the server not to have a whitelist
08:10 < bridge> <Ewan> well i believe he’s busy in general
08:10 < bridge> <Ewan> irl related things
08:12 < bridge> <keli_1> okay thank you for your answer
09:05 < bridge> <Jupstar ✪> Good parents only have time for their kids
09:22 < bridge> <gorp_tw> so like, is this inline style around player finished maps tables just here to make me suffer? because it feels like it was put here to make me suffer
09:22 < bridge> <gorp_tw> https://cdn.discordapp.com/attachments/293493549758939136/1381896360239956089/image.png?ex=68492ec6&is=6847dd46&hm=51e5d3479f8bcd6c8fd243cc08c6b7d616a6cc174f369ff8d4ef750b25bb7d3b&
09:23 < bridge> <gorp_tw> it causes the bounding box of the content to shift by 1 pixel. ONE.
09:23 < bridge> <gorp_tw> WHY IS IT EVEN HERE
09:23 < bridge> <gorp_tw> you remove it and you get my 1px border back
09:24 < bridge> <gorp_tw> with it, you try to scroll through the page and you get jumpscared by "would you like to now scroll *horizontally by one pixel????????????*"
09:27 < bridge> <gorp_tw> This monstrosity has been brought to you by Whoever The Hell Made This Template
09:27 < bridge> <gorp_tw> https://cdn.discordapp.com/attachments/293493549758939136/1381897550482899024/image.png?ex=68492fe2&is=6847de62&hm=c7e9bf308a8f2b8bde998108335db28237e2529d73dda040dc550f6e4a6083a4&
09:27 < bridge> <chillerdragon> fred stop hack into private group chat
09:28 < bridge> <gorp_tw> at this point the PR is so hacky that it would be better spent to just rewrite the templates a bit
09:28 < bridge> <gorp_tw> too many random elements with no id/class everywhere
10:05 < bridge> <blaiszephyr> What website
10:08 < bridge> <gorp_tw> ddnet.org/player/*
10:08 < bridge> <gorp_tw> ddnet.org/players/*
10:09 < bridge> <gorp_tw> something about it being sent syncr with large db queries
10:09 < bridge> <gorp_tw> and probably no caching
10:11 < bridge> <blaiszephyr> Yeah.. :justatest:
10:13 < bridge> <gorp_tw> it should be per-route with some quadratic falloff per hit
10:13 < bridge> <gorp_tw> probably some tool does it better than we can code
10:14 < bridge> <gorp_tw> and there should be some lazy cache on some other thread that just tries to get everything synced with the site for anything requested in the past few days - a week
10:15 < bridge> <gorp_tw> if that's too much then u can ofc more aggressively cache stuff separately that doesn't change much like favorite partners
10:15 < bridge> <gorp_tw> then you need less JOIN in your SELECT or whatever the hell its doing
10:15 < bridge> <cinavarkeles> @blaiszephyr
10:18 < bridge> <gorp_tw> if you have some sort of append-only layer then you can efficiency retrieve the diff of the last cached state
10:18 < bridge> <gorp_tw> if you have some sort of append-only layer then you can efficiently retrieve the diff of the last cached state
10:18 < bridge> <gorp_tw> which would be nice for seeing a single rank change / new cleared map quickly
10:19 < bridge> <gorp_tw> if you have some sort of append-only layer then you can efficiently retrieve the diff with the last cached state
11:22 < bridge> <0xdeen> Thanks @1voix1 !
11:22 < bridge> <Assa> Added a progress bar, it's not time based and not smart, but simple and existing, any opinions on this?
11:22 < bridge> <Assa> https://cdn.discordapp.com/attachments/293493549758939136/1381926376046596158/Base_Profile_2025.06.10_-_11.18.05.01.mp4?ex=68494abb&is=6847f93b&hm=12915332121c7db787765ff44fb52e7214c065769cd0bf4a61c8724e4a06b415&
11:22 < bridge> <0xdeen> Also big thanks for still paying @cattide !
11:25 < bridge> <0xdeen> I personally don't like inaccurate progress bars and they are hard to make accurate
11:26 < bridge> <Assa> I am more in favor of an inacurate one compared to none, as it shows that any progress is made. Would you be more in favor of a loading icon?
11:29 < bridge> <Assa> also since I am uploading to gpu I believe it's almost impossible to make accurate :justatest:
11:29 < bridge> <Assa> also since I am uploading to gpu I believe it's almost impossible to make accurate :justatest: might be data size, os, driver and hardware dependend
11:34 < bridge> <Assa> @sollybunny was it you, who merged the rendering and made a custom rendering for infection class?
12:03 < bridge> <kebscs> Looks good
12:04 < bridge> <robyt3> You can already tell that it's loading because the background is animated
12:05 < bridge> <blaiszephyr> A step counter and/or a loading icon maybe?
12:06 < bridge> <Assa> yes, looking into this, this is a fun mock using the dragger, we could get creative here 😄
12:06 < bridge> <Assa> https://cdn.discordapp.com/attachments/293493549758939136/1381937570157690910/Base_Profile_2025.06.10_-_12.05.03.02.mp4?ex=68495527&is=684803a7&hm=b63d783f8ec28a0a97fcf006d4a3a5f22ee85ba003fbd7b13bc8f99acf897d92&
12:07 < bridge> <Assa> couldn't be bothered to remove the loading bar yet
12:07 < bridge> <blaiszephyr> :kek:
12:07 < bridge> <Assa> I can also imagine a rotating Tee or weapon or something like that
12:08 < bridge> <robyt3> We already have a UI loading indicator, we don't need another one. And this is already the loading screen, so what info does this spinning indicator provide? Of course it's loading while on the loading screen.
12:08 < bridge> <Assa> I actually don't see any animation whatsoever in this step 😮
12:09 < bridge> <robyt3> It's the only background theme without animation I suppose
12:11 < bridge> <Assa> I guess we don't need this feature then, for me all of the loading is quite fast, I don't know if there are devices where you are stuck longer there
12:12 < bridge> <robyt3> Maybe if we ever refactor all loading to not be hacky
12:16 < bridge> <Assa> We could also change the texts to be inaccurate, and do something like "Loading your mamas skin", "Writing an angry email about the noise", "Trying really hard not to nouis..." and cycle through them, but yeah xD I just leave this here
12:22 < bridge> <blaiszephyr> "pseudo fly is a menace to society"
12:29 < bridge> <chillerdragon> chillerbot-ux has that while starting the client
12:30 < bridge> <chillerdragon> Shows epic text such as „I am LIBAN“
12:36 < bridge> <soulyvevo> i was a faithful friend from the start...
12:41 < bridge> <vahemaaa> yee i always read it as "I am LESBIAN"
12:42 < bridge> <vahemaaa> what does LIBAN means tho
12:46 < bridge> <chillerdragon> Some player used to spam that in pvp servers a few years ago. It became an iconic quote to me
12:46 < bridge> <chillerdragon> Same as MAPLE MAPLE MAPLE MAPLE
12:59 < bridge> <kebscs> I like the loading bar
12:59 < bridge> <kebscs> Go pr
12:59 < bridge> <ryozuki> @jupeyy_keks https://github.com/Askannz/munal-os
13:00 < bridge> <blaiszephyr> 💀
13:00 < bridge> <ryozuki> why skull
13:00 < bridge> <ryozuki> its dope
13:00 < bridge> <ryozuki> Munal OS has no bootloader; instead, the entire OS is compiled into a single EFI binary that embeds the kernel, the WASM engine and all the applications. The UEFI boot services are exited almost immediately and no UEFI services are used except for the system clock.
13:01 < bridge> <ryozuki> Address space
13:01 < bridge> <ryozuki> UEFI leaves the address space as identity-mapped and Munal OS does not remap it. In fact the page tables are not touched at all, because the OS does not make use of virtual address mechanisms. The entire OS technically runs within a single memory space, but something akin to the userspace/kernelspace distinction is provided by WASM sandboxing (see below), preventing arbitrary access to kernel memory by user applications.
13:03 < bridge> <Jupstar ✪> funny design
13:05 < bridge> <Solly (bun bun)> i hope not
13:05 < bridge> <Solly (bun bun)> atleast not into main
13:05 < bridge> <Solly (bun bun)> atleast not into master
13:05 < bridge> <Solly (bun bun)> its sorta merged into my client, although its old because merging kaffienes stuff is a royal pain
13:09 < bridge> <ryozuki> https://en.wikipedia.org/wiki/Multiversion_concurrency_control
13:38 < bridge> <Assa> can you discuss this with the others? As far as I can tell nobody except is in in favor of this
13:38 < bridge> <Assa> can you discuss this with the others? As far as I can tell nobody except us in in favor of this
13:39 < bridge> <Assa> can you discuss this with the others? As far as I can tell nobody except us is in favor of this
13:39 < bridge> <kebscs> It's a good qol
13:39 < bridge> <kebscs> I don't see the animating background
13:39 < bridge> <Assa> let me test robyts claim, that it's animated on other backgrounds
13:40 < bridge> <robyt3> How does it look when you load a small map? Having a loading bar flash by for 0.2 seconds doesn't look great I think.
13:40 < bridge> <robyt3> It should be animated if `RenderLoading` is called
13:41 < bridge> <Assa> it's unnoticable
13:41 < bridge> <Jupstar ✪> Loading bars give false hope.
13:41 < bridge> <Jupstar ✪> 
13:41 < bridge> <Jupstar ✪> Just like windows when copying files around
13:42 < bridge> <kebscs> I've never noticed the animating background
13:42 < bridge> <Assa> it's clamped when loading, like you get 1 frame every second
13:42 < bridge> <robyt3> Maybe it doesn't work for background maps because they use `LocalTime` which is not simulated while loading
13:43 < bridge> <robyt3> You should get 60 FPS
13:43 < bridge> <robyt3> If you call the function often enough
13:43 < bridge> <Assa> ```
13:43 < bridge> <Assa>     // make sure that we don't render for each little thing we load
13:44 < bridge> <Assa>     // because that will slow down loading if we have vsync
13:44 < bridge> <Assa>     const std::chrono::nanoseconds Now = time_get_nanoseconds();
13:44 < bridge> <Assa>     if(Now - m_LoadingState.m_LastRender < std::chrono::nanoseconds(1s) / 60l)
13:44 < bridge> <Assa>         return;
13:44 < bridge> <Assa> ```
13:44 < bridge> <Assa> 
13:44 < bridge> <Assa> I wonder if it actually is, but you're right, but it also isn't
13:44 < bridge> <Assa> I guess we don't call the function often enough
13:44 < bridge> <Jupstar ✪> Why does the loading take so long for you anyway xD
13:45 < bridge> <Jupstar ✪> Did you artificially slow it down?
13:45 < bridge> <Assa> it doesn't, I actively need to seek a huge map for it
13:45 < bridge> <Assa> dm1 is like instant
13:45  * bridge <Assa> but
13:45 < bridge> <Assa> I wonder if this is also like this in slower devices
13:46 < bridge> <Assa> My graphics brick is fast :owo:
13:47 < bridge> <Jupstar ✪> Yeah but dunno, for me back in time 3 takes less than a second.
13:47 < bridge> <Jupstar ✪> 
13:47 < bridge> <Jupstar ✪> But maybe it's just windows being windows or smth
13:48 < bridge> <Assa> maybe also the twitch stream in the bg
13:48 < bridge> <robyt3> It will also be a lot faster on second load because Windows loads the file into memory
13:51 < bridge> <Assa> nothing is slowed down here, I wonder
13:52 < bridge> <Assa> the pipeline has overall a higher setup time, but this is intended and expected as it moves stuff from rendering into setup
13:53 < bridge> <Jupstar ✪> Ah I doubt whatever you added is noticable
13:53 < bridge> <Jupstar ✪> Except you added a second loop over all tiles
13:53 < bridge> <Assa> no
13:53 < bridge> <Jupstar ✪> It's slow because it iterates over all tiles
13:54 < bridge> <Jupstar ✪> We could create few layers in parallel and it would be much faster
13:55 < bridge> <Jupstar ✪> ```
13:55 < bridge> <Jupstar ✪> [2025-06-10T11:54:36Z INFO  ddnet_rs::client::game] loading map: BiT3
13:55 < bridge> <Jupstar ✪>   opening the full map file took 0.00s / 0.06ms / 60.45us / 60449ns
13:55 < bridge> <Jupstar ✪>   decompressing all sounds took 0.00s / 2.39ms / 2394.31us / 2394310ns
13:55 < bridge> <Jupstar ✪>   decompressing all map images took 0.02s / 20.03ms / 20034.96us / 20034960ns
13:55 < bridge> <Jupstar ✪>   initialzing the map layers took 0.30s / 304.32ms / 304322.63us / 304322629ns
13:55 < bridge> <Jupstar ✪>   preparing the map buffering took 0.48s / 477.33ms / 477333.72us / 477333722ns
13:55 < bridge> <Jupstar ✪>   loading the full map (excluding opening it) took 0.48s / 477.36ms / 477361.86us / 477361861ns
13:55 < bridge> <Jupstar ✪>   creating the image graphics cmds took 0.00s / 0.00ms / 4.99us / 4990ns
13:55 < bridge> <Jupstar ✪>   creating the map buffers graphics cmds took 0.00s / 0.02ms / 20.25us / 20250ns
13:55 < bridge> <Jupstar ✪> ```
13:55 < bridge> <Jupstar ✪> 
13:56 < bridge> <Jupstar ✪> That is probably around the potential we can get
13:56 < bridge> <Jupstar ✪> Since this is a rather short task the gains of multi threaded are not gigantic
13:56 < bridge> <Jupstar ✪> But it's probs around 2-3x faster than ddnet.
13:56 < bridge> <Jupstar ✪> 
13:56 < bridge> <Jupstar ✪> So I assume ddnet takes around 1.2seconds on my PC
13:57 < bridge> <Jupstar ✪> But the costly things are both iterations over all tiles
13:58 < bridge> <Assa> why do we iterate twice over all tiles?
14:00 < bridge> <Jupstar ✪> The above log is not ddnet.
14:00 < bridge> <Jupstar ✪> 
14:00 < bridge> <Jupstar ✪> But ddnet iterates over the tiles once to create the tile skip stuff (which has nothing todo with graphics)
14:00 < bridge> <Jupstar ✪> 
14:00 < bridge> <Jupstar ✪> and once for the graphics upload
14:46 < bridge> <Assa> Now that we have the pipeline, we could add a water layer type and use a water shader ... 🙈
14:46 < bridge> <Assa> Maybe lets first improve on quad shader? I need to understand this code first ...
14:53 < bridge> <Assa> how could we integrate this? We already have a way to distinguish between animated and pure quad layers
14:54 < bridge> <Jupstar ✪> copy paste quad shader and remove all references to the uniform buffer
14:55 < bridge> <Jupstar ✪> then copy paste the quad code in the backends and remove all uniform buffer references
14:55 < bridge> <Jupstar ✪> then try to remove duplicated code
14:55 < bridge> <Assa> thank you, I'll try this
15:15 < bridge> <Assa> btw 19.2 vs 19.3, with 19.3 I have > 200 fps making this playable
15:15 < bridge> <Assa> https://cdn.discordapp.com/attachments/293493549758939136/1381985185561837628/screenshot_2025-06-10_15-14-08.png?ex=68498180&is=68483000&hm=7573cc55d9773fc02e8592e1c85972932bc3fc600631d07ddb5c904c05d58cdd&
15:15 < bridge> <Assa> https://cdn.discordapp.com/attachments/293493549758939136/1381985186597834944/screenshot_2025-06-10_15-14-48.png?ex=68498180&is=68483000&hm=e7f6e9a171fae2edbfa196cec554406c8149022b6cbbdaa0908c3694f168c394&
15:17 < bridge> <Assa> btw 19.2 vs 19.3, with 19.3 I have > 200 fps making this (almost) playable
15:17 < bridge> <Assa> https://cdn.discordapp.com/attachments/293493549758939136/1381985185561837628/screenshot_2025-06-10_15-14-08.png?ex=68498180&is=68483000&hm=7573cc55d9773fc02e8592e1c85972932bc3fc600631d07ddb5c904c05d58cdd&
15:17 < bridge> <Assa> https://cdn.discordapp.com/attachments/293493549758939136/1381985186597834944/screenshot_2025-06-10_15-14-48.png?ex=68498180&is=68483000&hm=e7f6e9a171fae2edbfa196cec554406c8149022b6cbbdaa0908c3694f168c394&
15:18 < bridge> <Assa> btw 19.2 vs 19.3, with 19.3 I have > 200 fps making this (almost) playable (compared to 36)
15:18 < bridge> <Assa> https://cdn.discordapp.com/attachments/293493549758939136/1381985185561837628/screenshot_2025-06-10_15-14-08.png?ex=68498180&is=68483000&hm=7573cc55d9773fc02e8592e1c85972932bc3fc600631d07ddb5c904c05d58cdd&
15:18 < bridge> <Assa> https://cdn.discordapp.com/attachments/293493549758939136/1381985186597834944/screenshot_2025-06-10_15-14-48.png?ex=68498180&is=68483000&hm=e7f6e9a171fae2edbfa196cec554406c8149022b6cbbdaa0908c3694f168c394&
15:19 < bridge> <Jupstar ✪> Yep, it's defs am improvement
15:19 < bridge> <Jupstar ✪> The reason why a noanim shader is so much faster is simply, bcs it completely skips the new loop you added to prepare the QuadRenderInfo
15:20 < bridge> <Jupstar ✪> No loops, no memcpys, no upload to gpu
15:20 < bridge> <Assa> this is currently without noanim shader, I still need to wrap my head around this xD just current master vs previous
15:21 < bridge> <Assa> my new loop only loops over batches of quads and not every quad anymore
15:23 < bridge> <Jupstar ✪> in render_layers.cpp
15:23 < bridge> <Jupstar ✪> https://cdn.discordapp.com/attachments/293493549758939136/1381987044640817214/image.png?ex=6849833b&is=684831bb&hm=3f7a28d1e4e5b85444c8f88c81d4da97b6130dabdf3dd9c8267993fb14259f9f&
15:24 < bridge> <Assa> I wonder why my IDE doesn't mark this
15:24 < bridge> <Assa> or any checks in the pipeline
15:25 < bridge> <Jupstar ✪> Probs from a newer version of clang-tidy
15:26 < bridge> <Jupstar ✪> Yep, but `m_vQuadRenderInfo.data()` this is what makes it slow
15:26 < bridge> <Jupstar ✪> Your loop is good, but the memcpy and gpu upload is not skipped
15:27 < bridge> <Jupstar ✪> Without anims you also don't need batching, you can render the whole layer at once
16:00 < bridge> <Assa> I have honestly no idea how to do this, too skillchecked
16:04 < bridge> <Jupstar ✪> Well you never did anything related in that field
16:04 < bridge> <Jupstar ✪> It's rather a question of if you are willing to read about all this stuff xd
16:04 < bridge> <Jupstar ✪> Or if you simply don't care
16:07 < bridge> <Assa> I did create my own vulkan rendering pipline from skretch once, I am a bit familiar with the concepts. But I have the additional problem of the ddnet code on top of it and I am no shader expert
16:46 < bridge> <nerxling1sad> @yuwubel
16:46 < bridge> <nerxling1sad> 1213
16:51 < bridge> <Assa> All I see we could do is safe the command buffer instead of recreating it
16:51 < bridge> <Assa> or something like render all quads once and save and rerender the result
16:53 < bridge> <Jupstar ✪> I think that's much harder xD
16:55 < bridge> <Assa> I guess if this was easy we already would have done that for tile layers as well
16:56 < bridge> <Assa> wait tile layers also contain envelopes 😮
17:23 < bridge> <Jupstar ✪> Yes, but we render 1 tile layer at a time
17:23 < bridge> <Jupstar ✪> We don't do the same for quads
17:23 < bridge> <Jupstar ✪> Tile layer envs are for the whole layer
17:23 < bridge> <Jupstar ✪> quads have animations per quad
17:27 < bridge> <Assa> @jupeyy_keks as far as I can tell the logic for this exists already, I forced the push pipeline now for quads:
17:27 < bridge> <Assa> 
17:28 < bridge> <Assa> 600-700 fps compared to 200 before, however ofc animations are now broken. But now I can do nails with heads
17:28 < bridge> <Assa> https://cdn.discordapp.com/attachments/293493549758939136/1382018462293168189/screenshot_2025-06-10_17-26-07.png?ex=6849a07e&is=68484efe&hm=77c3fba5f707a85406f153d6c13d615cc840bad50c8decad8a45f95136df5a37&
17:28 < bridge> <Assa> @jupeyy_keks as far as I can tell the logic for this exists already, I forced the "push pipeline" now for quads:
17:28 < bridge> <Assa> 
17:28 < bridge> <Assa> 600-700 fps compared to 200 before, however ofc animations are now broken. But now I can do nails with heads
17:28 < bridge> <Assa> https://cdn.discordapp.com/attachments/293493549758939136/1382018462293168189/screenshot_2025-06-10_17-26-07.png?ex=6849a07e&is=68484efe&hm=77c3fba5f707a85406f153d6c13d615cc840bad50c8decad8a45f95136df5a37&
17:32 < bridge> <Assa> I totally now what I am doing :justatest:
17:33 < bridge> <Jupstar ✪> ah, yeah that's clever
17:33 < bridge> <Jupstar ✪> I forgot we have that
17:33 < bridge> <Jupstar ✪> That's indeed almost what we need xd
17:34 < bridge> <Jupstar ✪> But note that ogl defs doesnt have it
17:35 < bridge> <Assa> yeah I am currently only adding this for vulkan
17:45 < bridge> <Jupstar ✪> If you done and upload it somewhere on GH ping me, then I can compare it on my PC
17:53 < bridge> <Assa> I'll do, thank you, and please :justatest:  I am sure you'll be a bit unhappy about it
18:11 < bridge> <TsFreeeeeeeeeddie> nice quad art. would be famous.
18:15 < bridge> <Assa> hand drawn :justatest:
18:20 < bridge> <robyt3> As further optimization you could also detect quad layers without any quads and discard them when creating the pipeline
18:35 < bridge> <Assa> that's actually really simple, make IsValid return false
18:44 < bridge> <robyt3> And remove other redundant checks
18:44 < bridge> <ryozuki> https://github.com/DioxusLabs/dioxus/tree/main/packages/subsecond
18:44 < bridge> <ryozuki> @jupeyy_keks check this out
18:44 < bridge> <ryozuki> its a subpackage not the repo itself
18:44 < bridge> <ryozuki> > Subsecond is a hot-reloading library for Rust. It makes it easy to add Rust hot-reloading to your existing Rust project with minimal integration overhead.
18:49 < bridge> <Jupstar ✪> Good, but worse than I expected xd
18:49 < bridge> <Jupstar ✪> I already know this. even used this once xD
19:02 < bridge> <Assa> do you mean my code or the Performance?
19:40 < bridge> <Assa> @jupeyy_keks can you measure performance yourself again? I get different results oO
19:51 < bridge> <jxsl13> Mona Teesa
19:52 < bridge> <jxsl13> :kek:
19:54 < bridge> <zhn> Bopa Tweena
20:08 < bridge> <Assa> We all love her twin bops :owo:
20:22 < bridge> <Assa> new measurement 150 vs 800 fps, I don't get it
20:22 < bridge> <Assa> prob some other thing going on in the bf
20:23 < bridge> <Assa> prob some other thing going on in the bg
20:38 < bridge> <Jupstar ✪> The performance
20:38 < bridge> <Jupstar ✪> _only_ 1.3k fps
20:38 < bridge> <Jupstar ✪> Would have thought it's close to 3k
20:38 < bridge> <Jupstar ✪> Do you render all quads at once?
20:43 < bridge> <Assa> no, when I do this I get a dbg message with an allocation error
20:46 < bridge> <Jupstar ✪> Mhh, there should not be any allocation
20:47 < bridge> <Jupstar ✪> Haven't looked into your PR yet
20:50 < bridge> <Assa> I think it does not what you expect
22:20 < bridge> <Jupstar ✪> yeah u still copy all quadrenderinfo
22:20 < bridge> <Jupstar ✪> 
22:20 < bridge> <Jupstar ✪> and in the backend you have to make the draw call one call (skip the while loop)
23:47 < bridge> <patiga> wow, pyo3 is a pain to update (the lib which I use to create the twmap Python module)
23:48 < bridge> <patiga> it completely changed its interface in how it interacts with the GIL, pretty much changing types everywhere
23:49 < bridge> <patiga> some stuff was really painful to figure out
23:49 < bridge> <patiga> it compiles now tho, I'll just assume for now it works 🥲
23:49 < bridge> <patiga> it compiles now tho, I'll just assume for now that it works 🥲