00:13 < bridge> [teeworlds] inp_grab 1 is raw mouse input without acceleration from os huh? 00:14 < bridge> [teeworlds] just wanted to make sure because i get confused when i look at the code it says something about warping and it was on 0 for me and i thought its raw by default? 00:15 < bridge> [teeworlds] can i report a bug here in ddnet? 00:16 < bridge> [teeworlds] why not in ddnet discord? 00:21 < bridge> [teeworlds] I am not in ddnet discord, can you invite me? 00:30 < bridge> [teeworlds] thanks 🙂 00:30 < bridge> [teeworlds] hm, adaptive dyn cam funnel cam based on lowest measured ping. 00:31 < bridge> [teeworlds] let me introduce my fake ping 00:31 < bridge> [teeworlds] yeah, how doe sit work, you would either have to send all packets with a letency 00:31 < bridge> [teeworlds] latency 00:31 < bridge> [teeworlds] otherwise your lowest would be used to adapt the funnel 00:32 < bridge> [teeworlds] and you would actually play with a worse, but actually fake ping 00:32 < bridge> [teeworlds] I wonder if there would be an advantage to a real bad ping, maybe the packet loss 00:34 < bridge> [teeworlds] you need to get the ping on a more network place 00:34 < bridge> [teeworlds] is there a dedicated ping packet? 00:34 < bridge> [teeworlds] would need to track ping on every packet, hm k 00:37 < bridge> [teeworlds] I think it's not possible to prevent players from pretending that their ping is bad 00:37 < bridge> [teeworlds] yeah, but if they pretend to to have a bad ping, they actually need to have a bad ping 00:37 < bridge> [teeworlds] even tho fake, it's bad 00:38 < bridge> [teeworlds] so widening the funnel and range would apply properly 00:38 < bridge> [teeworlds] I don't think that's possible either 00:38 < bridge> [teeworlds] on a logical level, nothing to do with actual network stuff 00:38 < bridge> [teeworlds] I mean if the ping is bad, it doe snot matter if it's fake or not 00:39 < bridge> [teeworlds] at least it must be bad for every packet sent 00:39 < bridge> [teeworlds] I get the idea 00:39 < bridge> [teeworlds] I don't think it's possible to enforce this in any way 00:39 < bridge> [teeworlds] enforce what? 00:39 < bridge> [teeworlds] that a player with a fake bad ping gets input latency as an (implicit) punishment 00:40 < bridge> [teeworlds] we are using tcp guys 00:40 < bridge> [teeworlds] that's not my idea 00:40 < bridge> [teeworlds] my idea is to limit the dyn cam range based on the latency 00:40 < bridge> [teeworlds] you should be able to measure the ping by the tcp packet number 00:40 < bridge> [teeworlds] ba dping, fake or not 00:40 < bridge> [teeworlds] will se emore 00:40 < bridge> [teeworlds] see 00:40 < bridge> [teeworlds] at least in a way to prevent zooming, not to prevent dyn cam 00:41 < bridge> [teeworlds] but you want to have that the bad ping, fake or not, to have an impact on their input latency? 00:41 < bridge> [teeworlds] yeah 00:41 < bridge> [teeworlds] that's what I mean with not possible 00:41 < bridge> [teeworlds] i understand his idea: show more to people with bad ping 00:41 < bridge> [teeworlds] you can track input packets with time info as well as anything else? 00:41 < bridge> [teeworlds] so fast movement is possible without snapping 00:42 < bridge> [teeworlds] yes. but what do you do with that timing? 00:42 < bridge> [teeworlds] how do you detect bad ping without an ability to fake it? 00:42 < bridge> [teeworlds] or without the ability to fake it without suffering bad ping 00:43 < bridge> [teeworlds] you track every packet's timing, keep track of the lowest latency from all sent packets, based on that lowest latency detected you shrink the funnel around dyn cam 00:43 < bridge> [teeworlds] okay. 00:43 < bridge> [teeworlds] so I pretend to send my packets at a much earlier time 00:43 < bridge> [teeworlds] you get a smaller funnel 00:43 < bridge> [teeworlds] as your lowest ping is actually seemingly your real ping 00:43 < bridge> [teeworlds] through all packets 00:44 < bridge> [teeworlds] I pretend to send all my packets much earlier than I do 00:44 < bridge> [teeworlds] you get a disadvantage 00:44 < bridge> [teeworlds] by getting a smaller view 00:44 < bridge> [teeworlds] huh? 00:44 < bridge> [teeworlds] I thought larger ping = bigger view? 00:44 < bridge> [teeworlds] wait 00:45 < bridge> [teeworlds] you send them earlier, so shouldn't your latency be smaller Oo? 00:45 < bridge> [teeworlds] I pretend to send them earlier 00:45 < bridge> [teeworlds] ah 00:45 < bridge> [teeworlds] so I pretend I already sent them a second ago 00:45 < Learath2> Found a very janky SDL patch to fix the fullscreen issue on macOS :P 00:45 < bridge> [teeworlds] hm, interesting 😮 00:45 < Learath2> Took 10 hours of debugging, if only apple would be a little more open with their code 00:46 < bridge> [teeworlds] rip idea then 😮 00:46 < bridge> [teeworlds] x) 00:46 < Learath2> in other news I might get another patch into SDL at this rate 00:46 < bridge> [teeworlds] each macOS update is like another step into their grave with macOS 00:47 < Learath2> the put together appearance of the OS is very much a facade, the amount of bitrot and compatibility code underneath the hood to keep things simple boggles ones mind 00:50 < Learath2> in other other news, lagswitches have been a thing since the beginning of time, there is no way to detect it 00:52 < bridge> [teeworlds] hm, might be due to the asyn nature of the teeworlds communication, client just fires packets after the connection stages have been passed 00:53 < bridge> [teeworlds] wonder if one would be ablte to establish some kind of back and forth of data that needs to be sent back and forth.. guess maybe not. 00:53 < bridge> [teeworlds] able 00:53 < Learath2> sony patented a way to detect lag switchers, their brilliant idea was to encrypt the packets so the timestamps can't be manipulated 00:56 < bridge> [teeworlds] Interesting 00:57 < bridge> [teeworlds] Thanks for the monstrous debugging work Learath2 01:00 < bridge> [teeworlds] full switch to vulkan 01:05 < Learath2> @Dune it's actually been quite educational tbh 01:06 < bridge> [teeworlds] You are used to fiddle with OSX? 01:06 < Learath2> I was familiar with reverse engineering but this has given me a lot of hands on experience 01:07 < bridge> [teeworlds] "full switch to vulkan" xD 01:07 < Learath2> @Dune I'm a little familiar with the actual public API, but the problems we've been having happen way deeper in the code where there is 0 documentation 01:07 < bridge> [teeworlds] Oh, you did reverse engineering for that 01:09 < Learath2> Like that NSOpenGLContextSuppressThreadAssertions flag, it was being set on all ddnet and probably teeworlds executables because we were linking on an older version of macOS 01:09 < Learath2> it's not documented anywhere that the flag was added in Catalina 01:30 < bridge> [teeworlds] you're not supposed to use that I guess 😉 02:06 < Learath2> @heinrich5991 yeah but for executables linked on old versions of the OS AppKit will set it behind your back and the only way to know is either to actually disassemble the thing or know about another arcane flag that reports other arcane flags being set on stdout 02:06 < Learath2> NSLogUnusualAppConfig is the other undocumented config :P 02:08 < bridge> [teeworlds] ^^ 15:35 < Learath2> I spent all that time tracking down that bug, I do a hg pull on SDL, turns out someone else fixed it a couple commits ago 16:00 < bridge> [teeworlds] waa 16:00 < bridge> [teeworlds] link? 16:02 < Learath2> https://hg.libsdl.org/SDL/rev/be892626e1aa 16:46 < bridge> [teeworlds] > 26 Mar 16:47 < bridge> [teeworlds] that fixes it? 17:02 < Learath2> that fixes the toggle issue 17:02 < Learath2> anyway, does anyone have any idea why rendering of scroll regions might be affected by changing the resolution at runtime? 17:02 < bridge> [teeworlds] Maybe @LordSk has a clue 17:03 < bridge> [teeworlds] It's not related to clipping? 17:04 < Learath2> @Dune it does seem to be 17:05 < Learath2> no idea where to look though 17:06 < bridge> [teeworlds] The clipping works on top of screen mapping so it *should* work even if the resolution changes 17:10 < Learath2> https://learath2.info/sshot5.png 17:15 < bridge> [teeworlds] How does it look without clipping at all? 17:17 < Learath2> It is indeed the clipping in CScrollRegion 17:17 < Learath2> https://learath2.info/sshot6.png 17:18 < Learath2> I'm not quite certain what goes wrong though, the clipping rectangles are indeed in "screen space" 17:20 < Learath2> ah, Graphics()->ScreenWidth 17:21 < Learath2> actually, no I do fix those 17:22 < bridge> [teeworlds] So clipping is the issue? 17:23 < Learath2> yep 17:24 < Learath2> @LordSk is clipping stateful? 17:24 < bridge> [teeworlds] on a frame basis yeah 17:25 < Learath2> the rects we pass are fine, if I draw the clip rect before I clip it's in the correct place 17:26 < bridge> [teeworlds] so the mapping is wrong for the clip rect 17:27 < bridge> [teeworlds] https://github.com/teeworlds/teeworlds/blob/master/src/game/client/ui.cpp#L131 17:27 < bridge> [teeworlds] (relevant code) 17:42 < Learath2> ah it's a highdpi issue 17:56 < Learath2> meh it's still broken 18:43 < Learath2> https://learath2.info/sshot7.png blue is what the clipping area actually ends up being, idk how it's happening at all... 18:43 < Learath2> it is a stateful issue though, e.g. going from a higher to lower resolution gives a different result to going from a lower to higher resolution 18:53 < Learath2> oh, the resolution change happens asynchronously 20:44 < Learath2> https://bugzilla.libsdl.org/show_bug.cgi?id=5068 I guess we can't have resizable windows on teeworlds anytime soon :( 20:45 < Learath2> I doubt it'd be acceptable to require a specific sdl version 20:55 < Learath2> we can patch sdl at runtime :) 20:55 < Learath2> though I have a feeling Oy would hate that even more 21:07 < bridge> [teeworlds] Learath2: patching SDL is difficult iirc, newer versions (2.0.9>) have some issues, forgot which 21:08 < bridge> [teeworlds] I think a fix would be very welcome 21:10 < Learath2> I can't really do the SDL upgrade with only access to macOS :/ 21:10 < Learath2> I'm kinda stuck in turkey so I only have a macbook with me 21:12 < bridge> [teeworlds] you don't have a linux on it? 21:15 < Learath2> don't have the space for it :( 21:16 < Dune> oh :( 21:16 < Dune> so you ssh? 21:35 < Learath2> for other things yeah, but how can I debug graphics like that? :/ 22:03 < bridge> [teeworlds] yeah I guess that sucks 22:04 < bridge> [teeworlds] ssh -X doesn't work well from mac? 23:01 < Learath2> @Dune hmm maybe I can install an X server, there is bound to be one