01:49 <+bridge_> [ddnet] Wcast-qual is a real mess in engine/shared/snapshot.cpp 08:00 <+bridge_> [ddnet] @snail nice video 08:04 <+bridge_> [ddnet] <ѕα∂ℓσνє🖤> i dont have my pc and he is not good with computers :justatest: 08:22 <+bridge_> [ddnet] how do i change lsit of .o files for linking with our cmakefiles? 08:22 <+bridge_> [ddnet] i've never used cmake other than as a user 08:22 <+bridge_> [ddnet] we generate CMake objects, that is basically a bunch of o files 08:22 <+bridge_> [ddnet] see e.g. engine shared 08:22 <+bridge_> [ddnet] ye its insane 08:25 <+bridge_> [ddnet] and without cuts 08:26 <+bridge_> [ddnet] yeah, but it's always in a single directory 08:28 <+bridge_> [ddnet] more objects more directories 08:30 <+bridge_> [ddnet] :?: 08:30 <+bridge_> [ddnet] ❓ 08:30 <+bridge_> [ddnet] you want to change the list 08:30 <+bridge_> [ddnet] so add 08:30 <+bridge_> [ddnet] engine-shared1 08:30 <+bridge_> [ddnet] engine-shared2 08:31 <+bridge_> [ddnet] but it's not compilation i change, only link 08:31 <+bridge_> [ddnet] you can control the compilation then too 08:31 <+bridge_> [ddnet] make -j20 engine-shared1 08:34 <+bridge_> [ddnet] i miss the time with makefiles you could just change 😢 08:34 <+bridge_> [ddnet] i dont miss these times xD 08:34 <+bridge_> [ddnet] cmake has everything you need 08:34 <+bridge_> [ddnet] me neither 08:34 <+bridge_> [ddnet] with proper makefiles, you could change things with just environment variables 😄 08:35 <+bridge_> [ddnet] cmake can do that too 08:35 <+bridge_> [ddnet] CC=clang cmake .. 08:35 <+bridge_> [ddnet] for compiler flags: 08:35 <+bridge_> [ddnet] cmake .. -DCMAKE_C_FLAGS="-Werror" 08:36 <+bridge_> [ddnet] lets be real, rust is superior cuz it has cargo.toml 08:36 <+bridge_> [ddnet] and a better dep management 08:36 <+bridge_> [ddnet] :greenthing: 08:36 <+bridge_> [ddnet] https://crates.io/ 08:36 <+bridge_> [ddnet] Just CFLAGS also works, don't need to use a cmake flag 08:36 <+bridge_> [ddnet] did u know there is a shitload of new c++ devs on windows 08:36 <+bridge_> [ddnet] idk how they manage 08:36 <+bridge_> [ddnet] well they probs do projects without deps 08:37 <+bridge_> [ddnet] cuz the moment they need them 08:37 <+bridge_> [ddnet] holy shit 08:37 <+bridge_> [ddnet] must be rly shit 08:37 <+bridge_> [ddnet] yeah but you can always change them without cleaning the cmake dir with the -D param 08:37 <+bridge_> [ddnet] the env flags are only cached once (first run) 08:38 <+bridge_> [ddnet] probs managed c++ XD 08:38 <+bridge_> [ddnet] Maybe they use vcpkg, heard it's acceptable-ish 08:38 <+bridge_> [ddnet] imagine thinking u need a 12gb ram ide when u have vim with cmake 08:38 <+bridge_> [ddnet] :greenthing: 08:38 <+bridge_> [ddnet] bloat 08:39 <+bridge_> [ddnet] I prefer my ide to use 32g, 12g is child numbers, what is that a puny browser? 08:48 <+bridge_> [ddnet] i think i managed to do it 🙂 11:45 <+bridge_> [ddnet] lol, the bot is faster to link that than my browser to load the issue after posting it 😄 12:05 <+bridge_> [ddnet] @Learath2 12:05 <+bridge_> [ddnet] deen on macos has a weird bug: 12:05 <+bridge_> [ddnet] 12:05 <+bridge_> [ddnet] his main and graphic thread both wait on the same condition variable 12:05 <+bridge_> [ddnet] 12:05 <+bridge_> [ddnet] both (and all calls made on them, wait, notify) are protected by a mutex 12:05 <+bridge_> [ddnet] 12:05 <+bridge_> [ddnet] the only way this can happen imo is, that a wakeup is lost: 12:05 <+bridge_> [ddnet] But this shouldnt happen with a mutex protecting the condition variable 12:05 <+bridge_> [ddnet] 12:05 <+bridge_> [ddnet] Another possibility is that the graphics thread does not notify the main thread when it started 12:05 <+bridge_> [ddnet] but i purposly added a check 12:05 <+bridge_> [ddnet] 12:05 <+bridge_> [ddnet] https://github.com/ddnet/ddnet/blob/68a4404701d53d5ce6d50db19eb0f3337bd67cec/src/engine/client/backend_sdl.cpp 12:06 <+bridge_> [ddnet] 12:06 <+bridge_> [ddnet] I don't see how both threads should ever wait on the condition variable at the same time 12:06 <+bridge_> [ddnet] 12:06 <+bridge_> [ddnet] `m_BufferSwapCond` 12:06 <+bridge_> [ddnet] 12:06 <+bridge_> [ddnet] Graphic thread waits on: 12:06 <+bridge_> [ddnet] https://github.com/ddnet/ddnet/blob/68a4404701d53d5ce6d50db19eb0f3337bd67cec/src/engine/client/backend_sdl.cpp#L74 12:06 <+bridge_> [ddnet] 12:06 <+bridge_> [ddnet] main in call of: 12:06 <+bridge_> [ddnet] https://github.com/ddnet/ddnet/blob/68a4404701d53d5ce6d50db19eb0f3337bd67cec/src/engine/client/backend_sdl.cpp#L1112 12:12 <+bridge_> [ddnet] mhh maybe its bcs of the fallback not cleaning up something correctly 12:14 <+bridge_> [ddnet] Hm, why is there 2 condvars? 12:15 <+bridge_> [ddnet] I just noticed that many client components use both "m_pClient" and "GameClient()" although "GameClient()" just returns "m_pClient" 😄 Lacks a little consistency. Although "GameClient()" is used significantly less, especially it is used often when also accessing the textures that are loaded in gameclient. 12:17 <+bridge_> [ddnet] @Not Keks ^^ 12:17 <+bridge_> [ddnet] mh yeah not needed, but i doubt that causes the bug 12:17 <+bridge_> [ddnet] It makes it a bit hard for me to reason about the flow, maybe if we clean that up the issue would be more obvious? 12:18 <+bridge_> [ddnet] A notify before wait would also be lost, I was trying to look for that but it's not obvious at all 12:18 <+bridge_> [ddnet] possible, but i kinda start to believe we forget to cleanup a thread or smth 12:21 <+bridge_> [ddnet] Anyway, first thing I'd do would be to reduce this to one condvar if possible just so it's easier to reason about 12:22 <+bridge_> [ddnet] Sorry, I can't look more into it right now, I can take another look when I get home 12:24 <+bridge_> [ddnet] Oh and luckily this happens at the very start of the initialization so it should be easier to debug 12:25 <+bridge_> [ddnet] yeah thanks, weird its not reproducable for me 😦 12:25 <+bridge_> [ddnet] Have you checked that you are both on the same sdl version? 12:26 <+bridge_> [ddnet] i think GameClient was added later 12:26 <+bridge_> [ddnet] GameClient should be used imho 12:27 <+bridge_> [ddnet] im not, but since its inside our code i assume its our bug 😄 12:27 <+bridge_> [ddnet] or deen didnt rebase correclty or smth xD 12:28 <+bridge_> [ddnet] Well the only thing that comes to my mind from a cursory glance is that 2 condvars 1 mutex being sus 12:28 <+bridge_> [ddnet] Especially when they are guarding just one condition 12:28 <+bridge_> [ddnet] but doesnt this make it safe 12:28 <+bridge_> [ddnet] that its only one condition 12:28 <+bridge_> [ddnet] the same condition 12:29 <+bridge_> [ddnet] the one is simple the waiter for main thread 12:29 <+bridge_> [ddnet] the other the waiter for other thread 12:29 <+bridge_> [ddnet] that's how they split 12:29 <+bridge_> [ddnet] It sounds safe, but it definitely throws of my in-brain concurrency analyzer 😛 12:30 <+bridge_> [ddnet] 😄 12:30 <+bridge_> [ddnet] s\/of/off/ 12:30 <+bridge_> [ddnet] but why m_pClient is a protected member variable, all components have access to it, why the indirect way over the function call? For access from outside I understand that. Is it about readability or is there another reason? 12:31 <+bridge_> [ddnet] @Not Keks Oh you are checking m_Started, so it's 2 conds 2 condvars but one is sorta guarding 2 conds 12:32 <+bridge_> [ddnet] Maybe just assume best case and spin on m_Started? That's what a futex would do aswell 12:32 <+bridge_> [ddnet] if both wait for the same condition, maybe it's because the lock order is not the same in both? 12:33 <+bridge_> [ddnet] Since it's a one direction change you can also sleep if you don't want to be busy waiting for it, though it might be better not to yield to the scheduler anyway since the gfx thread will come up very quickly anyway, might aswell keep the cpu 12:34 <+bridge_> [ddnet] i'll just use 1 cond, its not unsafe to have 2 conditions. they are chronological split 12:34 <+bridge_> [ddnet] 12:34 <+bridge_> [ddnet] started never occurs afterwards anymore 12:37 <+bridge_> [ddnet] easier refactoring is usually the reason 12:44 <+bridge_> [ddnet] now that i think about it, i think thats exactly the problem 12:44 <+bridge_> [ddnet] so you are right 12:44 <+bridge_> [ddnet] i forgot that condition variables only work bcs they are atomic as soon as you call notify or wait 12:44 <+bridge_> [ddnet] and this isnt given with 2 different ones 12:44 <+bridge_> [ddnet] \\o/ 12:44 <+bridge_> [ddnet] independent of the mutex 12:46 <+bridge_> [ddnet] If you are looking to do m_Started another way, maybe craft an empty buffer and the gfx thread can immediately finish it and set the buffer to nullptr letting you know it's ready for more 12:46 <+bridge_> [ddnet] One less variable too 12:47 <+bridge_> [ddnet] xd i think i'll let deen test for now 12:47 <+bridge_> [ddnet] dont want to overkill for now 12:47 <+bridge_> [ddnet] Makes sense, hopefully that fixes it up 13:00 <+bridge_> [ddnet] @Not Keks do you happen to know why this happens? 13:00 <+bridge_> [ddnet] https://cdn.discordapp.com/attachments/293493549758939136/955435748323106856/screenshot_2022-03-12_19-33-42.png 13:00 <+bridge_> [ddnet] what opengl 13:02 <+bridge_> [ddnet] Apparently happens with gl3, @Cøke suggested disabling it would fix it in his map testing channel 13:02 <+bridge_> [ddnet] then its the asset itself i'd say 13:02 <+bridge_> [ddnet] I was just a bit concerned whether a lot of maps exhibit this and testers just disable gl3 instead 😄 13:02 <+bridge_> [ddnet] or driver 13:02 <+bridge_> [ddnet] Nothing wrong with the tileset lol 13:02 <+bridge_> [ddnet] It's Client side 13:03 <+bridge_> [ddnet] Can you post the tileset so @Not Keks can take a look? 13:03 <+bridge_> [ddnet] U can exteact 13:03 <+bridge_> [ddnet] I'm not at PC rn 13:03 <+bridge_> [ddnet] U can extract 13:03 <+bridge_> [ddnet] I wonder if we have an issue with borderfix or dilate 13:04 <+bridge_> [ddnet] It happens for some more ppl who got a old client or opengl3 13:04 <+bridge_> [ddnet] It happens for some more ppl who got a old client or opengl 13:04 <+bridge_> [ddnet] It happens for some more ppl who got a old client or opengl on 13:06 <+bridge_> [ddnet] It's normal 1024x1024 13:06 <+bridge_> [ddnet] 64x64 tiles 13:06 <+bridge_> [ddnet] It's the same I used in multeasy btw 13:10 <+bridge_> [ddnet] it's 960x960, looks messed up only on gl1 for me 13:11 <+bridge_> [ddnet] Looking messed up on gl1 sounds like it hasn't been borderfixed, but honestly I don't even know if you are supposed to borderfix now 13:12 <+bridge_> [ddnet] @Not Keks I keep forgetting, what is the state of the two renderers? Are they supposed to be giving identical results on a frame by frame basis? 13:12 <+bridge_> [ddnet] nope, borderfixed tilesets will look messed up on anything newer than gl1 13:13 <+bridge_> [ddnet] And non-borderfixed ones look broken on gl1 still? 13:13 <+bridge_> [ddnet] ofc 13:13 <+bridge_> [ddnet] but in this case it looks more messed up than just no borderadd 13:13 <+bridge_> [ddnet] gl must have difficulty with this resolution for some reason 13:14 <+bridge_> [ddnet] closer look 13:14 <+bridge_> [ddnet] https://cdn.discordapp.com/attachments/293493549758939136/955439244686549033/screenshot_2022-03-21_13-13-56.png 13:14 <+bridge_> [ddnet] Yeah that's why this caught my eye. It looked very wrong for some reason 13:15 <+bridge_> [ddnet] I used normal 1024x1024 13:15 <+bridge_> [ddnet] Idk why this happens 13:15 <+bridge_> [ddnet] pipou must have exported at the wrong resolution when he edited it I guess 13:15 <+bridge_> [ddnet] Only Jupstar, master of all 3 gfx backends can save the world 13:15 <+bridge_> [ddnet] yeah trust opengl 3.3 xd 13:15 <+bridge_> [ddnet] That idk, I just fixed the bugged spikes 13:16 <+bridge_> [ddnet] looks similar to skins that aren't divisible btw, pixelly af 13:16 <+bridge_> [ddnet] so 13:16 <+bridge_> [ddnet] opengl 3.3 13:16 <+bridge_> [ddnet] 3.0 13:16 <+bridge_> [ddnet] and 2.x 13:16 <+bridge_> [ddnet] should all render it correclty 13:16 <+bridge_> [ddnet] 13:16 <+bridge_> [ddnet] 2.x has no mipmaps so it might look oversharp 13:16 <+bridge_> [ddnet] 13:16 <+bridge_> [ddnet] gl 1.x defs looks shit 13:16 <+bridge_> [ddnet] But why it's fine for me? 13:16 <+bridge_> [ddnet] Just don't use the 3.3 13:16 <+bridge_> [ddnet] XD 13:16 <+bridge_> [ddnet] what is your GPU? 13:16 <+bridge_> [ddnet] my opengl 1.0 13:16 <+bridge_> [ddnet] buy new pc xd 13:17 <+bridge_> [ddnet] use software opengl renderer 13:17 <+bridge_> [ddnet] no 13:17 <+bridge_> [ddnet] 3.3 is the reference btw, that's what you should be testing on as it's probably going to become the default soon-ish 13:17 <+bridge_> [ddnet] directx 10 13:17 <+bridge_> [ddnet] plz add 13:17 <+bridge_> [ddnet] XD 13:17 <+bridge_> [ddnet] we have vulkan, thats enough 13:17 <+bridge_> [ddnet] Why should we test 3.3 when I don't even use this 13:17 <+bridge_> [ddnet] Xf 13:18 <+bridge_> [ddnet] @Cøke open client, press f1 and see what your GPU is 13:18 <+bridge_> [ddnet] in purple 13:19 <+bridge_> [ddnet] gl1 looks shit on all newer maps tbh 13:19 <+bridge_> [ddnet] its 1% of users xd 13:19 <+bridge_> [ddnet] and they probs have some weird 4:3 monitors 13:19 <+bridge_> [ddnet] Because gl1 renderer is almost never the one chosen, so we want the maps to look correct for everyone not the few people that has to use gl1 because of hw/driver issues 13:19 <+bridge_> [ddnet] just ignore xd 13:19 <+bridge_> [ddnet] It's like I have to test a map for ppl with weak PC :troll: idk if they can load it or not, how should I check it 13:19 <+bridge_> [ddnet] :troll: 13:20 <+bridge_> [ddnet] I bet you also use atleast the gl3 renderer. Almost no one ends up with 1 or even 2 picked 13:20 <+bridge_> [ddnet] only intel GPUs on windows doent use GL 3.0 thats true 13:20 <+bridge_> [ddnet] default is 3.0 13:20 <+bridge_> [ddnet] I used nothing, I just fixed the spike 13:20 <+bridge_> [ddnet] Not the 3.3 if you unchecked it I guess. Idk how the settings work now 13:20 <+bridge_> [ddnet] many do not have open-angle version 3.3 13:20 <+bridge_> [ddnet] YAY 13:20 <+bridge_> [ddnet] yeah unchecking makes it 3.0 13:20 <+bridge_> [ddnet] maybe it's possible to make a workaround in gl1 to fix this borderadd bug? seems like just some issue with texture coords 13:20 <+bridge_> [ddnet] Ich habe aber AMD @Not Keks 13:21 <+bridge_> [ddnet] latest client? 13:21 <+bridge_> [ddnet] Ne aber relativ neu 13:21 <+bridge_> [ddnet] anyway, then its a driver bug 3.0 and 3.3 use the same shader 13:21 <+bridge_> [ddnet] i dont see why they should look different at all 13:22 <+bridge_> [ddnet] (for tile maps to be precise) 13:22 <+bridge_> [ddnet] Wym? For a gpu not to support opengl 3.3 you need to go back like 3 decades 13:23 <+bridge_> [ddnet] no 13:23 <+bridge_> [ddnet] can you post your hardware? 13:23 <+bridge_> [ddnet] oka 13:23 <+bridge_> [ddnet] But I wonder why the old tileset works, just for a few ppl with very old client doesn't work 13:23 <+bridge_> [ddnet] The tileset from Multeasy 13:24 <+bridge_> [ddnet] old client = broken 13:24 <+bridge_> [ddnet] anything before ddnet 14 should be broken 13:24 <+bridge_> [ddnet] https://cdn.discordapp.com/attachments/293493549758939136/955441706239660072/unknown.png 13:24 <+bridge_> [ddnet] win7 is out of life 13:24 <+bridge_> [ddnet] no 13:24 <+bridge_> [ddnet] NO 13:24 <+bridge_> [ddnet] just accept the truth 13:24 <+bridge_> [ddnet] the industry doesnt wait for win7 for ever 13:24 <+bridge_> [ddnet] NOOO 13:25 <+bridge_> [ddnet] @eeetadam so you don’t have a gpu? Just integrated gfx? 13:25 <+bridge_> [ddnet] ye 13:25 <+bridge_> [ddnet] pc 2007 year 13:25 <+bridge_> [ddnet] 2008* 13:25 <+bridge_> [ddnet] intel says its form 2009, it should actually atleast have GL 2.1 13:25 <+bridge_> [ddnet] So many blocked massages lol 13:26 <+bridge_> [ddnet] :cammo: 13:26 <+bridge_> [ddnet] no it's edited and the one with new spikes is 960x960 13:26 <+bridge_> [ddnet] switch to linux then it might work xd 13:26 <+bridge_> [ddnet] Ok idk why pipou did this 13:26 <+bridge_> [ddnet] no 13:27 <+bridge_> [ddnet] then use software rendering or accept that your pc is dead 13:27 <+bridge_> [ddnet] i bet the integrated GPU isnt much faster than the CPU 13:27 <+bridge_> [ddnet] I guess there are iGPUs that are 1.5 decades old that don’t support 3.3 13:27 <+bridge_> [ddnet] What u mean edited 13:27 <+bridge_> [ddnet] tried 13:27 <+bridge_> [ddnet] But 2.1 still renders the same way so mappers should test on 3.3 13:28 <+bridge_> [ddnet] https://github.com/pal1000/mesa-dist-win/releases/download/22.0.0-2/mesa3d-22.0.0-r2-release-msvc.7z 13:28 <+bridge_> [ddnet] 13:28 <+bridge_> [ddnet] unpack this, copy all .dll into ddnet directory 13:28 <+bridge_> [ddnet] 13:28 <+bridge_> [ddnet] x86 for 32bit 13:28 <+bridge_> [ddnet] x64 for 64bit 13:28 <+bridge_> [ddnet] @Cøke it was opened, altered and saved again 13:28 <+bridge_> [ddnet] >DDraceNetwork always welcomes creative maps you made and ideas for new DDRace features you have. 13:28 <+bridge_> [ddnet] https://github.com/ddnet/ddnet/issues/4855 13:29 <+bridge_> [ddnet] why not use directix instead of opengle? 13:29 <+bridge_> [ddnet] I have used another for clues, but deleted the complete old one 13:30 <+bridge_> [ddnet] why not use directx instead of opengl? 13:30 <+bridge_> [ddnet] :troll: 13:30 <+bridge_> [ddnet] when jupstar finishes vulkan and is bored again :troll: 13:30 <+bridge_> [ddnet] we have vulkan, why bother with dx 13:30 <+bridge_> [ddnet] intel core 2 duo lmao 13:30 <+bridge_> [ddnet] why downgrade rendering for a person that wants to stick to win7 so desperatly xd 13:31 <+bridge_> [ddnet] Bei mir kommt morgens auch immer der Vulkan aufn pott 13:31 <+bridge_> [ddnet] u can buy a raspberry pi 4 for 50€ and have a better pc 13:31 <+bridge_> [ddnet] ttrue xd 13:32 <+bridge_> [ddnet] we do not embrace propietary 13:32 <+bridge_> [ddnet] HEHEHEHA 13:32 <+bridge_> [ddnet] iif u have a pc from 2008 its ur fault 13:32 <+bridge_> [ddnet] xd 13:32 <+bridge_> [ddnet] i am always suprised these machines still work 13:33 <+bridge_> [ddnet] i'd assume the coolers fail at some point 13:33 <+bridge_> [ddnet] well maybe rly old processors dont heat that much 13:33 <+bridge_> [ddnet] yes 13:33 <+bridge_> [ddnet] @Not Keks https://www.youtube.com/watch?v=C4YPcDeyYd0 13:33 <+bridge_> [ddnet] 120 13:33 <+bridge_> [ddnet] there u have 13:33 <+bridge_> [ddnet] ok and 2008 is also "just" 14 years xd 13:33 <+bridge_> [ddnet] degrees 13:33 <+bridge_> [ddnet] 120 degrees 13:34 <+bridge_> [ddnet] I wonder if he can even run win10 tbf. What even is a core2duo at this point 13:34 <+bridge_> [ddnet] its better to use linux 13:34 <+bridge_> [ddnet] no 13:34 <+bridge_> [ddnet] yeah for old hardware its a must have 13:34 <+bridge_> [ddnet] yes 13:34 <+bridge_> [ddnet] n 13:34 <+bridge_> [ddnet] except you playing win98 games xD 13:34 <+bridge_> [ddnet] Wtf 13:34 <+bridge_> [ddnet] this guy is just trolling 13:35 <+bridge_> [ddnet] i know 13:35 <+bridge_> [ddnet] I can’t upgrade to win11 because my mobo from 2014 doesn’t have a TPM 13:35 <+bridge_> [ddnet] there is no benefit anyway 13:35 <+bridge_> [ddnet] yay 13:35 <+bridge_> [ddnet] 200 degrees 13:35 <+bridge_> [ddnet] u will get #ads in ur file browser 13:35 <+bridge_> [ddnet] nice 13:35 <+bridge_> [ddnet] Win98 games work like a charm under wine 13:35 <+bridge_> [ddnet] yeah except if they have CD lock 13:35 <+bridge_> [ddnet] that always sucks hard 13:35 <+bridge_> [ddnet] I don’t want to anyway, so it’s good that there is something stopping it from auto upgrading while I sleep 13:35 <+bridge_> [ddnet] @Learath2 use https://reactos.org/ 13:35 <+bridge_> [ddnet] to play old win games 13:35 <+bridge_> [ddnet] xd 13:36 <+bridge_> [ddnet] I remember downloading NoCD patches when I was a young lad 13:36 <+bridge_> [ddnet] https://cdn.discordapp.com/attachments/293493549758939136/955444829515567134/2022-03-21_13_36_29-DDNet_Client.png 13:36 <+bridge_> [ddnet] https://cdn.discordapp.com/attachments/293493549758939136/955444840068444160/2022-03-21_13_35_45-DDNet_Client.png 13:36 <+bridge_> [ddnet] WTF HOLY JESUS 13:36 <+bridge_> [ddnet] modern opengl OFF 13:37 <+bridge_> [ddnet] whats with this guy reaction 13:37 <+bridge_> [ddnet] hehehe 13:37 <+bridge_> [ddnet] https://cdn.discordapp.com/attachments/293493549758939136/955444993387028490/unknown.png 13:37 <+bridge_> [ddnet] oka 13:37 <+bridge_> [ddnet] How is he getting 4.6 with modern gl off @Not Keks? 13:37 <+bridge_> [ddnet] :greenthing: 13:37 <+bridge_> [ddnet] https://cdn.discordapp.com/attachments/293493549758939136/955445013339316254/unknown.png 13:37 <+bridge_> [ddnet] im dead 13:37 <+bridge_> [ddnet] . 13:38 <+bridge_> [ddnet] why r u on rc 13:38 <+bridge_> [ddnet] when 15.9.1 is out 13:38 <+bridge_> [ddnet] i dont like manual update 13:39 <+bridge_> [ddnet] and a new version was bugged for me so i changed back 13:39 <+bridge_> [ddnet] whats the bug 13:41 <+bridge_> [ddnet] it's been a while i don't know exactly, but what i can remember is that the editor crashed often 13:41 <+bridge_> [ddnet] worked over hours on a map -> crash -> all for nothing so i changed to the better version :justatest: 13:41 <+bridge_> [ddnet] bruhs 13:41 <+bridge_> [ddnet] https://cdn.discordapp.com/attachments/293493549758939136/955446117397581904/unknown.png 13:42 <+bridge_> [ddnet] this reminded me of https://www.gamingonlinux.com/2021/10/58-sales-and-over-38-of-bug-reports-from-linux-said-one-dev-but-its-been-helpful/ 13:47 <+bridge_> [ddnet] @Not Keks come on test server 13:48 <+bridge_> [ddnet] i changed to 1024x1024 and looks like the same 13:48 <+bridge_> [ddnet] still opengl off 14:21 <+bridge_> [ddnet] wtf how did it try directx 12 first, guess mesa 22 changed smth 😄 sry didnt know 14:22 <+bridge_> [ddnet] ok 14:22 <+bridge_> [ddnet] its just a string reported by the driver, not the chosen backend 14:22 <+bridge_> [ddnet] ok 14:26 <+bridge_> [ddnet] ogl 1.x 14:26 <+bridge_> [ddnet] https://cdn.discordapp.com/attachments/293493549758939136/955457366441222214/screenshot_2022-03-21_14-25-10.png 14:26 <+bridge_> [ddnet] 3.0 14:26 <+bridge_> [ddnet] https://cdn.discordapp.com/attachments/293493549758939136/955457379389022259/screenshot_2022-03-21_14-25-31.png 14:26 <+bridge_> [ddnet] 3.3 14:26 <+bridge_> [ddnet] https://cdn.discordapp.com/attachments/293493549758939136/955457402134736976/screenshot_2022-03-21_14-25-48.png 14:26 <+bridge_> [ddnet] vulkan (not implemented by AMD, so maybe interesting) 14:26 <+bridge_> [ddnet] https://cdn.discordapp.com/attachments/293493549758939136/955457454089588826/screenshot_2022-03-21_14-26-07.png 14:27 <+bridge_> [ddnet] except 1.x i dont really see a difference 14:27 <+bridge_> [ddnet] @Cøke 14:32 <+bridge_> [ddnet] are they meant to look any different? or being the same the best route? 14:32 <+bridge_> [ddnet] Being same is good 14:39 <+bridge_> [ddnet] ? 14:39 <+bridge_> [ddnet] what should i look at 15:14 <+bridge_> [ddnet] hllo I didn't use the leak command on f1 but my client seem to use the old way (I don't see EUR, etc.. but ping), any idea? 15:15 <+bridge_> [ddnet] After you connect once to a server the ping will be cached, maybe that's what you are seeing 15:17 <+bridge_> [ddnet] @Learath2 I didn't connect to all servers from the list 15:20 <+bridge_> [ddnet] and why is this now bugged? 15:20 <+bridge_> [ddnet] used now 1024x1024 15:20 <+bridge_> [ddnet] wait i come 15:35 <+bridge_> [ddnet] @deen i think we need to select which switch statement we want to assert and which are inoffensive 15:37 <+bridge_> [ddnet] yeah, probably 15:38 <+bridge_> [ddnet] that's the difficult choice 😄 15:40 <+bridge_> [ddnet] can't you set a grep to look for all the dbg_msg to see if they are often triggerred? 15:43 <+bridge_> [ddnet] how do i reset mouse sensor value back to normal 15:43 <+bridge_> [ddnet] i used bind x "+toggle inp_mousesens 1 100000000" 15:44 <+bridge_> [ddnet] in practice no one does that, but when server crashes it gets noticed 15:44 <+bridge_> [ddnet] inp_mousesens 200 15:44 <+bridge_> [ddnet] and with just a dbg_msg it can be difficult to debug, a coredump helps more 15:46 <+bridge_> [ddnet] ♥️ 15:47 <+bridge_> [ddnet] :heartw: :heartw: 15:47 <+bridge_> [ddnet] finally xd 15:47 <+bridge_> [ddnet] now i can rebase all my stuff xD 15:48 <+bridge_> [ddnet] @deen for the changelog you can also add that the video renderer got an upgrade, wanna see if it runs correctly for everyone 15:48 <+bridge_> [ddnet] then they might purposly test it 15:49 <+bridge_> [ddnet] Oooh we have a VK backend now 15:50 <+bridge_> [ddnet] @Cellegen | HU do you own the generic unhookable as SVG? and if, are they accurate? 16:09 <+bridge_> [ddnet] :justatest: 16:09 <+bridge_> [ddnet] i can make it today if you want 16:11 <+bridge_> [ddnet] poggers 16:11 <+bridge_> [ddnet] vulkan by jupstar 16:11 <+bridge_> [ddnet] :BASED: 🍷 16:11 <+bridge_> [ddnet] time to celebrate 16:11 <+bridge_> [ddnet] 16:12 <+bridge_> [ddnet] and also time to find broken drivers 16:13 <+bridge_> [ddnet] doesnt it build artifacts 16:13 <+bridge_> [ddnet] the checks 16:13 <+bridge_> [ddnet] i dont to compile on windows 16:14 <+bridge_> [ddnet] wanna compare 16:15 <+bridge_> [ddnet] found it 16:15 <+bridge_> [ddnet] https://github.com/ddnet/ddnet/suites/5738919643/artifacts/190259741 16:16 <+bridge_> [ddnet] i dont want to compile on windows 16:17 <+bridge_> [ddnet] is it normal i defaults to opengl 3? 16:18 <+bridge_> [ddnet] 2200 fps on a full mult server 16:19 <+bridge_> [ddnet] https://cdn.discordapp.com/attachments/293493549758939136/955485716207534120/unknown.png 16:19 <+bridge_> [ddnet] its poggers 16:20 <+bridge_> [ddnet] @Not Keks does it give more fps to increase the render thread count 16:20 <+bridge_> [ddnet] more consistent frames probs 16:20 <+bridge_> [ddnet] mine is at 3 16:21 <+bridge_> [ddnet] i guess u set it at half of real cores 16:23 <+bridge_> [ddnet] thinking about making accurate gameskin svg 16:23 <+bridge_> [ddnet] thinking about making accurate gameskin svg today 16:25 <+bridge_> [ddnet] ah yes, finally somebody helps 😛 16:26 <+bridge_> [ddnet] no i set it to 3 always 16:26 <+bridge_> [ddnet] 3 gives really good results already 16:26 <+bridge_> [ddnet] on ARM theoretically it can improve efficiency to use more cores 16:26 <+bridge_> [ddnet] @Not Keks 16:26 <+bridge_> [ddnet] since its not more work 16:26 <+bridge_> [ddnet] a intel core 2 duo 16:27 <+bridge_> [ddnet] just same work on all cores 16:27 <+bridge_> [ddnet] with 3 render threads 16:27 <+bridge_> [ddnet] :monkalaugh: 16:27 <+bridge_> [ddnet]