00:03 < bridge> <animepdf> How do I translate rgba to tw color (prefferably with 1 method that's already in code), I'm going insane with all these colors already
00:05 < bridge> <totar> do you mean rbg to config color?
00:05 < bridge> <animepdf> yeah
00:05 < bridge> <totar> the TW colors don't have the full rgb color range so it's not directly possible
00:07 < bridge> <totar> let me find the code that does the transformation
00:07 < bridge> <animepdf> would be much appreciated
00:07 < Voxel> I wish it was a bit more mainstream, since there's still the issue of it de-syncing
00:07 < Voxel> https://github.com/ddnet/ddnet/issues/5844
00:08 < bridge> <animepdf> I could find that tw color is bits representation of hsl(or smth like that), i think it will be fine for me to use hsl instead, if it has direct translation
00:08 < bridge> <jxsl13> where is the voxel emote
00:09 < Voxel> Define the Voxel Emote
00:09 < bridge> <jxsl13> *insert cube*
00:09 < Voxel> :eye:
00:09 < bridge> <jxsl13> just a cube
00:09 < bridge> <animepdf> :sillybastard:
00:09 < bridge> <jxsl13> probably
00:09 < bridge> <jxsl13> 🧊
00:09 < Voxel> Ice Cube!
00:09 < bridge> <jxsl13> here it is
00:09 < bridge> <jxsl13> and good night \:D
00:21 < bridge> <totar> @animepdf first you convert your RGB color to HSL
00:21 < bridge> <totar> <https://github.com/ddnet/ddnet/blob/f74027666a8a795f9b346fdbb4ea9ed8d5850bc0/src/base/color.h#L219C11-L231>
00:21 < bridge> <totar> 
00:21 < bridge> <totar> Then "UnclampLighting" with a value of 0.5f
00:21 < bridge> <totar> <https://github.com/ddnet/ddnet/blob/f74027666a8a795f9b346fdbb4ea9ed8d5850bc0/src/base/color.h#L181-L186>
00:21 < bridge> <totar> 
00:21 < bridge> <totar> Then pack the value
00:21 < bridge> <totar> <https://github.com/ddnet/ddnet/blob/f74027666a8a795f9b346fdbb4ea9ed8d5850bc0/src/base/color.h#L114-L117>
00:25 < bridge> <animepdf> Thanks!
03:10 < Voxel> It sucks being American because like, most of the devs here are asleep
03:10 < Voxel> I had a cool idea I wanted to tell Jupstar, but I doubt he's awake
06:29 < bridge> <teero777> Hello I had a nightmare and just woke up
06:29 < bridge> <teero777> What's the idea?
08:15 < bridge> <Jupstar ✪> I can also read it afterwards
11:41 < bridge> <ryozuki> https://loco.rs/
11:41 < bridge> <ryozuki> im using this and its dope
11:41 < bridge> <ryozuki> its the most dev friend you have in rust for web related
12:28 < zhn> hey guys, quick question: are dekos streamable?
12:28 < zhn> demos*
12:29 < bridge> <Jupstar ✪> streamable?
12:30 < zhn> yeah, is there any method to stream demos?
12:30 < bridge> <Jupstar ✪> ? XD
12:30 < bridge> <Jupstar ✪> Stream in what sense
12:30 < bridge> <jxsl13> live stream
12:30 < zhn> not like a binary file, but a demo that can be played in realtime 
12:30 < zhn> yeah
12:31 < bridge> <Jupstar ✪> Without video conversion?
12:31 < zhn> ah wait, its just client
12:31 < zhn> xddddd
12:31 < bridge> <Jupstar ✪> I mean a demo is kinda just snapshots
12:31 < zhn> yeye xd
12:31 < bridge> <Jupstar ✪> So you can stream a demo ig
12:32 < zhn> yeah then i need a web client kekeke
12:32 < zhn> afair there was one
12:34 < bridge> <Jupstar ✪> https://ddnet.github.io/load_map.html
12:34 < bridge> <Jupstar ✪> But it's quite a bit outdated already
12:55 < bridge> <teero777> @jupeyy_keks where is the collision data for rendering entities loaded in the vulkan backend?
12:57 < bridge> <Jupstar ✪> maplayers.cpp
12:57 < bridge> <Jupstar ✪> But it doesn't use collision data like you think
12:58 < bridge> <Jupstar ✪> It just loads the physics group layers from the map directly and puts them into a buffer. They don't use some collision class
15:00 < bridge> <teero777> the collision class just has pointers to the same physics layers so maybe it'll work
15:01 < bridge> <Jupstar ✪> What you try to do still needs a reupload of the layer
15:01 < bridge> <Jupstar ✪> You cannot change memory on the CPU and hope that it gets updated on GPU
15:01 < bridge> <teero777> exactly what i am doing
15:01 < bridge> <Jupstar ✪> Nice
15:02 < bridge> <teero777> *or trying to do
15:02 < bridge> <Jupstar ✪> Updating the whole layer might be slow tho xd
15:02 < bridge> <Jupstar ✪> You should not expect it to outperform OGL 1.1
15:02 < bridge> <teero777> well it only gets done once so it is fine
15:02 < bridge> <teero777> it should be just like loading the map again
15:02 < bridge> <Jupstar ✪> Ah
15:02 < bridge> <Jupstar ✪> Perfect
15:05 < bridge> <teero777> it worked :DDD
15:05 < bridge> <Jupstar ✪> @teero777 btw one question. Do you need vk for zooming or other reasons?
15:05 < bridge> <teero777> vk just looks better xd
15:06 < bridge> <teero777> i don't want to render on opengl 1.4
15:06 < bridge> <Jupstar ✪> Ok bcs there is another way if you just want to fix rendering
15:06 < bridge> <Jupstar ✪> find
15:06 < bridge> <Jupstar ✪> `m_GLTileBufferingEnabled = m_pBackend->HasTileBuffering();`
15:06 < bridge> <Jupstar ✪> and replace it with
15:06 < bridge> <Jupstar ✪> `m_GLTileBufferingEnabled = false; //m_pBackend->HasTileBuffering();`
15:06 < bridge> <Jupstar ✪> Then you have OGL 1.1 rendering with vulkan
15:06 < bridge> <Jupstar ✪> xd
15:06 < bridge> <Jupstar ✪> But without the rendering issues
15:07 < bridge> <Jupstar ✪> That is also what is used in the editor
15:07 < bridge> <learath2> Maybe you can't
15:07 < bridge> <Jupstar ✪> I mean you can allocate coherent memory that is visible to both, CPU & GPU and it will probs work
15:08 < bridge> <Jupstar ✪> But usually it's rather slow. I tried that before I instead flushed the memory properly
15:09 < bridge> <learath2> How is this facilitated btw?
15:12 < bridge> <Jupstar ✪> I wonder about that too. Vulkan is about giving away control from driver to programmer and then they add such stuff that sounds rather difficult BUS wise and cache wise and what do I know how hardware works in detail.
15:12 < bridge> <Jupstar ✪> 
15:12 < bridge> <Jupstar ✪> But it seems GPU vendors implement coherent memory.
15:12 < bridge> <Jupstar ✪> In theory they don't have to.
15:12 < bridge> <Jupstar ✪> 
15:12 < bridge> <Jupstar ✪> Also for integrated GPUs it's ofc easy, since CPU & GPU share the memory anyway
15:13 < bridge> <learath2> Yeah I was about to ask whether it's igpu/combined memory systems only
15:13 < bridge> <learath2> I wonder if there is some flag one can check to see if coherent memory is fast/cheap on this device
15:13 < bridge> <Jupstar ✪> Yes
15:14 < bridge> <Jupstar ✪> If coherent memory is device local and host local
15:14 < bridge> <Jupstar ✪> Then you know it's iGPU
15:14 < bridge> <Jupstar ✪> But then you also don't need coherent memory, because it's 99% also HOST_CACHED
15:14 < bridge> <Jupstar ✪> xd
15:14 < bridge> <Jupstar ✪> Well dunno if there are exceptions
15:16 < bridge> <Jupstar ✪> Ok there is no HOST_LOCAL. HOST_CACHED is kinda what I mean instead
15:16 < bridge> <Jupstar ✪> Then it makes sense
15:16 < bridge> <Jupstar ✪> ```
15:16 < bridge> <Jupstar ✪> DEVICE_LOCAL_BIT
15:16 < bridge> <Jupstar ✪> HOST_VISIBLE_BIT
15:16 < bridge> <Jupstar ✪> HOST_COHERENT_BIT
15:16 < bridge> <Jupstar ✪> HOST_CACHED_BIT
15:16 < bridge> <Jupstar ✪> ```
15:16 < bridge> <Jupstar ✪> https://vulkan.gpuinfo.org/listdevicescoverage.php?memorytype=15&platform=all
15:16 < bridge> <Jupstar ✪> Most say qualcomm
15:16 < bridge> <Jupstar ✪> So it's clear that isn't about dedicated GPUs
15:17 < bridge> <Jupstar ✪> Qualcomm, Apple M1-3, Intel, AMD APU. But only like 4 nvidia
15:28 < bridge> <ryozuki> why would a linker not link a symbol
15:36 < bridge> <chairn> because symbol doesn't exist ?
15:41 < bridge> <ryozuki> today ld --whole-archive saved me
15:42 < bridge> <ryozuki> if i make a shared library that links a static library which has a method i want to make available in the shared libary it may not be included always
15:42 < bridge> <ryozuki> with --whole-archive i fixed it
15:43 < bridge> <ryozuki> i think i fixed it
15:43 < bridge> <ryozuki> :justatest:
15:43 < bridge> <chairn> hmm, probably because the symbol pulls other symbols
15:43 < bridge> <chairn> hence --whole-archive makes sure that all symbols required are included
15:54 < bridge> <ryozuki> https://jonathanbuys.com/Gross_Apple_Marketing/
15:54 < bridge> <ryozuki> https://www.youtube.com/watch?v=q5yM4ZYwB_s
15:54 < bridge> <ryozuki> a good linux marketing video kek
16:21 < bridge> <ryozuki> the nm tool is nice
16:53 < bridge> <louis> lol this guy is just a glazer
18:58 < bridge> <zhn> anyone knows good way to passthrough igpu with qemu+kvm?
18:58 < bridge> <zhn> not a mao, but an actual gameplay :owo:
18:59 < bridge> <zhn> mao
18:59 < bridge> <zhn> map, i mean
19:02 < bridge> <Jupstar ✪> It has a demo player
19:02 < bridge> <Jupstar ✪> What else do you need? 😄
19:03 < bridge> <zhn> source >:D
19:03 < bridge> <Jupstar ✪> https://github.com/Jupeyy/ddnet/tree/web_preview
19:03 < bridge> <Jupstar ✪> well it's super outdated
19:03 < bridge> <Jupstar ✪> and building for emscripten is around as hard as android xd
19:04 < bridge> <Jupstar ✪> good luck
19:04 < bridge> <Jupstar ✪> building the libs*
19:04 < bridge> <zhn> uh oh, i will try anyway
19:04 < bridge> <zhn> not in the near future though xd
20:47 < bridge> <meloƞ> damn nix i'm sorry!
20:47 < bridge> <meloƞ> https://cdn.discordapp.com/attachments/293493549758939136/1301271224336384072/image.png?ex=6723dec4&is=67228d44&hm=a04dff2a9d5de0020d325274ec6c8abbd81e450acbba3cc27b417f9e288f3455&
20:49 < bridge> <milkeeycat> Rust pros, do you know a crate which has a macro to implement a `Display` trait for enum variants, for example:
20:49 < bridge> <milkeeycat> ```rust
20:49 < bridge> <milkeeycat> enum Foo {
20:49 < bridge> <milkeeycat>   #[fmt("Dat's bar")]
20:49 < bridge> <milkeeycat>   Bar,
20:49 < bridge> <milkeeycat>   #[fmt("Dat's baz")]
20:49 < bridge> <milkeeycat>   Baz
20:49 < bridge> <milkeeycat> }
20:49 < bridge> <milkeeycat> ```
20:53 < bridge> <ryozuki> https://lib.rs/crates/derive_more
20:55 < bridge> <milkeeycat> thanks 😄
21:20 < Voxel> First step on splitting everything apart: Splitting only the emoticons image and trying to find out how to properly load it
21:20 < Voxel> Seems very hard because the code feels extremely dependant on having it be sprites instead of just images
21:20 < Voxel> I could just load in all the images as 1x1 sprites
21:21 < bridge> <Jupstar ✪> The client already splits all images internally
21:21 < bridge> <Jupstar ✪> It doesn't use an texture atlas for rendering
21:22 < Voxel> I'm just trying to disect src/game/client/gameclient.cpp, and the CGameClient::LoadEmoticonsSkin function, since that's how the emoticons are actually loaded in
21:22 < bridge> <Jupstar ✪> Yeah
21:24 < Voxel> Don't know if I was supposed to do this, but I stored everything related in content.py as an image and not a sprite
21:24 < Voxel> `container.images.Add(Image("oop", "images/emoticons/oop.png"))`
21:25 < bridge> <Jupstar ✪> `Something is VERY wrong with the Game layer near (910, 24). Please report this at https://github.com/ddnet/ddnet/issues, you will need to post the map as well and any steps that you think may have led to this.`
21:25 < bridge> <Jupstar ✪> 
21:25 < bridge> <Jupstar ✪> lmao never seen that
21:26 < bridge> <Jupstar ✪> Oh wow that doesn't even exist anymore in newer ddnet code
21:26 < bridge> <robyt3> ye
21:27 < bridge> <robyt3> it wasn't really very wrong I think, it only means an some specific entity is near the border of the map
21:28 < Voxel> I don't know why I'm trying to do this update when Jupstar already did it and better LOL
21:29 < bridge> <Jupstar ✪> Maybe it's time to get away from content.py if you want to split it anyway ^^
21:29 < Voxel> I mean, I'd have to figure out how to like, load everything manually
21:31 < bridge> <robyt3> Probably makes sense to not use `content.py` anymore. Would also make more sense if the emoticon textures were managed in `CEmoticon` instead
21:33 < Voxel> Right. I feel like all textures would have to be inside gameclient.h somehow, then.
21:34 < Voxel> Or, nevermind. This is a huge rabbit hole LOL
21:38 < bridge> <tsfreddie> good night everyone
21:39 < Voxel> Good night!
21:40 < bridge> <meloƞ> Good night!
21:40 < bridge> <meloƞ> and welcome back Voxel!
22:00 < Voxel> I'm just here for devloupment help, that's all!
22:00 < Voxel> Since I finally have the guts to try to do an actual update for this game
22:01 < bridge> <meloƞ> :3
22:04 < Voxel> So would something like this work? I have all the textures stored in an OnInit() run in emoticon.cpp https://imgur.com/gWe3UHc
22:04 < Voxel> The whole code is still messy, since I have to remove dependancy of the original emoticons image
22:07 < bridge> <robyt3> You'll need to be careful not to free the same texture handle twice or forget freeing one if you copy the handles. Doesn't look like many uses of `m_EmoticonsSkin` though
22:08 < Voxel> That's going to be a challenge for me, since I still have extremely basic knowledge on memory management
22:09 < Voxel> But I'll try. And when that works out I'll send it to GitHub and have you guys have a closer look, before I even think about sending it as a PR Draft
22:41 < Voxel> https://imgur.com/ESzjYzK Is this even right? It's still all showing up as white squares. This is inside emoticon.cpp
22:42 < bridge> <Jupstar ✪> No errors in F1?
22:46 < Voxel> 2024-10-30 17:45:06 E png: failed to open file for reading. filename='images/emoticons.png' (only shows when it i open Settings>Assets, which shows a 4 colored box. It's all just white squares in_game)
22:46 < Voxel> So It's definitely loading SOMETHING, just not the thing I want.
22:49 < bridge> <robyt3> Maybe you copy the handles in gameclient before you load them in `CEmoticon::OnInit`
22:49 < bridge> <robyt3> So you only copied an unloaded handle
22:50 < bridge> <robyt3> The preview in the Assets settings are separate anyway, those will probably also need to be revised
22:50 < bridge> <robyt3> The previews in the Assets settings are separate anyway, those will probably also need to be revised
22:50 < Voxel> Yeah, I know that. Though, I do have ideas for that side of things.
22:51 < bridge> <robyt3> Either we provide a preview `icon.png` in every zip file or we somehow show a collage of all the individual images
22:51 < Voxel> I was thinking an icon.png
22:51 < bridge> <robyt3> Definitely simpler, yeah
22:55 < Voxel> So you're saying add something into CGameClient::OnInit() about the texture handles in CEmoticon?
22:57 < bridge> <robyt3> No, I meant your error is probably that you copy the texture handles before they are loaded. That would be fixed if you remove the emoticon handles from the gameclient and only refer to `CEmoticon` as the source of truth.
22:58 < Voxel> I see
22:59 < bridge> <robyt3> I'd add a getter function, e.g. `CTextureHandle CEmoticon::EmoticonTexture(int Emoticon) const`, for that
22:59 < bridge> <robyt3> I'd add a getter function, e.g. `IGraphics::CTextureHandle CEmoticon::EmoticonTexture(int Emoticon) const`, for that
23:13 < bridge> <Jupstar ✪> Voxel now that you are here:
23:13 < bridge> <Jupstar ✪> That is also smth I want. More customization shared between all clients.
23:13 < bridge> <Jupstar ✪> https://cdn.discordapp.com/attachments/293493549758939136/1301308121565888572/image.png?ex=67240121&is=6722afa1&hm=07bf28a83146b5b29a6c914aabffe7812b15470c6294356a5aa95c77f8b156e4&
23:19 < bridge> <cellegenrih> @.insanity_ don't forget to message Deen about uploading the halloween logo and banner to github, so it's not lost 😄
23:19 < bridge> <cellegenrih> Sounds like a lot of asset downloading or configurations to handle
23:21 < Voxel> @juppey_keks YES
23:22 < Voxel> this is half the reason why i want to split it, so its easier to send through servers
23:22 < Voxel> like, you can send weapon skins and not have to worry about, yknow, the everything else
23:22 < bridge> <cellegenrih> definitely would save a lot of internet traffic
23:29 < bridge> <headshotnoby> voxuis
23:31 < Voxel> Headbot
23:37 < bridge> <teero777> Head3DS
23:49 < bridge> <cyberfrighter> yeah
23:50 < bridge> <cyberfrighter> i want that too
23:58 < bridge> <Jupstar ✪> Once an asset is downloaded it, it is load from disk the next time.
23:58 < bridge> <Jupstar ✪> Considering our current skin system downloads skins the whole time I think this should be fine xd
23:58 < bridge> <Jupstar ✪> 
23:58 < bridge> <Jupstar ✪> Ig it also depends on how big a possible database for assets would be 😄
23:58 < bridge> <heinrich5991> > Considering our current skin system downloads skins the whole time I think this should be fine xd
23:58 < bridge> <heinrich5991> @robyt3 fixed that 🙂
23:59 < bridge> <Jupstar ✪> I dunno if that makes it easier xd
23:59 < bridge> <heinrich5991> it's now only doing a `If-Modified-Since` request which returns no data if the thing didn't change
23:59 < bridge> <Jupstar ✪> But ig it still needs to do a http request, even if cheap?