08:04 < bridge> Hi @matricks 08:05 < bridge> Imagine if matricks submits a PR to ddnet 08:06 < bridge> that would be so funny 08:12 < bridge> HAHAHA LMAO 08:12 < bridge> sorry 08:12 < bridge> Excuse my autism, Sir. 08:19 < bridge> its ok im just the same 08:19 < bridge> probably worse 08:26 < bridge> xD 08:51 < bridge> Don't blame something u don't understand for it tho 08:52 < bridge> I've been saying this for a decade now and people keep denying it. Modern text editors have insane input lag 08:52 < bridge> Try vim on a tty, then boot up to windows and try vscode 08:52 < bridge> Except u have 7ghz Intel running @ 200000watt 08:52 < bridge> It feels like you are typing over ssh 08:53 < bridge> Ah wait, we are actually not that far away from 7ghz 08:53 < bridge> Ok 7thz 08:54 < bridge> Make that 700thz and maybe we'll get some visible light out of it. That'd be cool 09:13 < bridge> Gotta say tho pasting large texts in insert mode vim always loses against vscode in performance. 09:13 < bridge> (@Learath2) 09:15 < bridge> In paste mode it should be better. But yes, that is indeed an issue 09:15 < bridge> Yes but I forget to enter paste mode all the time haha. And then there is no going back when vim hangs .\_. 09:16 < bridge> Im also a big electron hater. But gotta admit vscode is really smooth. 09:18 < bridge> СТИМ ДАРИТ ДИСКОРД НИТРО НА 3 МЕСЯЦА! 09:18 < bridge> https://cli.co/discord-steam 09:18 < bridge> **#### 🚨 Phishing Link Detected 🚨** 09:18 < bridge> **##### A message has been detected to contain a problematic link. We recommend not pressing any links within the message.** 09:18 < bridge> **###### If this is a false positive, please let us know by joining our support server through the command `!phish support`** 09:18 < bridge> A good algorithm in a show language will always win against a slow algorithm in a fast language xd 09:19 < bridge> Or design or whatever 09:19 < bridge> A good algorithm in a slow language will always win against a slow algorithm in a fast language xd 09:25 < bridge> tf is this bot lmao 09:26 < bridge> At least it seemed to have worked 09:26 < bridge> Xd 09:27 < bridge> !phish support 09:27 < bridge> Join our space here\: [#phishbot\:matrix.org](https://matrix.to/#/#phishbot:matrix.org) 09:27 < bridge> ha 09:27 < bridge> it's a matrix bot 09:32 < bridge> Mhh I assume the bridge has lot of rights? I wonder if u can make it leave xd 09:32 < bridge> !phish help 09:32 < bridge> **### Commands** 09:32 < bridge> ``` 09:32 < bridge> !phish help - Displays this menu. 09:32 < bridge> !phish ping - Pings the bot and gives uptime. 09:32 < bridge> !phish space - Provides a link to join the Phish Bot space.``` 09:32 < bridge> Ah no CMD for that xd 10:32 < bridge> i decided ill contribute smth to llvm 10:32 < bridge> time to clone this massive monorepo and setup a dev env 10:36 < bridge> 😎😎😎 10:40 < bridge> :justatest: 10:40 < bridge> https://cdn.discordapp.com/attachments/293493549758939136/1095991888802238594/image.png 10:55 < bridge> Couldn't you clone with --depth 1 10:55 < bridge> Since you dont need the entire history of commits :justatest: 11:04 < bridge> i want the entire history 11:04 < bridge> anyway its just 2gb 11:04 < bridge> the build is 20gb 11:04 < bridge> What will you be contributing to llvm? 11:05 < bridge> for now i want to extend the c api of mlir to be able to call mlir-translate via the api instead of the tool 11:05 < bridge> the cpp api allows this already 11:06 < bridge> Coolcool C is best 11:06 < bridge> tf 11:06 < bridge> https://cdn.discordapp.com/attachments/293493549758939136/1095998409565020160/image.png 11:06 < bridge> ok mr discord 11:07 < bridge> <-StormAx> bro, im also shocked 11:08 < bridge> How dare you post that? 11:09 < bridge> yeah i know cpp errors are heinous 11:12 < bridge> Nice try, trying to hack discord 11:24 < bridge> i guess i have to use gcc 11:24 < bridge> well ill try when im back from work 11:47 < bridge> help!!! me ban,for just like that 12:32 < bridge> would be weird that llvm cannot be compiled with clang 12:32 < bridge> error is in std header, so those are common to gcc and clang 12:42 < bridge> Clang offers an own cpp std lib. Libc++ and libc++-abi 12:46 < bridge> yeah it uses gcc std instead of clang or smth 12:48 < bridge> @Tater How to run Tater client from https://github.com/sjrc6/TaterClient-ddnet/releases/tag/7.1.5 ? @Cøke asked 12:49 < bridge> use this version it's updated https://github.com/danielkempf/TaterClient-ddnet/ 12:49 < bridge> yeah sorry used wrong client version 12:50 < bridge> you can download the ddnet version it says from the website then replace the exe 12:50 < bridge> or compile it yourself 12:51 < bridge> yes thx it works 12:51 < bridge> np 13:20 < bridge> @Jupeyy_Keks how do you handle the texture atlases like game.png btw? using it as a texture directly makes the hook bleed into the grenade a little 13:21 < bridge> I split them. I didn't find another easy solution for gl1 13:21 < bridge> On cpu 13:21 < bridge> split them as in creating a separate atlas with more space inbetween? 13:22 < bridge> or some texture array? 13:22 < bridge> Individual textures 13:24 < bridge> so one draw call for each weapon and so on if I understand correctly? 13:24 < bridge> Yes. But don't u already face this problem with skins 13:25 < bridge> I don't think so, I think pretty much all skins don't go close to the texture borders 13:25 < bridge> wait do you do mipmapping with skins? 13:25 < bridge> It will not match ddnet rendering then tho. Just that u are aware 13:27 < bridge> hm if it is only about details not noticeable in regular gameplay I think I'd be okay with it 13:34 < bridge> What you can do is to use texture query lod and then simply apply the query lod to the expected texture size to get the Texel offset apply that to the texture coordinates (u need to keep track of if it's bottom right etc.) And then with texturelod u have no bleeding . Tho no mipmap interpolation 13:34 < bridge> Also it will still distort very slightly. Since edges aren't clamped but skipped instead 13:35 < bridge> ```void CGameWorld::Clear() 13:36 < bridge> { 13:36 < bridge> // delete all entities 13:36 < bridge> for(auto &pFirstEntityType : m_apFirstEntityTypes) 13:36 < bridge> while(pFirstEntityType) 13:36 < bridge> delete pFirstEntityType; // NOLINT(clang-analyzer-cplusplus.NewDelete) 13:36 < bridge> } 13:36 < bridge> ``` 13:36 < bridge> did some experimenting with prediction and somehow when clearing a simulated world this crashed on me while deleting. 13:36 < bridge> fixed it like this... idk if this is a issue or some preperations where wrong on my side 13:36 < bridge> ```void CGameWorld::Clear() 13:36 < bridge> { 13:36 < bridge> // delete all entities 13:36 < bridge> for(auto &pFirstEntityType : m_apFirstEntityTypes) 13:36 < bridge> { 13:36 < bridge> while(pFirstEntityType) 13:36 < bridge> { 13:36 < bridge> auto nextEntityType = pFirstEntityType->m_pNextTypeEntity; 13:36 < bridge> delete pFirstEntityType->m_pPrevTypeEntity; 13:36 < bridge> delete pFirstEntityType; 13:36 < bridge> pFirstEntityType = nextEntityType; 13:36 < bridge> } 13:36 < bridge> } 13:36 < bridge> }``` 13:39 < bridge> doesnt delete[] m_apFirstEntityTypes; work? 13:39 < bridge> my cpp is rusty anyway 13:39 < bridge> pun intended 13:40 < bridge> It's a linked list 13:40 < bridge> So no 13:40 < bridge> Or multiple linked lists even 13:40 < bridge> CEntity *m_apFirstEntityTypes[NUM_ENTTYPES]; 13:41 < bridge> Yeah. U can't delete an array 13:41 < bridge> isnt this the point of delete[] 13:41 < bridge> The delete [] operator deallocates memory and calls destructors for an array of objects created with new []. 13:41 < bridge> Besides the code is really weird ddnets could should be right i think 13:42 < bridge> It's a compiler time sized array 13:42 < bridge> Not heap 13:42 < bridge> ah 13:42 < bridge> cpp sux 13:42 < bridge> Lmao 13:42 < bridge> it works and i aint complaining xD 13:43 < bridge> ^^ 13:43 < bridge> magic 🧙‍♂️ 13:43 < bridge> i hate smileys 13:43 < bridge> ^^ 13:43 < bridge> 🙂 13:43 < bridge> :poggers2: :kek: :troll: :justatest: 13:43 < bridge> better 13:43 < bridge> its like 13:43 < bridge> "u did good 🙂" 13:43 < bridge> Smileys i usually don't use xd 13:43 < bridge> sure 🙂 13:44 < bridge> 🧐 13:44 < bridge> cpp is nice 🙂 13:44 < bridge> Rust sucks🥲 13:46 < bridge> hm then what is actually the ddnet way of tee rendering? if you have every texture separately, what are your actual vertex/transformation buffers? 13:46 < bridge> I assume they are all push constants 13:47 < bridge> No buffers involved 13:47 < bridge> oh 13:47 < bridge> what about the camera, are all positional calculations done on the cpu? 13:47 < bridge> Since max 64 tees are visible it should be fine probably 13:48 < bridge> Desktop computers might have a slight advantage. But creating rendering info buffers also costs a bit time 13:48 < bridge> So in total it's probably not too much overhead and works on all renders 13:49 < bridge> And is pixel perfect 13:49 < bridge> I'd say if I reimplement ddnets. I'd not put images with different sizes in an Atlas anyway 13:49 < bridge> Skin bodies could be in an array. But even there I'm not sure 13:50 < bridge> Or weapons in your case 13:50 < bridge> but in the case of skins it shouldn't actually matter, no? all body parts are much smaller than their atlas segment 13:51 < bridge> Probably yes. There is some really fat skin in the database 13:51 < bridge> Maybe it bleeds for body outline 13:52 < bridge> defatulYoda 13:52 < bridge> Looks fine tho 13:52 < bridge> So yeah will probably never happen 13:53 < bridge> Maybe when zooming out lot 13:53 < bridge> okay and in the case of weapons, if I would put them into an texture array, I would have to rescale some of them since they don't have the same proportions, is that rescaling okay? 13:53 < bridge> https://ddnet.org/skins/skin/community/defatulYoda.png 13:53 < bridge> yeah it looks the closest but is probably still fine 13:54 < bridge> Mhh then that's also a problem here too 13:54 < bridge> Thought they are all same 13:55 < bridge> Generally rescale should be fine. But on fly u probably don't use a very expensive algorithm, which might make it ugly 13:55 < bridge> yea it wouldn't be on the fly 13:56 < bridge> Tbh. I'd really do the sampling my own completely 13:56 < bridge> I currently have a texture array for the tee skins and want to also insert the weapons in some static slots to be able to use them easily in the same draw call 13:58 < bridge> I don't really have a feel for pushconstants yet, when would you suggest using them. if we have at max 64 tees, I personally would've guessed that its better to have a buffer for all of them together than providing different push constants and doing each individually 13:58 < jupstar> so u want everything in one fat texture? :D 13:58 < bridge> yea :d 13:59 < jupstar> it probably is better to have them in one buffer, but u also have to respect some hardware weirdnesses like caching and stuff 13:59 < jupstar> from feeling i'd say it might be faster, but only very slightly, since it doesnt involve less GPU work 14:00 < jupstar> anyway, skins are different res than game.png? do you want to upscale all skins? 14:00 < bridge> > so u want everything in one fat texture? 14:00 < bridge> my thought was that it would be nice cause then I can render everything a single tee needs in a single draw call. and then even all tees in a single draw call 14:01 < jupstar> yep its nice and for demo rendering where all skins etc can be known beforehead it will probably be faster 14:01 < jupstar> as in you dont update the texture itself 14:02 < bridge> > anyway, skins are different res than game.png? 14:02 < bridge> well by default a skin.png is 256x128, game.png is 1024x512, but shotgun and grenade above each other is 256x128 again. since a tee only uses a few segments from game.png, I thought that I'd just take the size of the skins and use one slot of the skin array texture for 1 or 2 weapons 14:03 < bridge> I mean even for regular gameplay there can be at max 64 different skins 14:04 < jupstar> but anyway, your only real problem is the interpolated sampling isnt it? 14:04 < jupstar> the rest is just design of choice 14:06 < jupstar> since 100% pixel perfection is not your goal, isnt the solution i posted before good enough? 14:06 < bridge> This 14:07 < bridge> hm well my biggest question still: lets say I wanna make it easy for myself and use exactly one skin slot for each weapon, we only have 6 of them so it should be fine and easy for the texture coordinates. however, will that rescaling make the weapons look much worse? it fear it would smoothen out edges when it shouldn't or smth (maybe I missed your answer) 14:08 < jupstar> btw u dont even need to rescale do you 14:08 < jupstar> simply put the weapon in the top left of the texture and then apply the texture coordinates % of the expected size 14:09 < jupstar> (since texture coordinates are normalized anyway) 14:09 < bridge> hm true, that sounds good 14:10 < bridge> yea I like that 14:10 < bridge> I'll probably also try to put the hook somewhere, so that I can use a single quad to render the entire repeating part of the hook ^^ 14:11 < jupstar> that's gonna be the hardest part, since it might look very slightly wrong. But tbf vanilla teeworlds does this since 13 years and nobody really noticed. but yeah if the chains dont repeat pixel perfect u could:tm: notice it 14:13 < bridge> hm I'll see 😅 14:14 < bridge> btw how would you rate that indirect rendering thing? I think it looks fancy because you can use it to reuse command buffers where I would otherwise need to record them each time on buffers where I might need a different slice each time 14:15 < bridge> (just looked at it yesterday for the first time) 14:17 < jupstar_> did we talk about smth like that?, bit confused rn :D 14:18 < bridge> not yet 14:19 < bridge> but I currently struggle a lot with gpu buffers, especially with ones where I have them at a dynamic size and need to access the length on the cpu side each time which complicates the code there, since I can't just prerecord it 14:21 < bridge> All these indirect stuff is really opengls try to reduce some cpu overhead with having a named state machine 14:22 < bridge> also, why do you switch between irc and discord so much? ^^ 14:22 < bridge> Chatting on mobile sucks 14:22 < bridge> But mobile xd 14:22 < bridge> xd 14:22 < bridge> ah right one more thing 14:23 < bridge> back during the bigger voice chat with matricks, we had also talked a bit about rendering. regarding dilating he mentioned that we should just be able to use the blending mode with premultiplied_alpha, and wouldn't need to dilate ever again 14:24 < bridge> I'm not quite sure I understand anyway. But prerecord is nice for environment drawing where all stuff always has same amount of vertices etc to draw 14:25 < bridge> Yes that's true. U have to pre multiply every pixel then tho 14:25 < bridge> yea and with that indirect drawing you could also prerecord stuff with variable amounts of vertices 14:25 < bridge> but the gpu does that for us, no? 14:25 < bridge> eh ^ each line goes to one of your messages 14:26 < bridge> But wouldn't u need to update the information then? 14:26 < bridge> yeah I thought you could just do a central buffer somewhere, but ofc that would introduce complexity elsewhere 14:26 < bridge> No the image itself need to be premultiplied 14:27 < bridge> I dunno if GPUs have an API for that 14:27 < bridge> Vanilla does it on cpu 14:29 < bridge> Also premultiplied implies no alpha modification afterwards(fragment shader) 14:30 < bridge> Since e.g. a tile layer has a color that is applied at fragment stage 14:30 < bridge> ouch I thought it was a setting of a sampler, but now I see its about blending the different things we render 14:30 < bridge> A alpha channel inside the color to be precise 14:32 < bridge> @matricks maybe you could chime in here if you have time. premultiplied alpha is a setting at the wrong part of the pipeline to fix needing to dilate, no? dilating fixes the interpolation in the fragment shader 14:33 < bridge> It does 14:34 < bridge> But ddnet multiplies tile layer color at fragment stage. U can do it by hand ofc 14:34 < bridge> 14:34 < bridge> Vanilla prepares the color on the cpu already 14:34 < bridge> And I assume the static pipeline handles the rest then 14:36 < bridge> It should not matter tho probably when I think about it 14:37 < bridge> not sure what you mean by doing it by hand. dilating solves the issue of the interpolation during the sampling of the texture, no? since pixels with alpha = 0 have an effect on the color 14:37 < bridge> But I'm not aware of the GPU handling it for textures 14:37 < bridge> Yep but pre multiplies alpha also don't have the problem ofc 14:39 < bridge> aah but as I just figured out such a thing doesn't exist, right? not sure how you would do that by hand (in the fragment shader) since you would somehow need to get the color of all the pixels you need to interpolate between 14:40 < bridge> U can get them. But yeah it's a bit of struggle 14:40 < bridge> agreed ^^ 14:41 < bridge> So either go dilate and have disadvantage when creating the img. Or premultiplied and have to run over the full texture 14:41 < bridge> 👍 14:42 < bridge> I don't recommend any tho. From what I read both methods are used . GTA 5 uses smth like dilate for bushes ans similar assets apparently 14:42 < bridge> Maybe it depends on how often they upload and unload textures 16:48 < bridge> https://engineering.fb.com/2023/04/13/security/whatsapp-key-transparency/ 16:48 < bridge> made with rust xd 17:10 < bridge> my ddnet always crashes after a few seconds if i join skyblock on ddnet ger server 17:11 < bridge> Can you try https://wiki.ddnet.org/wiki/GFX_Troubleshooting and if that doesn't help https://wiki.ddnet.org/wiki/Troubleshooting#Crashes ? 17:14 < bridge> ddnet usa and everything else works fine tho 17:14 < bridge> its just that one server 17:15 < bridge> What even is skyblock? Sounds like minecraft xd 17:16 < bridge> skycraft* 17:16 < bridge> A 17:17 < bridge> https://ddnet.org/maps/skycraft 17:20 < bridge> where is the switch for laser no 7 on that map? i cant find it 17:27 < bridge> @Jupeyy_Keks what do u think about this https://mlir.llvm.org/docs/Dialects/MemRef/# 17:27 < bridge> this dialect is used to represent a "pointer descripter" 17:27 < bridge> this dialect is used to represent a "pointer descriptor" 17:27 < bridge> tldr: a pointer an all possible info about it, to optimize better 17:30 < bridge> Epic af 17:31 < bridge> Hardware info. F1 after client start whole console and purple text mentioning gfx 17:31 < bridge> And top right in F1 17:31 < bridge> Text 17:32 <+ChillerDragon> use chilerbot hax and type ``goto_switch 7`` in console 17:36 < bridge> what? 17:37 < bridge> no fr i searched it in the editor, theres no switch 7. i want to open the laser at the big shortcut where u jump left from spawn and then fly under the big tube 17:40 < bridge> Press F1 after client start pls and make screenshot 17:42 < bridge> https://cdn.discordapp.com/attachments/293493549758939136/1096098170733350922/screenshot_2023-04-13_17-41-39.png 17:45 < bridge> Mh ok. Any crash dumps in %appdata%/ddnet/dumps? 17:46 < bridge> U can delete that btw 17:48 < bridge> no its empty 17:49 < bridge> Weird then 17:54 < bridge> also is `MACRO_ALLOC_HEAP()` needed? 17:54 < bridge> ```cpp 17:54 < bridge> #define MACRO_ALLOC_HEAP() \ 17:54 < bridge> public: \ 17:55 < bridge> void *operator new(size_t Size) \ 17:55 < bridge> { \ 17:55 < bridge> void *p = malloc(Size); \ 17:55 < bridge> mem_zero(p, Size); \ 17:55 < bridge> return p; \ 17:55 < bridge> } \ 17:55 < bridge> void operator delete(void *pPtr) \ 17:55 < bridge> { \ 17:55 < bridge> free(pPtr); \ 17:55 < bridge> } \ 17:55 < bridge> \ 17:55 < bridge> private:``` 17:55 < bridge> it does the same thing constructor does 17:57 < bridge> appears to be used only in `src/game/server/entity.h` 17:58 < bridge> yes 17:58 < bridge> its overloading thje new opeartor 17:59 < bridge> is it not defined twice? 18:00 < bridge> nope 18:00 < bridge> ok its not nvm me than, i thought its a different one 18:01 < bridge> yeah its useless, according to vanilla they once used it for dbg msgs 18:01 < bridge> huh 18:01 < bridge> will get rid of alloc.h 18:01 < bridge> ah but actually its maybe not useless 18:01 < bridge> https://github.com/doomemacs/doomemacs 18:01 < bridge> new CEntity != new CEntity() 18:01 < bridge> i need to try this 18:02 < bridge> i never rly tried emacs 18:02 < bridge> first one will leave centity uninitialized if no custom constructor was implemented 18:02 < bridge> tho we probably always have one 18:02 < bridge> @Learath2 probs knows the details 18:03 < bridge> @Jupeyy_Keks is there a semantic difference between new with cpp and malloc? 18:03 < bridge> maybe thats why its done 18:03 < bridge> well this ensures the memory is zeroed atleast 18:03 < bridge> not with new 18:03 < bridge> 18:03 < bridge> but with implicit constructors 18:03 < bridge> We probably also used it while testing as ASan has trouble with global memory 18:04 < bridge> that's why this 18:04 < bridge> 18:04 < bridge> for implicit constructors the first would not zero the bytes 18:04 < bridge> why not just use calloc here? it zeroes the memory 18:04 < bridge> might me more efficient 18:04 < bridge> the second guarantes it 18:04 < bridge> tbh just remove that then xD 18:04 < bridge> then c++ can decide 18:04 < bridge> Ancient code. It's been there forever 18:05 < bridge> based on the object structure 18:06 < bridge> Btw, we probably should delete the implicit constructors for some of our classes 18:06 < bridge> well if a custom is provided they are automatically deleted 18:07 < bridge> @Learath2 does new from cpp zero memory? 18:07 < bridge> oh 18:07 < bridge> damn 18:08 < bridge> 18:08 < bridge> i tried cargo-geiger 18:08 < bridge> 18:08 < bridge> didn't expect so much use of unsafe tbh xD 18:08 < bridge> maybe it uses default values 18:08 < bridge> Depends entirely on what flavor of initialization you do. C++ has like a billion ways 18:08 < bridge> this is the thing with cpp, u need to know this, in rust this isnt a problem cuz u just cant have uninit values 18:08 < bridge> blegh 18:09 < bridge> @Learath2 iirc i saw there are entire books on initialization in cpp 18:09 < bridge> its insane 18:09 < bridge> yep it would defs be nice to have it explicit, like unsafe{new CEntity; //<-- no zeroing } 18:09 < bridge> would make more sense 18:10 < bridge> 39850 unsafes linked into the final executable 18:10 < bridge> 18:10 < bridge> ez 18:10 < bridge> lets see if lto changes smth 18:11 < bridge> xd 18:11 < bridge> wdym by that 18:11 < bridge> unsafes linked 18:11 < bridge> i lost u 18:11 < bridge> i used cargo geiger to see uses of unsafe in dependencies (and own code) 18:12 < bridge> and apparently 39850 times unsafe code is used that also lands in the final code 18:12 < bridge> ah 18:12 < bridge> in ur project? 18:12 < bridge> yeah 18:13 < bridge> well if u interface with vulkan c api its inevitable 18:13 < bridge> xd 18:13 < bridge> yep, but there are many unsafes in libs i didnt expect. well pretty much all libs have at least one time use 😄 18:14 < bridge> does geiger tell u 18:14 < bridge> Yeah, there is a really nice talk in it that tells you that you basically should always be using `T t{}` which is `value-initialization` that invokes `aggregate-initialization` which does `zero-initialization` on every member according to the rules of that 18:14 < bridge> @Jupeyy_Keks another awesome thing about rust is exactly this 18:14 < bridge> u know where the unsafe is 18:14 < bridge> its localized 18:14 < bridge> does geiger tell u which* 18:14 < bridge> libraries 18:14 < bridge> i cant type today 18:14 < bridge> https://cdn.discordapp.com/attachments/293493549758939136/1096106229580955801/image.png 18:14 < bridge> Which avoids setting some things to zero like memzero would, if not needed that is. And it won't nuke the vtable 😛 18:14 < bridge> slow brain lol 18:14 < bridge> pog 18:15 < bridge> 18:16 < bridge> can u try color_eyre 18:16 < bridge> instead of anyhow 18:16 < bridge> https://youtu.be/7DTlWPgX6zs I think this was the talk 18:17 < bridge> Honestly it's mostly shit only because we have to keep 2 decades of code working 18:17 < bridge> all u need in rust to know: https://doc.rust-lang.org/book/ch05-01-defining-structs.html 18:17 < bridge> Please, just break this stuff already. The two decade old code can compile with an older compiler. It doesn't need to compile with this one 18:18 < bridge> and maybe this https://doc.rust-lang.org/stable/std/mem/union.MaybeUninit.html 18:18 < bridge> if u do advanced stuff 18:19 < bridge> yknow i already forgot 18:19 < bridge> what does the rust code in ddnet do again 18:19 < bridge> ```rust 18:19 < bridge> use std::mem::MaybeUninit; 18:19 < bridge> 18:19 < bridge> // Create an explicitly uninitialized reference. The compiler knows that data inside 18:19 < bridge> // a `MaybeUninit` may be invalid, and hence this is not UB: 18:19 < bridge> let mut x = MaybeUninit::<&i32>::uninit(); 18:19 < bridge> // Set it to a valid value. 18:19 < bridge> x.write(&0); 18:19 < bridge> // Extract the initialized data -- this is only allowed *after* properly 18:19 < bridge> // initializing `x`! 18:19 < bridge> let x = unsafe { x.assume_init() }; 18:19 < bridge> ``` 18:19 < bridge> Rust is cheating by making the default be the better safe than sorry option 18:19 < bridge> Illegal 18:20 < bridge> Nothing for now 18:20 < bridge> printing the rust version 18:20 < bridge> 💀 18:20 < bridge> which is needed for rust propaganda 18:20 < bridge> Heinrich wanted to replace the entire networking stack with it and someone else wanted to replace the entire gamecore 18:20 < bridge> i want to do smth with rust in ddnet but all stuff i think may be too complex or time consuming 18:20 < bridge> ideally we should move the http stuff to rust 18:20 < bridge> Neither project ended up being a thing tho 18:21 < bridge> if it replaces graphics related things then i rq being a dev 18:21 < bridge> because in the future i want to make my own client 18:21 < bridge> @Voxel with this u can generate maps https://github.com/edg-l/ddnet-map-gen 18:21 < bridge> kek 18:22 < bridge> automatic gores 18:22 < bridge> Graphics only @Jupeyy_Keks would dare convert to Rust, and he would only support 40xx series nvidia cards 18:22 < bridge> it has a fly map generator and maze for now 18:22 < bridge> gores in the future tm 18:22 < bridge> so basically infinite plantknight content 18:22 < bridge> i already converted the whole vk backend lel 18:22 < bridge> kek 18:23 < bridge>