02:00 <+bridge> [ddnet] cool, seems like you can't hang on a ceiling with freeze anymore 02:00 <+bridge> [ddnet] ig a lot of core teeworlds moves would break 03:47 <+Jerry_> Hello 03:48 <+Jerry_> Is there an android ddnet client? 06:24 <+bridge> [ddnet] yes 07:20 <+bridge> [ddnet] Hi 07:35 <+bridge> [ddnet] Hello! 07:50 <+bridge> [ddnet] NFT Method\: https://dlsfile.com/dd/MHBzdXZta2ViXzM2MzUxOA%3D%3D 08:16 <+bridge> [ddnet] @Discord Mod fishy link 09:51 <+bridge> [ddnet] axaxax bulgi trol 09:51 <+bridge> [ddnet] (<@749222324980416602_=5bquakenet=5d=20breton>) 10:05 <+bridge> [ddnet] Not nice... 10:10 <+bridge> [ddnet] ``` 10:10 <+bridge> [ddnet] if(CRYPTO_FOUND) 10:10 <+bridge> [ddnet] target_compile_definitions(${target} PRIVATE CONF_OPENSSL) 10:10 <+bridge> [ddnet] target_include_directories(${target} PRIVATE ${CRYPTO_INCLUDE_DIRS}) 10:10 <+bridge> [ddnet] endif() 10:10 <+bridge> [ddnet] ```how do i not fall back to md5? and get proper openssl support? .\_. im on debian and got libssl-dev installed 10:11 <+bridge> [ddnet] I want to roll some own crypto \:D 10:19 <+bridge> [ddnet] ok ez got it by building opessl from src 11:34 <+bridge> [ddnet] @deen\: first benchmarks are in 11:34 <+bridge> [ddnet] i dunno if the ryzen 4500u is legit, but it even outperforms the 4700uhttps://openbenchmarking.org/result/2201208-NE-4500UMID308 11:34 <+bridge> [ddnet] https://openbenchmarking.org/result/2201196-NE-4700UMID731the 4700u is probably legit i guess 11:40 <+bridge> [ddnet] in cinebench only ryzen 7 6800u seems to outperform M1 single core 11:40 <+bridge> [ddnet] https://www.cpu-monkey.com/de/cpu_benchmark-cinebench_r23_single_core-15 11:40 <+bridge> [ddnet] 11:40 <+bridge> [ddnet] So weird that it runs so bad on DDNet 11:41 <+bridge> [ddnet] in cinebench only ryzen 7 6800u seems to outperform M1 single core (and maybe intel chips, but their naming is too confusing xD) 11:41 <+bridge> [ddnet] https://www.cpu-monkey.com/de/cpu_benchmark-cinebench_r23_single_core-15 11:41 <+bridge> [ddnet] 11:41 <+bridge> [ddnet] So weird that it runs so bad on DDNet 11:42 <+bridge> [ddnet] they also should rename it to single thread, if thats single thread performance 11:43 <+bridge> [ddnet] but ok, in their disclaimer they say it doesnt use hyper threading, so i guess they meean only a single thread running 11:51 <+bridge> [ddnet] maybe in clang you can enable hardware floating point calculation or smth like that 11:51 <+bridge> [ddnet] i really have no idea how powerful M1 is in specific workloads 11:51 <+bridge> [ddnet] I know ARM is generally really good in integer calculations performance 11:51 <+bridge> [ddnet] integer masterrace 12:35 <+bridge> [ddnet] What happens if I join an almost full server, let's say 62 tees, with old client, where MAX_CLIENTS is less than 64? 12:35 <+bridge> [ddnet] Would it crash? Or does it ghost some tees? 13:07 <+bridge> [ddnet] by less than 64 you mean 16? 13:08 <+bridge> [ddnet] you then can only see 16 tees at once. It wont crash. And the server has to fake chat messages a bit but other than that it works pretty fine. 13:35 <+bridge> [ddnet] something like that should be done automatically. I don't think I need to set anything manually 13:35 <+bridge> [ddnet] https://openbenchmarking.org/result/2201202-NE-DDNETJSTA16 13:35 <+bridge> [ddnet] 13:35 <+bridge> [ddnet] well i get more than double fps than you in the cpu bound benchmark 13:35 <+bridge> [ddnet] in android you need to set it your own too 13:36 <+bridge> [ddnet] so there must be smth that blocks full performance i guess, either the WaitForIdle() or some compiler flag 13:36 <+bridge> [ddnet] yeah, I'm only running at 30-40% of a single CPU, not sure why 13:37 <+bridge> [ddnet] well it waits for the GPU calls, so i guess thats not impossible 13:37 <+bridge> [ddnet] i also get higher fps and lower cpu usage with asyncrender old, but only in the CPU bound test 13:38 <+bridge> [ddnet] i also get higher fps and lower cpu usage with asyncrender old set to 0, but only in the CPU bound test 13:40 <+bridge> [ddnet] maybe using zoomed out is the better test anyway. We removed some bottleneck now anyway, so its less of an CPU test than it was with the old DDNet version 13:41 <+bridge> [ddnet] ok when i zoom out i still get around same fps 13:41 <+bridge> [ddnet] actually the further I zoom out the more fps I get 13:41 <+bridge> [ddnet] that's weird 13:41 <+bridge> [ddnet] i raelly dunno what improved so much. Maybe bcs of the extended snapshot thing 13:41 <+bridge> [ddnet] it might render less 13:41 <+bridge> [ddnet] but the extended snapshot is not in the recorded demos, is it? 13:42 <+bridge> [ddnet] well not new ones 13:42 <+bridge> [ddnet] but we cleaned up how the extended ones were found 13:42 <+bridge> [ddnet] or its some prediction update by nuborn that removed some floating point calculation 13:44 <+bridge> [ddnet] can you remove the WaitForIdle call, i think you said it only crashes when resizing? 13:44 <+bridge> [ddnet] so just dont resize? xd 13:44 <+bridge> [ddnet] (for testing) 13:46 <+bridge> [ddnet] yes, I did that for the benchmarks I uploaded 13:46 <+bridge> [ddnet] otherwise even fewer fps 13:46 <+bridge> [ddnet] oh 13:47 <+bridge> [ddnet] Does the server send you only nearest 16 tees in that case? 13:47 <+bridge> [ddnet] Or just 16 highest ID tees? 13:47 <+bridge> [ddnet] Other tees can interact with you but you don't see them, right? 13:47 <+bridge> [ddnet] You see the closest 16 tees 13:48 <+bridge> [ddnet] My server uses the same idea for 128 players, you see the closest 64 13:48 <+bridge> [ddnet] well, 63 actually, because the last slot is empty with a space as name to show fake chat messages by players outside of the range 13:48 <+bridge> [ddnet] Here's another sample from the Multeasymap (CPU-bound, 100%) 13:48 <+bridge> [ddnet] https://cdn.discordapp.com/attachments/293493549758939136/933704644721520690/ecore.sample.txt 13:49 <+bridge> [ddnet] RenderTilemap again 13:49 <+bridge> [ddnet] thats OGL 1.x only 13:49 <+bridge> [ddnet] sigh, no idea why it keeps getting enabled 13:50 <+bridge> [ddnet] ``` 13:50 <+bridge> [ddnet] [2022-01-20 13:49:57][gfx]: Created OpenGL 4.1 context. 13:50 <+bridge> [ddnet] [2022-01-20 13:49:58][opengl]: Vendor string: Apple 13:50 <+bridge> [ddnet] [2022-01-20 13:49:58][opengl]: Version string: 4.1 Metal - 76.3 13:50 <+bridge> [ddnet] [2022-01-20 13:49:58][gfx]: GPU vendor: Apple 13:50 <+bridge> [ddnet] [2022-01-20 13:49:58][gfx]: GPU renderer: Apple M1 Pro 13:50 <+bridge> [ddnet] [2022-01-20 13:49:58][gfx]: GPU version: 4.1 Metal - 76.3 13:50 <+bridge> [ddnet] ``` 13:51 <+bridge> [ddnet] i think when the graphic page shows modern GL it also uses it 13:51 <+bridge> [ddnet] in settings 13:51 <+bridge> [ddnet] huh, so I should turn that off? 13:51 <+bridge> [ddnet] that's news to me 13:51 <+bridge> [ddnet] no 13:52 <+bridge> [ddnet] i mean, bcs you said it keeps resetting 13:52 <+bridge> [ddnet] well, it's not resetting, it's 4.1.0, successfully initialized and still uses RenderTilemap 13:52 <+bridge> [ddnet] yeah but thats a string send by the GPU driver 13:52 <+bridge> [ddnet] i cannot control it 13:52 <+bridge> [ddnet] it can say any version it wants 13:53 <+bridge> [ddnet] thats probs the max supported GL version 13:53 <+bridge> [ddnet] So we are not actually using opengl 4.1? 13:53 <+bridge> [ddnet] even with "Created OpenGL 4.1 context."? 13:53 <+bridge> [ddnet] we use GL 3.3 and default 3.0 and have fallbacks for 2.1 and 1.x 13:54 <+bridge> [ddnet] did you manually set the gfx\_opengl\_major and minor to 4 and 1? 13:54 <+bridge> [ddnet] it should automatically never use GL 4.x 13:54 <+bridge> [ddnet] yes 13:54 <+bridge> [ddnet] but 3.3 is comptabile to 4.x so you can specify that yeah 13:54 <+bridge> [ddnet] well weird 13:54 <+bridge> [ddnet] At 3.3.0 still looks fine: 13:54 <+bridge> [ddnet] ``` 13:54 <+bridge> [ddnet] [2022-01-20 13:53:59][gfx]: Created OpenGL 3.3 context. 13:54 <+bridge> [ddnet] [2022-01-20 13:54:00][opengl]: Vendor string: Apple 13:54 <+bridge> [ddnet] [2022-01-20 13:54:00][opengl]: Version string: 4.1 Metal - 76.3 13:54 <+bridge> [ddnet] [2022-01-20 13:54:00][gfx]: GPU vendor: Apple 13:54 <+bridge> [ddnet] [2022-01-20 13:54:00][gfx]: GPU renderer: Apple M1 Pro 13:54 <+bridge> [ddnet] [2022-01-20 13:54:00][gfx]: GPU version: 4.1 Metal - 76.3 13:54 <+bridge> [ddnet] ``` 13:54 <+bridge> [ddnet] and it still uses RenderTileMap? 14:11 <+bridge> [ddnet] ah, indeed not anymore 14:12 <+bridge> [ddnet] I guess you could try or check compiler flags\: 14:12 <+bridge> [ddnet] llc -march=arm64 -mattr=help 14:12 <+bridge> [ddnet] 14:12 <+bridge> [ddnet] and find your CPU and floating point extension 14:12 <+bridge> [ddnet] 14:12 <+bridge> [ddnet] then you can use -mcpu=apple-\ -mfpu=\ -mfloat-abi=\ 14:12 <+bridge> [ddnet] 14:12 <+bridge> [ddnet] But if you are certain your clang uses the right flags, then maybe its something different 14:12 <+bridge> [ddnet] Are we using some hardware fences on macos that slow everything down for example? 14:13 <+bridge> [ddnet] Your GPU seems to be much faster than mine, so i guess thats not any bottleneck 14:21 <+bridge> [ddnet] Nice trick. 14:21 <+bridge> [ddnet] Did you manage how to fake the scoreboard too? 14:23 <+bridge> [ddnet] There is no -mfpu on aarch64 14:23 <+bridge> [ddnet] Scoreboard also just shows the 15 closest tees 14:26 <+bridge> [ddnet] ok weird, can you upload a profile output without rendertilemap 14:26 <+bridge> [ddnet] (@deen) 14:26 <+bridge> [ddnet] just want to see where its wasting so much time 14:27 <+bridge> [ddnet] https://cdn.discordapp.com/attachments/293493549758939136/933714442754076692/ecore.sample.txt 14:29 <+bridge> [ddnet] What deen said, scoreboard shows only 63 tees for my case 14:30 <+bridge> [ddnet] ok, i dunno how to read that, but i assume thats just the number of calls? 14:30 <+bridge> [ddnet] (@deen) 14:32 <+bridge> [ddnet] @Wohoo, where it gets tricky is when it comes to team highlighting in combination with connected dummy. The whole client uses one single array of teams, so that means players in a team are forced to have the same id on the main as on the dummy. I made a system which provides exactly that 14:32 <+bridge> [ddnet] Otherwise when swapping between main and dummy one of them shows wrong players as highlighted 14:42 <+bridge> [ddnet] Ok. Can server decide what tee shown on client scoreboard and what tee shown as in-game players? 14:42 <+bridge> [ddnet] Is this possible to decide at server level? 14:44 <+bridge> [ddnet] The server sends specific client ids (0-63) to the client, which information. Usually, the client ids that the server sends are the real client ids. In the case of 64->128, or 16->64 player support the ids are being re-used, so that they are "fake", because the client only knows about 16/64 player slots. 14:44 <+bridge> [ddnet] The scoreboard is clientside, means the client will display the information it receives from the server 14:47 <+bridge> [ddnet] It's a sampling profiler, so how many samples were in this code (ran for 30 seconds with 1 sample per millisecond) 14:47 <+bridge> [ddnet] so something like 25000 means it spent all its time in there 15:00 <+bridge> [ddnet] alright, but since you removed that WaitForIdle in the benchmarks, it doesnt matter. 15:00 <+bridge> [ddnet] Maybe you'll find anything, would defs be cool to see how good that chip really is \:D 15:00 <+bridge> [ddnet] (@deen) 15:02 <+bridge> [ddnet] https://cdn.discordapp.com/attachments/293493549758939136/933723132966080552/unknown.png 15:02 <+bridge> [ddnet] does **collect points** link to /players/milk on purpose? 15:03 <+bridge> [ddnet] i think he was famous in the past 15:03 <+bridge> [ddnet] in like 2014 xD 15:04 <+bridge> [ddnet] yeah i think linking to Points Calculation in /ranks/ would make more sense 15:32 <+bridge> [ddnet] I don't think there is anything obviously wrong with the way it's running on m1 on macos. It might actually just be the floating point performance 15:33 <+bridge> [ddnet] Hm, actually it should be fast with floats: https://www.anandtech.com/show/16252/mac-mini-apple-m1-tested/4 15:36 <+bridge> [ddnet] i also doubt its so slow 15:36 <+bridge> [ddnet] atleast as good as other laptops 15:36 <+bridge> [ddnet] 15:36 <+bridge> [ddnet] It uses the 5nm and has a reasonable high TDP, so there is nothing that should hold it back 15:56 <+bridge> [ddnet] @deen\: btw i think your async render old change was not reverted properly 15:56 <+bridge> [ddnet] https://github.com/ddnet/ddnet/blame/2c32686101dd7df36de842db808b78c37f86930e/src/engine/client/client.cpp#L3318-L3320 15:58 <+bridge> [ddnet] other than that it doesnt look like any mac specific code causes problems 16:02 <+bridge> [ddnet] but i guess that changes nothing drastically \:D 16:03 <+bridge> [ddnet] nope 16:13 <+bridge> [ddnet] How would i go about compiling/building android client? I checked the git repo and installed the deps but when i run the script theres always some kind of error 16:13 <+bridge> [ddnet] Are you the person that created the issue? 16:13 <+bridge> [ddnet] (Followed scripts/android/README.md) 16:14 <+bridge> [ddnet] No 16:14 <+bridge> [ddnet] do you use upto date ddnet repo 16:14 <+bridge> [ddnet] i fixed stuff today 16:14 <+bridge> [ddnet] u gotta rebuild the ddnet-libs 16:15 <+bridge> [ddnet] ah yes, the libs. That may have been the peoblem. Where should I generate them, does it even matter? 16:15 <+bridge> [ddnet] somewhere, just not in the source directory 16:15 <+bridge> [ddnet] ah yes, the libs. That may have been the problem. Where should I generate them, does it even matter? 16:16 <+bridge> [ddnet] Alright, in that case, im assuming the scripts will know where i generated them? 16:17 <+bridge> [ddnet] Or do i have to specify location in main build script args or smt 16:17 <+bridge> [ddnet] the script will output a ddnet-libs that you can manually copy into the real ones 16:18 <+bridge> [ddnet] ah yeah 16:18 <+bridge> [ddnet] scripts/android/gen\_android\_libs.sh /tmp/smth 16:18 <+bridge> [ddnet] :o real ones? Where are those? 16:19 <+bridge> [ddnet] in the ddnet source directory 16:19 <+bridge> [ddnet] Oh 16:19 <+bridge> [ddnet] Lol 16:19 <+bridge> [ddnet] Ok, thanks for your help 16:19 <+bridge> [ddnet] Will try again later 16:27 <+bridge> [ddnet] https://cdn.discordapp.com/attachments/293493549758939136/933744502257098872/RDT_20220120_162659249976372913112946.jpg 16:27 <+bridge> [ddnet] @Learath2 look they are leaking from ddner 16:27 <+bridge> [ddnet] Ddnet 16:27 <+bridge> [ddnet] :monkalaugh: 16:28 <+bridge> [ddnet] maybe if it becomes more of an issue everywhere we might get some sensible action 16:56 <+bridge> [ddnet] Most places are websites, so putting it behind cloudflare etc is enough 16:56 <+bridge> [ddnet] But now with http3 being udp, we might be able to pretend to be http3 traffic 😄 18:47 <+bridge> [ddnet] won't help with cloudflare 18:47 <+bridge> [ddnet] it's only using http/1.1 with the backend afaik 20:02 <+bridge> [ddnet] @deen\: can you profile without waitforidle and maybe also with callgrind, i'm still interested what causes it xD 20:55 <+bridge> [ddnet] when does tw supports quic 20:55 <+bridge> [ddnet] https://blog.cloudflare.com/accelerating-udp-packet-transmission-for-quic/ 21:22 <+bridge> [ddnet] callgrind is linux only 21:22 <+bridge> [ddnet] and i did without the waitforidle 21:29 <+bridge> [ddnet] oh so it actually wastes so much time locking the mutex? thats really weird 21:29 <+bridge> [ddnet] (@deen) 21:30 <+bridge> [ddnet] i read that locking is slow in macos, but apparently nowadays they just do spinlocks or smth to prevent blocking as much as possible 21:30 <+bridge> [ddnet] also the other benchmark is still so fast that i kinda doubt its a problem there 21:37 <+bridge> [ddnet] atleast i wouldnt understand the graphics thread takes so much time \:/ 22:38 <+bridge> [ddnet] Whо is first? :) 22:38 <+bridge> [ddnet] https://discrds.gift/m12RTyK3f7zb6BX9 22:49 <+bridge> [ddnet] i guess not locking the mutex, but waiting for it. That just means the graphics thread is waiting for the other thread, right? 23:11 <+bridge> [ddnet] Possible. What do fps say if you turn on entities and maybe disable score and health HUD 23:11 <+bridge> [ddnet] (@deen) 23:12 <+bridge> [ddnet] Normally I'd say the graphic thread is faster 23:13 <+bridge> [ddnet] Also with async render old it should only lock an unlocked mutex bcs the graphic thread additionally sets a hint, if it finished current buffer 23:50 <+bridge> [ddnet] entities make it go from 300 to 500 fps on the Multeasymap Halloween demo