00:43 < bridge> @learath2 does this look similar to what we need for bans? https://debezium.io/ 00:45 < bridge> looks very new age, sounds like it is atleast similar to what we want, but one thing is it won't solve any other problem we might want to solve with a message queue, like shipping chat messages to one place, or shipping logs 02:15 < bridge> xxxxD 02:15 < bridge> Idk what en and pl stands for but I don’t think it’s languages. Both sounds are used to differentiate which flag was captured 02:18 < bridge> not which but which time 02:18 < bridge> sounds differ if you grab flag from stand and from died player 02:19 < bridge> The sounds he sent is capture not grab 02:19 < bridge> Oh wait no grab 02:19 < bridge> Xd 02:20 < bridge> But the same exists for capture too 02:20 < bridge> I can’t even guess what en and pl stand for 02:49 < bridge> <0xdeen> I didn't have that great experience trying to use Debezium to mirror our ranks from MySQL (but could have been a mistake from my side), the setup seemed complex and finicky too 03:56 < bridge> true, but it can be used as a compromise for a smoother client experience 03:58 < bridge> doesn't sound worth the limited developer and reviewer bandwidth the project has 04:02 < bridge> anticheat is not always a losing game, it depends on the game type 04:03 < bridge> if you never trust the client then the cheats are limited by their ability to play the game legitimately better than a human, which is sometimes not possible depending on your game. 05:38 < bridge> ^ the end of lag :) 05:39 < bridge> (in solo until 8372) 05:39 < bridge> (in solo, until 8372) 05:46 < bridge> :0 05:55 < bridge> 😃 08:33 <+ws-client> https://github.com/ddnet/ddnet/blob/64f4ea1512b5abcc1ef27b90ede05cb9934df69b/src/engine/shared/huffman.cpp#L57 this overflows on init 08:33 <+ws-client> not sure if that is intended i really don't understand the huffman code but even if it is intended it is a bit weird 08:35 <+ws-client> https://github.com/ddnet/ddnet/blob/64f4ea1512b5abcc1ef27b90ede05cb9934df69b/src/engine/shared/huffman.h#L30 symbol is a `unsigned char` and `i` reaches `256` 08:35 <+ws-client> so it flips to zero in the last iteration 08:35 <+ws-client> thats the eofSymbol so maybe its intended but still :D 08:39 < bridge> Where does the init table come from? 08:45 < bridge> I thought huffman was supposed calculate the optimal frequency table for any given data then store that frequency table with the data so it can be decompressed with the optimal table, but it seems like we just use the same one for all data as far as I can tell. 08:45 < bridge> so someone must have created it from some TW packet data? 08:45 < bridge> or something 08:48 < bridge> omg of course it' 08:48 < bridge> omg of course it's 15 years old .-. 08:48 < bridge> https://github.com/ddnet/ddnet/commit/878ede3080ab2cfb627aca505c397d9765052996#diff-c39dd1d454f6249c201c0662b73ccf1aaee23f00bcc5ae34d034f96d325d8ec0 08:56 < bridge> someone was writing ddnet huffman file in rust? https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=8505fd268fea3cba6468da5447571347 09:02 < bridge> unless this frequency table is some sort of standard made by someone else it's possible we are leaving free bandwidth savings on the table by either regenerating it or sending the huffman tree along with the packet, but I think our packets are too small for that 09:06 < bridge> well aparently not free if u need to sync such a table with the client 😄 09:06 < bridge> btw @totar ur pr sends the inputs as individual packets right? 09:06 < bridge> it only does 1 flush which means they get compressed together 09:06 < bridge> but they are processed individually yes 09:06 <+ws-client> @totar the table is pre calculated and hardcodet into the client and server 09:07 < bridge> i see, maybe a new network packet would be nice where it takes the binary diff of the inputs.. since most bytes are mostly similar 😄 09:07 < bridge> ok but it's 15 years old and highly likely does not match the current distributation of data 09:07 <+ws-client> someone probably ran the numbers of which format the tw trafic has 09:07 < bridge> also there's no source in the original commit so we have no idea the quality of it's generation even 15 years ago 09:07 <+ws-client> i dont think that much changed in the last 15 years 09:07 < bridge> also there's no comments in the original commit so we have no idea the quality of it's generation even 15 years ago 09:07 <+ws-client> idk about 15 but the last 10 years for sure it barley changed 09:08 < bridge> simply changing which type of packet gets sent more often would significantly change the frequency table 09:08 <+ws-client> its mostly snap thats relevant i would say 09:08 <+ws-client> always has been i guess 09:08 < bridge> true 09:08 < bridge> but still we have no idea how much data was sampled to create it in the first place 09:08 < bridge> or how 09:08 <+ws-client> yea 09:09 < bridge> could you explain more? 09:09 <+ws-client> omg i dont wanna debug the fakin huffman code -.- im procrastinating so hard 09:09 < bridge> I think compressing the inputs more would be good for sure 09:09 < bridge> the oldest input packet is the base and all new inputs are binary patches of that one 09:10 < bridge> so all other input packets are basically only the difference between the inputs 09:10 < bridge> the client does that already sorta 09:10 < bridge> or you mean something more special? 09:10 < bridge> but the client uses a input packet that is ack'd by the server or not? 09:10 < bridge> with 300 ping that is pretty old 09:11 < bridge> I'm not sure storing binary patches for a 120byte struct is practical 09:11 < bridge> why not 09:11 < bridge> you need pointer to location of each patch? 09:11 < bridge> I guess it doesn't need to be 4 byte pointer 09:12 < bridge> actually I have no idea how binary diff algorithm works tbh 09:12 < bridge> maybe it's more clever 09:13 < bridge> let say u have two vec 09:13 < bridge> 09:13 < bridge> then it simply puts a 0 where the binary diff is equal else it puts a diff 09:13 < bridge> very simplificated 09:13 < bridge> and then compressions can normally very well compress these 0's 09:16 < bridge> very simplified 09:16 < bridge> the client and server will bundle I think 1400bytes of data to pass to the huffman which is about ~10 inputs. I'm not sure to what extend the huffman algorithm will naturally perform something similar to your idea by nature of how it works, it would probably be quite good without the fixed frequency table but now I'm not sure it's even doing anything anymore 09:17 < bridge> can it :troll: 09:17 < bridge> 🚂 09:20 < bridge> mh well i can only tell you compression algorithms as good as they are, are also not perfect.. for teeworlds snapshots taking binary diffs with zstd outperformed any compression i tested easily. 09:20 < bridge> 09:20 < bridge> The only disadvantage of binary patching is that the base "file" can get old (e.g. by a higher ping) 09:21 < bridge> well it should always arrive in the same "pack" of inputs so you start the diff from the start with every packet 09:21 < bridge> well it should always arrive in the same "cluster" of inputs so you start the diff from the start with every packet 09:22 < bridge> yeah probably because our huffman table is trash lol 09:22 < bridge> but how do u want to create a general purpose huffman table for snapshots, inputs etc. 09:22 < bridge> or do u want to use different tables per purpose? 09:22 < bridge> I don't think there's a correct answer 09:23 < bridge> but remember that having a fixed table means it changes the network protocol 09:23 < bridge> but remember that having a fixed table means it changes the network protocol anytime we update it 09:24 < bridge> I mean a seperate table for every type of message would be very good tbh but I think the network system smushes all the messages together regardless of type 09:24 < bridge> which might be better anyway since many messages are much less than the 1400byte size 09:24 < bridge> i think heinrich did tests in that direction 09:25 < bridge> also why do we use 1400bytes 09:25 < bridge> seems small 09:25 < bridge> UDP can be 64kb I think 09:26 < bridge> cuz its data mtu 09:26 < bridge> a UDP frame usually isnt much bigger than 1400 bytes if u think cross plattform afaik 09:27 < bridge> here we have an expert 09:27 < bridge> epyc 09:27 < bridge> no u 09:27 < bridge> i can say anything about net until Devinci comes and tells what exactly is wrong kekw 09:28 < bridge> bruh this uni sucks why do i need to wait like 2 years just to start mess up with networks and its internals 09:34 < bridge> So, this is the list of strings I couldn't translate, some because I don't know where they occure, and some because I don't know technical terms behind them 09:34 < bridge> 09:34 < bridge> ``` 09:34 < bridge> (paused) 09:34 < bridge> Add 09:34 < bridge> All combined 09:34 < bridge> Folder Link 09:34 < bridge> Follow 09:34 < bridge> Force vote 09:34 < bridge> Game paused 09:34 < bridge> Grabs 09:34 < bridge> Loading commands… 09:34 < bridge> Moved ingame 09:34 < bridge> No results 09:34 < bridge> NOT CONNECTED 09:35 < bridge> Personal best: 09:35 < bridge> Replace video 09:35 < bridge> Save 09:35 < bridge> Searching 09:35 < bridge> Server best: 09:35 < bridge> Sound error 09:35 < bridge> Super 09:35 < bridge> The audio device couldn't be initialised. 09:35 < bridge> The server is running a non-standard tuning on a pure game type. 09:35 < bridge> Try again 09:35 < bridge> Trying to determine UDP connectivity… 09:35 < bridge> Vote command: 09:35 < bridge> Vote description: 09:35 < bridge> 09:35 < bridge> [Graphics error] 09:35 < bridge> A render command failed. Try to update your GPU drivers. 09:35 < bridge> last ones are pretty verbose 09:36 < bridge> I never heard "command rendering" 09:36 < bridge> I never heard "command rendering", that's why I asked about them too 09:37 < bridge> drawing operations and memory transfers are called render commands at least in vulkan 09:38 < bridge> framebuffer is buffer of frames, practically transliteration is used 09:39 < bridge> of frame* 09:40 < bridge> "did not understand anything, but very interesting" 10:29 < bridge> "anticheat" as was used in the discussion was explicitly about trusting the client and then trying apply heuristics/detect cheats on top of it 10:30 < bridge> yeah that's fair 10:32 < bridge> So, this is the list of strings I couldn't translate, some because I don't know where they occure, and some because I don't know technical terms behind them 10:32 < bridge> 10:32 < bridge> ``` 10:32 < bridge> (paused) 10:32 < bridge> Add 10:32 < bridge> All combined 10:32 < bridge> Folder Link 10:32 < bridge> Follow 10:32 < bridge> Force vote 10:32 < bridge> Game paused 10:32 < bridge> Grabs 10:32 < bridge> Loading commands… 10:32 < bridge> Moved ingame 10:32 < bridge> No results 10:32 < bridge> NOT CONNECTED 10:32 < bridge> Personal best: 10:32 < bridge> Replace video 10:32 < bridge> Save 10:32 < bridge> Searching 10:32 < bridge> Server best: 10:32 < bridge> Sound error 10:32 < bridge> Super 10:33 < bridge> The audio device couldn't be initialised. 10:33 < bridge> The server is running a non-standard tuning on a pure game type. 10:33 < bridge> Try again 10:33 < bridge> Trying to determine UDP connectivity… 10:33 < bridge> Vote command: 10:33 < bridge> Vote description: 10:33 < bridge> 10:33 < bridge> ~~[Graphics error] 10:33 < bridge> A render command failed. Try to update your GPU drivers.~~ 10:33 < bridge> So, this is the list of strings I couldn't translate, some because I don't know where they occure, and some because I don't know technical terms behind them 10:33 < bridge> 10:33 < bridge> ``` 10:33 < bridge> (paused) 10:33 < bridge> Add 10:33 < bridge> All combined 10:33 < bridge> Folder Link 10:33 < bridge> Follow 10:33 < bridge> Force vote 10:33 < bridge> Game paused 10:33 < bridge> Grabs 10:33 < bridge> Loading commands… 10:33 < bridge> Moved ingame 10:33 < bridge> No results 10:33 < bridge> NOT CONNECTED 10:33 < bridge> Personal best: 10:33 < bridge> Replace video 10:33 < bridge> Save 10:33 < bridge> Searching 10:34 < bridge> Server best: 10:34 < bridge> I'll be editing this message when I find an appropriate translation for a certain string 10:34 < bridge> So, this is the list of strings I couldn't translate, some because I don't know where they occure, and some because I don't know technical terms behind them 10:34 < bridge> 10:34 < bridge> ``` 10:34 < bridge> (paused) 10:34 < bridge> Add 10:34 < bridge> All combined 10:34 < bridge> Folder Link 10:34 < bridge> Follow 10:34 < bridge> Force vote 10:34 < bridge> Game paused 10:34 < bridge> Grabs 10:34 < bridge> Loading commands… 10:34 < bridge> Moved ingame 10:34 < bridge> No results 10:34 < bridge> NOT CONNECTED 10:34 < bridge> Personal best: 10:34 < bridge> Replace video 10:34 < bridge> Save 10:34 < bridge> Searching 10:34 < bridge> Server best: 10:34 < bridge> Sound error 10:34 < bridge> Super 10:34 < bridge> The audio device couldn't be initialised. 10:34 < bridge> The server is running a non-standard tuning on a pure game type. 10:34 < bridge> Try again 10:34 < bridge> Trying to determine UDP connectivity… 10:35 < bridge> Vote command: 10:35 < bridge> Vote description: 10:35 < bridge> 10:35 < bridge> [Graphics error] 10:35 < bridge> An error during command recording occurred. Try to update your GPU drivers. 10:37 < bridge> And, btw, the progress is 95% (581 out of 607 strings translated), so the PR is not really that far away! 10:39 < bridge> actually double checking the inputs are only like 40bytes which is a lot less than I thought 10:40 < bridge> and how many packets will be deployed when having 300ms prediction margin? 10:40 < bridge> plus 3 ints 10:40 < bridge> hi 10:41 < bridge> 300/20ms = 15 inputs, so ((40+4+4+4)*15)/1400 = 0.55 packets 10:44 < bridge> probably a bit more with the overhead from message struct but idk how big that is 10:52 < bridge> https://cdn.discordapp.com/attachments/293493549758939136/1247110654306025513/ca8a3758b1011aa9.png?ex=665ed5ce&is=665d844e&hm=d5bd03c0590179d6b9bb49047c093e24922be8deb7428ce788b6d66b00e27fea& 10:52 < bridge> Hm, for some reason "Time limit" is not translated, while "Score limit" is 10:53 < bridge> interesting 10:54 < bridge> maybe it’s worth doing a quick regex search to find which string literals are not translated, and then determine if they should be translated 10:54 < bridge> not a catch-all but probably still worthwhile 11:18 < bridge> 300/20ms = 15 inputs, so ((40+4+4+4)*15)/1400 = 0.55 packets (at most, non-unique inputs are skipped) 12:06 < bridge> @everyone@here 12:06 < bridge> 12:06 < bridge> # В СТИМЕ НАЧАЛАСЬ ЛЕТНЯЯ РАЗДАЧА $10 12:06 < bridge> # [steamcommunity.com/gift](https://shorturl.at/QIHm2) [.](https://imgur.com/a/TCsCopk) 12:08 < bridge> not sure if someone already answered, but this is exactly what is done already in snap deltas ^^ 12:25 < bridge> There probably is no reason, just an oversight 12:34 < bridge> Haha, by remaking the translation I found so many bugs... 12:47 < bridge> yes, thanks for actually caring about a good translation! 🙂 12:51 < bridge> Looks like there are two time limit strings, did you also translate the other one or does it not work for some reason? For example in german.txt: 12:51 < bridge> ``` 12:51 < bridge> Time limit 12:51 < bridge> == Zeitlimit 12:51 < bridge> 12:51 < bridge> Time limit: %d min 12:51 < bridge> == Zeitlimit: %d min 12:52 < bridge> ``` 12:56 < bridge> I translated both 12:56 < bridge> 12:56 < bridge> ``` 12:56 < bridge> 12:56 < bridge> Time limit 12:56 < bridge> == Обмеження по часу 12:56 < bridge> 12:56 < bridge> Time limit: %d min 12:56 < bridge> ==Обмеження по часу: %dхв 12:56 < bridge> ``` 12:56 < bridge> I translated both 12:56 < bridge> 12:56 < bridge> ``` 12:56 < bridge> Time limit 12:56 < bridge> == Обмеження по часу 12:57 < bridge> 12:57 < bridge> Time limit: %d min 12:57 < bridge> ==Обмеження по часу: %dхв 12:57 < bridge> ``` 12:57 < bridge> This is the list of strings I haven't translated yet, btw 😏 12:59 < bridge> This is the list of strings I haven't translated yet, btw 😏 12:59 < bridge> Need some help 🥺 13:00 < bridge> egyt: can you mark the strings that you don't know where they appear? 13:00 < bridge> I can figure out where they appear 13:05 < bridge> of multiple snaps? 13:07 < bridge> I think it rarely ever sends an actual full snap, and typically just deltas, which only include items that change, and for those items the binary diff 13:07 < bridge> yea the server diffs multiple snaps to create efficient updates 13:07 < bridge> mh i see, but i think u dont even need to do the items part 13:07 < bridge> 13:07 < bridge> zstd + custom dict performs just as good if not even better 13:08 < bridge> All of those mentioned in my list 13:08 < bridge> that confuses me xD 13:08 < bridge> it diffs multiple snaps for a single snap 13:08 < bridge> or it sends previous snaps to create a snapshot chain? 13:08 < bridge> All of those mentioned in my list 13:08 < bridge> Would be nice if you could send screenshots of GUI too 13:08 < bridge> well the item part helps because most items don't need to be updated coz they stay the same 13:08 < bridge> Server sends only the changes 13:08 < bridge> well thats why it *should* help 13:08 < bridge> as snap delta 13:09 < bridge> in reality ofc you might find that this optimization doesn't help 13:09 < bridge> yes but i don't see how that makes the binary diff better 13:09 < bridge> a 13:09 < bridge> well maybe it does, but i could not oberse it 😄 13:09 < bridge> well maybe it does, but i could not observe it 😄 13:10 < bridge> @patiga what i wonder tho is if the snapshot packet is used to _unpack_ old snapshots 13:10 < bridge> it relies on snapshots you received earlier, not ones in the future 13:10 < bridge> yes 13:10 < bridge> but in the input case of tater it's about actually sending old inputs 13:10 < bridge> with high prediction margin they still come in before the tick that handles these inputs is used 13:11 < bridge> so you basically have a higher success rate when packet drop 13:11 < bridge> I'm confused about your usage of "unpack" 13:11 < bridge> u basically have a chain of inputs until the current one 13:12 < bridge> well it sounded a bit like snapshots are used similary like the input concept here 😄 13:12 < bridge> but i guess it just sends the current snapshot 13:12 < bridge> iirc, input isn't in the snapshot 13:13 < bridge> well i think we just talk past each other xD 13:13 < bridge> yea seems likely 😅 13:13 < bridge> like what i want is: 13:13 < bridge> 13:13 < bridge> binary patch the input chain: 13:13 < bridge> - very old input 13:13 < bridge> - old input 13:13 < bridge> - input 13:13 < bridge> 13:13 < bridge> old & current input can be binary diffs of the very old one 13:14 < bridge> they are directly send in the same network packet anyway 13:14 < bridge> if the very old input is a binary diff smth like it's done with snapshots is ofc possible yeah 13:14 < bridge> basically my _optimization_ is in first place unrelated to any binary diff of a previous packet 13:15 < bridge> just so u can send a lot of inputs in a single packet 13:15 < bridge> ah right, I jumped into the discussion at the wrong time, with a wrong thing in mind xd 13:16 < bridge> sounds fun though :) 13:21 < bridge> like what i want is: 13:21 < bridge> 13:21 < bridge> binary patch the input chain: 13:21 < bridge> - very old input 13:21 < bridge> - old input 13:21 < bridge> - input 13:21 < bridge> 13:21 < bridge> old input can be binary diff of the very old one 13:21 < bridge> current input of old input* 13:27 < bridge> While I can guess where they appear, I can't be sure, as it happened with yesterday stuff 14:02 < bridge> I had an interesting idea to improve performance in rendering on at least some maps, which is already tested and proven to be useful, is anyone interested? maybe @jupeyy_keks 14:03 < bridge> > "NOT CONNECTED" 14:03 < bridge> displayed in rcon while not connected to a server 14:04 < bridge> > "Trying to determine UDP connectivity…" 14:04 < bridge> displayed in the connecting screen when the server does not respond, but testing the internet connection hasn't finished yet 14:07 < bridge> Okay, 24 left 14:10 < bridge> > "Loading commands…" 14:10 < bridge> displayed in rcon while not all command descriptions have been downloaded from the server yet 14:11 < bridge> > "Personal best:" 14:11 < bridge> best race time of the current map of the current player 14:11 < bridge> > "Server best:" 14:11 < bridge> best race time of the current map on the server 14:13 < bridge> > "The audio device couldn't be initialised." 14:13 < bridge> this one looks a bit misleading. it just means "couldn't initialize the sound system, the client will not be able to play sounds" 14:14 < bridge> > "The server is running a non-standard tuning on a pure game type." 14:14 < bridge> displayed when the server admin changed the server source code for a vanilla gametype (DM, CTF, TDM) and changed tunings (physic parameters, like gravity) there 14:14 < bridge> Yet another bug? ❤️ 14:14 < bridge> > "Sound error" 14:14 < bridge> this is just the title of the message box of the aforementioned audio initialization error 14:15 < bridge> sure 14:15 < bridge> you can share ur idea 😄 14:17 < bridge> > "Add" 14:17 < bridge> opposite of the "Remove" button you already translated, used for the adding vote options in the vote option menu 14:19 < bridge> > "Try again" 14:19 < bridge> shown in the "incorrect password" dialog that contains a field for the password, clicking "try again" will use the password in the field for connecting to the server again 14:31 < bridge> So, In a map I am working on, I have a lot of quads, about 8000 distributed in 50 groups. For context, I would be currently on r4 on the list with the most quads per map on ddnet, if my map would be there, anyway. I noticed, that a snow Strom, which was over 500 fields away from the spawn region, greatly dropped fps beside not quad of this layer being visible or in render distance. 14:31 < bridge> 14:31 < bridge> I improved the FPS by adding clip regions on every quadlayer, meaning I had to put every quad into it's own group and add a clipping region to it, because layers don't support clip regions. 14:31 < bridge> This causes the renderer to [skip]() the group, if it's region is out of bounds, instead of checking EVERY QUAD if it needs rendering. 14:31 < bridge> 14:31 < bridge> This improved, in my special case, the rendering up to a factor of 10 (from 500 fps to 5000) (machine one), (from 200 fps to 990 (fps cap!))(machine 2) 14:31 < bridge> 14:31 < bridge> My idea: Add, when loading a map, a virtual clip region to a quad layer. This improves FPS everywhere outside of the clip and if you have multiple quad layers without overlap, it'll improve overall fps. 14:31 < bridge> 14:31 < bridge> How to do this? Check every corner of a quad in a layer, min-max x/y for to generate a clip region, you only need to do this once, when loading the map 14:31 < bridge> You'll need to add possible envelope offsets, which is easy, the maximum/minimum value has to be a point in the envelope (except when rotating) 14:31 < bridge> TODO para X, Y, can be considered and recalculated, definately possible, para 0/0 can be skipped 14:31 < bridge> 14:31 < bridge> Also, you could pre-calculate this region at a minimum quad count, which still needs to be found 14:32 < bridge> So, In a map I am working on, I have a lot of quads, about 8000 distributed in 50 groups. For context, I would be currently on r4 on the list with the most quads per map on ddnet, if my map would be there, anyway. I noticed, that a snow Strom, which was over 500 fields away from the spawn region, greatly dropped fps beside no quad of this layer being visible or in render distance. 14:32 < bridge> 14:32 < bridge> I improved the FPS by adding clip regions on every quadlayer, meaning I had to put every quad into it's own group and add a clipping region to it, because layers don't support clip regions. 14:32 < bridge> This causes the renderer to [skip]() the group, if it's region is out of bounds, instead of checking EVERY QUAD if it needs rendering. 14:32 < bridge> 14:32 < bridge> This improved, in my special case, the rendering up to a factor of 10 (from 500 fps to 5000) (machine one), (from 200 fps to 990 (fps cap!))(machine 2) 14:32 < bridge> 14:32 < bridge> My idea: Add, when loading a map, a virtual clip region to a quad layer. This improves FPS everywhere outside of the clip and if you have multiple quad layers without overlap, it'll improve overall fps. 14:32 < bridge> 14:32 < bridge> How to do this? Check every corner of a quad in a layer, min-max x/y for to generate a clip region, you only need to do this once, when loading the map 14:32 < bridge> You'll need to add possible envelope offsets, which is easy, the maximum/minimum value has to be a point in the envelope (except when rotating) 14:32 < bridge> TODO para X, Y, can be considered and recalculated, definately possible, para 0/0 can be skipped 14:32 < bridge> 14:32 < bridge> Also, you could pre-calculate this region at a minimum quad count, which still needs to be found 14:34 < bridge> So, In a map I am working on, I have a lot of quads, about 8000 distributed in 50 groups. For context, I would be currently on r4 on the list with the most quads per map on ddnet, if my map would be there, anyway. I noticed, that a snow Strom, which was over 500 fields away from the spawn region, greatly dropped fps beside no quad of this layer being visible or in render distance. 14:34 < bridge> 14:34 < bridge> I improved the FPS by adding clip regions on every quadlayer, meaning I had to put every quad into it's own group and add a clipping region to it, because layers don't support clip regions. 14:34 < bridge> This causes the renderer to [skip]() the group, if it's region is out of bounds, instead of checking EVERY QUAD if it needs rendering. 14:34 < bridge> 14:34 < bridge> This improved, in my special case, the rendering up to a factor of 10 (from 500 fps to 5000) (machine one), (from 200 fps to 990 (fps cap!))(machine 2) 14:34 < bridge> 14:34 < bridge> My idea: Add, when loading a map, a virtual clip region to a quad layer. This improves FPS everywhere outside of the clip and if you have multiple quad layers without overlap, it'll improve overall fps. 14:34 < bridge> 14:34 < bridge>