02:16 <+bridge> [ddnet] I implemented that in one of my clients. For Linux only tho. 02:16 <+bridge> [ddnet] (@BloodWod-513) 11:00 <+bridge> [ddnet] for noby (no HiDPI) 11:00 <+bridge> [ddnet] https://github.com/ddnet/ddnet/blob/a49082d510594a13d6bc63f4beae133b902eb662/src/engine/client/backend_sdl.cpp#L946-L950 11:00 <+bridge> [ddnet] 11:00 <+bridge> [ddnet] causes this 11:00 <+bridge> [ddnet] 11:00 <+bridge> [ddnet] https://cdn.discordapp.com/attachments/520621816226643972/887500328747008000/Screen_Shot_2021-09-14_at_7.49.22_PM.png 11:00 <+bridge> [ddnet] 11:00 <+bridge> [ddnet] just using 11:00 <+bridge> [ddnet] `SDL_GL_GetDrawableSize(m_pWindow, pCurrentWidth, pCurrentHeight); ` 11:00 <+bridge> [ddnet] fixes it 11:00 <+bridge> [ddnet] 11:00 <+bridge> [ddnet] @TsFreddie did you not experience this when testing? 11:00 <+bridge> [ddnet] It's really weird that SDL2 is so inconsistent then 11:00 <+bridge> [ddnet] 🤔 11:00 <+bridge> [ddnet] nope 11:01 <+bridge> [ddnet] ok xd 11:01 <+bridge> [ddnet] ~~can we sue SDL2~~ 11:01 <+bridge> [ddnet] xd 11:01 <+bridge> [ddnet] i'll just wait for an epic 10h debugging session by Learath and its fine 11:54 <+bridge> [ddnet] oof 11:54 <+bridge> [ddnet] he might end SDL2 11:56 <+bridge> [ddnet] @Jupstar ✪\: what do you want me to do here? https://github.com/ddnet/ddnet/pull/4157#discussion_r707436519 11:57 <+bridge> [ddnet] use reference 11:58 <+bridge> [ddnet] when calling the function? 11:59 <+bridge> [ddnet] just use the function like `UnloadTextureNew` 11:59 <+bridge> [ddnet] its the most used anyway 11:59 <+bridge> [ddnet] not in upstream 11:59 <+bridge> [ddnet] i never understood refrences 11:59 <+bridge> [ddnet] yeah idc, just merge the two functions 12:00 <+bridge> [ddnet] and use references 12:00 <+bridge> [ddnet] yea i thought they could be merged then i was scared \:D 12:00 <+bridge> [ddnet] because of the REFRENCE 12:00 <+bridge> [ddnet] xxD 12:00 <+bridge> [ddnet] why tho 12:01 <+bridge> [ddnet] dont we have a naming convetion for refrences? 12:01 <+bridge> [ddnet] reference is bascially same as pointer, just without uglyness and NULL xd 12:01 <+bridge> [ddnet] like \_r prefix? 12:01 <+bridge> [ddnet] and no rebind 12:01 <+bridge> [ddnet] what? xD 12:01 <+bridge> [ddnet] sounds good 12:01 <+bridge> [ddnet] just wondering how i know a var is a refrence 12:02 <+bridge> [ddnet] & 12:02 <+bridge> [ddnet] you'll find out if something don't work :greenthing: 12:02 <+bridge> [ddnet] i mean by name 12:02 <+bridge> [ddnet] why would you want to know it 12:02 <+bridge> [ddnet] doesnt it make sense to mark it with a prefix? 12:02 <+bridge> [ddnet] same as pointers 12:02 <+bridge> [ddnet] if the object should not be modifable it should be const ref 12:03 <+bridge> [ddnet] else its just like you alter the object 12:03 <+bridge> [ddnet] one might think its a local variable 12:03 <+bridge> [ddnet] fromt he scope of the current function 12:03 <+bridge> [ddnet] then he should learn coding xD 12:03 <+bridge> [ddnet] fak off 12:03 <+bridge> [ddnet] xd 12:03 <+bridge> [ddnet] i just feel like it would be more consistant wouldnt it 12:04 <+bridge> [ddnet] no 12:04 <+bridge> [ddnet] ok 12:04 <+bridge> [ddnet] just do the opposite of vanilla and you are god pro 12:04 <+bridge> [ddnet] Jupstar and I disagree on whether we should use a reference there :/ 12:04 <+bridge> [ddnet] I think we had an issue where this was discussed 12:04 <+bridge> [ddnet] pointer always looks like you can pass NULL 12:04 <+bridge> [ddnet] imho references should be used anywhere u dont expect null pointers 12:04 <+bridge> [ddnet] they are safer 12:05 <+bridge> [ddnet] its actually C++ fault you can pass a argument to a function expecting a reference without an implicit & imho 12:05 <+bridge> [ddnet] well, there is also gsl::not_null if you need reassignable non-nullable pointers 12:06 <+bridge> [ddnet] https://github.com/ddnet/ddnet/issues/3088#issuecomment-708713058 12:06 <+bridge> [ddnet] ah here 12:06 <+bridge> [ddnet] then lets ignore that xD 12:06 <+bridge> [ddnet] i use references all the time 12:06 <+bridge> [ddnet] but in any case you won't know if a variable is actually a reference unless you have a naming convention, IDE features, know the code in and out or look it up 12:06 <+bridge> [ddnet] also auto can make code rly confusing 12:06 <+bridge> [ddnet] is my auto var & && **? 12:06 <+bridge> [ddnet] cuz auto does weird things 12:06 <+bridge> [ddnet] xd 12:06 <+bridge> [ddnet] Learath2 and deen also think we should use references where variables are non-null 12:07 <+bridge> [ddnet] https://github.com/teeworlds/documentation/blob/master/nomenclature.md#passing-variables 12:07 <+bridge> [ddnet] i think thats outdated for ddnet 12:07 <+bridge> [ddnet] so we have pros/cons: 12:07 <+bridge> [ddnet] + can't be null 12:07 <+bridge> [ddnet] - non-obvious at call site 12:07 <+bridge> [ddnet] anything else? 12:07 <+bridge> [ddnet] we got a issue with the naming stuff 12:08 <+bridge> [ddnet] looks cleaner than putting & before everything 12:08 <+bridge> [ddnet] can you elaborate? & makes it obvious that the variable can be changed (in the absence of non-const references) 12:08 <+bridge> [ddnet] so you consider that clutter? 12:08 <+bridge> [ddnet] as said in the pr, const pointer 12:08 <+bridge> [ddnet] so it doesnt imply anything 12:09 <+bridge> [ddnet] you have to check the function body anyway 12:09 <+bridge> [ddnet] yes, it implies it – in the absence of non-const referneces the variable cannot be changed if you don't put a & 12:09 <+bridge> [ddnet] an & doesn't imply that it will be changed 12:09 <+bridge> [ddnet] yeah 12:09 <+bridge> [ddnet] you cannot guarantee that anyway(?), not even rust has that 12:10 <+bridge> [ddnet] see, so it doesnt improve anything to use & 12:10 <+bridge> [ddnet] @ChillerDragon this is ours https://github.com/ddnet/ddnet/issues/2945 12:10 <+bridge> [ddnet] I think it does improve the following: in the majority of cases, the argument is passed without & and then I know that it won't be changed 12:10 <+bridge> [ddnet] do you disagree with this argument? 12:11 <+bridge> [ddnet] yes, bcs i expect references 12:11 <+bridge> [ddnet] just like there can be const pointers 12:11 <+bridge> [ddnet] okay, but in the absence of non-const references 12:11 <+bridge> [ddnet] do you see how this argument is valid? 12:11 <+bridge> [ddnet] const pointers seem to be a distraction here. I'm not saying that & will change the variable 12:12 <+bridge> [ddnet] just that without an ampersand (and without non-const references) it won't change the variabel 12:12 <+bridge> [ddnet] @Learath2 ur missing an important convo :monkalaugh: 12:12 <+bridge> [ddnet] yes, and that's why i dont see any reason that & should be used for modifying stuff like references shouldnt 12:12 <+bridge> [ddnet] you completely don't understand my argument? I don't know how else to explain it tbh 12:12 <+bridge> [ddnet] you can obviously weigh it less than any counterpoints, but it seems my point doesn't get across 12:14 <+bridge> [ddnet] The problem is 12:14 <+bridge> [ddnet] even if you see & in the code, you have to check if the function takes it as const pointer or not 12:14 <+bridge> [ddnet] so it doesnt improve anything anyway 12:15 <+bridge> [ddnet] okay, let me try once more: 12:15 <+bridge> [ddnet] the benefit of not using non-const references is that I *don't* have to check whether the argument is modified if there's no & 12:15 <+bridge> [ddnet] I'm not claiming anything about the case where there's an &. obviously it might or might not be modified there 12:16 <+bridge> [ddnet] even if it's a non-const pointer, it might not be modified 12:16 <+bridge> [ddnet] do you see what I mean with my first of the three messages? (keeping in mind the second and the third) 12:18 <+bridge> [ddnet] I think this is an issue of what you are used to. As a C programmer the & makes it extremely likely to me that the object I pass will be changed. A modern C++ programmer that is more used to references would obviously argue that the & doesn't imply anything since the reference feature indeed makes it quite ambiguous 12:18 <+bridge> [ddnet] nope, just isnt really an arguement for me 12:18 <+bridge> [ddnet] Doesn't matter if & or no &, in the end you look at the function body anyway 12:19 <+bridge> [ddnet] without non-const references, you don't need to look at the function body. do you agree? 12:19 <+bridge> [ddnet] this seems to be a matter of logic to me, not really something to have an opinion on 12:19 <+bridge> [ddnet] you have to check if the value is modified or not anyway 12:19 <+bridge> [ddnet] so you end up looking at the function body 12:19 <+bridge> [ddnet] it should be expected that non-const references are modified and const-references are not 12:20 <+bridge> [ddnet] I'm sorry, missed the ampersand thing 12:20 <+bridge> [ddnet] that sounds the most reasonable imho 12:20 <+bridge> [ddnet] without non-const references, you don't need to look at the function body if there's no ampersand. do you agree? 12:20 <+bridge> [ddnet] I agree that the first one was wrong 12:20 <+bridge> [ddnet] @Jupstar ✪ 12:21 <+bridge> [ddnet] (if oyu don't pass a pointer, you can generate a pointer without an ampersand…) 12:21 <+bridge> [ddnet] Double negative makes that a bit hard to read :P 12:22 <+bridge> [ddnet] "With only const references, you need to look at the function body if there is no ampersand" 12:22 <+bridge> [ddnet] Hm that doesnt make much sense either :D 12:23 <+bridge> [ddnet] with only const references, you only need to look at the function body if there's an ampersand 12:23 <+bridge> [ddnet] I think this is the same statement, but positive 12:24 <+bridge> [ddnet] (btw, I see that you need to look at the function body to see if it's actually modified if you do pass a pointer, I also see that you need to look at the function body to see if a variable is modified in the presence of non-const references) 12:25 <+bridge> [ddnet] didn't other style guides solve this issue already? 12:26 <+bridge> [ddnet] Most style guides are led by ideology not logic. C++ people would promote the use of their shiny references and C people would promote pointers 12:27 <+bridge> [ddnet] well style guides by definition are subjective 12:27 <+bridge> [ddnet] no matter the lang 12:27 <+bridge> [ddnet] You can have an objective discussion on when to use 2 equivalent things 12:27 <+bridge> [ddnet] Yea so the issue is that we introduced c++ at all \:p 12:27 <+bridge> [ddnet] I was trying to establish arguments in favor and against usage of references 12:27 <+bridge> [ddnet] I thought this was kinda objective, but one of my arguments was dismissed as completely invalid 12:28 <+bridge> [ddnet] I thought this was kinda objective, but one of my arguments was dismissed as invalid 12:28 <+bridge> [ddnet] I think what tips the scale for references are rvalue references, which achieve something you can't do with pointers 12:29 <+bridge> [ddnet] what you're doing is giving a conclusion already. I think it's better to collect arguments first and get to a conclusion later 12:29 <+bridge> [ddnet] so people like me don't get stuck on their position, but rather document the pros/cons together and then see how we weigh them 12:29 <+bridge> [ddnet] so you are saying you don't care how the value is passed? 12:30 <+bridge> [ddnet] Can we assume proper const usage so the arguments are easier? 12:30 <+bridge> [ddnet] ^ 12:30 <+bridge> [ddnet] no, that's not what I'm trying to say. can you explain what part of my message made you think that? 12:31 <+bridge> [ddnet] I was trying to present the statement in a logic form 12:31 <+bridge> [ddnet] I was trying to present the statement in a logical form 12:31 <+bridge> [ddnet] ok then let me ask this: 12:31 <+bridge> [ddnet] You talk about references, what kind of references? 12:32 <+bridge> [ddnet] do you want to forbid moving code or what?== 12:32 <+bridge> [ddnet] I'm talking about c++98-style references 12:33 <+bridge> [ddnet] c++98:monkaS: 12:33 <+bridge> [ddnet] maybe this is where our disagreement on what's logical comes from? 12:33 <+bridge> [ddnet] So only lvalue references 12:33 <+bridge> [ddnet] you were already considering rvalue references? 12:34 <+bridge> [ddnet] mhh, I'm just not sure if a const ref should imply, you don't have to care about it 12:35 <+bridge> [ddnet] you mean you're not sure if a const reference should imply that the function doesn't change the variable's value? 12:36 <+bridge> [ddnet] not that, but e.g. taking an address of a member of the reference for example 12:36 <+bridge> [ddnet] e.g. not passing variables with limited lifetime 12:37 <+bridge> [ddnet] The const is poisonous, you cant take a non const pointer through it 12:38 <+bridge> [ddnet] Can't even call a non const function through it. So const is fairly safe 12:38 <+bridge> [ddnet] assuming there is no const cast, which there is in vanilla :justatest: 12:39 <+bridge> [ddnet] and then there is `mutable` xd 12:42 <+bridge> [ddnet] Wait what?? What for? 12:42 <+bridge> [ddnet] in CChat to replace newlines with spaces or something like that 12:42 <+bridge> [ddnet] > mutable - permits modification of the class member declared mutable even if the containing object is declared const. 12:42 <+bridge> [ddnet] :monkalaugh: 12:42 <+bridge> [ddnet] probably somewhere else as well 12:42 <+bridge> [ddnet] ``` 12:42 <+bridge> [ddnet] src/game/client/components/chat.cpp 12:42 <+bridge> [ddnet] 669: *(const_cast(pStr)) = 0; 12:42 <+bridge> [ddnet] 674: *(const_cast(pEnd)) = 0; 12:42 <+bridge> [ddnet] 677: char *p = const_cast(pLine); 12:42 <+bridge> [ddnet] 12:42 <+bridge> [ddnet] src/game/server/gamecontext.cpp 12:42 <+bridge> [ddnet] 1736: *(const_cast(p)) = 0; 12:43 <+bridge> [ddnet] 1741: *(const_cast(pEnd)) = 0; 12:43 <+bridge> [ddnet] 12:43 <+bridge> [ddnet] src/engine/shared/console.cpp 12:43 <+bridge> [ddnet] 1088: str_copy(const_cast(pCommand->m_pName), pName, TEMPCMD_NAME_LENGTH); 12:43 <+bridge> [ddnet] 1089: str_copy(const_cast(pCommand->m_pHelp), pHelp, TEMPCMD_HELP_LENGTH); 12:43 <+bridge> [ddnet] 1090: str_copy(const_cast(pCommand->m_pParams), pParams, TEMPCMD_PARAMS_LENGTH); 12:43 <+bridge> [ddnet] ``` 12:45 <+bridge> [ddnet] Um, modifying a const object through a non const lvalue is still UB 12:45 <+bridge> [ddnet] no, unfortunately not 12:45 <+bridge> [ddnet] it only matters if the original variable is declared const 12:46 <+bridge> [ddnet] That’s what I said? 12:46 <+bridge> [ddnet] which means the compiler can't use const on pointers to optimize 12:46 <+bridge> [ddnet] ah 12:46 <+bridge> [ddnet] then I misunderstood 12:46 <+bridge> [ddnet] I assumed the members of pCommand were declared const 12:47 <+bridge> [ddnet] ```c++ 12:47 <+bridge> [ddnet] class CCommandInfo 12:47 <+bridge> [ddnet] { 12:47 <+bridge> [ddnet] protected: 12:48 <+bridge> [ddnet] int m_AccessLevel; 12:48 <+bridge> [ddnet] 12:48 <+bridge> [ddnet] public: 12:48 <+bridge> [ddnet] CCommandInfo() { m_AccessLevel = ACCESS_LEVEL_ADMIN; } 12:48 <+bridge> [ddnet] virtual ~CCommandInfo() {} 12:48 <+bridge> [ddnet] const char *m_pName; 12:48 <+bridge> [ddnet] const char *m_pHelp; 12:48 <+bridge> [ddnet] const char *m_pParams; 12:48 <+bridge> [ddnet] 12:48 <+bridge> [ddnet] virtual const CCommandInfo *NextCommandInfo(int AccessLevel, int FlagMask) const = 0; 12:48 <+bridge> [ddnet] 12:48 <+bridge> [ddnet] int GetAccessLevel() const { return m_AccessLevel; } 12:48 <+bridge> [ddnet] }; 12:48 <+bridge> [ddnet] ``` 12:48 <+bridge> [ddnet] so it matters with what it's initialized 12:48 <+bridge> [ddnet] Anyway, we veered off course. @heinrich5991 so talking about lvalue references and assuming proper const usage. Do you have any reason you don’t like references? I think either way you need to look at the signature 12:48 <+bridge> [ddnet] how did you made it colored 12:49 <+bridge> [ddnet] ```c++ 12:49 <+bridge> [ddnet] oh ok 12:49 <+bridge> [ddnet] jupstar nobo 12:50 <+bridge> [ddnet] yes, my argument against lvalue references was that they make variable modification at call sites nonobvious 12:51 <+bridge> [ddnet] i am not going to deny that this is an argument, i just wouldn't know if i'd rely on that in every situation 12:51 <+bridge> [ddnet] Hm, well it is non-obvious even with &, which could be a const pointer. I don’t think you can avoid a look at the signature in C++ 12:51 <+bridge> [ddnet] A good function name solves more problems 12:52 <+bridge> [ddnet] but it is obvious for the cases where you just pass a non-pointer 12:52 <+bridge> [ddnet] is that a significant amount of cases in our code base? 12:52 <+bridge> [ddnet] I guess strings are passed as pointers 12:52 <+bridge> [ddnet] Hm, how about wrapper classes like shared_ptr? 12:53 <+bridge> [ddnet] we currently call them `p` 12:54 <+bridge> [ddnet] (i.e. you can still see it at the call site) 12:55 <+bridge> [ddnet] That’s fair. So pointers make the code easier to skim 12:55 <+bridge> [ddnet] only if you dont care about const refs 12:55 <+bridge> [ddnet] add _mut at end of the function if it modifies :monkalaugh: 12:56 <+bridge> [ddnet] so no mutable, no pointers from const ref 12:56 <+bridge> [ddnet] addresses* 12:56 <+bridge> [ddnet] ? If references don’t exist in the codebase no & and not an array implies no modification 12:57 <+bridge> [ddnet] (we do have mutable in the codebase, but it is rare) 12:57 <+bridge> [ddnet] Huh, where did we use one? A mutex? 12:57 <+bridge> [ddnet] you can use them without modifying tho 12:58 <+bridge> [ddnet] yes, but that's not what my point is about 12:58 <+bridge> [ddnet] it's about the case where you don't pass the pointer (see also what Learath2 said) 12:58 <+bridge> [ddnet] what you're saying is not an argument against the benefit Learath2 said 12:58 <+bridge> [ddnet] it's not an equivalence, it's just a one-way implication 13:00 <+bridge> [ddnet] anyway, anything that isnt flagged const must be expected to be modified anyway 13:01 <+bridge> [ddnet] a good function name solves more 13:02 <+bridge> [ddnet] while coding i normally see the signature anyway, so it doesn't improve the situation imo 13:02 <+bridge> [ddnet] those are arguments on top of the presented argument 13:02 <+bridge> [ddnet] have we accepted the argument and can move to counter arguments? 13:03 <+bridge> [ddnet] Well idk about you but I don’t only skim on my computer. I sometimes browse on less than ideal situations 13:03 <+bridge> [ddnet] NULL is the counter argument 13:03 <+bridge> [ddnet] yes, it's a different argument 13:03 <+bridge> [ddnet] NULL 0 nullptr 13:03 <+bridge> [ddnet] :monkalaugh: 13:03 <+bridge> [ddnet] do you refuse to list pros/cons individually? @Jupstar ✪ 13:03 <+bridge> [ddnet] c++ loves diversity 13:04 <+bridge> [ddnet] Assuming everyone uses a cutting edge space station IDE is a bad idea imo. It leads to Java 13:04 <+bridge> [ddnet] i thought we are at the counter argument for pointers now 13:04 <+bridge> [ddnet] okay, so you do accept the above argument as valid, i.e. might not apply to you but you see why other people might think that? 13:04 <+bridge> [ddnet] i use vim and just have to press K to view the signature and gd to view the definition 13:04 <+bridge> [ddnet] u dont need an ide :monkaS: 13:05 <+bridge> [ddnet] Your vim setup is not far off from an ide 😛 13:05 <+bridge> [ddnet] i dont know what you mean, but i still wouldn't ignroe const refs, just bcs they are not modifable 13:05 <+bridge> [ddnet] I don't think this discussion is viable if you refuse to accept counter arguments 13:06 <+bridge> [ddnet] Hm, isn’t the point of this argument to pretend the other option doesn’t exist? 13:06 <+bridge> [ddnet] i accept that a extra symbol in c++ could improve the situation 13:06 <+bridge> [ddnet] an 13:06 <+bridge> [ddnet] i see his argument 13:06 <+bridge> [ddnet] i just dont weight it as 100% given 13:06 <+bridge> [ddnet] If we decide pointers are the better tool we wouldn’t have const references in the codebase 13:06 <+bridge> [ddnet] i'd like to not rely on that 13:07 <+bridge> [ddnet] wait 13:07 <+bridge> [ddnet] he talks about only using const ref 13:07 <+bridge> [ddnet] doesnt he 13:07 <+bridge> [ddnet] yes. I think Learath2 means non-const 13:08 <+bridge> [ddnet] Hm, now I disagree. I think we should use one, not mix and match. Const references do make it ambiguous again 13:08 <+bridge> [ddnet] well with pointers only we have the same situation 13:08 <+bridge> [ddnet] we want a visual difference between modifyable and not modyfiable 13:09 <+bridge> [ddnet] No we don’t with pointers only, if you don’t see an & and the thing you are passing is not an array it’s guaranteed that no modification can even happen 13:09 <+bridge> [ddnet] yeah, so i guess the easiest is what deen said acutally 13:10 <+bridge> [ddnet] not allow null pointers 13:11 <+bridge> [ddnet] and still keep in mind there is mutable and also you might want to take a const ref and expect a different lifetime 13:11 <+bridge> [ddnet] so its not a 100% garantuee imo 13:12 <+bridge> [ddnet] anyway, i think we should still allow references, they just feel nicer to use, like you just work with that variable 13:12 <+bridge> [ddnet] UnloadTexture implies to me that the object is invalid after calling it 13:12 <+bridge> [ddnet] But the fact that there is mutable doesn’t change this 13:13 <+bridge> [ddnet] i dont understand that tbh, why does mutable not change it? 13:13 <+bridge> [ddnet] isnt that the whole sense of mutable 13:14 <+bridge> [ddnet] If you don’t see an & how is the called function supposed to mutate anything? 13:14 <+bridge> [ddnet] The called function will get it’s own copy of the object through the copy constructor 13:14 <+bridge> [ddnet] AHH 13:14 <+bridge> [ddnet] thats what u mean xD 13:15 <+bridge> [ddnet] yeah, but can create quite a bit of copying 13:15 <+bridge> [ddnet] e.g passing a std::vector 13:16 <+bridge> [ddnet] Ofc, which is why you’d pass those as a pointer instead. A const one if you don’t modify a non-const one if you do. If you see an ampersand you need to look at the signature. If we enforce proper const usage that’s where you are done 13:16 <+bridge> [ddnet] Ofc, which is why you’d pass those as a pointer instead. A const one if you don’t modify, a non-const one if you do. If you see an ampersand you need to look at the signature. If we enforce proper const usage that’s where you are done 13:17 <+bridge> [ddnet] sure, but then we defs also have to limit more stuff 13:18 <+bridge> [ddnet] Btw, I don’t mean to say this is the best solution. I’m just illustrating that it is indeed possible to reason more about a call locally when only using pointers 13:18 <+bridge> [ddnet] Dare I say a 100% even if you look at the signature 🙂 13:18 <+bridge> [ddnet] Dare I say a 100% even, if you look at the signature 🙂 13:18 <+bridge> [ddnet] well you could also always use std::ref xD 13:19 <+bridge> [ddnet] if you have no other hobbies 13:19 <+bridge> [ddnet] that would visually split it 13:19 <+bridge> [ddnet] i mean 13:20 <+bridge> [ddnet] @heinrich5991 why were you okay with const references anyway? The rarity of const_cast and mutable? 13:21 <+bridge> [ddnet] yes, that only works with rarity of const_cast and mutable 13:22 <+bridge> [ddnet] I guess we can now talk about references being non-null? 13:22 <+bridge> [ddnet] idk, has Jupstar understood that the above is an argument that can be made? 13:22 <+bridge> [ddnet] i'd still say lifetime is underestimated 13:22 <+bridge> [ddnet] if you have like SetInstance 13:22 <+bridge> [ddnet] the ref cannot be rebinded 13:22 <+bridge> [ddnet] rebound 13:23 <+bridge> [ddnet] i think i have been clear its an argument, but not one that eliminates reference usage for me 13:24 <+bridge> [ddnet] I wasn't really asking for the latter, I was trying to enumerate valid arguments 13:24 <+bridge> [ddnet] No one is saying 1 argument needs to convince us. Just need to make the arguments first, then we can look at them and decide 13:24 <+bridge> [ddnet] but I understand that you feel strongly about this 13:24 <+bridge> [ddnet] ok, so let's move on to other argumetns 13:25 <+bridge> [ddnet] ambiguity of whether a variable can be null or not is indeed a problem for pointers 13:25 <+bridge> [ddnet] there's no easy native non-null pointer type, unfortunately 13:25 <+bridge> [ddnet] The not-null guarantee also allows us to drop null checks at some places, albeit very easy for the branch predictor 13:26 <+bridge> [ddnet] Peppering the code with `gsl::not_null` doesn’t really seem viable, it’s a tad ugly imo 13:26 <+bridge> [ddnet] where? mostly in dbg_assert? 13:26 <+bridge> [ddnet] yes, and it's also something that should be a default 13:27 <+bridge> [ddnet] not something you have to remember to write 13:27 <+bridge> [ddnet] [gcc::nonnull] void* pPtr 13:27 <+bridge> [ddnet] [[]] 13:28 <+bridge> [ddnet] Well responsibly if you expect someone might re-use your function it’s s good idea to have a null check. With references you are forcing it to never be called in a wrong way 13:29 <+bridge> [ddnet] I agree that with references you don't have the problem 13:29 <+bridge> [ddnet] I'd say pretending they're non-null is a fine strategy for pointers 13:29 <+bridge> [ddnet] , hoping for it to crash in that case 13:31 <+bridge> [ddnet] but yes, that's a clear win for references 13:43 <+bridge> [ddnet] yikers 13:43 <+bridge> [ddnet] jupjapjop rage quitted the pr \:( 13:43 <+bridge> [ddnet] :monkaS: 13:44 <+bridge> [ddnet] neutral = idc 13:45 <+bridge> [ddnet] i tried to avoid the discussion and only implement ur merge request 13:45 <+bridge> [ddnet] we dont allow size_t, we dont allow anything, i just dont want to judge on all these restrictions 13:45 <+bridge> [ddnet] i wanted your feedback on if i did that correctly 13:45 <+bridge> [ddnet] i think you did 13:45 <+bridge> [ddnet] \:) 13:54 <+bridge> [ddnet] size_t best 13:55 <+bridge> [ddnet] auto best 14:38 <+bridge> [ddnet] I love unsigned types ❤️ 14:40 <+bridge> [ddnet] petition to finally make all indices unsigned so we don't have to goof around with int casts 14:41 <+bridge> [ddnet] size_t is unsigned right 14:41 <+bridge> [ddnet] yep 14:41 <+bridge> [ddnet] usize from rust describes it better imho 14:42 <+bridge> [ddnet] rust even has this https://doc.rust-lang.org/std/num/struct.NonZeroUsize.html 14:42 <+bridge> [ddnet] "This enables some memory layout optimization" 14:42 <+bridge> [ddnet] usize misses the distinction between size_t and uintptr_t, not sure how relevant this is 14:43 <+bridge> [ddnet] I had an interesting discussion in #C a couple days ago, given a start and an end pointer, how would you check if an object of n bytes given in `size_t` fits? e.g. `bool fits(char *b, char *e, size_t n)` 14:44 <+bridge> [ddnet] I believe objects larger than size_t are UB? 14:44 <+bridge> [ddnet] ye right? 14:44 <+bridge> [ddnet] I believe objects larger than SSIZE_MAX are UB? 14:44 <+bridge> [ddnet] They can't possibly exist due to how the standards written iirc 14:45 <+bridge> [ddnet] so e-b < n? 14:45 <+bridge> [ddnet] so `e-b < n`? 14:45 <+bridge> [ddnet] This is indeed the correct answer, but bonus question, most compilers will complain about this, how would you fix it? 14:45 <+bridge> [ddnet] so `e-b <= n`? 14:45 <+bridge> [ddnet] cast it to `size_t` 14:46 <+bridge> [ddnet] well you have the comparison the wrong way around actually 14:46 <+bridge> [ddnet] because we know that hte left side can't be negative, given the specification 14:46 <+bridge> [ddnet] ah true 14:46 <+bridge> [ddnet] `e-b >= n` 14:46 <+bridge> [ddnet] `(size_t)(e-b) >= n` 14:46 <+bridge> [ddnet] we don't know if the right side is smaller than SSIZE_MAX 14:48 <+bridge> [ddnet] do we rly not allow size_t rn? 14:48 <+bridge> [ddnet] I believe I said to Jupstar that we don't use it and that he should change it in the PR 14:48 <+bridge> [ddnet] what was the pr 14:49 <+bridge> [ddnet] This is the conclusion we came to aswell, surprised you got it that quickly 😛 14:49 <+bridge> [ddnet] heinrich is a genius 14:50 <+bridge> [ddnet] I had the benefit that I knew it was a trick question 😛 14:50 <+bridge> [ddnet] The naive approach is `b + n < e` which leads to all sorts of interesting questions about pointer arithmetic and whether it's UB to even calculate an invalid pointer 14:51 <+bridge> [ddnet] someone want to review #4151? 14:51 <+bridge> [ddnet] https://github.com/ddnet/ddnet/pull/4151 14:51 <+bridge> [ddnet] ah i actually understood it 14:52 <+bridge> [ddnet] just ur naming got me confused whe nu asked it 14:52 <+bridge> [ddnet] b and e 14:52 <+bridge> [ddnet] why not start and end 14:52 <+bridge> [ddnet] well its just me being dumb 14:53 <+bridge> [ddnet] `(size_t)(end-start) >= size` 14:53 <+bridge> [ddnet] ez 14:53 <+bridge> [ddnet] There is also another thing that came up while we discussed this. It is possible that `e-b` don't fit in a `ptrdiff_t` how would you take care of that one? 🙂 14:53 <+bridge> [ddnet] time to search what a ptrdiff_t is 14:54 <+bridge> [ddnet] it's the type of the result of a pointer subtraction 14:54 <+bridge> [ddnet] but it is signed, so it has half the range of size_t 14:54 <+bridge> [ddnet] is it possible that it doesn't fit? I think we said that maximum object size is SSIZE_MAX in C 14:55 <+bridge> [ddnet] ah, ptrdiff_t and ssize_t is different? need to research 😮 14:55 <+bridge> [ddnet] well ptrdiff_t is signed, so even if the two have the same amount of bits one has half the range in positive numbers 14:55 <+bridge> [ddnet] > If an array is so large (greater than PTRDIFF_MAX elements, but less than SIZE_MAX bytes), that the difference between two pointers may not be representable as std::ptrdiff_t, the result of subtracting two such pointers is undefined. 14:55 <+bridge> [ddnet] :monkalaugh: 14:56 <+bridge> [ddnet] 🙂 14:56 <+bridge> [ddnet] (I know it's an insane case btw, it's just fun to language lawyer around 😛 ) 14:57 <+bridge> [ddnet] int_fast64_t 14:57 <+bridge> [ddnet] what does it mean fastest? 14:57 <+bridge> [ddnet] > fastest signed integer type with width of at least 8, 16, 32 and 64 bits respectively 14:57 <+bridge> [ddnet] > (typedef) 14:57 <+bridge> [ddnet] fastest to compute, but ignore them 14:57 <+bridge> [ddnet] fastest for operations like arithmetic, I think 14:57 <+bridge> [ddnet] on linux they just 64bit 14:57 <+bridge> [ddnet] even if 32bit 14:57 <+bridge> [ddnet] ah ok 14:57 <+bridge> [ddnet] or better, 32_t is 64bit i think 14:58 <+bridge> [ddnet] c++ has so many typedefs 14:58 <+bridge> [ddnet] > The designated type is not guaranteed to be fastest for all purposes; if the implementation has no clear grounds for choosing one type over another, it will simply pick some integer type satisfying the signedness and width requirements. 14:58 <+bridge> [ddnet] It's mostly not very useful 15:00 <+bridge> [ddnet] I want a language with good support for fixed point arithmetic pls 15:00 <+bridge> [ddnet] C++ should do fine, I'd think 15:00 <+bridge> [ddnet] you can overload operators 15:00 <+bridge> [ddnet] so the obvious next question is: what operations do you want from the language? 15:01 <+bridge> [ddnet] (that I don't see rn) 15:01 <+bridge> [ddnet] a game engine, would be interesting 😄 15:01 <+bridge> [ddnet] 🙂 15:02 <+bridge> [ddnet] Hm, one could indeed make it quite pretty in C++. It does let you overload a whole lot of things 15:03 <+bridge> [ddnet] I guess with templates you can even allow a lot of different radix positions 15:08 <+bridge> [ddnet] https://docs.rs/fixed/1.10.0/fixed/ 15:09 <+bridge> [ddnet] Ah that is cute 15:10 <+bridge> [ddnet] Now the only thing that remains is begging for fixed point extensions to the instruction sets 15:10 <+bridge> [ddnet] most fixed point operations are just integer operations, plus some shifts 15:10 <+bridge> [ddnet] at least +-*/ are 15:10 <+bridge> [ddnet] division is probs slow 15:11 <+bridge> [ddnet] Oh those are trivial, I was looking for more interesting ones like sqrt 15:11 <+bridge> [ddnet] and maybe a FPSINCOS 15:11 <+bridge> [ddnet] I think they use the taylor expansion because the CPU's version is shit 15:12 <+bridge> [ddnet] Huh, really? 15:13 <+bridge> [ddnet] https://github.com/oss-mirror/glibc/blob/27ae52e4d149fc2dc5ef109426753ad3d5126582/sysdeps/i386/fpu/e_sqrtf.S 15:13 <+bridge> [ddnet] mh, this looks like they use the CPU's version for sqrt 15:14 <+bridge> [ddnet] clang 12 -O3 15:14 <+bridge> [ddnet] https://cdn.discordapp.com/attachments/293493549758939136/887687737241653298/Screenshot_2021-09-15_at_15.13.21.png 15:14 <+bridge> [ddnet] seems like I'm wrong ^^ 15:15 <+bridge> [ddnet] I wonder what the jmp sqrt is for there, it only happens if xmm0 is negative 15:16 <+bridge> [ddnet] correct error handling 15:16 <+bridge> [ddnet] I'd guess 15:17 <+bridge> [ddnet] ah, there is more to floating point errors than just returning -1 😛 15:17 <+bridge> [ddnet] might need to raise an exception and stuff 15:17 <+bridge> [ddnet] set errno 15:17 <+bridge> [ddnet] would all bloat this function 15:17 <+bridge> [ddnet] yep EDOM iirc 15:18 <+bridge> [ddnet] Interesting though, it does notice that one branch is very short and does inline that 15:18 <+bridge> [ddnet] I wonder if that's hardcoded for math functions 15:19 <+bridge> [ddnet] Well I'm not about to dig into clang to find out 🙂 15:19 <+bridge> [ddnet] this message would also be in character without the "not" 15:19 <+bridge> [ddnet] heh, I do like going spelunking but I'm busy today 15:21 <+bridge> [ddnet] actually I'll check glibc now that I'm curious I probably cant think about anything else 15:24 <+bridge> [ddnet] `if (__glibc_unlikely (isless (x, M_LIT (0.0)))) __set_errno (EDOM);` 15:25 <+bridge> [ddnet] Seems the error handling isn't that complex after all? 15:25 <+bridge> [ddnet] hm, so it's the unlikely that causes it not to get inlined? 15:25 <+bridge> [ddnet] or the errno modification? 15:27 <+bridge> [ddnet] let me check if __set_errno is complex 15:27 <+bridge> [ddnet] errno is in thread-local storage, I think 15:28 <+bridge> [ddnet] maybe [gs:4] or so 15:28 <+bridge> [ddnet] so I guess also not complex 15:28 <+bridge> [ddnet] even if unlikely I see no reason not to inline it btw, unless setting errno entails more than just setting erno 15:28 <+bridge> [ddnet] errno* 15:29 <+bridge> [ddnet] ``` 15:29 <+bridge> [ddnet] square(int): 15:29 <+bridge> [ddnet] push rax 15:29 <+bridge> [ddnet] call __errno_location 15:29 <+bridge> [ddnet] mov DWORD PTR [rax], 33 15:29 <+bridge> [ddnet] ``` 15:29 <+bridge> [ddnet] `#define __set_errno(e) (errno = (e))` mh 15:29 <+bridge> [ddnet] what does `push rax` do there? 15:30 <+bridge> [ddnet] yes, but errno is in TLS 15:30 <+bridge> [ddnet] errno is defined as something like `(*__errno_location())` 15:30 <+bridge> [ddnet] probably exactly that 15:31 <+bridge> [ddnet] @nuborn how important is it that the tuning resets shotgun tunings? 15:31 <+bridge> [ddnet] https://github.com/ddnet/ddnet/blame/37caf97bd9c81fab960e1fca4f05921cdd9fde15/src/game/client/gameclient.cpp#L2977 15:31 <+bridge> [ddnet] 15:31 <+bridge> [ddnet] In ddrace the shotgun is a laser anyway, and it currently breaks the vanilla shotgun rendering 15:31 <+bridge> [ddnet] ```extern int *__errno_location (void) __THROW __attribute_const__; 15:31 <+bridge> [ddnet] # define errno (*__errno_location ())``` 15:32 <+bridge> [ddnet] it's important for the shotgun bullets that are spawned by tiles, I think 15:32 <+bridge> [ddnet] those that freeze you and sometimes explode when hitting walls 15:32 <+bridge> [ddnet] are they not simple projectiles? 15:32 <+bridge> [ddnet] but shotgun projectiles? 15:32 <+bridge> [ddnet] i really no idea what ddrace does 15:32 <+bridge> [ddnet] they are shotgun projectiles, to the client, I think 15:34 <+bridge> [ddnet] what is your function body here? 15:34 <+bridge> [ddnet] `errno = EDOM` 15:35 <+bridge> [ddnet] i assume `OnConnect` is not safe enough to request what mod type the server is? 15:36 <+bridge> [ddnet] hm, gcc doesn't do the weird push rax, I wonder what clang is thinking there 15:37 <+bridge> [ddnet] Don't we already have a message reporting server capabilities? You either need to send something there or use an ugly string match since we know the gametype string 15:38 <+bridge> [ddnet] yeah seems to be sent before 15:38 <+bridge> [ddnet] i just want to be sure, so i dont break anything 15:38 <+bridge> [ddnet] RAX is caller saved as far as I'm aware 15:38 <+bridge> [ddnet] you could theoretically add a flag to the server capabilities (bit weird because it's game-specific and those are engine) or to the game flags (but those can change any time during the game and are only available later) 15:38 <+bridge> [ddnet] i'd just not set any ddrace specific tunings if the server isnt ddrace for now 15:39 <+bridge> [ddnet] @Jupstar ✪ what is the problem with the tuning btw? What do you need to handle differently for vanilla? 15:39 <+bridge> [ddnet] not set ddnet-specific custom tuning, i.e. no shotgun spread etc. 15:39 <+bridge> [ddnet] ```c++ 15:39 <+bridge> [ddnet] 15:39 <+bridge> [ddnet] if(m_GameInfo.m_EntitiesDDRace) 15:39 <+bridge> [ddnet] { 15:39 <+bridge> [ddnet] TuningList()[i].Set("gun_curvature", 0); 15:40 <+bridge> [ddnet] TuningList()[i].Set("gun_speed", 1400); 15:40 <+bridge> [ddnet] TuningList()[i].Set("shotgun_curvature", 0); 15:40 <+bridge> [ddnet] TuningList()[i].Set("shotgun_speed", 500); 15:40 <+bridge> [ddnet] TuningList()[i].Set("shotgun_speeddiff", 0); 15:40 <+bridge> [ddnet] } 15:40 <+bridge> [ddnet] ``` 15:40 <+bridge> [ddnet] 15:40 <+bridge> [ddnet] simple patch like this 15:40 <+bridge> [ddnet] eeeeeeeeh piggybacking off a semi related flag :/ 15:40 <+bridge> [ddnet] what? 15:41 <+bridge> [ddnet] Technically `m_GameInfo.m_EntitiesDDRace` doesn't imply anything other than `show ddrace entities` 15:41 <+bridge> [ddnet] mh i guess we also have a better var for that 15:41 <+bridge> [ddnet] Wait, so these tunings don't exist in vanilla? 15:41 <+bridge> [ddnet] ah, look at that 15:41 <+bridge> [ddnet] maybe we can just remove these things on the client side 15:42 <+bridge> [ddnet] we apparently send the tuning params unconditionally on connect? 15:42 <+bridge> [ddnet] The client needs to know them for proper prediction on ddrace, no? 15:42 <+bridge> [ddnet] https://github.com/ddnet/ddnet/blob/37caf97bd9c81fab960e1fca4f05921cdd9fde15/src/game/server/gamecontext.cpp#L2421-L2422 15:43 <+bridge> [ddnet] that would work too, no edge cases? spawning in tune zone or smth 15:44 <+bridge> [ddnet] I actually don't know how tune zones are sent to the client 15:44 <+bridge> [ddnet] Ok, I seriously don't get what's wrong here. I thought these tunes don't exist in vanilla, setting them to their default sounds sane to me 15:45 <+bridge> [ddnet] gun_curvature 15:45 <+bridge> [ddnet] those things exist in vanilla with different defaults 15:45 <+bridge> [ddnet] shotgun and gun have curvature in vanilla 15:45 <+bridge> [ddnet] Ahhh these are ddnet defaults 15:46 <+bridge> [ddnet] Very inefficiently, in `CGameContext::SendTuningParams` 15:46 <+bridge> [ddnet] Ah, you said tune zones, soz 15:47 <+bridge> [ddnet] Well it's still in SendTuningParams 😛 15:47 <+bridge> [ddnet] i could assume they are sent anyways, so vanilla clients dont break or smth xd 15:47 <+bridge> [ddnet] if whoever implemented tune zones thought about it 15:49 <+bridge> [ddnet] I like your optimism 15:49 <+bridge> [ddnet] How about we don't touch tunezone 0 (which is where I think we store the global tunes) when reseting there? 15:50 <+bridge> [ddnet] The server will send the proper tunes when you are ingame (NETMSGTYPE_SV_TUNEPARAMS) and tunezone 0 will become correct 15:50 <+bridge> [ddnet] there's also a different `m_Tuning` variable oO 15:50 <+bridge> [ddnet] what about stopping support for legacy 0.6 kekw 15:50 <+bridge> [ddnet] tune zones are strange anyway, we have so many dublicates in the client prediciton xD 15:51 <+bridge> [ddnet] idc about 0.6 clients, but vanilla 15:51 <+bridge> [ddnet] ah 0.7 15:51 <+bridge> [ddnet] 0.6 vanilla servers 15:51 <+bridge> [ddnet] there is that one person, who uses nightly and is annoyed by vanilla shotgun tuning being wrong xD 15:51 <+bridge> [ddnet] Yeah this was what confused me aswell 15:52 <+bridge> [ddnet] then i don't know what about you are talking here :P 15:52 <+bridge> [ddnet] xD 15:52 <+bridge> [ddnet] I have a feeling that this will get more broken the more we dig into it 15:53 <+bridge> [ddnet] ah! 15:53 <+bridge> [ddnet] there's `m_UseTuneZones` 15:53 <+bridge> [ddnet] this should be false for vanilla 15:53 <+bridge> [ddnet] in this case we seem(?) to ignore the tune zones and use the tuning in `m_Tuning` 15:54 <+bridge> [ddnet] but what populates tunezone 0 if m_UseTuneZones? 15:54 <+bridge> [ddnet] and `m_Tuning` is the default. so where do we get the discrepancy? 15:54 <+bridge> [ddnet] I have the feeling it's executing the map commands to find out 15:54 <+bridge> [ddnet] `m_GameWorld.m_WorldConfig.m_UseTuneZones = m_GameInfo.m_PredictDDRaceTiles;` 15:54 <+bridge> [ddnet] so i can rely on the game info 15:55 <+bridge> [ddnet] yup, looks like it, look for `CGameClient::ConTuneZone` in gameclient.cpp 15:55 <+bridge> [ddnet] Mh, I don't like that there are 50 copies of the tuning in the client :/ 15:55 <+bridge> [ddnet] only 25 😉 15:55 <+bridge> [ddnet] 27 15:56 <+bridge> [ddnet] There is one part of the charactercore, the world seems to keep 2 aswell 15:56 <+bridge> [ddnet] it seems the bug is that the client is looking at tune zones when it should not @Jupstar ✪ 15:57 <+bridge> [ddnet] no tunezone 0 is the global now, tsfreddie changed it, to reduce the amount of tune zone copies xd 15:58 <+bridge> [ddnet] But if `!m_UseTuneZones` tune zone 0 is set to the tunes received from the server 15:59 <+bridge> [ddnet] yeah thats ok too i guess 15:59 <+bridge> [ddnet] i just remove the initial tune zone params 15:59 <+bridge> [ddnet] ^ 15:59 <+bridge> [ddnet] like this 15:59 <+bridge> [ddnet] if its wrong, correct me 15:59 <+bridge> [ddnet] @Learath2 i got a calculation that works now, for the dynamic camera. Just bad, that it wont work when dyndeadzone or dynfollowfactor are non-default :( 15:59 <+bridge> [ddnet] https://github.com/ddnet/ddnet/blob/37caf97bd9c81fab960e1fca4f05921cdd9fde15/src/game/client/gameclient.cpp#L2196 16:00 <+bridge> [ddnet] why does this line exist? 16:00 <+bridge> [ddnet] uhm, I don't think that's correct, is that not too early to check `m_UseTuneZones` 16:00 <+bridge> [ddnet] it shouldn't be changing the world config 16:00 <+bridge> [ddnet] @heinrich5991 well gameinfo can change, e.g. in fokkonauts mod 16:00 <+bridge> [ddnet] but its the only code path that sets the variable 16:01 <+bridge> [ddnet] https://github.com/ddnet/ddnet/commit/f18a47ae30823f3adcedff871d2b454408804d93 16:01 <+bridge> [ddnet] well, this commit looks wrong 16:01 <+bridge> [ddnet] but it only moves it a few lines up 16:02 <+bridge> [ddnet] he probably needed it somewhere else 16:02 <+bridge> [ddnet] ah, I'm looking at this the wrong way, I thought the `m_WorldConfig` object came from the network, nvm 16:03 <+bridge> [ddnet] That is an extremely curious change though. It looks um, useless to me 16:03 <+bridge> [ddnet] it moves it above the `return` 16:03 <+bridge> [ddnet] Ah, hm, well shouldn't the entire thing move above ideally? 16:03 <+bridge> [ddnet] yea 16:04 <+bridge> [ddnet] I'll PR it 16:04 <+bridge> [ddnet] Yeah idk all this stuff is weird, I never touch it because only @nuborn seems to know it all 😛 16:05 <+bridge> [ddnet] and tsfreddie xd 16:06 <+bridge> [ddnet] @Learath2 There is no chance in getting to know about the deadzone or follow factor of a player right= 16:07 <+bridge> [ddnet] right now i need to assume default values, deadzone 300 and followfactor 60 in order to create dyncam zoomed cursor 16:07 <+bridge> [ddnet] which obviously wont work for other values 16:07 <+bridge> [ddnet] @Jupstar ✪ anyway, I think `OnConnected` happens immediately on `CON_READY`, which I think is before the first tunes are sent 16:07 <+bridge> [ddnet] first snap is sent* 16:09 <+bridge> [ddnet] hm, I thought deadzone and ff wouldn't matter at all :/ 16:10 <+bridge> [ddnet] sadly they do 16:12 <+bridge> [ddnet] yea there is no fucking way in getting those values 16:12 <+bridge> [ddnet] also as it seems no hack or smth 16:13 <+bridge> [ddnet] ye I took a look aswell, they do indeed matter and there is no way to get them 16:16 <+bridge> [ddnet] besides reversing the calculation on the server is hardly a good solution anyway, I guess ideally the position of the cursor should be sent relative to the tee 16:16 <+bridge> [ddnet] it is 16:16 <+bridge> [ddnet] but the clientside cursor is not rendered at that exact point 16:16 <+bridge> [ddnet] thats my issue, because i want them to be exactly matching 16:17 <+bridge> [ddnet] which only works in zoom 10 (for any follow factor or deadzone), or with my calculation with any zoom and dycam off or dyncam on and default ff and deadz 16:24 <+bridge> [ddnet] @heinrich5991 not bcs of this pr, but is there no way the gameinfo atleast sets an estimated GameInfo, so entities are shown correctly most of the time, before the first snap comes in 16:24 <+bridge> [ddnet] Client wont show anything until first snap 16:24 <+bridge> [ddnet] client will wait for three snaps, I think, even 16:24 <+bridge> [ddnet] three then, sirry 16:24 <+bridge> [ddnet] but i defs see a change in entities 16:24 <+bridge> [ddnet] so the gameinfo kinda is delayed 16:26 <+bridge> [ddnet] hmmm 16:26 <+bridge> [ddnet] maybe it renders the game before evaluating the snaps? 16:26 <+bridge> [ddnet] possible, i can also only see it on ctf3, ctf5 is too slow or smth 16:29 <+bridge> [ddnet] ah see it when i connect to non EU servers 16:33 <+bridge> [ddnet] can confirm, interesting 16:34 <+bridge> [ddnet] trying to debug it 16:41 <+bridge> [ddnet] huh, that is indeed most interesting, I don't think it could render before evaluating snaps 16:42 <+bridge> [ddnet] it has 2 snaps 16:42 <+bridge> [ddnet] in my 1 min debugging session xd 16:42 <+bridge> [ddnet] 2 snaps? 16:43 <+bridge> [ddnet] 2 snaps received 16:43 <+bridge> [ddnet] could it be that we run out of space in the first few snaps? 16:43 <+bridge> [ddnet] it seems OnRender() is called with IClient::STATE_ONLINE before OnNewSnapshots() is called 16:43 <+bridge> [ddnet] The very silent returns in all the Snap functions would make it invisible if we run out of space in the snaps 16:44 <+bridge> [ddnet] `if(m_ReceivedSnapshots[g_Config.m_ClDummy] >= 3)` 16:44 <+bridge> [ddnet] seems like there is a missmatch 16:45 <+bridge> [ddnet] why does it even wait 2 snaps, so it has a current and previous one? 16:46 <+bridge> [ddnet] 2 is definitely needed as many things expect a prev snap, 3 is probably for things like `prevprevpos` 16:46 <+bridge> [ddnet] teeworlds has so weird design choices, why does the server not just send 2 snapshots or smth xd 16:47 <+bridge> [ddnet] no need to wait 4 ticks 16:47 <+bridge> [ddnet] Um, it's not exactly weird to me tbf, sending 2 snaps instantly would just send identical snaps 16:47 <+bridge> [ddnet] it could store the last 2 16:47 <+bridge> [ddnet] and send them at connect 16:47 <+bridge> [ddnet] so the cleint can directly start 16:47 <+bridge> [ddnet] instead of wasting 80ms xD 16:48 <+bridge> [ddnet] But why? 80ms is absolutely nothing 16:48 <+bridge> [ddnet] depends, plus ping delay for first packages 16:48 <+bridge> [ddnet] tw connecting is not really fast, i'd say 16:48 <+bridge> [ddnet] except for map downloading everything else could be almost instant 16:49 <+bridge> [ddnet] why don't we implement the factorio map rendering stuff? because we currently have simpler code that works, I'd guess 16:49 <+bridge> [ddnet] same here 16:49 <+bridge> [ddnet] Does it need to be fast? We could also remove the loading screen with something like matricks' `bluesky` branch 16:49 <+bridge> [ddnet] mhh is memory bliting really faster than redrawing? 16:50 <+bridge> [ddnet] yes, if I zoom all the way out, it starts to lag 16:50 <+bridge> [ddnet] i made some benchmarks a while ago for android, and the GPU cores were faster 😄 16:50 <+bridge> [ddnet] yeah ok 16:50 <+bridge> [ddnet] is situation dependend 16:50 <+bridge> [ddnet] zooming out is mostly laggy, bcs of teeworlds map extension 16:50 <+bridge> [ddnet] like outside of map is rendered too 16:51 <+bridge> [ddnet] and gpus arent really good in firing up instaces 16:51 <+bridge> [ddnet] and cpus are slow in handling alot of stuff insglethreaded 16:51 <+bridge> [ddnet] Didn't factorio people already bench this? scrolling the old buffer over was an order of magnitude cheaper than going through and rendering the entire screen again iirc 16:52 <+bridge> [ddnet] yeah, but their scene might also be more complex 16:52 <+bridge> [ddnet] https://www.factorio.com/blog/post/fff-333 16:52 <+bridge> [ddnet] doesn't look like this (left side is what they cache) 16:53 <+bridge> [ddnet] doesn't look like it (left side is what they cache) 16:53 <+bridge> [ddnet] Anyway, besides the point, there are indeed some optimisations we can do but I don't think they are worth the pain of introducing new codepaths for the handful of ms they save us 16:53 <+bridge> [ddnet] Like how would you create these 2 older snaps to be sent on connect? Who would they be snapped for? 16:54 <+bridge> [ddnet] old snaps from the server 16:54 <+bridge> [ddnet] saved server side 16:54 <+bridge> [ddnet] snaps are done for specific client IDs 16:54 <+bridge> [ddnet] But we don't send the same snaps to everyone, there is a lot of branching on `SnappingClient` 16:54 <+bridge> [ddnet] but yeah, i just feel like you can always improve, but network is almost impossible anyway, bcs of vanilla compability 16:55 <+bridge> [ddnet] you could snap the entire world like for a demo, does this extremely fat snap still fit? is sending this fat snap over slower connections still faster than waiting for the 2 snaps? 16:56 <+bridge> [ddnet] but it does knwo the client id, doesnt it 16:56 <+bridge> [ddnet] i mean it generates it itself 16:56 <+bridge> [ddnet] i think tune zones arent predicted 16:56 <+bridge> [ddnet] so probs the client dont know about them 16:56 <+bridge> [ddnet] also doesnt actually need to contain anything specific 16:56 <+bridge> [ddnet] They are both predicted by parsing the map and by sending tunes on entering them 16:56 <+bridge> [ddnet] @Ryozuki the client apparently executes the statements from the map, see above 16:56 <+bridge> [ddnet] ah that must be quite new then 16:57 <+bridge> [ddnet] cuz i remember when u spec someone in tune zones it looked weird 16:57 <+bridge> [ddnet] e.g slow grenade 16:57 <+bridge> [ddnet] idk 16:57 <+bridge> [ddnet] but u must be outside the tune zone 16:57 <+bridge> [ddnet] point is that it's not impossible, it's that it's a lot of work for saving a couple dozen ms 16:57 <+bridge> [ddnet] and another player in 16:57 <+bridge> [ddnet] tsfreddie improved stuff tehre 😄 16:58 <+bridge> [ddnet] im junkie# 16:59 <+bridge> [ddnet] Well if you want to optimize that to it's limit the model you should implement is the `bluesky` branch. Maps sent as a group of resources which are asynchronously loaded as they are sent. The loading screen is like instant on there 16:59 <+bridge> [ddnet] do we rly need to optimize it? 16:59 <+bridge> [ddnet] running at 1k fps is enough xd 17:00 <+bridge> [ddnet] "runs fine on my developer machine" 17:00 <+bridge> [ddnet] i think this is more about network 17:00 <+bridge> [ddnet] @Ryozuki not rendering in this case, we were talking about the loading screen 17:00 <+bridge> [ddnet] not a good benchmark 17:00 <+bridge> [ddnet] ah 17:00 <+bridge> [ddnet] if we'd be OGl 3.3 only, i'd also love to implement LED corrected text 17:00 <+bridge> [ddnet] so its sharper when the font size is small 17:00 <+bridge> [ddnet] what's LED? 17:00 <+bridge> [ddnet] @heinrich5991 btw wanna try enabling aio for the next patch on windows? 17:00 <+bridge> [ddnet] RGB 17:01 <+bridge> [ddnet] the LED of your monitor i mean 17:01 <+bridge> [ddnet] ah, the subpixel rendering? 17:01 <+bridge> [ddnet] yea 17:01 <+bridge> [ddnet] oh ye 17:01 <+bridge> [ddnet] i remember when i implemented some text rendering on my own, on certain positions it looked a bit blurred 17:01 <+bridge> [ddnet] but that must be something i made wrong xd 17:01 <+bridge> [ddnet] lets drop unicode support and use msdf for the text, that should get us an extra couple hundred fps 😛 17:02 <+bridge> [ddnet] as a + msdf text looks gorgeous at any scale 17:02 <+bridge> [ddnet] Japan Maritime Self-Defense Force, the Japanese Navy 17:02 <+bridge> [ddnet] https://cdn.discordapp.com/attachments/293493549758939136/887714968403836938/unknown.png 17:02 <+bridge> [ddnet] ? 17:02 <+bridge> [ddnet] xd 17:02 <+bridge> [ddnet] https://github.com/Chlumsky/msdfgen 17:03 <+bridge> [ddnet] oh valve 17:03 <+bridge> [ddnet] https://steamcdn-a.akamaihd.net/apps/valve/2007/SIGGRAPH2007_AlphaTestedMagnification.pdf 17:03 <+bridge> [ddnet] well valve came up with sdf 17:03 <+bridge> [ddnet] but tbf, is there a gain in 2d? 17:03 <+bridge> [ddnet] this guy came up with the idea of generating more than one sdf and shoving it into the other channels 17:04 <+bridge> [ddnet] or are we already thinking about 3d tw, im in xd 17:04 <+bridge> [ddnet] oh definitely, with the amount of text we can have in ddnet on a single screen I'm sure the gpu would blast through it 17:05 <+bridge> [ddnet] (you can render these in shader) 17:05 <+bridge> [ddnet] libreoffice ;~; 17:05 <+bridge> [ddnet] https://cdn.discordapp.com/attachments/293493549758939136/887715830857613362/unknown.png 17:05 <+bridge> [ddnet] not even they can handle text xd 17:06 <+bridge> [ddnet] wdym? 17:06 <+bridge> [ddnet] the selection over the f? 17:06 <+bridge> [ddnet] the f goes outside 17:06 <+bridge> [ddnet] you know who handles text 17:06 <+bridge> [ddnet] LaTeX 17:06 <+bridge> [ddnet] might make sense for selection, letter can overlap 17:06 <+bridge> [ddnet] yeah 17:06 <+bridge> [ddnet] i just noticed it, when i improved our text selection 17:07 <+bridge> [ddnet] and felt releafed 17:07 <+bridge> [ddnet] ah 🙂 17:07 <+bridge> [ddnet] hm, never saw it anywhere on macOS 17:07 <+bridge> [ddnet] https://cdn.discordapp.com/attachments/293493549758939136/887716233380765716/Screenshot_2021-09-15_at_17.06.59.png 17:07 <+bridge> [ddnet] browsers are also good at handling text 🙂 17:08 <+bridge> [ddnet] https://cdn.discordapp.com/attachments/293493549758939136/887716384346349589/unknown.png 17:08 <+bridge> [ddnet] it's surprising how the open source world is so behind all the proprietary magic, CoreText is a beast and it looks very pretty 17:08 <+bridge> [ddnet] can you try with AV, @Learath2 17:08 <+bridge> [ddnet] :monkaS: 17:08 <+bridge> [ddnet] https://cdn.discordapp.com/attachments/293493549758939136/887716552873476146/unknown.png 17:08 <+bridge> [ddnet] eh, discord doesn't do kerning 17:08 <+bridge> [ddnet] the letters "AV" 17:08 <+bridge> [ddnet] Sure, let me check 17:09 <+bridge> [ddnet] If you have a font with heavier kerning I can check that too 17:09 <+bridge> [ddnet] https://cdn.discordapp.com/attachments/293493549758939136/887716829705957466/Screenshot_2021-09-15_at_17.09.13.png 17:09 <+bridge> [ddnet] just select the A there 17:10 <+bridge> [ddnet] :monkaS: 17:10 <+bridge> [ddnet] https://cdn.discordapp.com/attachments/293493549758939136/887717064414986300/unknown.png 17:12 <+bridge> [ddnet] Ah, I see what you mean, though I wonder if one can even argue as to which is correct 17:12 <+bridge> [ddnet] https://cdn.discordapp.com/attachments/293493549758939136/887717392262783066/Screenshot_2021-09-15_at_17.11.06.png 17:12 <+bridge> [ddnet] ^^ I guess libreoffice should select the whole letter if it doesn't intersect with others 17:12 <+bridge> [ddnet] It seems the selection box is just shrinked by the amount of kerning 17:13 <+bridge> [ddnet] well since the kerning is negative in this case, the kerning is just added to the width would be a more correct way to put it 17:15 <+bridge> [ddnet] Things like arabic just completely break this idea of "bounding boxes" btw 😛 17:17 <+bridge> [ddnet] I have a random notepad instance open with a password that has no explanation next to it open... 17:23 <+bridge> [ddnet] latex 17:23 <+bridge> [ddnet] bounding boxes reminds me of https://www.freetype.org/freetype2/docs/glyphs/glyphs-3.html 17:28 <+bridge> [ddnet] i stared at this image rly long when figuring out how to render text 17:28 <+bridge> [ddnet] https://cdn.discordapp.com/attachments/293493549758939136/887721468711014440/metrics.png 17:28 <+bridge> [ddnet] yo we talking typography 17:34 <+bridge> [ddnet] typographygang 17:34 <+bridge> [ddnet] Now look into how to lay arabic glyphs properly and you want to die 😛 17:37 <+bridge> [ddnet] depends on the font ofc, but generally spoken, freetype doesn't give me a perfect size to calculate with, the char advance is smaller than the char width and the char width is too big 17:37 <+bridge> [ddnet] depends on the font ofc, but generally spoken, freetype doesn't give me a perfect size to calculate with, the char advance can be smaller than the char width and the char width is too big 17:38 <+bridge> [ddnet] huh, how is the width too big? 17:38 <+bridge> [ddnet] i dunno, maybe it is some very transparent pixel or smth 17:39 <+bridge> [ddnet] you mean the rect (bearingX, bearingY) x (bearingX + width, bearingY + height) wasn't correct? interesting 17:40 <+bridge> [ddnet] ah and we also have outline ofc 17:40 <+bridge> [ddnet] that destroys everything too xd 17:41 <+bridge> [ddnet] hm, how do we do the outline? if it's thickness is known you just add double that in every direction, if we render a bigger character then just do the bounding box around that? 17:41 <+bridge> [ddnet] i mean i can just say general things as i dont know any details: 17:41 <+bridge> [ddnet] e.g. the size metrics are not reliable and freetype also mentions it 17:42 <+bridge> [ddnet] https://www.freetype.org/freetype2/docs/reference/ft2-base_interface.html#ft_size_metrics 17:42 <+bridge> [ddnet] 17:42 <+bridge> [ddnet] "Note that due to glyph hinting and the selected rendering mode these values are usually not exact; consequently, they must be treated as unreliable with an error margin of at least one pixel!" 17:42 <+bridge> [ddnet] yeah but sadly what i experienced is that the advance can be smaller than what is rendered 17:42 <+bridge> [ddnet] and atleast the breaing does not respect the outline 17:44 <+bridge> [ddnet] well bearingX-outlinewidth would work, no? 17:44 <+bridge> [ddnet] advance + kerning is where the next origin should be, right? 17:44 <+bridge> [ddnet] i mean that the advance doesnt even reach the end of the non outline glyph 17:45 <+bridge> [ddnet] wtf? 17:45 <+bridge> [ddnet] https://cdn.discordapp.com/attachments/293493549758939136/887725942124978197/unknown.png 17:46 <+bridge> [ddnet] i only use the advance here to calculate the selection quad 17:46 <+bridge> [ddnet] i even add the bearing of the next character and its still to less 17:47 <+bridge> [ddnet] the sum of advanceX + 2 * glyph_count * outlinewidth should always be correct imo, so weird 17:47 <+bridge> [ddnet] ah yeah, but i mean that advance is not enough to end after the inner `A` 17:47 <+bridge> [ddnet] that is weird 17:47 <+bridge> [ddnet] it could ofc be improved with the outline, which i didnt use 17:48 <+bridge> [ddnet] but i'd except the selection to atleast end before the inner char end 17:48 <+bridge> [ddnet] s 17:50 <+bridge> [ddnet] mhh but yeah 17:50 <+bridge> [ddnet] maybe you are right 17:50 <+bridge> [ddnet] i should just use the outline than it should fit pretty much 17:50 <+bridge> [ddnet] or i should completly ignore the outline, as it destroys the other math 17:51 <+bridge> [ddnet] hard to say 17:51 <+bridge> [ddnet] you vote @Learath2 17:52 <+bridge> [ddnet] current behavior is like vanilla 0.6 i think 17:53 <+bridge> [ddnet] mhh since i use advance now, i think i could indeed ignore it 17:53 <+bridge> [ddnet] good catch, i was blind for that 18:07 <+bridge> [ddnet] @Jupstar ✪ btw do you know any way to fix the ugly overlapping outline? 18:08 <+bridge> [ddnet] either respecting outline 18:08 <+bridge> [ddnet] https://cdn.discordapp.com/attachments/293493549758939136/887731486768398416/unknown.png 18:08 <+bridge> [ddnet] or use stencil buffer 18:08 <+bridge> [ddnet] bcs stencil best xd 18:08 <+bridge> [ddnet] but ogl 3.3 18:08 <+bridge> [ddnet] ok not 3.3 18:08 <+bridge> [ddnet] but atleast not garantueed in gl 1.x 18:10 <+bridge> [ddnet] @Jupstar ✪ could we maybe ignore the transparency and instead precalculate the color of the outline pixels in advance? 18:10 <+bridge> [ddnet] without transparency the imagine behind won't be respected 18:11 <+bridge> [ddnet] but yeah 18:11 <+bridge> [ddnet] theorectically it would work, dunno how important the transparency is 18:11 <+bridge> [ddnet] in a red background it will ofc look different with transparency 18:12 <+bridge> [ddnet] but before we render the text, we have the background pixels, we could calculate the outline color at all points 18:12 <+bridge> [ddnet] xD 18:13 <+bridge> [ddnet] yeah, but that is even less supported by gl 1.x than stencil i guess 18:13 <+bridge> [ddnet] that would require reading frame buffer 18:13 <+bridge> [ddnet] meh 18:13 <+bridge> [ddnet] well not in a good performance at least, ofc we could go completly crazy and load the current framebuffer and calculate everything on fly 😄 18:14 <+bridge> [ddnet] let me read some 90s text rendering stuff, maybe they have it figured out 18:15 <+bridge> [ddnet] i'd assume most gpus always supported stencil 18:15 <+bridge> [ddnet] i mean its not more special than a zbuffer or smth 18:15 <+bridge> [ddnet] is there no extension we can check for? 18:15 <+bridge> [ddnet] or as you said, no transparency at all 18:16 <+bridge> [ddnet] i think before win7 transparency wasnt a thing so much 18:16 <+bridge> [ddnet] no idea tbh 18:16 <+bridge> [ddnet] probably there is 18:16 <+bridge> [ddnet] but i dunno if the SDL_CreateWindow can fail bcs of this 18:16 <+bridge> [ddnet] since that creates the default frame buffer 18:40 <+bridge> [ddnet] it kinda makes it better, but the annoying outline still annoys xd 18:40 <+bridge> [ddnet] https://cdn.discordapp.com/attachments/293493549758939136/887739609356840980/unknown.png 19:14 <+bridge> [ddnet] @Jupstar ✪\: when make split screen for dummy? 19:16 <+bridge> [ddnet] already made it 19:16 <+bridge> [ddnet] but is horrible, bcs switchting dummy requires OnSnapshot to be called 19:16 <+bridge> [ddnet] ik u made it thats why iping u 19:16 <+bridge> [ddnet] when polish and merge into ddnet 19:17 <+bridge> [ddnet] good question 19:17 <+bridge> [ddnet] i'd say, when someone cleansup everything with [DUMMY_CLIENTS] 19:18 <+bridge> [ddnet] whats the issue with dummy\_clients? 19:19 <+bridge> [ddnet] the network code mostly 19:19 <+bridge> [ddnet] ah true network code is still 0.6 thats bad 19:19 <+bridge> [ddnet] hrhrhrhrhrh 19:19 <+bridge> [ddnet] like using m_CurrentGameInfo 19:19 <+bridge> [ddnet] or whatever all these vars are called 19:19 <+bridge> [ddnet] some are set in OnSnapshot only 19:19 <+bridge> [ddnet] so its hard to get both at the same time or what? 19:20 <+bridge> [ddnet] or get the one from dummy 19:20 <+bridge> [ddnet] i see 19:20 <+bridge> [ddnet] switchting between them per tick is hard 19:24 <+bridge> [ddnet] playing like that must be pain anyways 19:24 <+bridge> [ddnet] i want it mostly for spectating 19:26 <+bridge> [ddnet] https://cdn.discordapp.com/attachments/293493549758939136/851668875400708116/test.mp4 19:26 <+bridge> [ddnet] this was the last try xd 19:27 <+bridge> [ddnet] cool. Would be even nicer to only show the pip when dummy is not on main screen anymore maybe 19:27 <+bridge> [ddnet] yeah and maybe pip for other team members 😄 19:30 <+bridge> [ddnet] oh yeah, that would be sweet too when speedrunning 19:30 <+bridge> [ddnet] What the fuck is with the audio 19:30 <+bridge> [ddnet] onsnapshot generates them i think 19:30 <+bridge> [ddnet] and since its called per frame its quite alot of sound xD 20:03 <+bridge> [ddnet] this was my first thought about this (since that code is only useful for tunezones the player hasn't visited yet), but seems like using the gameinfo may be the cleanest 20:04 <+bridge> [ddnet] If it does arrive in time, sure 20:14 <+bridge> [ddnet] @heinrich5991 could you also reset on connect, that the server sended the message for rcon username login? because when i connect to ddnet, then to my server it asks for a password, but my server doesnt send that 20:14 <+bridge> [ddnet] fresh client restart doesnt ask for username 21:14 <+bridge> [ddnet] https://www.optaplanner.org/blog/2021/09/15/HowMuchFasterIsJava17.html 21:14 <+bridge> [ddnet] tldr 21:15 <+bridge> [ddnet] > 21:15 <+bridge> [ddnet] > 21:15 <+bridge> [ddnet] > Java 17 is 8.66% faster than Java 11 and 2.41% faster than Java 16 for G1GC (default). 21:15 <+bridge> [ddnet] > 21:15 <+bridge> [ddnet] > Java 17 is 6.54% faster than Java 11 and 0.37% faster than Java 16 for ParallelGC. 21:15 <+bridge> [ddnet] :monkalaugh: 21:16 <+bridge> [ddnet] nice, more fps in modded minecraft 21:16 <+bridge> [ddnet] ye 21:16 <+bridge> [ddnet] and actually u can use java 17 on minecraft 1.16+ 21:16 <+bridge> [ddnet] before it was stuck at 11 21:16 <+bridge> [ddnet] and 8 21:17 <+bridge> [ddnet] https://cdn.discordapp.com/attachments/293493549758939136/887779077107359764/unknown.png 21:17 <+bridge> [ddnet] i was rly surprised 21:17 <+bridge> [ddnet] i thought they would have been perma stuck in java 8 21:17 <+bridge> [ddnet] @Jupstar ✪ do you know which server the tuning problem happened at? 21:17 <+bridge> [ddnet] vanilla 21:17 <+bridge> [ddnet] the shotgun bullets 21:18 <+bridge> [ddnet] oh. because I just tested this on a vanilla server, and it looks like the server does send the tunings 21:18 <+bridge> [ddnet] at join 21:18 <+bridge> [ddnet] before OnConnect or what? 21:18 <+bridge> [ddnet] so Im starting to wonder if the problem could be the opposite, that "OnConnected" is somehow called after the tuning msg 21:19 <+bridge> [ddnet] not impossible 😄 21:19 <+bridge> [ddnet] hmm, yeah, never thought about it 21:19 <+bridge> [ddnet] we can also initialize it when connecting 😄 21:20 <+bridge> [ddnet] yeah, the earlier the better it seems:P 21:28 <+bridge> [ddnet] or, no, it doesnt actually happen before OnConnected 21:28 <+bridge> [ddnet] 😮 21:28 <+bridge> [ddnet] but? 21:28 <+bridge> [ddnet] the tune params are wrong or what? 21:28 <+bridge> [ddnet] but my shotgun also worked 21:28 <+bridge> [ddnet] so maybe I was lucky with something 21:28 <+bridge> [ddnet] maybe my network just works different xd 21:29 <+bridge> [ddnet] btw 21:29 <+bridge> [ddnet] oh, so you could reproduce it as well? 21:29 <+bridge> [ddnet] its when you spec someone 21:29 <+bridge> [ddnet] someone shoots, and you spec him 21:29 <+bridge> [ddnet] oh, I see 21:32 <+bridge> [ddnet] @nuborn 138.255.102.160:8241 21:45 <+bridge> [ddnet] @nuborn what is the ddrace packet for tunezones that are not 0 21:45 <+bridge> [ddnet] I dont think we have a separate packet 21:45 <+bridge> [ddnet] the client just gets sent a new tune packet after the player crosses the zone border 21:46 <+bridge> [ddnet] oh 21:46 <+bridge> [ddnet] why do we even have a tunezone list then? 21:46 <+bridge> [ddnet] to keep the tunes for the other zones in memory, so that projectiles and other things still look correct when in a different zone zone 21:47 <+bridge> [ddnet] but how is it filled then 21:47 <+bridge> [ddnet] and it also removes latency from the prediction when crossing to a zone with different gravity, etc 21:47 <+bridge> [ddnet] there has to be some index or smth xd 21:48 <+bridge> [ddnet] in UpdatePrediction (search for things like "m_ExpectingTuningSince") 21:49 <+bridge> [ddnet] i see 21:49 <+bridge> [ddnet] @Jupstar ✪ it's updated from the map, and later from the server when you enter the tune zones, from how I read the code 21:50 <+bridge> [ddnet] ah i see, there also is `m_GameWorld.TuningList()[0] = m_Tuning[g_Config.m_ClDummy];` 21:50 <+bridge> [ddnet] but its not the same tuning list as the one in gameclient xD 21:51 <+bridge> [ddnet] bcs we have so many 21:52 <+bridge> [ddnet] oh, since it only happens in UpdatePrediction, the player will miss it if it's in spec ("if(!m_Snap.m_pLocalCharacter)") 21:53 <+bridge> [ddnet] which I think would happen if the player joins to spec on a vanilla server 21:53 <+bridge> [ddnet] ah thats the problem 21:53 <+bridge> [ddnet] i see 21:53 <+bridge> [ddnet] is that check useful? 21:54 <+bridge> [ddnet] for the rest of the code in that function, yes 21:54 <+bridge> [ddnet] or, I assume at least 21:54 <+bridge> [ddnet] there are only a few `m_pLocalCharacter` 21:54 <+bridge> [ddnet] accesses 21:54 <+bridge> [ddnet] but yeah 21:54 <+bridge> [ddnet] seems like they all need the char pos 21:55 <+bridge> [ddnet] well if you want to fix it i'd be glad, bcs i dont really know that code 21:56 <+bridge> [ddnet] https://github.com/ddnet/ddnet/commit/b1051d23984bed5de37eb5339cd8bd1271213f2b 21:56 <+bridge> [ddnet] this is the blame commit btw 21:58 <+bridge> [ddnet] yes, it was updated by TsFreddie to make the association to the tune zone number more accurate, I believe. before it just looked at the player position from the snapshot 22:00 <+bridge> [ddnet] why isnt the tunezone just always calculated if tunezone index is not 0 for whatever entity and else just use the params the server sends? 22:00 <+bridge> [ddnet] like inside the prediction code or somewhere 22:01 <+bridge> [ddnet] UpdatePredictions is only called by OnNewSnapshot 22:01 <+bridge> [ddnet] 22:01 <+bridge> [ddnet] but the collision index could always be calculated couldnt it 22:01 <+bridge> [ddnet] would make the prediction more accurate 22:02 <+bridge> [ddnet] for the association between the server messsage and the tunezone number? 22:02 <+bridge> [ddnet] we always know the tunezone tiles from the map 22:03 <+bridge> [ddnet] i'd imagine it like this 22:03 <+bridge> [ddnet] 22:03 <+bridge> [ddnet] somewhere in the prediction 22:03 <+bridge> [ddnet] GetTuneCollisionIndex 22:03 <+bridge> [ddnet] Get tune param from that index 22:03 <+bridge> [ddnet] 22:03 <+bridge> [ddnet] Calculate the prediction with these tune params 22:03 <+bridge> [ddnet] yeah, but the map index only gives the tunezone number 22:04 <+bridge> [ddnet] so the server has to send the tunezone params in the end or what 22:04 <+bridge> [ddnet] then we have to look up the m_Tunezones[...] table, that are based on what the server sent 22:04 <+bridge> [ddnet] yes, although on ddnet they are also stored in the map 22:04 <+bridge> [ddnet] ok, but then these paramlist should just be updated everytime a new packet comes in 22:04 <+bridge> [ddnet] i guess its accurate enough still isnt it 22:04 <+bridge> [ddnet] (but its possible to change tunings in rcon afterwards) 22:05 <+bridge> [ddnet] ah you can even change tunings of tune zones? 22:05 <+bridge> [ddnet] that isnt 0 22:05 <+bridge> [ddnet] but well wouldnt change anything 22:05 <+bridge> [ddnet] just keep the list updated with the snapshots 22:05 <+bridge> [ddnet] rest isnt really a problem of the packets but prediction 22:06 <+bridge> [ddnet] that is what is done now, I believe, but we try to update each tunezone individually, based on what tunezone was updated by the server 22:06 <+bridge> [ddnet] yeah i understand that, but the local char isnt really needed for that is it? 22:07 <+bridge> [ddnet] the client enters a new zone -> server sends a tuning msg -> the client needs to figure out what tunezone it was meant for 22:07 <+bridge> [ddnet] ah i see 22:07 <+bridge> [ddnet] yeah 22:07 <+bridge> [ddnet] then rip 22:07 <+bridge> [ddnet] and the only way to figure out the tunezone is to look at the player position 22:08 <+bridge> [ddnet] so there isnt really a server packet telling u what tunezone you looking at 22:08 <+bridge> [ddnet] sounds annoying 22:08 <+bridge> [ddnet] yes, thats part of the problem 22:08 <+bridge> [ddnet] and if `m_GameWorld.TuningList()[0] = m_Tuning[g_Config.m_ClDummy];` is just called even without char(top of the function)? 22:09 <+bridge> [ddnet] in worst case u have that tuning, in best case it gets updated 22:13 <+bridge> [ddnet] yes, moving it to the top looks like it might be safe 22:16 <+bridge> [ddnet] im crying 22:16 <+bridge> [ddnet] wtf 22:16 <+bridge> [ddnet] client can only process 1024 snaps 22:16 <+bridge> [ddnet] per snapshot 22:16 <+bridge> [ddnet] even tho max size is not reached 22:17 <+bridge> [ddnet] https://github.com/ddnet/ddnet/blob/master/src/engine/shared/snapshot.cpp#L234 22:17 <+bridge> [ddnet] this is why 22:17 <+bridge> [ddnet] only this 22:17 <+bridge> [ddnet] then increase it 22:18 <+bridge> [ddnet] https://github.com/ddnet/ddnet/blob/master/src/engine/shared/snapshot.h#L136 22:18 <+bridge> [ddnet] and this ofc 22:18 <+bridge> [ddnet] wouldnt work, its also clientside 22:18 <+bridge> [ddnet] then dont change it 22:18 <+bridge> [ddnet] @Jupstar ✪ oh, I was perhaps thinking of the whole entire block 22:18 <+bridge> [ddnet] why do you even need so many 😄 22:19 <+bridge> [ddnet] what block? 22:19 <+bridge> [ddnet] the above uses the character position 22:19 <+bridge> [ddnet] on my server there are many objetcs :( currently, i have removed the dbg_asserts from snapnewitem, so that too many items/size just gets dropped without crashing the server 22:20 <+bridge> [ddnet] i see too bad 22:21 <+bridge> [ddnet] hmm, yes, but the default to tunezone 0 should perhaps only happen if tunezones are not used, or if the player is in spec/not available 22:21 <+bridge> [ddnet] so just add an if? 22:21 <+bridge> [ddnet] xd 22:22 <+bridge> [ddnet] I think so, just have to think about it for a second 😛 22:22 <+bridge> [ddnet] sure 22:22 <+bridge> [ddnet] i'd have thought it doesnt matter is the players tune index is different anyway 22:23 <+bridge> [ddnet] if its inside a tune zone 22:23 <+bridge> [ddnet] i'd have thought it doesnt matter as the players tune index is different anyway 22:23 <+bridge> [ddnet] oh, it would be for keeping zone 0 correct (and the projectiles in it, etc) when the player is outside it 22:23 <+bridge> [ddnet] ```c++ 22:24 <+bridge> [ddnet] if(!m_GameWorld.m_WorldConfig.m_UseTuneZones) 22:24 <+bridge> [ddnet] m_GameWorld.TuningList()[0] = m_Tuning[g_Config.m_ClDummy]; 22:24 <+bridge> [ddnet] ``` 22:24 <+bridge> [ddnet] 22:24 <+bridge> [ddnet] But this should have the same effect then 22:24 <+bridge> [ddnet] so its desired anyway? xd 22:24 <+bridge> [ddnet] ah i see 22:24 <+bridge> [ddnet] got it wrong way 22:25 <+bridge> [ddnet] it would keep it correct yeah 22:25 <+bridge> [ddnet] true 22:28 <+bridge> [ddnet] yes, this would work 22:30 <+bridge> [ddnet] nais