06:49 <+bridge> [ddnet] <gerdoe> :kek:
06:50 <+bridge> [ddnet] <gerdoe> u
09:43 <+bridge> [ddnet] <Ryozuki> i hate debian 9 now
09:59 <+bridge> [ddnet] <lynn> will tune prediction get fixed
10:17 <+bridge> [ddnet] <Ryozuki> fix it urself
10:17 <+bridge> [ddnet] <Ryozuki> :greenthing:
10:39 <+bridge> [ddnet] <Learath2> What is broken about it? Do we have an issue on it?
10:39 <+bridge> [ddnet] <Learath2> My condolences
10:40 <+bridge> [ddnet] <lynn> according to Sorah there's an issue with dragger-related tuning, showing connections to sees even if laser_bounce_delay is 0
10:40 <+bridge> [ddnet] <lynn> removing antiping fixes this
10:40 <+bridge> [ddnet] <lynn> according to Sorah there's an issue with dragger-related tuning, showing connections to tees even if laser_bounce_delay is 0
10:40 <+bridge> [ddnet] <lynn> im not sure if there's an issue for it, it's an odd one to search for
10:40 <+bridge> [ddnet] <Learath2> Um what would laser_bounce_delay even mean in the context of draggers? 😄
10:41 <+bridge> [ddnet] <Learath2> I don't see the tuning referred to in dragger.cpp
10:41 <+bridge> [ddnet] <lynn> i dont really understand how it works personally but it should not show the laser when the tee gets teleported
10:41 <+bridge> [ddnet] <lynn> it's easy to replicate on my Volleyball map
12:43 <+lynn> irc moment
16:42 <+bridge> [ddnet] <Jupstar> lol did debian edit the LTS release death date?
16:42 <+bridge> [ddnet] <Jupstar> https://wiki.debian.org/LTS
16:42 <+bridge> [ddnet] <Jupstar> i could swear it was 2023 last time i looked
16:43 <+bridge> [ddnet] <Jupstar> ah we chose ubuntu18
16:43 <+bridge> [ddnet] <Jupstar> right
16:46 <+bridge> [ddnet] <deen> I think Ubuntu for CI tests, but Debian for official build since Debian uses an older glibc
16:46 <+bridge> [ddnet] <Jupstar> i think our current glibc dependencies are pretty low
16:46 <+bridge> [ddnet] <Ryozuki> debian 9 ends  july right?
16:46 <+bridge> [ddnet] <Ryozuki> can we use c++20 then
16:46 <+bridge> [ddnet] <Jupstar> not even from 2016 or whenever debian 9 is from
16:46 <+bridge> [ddnet] <Jupstar> ubuntu18
16:46 <+bridge> [ddnet] <Jupstar> is the problem xd
16:46 <+bridge> [ddnet] <Jupstar> ok we probs static link c++ right?
16:47 <+bridge> [ddnet] <Jupstar> so it might be fine
16:47 <+bridge> [ddnet] <deen> GCC does not yet support full C++20 anyway, so you definitely can't use all features
16:47 <+bridge> [ddnet] <Ryozuki> :stopdude:
16:47 <+bridge> [ddnet] <Ryozuki> c++17 then
16:47 <+bridge> [ddnet] <Jupstar> if newer libc symbols arent used it wont matter theoretically xd
16:48 <+bridge> [ddnet] <deen> Yes, C++17 should be mostly fine with GCC 7, only feature lists GCC 8: https://gcc.gnu.org/projects/cxx-status.html#cxx17
16:48 <+bridge> [ddnet] <Jupstar> DR: [[nodiscard]] for constructors
16:48 <+bridge> [ddnet] <Jupstar> 
16:48 <+bridge> [ddnet] <Jupstar> [[nodiscard]] with message
16:48 <+bridge> [ddnet] <Jupstar> 
16:48 <+bridge> [ddnet] <Jupstar> c++20 has some quality of life stuff
16:49 <+bridge> [ddnet] <Jupstar> and i hope c++2248 then finally supports char8_t so, that we dont have to care about passing UTF8 around anymore cross platform xd
16:49 <+bridge> [ddnet] <Ryozuki> is nodiscard used to not ignore return values?
16:49 <+bridge> [ddnet] <Ryozuki> like rust must_use?
16:49 <+bridge> [ddnet] <Jupstar> probs
16:49 <+bridge> [ddnet] <Jupstar> c++17 already supports it
16:49 <+bridge> [ddnet] <deen> yes
16:49 <+bridge> [ddnet] <Jupstar> but c++20 makes it better xd
16:49 <+bridge> [ddnet] <deen> but it's nice to have a custom error message
16:50 <+bridge> [ddnet] <deen> explaining why you have to use the return value
17:06 <+bridge> [ddnet] <c0d3d3v> tunning for collision is broken too
17:08 <+bridge> [ddnet] <c0d3d3v> you can see it on the oco map
17:08 <+bridge> [ddnet] <Learath2> How did these things even break without anyone noticing:/
17:09 <+bridge> [ddnet] <Learath2> I might take a look if ddnet decides to compile on mac this week
17:09 <+bridge> [ddnet] <c0d3d3v> on oco map collision is turend off for the complete map
17:09 <+bridge> [ddnet] <Jupstar> can someone use nightly really quick with opengl and confirm that its broken rn?
17:09 <+bridge> [ddnet] <Jupstar> i guess i broke it somehow
17:09 <+bridge> [ddnet] <c0d3d3v> but it struggles because of prediction. and somehow ddnet overwrites this collision paramter
17:10 <+bridge> [ddnet] <Learath2> Tuning? What does that have to do with gl?
17:10 <+bridge> [ddnet] <Jupstar> not tuning related
17:10 <+bridge> [ddnet] <Jupstar> i just want confirmation that my setup isnt broken
17:10 <+bridge> [ddnet] <Jupstar> but that i broke the code
17:10 <+bridge> [ddnet] <Learath2> Ah
17:11 <+bridge> [ddnet] <c0d3d3v> I can build it... takes maybe 5min xD
17:11 <+bridge> [ddnet] <Jupstar> xd
17:11 <+bridge> [ddnet] <Jupstar> viewport is wrong and i worked on that, but only vulkan, but maybe smth broke it xd
17:12 <+bridge> [ddnet] <Learath2> @Not Keks you could always do a git stash save and check if your change broke it
17:13 <+bridge> [ddnet] <Jupstar> can also try old version if its not my setup xd
17:13 <+bridge> [ddnet] <Jupstar> else it must be one of the last 2-3 prs from me
17:15 <+bridge> [ddnet] <Jupstar> somehow fullscreen related xd
17:19 <+bridge> [ddnet] <c0d3d3v> you mean this:
17:19 <+bridge> [ddnet] <c0d3d3v> https://cdn.discordapp.com/attachments/293493549758939136/965995087651803236/unknown.png
17:19 <+bridge> [ddnet] <Jupstar> yes
17:20 <+bridge> [ddnet] <c0d3d3v> xDD
17:20 <+bridge> [ddnet] <c0d3d3v> https://cdn.discordapp.com/attachments/293493549758939136/965995208120606770/unknown.png
17:20 <+bridge> [ddnet] <Jupstar> xd
17:20 <+bridge> [ddnet] <c0d3d3v> but in window it works
17:20 <+bridge> [ddnet] <c0d3d3v> https://cdn.discordapp.com/attachments/293493549758939136/965995293688606740/unknown.png
17:20 <+bridge> [ddnet] <c0d3d3v> partially
17:20 <+ChillerDragon> Yo @Ryozuki do you know makedeb? https://docs.makedeb.org/introduction/welcome/ this seems to be "yay" for debian haha https://github.com/AFK-OS/una
17:20 <+bridge> [ddnet] <c0d3d3v> dropdown is broken
17:21 <+bridge> [ddnet] <Ryozuki> i dont use debian
17:21 <+bridge> [ddnet] <Ryozuki> only for sv
17:21 <+ChillerDragon> u used too and still
17:21 <+ChillerDragon> PolyMC ppl advertise that on debian install page
17:21 <+ChillerDragon> https://polymc.org/wiki/installing/linux/ubuntu/
17:21 <+bridge> [ddnet] <c0d3d3v> dropdown is broken in all window setting with opengl
17:23 <+bridge> [ddnet] <Jupstar> its this commit
17:23 <+bridge> [ddnet] <Jupstar> https://github.com/ddnet/ddnet/commit/50f9aa88d334365f3225d5c0347920f9e750549e
17:23 <+bridge> [ddnet] <Jupstar> but it must be in graphics_threaded.*
17:23 <+bridge> [ddnet] <Jupstar> i am just blind xD
17:24 <+bridge> [ddnet] <c0d3d3v> I can at least tell you in f60ae47be10a282cc7b5d7bab7a275c223ba916b from 12.04 it worked xD
17:24 <+bridge> [ddnet] <Jupstar> ah
17:24 <+bridge> [ddnet] <Jupstar> found it
17:24 <+bridge> [ddnet] <Jupstar> 2x m_ScreenWidth
17:25 <+bridge> [ddnet] <c0d3d3v> gg
17:25 <+bridge> [ddnet] <Jupstar> why does this happen so often xD
17:25 <+bridge> [ddnet] <Jupstar> too much copy pasta
17:54 <+bridge> [ddnet] <Patiga> @Not Keks after spending too much time with trying that other solution, I took a step back and tried to figure out what exactly is wrong and how to best fix it. turns out, I only need an `srgb_to_rgb` function in the shader and call it on the sampled color from the texture, before mixing it with the other colors
17:55 <+bridge> [ddnet] <Jupstar> ok still weird
17:55 <+bridge> [ddnet] <Jupstar> that also means the backend converted the flat images to srgb at some point?
17:55 <+bridge> [ddnet] <Jupstar> but why isnt there a flat RGB texture format
17:55 <+bridge> [ddnet] <Jupstar> impossible xd
17:55 <+bridge> [ddnet] <Patiga> I'm not sure exactly, but I suppose its a side effect of rendering to an srgb texture
17:56 <+bridge> [ddnet] <Jupstar> ok
17:56 <+bridge> [ddnet] <Patiga> its weird
17:56 <+bridge> [ddnet] <Patiga> but now it renders nicely with webgl :)
17:56 <+bridge> [ddnet] <Patiga> I'm gonna try to rly soon
17:56 <+bridge> [ddnet] <Jupstar> kinda inverted function * normal function = neutral element xD
17:56 <+bridge> [ddnet] <Patiga> yeah ^^
17:57 <+bridge> [ddnet] <Jupstar> and can i also compile to native code?
17:57 <+bridge> [ddnet] <Patiga> yes, runs on both
17:57 <+bridge> [ddnet] <Jupstar> cool
17:57 <+bridge> [ddnet] <Patiga> much much more fps on native
17:57 <+bridge> [ddnet] <Jupstar> yeah
17:57 <+bridge> [ddnet] <Jupstar> thats what i am interested in xD
17:57 <+bridge> [ddnet] <Jupstar> the difference
17:58 <+bridge> [ddnet] <Jupstar> for the ddnet web client its huge
17:58 <+bridge> [ddnet] <Jupstar> 10k vs 300fps xd
17:59 <+bridge> [ddnet] <Jupstar> but since pthreads are badly supported and GLES3 might use some workarounds to work on webgl2 i dunno what causes the bottleneck
17:59 <+bridge> [ddnet] <Jupstar> or if browsers are that slow
17:59 <+bridge> [ddnet] <Ryozuki> rust wgpu right?
17:59 <+bridge> [ddnet] <Jupstar> or maybe javascript only allows certain amount of FPS
17:59 <+bridge> [ddnet] <Patiga> yeah
17:59 <+bridge> [ddnet] <Jupstar> but zooming out also was worse
17:59 <+bridge> [ddnet] <Jupstar> so no idea
18:00 <+bridge> [ddnet] <Tater> There is a ddnet web client?
18:00 <+bridge> [ddnet] <Ryozuki> did u learn it with https://sotrh.github.io/learn-wgpu/#what-is-wgpu
18:00 <+bridge> [ddnet] <Jupstar> its just ddnet compiled for webasm
18:00 <+bridge> [ddnet] <Ryozuki> or another source?
18:01 <+bridge> [ddnet] <Jupstar> https://aliveclan.de/ddnettest/load_map.html
18:01 <+bridge> [ddnet] <Jupstar> 
18:01 <+bridge> [ddnet] <Jupstar> using render demo you will load the full client
18:01 <+bridge> [ddnet] <Jupstar> 
18:01 <+bridge> [ddnet] <Jupstar> render map is stripped down
18:01 <+bridge> [ddnet] <Jupstar> 
18:01 <+bridge> [ddnet] <Jupstar> tho keep in mind it has no HTTP/curl or UDP support
18:01 <+bridge> [ddnet] <Jupstar> since curl has no websockets backend and UDP wont work on websockets
18:01 <+bridge> [ddnet] <Tater> Neat
18:01 <+bridge> [ddnet] <Patiga> yes, but only till the end of "The Pipeline", after that I mostly used the docs and rarely came back to the tutorial for documentation
18:02 <+bridge> [ddnet] <Ryozuki> i see
18:02 <+bridge> [ddnet] <Jupstar> -20% waifu pfp
18:03 <+bridge> [ddnet] <Patiga> on dm1, zoomed out to full map: for me its 80 fps in firefox, where I have many tabs open, 140 in chromium with it being the single tab, ~2800 with the vulkan backend, not sure where the bottlenecks are
18:03 <+bridge> [ddnet] <Jupstar> ok i see
18:03 <+bridge> [ddnet] <Jupstar> yeah firefox was slwoer for me too
18:03 <+bridge> [ddnet] <Jupstar> and zooming completly broke firefox
18:04 <+bridge> [ddnet] <Jupstar> while chrome still worked
18:04 <+bridge> [ddnet] <Ryozuki> :monkaS:
18:04 <+bridge> [ddnet] <Patiga> zooming works fine for me, and with practically no performance overhead ^^
18:04 <+bridge> [ddnet] <Jupstar> i used a huge map
18:04 <+bridge> [ddnet] <Jupstar> maybe that makes a difference
18:05 <+bridge> [ddnet] <Patiga> which one is it?
18:05 <+bridge> [ddnet] <Jupstar> gimme a second
18:05 <+bridge> [ddnet] <Patiga> can you link it in heinrichs collection?
18:06 <+bridge> [ddnet] <Jupstar> Back in Time 3.map
18:06 <+bridge> [ddnet] <Jupstar> its a official ddnet map but let me find the link
18:07 <+bridge> [ddnet] <Patiga> its not yet in heinrichs collection
18:07 <+bridge> [ddnet] <Jupstar> https://github.com/ddnet/ddnet-maps/blob/master/types/insane/maps/Back%20in%20Time%203.map?raw=true
18:07 <+bridge> [ddnet] <Patiga> ah, nice
18:08 <+bridge> [ddnet] <Jupstar> then one zoom step further for unknown reason
18:08 <+bridge> [ddnet] <Jupstar> https://cdn.discordapp.com/attachments/293493549758939136/966007427583590431/unknown.png
18:08 <+bridge> [ddnet] <Jupstar> https://cdn.discordapp.com/attachments/293493549758939136/966007462060765244/unknown.png
18:08 <+bridge> [ddnet] <Jupstar> from 200 fps to 30fps
18:08 <+bridge> [ddnet] <Jupstar> on firefox
18:09 <+bridge> [ddnet] <Jupstar> dunno if its some weird mipmap glitch
18:09 <+bridge> [ddnet] <Jupstar> but on chrome it doesnt happen
18:09 <+bridge> [ddnet] <Ryozuki> :Sadge:
18:10 <+bridge> [ddnet] <Jupstar> maybe it somehow maps around VRAM to safe memory on the host and then has to load it or smth like that
18:11 <+bridge> [ddnet] <Jupstar> you generate the vertices different @Patiga , maybe its better for u 😄
18:12 <+bridge> [ddnet] <Patiga> yeah, I'm not sure if my approach will be faster in the end, thought so in the start
18:12 <+bridge> [ddnet] <Jupstar> it wont be faster than ddnet ones if u mean that 😛
18:12 <+bridge> [ddnet] <Patiga> for tilemaps I just use one quad that fills the entire screen, and the fragment shader does the rest
18:12 <+bridge> [ddnet] <Patiga> why? ^^
18:12 <+bridge> [ddnet] <Jupstar> let me look into your shader again
18:14 <+bridge> [ddnet] <Jupstar> u dont use mipmaps?
18:14 <+bridge> [ddnet] <Jupstar> ok dunno how old the shaders are u sent me
18:14 <+bridge> [ddnet] <Jupstar> color is float
18:14 <+bridge> [ddnet] <Patiga> yeah I don't have mip maps yet
18:15 <+bridge> [ddnet] <Jupstar> maybe ur buffers are even a bit bigger than DDNets ones
18:15 <+bridge> [ddnet] <Jupstar> i dunno what groupinfo is used for
18:15 <+bridge> [ddnet] <Patiga> group info just has the group offset in it
18:15 <+bridge> [ddnet] <Jupstar> so you use local groups?
18:15 <+bridge> [ddnet] <Patiga> but my buffers are also constant, is that also like that in the ddnet code?
18:15 <+bridge> [ddnet] <Jupstar> yes
18:16 <+bridge> [ddnet] <Jupstar> but we use more drawcalls instead of drawing too much
18:16 <+bridge> [ddnet] <Jupstar> to save time on the GPU
18:16 <+bridge> [ddnet] <Patiga> it kinda mimics the map format, map consists of groups of layers
18:16 <+bridge> [ddnet] <Jupstar> ok
18:17 <+bridge> [ddnet] <Patiga> how does ddnet do it? always render a constant amount of tiles, repeating if its not enough?
18:17 <+bridge> [ddnet] <Jupstar> well best is to show u
18:17 <+bridge> [ddnet] <Jupstar> gimme a second
18:18 <+bridge> [ddnet] <Jupstar> https://cdn.discordapp.com/attachments/293493549758939136/966009984464879636/1.png
18:18 <+bridge> [ddnet] <Jupstar> https://cdn.discordapp.com/attachments/293493549758939136/966009984733302834/2.png
18:18 <+bridge> [ddnet] <Jupstar> https://cdn.discordapp.com/attachments/293493549758939136/966009985198858260/3.png
18:19 <+bridge> [ddnet] <Jupstar> one row at a time but from the same buffer and never too much
18:19 <+bridge> [ddnet] <Jupstar> so the GPU state never changes
18:19 <+bridge> [ddnet] <Jupstar> the rasterizer should detect no fragment overlapping
18:20 <+bridge> [ddnet] <Jupstar> so its nicely batched on the fragment stage
18:21 <+bridge> [ddnet] <Patiga> and what is contained in the buffer for the tiles?
18:21 <+bridge> [ddnet] <Jupstar> layout (location = 0) in vec2 inVertex;
18:21 <+bridge> [ddnet] <Jupstar> #ifdef TW_TILE_TEXTURED
18:21 <+bridge> [ddnet] <Jupstar> layout (location = 1) in vec3 inVertexTexCoord;
18:21 <+bridge> [ddnet] <Jupstar> #endif
18:21 <+bridge> [ddnet] <Jupstar> 5 * 4 bytes
18:21 <+bridge> [ddnet] <Jupstar> and 3 coordinates
18:21 <+bridge> [ddnet] <Jupstar> bcs we use 2d array textures
18:22 <+bridge> [ddnet] <Jupstar> 3 texture coordinates*
18:22 <+bridge> [ddnet] <Jupstar> no other data is streamed tho
18:22 <+bridge> [ddnet] <Jupstar> so saves a bit of bandwidth
18:23 <+bridge> [ddnet] <Patiga> I don't get it yet, you have a buffer that contains the vertices of a row of tiles?
18:24 <+bridge> [ddnet] <Jupstar> yeah every tiles
18:24 <+bridge> [ddnet] <Jupstar> 
18:24 <+bridge> [ddnet] <Jupstar> row to row
18:24 <+bridge> [ddnet] <Jupstar> and then additionally the CPU has information about tile offsets
18:24 <+bridge> [ddnet] <Jupstar> thats why everyone is mad at me that is uses a lot of RAM xd
18:24 <+bridge> [ddnet] <Jupstar> but it has direct access, without any calculations xd
18:25 <+bridge> [ddnet] <Patiga> ah so the cpu sends the gpu each row of tiles, essentially
18:25 <+bridge> [ddnet] <Patiga> and does the cpu calculate the coordinates of the vertices, or are they precomputed somehow?
18:25 <+bridge> [ddnet] <Jupstar> it basically says
18:25 <+bridge> [ddnet] <Jupstar> 
18:25 <+bridge> [ddnet] <Jupstar> render from this offset in the buffer, this amount of tiles
18:25 <+bridge> [ddnet] <Jupstar> and then per row
18:25 <+bridge> [ddnet] <Jupstar> all precomputed
18:25 <+bridge> [ddnet] <Jupstar> it just starts draw calls and sets the tile color
18:26 <+bridge> [ddnet] <Patiga> wait it sends offset + amount of tiles, so is that buffer just a row of tiles or is it the entire 2d tile layer?
18:27 <+bridge> [ddnet] <Jupstar> on the GPU it does only save what it uses
18:27 <+bridge> [ddnet] <Jupstar> on the CPU it saves the offset per tile and stores 1 bit, if the tile is active or not
18:28 <+bridge> [ddnet] <Patiga> okay could we maybe start at the beginning? we are on the cpu and  have a 2d array of tiles, so what do we compute as the cpu?
18:28 <+bridge> [ddnet] <Jupstar> first we calculate all vertices of all tiles that are not index 0
18:28 <+bridge> [ddnet] <Jupstar> upload all vertices to gpu
18:29 <+bridge> [ddnet] <Jupstar> now we on the CPU
18:29 <+bridge> [ddnet] <Jupstar> 
18:29 <+bridge> [ddnet] <Jupstar> we see how big the current scene is
18:29 <+bridge> [ddnet] <Jupstar> first tile index of the first visible tile will contain the index of the current tile offset that is about to render
18:29 <+bridge> [ddnet] <Patiga> oooh
18:29 <+bridge> [ddnet] <Jupstar> now we see how many tiles there are to render in this line
18:29 <+bridge> [ddnet] <Jupstar> and that repeats per line
18:30 <+bridge> [ddnet] <Patiga> yeah that sounds good, I might need to try that to
18:31 <+bridge> [ddnet] <Patiga> and that way I also see how it can be much faster, since its just primitive draw calls, that should be fast
18:31 <+bridge> [ddnet] <Patiga> my approach scales better tho :>
18:31 <+bridge> [ddnet] <Jupstar> ^^
18:31 <+bridge> [ddnet] <Jupstar> how do you render border tiles btw?
18:31 <+bridge> [ddnet] <Jupstar> or do you simply not
18:31 <+bridge> [ddnet] <Patiga> I do
18:32 <+bridge> [ddnet] <Jupstar> i managed to beat the native driver in a instanced rendering optimization:
18:32 <+bridge> [ddnet] <Jupstar> https://github.com/Jupeyy/ddnet/commit/67c1ab36cc8db0cd49e976d2dfaaeacbb723c009
18:32 <+bridge> [ddnet] <Jupstar> 
18:32 <+bridge> [ddnet] <Jupstar> but its only like 35fps to 42fps when zooming out fare
18:32 <+bridge> [ddnet] <Jupstar> i managed to beat the native driver in a instanced rendering optimization:
18:32 <+bridge> [ddnet] <Jupstar> https://github.com/Jupeyy/ddnet/commit/67c1ab36cc8db0cd49e976d2dfaaeacbb723c009
18:32 <+bridge> [ddnet] <Jupstar> 
18:32 <+bridge> [ddnet] <Jupstar> but its only like 35fps to 42fps when zooming out far
18:32 <+bridge> [ddnet] <Jupstar> and below that its not really worth it
18:32 <+bridge> [ddnet] <Patiga> so on my setup the gpu simply has the 2d array of tiles. in the frament shader it indexes into that texture, clamping between 0 and max_tiles
18:33 <+bridge> [ddnet] <Jupstar> border rendering is really most challenging one in optimization without storing data from a previous frame
18:33 <+bridge> [ddnet] <Jupstar> the GPU clock speeds are simply too low
18:33 <+bridge> [ddnet] <Jupstar> looping 4k tiles is slow
18:34 <+bridge> [ddnet] <Patiga> hmm, yea
18:34 <+bridge> [ddnet] <Jupstar> especially the border cornes(not the left right top bottom lines, they are kinda ok) 😄
18:34 <+bridge> [ddnet] <Patiga> I wonder what kind of optimizations could be found for that the-fragment-shader-does-everything-for-the-tilemaps approach
18:34 <+bridge> [ddnet] <Jupstar> what is that xd
18:34 <+bridge> [ddnet] <Jupstar> i dont get it
18:34 <+bridge> [ddnet] <Jupstar> u want to skip the vertex shader?
18:35 <+bridge> [ddnet] <Patiga> nah maybe that fragment shader could be written more efficiently
18:36 <+bridge> [ddnet] <Jupstar> border tiles, ns shoot up XD
18:36 <+bridge> [ddnet] <Jupstar> https://cdn.discordapp.com/attachments/293493549758939136/966014348990505011/unknown.png
18:36 <+bridge> [ddnet] <Patiga> heh ^^
18:36 <+bridge> [ddnet] <Patiga> which program is that?
18:36 <+bridge> [ddnet] <Jupstar> renderdoc
19:26 <+ChillerDragon> @Ryozuki when new blog post explaining the network code?
19:28 <+ChillerDragon> Where is ``m_Data.m_aChunkData`` being initialized before it is used here? https://github.com/ChillerDragon/teeworlds/blob/1fc3b63c873e4813f1ff7805428c8a335cc4e70f/src/engine/shared/network.cpp#L45
19:31 <+bridge> [ddnet] <deen> line 291?
19:32 <+bridge> [ddnet] <deen> or ~312 for the conn case
19:34 <+ChillerDragon> But isnt that called after it is being used already?
19:34 <+ChillerDragon> https://github.com/ChillerDragon/teeworlds/blob/610249c9e30fe9763e88cb293989dace11337e03/src/engine/shared/network_client.cpp#L72-L77
19:36 <+bridge> [ddnet] <Ryozuki> https://stockfishchess.org/blog/2022/stockfish-15/
19:38 <+bridge> [ddnet] <Ryozuki> > Stockfish 15 continues to push the boundaries of chess, providing unrivalled analysis and playing strength. In our testing, Stockfish 15 is ahead of Stockfish 14 by 36 Elo points and wins nine times more game pairs than it loses.
19:38 <+bridge> [ddnet] <Ryozuki> :greenthing:
19:40 <+bridge> [ddnet] <Chairn> 36 elo, that's at least 3 washing machines
19:51 <+bridge> [ddnet] <fokkonaut> ?
19:52 <+bridge> [ddnet] <fokkonaut> its not being used there
19:54 <+ChillerDragon> ``unsigned char *pEnd = m_Data.m_aChunkData + m_Data.m_DataSize;
19:54 <+ChillerDragon> aaa
19:54 <+ChillerDragon> ``unsigned char *pEnd = m_Data.m_aChunkData + m_Data.m_DataSize;`` this line is reading/using ``m_Data.m_aChunkData`` isnt it?
20:04 <+bridge> [ddnet] <fokkonaut> it sets a pointer to the final size to later on compare against
21:32 <+bridge> [ddnet] <Tater> is it possible for windowed mode to have a border? for me it's just shows the game on top of my desktop with no title bar, but I assume that's intentional.
21:33 <+bridge> [ddnet] <Jupstar> no
21:33 <+bridge> [ddnet] <Jupstar> windowed = normal window
21:34 <+bridge> [ddnet] <Jupstar> with title and everything
21:34 <+bridge> [ddnet] <Tater> why can't I see the title then
21:34 <+bridge> [ddnet] <Jupstar> press META + KEY UP
21:34 <+bridge> [ddnet] <Tater> META?
21:34 <+bridge> [ddnet] <Jupstar> the windows key
21:34 <+bridge> [ddnet] <Jupstar> super key
21:34 <+bridge> [ddnet] <Tater> ye nvm
21:34 <+bridge> [ddnet] <Jupstar> kde calls it meta key xd
21:34 <+bridge> [ddnet] <Tater> that works ty
22:02 <+bridge> [ddnet] <c0d3d3v> @ChillerDragon gamelayer gets not selected in latest master with Ctrl+Right click
22:02 <+bridge> [ddnet] <c0d3d3v> tested on cave fly
22:02 <+bridge> [ddnet] <c0d3d3v> https://cdn.discordapp.com/attachments/293493549758939136/966066389246959646/game_layer_gets_not_selected-2022-04-19_21.59.23.mp4
22:03 <+tee> hi
22:03 <+tee> anyone here?
22:05 <+bridge> [ddnet] <c0d3d3v> I think so 😄
23:07 <+bridge> [ddnet] <c0d3d3v> if someone wants to test some maps xD  https://github.com/ddnet/ddnet/pull/4980#issuecomment-1103174684