00:10 <+bridge_> [ddnet] I wonder how such a big outage could ever happen 00:13 <+bridge_> [ddnet] was the intern making the change 00:15 <+bridge_> [ddnet] windows updates 00:15 <+bridge_> [ddnet] xd 00:16 <+bridge_> [ddnet] if it was one guy they are getting their ass kicked for the millions they cost mr zucc 00:17 <+bridge_> [ddnet] i guess its not even that bad for them, its been through all news, good free marketing 00:20 <+bridge_> [ddnet] cosmic rays 00:20 <+bridge_> [ddnet] - veritasium 00:20 <+bridge_> [ddnet] https://tsfreddie.itch.io/nuclearcell 00:20 <+bridge_> [ddnet] you know what? at that scale cosmic rays would be the only explanation I'd forgive the intern for 00:20 <+bridge_> [ddnet] new game 00:21 <+bridge_> [ddnet] i'd blame the person that didnt buy ecc RAM 00:21 <+bridge_> [ddnet] ran out of debugging time at the end. might be horribly broken. :justatest: 00:25 <+bridge_> [ddnet] the power bricks just fall off the screen wtf 00:26 <+bridge_> [ddnet] just attach another power connector xd 00:27 <+bridge_> [ddnet] you have to line it up exactly 00:27 <+bridge_> [ddnet] You guys made it so vali can't ddos teeworlds and 1st thing he does is ddos facebook i hope ur happy 😤 😤 😤 00:28 <+bridge_> [ddnet] I hope, unlike us facebook would have his ass for the millions he cost them 😛 00:29 <+bridge_> [ddnet] also you can recatch the falling bricks. it falls pretty slow for you to catch tbh. 00:41 <+bridge_> [ddnet] sad news facebook is back online :( 06:10 <+bridge_> [ddnet] :justatest: 07:28 <+bridge_> [ddnet] score: 2940 07:37 <+bridge_> [ddnet] nouis 09:50 <+bridge_> [ddnet] wait what did u say ? xD 09:57 <+bridge_> [ddnet] you seem to be just as funny as björn when you ask such questions haha, he is not even noticed without this ddos shit because no one is interested in him. through the ddos notices at all someone that he exists, hope he continues to do it at great sites and moves for it where he belongs 09:58 <+bridge_> [ddnet] you seem to be just as funny as björn when you ask such questions haha, he is not even noticed without this ddos shit because no one is interested in him. through the ddos notices at all someone that he exists, hope he continues to do it at big sites and moves for it where he belongs 10:01 <+bridge_> [ddnet] :pepeH: 10:06 <+bridge_> [ddnet] Whos vali 10:06 <+bridge_> [ddnet] Tell him about kog 10:06 <+bridge_> [ddnet] :troll: 10:10 <+bridge_> [ddnet] i think he is not interested in such small servers 10:14 <+bridge_> [ddnet] hey guys I have this weird problem -- the moment i press the Editor button on the main menu my desktop computer starts making a weird high pitched noise, the moment I exit the editor it instantly stops (I don't know which part is making the noise lmao I've never heard smth like this before) -- it doesn't happen in other uses of my computer, or in other parts of the ddnet client(nvm as I was typing/testing this I realized a similar noise hap 10:14 <+bridge_> [ddnet] lmao this sounds so stupid 10:15 <+bridge_> [ddnet] also it's not the cpu fan spinning too fast, it's barely spinning 10:16 <+bridge_> [ddnet] lmao it only happens in the editor when the UI elements are present (if I press tab to toggle them noise goes away) 10:16 <+bridge_> [ddnet] coil whine 10:16 <+bridge_> [ddnet] this might be interesting for #developer 10:17 <+bridge_> [ddnet] but I don't understand it. might be related to rendering text? 10:17 <+bridge_> [ddnet] can depend on exact power consumption of your gpu 10:17 <+bridge_> [ddnet] how come it's so instant, what happens the moment I press editor that makes it start 10:17 <+bridge_> [ddnet] you can try f1, gfx_refresh_rate and change to another value there, try 0, 480, 120 10:18 <+bridge_> [ddnet] Because your GPU instantly switches to a specific power mode I guess 10:18 <+bridge_> [ddnet] and rendering all the text might be more/less taxing than the normal menu and ingame 10:21 <+bridge_> [ddnet] it was set to 0, I set it to 480 and it went away 10:23 <+bridge_> [ddnet] I also now noticed it happens (to a lesser degree(less noisy), and not at all instant) when in game, a lot harder to notice 10:23 <+bridge_> [ddnet] should editor have capped fps by default? 10:28 <+bridge_> [ddnet] I have this in the entire game and I get different pitches depending on the state of the ui 10:28 <+bridge_> [ddnet] I think it’s bad isolation on the sound output :/ 10:30 <+bridge_> [ddnet] sry i don't get it, what does sound output have to do with this (is there sound in editor)? 10:31 <+bridge_> [ddnet] Oh, you get noise outside? 10:31 <+bridge_> [ddnet] I get it on my speakers and headphone 10:31 <+bridge_> [ddnet] yep, not from the speaker, from the computer itself 10:32 <+bridge_> [ddnet] Sounds like coil whine alright. I don’t really know a way to fix it 10:33 <+bridge_> [ddnet] capping gfx_refresh_rate (i capped it to 480) like deen said solved it 10:33 <+bridge_> [ddnet] Great \o/ 10:35 <+bridge_> [ddnet] Bonus point: You now have lower power consumption 10:36 <+bridge_> [ddnet] :poggers: time to offset that with mining bitcoin 10:39 <+bridge_> [ddnet] feature request: make gfx_refresh_rate 0 placebo, use gpu power that'd be used for 1k fps+ go towards mining ddnet crypto, ez sustainable business model :trollet: 10:42 <+bridge_> [ddnet] You found the one way of making money that's even worse than advertisements, so no thanks 😄 10:42 <+bridge_> [ddnet] https://blog.cloudflare.com/october-2021-facebook-outage/ cloudflares blog posts are so nice to read. They have some people that write so good 10:44 <+bridge_> [ddnet] Because their blog targets potential employees, not potential customers 10:46 <+bridge_> [ddnet] Btw apparently the root issue was an invalid configuration value in persistent storage, causing the configuration validator to keep going off when it finds an invalid cached config value. Feedback loop 😛 10:48 <+bridge_> [ddnet] which caused their bgp sessions to go down 🙂 10:48 <+bridge_> [ddnet] which caused their bgp sessions to go down 🙂 10:48 <+bridge_> [ddnet] And took down the database that was hosting the config 😄 10:50 <+bridge_> [ddnet] An interesting failure though, I’m sure their blog post was simplified but it sounds like bad engineering practice to do a database query when you find an invalid config value. Shouldn’t you be pushing these changes rather than polling them? 10:54 <+bridge_> [ddnet] Oh and the amount of data dns hosters get is insane, I never quite considered how much they can track 10:58 <+bridge_> [ddnet] Ah the config thing I read was a previous post-mortem, nvm. So it’s still unknown what actually happened. Someone nuked the routing table? 😛 11:15 <+bridge_> [ddnet] > Fortunately, 1.1.1.1 was built to be Free, Private, Fast (as the independent DNS monitor DNSPerf can attest), and scalable, and we were able to keep servicing our users with minimal impact. 11:15 <+bridge_> [ddnet] never miss a oportunity to add self flattery 11:15 <+bridge_> [ddnet] :bluekitty: 11:32 <+bridge_> [ddnet] https://youtu.be/2S2v45_NSYs 11:32 <+bridge_> [ddnet] the fact u need a vid is hilarious 11:32 <+bridge_> [ddnet] You know we have went wrong somewhere along history if people need to make videos like this 11:32 <+bridge_> [ddnet] :monkalaugh: 11:36 <+bridge_> [ddnet] my covid vaccine has coil whine help 11:37 <+bridge_> [ddnet] [marked as duplicate] 11:48 <+bridge_> [ddnet] I wanted to get one of those biohax chips in my hand actually, but I don't think I can put it there myself without lidocaine 14:00 <+bridge_> [ddnet] just buy some fancy 8k GPU for 5000 dollars, it will be so underloaded by teeworlds that it won't consume alot of power 14:00 <+bridge_> [ddnet] (@Cipy29) 14:00 <+bridge_> [ddnet] for me the diff between 1k fps and 500fps ingame is under 10 watts 14:01 <+bridge_> [ddnet] and my card has a TDP of like 300 Watts 14:09 <+bridge_> [ddnet] but fps caps for different context sound good, editor & menu vs ingame & demos 14:09 <+bridge_> [ddnet] Maybe we should add it 14:12 <+bridge_> [ddnet] the question is always, what is a good default value xD 14:12 <+bridge_> [ddnet] 14:12 <+bridge_> [ddnet] vsync would probably the best for such stuff 14:12 <+bridge_> [ddnet] 14:12 <+bridge_> [ddnet] But we also know the display's refresh rate now 14:37 <+bridge_> [ddnet] hey @Learath2 14:37 <+bridge_> [ddnet] any idea where in the source code it does the serverinfo request? 14:39 <+bridge_> [ddnet] `CServer::SendServerInfo` is what sends it, but `UpdateServerInfo` -> `CacheServerInfo` is what generates it. It's only generated when something about the server changes 14:43 <+bridge_> [ddnet] Trying to cache the packet using a hardcoded request 14:43 <+bridge_> [ddnet] but it doesn't seem to respond at all 14:50 <+bridge_> [ddnet] Hm, if you show me the request I can take a look at it, but caching at the firewall for too long doesn't sound like a great idea to me 14:51 <+bridge_> [ddnet] The new central serverlist is already fairly stale (5s) If it gets cached for longer on the firewall it'll lead to extended periods of stale serverinfo 14:52 <+bridge_> [ddnet] 30s 14:52 <+bridge_> [ddnet] this is just for older clients anyway 14:52 <+bridge_> [ddnet] anyway, I just hardcoded 14:52 <+bridge_> [ddnet] `\x78\x65\x5b\x06\x00\x00\xff\xff\xff\xff\x67\x69\x65\x33\xdb` 14:53 <+bridge_> [ddnet] the central serverlist also uses the serverinfo request for now, until @heinrich5991 finishes up the server part 14:53 <+bridge_> [ddnet] seems the first 4 bytes are random 14:53 <+bridge_> [ddnet] and the last byte too 14:53 <+bridge_> [ddnet] thats whitelisted 14:53 <+bridge_> [ddnet] so that won't be cached 14:54 <+bridge_> [ddnet] tbh, I could probably make the current protection less "aggressive" 14:55 <+bridge_> [ddnet] which means it would allow all traffic, until an attack starts 14:55 <+bridge_> [ddnet] players who are already connected will stay connected 14:55 <+bridge_> [ddnet] but until the ddos attack is going on, only newer clients can join 14:55 <+bridge_> [ddnet] but while the ddos attack is going on, only newer clients can join 14:55 <+bridge_> [ddnet] `src/engine/shared/network.h` documents the packet header, it shouldn't be random 14:55 <+bridge_> [ddnet] its a random "token" 14:56 <+bridge_> [ddnet] sha1 apparently 14:56 <+bridge_> [ddnet] The last byte is a token in that packet 14:56 <+bridge_> [ddnet] well 14:56 <+bridge_> [ddnet] from 3 samples 14:56 <+bridge_> [ddnet] the packet looks like this 14:56 <+bridge_> [ddnet] 2 bytes of extra token, 1 byte of basic token, those should be the only random things there 14:57 <+bridge_> [ddnet] "78 65 5b 06 00 00 ff ff ff ff 67 69 65 33 db" 14:57 <+bridge_> [ddnet] "78 65 27 eb 00 00 ff ff ff ff 67 69 65 33 3e" 14:57 <+bridge_> [ddnet] so yeah 14:57 <+bridge_> [ddnet] buffer[2] and buffer[3] are random 14:57 <+bridge_> [ddnet] and last byte 14:57 <+bridge_> [ddnet] does it matter though? 14:58 <+bridge_> [ddnet] As in, can I just set this to *anything*? 14:58 <+bridge_> [ddnet] random should be fine iirc, but it's been a while since I touched that part of the code 14:59 <+bridge_> [ddnet] well 14:59 <+bridge_> [ddnet] doesn't seem to respond (to me atleast) 15:00 <+bridge_> [ddnet] thoughts? 15:04 <+bridge_> [ddnet] Hm, you can try `debug 1` on the server to see if any error is triggered, or you can add some `dbg_msg` along the path. I need to go take care of some personal stuff 15:05 <+bridge_> [ddnet] This sounds like a good idea, but how would you extract the list of established clients from the gameserver? Will you just keep the filter monitoring? 15:05 <+bridge_> [ddnet] Pretty much 15:06 <+bridge_> [ddnet] I won't really be able to explain the entire thing, but It'll be able to seperate connected players from other traffic 100% 15:08 <+bridge_> [ddnet] Was related to sport 16:14 <+bridge_> [ddnet] @Fän yes, can be set to anything 16:17 <+bridge_> [ddnet] figured. tyvm 16:34 < afterfx> test 16:35 <@heinrich5991> bye afterfx 16:35 <+bridge_> [ddnet] man. 16:37 <+bridge_> [ddnet] hm? 16:37 <+bridge_> [ddnet] afterfx was already gone before I could say anything 16:37 <+bridge_> [ddnet] test unsuccessful then 16:44 <+bridge_> [ddnet] https://skins.tw/how-to/ddnet-integration 16:44 <+bridge_> [ddnet] > This does not longer work with Steam. DDNet had to remove this feature for the steam version, since it conflicts terms of services. 16:44 <+bridge_> [ddnet] > You can still use the downloadable version on DDNet's website. 16:44 <+bridge_> [ddnet] we don't support `cl_skin_download_url` on steam? 16:45 <+bridge_> [ddnet] we do 16:47 <+bridge_> [ddnet] we just don't provide skins that's all 16:53 <+bridge_> [ddnet] @NeXus ^ 17:30 <+bridge_> [ddnet] @Learath2 could you test https://github.com/ddnet/ddnet/pull/4095 on macos? 17:30 <+bridge_> [ddnet] mh, it's so hard to compile on macOS 17:31 <+bridge_> [ddnet] let me give it a quick try 17:33 <+bridge_> [ddnet] while you at it, can you test the client with HiDPI off? 17:34 <+bridge_> [ddnet] wörk wörk 17:34 <+bridge_> [ddnet] to see if SDL fixed the weird bug i send a few weeks ago 17:35 <+bridge_> [ddnet] wurk wurlk 17:35 <+bridge_> [ddnet] we abuse Learath, bcs no other macos dev that takes the time \<.\< 17:35 <+bridge_> [ddnet] wurk wurk 17:35 <+bridge_> [ddnet] I do have macOS 17:35 <+bridge_> [ddnet] but I cba 17:35 <+bridge_> [ddnet] do we even have another developer with macos? 17:36 <+bridge_> [ddnet] apparently Fän 17:36 <+bridge_> [ddnet] I still have to do `sed -i "" 's/11\.0/10.15/g' CMakeCache.txt` so damn annoying 17:36 <+bridge_> [ddnet] only "dev" i do on macOS is *sometimes* C in vscode 17:36 <+bridge_> [ddnet] and I have to delete the bundled sdl so it will stop linking to it 17:37 <+bridge_> [ddnet] Can whoever is doing this 17:37 <+bridge_> [ddnet] stop ddosing the server while I'm still working on it 17:37 <+bridge_> [ddnet] <.< 17:37 <+bridge_> [ddnet] i dont even understand why its so hard to compile under macos \:D, we dont really have troublesome libs imo 17:37 <+bridge_> [ddnet] It's macOS 17:37 <+bridge_> [ddnet] everything is hard under macos 17:37 <+bridge_> [ddnet] ok best argument 17:38 <+bridge_> [ddnet] have to admit 17:38 <+bridge_> [ddnet] pkg-config is provided by homebrew, which will cause wrong sdk paths to end up in the includes 17:38 <+bridge_> [ddnet] ok who ever tf is ddosing 17:38 <+bridge_> [ddnet] stop it 17:38 <+bridge_> [ddnet] get some help 17:38 <+bridge_> [ddnet] I'm trying to work here 17:38 <+bridge_> [ddnet] <.< 17:38 <+bridge_> [ddnet] isn't this like any normal day for you? 😄 17:38 <+bridge_> [ddnet] It is 17:38 <+bridge_> [ddnet] but usually I don't work on it 17:38 <+bridge_> [ddnet] but usually I don't work on it actively 17:38 <+bridge_> [ddnet] while being attacked 17:39 <+bridge_> [ddnet] mh, #4095 doesn't work on macOS 17:39 <+bridge_> [ddnet] https://github.com/ddnet/ddnet/pull/4095 17:39 <+bridge_> [ddnet] not sure how to help you debug it though 17:40 <+bridge_> [ddnet] @heinrich5991 `https://master2.ddnet.tw/ddnet/15/servers.json failed. libcurl error: SSL certificate problem: certificate has expired` um why? 17:42 <+bridge_> [ddnet] @Jupstar ✪ I think the problem is that the mouse isn't grabbed at all 17:42 <+bridge_> [ddnet] looks fine from my side 17:42 <+bridge_> [ddnet] Expires on: December 23, 2021 17:43 <+bridge_> [ddnet] hm looks fine on browser but libcurl doesn't agree 17:43 <+bridge_> [ddnet] did you use bundled libs and update the git submodule? 17:43 <+bridge_> [ddnet] (@Learath2) 17:43 <+bridge_> [ddnet] I can't use bundled libs 17:43 <+bridge_> [ddnet] libsdl doesn't include the required patch to even run on macOS without crashing instantly with SIGILL 17:44 <+bridge_> [ddnet] but ingame should still be grabbed shouldnt it? 17:44 <+bridge_> [ddnet] guess thats the most important 17:44 <+bridge_> [ddnet] mh, also the cursor is out of sync with the desktop cursor 17:45 <+bridge_> [ddnet] so I can only get about halfway down the window before my desktop cursor peeks out the botto 17:45 <+bridge_> [ddnet] ingame is still grabbed properly 17:46 <+bridge_> [ddnet] mhh, guess we need someone with current SDL to test 17:46 <+bridge_> [ddnet] that sounds like bug that any SDL dev would instantly catch 17:47 <+bridge_> [ddnet] I mean my own version of sdl is 2.0.16 17:47 <+bridge_> [ddnet] Well what did we add in our bundled build? I'll roll it up to master and add those too 17:47 <+bridge_> [ddnet] but this sounds like a bug that would affect anything in existence 17:47 <+bridge_> [ddnet] (@Learath2) 17:47 <+bridge_> [ddnet] anything that uses SDL 17:48 <+bridge_> [ddnet] if it's not a new bug, other devs might have worked around it 17:48 <+bridge_> [ddnet] I don't know what you do, so I don't know if it would affect everything that uses sdl 17:49 <+bridge_> [ddnet] do you just take the position of the desktop cursor? 17:49 <+bridge_> [ddnet] I mean 17:49 <+bridge_> [ddnet] > libsdl doesn't include the required patch to even run on macOS without crashing instantly with SIGILL 17:49 <+bridge_> [ddnet] also sounds pretty bad 😛 17:49 <+bridge_> [ddnet] it just uses the desktop cursor pos relative to the window 17:49 <+bridge_> [ddnet] It will work if you compile with an older sdk, it makes appkit disable some asserts 17:51 <+bridge_> [ddnet] but i also dunno what tsfreddie added with all this m\_ScreenHiDPIScale stuff 17:51 <+bridge_> [ddnet] disabling highdpi fixes it 17:51 <+bridge_> [ddnet] ok 17:52 <+bridge_> [ddnet] it also makes things look pixellated though 😄 17:52 <+bridge_> [ddnet] why cant we just fetch the window size and the canvas size in macos 17:52 <+bridge_> [ddnet] also it's not the greatest experience since I can sort of escape the "grab" 17:52 <+bridge_> [ddnet] it's not really grabbing anything 17:53 <+bridge_> [ddnet] let me try a patch, and you have to test xd 17:54 <+bridge_> [ddnet] Well as long as you fetch it at the correct time it used to work just fine, which is why I was very skeptical when tsfreddie was doing the dpi stuff. I just didn't interfere because I didn't have the time to investigate or do it myself 17:55 <+bridge_> [ddnet] I have not once in my life seen an airline as janky as brussels airlines 17:56 <+bridge_> [ddnet] I submit documents, the website says you'll receive an automated mail acknowledging the submission, I get no automated mail 17:56 <+bridge_> [ddnet] How do you fail to implement an automatic mail, it's just a function call 17:58 <+bridge_> [ddnet] ok pushed it 18:00 <+bridge_> [ddnet] but i dunno `m_ScreenHiDPIScale` is a float 18:00 <+bridge_> [ddnet] i dont like to rely on floats 18:00 <+bridge_> [ddnet] this really needs an update some day 18:01 <+bridge_> [ddnet] ™ 18:01 <+bridge_> [ddnet] I don't like the fact that we need to even know about whether the underlying canvas is hidpi or not 18:02 <+bridge_> [ddnet] yeah 18:02 <+bridge_> [ddnet] just split to canvas width/height and windows width/height 18:02 <+bridge_> [ddnet] Still doesn't work 18:02 <+bridge_> [ddnet] i mean for displaying resolutions its ok 18:02 <+bridge_> [ddnet] in menus? 18:03 <+bridge_> [ddnet] I can only move the cursor on one quarter of the window, so it does line up with the 2x scaling this monitor has 18:03 <+bridge_> [ddnet] in all menus 18:03 <+bridge_> [ddnet] oh yeah, rip, can you test if it works on editor, just so i know the idea atleast works 18:03 <+bridge_> [ddnet] editor works 18:04 <+bridge_> [ddnet] ok, in menus it saves the state in a var, i'll update it 18:04 <+bridge_> [ddnet] we should also rename "screenwidth" 18:04 <+bridge_> [ddnet] its actually canvas width 18:04 <+bridge_> [ddnet] bit confusing 18:04 <+bridge_> [ddnet] There is one more problem though 18:05 <+bridge_> [ddnet] mac CI is broken. `/Applications/Xcode_12.5.1.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX11.3.sdk/System/Library/Frameworks/ApplicationServices.framework/Frameworks/QD.framework/Headers/ColorSyncDeprecated.h:1761:3: error: unknown type name 'ptrdiff_t'` 18:06 <+bridge_> [ddnet] Idk how best to show it but at the edges of the screen both the desktop and the teeworlds cursor are rendered 18:06 <+bridge_> [ddnet] s\/screen/window/ 18:07 <+bridge_> [ddnet] @heinrich5991 I can take a look if you do a more verbose build 18:07 <+bridge_> [ddnet] I'd like to see CMakeCache.txt and the output of the compiler if you want to give it a go 18:08 <+bridge_> [ddnet] how do I get a more verbose build? this is the output of the compiler: https://github.com/ddnet/ddnet/runs/3804985058 18:09 <+bridge_> [ddnet] I think cmake --build --verbose works, but don't remember 18:09 <+bridge_> [ddnet] or `make VERBOSE=1` is also usable 18:10 <+bridge_> [ddnet] G 18:10 <+bridge_> [ddnet] GER1 is now joinable on all versions 18:10 <+bridge_> [ddnet] 🙂 18:10 <+bridge_> [ddnet] nice 🙂 18:10 <+bridge_> [ddnet] ok updated 18:11 <+bridge_> [ddnet] Just checked `ninja -v` is exactly the output I'm looking or 18:11 <+bridge_> [ddnet] for* 18:11 <+bridge_> [ddnet] Thanks! 18:11 <+bridge_> [ddnet] can confirm 0.7 works 18:12 <+bridge_> [ddnet] @Learath2\: i really dont want to annoy you, but could you also check if```c 18:12 <+bridge_> [ddnet] // SDL_GL_GetDrawableSize reports HiDPI resolution even with SDL_WINDOW_ALLOW_HIGHDPI not set, which is wrong 18:12 <+bridge_> [ddnet] if(SdlFlags & SDL_WINDOW_ALLOW_HIGHDPI) 18:12 <+bridge_> [ddnet] SDL_GL_GetDrawableSize(m_pWindow, pCurrentWidth, pCurrentHeight); 18:12 <+bridge_> [ddnet] else 18:12 <+bridge_> [ddnet] SDL_GetWindowSize(m_pWindow, pCurrentWidth, pCurrentHeight); 18:12 <+bridge_> [ddnet] ```in backend\_sdl.cppis really needed for non HiDPI 18:12 <+bridge_> [ddnet] its like the most random if branch we have 18:12 <+bridge_> [ddnet] SDL\_GL\_GetDrawableSize should always give the canvas size 18:13 <+bridge_> [ddnet] There is a point in the startup where it will return the wrong size :/ 18:13 <+bridge_> [ddnet] I'll check with dbg_msg in a second 18:13 <+bridge_> [ddnet] thats a rather big bug in SDL imo then 18:13 <+bridge_> [ddnet] i just cant imagine they didnt fixed it yet 18:14 <+bridge_> [ddnet] it's more likely an issue in the way apple does gl 18:14 <+bridge_> [ddnet] but SDL could just internally check if HiDPI is on 18:14 <+bridge_> [ddnet] and if not, give the window size 18:14 <+bridge_> [ddnet] having todo it on the user side is very counter intuitive 18:14 <+bridge_> [ddnet] Okay, your latest push works fine 18:15 <+bridge_> [ddnet] now I'll check th ebranch 18:15 <+bridge_> [ddnet] the* 18:16 <+bridge_> [ddnet] yeah, this happens right at startup, I think it's the bug I'm thinking of, but I'll print it out and check anyway 18:16 <+bridge_> [ddnet] time to get SDL dev, so many things that confuse me 18:17 <+bridge_> [ddnet] I think it still triggers a window resize when the correct resolution is available btw, atleast on my resizing branch I never had to think about it after I started reacting on all resize events 18:18 <+bridge_> [ddnet] i think i added support for the correct resize event 18:18 <+bridge_> [ddnet] but tsfreddie probably wants it for the HiDPI variable 18:18 <+bridge_> [ddnet] maybe we should just update that variable on the resize events 18:20 <+bridge_> [ddnet] Um, for me it behaves exactly as expected, @TsFreddie what did you see that made you add this? 18:20 <+bridge_> [ddnet] ```[2021-10-05 18:19:46][dbg]: drawable w=2576 h=1798 18:20 <+bridge_> [ddnet] [2021-10-05 18:19:46][dbg]: window w=1288 h=899``` this is with hidpi on 18:20 <+bridge_> [ddnet] you have to test it with off 18:20 <+bridge_> [ddnet] with hidpi off it returns the same size for both, which is sane 18:20 <+bridge_> [ddnet] yes 18:21 <+bridge_> [ddnet] that sounds correct 18:21 <+bridge_> [ddnet] maybe he tried on SDL 2.0.14 18:21 <+bridge_> [ddnet] what we really want there is the canvas size, right? 18:21 <+bridge_> [ddnet] and it got fixe 18:21 <+bridge_> [ddnet] I'll try just using that see if anything breaks 18:21 <+bridge_> [ddnet] yes 18:22 <+bridge_> [ddnet] actually, can't possibly change anything since we use the drawable size when hidpi 18:22 <+bridge_> [ddnet] but isnt that expected? 18:22 <+bridge_> [ddnet] just use drawable size for both 18:22 <+bridge_> [ddnet] that would be the proper fix 18:23 <+bridge_> [ddnet] Yeah, I mean me actually removing the branch is a useless test, since it can't possibly change anything 18:24 <+bridge_> [ddnet] yeah i want it to be removed, bcs it isnt correct 18:24 <+bridge_> [ddnet] If we remove it lets wait for @TsFreddie to be around so he can check it out 18:24 <+bridge_> [ddnet] on linux the drawable size is smaller, e.g. if you have window decorations 18:24 <+bridge_> [ddnet] e.g. close button 18:24 <+bridge_> [ddnet] Jupstar: any idea on the desktop and tw cursor both being displayed? 18:25 <+bridge_> [ddnet] it means you can interact with the decoration, which is very bad UX. you can resize the window, or move it around 18:25 <+bridge_> [ddnet] or better\: its not clear what the window manager does, when triggering a resize event by ourself 18:25 <+bridge_> [ddnet] when does it happen? 18:25 <+bridge_> [ddnet] (@Learath2) 18:25 <+bridge_> [ddnet] always? 18:26 <+bridge_> [ddnet] in menus only 18:26 <+bridge_> [ddnet] in editor it works? 18:27 <+bridge_> [ddnet] Ah, no it doesn't work there either 18:27 <+bridge_> [ddnet] does `SDL_ShowCursor(false);` fail maybe \:o? 18:28 <+bridge_> [ddnet] it's very weirdly grabbed, like it's not really grabbed but something is at each tick moving the cursor back in bound 18:28 <+bridge_> [ddnet] wtf xD 18:29 <+bridge_> [ddnet] do they teleport the mouse? XD 18:29 <+bridge_> [ddnet] maybe some macOS restriction that they can't properly grab it? idk the apis you use, maybe check the functions see if they document any macOS quirks? 18:29 <+bridge_> [ddnet] I know it's hard to get raw input on macOS 18:29 <+bridge_> [ddnet] well we use `SDL_SetWindowGrab` which sounds correct 18:30 <+bridge_> [ddnet] like if I move my mouse quick enough it'll be outside for a split second 18:30 <+bridge_> [ddnet] if I move it constantly around the edges it'll jitter in and out 18:32 <+bridge_> [ddnet] alternativly dont grab the mouse at all under macos, dunno why this happens 18:32 <+bridge_> [ddnet] how does it work in other games? 18:32 <+bridge_> [ddnet] ever played anything? 18:32 <+bridge_> [ddnet] let me check factorio 18:33 <+bridge_> [ddnet] why would anyone add a messenger link to their company website if they don't intend to have anyone actually watching the chat? 18:37 <+bridge_> [ddnet] factorio doesn't grab the mouse at all, neither in-game nor in menus 18:37 <+bridge_> [ddnet] though their gameplay doesn't require grabbing, ours does 18:38 <+bridge_> [ddnet] but ingame our grabbing works, doesnt it 18:38 <+bridge_> [ddnet] its really a matter of, if non ingame should grab 18:38 <+bridge_> [ddnet] yep, so we just don't grab in menus and it's fine I guess 18:38 <+bridge_> [ddnet] I think I even prefer not grabbing in menus and editor as I said in the PR 18:39 <+bridge_> [ddnet] yeah for editors sounds good tbh 18:39 <+bridge_> [ddnet] but yeah, i cant judge on it 18:39 <+bridge_> [ddnet] in non fullscreen no problem 18:39 <+bridge_> [ddnet] but in fullscreen it will minimize your app xD 18:39 <+bridge_> [ddnet] and windows + opengl = true love 18:40 <+bridge_> [ddnet] so maybe on not enable it on macos 18:40 <+bridge_> [ddnet] since fullscreen doesnt work anyway? 18:43 <+bridge_> [ddnet] wait what? on fullscreen if you don't grab it will minimize? 18:46 <+bridge_> [ddnet] no, clicking outside the window 18:46 <+bridge_> [ddnet] will minimize your app 18:46 <+bridge_> [ddnet] ah on macOS it won't 18:47 <+bridge_> [ddnet] ah I see what you mean, I think even on macOS it would, you mean clicking desktop on a second screen, right? 18:48 <+bridge_> [ddnet] yes 18:49 <+bridge_> [ddnet] which is why borderless fullscreen is superior 18:49 <+bridge_> [ddnet] in many things yes 18:49 <+bridge_> [ddnet] but it usually doesnt disable compositing 18:49 <+bridge_> [ddnet] so less fps, and fps is everything 18:50 <+bridge_> [ddnet] and ofc you couldn't play 5\:4, which some ppl do in this community 18:50 <+bridge_> [ddnet] I don't have a compositor even 😛 18:51 <+bridge_> [ddnet] macos might be fine, windows sucks, KDE too xd 18:51 <+bridge_> [ddnet] with wayland it worked perfect 18:51 <+bridge_> [ddnet] but wayland has forced vsync 18:51 <+bridge_> [ddnet] and rn my system crashes with wayland so cant test anyway xD 18:52 <+bridge_> [ddnet] I thought you need to play 4:3 stretched to be a pro 18:52 <+bridge_> [ddnet] i bet most of these ppl dont even know that they dont have 144hz using such resolutions anymore 18:52 <+bridge_> [ddnet] one of the reasons i added support for it 18:54 <+bridge_> [ddnet] did we update macos for the CI? 18:54 <+bridge_> [ddnet] or random fail 18:56 <+bridge_> [ddnet] not random 18:56 <+bridge_> [ddnet] Learath2 wanted to help me debug it, but I havne't gotten to it yet 18:56 <+bridge_> [ddnet] feel free to try to debug it 18:56 <+bridge_> [ddnet] looks like a SDK fail 18:57 <+bridge_> [ddnet] i just dont understand why it happens rn, what triggered it xd 18:57 <+bridge_> [ddnet] looks like an sdk mixup to me, as in two different versions of the sdk getting both included, but I can't know for sure 18:58 <+bridge_> [ddnet] ok on my local branch it works, i just need to build artifacts 18:58 <+bridge_> [ddnet] not without seeing CMakeCache and/or the verbose build 19:02 <+bridge_> [ddnet] https://github.com/ddnet/ddnet/runs/3805775384 I added output of CMakeCache.txt and verbose build (hopefully) 19:02 <+bridge_> [ddnet] I'll eat some dinner now though 19:07 <+bridge_> [ddnet] @Learath2\: for me it works with the cursor not being shown, only when i try to leave the window 19:07 <+bridge_> [ddnet] then i also get this jittering 19:07 <+bridge_> [ddnet] on macOS? 19:07 <+bridge_> [ddnet] yes 19:08 <+bridge_> [ddnet] mojave 19:08 <+bridge_> [ddnet] whatever version that is 19:09 <+bridge_> [ddnet] the jittering isnt nice, but i think its ok, the 5 users using macos have to live with it xDD 19:10 <+bridge_> [ddnet] nice resizing works fine on macos too 19:11 <+bridge_> [ddnet] i really dont have any major bugs, except that i cant use fullscreen at all 19:11 <+bridge_> [ddnet] not even desktop fullscreen 19:11 <+bridge_> [ddnet] ah wait 19:12 <+bridge_> [ddnet] on this build it even works 19:12 <+bridge_> [ddnet] only not on the nightly built from ddnet.tw 19:12 <+bridge_> [ddnet] is the nightly still using the old libs @deen ? 19:12 <+bridge_> [ddnet] just want to be sure its not our bundled libs 19:15 <+bridge_> [ddnet] @Learath2\: does "real" fullscreen not work for you? 19:15 <+bridge_> [ddnet] nope 19:15 <+bridge_> [ddnet] ok, then i guess its a driver bug 19:15 <+bridge_> [ddnet] It doesn't render anything at all 19:15 <+bridge_> [ddnet] bcs it works with the software renderer 19:15 <+bridge_> [ddnet] it does grab all input including the touchpad though, so it's really hard to quit 19:16 <+bridge_> [ddnet] you need to blindly open the console and type quit 19:16 <+bridge_> [ddnet] ok really weird 19:16 <+bridge_> [ddnet]