02:53 <+bridge> [ddnet] New c++? https://github.com/carbon-language/carbon-lang 02:54 <+bridge> [ddnet] seems sorta like Rust-lite designed existing cpp code bases 02:54 <+bridge> [ddnet] seems sorta like Rust-lite designed for existing cpp code bases 07:34 <+bridge> [ddnet] @deen maybe its time to update pts with vk? https://www.phoronix.com/scan.php?page=news_item&px=Zink-Lazy-Descriptors-Default 07:34 <+bridge> [ddnet] Then he can test zink vs native vk xdd 09:44 <+bridge> [ddnet] What's the purpose of the 'use clipping' feature on map groups? 09:48 <+bridge> [ddnet] true, thought about that too 09:55 <+bridge> [ddnet] have we ever done profile guided optimization? 09:55 <+bridge> [ddnet] maybe we can get some perf 10:26 <+bridge> [ddnet] Tried everything. Ofast best option for tw 10:26 <+bridge> [ddnet] Rest only few percentage 10:26 <+bridge> [ddnet] `-Ofast` is dangerous, it lets the compiler mess up float calculations, probably changing gameplay 10:26 <+bridge> [ddnet] wrong reply 10:27 <+bridge> [ddnet] clipping lets you show the layer only when the player is in certain positions 10:28 <+bridge> [ddnet] Tw uses quantinized floats tho 10:28 <+bridge> [ddnet] It's also not dangerous. It's simply not standard conform 10:28 <+bridge> [ddnet] yes, it's not standard conformant 10:28 <+bridge> [ddnet] yes, but we had compiler options change gameplay before 10:29 <+bridge> [ddnet] so having quantized floats is apparently not enough to work against it 10:29 <+bridge> [ddnet] https://github.com/ddnet/ddnet/blob/5daa0f96f593460a594ba237646b3119d5b6c4c1/CMakeLists.txt#L303-L308 10:29 <+bridge> [ddnet] Yes i bet vsc compiles different float than gcc too 10:30 <+bridge> [ddnet] probably not, on x64 10:30 <+bridge> [ddnet] I'd guess they're abiding by IEEE, hopefully with the same rounding mode 10:30 <+bridge> [ddnet] IEEE 754 10:30 <+bridge> [ddnet] I think bsd also has a forced difference 10:31 <+bridge> [ddnet] Smth about storing redults in registers 10:32 <+bridge> [ddnet] this doesn't matter anymore in x64 AFAIK because you can use the IEEE 754 compliant sse registers and not the weird stuff people use on x86 10:32 <+bridge> [ddnet] so compilers just use that AFAIK 10:33 <+bridge> [ddnet] Anyway only server accuarcy matters more . the 2 edges u have client side prediction almost dont natter 10:33 <+bridge> [ddnet] I use it sincr 3-4 years 10:33 <+bridge> [ddnet] Never seen a problem. Runs smooth af 10:39 <+bridge> [ddnet] perhaps one could find out which part of -Ofast gives the benefit 10:40 <+bridge> [ddnet] Probs sqrt and loop hard unrools 10:45 <+bridge> [ddnet] `-Ofast` on gcc apparently additionally enables `-ffast-math`, `-fallow-store-data-races`, `-fno-protect-parens` and disables `-fsemantic-interposition` 10:47 <+bridge> [ddnet] I don't understand what `-fallow-store-data-races` does precisely from the docs 10:49 <+bridge> [ddnet] looks like people even complain about it & asks about improving the documentation 10:49 <+bridge> [ddnet] ``` 10:49 <+bridge> [ddnet] Allow the compiler to perform optimizations that may introduce new data races 10:49 <+bridge> [ddnet] on stores, without proving that the variable cannot be concurrently accessed 10:49 <+bridge> [ddnet] by other threads. Does not affect optimization of local data. It is safe to 10:49 <+bridge> [ddnet] use this option if it is known that global data will not be accessed by 10:49 <+bridge> [ddnet] multiple threads. 10:50 <+bridge> [ddnet] 10:50 <+bridge> [ddnet] Examples of optimizations enabled by -fallow-store-data-races include 10:50 <+bridge> [ddnet] hoisting or if-conversions that may cause a value that was already in memory 10:50 <+bridge> [ddnet] to be re-written with that same value. Such re-writing is safe in a single 10:50 <+bridge> [ddnet] threaded context but may be unsafe in a multi-threaded context. Note that on 10:50 <+bridge> [ddnet] some processors, if-conversions may be required in order to enable 10:50 <+bridge> [ddnet] vectorization. 10:50 <+bridge> [ddnet] ``` 10:51 <+bridge> [ddnet] yes, that's what I found as well (it's the result of the documentation bug ^^) 10:51 <+bridge> [ddnet] yes, " 10:51 <+bridge> [ddnet] Suggested improvement" 10:51 <+bridge> [ddnet] yes, "Suggested improvement" 10:58 <+bridge> [ddnet] how many programming languages does Google wants to make 11:02 <+bridge> [ddnet] google using cloudflare's "quiche" (quic library): https://security.googleblog.com/2022/07/dns-over-http3-in-android.html 12:36 <+bridge> [ddnet] @Not Keks wrote a script too see if the 'bounding box' optimization for tilemaps would help (if you have a better name, go ahead :p) 12:36 <+bridge> [ddnet] bounding box here is the smallest rectangle around all non-zero-id tiles in the layer 12:36 <+bridge> [ddnet] to measure the optimization, I took the bounding box of the game layer to approximate the area in which the gameplay happens 12:36 <+bridge> [ddnet] then, for each tile layer I calculate size_of_tiles_layer_bounding_box / size_of_game_layer_bounding box to get the 'coverage' of the tiles layer on the gameplay area 12:36 <+bridge> [ddnet] I then average that over all the tiles layers of the map to get the 'coverage' of the map 12:36 <+bridge> [ddnet] then averaged again over all maps to get the total average coverage 12:37 <+bridge> [ddnet] (I disregarded clipping, parallax and everything else for this) 12:37 <+bridge> [ddnet] https://cdn.discordapp.com/attachments/293493549758939136/999263813989847070/tilemap_bounding_box.py 12:37 <+bridge> [ddnet] https://cdn.discordapp.com/attachments/293493549758939136/999263883481075732/output.txt 12:38 <+bridge> [ddnet] `Total coverage: 63%` (at the end of the output) 12:39 <+bridge> [ddnet] I think this indicates that this optimization could improve the performance significantly 12:41 <+bridge> [ddnet] feel free to look over the code though, I'm not 100% sure it all makes sense 13:04 <+bridge> [ddnet] But also only if the user views the empty pixels. But yeah might help in some maps.. Is that per layer? Are bigger layers weighted more? 13:04 <+bridge> [ddnet] If u have a 2x2 layer anf its filled with 1 tile the coverage is 25% 13:05 <+bridge> [ddnet] per layer, averaged for the map 13:05 <+bridge> [ddnet] all layers are weighted the same 13:05 <+bridge> [ddnet] rendering videos is bugged on 16.2.2? Im having issues :/ 13:05 <+bridge> [ddnet] ah damn 13:05 <+bridge> [ddnet] you are right, but maybe its still fine as an approximation, I don't think that is something regular in maps 13:05 <+bridge> [ddnet] Yrah probs 13:06 <+bridge> [ddnet] More precise pls 13:07 <+bridge> [ddnet] well I also don't take positioning into account so its hard to fix that easily in the calculation I think, coz for that I'd need to somehow include the 'outer-tile-repeats' logic somwhow 13:07 <+bridge> [ddnet] ah, might actually be possible 13:07 <+bridge> [ddnet] this is the video im getting 13:07 <+bridge> [ddnet] https://cdn.discordapp.com/attachments/293493549758939136/999271416358780928/renderwork.mp4 13:08 <+bridge> [ddnet] https://cdn.discordapp.com/attachments/293493549758939136/999271493152276520/10uwu.demo 13:08 <+bridge> [ddnet] but demo is working good 😅 13:08 <+bridge> [ddnet] I check if the rightmost column is filled, if yes, set max_x to the siez of the game layer 13:09 <+bridge> [ddnet] hm that will still not take offsets into account 13:09 <+bridge> [ddnet] eh maybe I just leave it at that 13:17 <+bridge> [ddnet] i fixed it setting windowed screen before render, with windowed bordeless im having issues although i never had an issue, idk 😅 13:36 <+bridge> [ddnet] Maybe buggy driver 14:41 <+bridge> [ddnet] the dma was passed \o/ 14:41 <+bridge> [ddnet] users will be able to install any software they like on apple's hardware 🙂 14:43 <+bridge> [ddnet] :poggers: 23:29 <+bridge> [ddnet] @Not Keks is there a reason why I shouldn't use vertex buffers as uniform buffers? 23:29 <+bridge> [ddnet] not sure what my thought process was there, but its what I did a few times 23:36 <+bridge> [ddnet] https://developer.nvidia.com/blog/vulkan-dos-donts/ 23:37 <+bridge> [ddnet] hm seems like a nice resource