04:50 <+bridge> [ddnet] Jupstar ✪: @Learath2 @Ryozuki my take in rust: 04:50 <+bridge> [ddnet] ```rs 04:50 <+bridge> [ddnet] use std::mem; 04:50 <+bridge> [ddnet] use std::sync::Mutex; 04:50 <+bridge> [ddnet] use std::sync::atomic::AtomicI32; 04:50 <+bridge> [ddnet] use std::sync::atomic::Ordering; 04:50 <+bridge> [ddnet] 04:50 <+bridge> [ddnet] fn main() { 04:50 <+bridge> [ddnet] let protect_me = AtomicI32::new(0); 04:50 <+bridge> [ddnet] let m = Mutex::new(()); 04:50 <+bridge> [ddnet] crossbeam::scope(|s| { 04:50 <+bridge> [ddnet] let t = s.spawn(|_| { 04:50 <+bridge> [ddnet] let mut break_loop = false; 04:50 <+bridge> [ddnet] while !break_loop { 04:50 <+bridge> [ddnet] let guard = m.lock().unwrap(); 04:50 <+bridge> [ddnet] println!("test {}", protect_me.load(Ordering::Relaxed)); 04:50 <+bridge> [ddnet] if protect_me.load(Ordering::Relaxed) >= 1000 { 04:50 <+bridge> [ddnet] break_loop = true; 04:50 <+bridge> [ddnet] } 04:50 <+bridge> [ddnet] mem::drop(guard); // optional 04:50 <+bridge> [ddnet] } 04:50 <+bridge> [ddnet] }); 04:50 <+bridge> [ddnet] while protect_me.load(Ordering::Relaxed) < 1000 { 04:50 <+bridge> [ddnet] let guard = m.lock().unwrap(); 04:50 <+bridge> [ddnet] protect_me.store(protect_me.load(Ordering::Relaxed) + 1, Ordering::Relaxed); 04:50 <+bridge> [ddnet] mem::drop(guard); // optional 04:51 <+bridge> [ddnet] } 04:51 <+bridge> [ddnet] t.join().unwrap(); // optional 04:51 <+bridge> [ddnet] }).unwrap(); 04:51 <+bridge> [ddnet] } 04:51 <+bridge> [ddnet] ``` 04:51 <+bridge> [ddnet] needs `crossbeam = "0.8.1"` in Cargo.toml 04:51 <+bridge> [ddnet] note that relaxed atomics use *exactly* the same instructions for loading/storing as normal variables on all platforms that I know of: https://www.cl.cam.ac.uk/~pes20/cpp/cpp0xmappings.html 04:52 <+bridge> [ddnet] Don't know if known already, but for some reason when enabling super on LAN, the server closes / crashes 04:53 <+bridge> [ddnet] doesn't look known 04:53 <+bridge> [ddnet] care to submit a bug report? 04:54 <+bridge> [ddnet] I don't use github, I should probably learn to 04:55 <+bridge> [ddnet] I can walk you through creating an account, but that's probably not very hard if you've ever created an account somewhere 04:55 <+bridge> [ddnet] afterwards you go here: https://github.com/ddnet/ddnet/issues 04:55 <+bridge> [ddnet] (usually you'd use the search bar there to check whether your issue has already been reported, but in this case I already did it for you) 04:56 <+bridge> [ddnet] then you click "New issue" and enter a title and a description, then click "Submit new issue" 04:57 <+bridge> [ddnet] Hopefully that's fine 04:57 <+bridge> [ddnet] perfect 04:58 <+bridge> [ddnet] Thanks for the walkthrough :happy: 05:08 <+bridge> [ddnet] @Skeith I couldn't reproduce the issue, can you tell me what version of the DDNet server you use and on which operating system the server runs? 05:08 <+bridge> [ddnet] https://github.com/ddnet/ddnet/issues/4265 05:09 <+bridge> [ddnet] Windows 10 05:09 <+bridge> [ddnet] https://cdn.discordapp.com/attachments/293493549758939136/903480667558522890/unknown.png 05:10 <+bridge> [ddnet] I could update my ddnet client and see if that fixes the issue 05:11 <+bridge> [ddnet] Probably should've done that from the start, forgot to check if I was updated 05:13 <+bridge> [ddnet] the ddnet server shouldn't crash no matter which ddnet client version connects 05:14 <+bridge> [ddnet] ah, but the server is updated with the client (because it's from steam?) 05:14 <+bridge> [ddnet] Yea, I have it via steam nightly 05:15 <+bridge> [ddnet] @heinrich5991 Should I update and see if it fixes itself? 05:15 <+bridge> [ddnet] if there's no inconvenience, yes 05:15 <+bridge> [ddnet] if that's not inconvenient for you, yes 05:17 <+bridge> [ddnet] Yep, doesn't crash me anymore 05:18 <+bridge> [ddnet] My bad, I'll remember to update first before reporting. 😅 05:18 <+bridge> [ddnet] nice, you can comment that it doesn't crash anymore on latest nightly and close the issue 🙂 05:18 <+bridge> [ddnet] and you already have an account for the next time you find a bug ^^ 05:25 <+bridge> [ddnet] good night 05:26 <+bridge> [ddnet] Good night :happy: 07:15 <+bridge> [ddnet] I was wondering if you could avoid the atomic since that was one of jupeyy's requirements 07:16 <+bridge> [ddnet] @heinrich5991 if you have a couple minutes can you take a look at this weird crash where we seem to be ticking on a zero'd out ccharacter instance (maybe zero'd due to static initialization) 08:26 <+bridge> [ddnet] have you ever heard of that bug, on one map with the latest ddnet some quads doesn't seem to work properly (iF|City, vanilla based mod). The left light quad on the other room seems to work properly, but not the room on the right 08:26 <+bridge> [ddnet] https://cdn.discordapp.com/attachments/293493549758939136/903530114841739284/unknown.png 08:26 <+bridge> [ddnet] Someone told me to disable mordern opengl as a fix 08:28 <+bridge> [ddnet] they're just different as if it was another client 08:29 <+bridge> [ddnet] they're just different looking, if you go check how it looks like with another client 09:04 <+bridge> [ddnet] Is the quad animated ? 09:53 <+bridge> [ddnet] https://github.blog/changelog/2021-10-27-pull-request-merge-queue-limited-beta/ 09:54 <+bridge> [ddnet] github making its own bors feature 10:11 <+bridge> [ddnet] Yaaay 10:12 <+bridge> [ddnet] Bors keeps ignoring fokkonauts prs 10:12 <+bridge> [ddnet] cuz if city sux😳 10:12 <+bridge> [ddnet] No u 10:12 <+bridge> [ddnet] Yea 10:45 <+bridge> [ddnet] @deen I have an idea depending on how often we get this crash 10:54 <+bridge> [ddnet] Often enough? 10:54 <+bridge> [ddnet] I mean can I hope to get one in a day? 10:55 <+bridge> [ddnet] I want to try what jupeyy suggested. I'll just allocate the character objects dynamically so we just get an asan use-after-free 10:55 <+bridge> [ddnet] yes 10:55 <+bridge> [ddnet] If you deploy it on all servers and run it for a day you'll get ~10 crashes 12:22 <+bridge> [ddnet] I once had a bug where a quad looked normal ingame, but in the editor it was a black square. Probably not divisible by 4 12:27 <+bridge> [ddnet] maybe because my branch doesnt exist anymore 12:38 <+bridge> [ddnet] @Learath2 in this case, the same code is generated for atomics and normal variables (see the link, relaxed atomics are the same). for more complex data structures, I agree, it'd no longer be possible to use atomics. then you'd probably create a safe abstraction out of your weird mutex usage: 12:39 <+bridge> [ddnet] ```rs 12:39 <+bridge> [ddnet] use std::cell::UnsafeCell; 12:39 <+bridge> [ddnet] use std::mem; 12:39 <+bridge> [ddnet] use std::ops; 12:39 <+bridge> [ddnet] use std::sync; 12:39 <+bridge> [ddnet] 12:39 <+bridge> [ddnet] pub struct WeirdMutex { 12:39 <+bridge> [ddnet] mutex: sync::Mutex<()>, 12:39 <+bridge> [ddnet] data: UnsafeCell, 12:39 <+bridge> [ddnet] } 12:39 <+bridge> [ddnet] 12:39 <+bridge> [ddnet] pub struct WeirdMutexGuard<'a, T> { 12:39 <+bridge> [ddnet] _guard: sync::MutexGuard<'a, ()>, 12:39 <+bridge> [ddnet] data: &'a mut T, 12:39 <+bridge> [ddnet] } 12:39 <+bridge> [ddnet] 12:39 <+bridge> [ddnet] pub struct WeirdMutexRo<'a, T> { 12:39 <+bridge> [ddnet] inner: &'a WeirdMutex, 12:39 <+bridge> [ddnet] } 12:39 <+bridge> [ddnet] 12:39 <+bridge> [ddnet] pub struct WeirdMutexRoGuard<'a, T> { 12:39 <+bridge> [ddnet] _guard: sync::MutexGuard<'a, ()>, 12:39 <+bridge> [ddnet] data: &'a T, 12:39 <+bridge> [ddnet] } 12:39 <+bridge> [ddnet] 12:39 <+bridge> [ddnet] unsafe impl<'a, T> Send for WeirdMutexRo<'a, T> {} 12:39 <+bridge> [ddnet] unsafe impl<'a, T> Sync for WeirdMutexRo<'a, T> {} 12:39 <+bridge> [ddnet] 12:39 <+bridge> [ddnet] impl ops::Deref for WeirdMutex { 12:39 <+bridge> [ddnet] type Target = T; 12:39 <+bridge> [ddnet] fn deref(&self) -> &T { 12:39 <+bridge> [ddnet] ```rs 12:39 <+bridge> [ddnet] fn main() { 12:40 <+bridge> [ddnet] let protect_me = WeirdMutex::new(0); 12:40 <+bridge> [ddnet] crossbeam::scope(|s| { 12:40 <+bridge> [ddnet] let ro = protect_me.ro(); 12:40 <+bridge> [ddnet] let t = s.spawn(move |_| { 12:40 <+bridge> [ddnet] let mut break_loop = false; 12:40 <+bridge> [ddnet] while !break_loop { 12:40 <+bridge> [ddnet] let guard = ro.lock(); 12:41 <+bridge> [ddnet] also Jupstar ✪: @Ryozuki this allows you to contain your unsafe code to a module unrelated to the application logic, this means that you don't introduce race conditions when you change application logic (this does use unsafe, but that's nothing bad per se, using unsafe to create safe abstractions, this is also how mutex etc. are implemented) 13:11 <+bridge> [ddnet] How to make sixup? 13:17 <+bridge> [ddnet] Maps have to be converted with map_convert_07 and put into maps7 directory 13:38 <+bridge> [ddnet] @heinrich5991\: mhh, my point really wasnt so much about performance, more about what is possible. 13:38 <+bridge> [ddnet] Also i'd have thought the difference between relaxed atomics and non atomics is simply, that non atomics don't need to exist on the memory frame readable by other threads. 13:38 <+bridge> [ddnet] So basically it could hold the value in a register all the time and only push the changes, but never read them back 13:39 <+bridge> [ddnet] @ReiTW\: can you send the map, so i dont need to enter the if city mod 13:39 <+bridge> [ddnet] sure wait 13:41 <+bridge> [ddnet] https://cdn.discordapp.com/attachments/293493549758939136/903609449476931604/TeeTown_d908d0a7.map 14:17 <+bridge> [ddnet] @deen I'm making my twmap library stricter to only allow external images that are actually valid (shipped with the vanilla client). there are 8 maps in ddnet that have faulty external images. only one of those maps actually used that image (mazepack). could you upload the fixes when you have the time? 14:17 <+bridge> [ddnet] https://cdn.discordapp.com/attachments/293493549758939136/903618540077191208/mazepack.map 14:17 <+bridge> [ddnet] https://cdn.discordapp.com/attachments/293493549758939136/903618544586068009/Hardstyle_2.map 14:17 <+bridge> [ddnet] https://cdn.discordapp.com/attachments/293493549758939136/903618547048132648/Crimson.map 14:17 <+bridge> [ddnet] https://cdn.discordapp.com/attachments/293493549758939136/903618549078183967/NUT_Hardcore_UNITED.map 14:17 <+bridge> [ddnet] https://cdn.discordapp.com/attachments/293493549758939136/903618549355020308/NUT_race7.map 14:17 <+bridge> [ddnet] https://cdn.discordapp.com/attachments/293493549758939136/903618550181290074/NUT_hardcore_race2.map 14:17 <+bridge> [ddnet] https://cdn.discordapp.com/attachments/293493549758939136/903618551519256596/Get_The_Gifts.map 14:17 <+bridge> [ddnet] https://cdn.discordapp.com/attachments/293493549758939136/903618553566093343/Deadline_1.map 14:17 <+bridge> [ddnet] hm couldve maybe zipped them, my bad 14:18 <+bridge> [ddnet] the maps are 14:18 <+bridge> [ddnet] ``` 14:18 <+bridge> [ddnet] types/ddmax/maps/Deadline 1.map 14:18 <+bridge> [ddnet] types/ddmax/maps/Get The Gifts.map 14:18 <+bridge> [ddnet] types/ddmax/maps/NUT_hardcore_race2.map 14:18 <+bridge> [ddnet] types/ddmax/maps/NUT Hardcore UNITED.map 14:18 <+bridge> [ddnet] types/ddmax/maps/NUT_race7.map 14:18 <+bridge> [ddnet] types/oldschool/maps/Crimson.map 14:18 <+bridge> [ddnet] types/oldschool/maps/Hardstyle 2.map 14:18 <+bridge> [ddnet] types/solo/maps/mazepack.map 14:18 <+bridge> [ddnet] ``` 14:19 <+bridge> [ddnet] https://cdn.discordapp.com/attachments/293493549758939136/903618943586033714/maps.zip 14:19 <+bridge> [ddnet] thanks 14:19 <+bridge> [ddnet] (deleted the single map files to clutter the chat less, sry irc) 14:19 <+bridge> [ddnet] @deen I'm making my twmap library stricter to only allow external images that are actually valid (shipped with the vanilla client). there are 8 maps in ddnet that have faulty external images. only one of those maps actually used that image (mazepack). could you upload the fixes when you have the time? 14:25 <+bridge> [ddnet] @ReiTW\: i see, the mapper used an alpha value of \>10 (normally colors are clamped between 0 - 1) in the envelop \:D 14:25 <+bridge> [ddnet] thanks for sharing 14:26 <+bridge> [ddnet] @Patiga\: can your map tool fix that already? \:D 14:27 <+bridge> [ddnet] else i have it as feature request \:P 14:27 <+bridge> [ddnet] hm how would you go about fixing that? if you clamp it to 0-1, you would interpolate differently 14:28 <+bridge> [ddnet] well the non gl 3.3 version litterally converts it to unsigned char, so not much better 14:28 <+bridge> [ddnet] just disallow and clamp is my guess 14:29 <+bridge> [ddnet] is that used so commonly or what? 14:29 <+bridge> [ddnet] huh in blender values > 1 were also easy to do for colors 14:29 <+bridge> [ddnet] bcs blender supports high dynamic color ranges 14:29 <+bridge> [ddnet] well values >1, but very close to 1 will be very very common I think 14:29 <+bridge> [ddnet] i doubt blender uses RGBA color spaces \:D 14:29 <+bridge> [ddnet] above 2 I'm not sure, lemme check 14:32 <+bridge> [ddnet] ok nvm, old backend defs clamps it before``` 14:32 <+bridge> [ddnet] clampf(r, 0.f, 1.f); 14:32 <+bridge> [ddnet] clampf(g, 0.f, 1.f); 14:32 <+bridge> [ddnet] clampf(b, 0.f, 1.f); 14:32 <+bridge> [ddnet] clampf(a, 0.f, 1.f); 14:32 <+bridge> [ddnet] m_aColor[pArray[i].m_Index].r = (unsigned char)(r * 255.f); 14:32 <+bridge> [ddnet] m_aColor[pArray[i].m_Index].g = (unsigned char)(g * 255.f); 14:32 <+bridge> [ddnet] m_aColor[pArray[i].m_Index].b = (unsigned char)(b * 255.f); 14:32 <+bridge> [ddnet] m_aColor[pArray[i].m_Index].a = (unsigned char)(a * 255.f); 14:32 <+bridge> [ddnet] ``` 14:33 <+bridge> [ddnet] so values not in range of 0-1 are "invalid" in some way 14:33 <+bridge> [ddnet] does it clamp before or after it gets multiplied with the original color value? 14:33 <+bridge> [ddnet] looks like before? 14:34 <+bridge> [ddnet] yeah 14:35 <+bridge> [ddnet] but i dont want to clamp inside the GPU 14:35 <+bridge> [ddnet] i guess this just is a flaw in the teeworlds universe 14:36 <+bridge> [ddnet] mhh but it works on the other backend 14:36 <+bridge> [ddnet] wait the function this is in is `SetColorVertex`, then it should already have calculated the influence of the envelope, no? 14:36 <+bridge> [ddnet] strange, let me debug quick 14:36 <+bridge> [ddnet] it did, i am bit confused right now, gimme a second 14:37 <+bridge> [ddnet] ah yea I remember testing that. if you have a color where the for example green value is 0.5, you can use a envelope value of 2 to get it to 1.0 green, intensifying it 14:39 <+bridge> [ddnet] ah right, doesnt matter where its clammped 14:39 <+bridge> [ddnet] the other quad corners are 0 14:39 <+bridge> [ddnet] and 0\*10 = 0 14:39 <+bridge> [ddnet] with half transparent it would also break with older backend 14:39 <+bridge> [ddnet] sounds about right ^^ 14:41 <+bridge> [ddnet] mhh that annoys me now, bcs it would only be "fixable" on the GPU side 14:41 <+bridge> [ddnet] can your tool find out what maps also do it? 14:41 <+bridge> [ddnet] i want to know if any ddnet map abuses it 14:42 <+bridge> [ddnet] yeah I'm on it 14:42 <+bridge> [ddnet] oh nice 14:45 <+bridge> [ddnet] welp 14:45 <+bridge> [ddnet] out of the ~2000 maps, 695 maps have used envelope that contains an envelope point with a value > 10.0 14:46 <+bridge> [ddnet] *have a 14:46 <+bridge> [ddnet] for colors? 14:46 <+bridge> [ddnet] or generally 14:46 <+bridge> [ddnet] generally, lemme check for colors 14:46 <+bridge> [ddnet] ah right, for the others its irrelevant 14:50 <+bridge> [ddnet] for color envelopes: 17 maps with values > 10, 43 with values > 2, 376 with values > 1 14:50 <+bridge> [ddnet] ok but i guess \>1 can also be margin of error 14:51 <+bridge> [ddnet] just so we are on the same page: the map stores the env color value as a i32. value 1 is 1024 14:51 <+bridge> [ddnet] ok it only matters for alpha values, can you also check that? XD 14:51 <+bridge> [ddnet] yeah >1 probably is mostly maps that wanted the value 1 14:51 <+bridge> [ddnet] sure 14:53 <+bridge> [ddnet] maps with color envelopes with a point with an alpha value > 2: 27 14:53 <+bridge> [ddnet] ok 14:53 <+bridge> [ddnet] if you want the list of maps for any of those I can paste it 14:54 <+bridge> [ddnet] obviously that doesnt mean it braeks smth, if the quad doesnt use the alpha channel for example 14:54 <+bridge> [ddnet] 14:54 <+bridge> [ddnet] but yeah you can show me a few 14:55 <+bridge> [ddnet] first 10 of the 27: 14:55 <+bridge> [ddnet] ``` 14:55 <+bridge> [ddnet] "types/brutal/maps/Agony.map" 14:55 <+bridge> [ddnet] "types/brutal/maps/Aim 11.0.map" 14:55 <+bridge> [ddnet] "types/brutal/maps/Aim 8.0.map" 14:55 <+bridge> [ddnet] "types/brutal/maps/Childs Play 1.map" 14:55 <+bridge> [ddnet] "types/brutal/maps/Nightly Tandem.map" 14:55 <+bridge> [ddnet] "types/brutal/maps/Space & Time 2.map" 14:55 <+bridge> [ddnet] "types/brutal/maps/Space & Time.map" 14:55 <+bridge> [ddnet] "types/ddmax/maps/Blue Sky.map" 14:55 <+bridge> [ddnet] "types/ddmax/maps/Cigarette.map" 14:55 <+bridge> [ddnet] "types/ddmax/maps/DeadEnd.map" 14:55 <+bridge> [ddnet] ``` 14:56 <+bridge> [ddnet] ah 14:56 <+bridge> [ddnet] and they can be unused, like in Aim 8.0 14:56 <+bridge> [ddnet] atleast the editor shows it "red" 14:56 <+bridge> [ddnet] i guess that means unused? 14:56 <+bridge> [ddnet] I should have already filtered the unused ones 14:56 <+bridge> [ddnet] I think it was the unintuitive color 14:56 <+bridge> [ddnet] ok then i dunno what the editor wants \:D 14:56 <+bridge> [ddnet] yea red is used 14:56 <+bridge> [ddnet] green unused 14:58 <+bridge> [ddnet] thats some weird color choice xD 14:58 <+bridge> [ddnet] agreed ^^ 14:59 <+bridge> [ddnet] mh i see, bcs all enveloppes use the same value it doesnt matter again 14:59 <+bridge> [ddnet] I must have had a stroke while coding that 15:02 <+bridge> [ddnet] i cant even tell what makes more sense tbh, multiply it in the interpolation or pre multiply itother than that it annoys me, bcs i bet 99.99% of the maps just use it without thinking about itIn @ReiTW example its not needed at all, the quad only uses corners with alpha 1 and alpha 0, which makes no difference with the env 10 15:50 <+bridge> [ddnet] Jupstar ✪: relaxed atomics similarly have no guarantees on when the changes are visible from other threads 15:50 <+bridge> [ddnet] the compiler can also keep them in a register until a synchronization point 15:51 <+bridge> [ddnet] There is a very loose guarantee that the changes will be possible in finite time :P 15:51 <+bridge> [ddnet] s\/possible/visible 15:52 <+bridge> [ddnet] is there? 15:52 <+bridge> [ddnet] it's there de-facto because cpus flush memory after some very short time 15:52 <+bridge> [ddnet] but is it guaranteed anywhere? 15:53 <+bridge> [ddnet] The C++11 standard does guarantee it iirc 15:56 <+bridge> [ddnet] > 29.3.13 Implementations should make atomic stores visible to atomic loads within a reasonable amount of time. 15:56 <+bridge> [ddnet] huh, TIL 16:01 <+bridge> [ddnet] Yep \\○/ 16:06 <+bridge> [ddnet] @heinrich5991 wouldn't it be way too difficult to use relaxed atomics for anything without that guarantee? 16:10 <+bridge> [ddnet] tell me a use case for relaxed atomics that doesn't use another form of synchronization @Learath2 16:16 <+bridge> [ddnet] Hm, any use case where you just dont want a trap representation/an incomplete update 16:18 <+bridge> [ddnet] Or where you dont care about the order w.r.t surrounding code. Getting unique ids using fetch_add or updating stats were common examples I found when researching atomics 16:18 <+bridge> [ddnet] ah yea, I can see fetch_add being useful 16:18 <+bridge> [ddnet] updating stats as well, I guess 16:20 <+bridge> [ddnet] Though I'm not sure if any relevant platforms even tear writes anymore 16:22 <+bridge> [ddnet] the CPUs themselves not (see the atomics mapping posted above, it's all normal stores) 16:22 <+bridge> [ddnet] but the compiler doesn't give any guarantees that it's going to lower your int assignment to the CPU instruction 16:45 <+bridge> [ddnet] what is a tear write 16:45 <+bridge> [ddnet] can you explain 16:45 <+bridge> [ddnet] this is hard to find with google xd 16:45 <+bridge> [ddnet] e.g. writing a u32 as one byte at a time 16:46 <+bridge> [ddnet] another thread might see a partial update 16:46 <+bridge> [ddnet] ah 16:46 <+bridge> [ddnet] thanks 16:47 <+bridge> [ddnet] Now that I think about it fetch_add is useful true but only on platforms where the operation doesnt require a full fence 16:47 <+bridge> [ddnet] I think on x86 a RMW operation always requires a lock, no? 16:49 <+bridge> [ddnet] RMW = read modify write right? 16:49 <+bridge> [ddnet] xd 16:50 <+bridge> [ddnet] i should rly deep dive in atomics sometime 16:50 <+bridge> [ddnet] i just havent had the need to do so xd 16:52 <+bridge> [ddnet] Yep 16:53 <+bridge> [ddnet] https://stackoverflow.com/questions/61744469/are-x86-atomic-rmw-instructions-wait-free 16:53 <+bridge> [ddnet] Atomics are fairly simple. Memory order is where all the insanity is 16:53 <+bridge> [ddnet] SeqCst atomics work as humans expect 16:54 <+bridge> [ddnet] :o 16:54 <+bridge> [ddnet] the answer to this question is long af 16:56 <+bridge> [ddnet] Hi, would be cool to add custom colorization for some entities instead of having to edit the asset. 16:58 <+bridge> [ddnet] applying a tint to the whole entity is probs easy but u probs dont want that 16:58 <+bridge> [ddnet] i dont think its worth 18:16 <+bridge> [ddnet] Jupstar ✪: you know if there is a way to render a label (or text) on a rect but that is not centered vertically 18:16 <+bridge> [ddnet] e.g it starts from the top 18:18 <+bridge> [ddnet] it is possible, but e.g. a g would go bellow it 18:19 <+bridge> [ddnet] or from the top `|` might be above it 18:19 <+bridge> [ddnet] https://cdn.discordapp.com/attachments/293493549758939136/903679355392237629/tooltip.mp4 18:19 <+bridge> [ddnet] im trying to do this 18:19 <+bridge> [ddnet] a tooltip 18:19 <+bridge> [ddnet] on hover 18:19 <+bridge> [ddnet] https://cdn.discordapp.com/attachments/293493549758939136/903679442189168700/unknown.png 18:19 <+bridge> [ddnet] oh 18:20 <+bridge> [ddnet] do label also has vertical alignment 18:20 <+bridge> [ddnet] idk why it doesnt start on top 18:20 <+bridge> [ddnet] xd 18:20 <+bridge> [ddnet] let me see in code wait 18:22 <+bridge> [ddnet] guess bcs of the margin? 18:23 <+bridge> [ddnet] i guess it just wasnt made for multi lines, is it multi line? 18:23 <+bridge> [ddnet] i added maxwidth so it becomes multiline 18:23 <+bridge> [ddnet] i guess 18:23 <+bridge> [ddnet] xd 18:23 <+bridge> [ddnet] the text itself doesnt have \n 18:24 <+bridge> [ddnet] the margin is 1 18:24 <+bridge> [ddnet] on all sides 18:24 <+bridge> [ddnet] ok 18:24 <+bridge> [ddnet] if i make the rect height 18:24 <+bridge> [ddnet] small enough it kinda starts 18:25 <+bridge> [ddnet] but the text overflows 18:25 <+bridge> [ddnet] i'd say add``` 18:25 <+bridge> [ddnet] else if(AlignVertically == 1) 18:25 <+bridge> [ddnet] { 18:25 <+bridge> [ddnet] AlignmentVert = pRect->y; 18:25 <+bridge> [ddnet] } 18:25 <+bridge> [ddnet] ```to DoLabel 18:25 <+bridge> [ddnet] it just isnt implemented yet 18:25 <+bridge> [ddnet] xd 18:25 <+bridge> [ddnet] ok ill put it there 18:25 <+bridge> [ddnet] btw 18:25 <+bridge> [ddnet] Align 18:25 <+bridge> [ddnet] to align on left 18:25 <+bridge> [ddnet] is -1? 18:25 <+bridge> [ddnet] i hecking love magic numbers 18:25 <+bridge> [ddnet] ah sry 18:25 <+bridge> [ddnet] -1 18:26 <+bridge> [ddnet] yeah -1 is left i think 18:26 <+bridge> [ddnet] https://cdn.discordapp.com/attachments/293493549758939136/903681172595425371/unknown.png 18:26 <+bridge> [ddnet] i added this 18:26 <+bridge> [ddnet] i wonder if it works 18:26 <+bridge> [ddnet] also pls add it to DoTextLabel, same code just without `pRect->` 18:26 <+bridge> [ddnet] lamo so much code duplicates always 18:26 <+bridge> [ddnet] xd 18:27 <+bridge> [ddnet] yeah try it \:D 18:27 <+bridge> [ddnet] but also add it to DoLabel 18:27 <+bridge> [ddnet] there are 2 versions xD 18:27 <+bridge> [ddnet] jhust search AlignVertically in the file 18:27 <+bridge> [ddnet] ye xd 18:27 <+bridge> [ddnet] done 18:27 <+bridge> [ddnet] :w 18:27 <+bridge> [ddnet] ups 18:27 <+bridge> [ddnet] my vim lmao 18:27 <+bridge> [ddnet] leaking 18:27 <+bridge> [ddnet] the other uses pRect 18:27 <+bridge> [ddnet] yeye 18:28 <+bridge> [ddnet] it works nice 18:28 <+bridge> [ddnet] epic gamer moment 18:28 <+bridge> [ddnet] do u know 18:28 <+bridge> [ddnet] if i can calculate the perfect font height 18:28 <+bridge> [ddnet] but nice that you implement tooltips 18:29 <+bridge> [ddnet] for a given width and height rect 18:29 <+bridge> [ddnet] ? 18:29 <+bridge> [ddnet] xd 18:29 <+bridge> [ddnet] nope you cant 18:29 <+bridge> [ddnet] ok 18:30 <+bridge> [ddnet] freetype might round up and down depending on the requiresments 18:30 <+bridge> [ddnet] so you'd have to test all fontsizes 18:30 <+bridge> [ddnet] but you can do an estimate theoretically and just subtract it by 1 or smth 18:31 <+bridge> [ddnet] hmm maybe tooltips want to use more stuff than a simple text 18:31 <+bridge> [ddnet] i guess i can leave dotooltip as a smart rect generator 18:32 <+bridge> [ddnet] what is the current issue? 18:33 <+bridge> [ddnet] https://github.com/ddnet/ddnet/issues/4212 18:33 <+bridge> [ddnet] text is bigger than fontsize bcs of the outline for example 18:33 <+bridge> [ddnet] ah no 18:33 <+bridge> [ddnet] i dont have any issue right now 18:33 <+bridge> [ddnet] oh ok 18:33 <+bridge> [ddnet] i just thought a tooltip should be able to display buttons and anything 18:33 <+bridge> [ddnet] so i wont render text on the dotooltip function 18:33 <+bridge> [ddnet] it will just place a rect smartly 18:33 <+bridge> [ddnet] i see 18:34 <+bridge> [ddnet] https://cdn.discordapp.com/attachments/293493549758939136/903683120115613737/unknown.png 18:35 <+bridge> [ddnet] oh i should also allow color 18:35 <+bridge> [ddnet] do u think it should have some outline? 18:35 <+bridge> [ddnet] mhh, a small shadow always looks cool xd 18:35 <+bridge> [ddnet] xd 18:36 <+bridge> [ddnet] but our outline is boring anyway xD 18:36 <+bridge> [ddnet] a shadow that fades out would be nice xD 18:44 <+bridge> [ddnet] https://cdn.discordapp.com/attachments/293493549758939136/903685686589272084/unknown.png 18:45 <+bridge> [ddnet] https://cdn.discordapp.com/attachments/293493549758939136/903685900456833094/unknown.png 18:45 <+bridge> [ddnet] Hello World pro edition 18:45 <+bridge> [ddnet] i guess its ok 18:45 <+bridge> [ddnet] ah 18:45 <+bridge> [ddnet] wait 18:45 <+bridge> [ddnet] what now 18:46 <+bridge> [ddnet] pSelCursor 18:46 <+bridge> [ddnet] this is just a test so 18:46 <+bridge> [ddnet] the code image demonstrates the usage of DoTooltip 18:46 <+bridge> [ddnet]