12:32 < Learath2> Hello people of #teeworlds, I'm here to bless you with technology from the future, libcurl. However it'd be best if we could get the engine jobs revamp along with it. Thus it is time I inquire once more about allowing a little more C++11 in our codebase
12:32 < Learath2> shared_ptr's are perfect for this and they can't be zero overhead without language support, ofc we can refcount on our own, but not reinventing the wheel and all
13:11 < bridge> [teeworlds] <redix> i agree that the engine jobs should get reworked, but what about just using the non-blocking libcurl api?
13:17 < bridge> [teeworlds] <jxsl13> C++11 WOHOOOOOOO
13:17 < bridge> [teeworlds] <jxsl13> !!!!
13:17 < bridge> [teeworlds] <jxsl13> send code
13:18 < bridge> [teeworlds] <fokkonaut> https://github.com/fokkonaut/F-Client/commit/d14f4f07711678903cb172b79bb729db5523937d
13:32 < Dune> Learath2: you want to add a libcurl dependency in Teeworlds?
13:49 < minus> refcounting doesn't sound like a huge deal to implement
13:55 < bridge> [teeworlds] <heinrich5991> minus: in the face of threads?
13:55 < bridge> [teeworlds] <heinrich5991> we need c++11 support for proper atomics though to implement them
13:56 < bridge> [teeworlds] <heinrich5991> @redix truly nonblocking libcurl isn't reliably available due to dns lookups
14:03 < Learath2> minus: Sure but why bother when it's already a language feature? I'm sure the people who implement the standard for compilers have a better testing suite and code review standards then us
14:03 < bridge> [teeworlds] <jxsl13> open a c++11 proposal issue, stop starting an obsolete conversation again like last time 😄
14:04 < Learath2> You really are a buzzkill
14:04 < bridge> [teeworlds] <jxsl13> the arguments are the same, each time
14:04 < bridge> [teeworlds] <jxsl13> and nothing seems to move forward
14:04 < Learath2> Maybe we should port teeworlds to x86 assembly, you know these newfangled languages are too much
14:05 < bridge> [teeworlds] <jxsl13> even dune seemed to agree at some point that c++11 is fine. who else needs to be convinced?
14:05 < bridge> [teeworlds] <jxsl13> oy?
14:05 < bridge> [teeworlds] <heinrich5991> oy
14:05 < bridge> [teeworlds] <jxsl13> open an issue 😄
14:06 < Dune> @jxsl13 I don't think moving Teeworlds to C++11 is a good idea
14:06 < Dune> I recognize it is a controversial topic with many valid arguments on both sides, but I don't remember saying that it is "fine"
14:07 < Dune> I personally think it will do more harm than good
14:07 < bridge> [teeworlds] <jxsl13> ._. I'm not gonna look through the logs for that.
14:08 < bridge> [teeworlds] <jxsl13> Dune needs to be convinced again, attacc!
14:08 < bridge> [teeworlds] <jxsl13> (or open an issue)
14:11 < Dune> iirc sharedptr is like 10 lines to implement. heinrich5991 seems to say there is some overhead without c++11 features though :)
14:16 < bridge> [teeworlds] <heinrich5991> correctly implementing `shared_ptr` is hard
14:16 < bridge> [teeworlds] <heinrich5991> it's a synchronization feature
14:16 < bridge> [teeworlds] <heinrich5991> Dune: was it just auto you were worried about?
14:17 < bridge> [teeworlds] <heinrich5991> what if I find a way to lint against auto so that people adding auto to the codebase get a failed build?
14:19 < Dune> lambdas etc. c++11 seems to push people to introduce unnecessary levels of abstraction. I agree that it would be fine if we had strict code guidelines, and it is only in the absence thereof that I personally prefer c++03
14:19 < Dune> it would be silly to have a bot just for my personal likings though ;)  
14:19 < bridge> [teeworlds] <heinrich5991> lambdas make code faster, but we can lint against them, too
14:20 < Dune> well-used lambdas are good yeah. kinda like gotos, yet we don't allow gotos
14:21 < bridge> [teeworlds] <heinrich5991> comparing lambdas to gotos is… every modern language has lambdas, but I don't think I know any that has gotos
14:21 < bridge> [teeworlds] <heinrich5991> this is a false comparison IMO
14:21 < Learath2> Which I think is equally unwise, but that's another discussion
14:21 < Dune> I'm not hardcore against it though, if everyone else is for it, I'll just go with it :)  I was only answering because jxsl13 seemed to implied I was for it
14:21 < Dune> Learath2: I liked your goto, yeah
14:22 < Dune> I like that Teeworlds uses abstractions very sparingly and I think it has deserved it a lot
14:22 < Dune> served* (?)
14:31 < Learath2> served in what way? It's not terribly easy to read the teeworlds code, nor is teeworlds very performant
14:32 < Dune> code simplicity and readability. You feel like the code is complex/hard to read?
14:33 < Dune> (of course, I'm biased because I'm familiar with it)
14:33 < Learath2> I don't but I've been looking at it for 10 years, it's trivial to navigate around for me, a lot of people start out, implement a chat command or two, see the rest of the code with 0 documentation and bail
14:34 < Dune> The lack of documentation is an issue but unrelated to the code, right?
14:34 < Learath2> The lack of documentation wouldn't be much of an issue if the code was really readable though
14:35 < bridge> [teeworlds] <jxsl13> xD I feel the code complexity
14:35 < bridge> [teeworlds] <jxsl13> it has gotten way better in 0.7
14:35 < Learath2> Start from where you get the input in CControl and try to follow it through to CCharacter on the server, it's not trivial to read any of that code
14:36 < bridge> [teeworlds] <jxsl13> I have been looking at the code for 12 years and have started to touch it rather recently.
14:36 < bridge> [teeworlds] <jxsl13> *rubs hands, as Dune slowly changed his view*
14:38 < Learath2> Or having to implement a linked list whenever you want one, don't get me wrong, my language of choice is C and I'm very well acquainted with implementing linked lists but many new programmers don't learn how to even work without these abstractions that hide away the details
14:38 < rand> I had some hard time going from src/game to src/engine then back to src/game, then looking for a definition to finally get that it was a generated file…
14:40 < rand> then, controls, snap, DirectInput, PredictedInput
14:41 < Learath2> Then one asks the question what is predicted input what is direct input, which sounds like a simple question but how would the server know what was predicted what was direct input
14:42 < Learath2> Anyways, tw code isn't very unreadable, but it's not self-documenting either
15:12 < Learath2> There is something wrong with gfx resolution, if you set it and restart it will just not respect it and set it to the desktop size
15:15 < Dune> never had that issue Learath2, OS?
15:15 < Dune> OSX?
15:15 < Learath2> macOS yep
15:15 < Learath2> in windowed mode
15:19 < Learath2> backend_sdl.cpp:L701 is responsible for it
15:20 < Dune> yeah https://github.com/teeworlds/teeworlds/issues/1659 is a big pita :/
15:20 < Dune> https://github.com/teeworlds/teeworlds/commit/b81e29535053eb55ace213b8da5fc421def90fac
15:26 < Learath2> I don't think you need to force the desktop resolution when rendering windowed
15:29 < Learath2> changing gfx_fullscreen also kills the game on macOS :P
15:31 < Dune> can't really try any fixes without a mac :/
15:45 < Learath2> if only I could link to the version of sdl I built myself
16:48 < Learath2> it's an SDL bug with OpenGL being deprecated on macOS
16:48 < Learath2> brilliant
18:33 < Learath2> Okay I managed to diagnose the problem and I'm kinda stuck, only the main thread seems to be allowed to call [NSOpenGLContext update] which needs to be called whenever the window moves, [NSOpenGLContext update] is only ever called when an update is scheduled through [SDLOpenGLContext scheduleUpdate] which happens when we are setting the current window or when the window moves/gets resized/etc.
18:33 < Learath2> However when we now swap after the window moves we cause an [SDLOpenGLContext updateIfNeeded] which causes a [NSOpenGLContext update] outside of the main thread
18:33 < Learath2> Which is not allowed
19:00 < Dune> so this is an SDL issue
19:00 < Dune> it is calling [NSOpenGLContext update] outside of the main thread, and there is nothing we can do about that?
19:11 < Learath2> Dune: Apparently we should be rendering on the thread that we create the window and context on, that's what SDL says it supports, but I don't quite see how that helps, given [NSOpenGLContext update] uses pthread_main_np
19:14 < bridge> [teeworlds] <Dune> I don't know what pthread_main_np does
19:17 < Learath2> returns 1 if the calling thread is the initial thread
19:18 < Learath2> huh, who wrote the code to make gfx threaded anyway? everyone and their mothers seem to warn about creating the context and window on different threads being illegal
20:06 < bridge> [teeworlds] <redix> Matricks wrote it: https://github.com/teeworlds/teeworlds/pull/912
20:15 < bridge> [teeworlds] <redix> @heinrich5991 true, forgot about the dns thing =\
22:17 < Learath2> After extensive digging I have concluded that calling SDL_GL_SwapWindow outside the main thread is not legal on OSX. You can do all the GL you want on a separate thread but SDL doesn't seem to like being split off to other threads
22:24 < bridge> [teeworlds] <redix> SDL_GL_SwapWindow is the main reason why the rendering was moved to another thread at all. In the main thread it causes input latency, since the call blocks when vsync is enabled.
22:28 < Dune> so we need communication between the threads or?
22:57 < Learath2> Well OSX doesn't allow it, however I noticed prebuilt ddnet binaries worked fine for me, after further digging I found a weird symbol called `sNSOpenGLContextSuppressThreadAssertionsComputedValue` which skips the main thread check on those binaries
22:58 < Learath2> no idea what it's computed off of yet as reading objective c disassembly is a tedious process
23:04 < Dune> this looks painful
23:10 < Learath2> osx either works very easily, or never works
23:21 < Learath2> okay, if you link on an old enough version of osx it'll work