00:15 < bridge_> <ƤØŢĀŤ0Co> Just some similar word combination 😅 no worries
01:00 < bridge_> <Ewan> you should probably make an issue about this
01:00 < bridge_> <Ewan> nobody is reading this wall of text on discord
01:02 < bridge_> <Ewan> but personally i don't really know, seems like a different gamemode entirely
01:02 < bridge_> <Ewan> seems weird to add a completely accessory gamemode to DDNet. it should be developed in parallel and if the admins like its implementation enough & think it will be played, they might host it
01:52 < ws-client> <ChillerDragon> What is "A defined spawn point."
01:52 < ws-client> <ChillerDragon> ?? "Server Stability Enhancements: Necessary adjustments to accommodate quick map changes and simultaneous player activities."
01:53 < ws-client> <ChillerDragon> why do we need this? "Administrative and Monitoring Tools: For initiating events, overseeing game progress, and managing player interactions."
01:55 < ws-client> <ChillerDragon> @ƤØŢĀŤ0Co that sounds like a lot of work. Not sure if anyone is motivated to pick that up. 
01:57 < ws-client> <ChillerDragon> I would say it is easier to realize if you just do it your self without ddnet. As a fork. Integrating such big changes into the main code base is a pain. 
01:58 < ws-client> <ChillerDragon> Then you can ask ddnet to announce it to get some players.
02:14 < bridge_> <sans._.> I would do it, pain and sweat, the problem is I have close to no experience in any C-like language, that sounds like a fun gamemode for a change
03:38 < bridge_> <chillerdragon> @sans._.: gather experience by doing it
03:38 < bridge_> <sans._.> bet
04:52 < bridge_> <zhn> he did already
04:55 < bridge_> <Ewan> [nope](https://cdn.discordapp.com/emojis/1232334761624866816.gif?size=48&quality=lossless&name=nope)
04:56 < bridge_> <Ewan> i didn't read i just have amazing inference powers
04:56 < bridge_> <zhn> wrong reply
04:56 < bridge_> <zhn> he opened issue i mean
05:01 < bridge_> <Ewan> i see
05:01 < bridge_> <Ewan> well then someone link it
06:42 < bridge_> <zhn> https://tenor.com/view/silly-cat-silly-car-car-stare-10-thousand-yard-stare-10-thousand-yard-gif-14200271775968563996
06:42 < bridge_> <zhn> https://tenor.com/view/silly-cat-silly-car-car-stare-10-thousand-yard-stare-10-thousand-yard-gif-14200271775968563996
07:19 < bridge_> <Ewan> i dont read those anymore
07:19 < bridge_> <Ewan> mb
07:57 < bridge_> <smlsd> Hello devs
07:57 < bridge_> <smlsd> Can you devs tell me which program used to make this game
07:57 < bridge_> <smlsd> And how did make online
08:24 < bridge_> <Jupstar ✪> it's made from scratch
08:24 < bridge_> <Jupstar ✪> also made from scratch
08:24 < bridge_> <Jupstar ✪> but it uses cpp and udp for network
08:26 < bridge_> <milkeeycat> ? :justatest:
08:26 < bridge_> <milkeeycat> https://cdn.discordapp.com/attachments/293493549758939136/1233665610572107827/image0.png?ex=662dec21&is=662c9aa1&hm=c46ede56804cb04f0d1c724341ed67d804a8758d857edeabd289cd03d45acd9b&
08:28 < bridge_> <Jupstar ✪> https://static.wikia.nocookie.net/international-pokedex/images/d/dd/Scratch_%28Ash%27s_Chimchar%29.png/revision/latest?cb=20190324180250
09:37 < bridge_> <meloƞ> :angy:
09:37 < bridge_> <meloƞ> https://cdn.discordapp.com/attachments/293493549758939136/1233683416738955358/image.png?ex=662dfcb7&is=662cab37&hm=7cdf86d86ad3e150ed4604b56c7a915153db929a5f10cdb1e733a1ae227dcf03&
09:37 < bridge_> <meloƞ> :angy: me broki something oopsie daisy
09:37 < bridge_> <meloƞ> https://cdn.discordapp.com/attachments/293493549758939136/1233683416738955358/image.png?ex=662dfcb7&is=662cab37&hm=7cdf86d86ad3e150ed4604b56c7a915153db929a5f10cdb1e733a1ae227dcf03&
09:38 < bridge_> <meloƞ> ```2024-04-27 09:37:07 I glslprogram: Error! Shader program wasn't linked! The linker returned:
09:38 < bridge_> <meloƞ> 
09:38 < bridge_> <meloƞ> Program Link Failed for unknown reason.```
09:38 < bridge_> <meloƞ> 
09:38 < bridge_> <meloƞ> ah gg
09:39 < bridge_> <ƤØŢĀŤ0Co> Alright, Im not that strong in c++, but I believe I could try to do this. I will need some help tho, but thats what github is for, right🤗?
09:39 < bridge_> <meloƞ> oh god damn it i confused source_dir with destination_dir :kek:
09:40 < bridge_> <meloƞ> :justatest:  setup repo and i might check in from time to time :kek:
09:41 < bridge_> <ƤØŢĀŤ0Co> Sure! Just woke, so not at this moment tho
09:44 < bridge_> <meloƞ> i wrote a small python script that merely copies the .exe and steam_api.dll that automatically executes after a clean rebuild which fixed it for me, couldnt find another way without modifying the cmakelist - only thing that bugs me is why steam_api.dll gets generated within `/build/Debug` while all other .dll's are under `/build/` - is there a reason for that?
09:51 < bridge_> <milkeeycat> did you move ur executable in different directory?
09:52 < bridge_> <meloƞ> yes - my data folder is under Project/build - while msvc builds the target (and for some reason steam_api.dll) under Project/build/Debug
09:56 < bridge_> <meloƞ> @archimede67 https://github.com/ddnet/ddnet/pull/7556 when :feelsbadman:
10:11 < ws-client> <ChillerDragon> https://github.com/ddnet/ddnet/issues/8271 can some powerful githubber assign me to this issue?
10:24 < ws-client> <ChillerDragon> ty jopsti
10:25 < bridge_> <meloƞ> did i break my fix_style.py or is this actually intended? :kek:
10:25 < bridge_> <meloƞ> https://cdn.discordapp.com/attachments/293493549758939136/1233695473802674219/image.png?ex=662e07f1&is=662cb671&hm=4b0f0d87cdd7412fa09c0920a3585a4287369c01b05c809759a63499615a56cd&
10:37 < bridge_> <nawretard> Hello, I would like to contribute but besides during studies, I never programmed in C/C++, any suggestion for tools or tutorials to get started? I prefer working with linux, but right now I only have the OS on a dualboot with nothing related to programming on it
10:41 < bridge_> <meloƞ> check the github readme: https://github.com/ddnet/ddnet on how to get started with the ddnet codebase, if you're unfamiliar with c++ programming in general there are hundreds of good youtube videos and blogposts related to the basics - if you're atleast familiar with those you can check other sources like ryo's blogposts: https://edgarluque.com - he has done articles for UI Code, Code conventions and an Intro to the DDNet game source code - there i
10:44 < bridge_> <nawretard> Thank you very much, I'll have a look ! (sorry if it's a question frequently asked, I should probably have searched a bit more before asking)
10:44 < bridge_> <meloƞ> no worries - glad to help you out
10:55 < bridge_> <learath2> You may be running the wrong version of it on accident? Or did we get strongarmed into upgrading from `clang-format-10`?
10:55 < bridge_> <meloƞ> im using clang-format 10.0.1 - i dont really know if that can be considered the "wrong" version
10:56 < bridge_> <learath2> Mh, then idk
11:47 < bridge_> <Ewan> this is a VS generator thing
11:48 < bridge_> <Ewan> use a good one
12:56 < bridge_> <smlsd> Tell me real
12:57 < bridge_> <Jupstar ✪> i told you real
12:57 < bridge_> <Jupstar ✪> something made from scratch means, it was completely self made
12:58 < bridge_> <Jupstar ✪> and teeworlds/ddnet really reinvents all wheels
13:21 < bridge_> <milkeeycat> that's what :gigachad:s go
13:21 < bridge_> <milkeeycat> that's what :gigachad:s do
13:28 < bridge_> <meloƞ> its not based off of anything, the development started 20 years ago (iirc)
13:32 < bridge_> <smlsd> Bro just tell me now godot or unity or gamemaker2 or something
13:38 < bridge_> <Jupstar ✪> it's made in unreal engine 5 and uses raytracing only
13:39 < bridge_> <Jupstar ✪> if you don't have a rtx 4090 the game will run like shit
13:40 < bridge_> <milkeeycat> runs fine on my nvidia mx130 :clueless:
13:42 < bridge_> <Peakies> are you talking about DDRaceNetwork(DDNet) right ?
13:42 < bridge_> <teero777> never knew raytracing was turing complete :poggers2:
13:43 < bridge_> <egyt> You've been Microsofted!
13:44 < bridge_> <egyt> You've been Microsofted! Install trisquel NOW!
13:44 < bridge_> <egyt> You've been Microsofted! Install Trisquel NOW!
13:51 < bridge_> <meloƞ> its - literally - made - from - scratch XD https://github.com/ddnet/ddnet
13:59 < bridge_> <milkeeycat> bro if you dont what to tell how it's made then just dont ping him brug
13:59 < bridge_> <milkeeycat> bro if you dont what to tell how it's made then just dont ping him bruh
14:04 < bridge_> <meloƞ> true
15:35 < bridge_> <teero777> yo how can i use the ddnet http system to do smth like this?
15:35 < bridge_> <teero777> ```
15:35 < bridge_> <teero777> curl http://localhost:5555 -d '{
15:35 < bridge_> <teero777>   "data": "hello"
15:35 < bridge_> <teero777> }'
15:43 < bridge_> <teero777> oh ok seems like it is PostJson
15:49 < bridge_> <teero777> oh ok seems like it is HttpPostJson
15:59 < bridge_> <Ewan> can also use curl easy api
16:23 < bridge_> <Tyrone> Hello, Im trying to re-create the rainbow feature on my tee wehn i enable my button. Im new to tw modding, and ive been scratching my head about this for a while today. But unfortunatley i need to go work, and still unable to figure a soultion to this. 
16:23 < bridge_> <Tyrone> 
16:24 < bridge_> <Tyrone> My idea was that when i change to my config, i can just set the color of my tee's body color to whatever i want. 
16:24 < bridge_> <Tyrone> I can set the color to a static value in the render.h file however this cant be changed once set. 
16:24 < bridge_> <Tyrone> 
16:24 < bridge_> <Tyrone> Im just wondering if anyone has any ideas on how I will be able to achompish my idea, Teero had mentioned to me using tw ticks. but he couldnt explain it in english for me lol so im still stuck. (Thanks for trying tho teero <3 )
16:24 < bridge_> <Tyrone> https://cdn.discordapp.com/attachments/293493549758939136/1233785722356629554/image.png?ex=662e5bfe&is=662d0a7e&hm=262af4c3a5621ceea029e4dbb7f9890c62f4ef5ebddedd4c2f3cbf40ed28f75d&
16:24 < bridge_> <Tyrone> This is in the render.cpp file
16:24 < bridge_> <Tyrone> Im probably just being dumb lol but ty in advance if anyone has the idea :D
16:27 < bridge_> <meloƞ> i did it like this iirc:
16:27 < bridge_> <meloƞ> 
16:27 < bridge_> <meloƞ> ```
16:27 < bridge_> <meloƞ>                 RenderInfo.m_ColorBody = color_cast<ColorRGBA>(ColorHSVA(round_to_int(LocalTime() * 20.f) % 255 / 255.f, 1.f, 1.f));
16:27 < bridge_> <meloƞ> ```
16:27 < bridge_> <meloƞ> i did it like this iirc:
16:27 < bridge_> <meloƞ> 
16:27 < bridge_> <meloƞ> ```cpp
16:27 < bridge_> <meloƞ>                 RenderInfo.m_ColorBody = color_cast<ColorRGBA>(ColorHSVA(round_to_int(LocalTime() * 20.f) % 255 / 255.f, 1.f, 1.f));
16:27 < bridge_> <meloƞ> ```
16:28 < bridge_> <Tyrone> Hmm ok thank you, I will try this. If anyone else also has any ideas would be appreciated! Always cool to hear how others do stuff
16:29 < bridge_> <meloƞ> also i placed it in the Render function of CPlayers `CPlayers::RenderPlayer`
16:29 < bridge_> <meloƞ> also i placed it in the Render function of players.cpp `CPlayers::RenderPlayer`
16:29 < bridge_> <Tyrone> Was this in your render.cpp file also? Rn my codes kinda everywhere and anywhere lol
16:29 < bridge_> <Tyrone> Oh okay awesome
16:30 < bridge_> <Tyrone> https://streamable.com/tptit3
16:30 < bridge_> <Tyrone> This is the monstrocity of a client I’m making rn lmao
16:30 < bridge_> <meloƞ> oh god :justatest:
16:31 < bridge_> <Tyrone> Just playing around with all settings
16:32 < bridge_> <meloƞ> stormax client:
16:32 < bridge_> <meloƞ> https://cdn.discordapp.com/attachments/293493549758939136/1233787769399279667/image.png?ex=662e5de6&is=662d0c66&hm=078f9dbab7d7ca8883e4d878d14e08dad4d027b50f6f5adbba47bf77ec4e52e6&
16:32 < bridge_> <meloƞ> :justatest:
16:32 < bridge_> <meloƞ> https://cdn.discordapp.com/attachments/293493549758939136/1233787903822401627/image.png?ex=662e5e06&is=662d0c86&hm=4c5e84f76a8bceb28c9c371250867c771e781188bdeb4978d613309650162823&
16:33 < bridge_> <Tyrone> What is this hahahhaa
16:33 < bridge_> <Tyrone> Looks cool
16:34 < bridge_> <meloƞ> fetching of ddnet.org/stats and ddstats.qwik.space and displaying it there :D
16:34 < bridge_> <meloƞ> fetching of ddnet.org/players and ddstats.qwik.space and displaying it there :D
16:54 < bridge_> <Tyrone> https://streamable.com/z4t0bf
16:54 < bridge_> <Tyrone> I did it before work rq :D
16:54 < bridge_> <Tyrone> https://streamable.com/z4t0bf
16:54 < bridge_> <Tyrone> ty @blaiszephyr <3
17:00 < bridge_> <meloƞ> :pikasip:
20:23 < bridge_> <milkeeycat> yo, do you think tokenizer should tokenize basic types like `i32`, `u8` or should it spit out just as in ident and it's parser's job to deal wit that? :thonk:
20:28 < bridge_> <Jupstar ✪> a proper tokenizer should parse them properly
20:28 < bridge_> <Jupstar ✪> and not as ident
20:29 < bridge_> <Jupstar ✪> at least as Type(Ident)
20:29 < bridge_> <learath2> Tokenizer tokenizes
20:29 < bridge_> <learath2> Is it perhaps a lexer we are talking about here?
20:29 < bridge_> <milkeeycat> the thing which takes raw dawg string and returns bunch of tokens :justatest:
20:30 < bridge_> <learath2> Some people make the tokenizer and lexer in one. But a tokenizer only splits the raw text into tokens with no extra context. It's a lexer that attaches context to those tokens
20:31 < bridge_> <Jupstar ✪> mh true
20:32 < bridge_> <learath2> Anyway, I'm guessing you are making a lexer. Which means you should attach more context to your tokens, so yeah i32 would usually get attached some context to indicate it's a type by a lexer
20:34 < bridge_> <Jupstar ✪> i guess even with a lexer you would not really do it
20:34 < bridge_> <Jupstar ✪> where is our playboy ryo
20:36 < bridge_> <fokkonaut> Hi, I am trying to make some optimizations in my 0.6 compatibility layer and made the following commit, but there are issues which I currently cant resolve.
20:36 < bridge_> <fokkonaut> Connecting doesn't work correctly for 0.7 clients this way for some reason 
20:36 < bridge_> <fokkonaut> https://github.com/fokkonaut/F-DDrace/commit/78d50e5b965caac9da04c6ecb6d77dc486fb2979
20:36 < bridge_> <fokkonaut> I tried to adapt to ddnet's way of unpacking twice
20:39 < bridge_> <Jupstar ✪> r u writing ur own programming language? 😄
20:40 < bridge_> <meloƞ> https://github.com/MilkeeyCat/milklang/
20:40 < bridge_> <meloƞ> https://github.com/MilkeeyCat/milklang/issues/1
20:40 < bridge_> <meloƞ> 
20:40 < bridge_> <meloƞ> nice issue btw
20:41 < bridge_> <milkeeycat> it's hard to call a programming language but im trying :justatest:
20:41 < bridge_> <Jupstar ✪> and what happened to your demo player project?
20:41 < bridge_> <milkeeycat> waiting when someone add support for quads 😏
20:41 < bridge_> <meloƞ> ask gerdoe
20:41 < bridge_> <meloƞ> :kek:
20:45 < bridge_> <Jupstar ✪> with optimizations, do you mean performance? or more like refactoring?
20:46 < bridge_> <fokkonaut> Both
20:47 < bridge_> <Jupstar ✪> if you want more performance you should focus on other code i'd say
20:51 < bridge_> <Jupstar ✪> what i spotted as biggest bottlenecks in the server yet are:
20:51 < bridge_> <Jupstar ✪> - the O(n²) physics handling of tees
20:51 < bridge_> <Jupstar ✪> - snapshot deltas
20:51 < bridge_> <Jupstar ✪> - many connections (tho you probably can only scale this one with more cores)
20:51 < bridge_> <Jupstar ✪> 
20:51 < bridge_> <Jupstar ✪> tbf i handle snapshot deltas differently to ddnet, so maybe the implementation is just bad.
20:51 < bridge_> <Jupstar ✪> 
20:51 < bridge_> <Jupstar ✪> for physics, reducing it to O(n) improved the game a lot
20:51 < bridge_> <Jupstar ✪> https://cdn.discordapp.com/attachments/293493549758939136/1227004473197727784/image.png?ex=662e1437&is=662cc2b7&hm=7fad014b670d570fd3019eb3626dd28e78d564e1c9ad8ce2f54aea7d12ddf92f&
20:51 < bridge_> <meloƞ> how high did you peak it before it breaks?
20:51 < bridge_> <meloƞ> iirc you mentioned it already but i forgot
20:53 < bridge_> <Jupstar ✪> i think the highest stable i tried was 1800. then the prediction code could not keep up and thought the network is lagging and increased prediction margin xD
20:53 < bridge_> <Jupstar ✪> 
20:53 < bridge_> <Jupstar ✪> then everything was just getting worse and worse
20:53 < bridge_> <Jupstar ✪> 
20:53 < bridge_> <Jupstar ✪> but i had 2000 connected once
20:53 < bridge_> <Jupstar ✪> just didnt work very long
20:53 < bridge_> <Jupstar ✪> and ofc i'm on a desktop pc, which is probably faster than the average VPS u buy 😄
20:54 < bridge_> <meloƞ> :D imagine hosting this on a 2€ vps
20:54 < bridge_> <meloƞ> you gonna get a hatemail followed by a picture of a burning server
20:54 < bridge_> <Jupstar ✪> but tees here are still stacking, which isn't optimal
20:54 < bridge_> <Jupstar ✪> 
20:54 < bridge_> <Jupstar ✪> on a free map it might work with 2000 tees at once
20:54 < bridge_> <Jupstar ✪> but only if i disable snapshot deltas.. that thing completely destroys performance 😄
20:54 < bridge_> <Jupstar ✪> i defs need a better method here
20:55 < bridge_> <Jupstar ✪> https://github.com/facebook/zstd/wiki/Zstandard-as-a-patching-engine
20:55 < bridge_> <Jupstar ✪> i'd be interested in that
20:55 < bridge_> <Jupstar ✪> but no rust lib
21:00 < bridge_> <Peakies> my favourite scene
21:13 < bridge_> <zhn> yeah this ccharactercore::move call is just hilarious :p, o(n) physics would break everything though
21:14 < bridge_> <Jupstar ✪> i'd say no xd
21:14 < bridge_> <Jupstar ✪> it breaks nothing
21:14 < bridge_> <Jupstar ✪> at least as i implemented it
21:14 < bridge_> <zhn> what did you implement then huh
21:15 < bridge_> <Jupstar ✪> https://github.com/Jupeyy/dd-pg/blob/d5009f76e5909be7b8e4be7bda16af1e2118c58b/game/shared-game/src/entities/character/pos.rs
21:15 < bridge_> <Jupstar ✪> i basically used a tee like a tile on a tilemap xd
21:15 < bridge_> <Jupstar ✪> and thanks to my RAII entities it automatically deregisters from playfield etc.
21:16 < bridge_> <Jupstar ✪> ah and also all relevant physics use checks by radius
21:16 < bridge_> <Jupstar ✪> that makes this a lot more easy
21:16 < bridge_> <chairn> how can you reduce it to O(n) when you can have collisions with every tees ?
21:16 < bridge_> <zhn> ^
21:17 < bridge_> <Jupstar ✪> it is O(1) in average case
21:17 < bridge_> <Jupstar ✪> in worst case it's O(n)
21:17 < bridge_> <Jupstar ✪> (per character tick)
21:17 < bridge_> <zhn> add_or_move does nothing but just gets tee and sets pos
21:17 < bridge_> <zhn> i dont see any physics related code
21:17 < bridge_> <Jupstar ✪> the average case is that tees don't stack
21:17 < bridge_> <chairn> in worst case it's O(n²)
21:17 < bridge_> <Jupstar ✪> if they don't stack i simply look at neighbours
21:17 < bridge_> <Jupstar ✪> it's easier to talk here in tick per character
21:17 < bridge_> <Jupstar ✪> than over all chars
21:18 < bridge_> <Jupstar ✪> so O(n) in worst case per char
21:18 < bridge_> <chairn> hm
21:18 < bridge_> <Jupstar ✪> if u are sourounded by 16 tees it might be smth like O(16)
21:18 < bridge_> <chairn> so O(n) per character is O(n²) for the game
21:18 < bridge_> <Jupstar ✪> which is the case in my screenshot
21:19 < bridge_> <Jupstar ✪> yeah it's n * n, where every n is character count
21:19 < bridge_> <Jupstar ✪> but it even iterates over "empty" characters
21:21 < bridge_> <zhn> and its currently O(n²) in cpp code afair
21:21 < bridge_> <Jupstar ✪> so it's basically 64*64
21:21 < bridge_> <chairn> it's always O(n²) for physics collision
21:21 < bridge_> <chairn> you can segment the game in smaller region to reduce the complexity though
21:21 < bridge_> <Jupstar ✪> and thus in average case it's not O(n²)
21:21 < bridge_> <Jupstar ✪> with that argument a hashmap is also not O(1)
21:21 < bridge_> <Jupstar ✪> bcs they also only mean the average case
21:21 < bridge_> <Jupstar ✪> https://github.com/Jupeyy/dd-pg/blob/test8/game/shared-game/src/entities/character/core.rs#L641-L642
21:21 < bridge_> <Jupstar ✪> for ddnet you might want to sort the ids, so it's 100% same physics
21:22 < bridge_> <chairn> the lookup is still n²
21:23 < bridge_> <robyt3> It seems to me like `pSevendown` is only ever set to `false` now except when it's initialized to `true`, is that intended? I would try to replace https://github.com/fokkonaut/F-DDrace/commit/78d50e5b965caac9da04c6ecb6d77dc486fb2979#diff-9f0365db9b2c308b61066eb7d11ecc9fc43c8c63b846f6cdb6632788e6d9c66cR364-R365 with `*pSevendown = !(pPacket->m_Flags & 1);` and see if works
21:23 < bridge_> <Jupstar ✪> i seriously don't understand what you mean 😄
21:25 < bridge_> <fokkonaut> sevendown means 0.6
21:25 < bridge_> <fokkonaut> And the unused flag is only used in 0.7
21:25 < bridge_> <fokkonaut> which is why sevendown is set to true intiially
21:25 < bridge_> <Jupstar ✪> on average it has to lookup 9 tiles. in worst case smth like 12 i guess
21:25 < bridge_> <Jupstar ✪> and as said i assume tees not stacking
21:25 < bridge_> <chairn> oh, you look tiles nearby
21:25 < bridge_> <chairn> in current algo, you lookup all tees and compute distance
21:26 < bridge_> <Jupstar ✪> yeah 😄
21:26 < bridge_> <robyt3> But previously you set `pSevendown` also to `true` when `GetSevendown` returned `true`, now it only gets set to `false` there
21:26 < bridge_> <fokkonaut> But now the initial value is different
21:29 < bridge_> <robyt3> So you first receive one message where it gets set to false and then everything else will use the wrong branch
21:29 < bridge_> <robyt3> `if (*pSevendown)` behave differently now I assume
21:29 < bridge_> <fokkonaut> Hm. I'm not sure
21:29 < bridge_> <robyt3> Just try the suggested change I guess
21:29 < bridge_> <fokkonaut> I think I tried it already and it didnt work. I'm not on my pc currently
21:29 < bridge_> <fokkonaut> i'll see..
21:29 < bridge_> <robyt3> Maybe you could record the connecting messages with Wireshark and then compare how it differs due to this commit
21:29 < bridge_> <Peakies> @robyt3 after 9hr working on switch screen still it's not perfect :|, am I noob or it's hard to reach perfect switch screen ?!
21:30 < bridge_> <fokkonaut> trie
21:30 < bridge_> <fokkonaut> true*
21:30 < bridge_> <robyt3> It's not exactly easy, 5 different fullscreen modes, 2 backends, 3 operating systems are a lot of combinations
21:30 < bridge_> <learath2> I think you can do n logn no? With a bsp tree
21:30 < bridge_> <chairn> @jupeyy_keks how do you handle tees speed, when a tee can cross tens of tiles in a single tick ?
21:30 < bridge_> <chairn> but you have to generate it once per tick, no?
21:31 < bridge_> <Peakies> shit I just stuck on 1 operation system called as Windows and Vulkan backend and fucking fullscreen modes 😐
21:31 < bridge_> <Jupstar ✪> only one tee is moving at once, so that's no problem
21:31 < bridge_> <chairn> well, you could always use the previous one and say a tee can only change to a neighbour node
21:32 < bridge_> <Jupstar ✪> i don't replace any "normal" logic. i simply reduce the amount of players checked against
21:32 < bridge_> <Jupstar ✪> if a tee moves, it moves in small segments
21:32 < bridge_> <Jupstar ✪> so for every segment it rechecks all tees
21:32 < bridge_> <Jupstar ✪> just like the normal physics does
21:32 < bridge_> <learath2> I think you can do even better, but too much wine in me to remember the related keywords now
21:33 < bridge_> <meloƞ> good feast!
21:33 < bridge_> <Jupstar ✪> 100%
21:33 < bridge_> <learath2> Something something temporal coherence, something locality something
21:33 < bridge_> <chairn> maybe you can refresh your mind with this:
21:33 < bridge_> <chairn> <https://en.wikipedia.org/wiki/Collision_detection>
21:34 < bridge_> <Jupstar ✪> the biggest problems with trees are, that you have to update them every tick
21:35 < bridge_> <Jupstar ✪> and updating trees not the nicest
21:35 < bridge_> <Jupstar ✪> else raytracing would run at 500 fps 😏
21:35 < bridge_> <learath2> Space hashing maybe?
21:36 < bridge_> <learath2> I can do raytracing in O(1)
21:36 < bridge_> <Jupstar ✪> you could probably also optimize the segment moving
21:36 < bridge_> <chairn> space partitioning ?
21:37 < bridge_> <learath2> I build a replica of the scene irl, add lights, then take a picture
21:37 < bridge_> <Jupstar ✪> most raytracing impls cache older rays. which is why sometimes moving from very dark to very light actually looks quite bad
21:37 < bridge_> <learath2> It takes about 2 weeks consistently
21:37 < bridge_> <peter0x44> just let the rays trace themselves
21:37 < bridge_> <peter0x44> good strategy
21:38 < bridge_> <Jupstar ✪> the sun is also just a GPU starting many threads for many rays
21:38 < bridge_> <Jupstar ✪> 😏
21:38 < bridge_> <learath2> Yeah I guess I'm thinking space partitioning, but in an O(1) manner rather than keeping an up to date tree
21:38 < bridge_> <chairn> isn't ray tracing going the other way ? like from the camera to the light source
21:39 < bridge_> <learath2> Depends. There are algorithms that go either way. Though all the performant ones indeed start from the camera
21:39 < bridge_> <Jupstar ✪> that is the hardest to answer question.
21:39 < bridge_> <Jupstar ✪> 
21:39 < bridge_> <Jupstar ✪> but modern implementations do i think
21:39 < bridge_> <Jupstar ✪> but the other way around can also be better in some cases
21:40 < bridge_> <learath2> There are algorithms that launch rays from light sources then use complicated things far beyond my understanding to cull rays that wont ever reach the camera
21:40 < bridge_> <learath2> They still take hours to converge on complex scenes though iirc
21:41 < bridge_> <chairn> i don't think there is an O(1) algorithm for this
21:41 < bridge_> <Jupstar ✪> https://www.scratchapixel.com/index.html
21:42 < bridge_> <Jupstar ✪> https://www.scratchapixel.com/lessons/mathematics-physics-for-computer-graphics/monte-carlo-methods-mathematical-foundations/quick-introduction-to-monte-carlo-methods.html
21:42 < bridge_> <chairn> > 1987 Thibault and Naylor[3] described how arbitrary polyhedra may be represented using a BSP tree as opposed to the traditional b-rep (boundary representation). This provided a solid representation vs. a surface based-representation. Set operations on polyhedra were described using a tool, enabling constructive solid geometry (CSG) in real-time. This was the forerunner of BSP level design using "brushes", introduced in the Quake editor and picked
21:42 < bridge_> <chairn> > 1990 Naylor, Amanatides, and Thibault provided an algorithm for merging two BSP trees to form a new BSP tree from the two original trees. This provides many benefits including combining moving objects represented by BSP trees with a static environment (also represented by a BSP tree), very efficient CSG operations on polyhedra, exact collisions detection in O(log n * log n), and proper ordering of transparent surfaces contained in two interpenetr
21:43 < bridge_> <chairn> > 1990 Teller and Séquin proposed the offline generation of potentially visible sets to accelerate visible surface determination in orthogonal 2D environments.
21:43 < bridge_> <chairn> > 1991 Gordon and Chen [CHEN91] described an efficient method of performing front-to-back rendering from a BSP tree, rather than the traditional back-to-front approach. They utilized a special data structure to record, efficiently, parts of the screen that have been drawn, and those yet to be rendered. This algorithm, together with the description of BSP Trees in the standard computer graphics textbook of the day (Computer Graphics: Principles and 
21:43 < bridge_> <chairn> > 1992 Teller's Ph.D. thesis described the efficient generation of potentially visible sets as a pre-processing step to accelerate real-time visible surface determination in arbitrary 3D polygonal environments. This was used in Quake and contributed significantly to that game's performance
21:43 < bridge_> <Jupstar ✪> sad that i am too lazy to wanting to fully understand it
21:43 < bridge_> <chairn> https://en.wikipedia.org/wiki/Binary_space_partitioning
21:43 < bridge_> <Jupstar ✪> it's actually really peak stochastics
21:43 < bridge_> <Jupstar ✪> xd
21:44 < bridge_> <learath2> O(1) algorithm to find which chunk you are in is trivial if the chunks are same size. Finding a chunks neighbours are also O(1) in such a case. Then it's a matter of checking for collisions within the chunk, which is I guess O(n^2) in the worst case that everyone is in one chunk, but you should be able to tune chunk size to make sure that only happens for cases where n is small enough that it doesnt matter
21:44 < bridge_> <chairn> what's the relation with collision detection or space partitioning ?
21:45 < bridge_> <chairn> i guess you could try random position for 10^6 and say, i got not collision after this many tries, but kinda inefficient 😄
21:45 < bridge_> <Jupstar ✪> space partioning is simply to reduce the amount of "possible" checks
21:45 < bridge_> <Jupstar ✪> or what do you want to hear
21:46 < bridge_> <chairn> i don't see the relation between monte carlo and what we were discussing
21:46 < bridge_> <Jupstar ✪> we were talking about if cameras shoot rays vs light sources
21:47 < bridge_> <Jupstar ✪> btw afaik the ray tracers in GPU expect you to build a BVH
21:47 < bridge_> <Jupstar ✪> https://en.wikipedia.org/wiki/Bounding_volume_hierarchy
21:49 < bridge_> <Jupstar ✪> https://www.scratchapixel.com/images/monte-carlo-methods/mcintegration06.png?
21:50 < bridge_> <Jupstar ✪> stochastic is kinda very useful math. but also the kind of math i never like learning
21:50 < bridge_> <Jupstar ✪> bcs there are 1 trillion approaches that only differ by small things xD
21:51 < bridge_> <chairn> but BVH is not stochastic either
21:51 < bridge_> <chairn> neither is ray tracinf afaik
21:51 < bridge_> <chairn> neither is ray tracing afaik
21:51 < bridge_> <Jupstar ✪> u wanted me to to talk about space partioning. bvh is kinda a special case
21:51 < bridge_> <Jupstar ✪> ray tracing is a LOT of stochastics
21:52 < bridge_> <Jupstar ✪> u shoot rays in random directions and want an approximation of light influence
21:53 < bridge_> <Jupstar ✪> ok tbf it always depends on the algorithms used
21:54 < bridge_> <Jupstar ✪> i dunno how much companies like disney approximate vs actually just execute rays to get best results
22:06 < bridge_> <learath2> https://youtu.be/gsZiJeaMO48 this convo reminded me of this video. Pretty nice content
22:19 < bridge_> <Jupstar ✪> really good video. just music is annoying 😄
22:21 < bridge_> <learath2> YES, so annoying
22:31 < bridge_> <reitw> Saw this video prob a year ago or months, this is so well explained
22:31 < bridge_> <reitw> Music wasn't that bothering for me
22:32 < bridge_> <chairn> it's too mathematical for a video imo
22:35 < bridge_> <learath2> I'm a little biased since I love math visualized kinda videos
23:22 < bridge_> <Jupstar ✪> i am always surprised how few (reasonably small) heap allocations have an effect on performance.
23:22 < bridge_> <Jupstar ✪> 
23:22 < bridge_> <Jupstar ✪> tried to optimize bsdiff by removing the heap allocations, made 0 difference 😂 
23:22 < bridge_> <Jupstar ✪> 
23:22 < bridge_> <Jupstar ✪> so 600 players seems to be the limit then for now :c
23:22 < bridge_> <Jupstar ✪> and that defs won't scale with more connections without using more cores.
23:22 < bridge_> <Jupstar ✪> underwhelming
23:24 < bridge_> <Jupstar ✪> i am always surprised how (reasonably small) heap allocations have only a low/non-existing effect on performance.
23:24 < bridge_> <Jupstar ✪> 
23:24 < bridge_> <Jupstar ✪> tried to optimize bsdiff by removing the heap allocations, made 0 difference 😂 
23:24 < bridge_> <Jupstar ✪> 
23:24 < bridge_> <Jupstar ✪> so 600 players seems to be the limit then for now :c
23:24 < bridge_> <Jupstar ✪> and that defs won't scale with more connections without using more cores.
23:24 < bridge_> <Jupstar ✪> underwhelming