00:07 < bridge> make a real map 00:10 < bridge> wdym 00:11 < bridge> real maps are boring, you play them once and forget they exist entirely, unless they're incredibly well suited for speedrunning or playing t0 00:12 < bridge> the only map with which my time spent creating it was justified was Volleyball 00:12 < bridge> volleyball very justified 00:12 < bridge> greatmap 00:12 < bridge> it has a ton of replay value 00:12 < bridge> yea 00:12 < bridge> but i enjoyed some modern moderates 00:12 < bridge> vb2 is mostly fixes anyway 00:13 < bridge> or the dummy map released yday 00:13 < bridge> s-class 00:13 < bridge> yeah im gonna play that now, i heard many great things about it 00:24 < bridge> bro wanted to get off but his ass got bitten by 00:36 < bridge> these lineups are mindblowing 00:37 < bridge> Desert bus is a good map. 00:53 < bridge> ya s-class i think is the best map ive played in years 00:53 < bridge> well worth the praise 00:54 < bridge> i also really enjoyed twin electric field so maybe im biased 01:13 < bridge> including less is always good 01:14 < bridge> eventually iwyu will be added to ci 01:14 < bridge> and we will have standardized includes, and we will solve the gamclient recompile on any change 01:15 < bridge> i mean you don't include less, u just reusing occasional header include with another, like, there's no profit at all xd 01:16 < bridge> if you only use clamp but not anything else from base/math.h then you can just include algorithm 01:17 < bridge> only reason using clamp was in math.h is only reason using clamp was in math.h is 01:17 < bridge> so can move away from it, teeworlds source is dead 01:18 < bridge> i also intend to inline std::max, min and abs 01:18 < bridge> which arent right now 01:19 < bridge> aren't they inlined tho 01:20 < bridge> inlined manually not by the "Inline" keyword or compiler 01:20 < bridge> isn't it the same thing though 01:20 < bridge> well apart from the dont include all of base/math.h 01:20 < bridge> its what people use everywhere else 01:21 < bridge> it allows init list for varargs 01:21 < bridge> the only reason to not manually inline it is that its a big change 01:21 < bridge> we currently use both maximum and std::max 01:25 < bridge> when finish that pogo nade map 01:28 < bridge> ```sh 01:28 < bridge> > echo "#include " | gcc -std=c++11 -P -E -x c++ - | wc -l 01:28 < bridge> 10681 01:28 < bridge> > echo "#include \"math.h\"" | gcc -std=c++11 -P -E -x c++ - | wc -l 01:28 < bridge> 12977 01:28 < bridge> ``` 01:28 < bridge> base/math.h consists only of cstdlib cmath and algorithm, it will not make anything better in terms of including imo if we stop using it. inconsistence looks like real reason tho, too late to mention xd 01:30 < bridge> hm, both headers are fat af on c++17 and above 02:13 < bridge> https://cdn.discordapp.com/attachments/293493549758939136/1379251492007182356/image.png?ex=683f8f8c&is=683e3e0c&hm=1d05ef6d70b0ccd5f0f242ab7d6ee3046e92e7b026cf95c92d554bd9f958a919& 02:13 < bridge> me and the boys waiting for ddnet to stop dying after bad exit 12:11 < bridge> also means thin gs which dont need clamp dont include algorithm 12:11 < bridge> if i were to remove it from base/math.h as i should cuz iwyu 12:37 < bridge> Please write your thoughts down in this thread https://github.com/ddnet/ddnet/issues/9801 12:37 < bridge> The idea/need for limiting new features came from the observation, that a lot of gameplay features are being added right now, without much thought/evaluation. Many of those features will not be used a lot, but they add complexity and will be supported forever. Keep in mind, that ddnet doesn't try to make every single variable modifiable, but only add complexity where 'it makes sense' 12:37 < bridge> 12:37 < bridge> e.g. in this case, you have a few mappers saying it would be cool to be able to edit the duration/dash length of ninja 12:37 < bridge> would they use it for a map? maybe 12:37 < bridge> would that map be possible without the duration tune? also maybe 12:37 < bridge> do the tunes introduce more broken behavior or incomprehensible gameplay for players? maybe 12:37 < bridge> those are questions which should be answered before introducing new gameplay features. The thought was that these questions can't really be answered solely on github, as we pretty much only have developers there as you say. So requiring a map for new features puts mappers into the process (thats the idea at least). 12:38 < bridge> i know the idea 12:38 < bridge> but mappers dont use github so no way a new map will be released 12:38 < bridge> grace period is a better idea 12:42 < bridge> in a case of tiles i would say this can be more strict 12:42 < bridge> but these are just tunes that change hardcoded values 12:42 < bridge> not much else to do with them 12:42 < bridge> I agree that grace period would be a smoother workflow when you want to code a new feature. However, this puts the work onto the maintainers. There currently isn't any infrastructure in place to help with this. 12:42 < bridge> You could for example ask the mappers who asked for this feature if they are still interested in this feature and would like to create a map 12:43 < bridge> I did 12:43 < bridge> if its not released its a pain to have an github acc, download the artifacts etc etc 12:43 < bridge> its just not somethich non tech people will do 12:43 < bridge> its just not somethig non tech people will do 12:44 < bridge> some hard coded values should maybe not be modified. e.g. higher ninja_velocity would probably only lead to more broken gameplay. ninja dashes are already very buggy 12:45 < bridge> i would say thats up to mapper and testers to decide 12:45 < bridge> there might be some good application fir it 12:45 < bridge> there might be some good application for it 12:45 < bridge> theres plenty of tunes where changing them would just make the game feel bad 12:48 < bridge> this does not sound like a sufficient reason for adding something to me. Also, what people say what they want and what they are actually gonna use can vary a lot 12:49 < bridge> then maybe open a discussion for that. While you could use any file sharing site for that, I agree that its not the best practice to tell mappers to download binaries from any dev directly 12:49 < bridge> true i guess 12:49 < bridge> but for ninja velocity tune have to be combined with movetime 12:49 < bridge> if you use just 1 it becomes weird 13:08 < bridge> most of the time is "uuuhh rendering idk" which is epic 13:08 < bridge> https://cdn.discordapp.com/attachments/293493549758939136/1379416562632495114/image.png?ex=68402948&is=683ed7c8&hm=4b4d0592a9d0cba2f0696f1471efa65621881f2b3a41886ff3844d6efeb9503f& 13:09 < bridge> idk what the wait thing is, im not capping the fps 13:09 < bridge> nice, can you do the same with my PR and compare? 13:10 < bridge> which one? 13:10 < bridge> nice, can you do the same with [my PR]() and compare? 13:10 < bridge> ^ was already searching for the link for you 😄 13:10 < bridge> this graph doesnt help in figuring out whats taking all the render time 13:10 < bridge> normally you arnet bottle knecked by gpu at all 13:12 < bridge> unless your pr reduces shit rendered then i doubt i will see any improvement 13:12 < bridge> atleaast on my gpu bottleknecked machine 13:13 < bridge> it does _some_ things, which might improve gpu batching. I overall want to find out, if it looks roughly equal 13:13 < bridge> well im currently compiling 13:13 < bridge> so we will see 13:13 < bridge> this is on tater btw, i should probably compare with plain ddnet 13:16 < bridge> ``` 13:16 < bridge> 2025-06-03 12:15:48 I chat/server: *** You have been punished for bad client. Get official client from ddnet.org/downloads 13:16 < bridge> 2025-06-03 12:15:48 I broadcast: You have been punished for bad client. Get official client from ddnet.org/downloads 13:16 < bridge> ```` 13:16 < bridge> uhhh opk 13:16 < bridge> ``` 13:16 < bridge> 2025-06-03 12:15:48 I chat/server: *** You have been punished for bad client. Get official client from ddnet.org/downloads 13:16 < bridge> 2025-06-03 12:15:48 I broadcast: You have been punished for bad client. Get official client from ddnet.org/downloads 13:16 < bridge> ```` 13:16 < bridge> uhhh ok 13:17 < bridge> time to punish for bad server 😠 13:18 < bridge> https://cdn.discordapp.com/attachments/293493549758939136/1379419002765447188/image.png?ex=68402b8e&is=683eda0e&hm=103da998f42d5993e3c26d0801b328d43d2f360ae4cea4c70fce429ed8f7056b& 13:18 < bridge> looks pretty much the same 13:18 < bridge> left is totar, right is asssin 13:18 < bridge> left is totar, right is assa 13:19 < bridge> https://cdn.discordapp.com/attachments/293493549758939136/1379419145711517696/flamegraph-tater.svg?ex=68402bb0&is=683eda30&hm=34862c8c2c49b4a9d0e020d916a81409c2880f9bcfdfee8f853e9885b037de48& 13:19 < bridge> https://cdn.discordapp.com/attachments/293493549758939136/1379419146089009172/flamegraph-assasin.svg?ex=68402bb0&is=683eda30&hm=1c68c09b767a3cc7ad873bfe7d2f3893eefaf8bfd6dc5ddb29d0f89f5ce795a3& 13:20 < bridge> what are this huge peaks? 13:20 < bridge> standard library going brr 13:21 < bridge> it doesnt really matter as its so thin 13:21 < bridge> (how wide = how big time) 13:21 < bridge> yeah was just wondering ^^ I can't tell much from the images, because of the low res 😦 13:21 < bridge> well thats why i gave u svgs 13:21 < bridge> . 13:23 < bridge> the flamegraph tools mustve gotten better since they now take like 30s to do everything 13:23 < bridge> instead of an hour xd 13:24 < bridge> ddnet looks the exact same aswell 13:24 < bridge> this is really useless 13:25 < bridge> uhh why we showing 128 view? 13:25 < bridge> https://cdn.discordapp.com/attachments/293493549758939136/1379420704839045332/image.png?ex=68402d24&is=683edba4&hm=c2f6a2848b47315b1e068f87288cf79c0f5bb026afa6af3462251fbe86d0f1d8& 13:25 < bridge> oh i guess there is 68 13:25 < bridge> there should probbaly bea middle ground 13:25 < bridge> to prevent half wasted space lmao 13:27 < bridge> I see a 1300 samples in my graph in CRenderLayer::RenderTileLayer, I wonder if there is an issue 13:28 < bridge> well the limiting facotr is just rendering shit, but theres not yet a way to profile that 13:28 < bridge> I don't get this graphs, they are uncomparable. The line is much thinner in tators version, while it has much more samples there 13:28 < bridge> its semi random since its different times different circumstances 13:28 < bridge> i just stand afk, zoomed out in a server 13:29 < bridge> for abta min 13:29 < bridge> we should really have a standard test fake server 13:29 < bridge> which is a recording of something and has everything going on all at once 13:29 < bridge> So a demo? 13:29 < bridge> and if the server doesnt play it back right or the client messes shit up oh no (dada you got a test) 13:29 < bridge> Coverage map? 13:30 < bridge> and you can also use it for profiling 13:30 < bridge> mm demos dont have the server bit tho 13:30 < bridge> I use demos with my benchmark script for profiling 13:30 < bridge> I use demos with my benchmark script for profiling (rendering) 13:32 < bridge> I also see, that you have recorded the initialization as well 13:33 < bridge> yeah 13:33 < bridge> i dont have control over when it starts and stops recording 13:33 < bridge> i was hoping i would get more clear breakdown than "rendering" 13:34 < bridge> well you get, at least in my PR I see which functions are called how much. But one of these is UploadTileData, which only happens on map load 13:34 < bridge> is that an improvement 13:35 < bridge> everything that happens on setup time is an improvement for afterwards 13:35 < bridge> kk 13:35 < bridge> does that fuck with uhhm 13:35 < bridge> realtime uploading quads 13:35 < bridge> idk what its called 13:36 < bridge> ? 13:36 < bridge> the editor doesn't use this rendering and afaic hot reloading reloads also the rendering map 13:37 < bridge> the server can add quads at any time 13:37 < bridge> Idk if ddnet needs more fps improvements since it's already very good 13:37 < bridge> it does 13:37 < bridge> xd 13:37 < bridge> But a major thing would be not rendering envelopes if they're off screen 13:37 < bridge> low end machines exists 13:37 < bridge> ??? 13:37 < bridge> Loopray has 100 envelopes while only 2 max are on screen at once 13:38 < bridge> But lowers fps a lot 13:38 < bridge> its what infclass uses for the ui 13:38 < bridge> guess that's broken in my PR 13:39 < bridge> are you sure it adds them and then removes them from the map? 13:39 < bridge> well i know it creates and deletes something from a layer called #generated 13:40 < bridge> yes but you are sending the player the map once 13:40 < bridge> it appears to work still 13:40 < bridge> https://cdn.discordapp.com/attachments/293493549758939136/1379424446368059432/image.png?ex=684030a0&is=683edf20&hm=9c7ed7ea83b5506530ffc7ec5baa4e9073e65d666a406589487f31bc542f0725& 13:40 < bridge> no, thats something different 13:40 < bridge> then it doesn't do that 13:40 < bridge> envelopes are doing the work here 13:41 < bridge> the server sends a custom server time to start the animation 13:41 < bridge> iirc 13:41 < bridge> ah does the server advance time 13:41 < bridge> yes 13:42 < bridge> i see 13:42 < bridge> thats wack 13:43 < bridge> I think its quite smart and works well :) 13:43 < bridge> @sollybunny will be a lot easier to implement this layer in the rendering pipeline btw, since you can just use the polymorphism for your advantage and create a InfclassLayer or something 🙂 13:44 < bridge> time to convert the shrek movie into animated quads 13:49 < bridge> agreed 13:49 < bridge> but every time they say shrek, it speeds up by a factor of 2. 13:53 < bridge> I wonder what's easier, using more quads or making a million very long envelopes 14:02 < bridge> - mail at work that mfa will be enforced in a week 14:02 < bridge> - everyone rushing to get ther mfa done 14:02 < bridge> - login server crashes 14:02 < bridge> ☕ :owo: 14:09 < bridge> https://cdn.discordapp.com/attachments/293493549758939136/1379431695907946496/image.png?ex=68403760&is=683ee5e0&hm=c04e61753a5d46404609b1de07151304fd893134c56ff8daeced8544eb7fc3b9& 14:09 < bridge> fps drops i dont know why D: 14:14 < bridge> theres no garbage collection for this.. to happen? 14:15 < bridge> It can still be a large allocation in theory. But it doesn't mean it's inside ddnet 14:18 < bridge> im thinking its either chat or particles 14:19 < bridge> @ryozuki im gonna use llvm :monkaStop: currently reading https://llvm.org/docs/WritingAnLLVMBackend.html 14:19 < bridge> or both 14:20 < bridge> tater client? 14:20 < bridge> i get frame drops on both 14:20 < bridge> tater its worse 14:21 < bridge> reconstructing the entire chat is expensive, not showing it reduces the drops by a ton 14:22 < bridge> niceu 14:22 < bridge> im reading to only write my own worse version :lol: 14:22 < bridge> im reading it to only write my own worse version :lol: 14:24 < bridge> do you think the compiler inlines "allocation" of particle slots 14:24 < bridge> right now its on the stack then copied to the array if it finds a spot, but it could be find a slot then write into there directly 14:24 < bridge> its cross compilation unit so idk 14:25 < bridge> it would also be less work if you could allocate multiple particles at once, and write as many as there are (or all) 14:25 < bridge> by returning a null terminated array of particle ptrs 14:26 < bridge> TRANSLATION UNIT 14:27 < bridge> its cross translation unit so idk 14:28 < bridge> you could also have a reduced particle mode 14:37 < bridge> particle slider? 😛 14:38 < bridge> it's like there is some merit to the default settings some games have for graphics, from "Potato" to "Ultra" 14:38 < bridge> but ddnet so far always ran very well on potato 14:41 < bridge> well im having issues x-x 14:41 < bridge> partially solved by disabling particles 14:42 < bridge> ||maybe you should stop the erotic stream in the background? /s|| 🙈 14:43 < bridge> D:!!! 14:43 < bridge> howd u know 15:43 < bridge> <01000111g> Could someone integrate audio packs to the asset section of the client? Right now its very weird: You create a new folder called audio in ur tw directory and put the files in there and it magically works. Still it should be consistent with the other (visual) assets 17:09 < bridge> it would be different from all the current assets 17:10 < bridge> that its a folder per "asset" (soundpack) 17:10 < bridge> i guess all the other folders could support folders aswell eventually 17:29 < bridge> #6753 17:29 < bridge> https://github.com/ddnet/ddnet/issues/6753 17:32 < bridge> #5321 17:32 < bridge> https://github.com/ddnet/ddnet/issues/5321 17:45 < bridge> the asset loader is a mess 17:46 < bridge> no chance im fixing it, but it does look like soundpacks can be added to the system 18:10 < bridge> i could add so it always creates an empty audio folder 18:10 < bridge> other than that soundpacks arent implemented 21:06 < bridge> @teero777 I downloaded the demo, compiled the latest master and it doesn't crash for me. Tested with all backends on windows 21:11 < bridge> 19.3 download doesn't crash for me either 22:38 < bridge> i compiled latest master and it crashes for me 22:39 < bridge> it's a negative index. it might index into valid memory for you somehow 22:39 < bridge> check with asan 22:54 < bridge> Or add debug messages logging relevant variable values 23:02 < bridge> holly... it took 2.5 hours and 2 ooms to build llvm with x86 target :pepeW: 23:07 < bridge> my guess is, if you debug, you'll notice that this line `int TileLayerAndOverlayCount = GetTileLayerAndOverlayCount(pTMap, LayerType, &pTiles);` 23:07 < bridge> returns 0 and is maybe not properly handled, I wonder if the map contains some invalid data or something 23:09 < bridge> @teero777 can you checkout the pipeline PR? It might already fix this issue 23:10 < bridge> i get the crash 23:10 < bridge> i get the crash on master 23:10 < bridge> ill check with the pipeline 23:13 < bridge> @essigautomat no crash 23:14 < bridge> ы 23:18 < bridge> :poggers: 23:24 < bridge> okay cool :D