00:25 < pata> Hey guys
00:26 < pata> May I ask, how you are generating the update.json ?
00:59 <@deen> pata: hi
00:59 <@deen> with a text editor
01:00 <@deen> but I guess it could be automated if one wants to do that
01:00 <@deen> by diffing between the two releases in question
01:04 <@deen> pata: why do you ask?
02:06 < pata> I am working on a project which should include automatic updates. I used the DDNet Mechanism as an example and I was wondering if I should keep the file-structure ;)
02:10 < pata> I think of just comparing tags or commits using the github api. But for only a few files that have changed, this would not reduce the time much, I fear.
02:12 < pata> I will get back to you, if I got any news. cu
14:34 < kamillentee> deen do you still provide the first try of sdl2 somewhere as shown here https://forum.ddnet.tw/viewtopic.php?f=5&t=2128
14:34 < kamillentee> wanna try something
14:37 < kamillentee> ok found old sources with sdl2-try2 do you have sdl2-try3 too
14:52 < kamillentee> well new client fixed lags on 2 of my clients, still lagging on one. So I compiled a client with one of the first tries with sdl2 (pretty old though, ddnet 2.19). And its supersmooth, minimzing is without a delay startup very fast, its even faster than than the new sdl2 clients 
14:53 < kamillentee> dunno what has changed there
18:00 <@deen> kamillentee: me neither. you can check with teeworlds master branch (0.7)
18:00 <@deen> I took quite a few fixes from there
18:00 <@deen> if you can figure out why, I'd appreciate it
18:01 <@deen> Here I started merging swick's SDL2 branch into DDNet, the following commits try to fix bugs. maybe a bisect can help: db8a126315de1657253917b861b51306da9e3a53
18:02 <@deen> (it's possible the first few don't even compile)
18:15 <@deen> kamillentee: you could also try f1, gfx_quad_as_triangle 0
18:18 < kamillentee> deen I know about that command
18:18 < kamillentee> did not help here
18:18 < kamillentee> but tankyou for the first advices
18:18 < kamillentee> +h
18:19 <@deen> Maybe it was some other change in the code that changed the performance, nothing sdl2 related
18:19 < kamillentee> well its well playable even in 9.1 
18:19 < kamillentee> or 9.2
18:19 <@deen> ah, ok
18:20 <@deen> so it's the SDL2 change, ok
18:20 < kamillentee> yes 
18:26 < kamillentee> ok i found sdl2-try3 somewhere and tested it, already lagging. But sdl2-try2 is perfectly fine
18:27 < kamillentee> somewhere between the versions there are changes thats make the client lagging
18:27 < kamillentee> still sdl2-try3 is way faster with startup and minimizing than further versions
18:33 <@deen> for me startup is always very fast (and I have no minimize). the only things I know that makes startup slow are many skins and texture compression
18:34 < kamillentee> I mean the minimize command in f1
18:34 <@deen> yeah, that does nothing when your WM doesn't know about minimizing windows :P
18:35 < kamillentee> ok could not live with such a setting :P
18:35 <@deen> ah, another possibility is that it's because we force threaded and asyncrender now
18:35 <@deen> I have 20 virtual screens, so it's no problem
18:36 <@deen> some old systems really didn't like gfx_threaded
18:36 <@deen> and gfx_asyncrender_old
18:36 < kamillentee> ye I have this problems on a rather old system, the newer ones dont have such problems
18:37 <@deen> maybe on that old system try gfx_threaded_old 1 and gfx_asyncrender_old 1
18:37 <@deen> and what's old for you?
18:37 <@deen> (I mean, try it with the try2 version and see if it also becomes slow)
18:38 < kamillentee> core 2 duo, dunno much about that system
18:38 <@deen> that's not old for me, i don't have a system newer than that :P
18:39 <@deen> single-core p4 machines had problems i think
18:39 < kamillentee> I know :p cause had one 3 years ago, I sometimes used it
18:40 <@deen> it might also rather depend on the graphics card
18:40 <@deen> old amd cards apparently don't like some of the sdl2 stuff
18:40 <@deen> (or their drivers)
18:41 < kamillentee> that might be another small problem (not important here) I have with an amd graka
18:41 <@deen> afk
19:38 <@deen> anyone want to figure out how to make dpi scaling work with Windows >= 8.1 and Mac OS X?
19:38 <@deen> I've tried to work on it, but don't have a machine to test it
19:41 < ddnet-commits> [ddnet] def- pushed 2 new commits to master: https://git.io/vwj31
19:41 < ddnet-commits> ddnet/master f3a4069 def: Set gfx_highdpi to 0 as default (needs someone to fix it on Win >= 8.1 and Mac)
19:41 < ddnet-commits> ddnet/master 37e822b def: Version 10.0.2
20:21 < laxa> does ddnet has nightly-build from trunk ?
20:21 < laxa> *has/have
20:22 < laxa> Well, doesn't look like it
20:48 <@deen> laxa: we had, i removed them because of lack of development
20:48 <@deen> I could run them, it's just a disabled crontab
20:49 < laxa> it's not for me
20:49 < laxa> but Skeptar was pming me to build the latest trunk
20:50 <@deen> well, it's released now :P
20:50 < laxa> :)
20:50 < Skeptar> noo
21:30 < kamillentee> db8a126315de1 is lagging, the commit right before not. Guess that does not help much, but I dont have much time to test more
21:31 < Learath2> db8a126315de1 is the merge sdl2 commit
21:32 < kamillentee> I know
21:32 < Learath2> so sdl2 is lagging ?
21:33 < kamillentee> yes it seems like that, even if sdl2-try2 did not lag back then
21:35 < kamillentee> btw when do the logs usually update here https://ddnet.tw/irclogs/
21:42 <@deen> kamillentee: at midnight
21:42 <@deen> kamillentee: next step would be a diff between sdl2-try2 and db8a126315de1
21:54 < kamillentee> Just wondering because last log file is from friday (empty)