00:00 <@matricks> dunno
00:00 <@matricks> I've never done any special configuration for my graphics under linux
00:01 < alebrije> or maybe just add the option: <option name="vblank_mode" value="0" />
00:01 < alebrije> (for turning off vsync)
00:04 < alebrije> i'll try the last optino (vsync) and brb
00:14 < alebrije> matricks: does not work, :P
12:15 < ozbitfighter> am curious if that finanical bounty works?
12:21 <@matricks> is there a bounty? :D
12:21 < ozbitfighter> Back in jan feb someone posted a bounty of 2000 to be split amongst coders.
12:22 < ozbitfighter> https://www.teeworlds.com/forum/viewtopic.php?id=10785
12:22 < ozbitfighter> last post though was in march and it's now may.
12:22 <@matricks> I have no idea
12:23 < ozbitfighter> didn't he givee you a few hundred?
12:23 <@matricks> yeah
12:24 < ozbitfighter> gtg curious if anyone knows.
13:25 < ozbitfighter> !logs
13:53 <@matricks> no
17:38 < Siile> hello
17:38 < Siile> a simple question, I'm fixing my framerate dependant bouncy algorithms as u suggested
17:39 < Siile> how do I access tick rate or ticks passed or u-get-the-point from CRenderTools::RenderTee
17:39 < Siile> any ideas?
17:42 < Siile> ah lol, stupid question
17:42 < Siile> shouldn't smoke & code lol
17:43 < Siile> maybe if I had looked the source a bit before asking...
17:58 < Siile> hngg: return Current + ((Dest - Current) * ((Speed^Tfact-(Speed-1.0)^Tfact)/(Speed^Tfact)));
18:15 < BotoX> Rust or Go?
18:15 < heinrich5991> BotoX: depends on what you want
18:15 < heinrich5991> if you want fast python, go for go (pun unintended)
18:15 < BotoX> General opinion
18:16 < heinrich5991> if you want safe c/c++, go for rust
18:16 < heinrich5991> rust!
18:16 <@matricks> I've been fiddling with rust latly
18:16 < BotoX> noticed taht
18:16 < BotoX> *that :s
18:17 < BotoX> Though, I guess rust isn't really "stable" yet
18:17 < heinrich5991> go doesn't really give you control about what you allocate
18:17 <@matricks> BotoX: nope
18:18 < koomi> in fact it's really unstable
18:18 < koomi> if they go through with that &uniq stuff that will be a huge change
18:19 <@matricks> yup
18:19 <@matricks> but they aim for a 1.0 this year, which is good
18:19 <@matricks> it's needed for libaries etc to start form
18:19 < BotoX> hmm, why are variables constant by default
18:19 < BotoX> that seems odd
18:19 < heinrich5991> huh?
18:19 < heinrich5991> that seems sane
18:19 < BotoX> >The let keyword introduces a local variable. Variables are immutable by default.
18:19 < heinrich5991> I never annotated my variables in C++
18:19 <@matricks> yeah, thats the sane alternative
18:20 <@matricks> BotoX: that is a good thing
18:20 < heinrich5991> so the compiler couldn't catch unwanted mutations
18:20 < heinrich5991> that's just like references onst by default
18:20 <@matricks> safe-per-default is the way you wanna go
18:20 < BotoX> hmm, I'm pretty sure most programmers change variables more often
18:20 < BotoX> than they need static ones
18:20 <@matricks> BotoX: I don't
18:20 <@matricks> BotoX: most programmers doesn't mark the variables const, when they really are
18:21 < BotoX> that's another way to look at it, makes sense
18:21 < heinrich5991> BotoX: variables in for loops are automatically mutable
18:21 < heinrich5991> that is about everywhere I need mutable stuff - loops
18:21 <@matricks> 40 let statements in my rust code... 10 let mut statements
18:21 <@matricks> small sample set
18:21 < koomi> matricks: I just hope they take their time and do it right instead of rushing for 1.0
18:21 <@matricks> koomi: yup
18:22 <@matricks> koomi: but at some point you need to stop, let things stabilize and just go for it and not overdesign everything
18:22 <@matricks> and let it flourish for a bit to see what needs to be fixed, stuff that you can't predict
18:22 <@matricks> and then be willing to make the changes needed
18:23 < heinrich5991> the last part is what's hard
18:23 <@matricks> yup
18:23 < heinrich5991> if you want to become a successor of C/C++ you have to be stable
18:23 <@matricks> C++ is being hurt like hell because it's too stable :/
18:23 <@matricks> but yeah
18:24 <@matricks> ARGH!!!@#$!PIOH%TR
18:25 <@matricks> out of pepsi max...
18:25 < koomi> right, backward compatibility is important but also a very tight constraint for further development
18:26 <@matricks> yeah, you need a good transition mechanism..
19:41 < heinrich5991> did you know clang is a drop in replacement for cl too?
19:45  * Pedro__ slaps IceCream__ around a bit with a large fishbot
20:21 < heinrich5991> bad Pedro__
20:21 < Pedro__> ^^
20:59 < alebrije> hi all
20:59 <@matricks> o/
21:00 < alebrije> matricks: did you remember me and my problem?
21:00 <@matricks> yes
21:00 < alebrije> its a driver problem?
21:00 <@matricks> driver/software
21:00 <@matricks> dunno
21:00 < alebrije> :(
21:02 < alebrije> btw, when i play on fullscreen, vsync is on (by default) in my games but when i play on window mode vsync is off, lol
21:07 < alebrije> i will hope 0.7 v dont have this problem, :P
21:46 <@matricks> minus: finally!!!
21:47 <@matricks> minus: i've rendered a wire-frame cube in rust :D
21:47 < EastByte> cool
21:48 <@matricks> always takes for ever to figure out what you have done wrong with the matrices... :/
21:49 < EastByte> what kind of interface did you use?
21:49 < EastByte> sdl?
21:49 <@matricks> sdl2
21:49 < EastByte> ah
21:50 <@minus> matricks: sugoi
21:50 < EastByte> you should publish your rust code on github so I can benefit :D
21:50 <@minus> matrices and opengl, yes
21:51 <@minus> oh, SDL2, nice
21:52 <@minus> SDL2 ,opengl, double buffering and you have a nice setup for software rendering, hurr
21:53 < heinrich5991> minus: mh. triple buffering wuold be nicer
21:54  * minus slaps heinrich5991 with a backbuffer
21:54  * matricks slaps heinrich5991 
21:56 < heinrich5991> what's wrong?
21:57 <@minus> you said something evil
21:57 <@minus> triple buffering doesn't help anything but smoothing the framerate
21:58 <@matricks> and depending on what you do, it should be useless
21:59 <@minus> g-sync's the future!
21:59 < heinrich5991> wasn't triple buffering like the screen and two other buffers
21:59 <@matricks> yes
21:59 < heinrich5991> how is that not useful?
21:59 <@matricks> heinrich5991: adds latency
22:00 < heinrich5991> afaik it removes latency from double buffering
22:00 <@minus> +16ms @ 60fps
22:00 <@minus> no it doesn't
22:00 < heinrich5991> I thought it was like
22:00 <@matricks> heinrich5991: no, you get one more frame behind
22:00 < heinrich5991> render to B
22:00 < heinrich5991> render to C
22:00 < heinrich5991> render to B
22:00 < heinrich5991> screen gets ready
22:00 < heinrich5991> newest frame, B is copied
22:00 < heinrich5991> to A
22:01 < BotoX> >g-sync
22:01 <@matricks> .., thats not how it works
22:01 < BotoX> >not free sync
22:01 < heinrich5991> https://en.wikipedia.org/wiki/Triple_buffering#Triple_buffering
22:01 < heinrich5991> matricks: ^
22:01 <@minus> BotoX: was just an example for shitty proprietary tech
22:01 <@minus> BotoX: better pick the VESA std
22:01 <@matricks> heinrich5991: yes
22:01 < BotoX> ya
22:02 <@minus> free sync is AMD proprietary
22:02 <@matricks> heinrich5991: you can gain (depending on the case) a little bit of gpu power back at the cost of latency
22:02 < heinrich5991> well then you're back at double buffering
22:03 < heinrich5991> with a third buffer
22:03 < BotoX> Isn't AMD using the VESA standarD
22:03 <@minus> BotoX: no, the VESA std is something else
22:03 <@matricks> heinrich5991: huh?
22:03 < heinrich5991> In computer graphics, triple buffering is similar to double buffering but provides a speed improvement. In double buffering the program must wait until the finished drawing is copied or swapped before starting the next drawing. This waiting period could be several milliseconds during which neither buffer can be touched.
22:03 < heinrich5991> In triple buffering the program has two back buffers and can immediately start drawing in the one that is not involved in such copying
22:03 < heinrich5991> .
22:03 <@matricks> heinrich5991: that is not true, but sure
22:04 < heinrich5991> what of that is nto true?
22:04 <@minus> yes, looks like triple buffering makes sense
22:04 < BotoX> erm, looks like FreeSync will be the VESA standard
22:05 <@minus> oO
22:05 <@matricks> heinrich5991: that you have to wait before rendering the next frame
22:05 <@minus> BotoX: dunno, i have my info from heise
22:05 <@minus> superificial info
22:05 < heinrich5991> A is on the screen
22:05 < heinrich5991> B is completely rendered
22:05 < heinrich5991> what do you do until the flip?
22:05 <@minus> matricks: no waiting at all in triple buffering
22:05 < BotoX> http://www.vesa.org/featured-articles/vesa-adds-adaptive-sync-to-popular-displayport-video-standard/
22:05 <@minus> ic
22:05 < BotoX> I guess they took FreeSync and made it Free
22:05 <@matricks> heinrich5991: start building the command buffer
22:06 < BotoX> Since it was in corporation with AMD
22:06 < heinrich5991> ok, so you're one frame behind, right?
22:06 < heinrich5991> even two maybe
22:06 <@matricks> heinrich5991: depending on how you count, but yes
22:06 <@minus> tell me about the outcome of your discussion, gnight :p
22:07 < heinrich5991> good night
22:07 <@matricks> nite minus 
22:07 < heinrich5991> yea. and from the description of the wiki page I get that with triple buffering you don't have these waiting times
22:07 < heinrich5991> as you render as fast as you can (potentially and probably) wasting cpu/gpu cycles
22:07 < Stitch626> heinrich, we know wiki isn't perfect :(
22:08 <@matricks> oh, you mean the case where you can render like 120hz but only show 60hz
22:08 < heinrich5991> Stitch626: dunno how your comment helps here
22:08 < heinrich5991> yes
22:08 < BotoX> heinrich5991: dunno how your comment helps here
22:08 < Stitch626> it doen't help, i only wanted to say that
22:08 < Stitch626> o:
22:08 <@matricks> okey, yes, then triple buffer could reduce the latency, but I wouldn't call that a speed up because you just wasted loads of cycles rendering stuff that isn't even being shown
22:09 <@matricks> and at some point, the gpu or cpu will have to wait, you can't get around that more or less
22:11 < Stitch626> i think you're right matricks, it may help, but it will not kill the waiting time(s) - only reduce (maybe)
22:12 <@matricks> either the cpu will be able to produce more commands then the gpu can keep up with or the gpu will consume faster then the cpu can produce
22:12 <@matricks> one will have to wait at some point
22:14 < heinrich5991> could one try to microschedule the draw process so that it finishes right in time?
22:14 <@matricks> yes, but normally you just feed it as fast as you can with data
22:15 <@matricks> and make a sync point at some place where the cpu waits for the gpu 
22:15 <@matricks> this case is the normal game case where you push the gpu as hard as you can
22:16 <@matricks> and games usually case the resolution depending on how long the frames take to render
22:17 <@matricks> to be able to push them to the limit and keep the framerate when shit goes down :)
22:24 <@matricks> people usually reacts kinda funny when you propose the idea that games scale the resolusion during game play, "it must look so ugly!!" etc :)
22:28 < heinrich5991> :)
22:28 < heinrich5991> how do you even adjust the resolution?
22:28 <@matricks> been a common practice for over 10 years :)
22:28 < heinrich5991> with opengl we even have problems for resizing the windows
22:28 < heinrich5991> *window
22:28 <@matricks> you don't change the resolusion on the screen or so
22:28 <@matricks> you render it to a buffer that you scale to the window later
22:29 <@matricks> and on top of that you draw static stuff like UI that would look horrible if it scaled
22:29 < heinrich5991> ah
22:29 < heinrich5991> =)
22:29 < heinrich5991> that's why noone notices
22:29 <@matricks> because we are tricky with it
22:30 <@matricks> and it usually kicks in in FPS games when there is grenades going off kicking up dust etc and the screen just becomes a blurry mess either way so
22:30 <@matricks> there is other tricks as well with regards to that
22:31 <@matricks> like quarter alpha, you render all your alpha blended surfaces at a quarter of the resolusion
22:31 < heinrich5991> why render something hard as smoke if you can't anyway?
22:31 <@matricks> because smoke exists
22:49 < deen> alebrije: use xvattr to set XV_VSYNC to 0
23:05 < alebrije> deen: i did a file called /etc/X11/xorg.conf.d/20-radeon.conf and use it the Option "SwapbuffersWait" "off" for turning off the vsync on the Radeon driver.
23:05 < deen> Ah yeah, and that too
23:05 < deen> I remembered it was some weird stuff with radeon driver, but not exactly what
23:08 < alebrije> another option who someone tolde yesterday here is using `driconf` but i dont see any oprtion for vsync and i edited the file ~/.drirc tu put something like v_blank off (dont remember) but does not work.
23:08 < deen> it only works in combination with swapbufferswait
23:09 <@matricks> try turning off the compositor
23:09 < deen> even without a compositor iirc
23:09 < deen> alebrije: so does it work now?
23:12 < alebrije> on Fullscreen, we can get more fps (turning of vsync on 20-radeon.conf and in games). With Teeworlds the lag (for chatconsole and server messages) is less noticeable, but my other games give me some kind of lag now. >.<
23:13 < alebrije> lol we, i mean *i
23:14 < alebrije> its weird
23:15 < deen> alebrije: never noticed that
23:16 < alebrije> deen: the lag for chat console and server messages?
23:17 < deen> chatconsole always dropped my fps by 50%, server messages and other games were fine
23:17 < alebrije> On ubuntu 12.04 and Catalyst driver, No Problems.
23:18 < alebrije> Now, with Ubuntu 14.04 and free driver, Teeworls is the only problem (until now)
23:19 < alebrije> :(
23:19 < deen> What kind of problem did you have before the vsync?
23:21 < alebrije> vsync is not the problem. The problem is the lag or spikes lag when someone chat or i get server messages (some one join, leave, etc).
23:21 < deen> Aaah, I had them sometimes too, especially when someone with weird characters in name joins
23:22 < deen> do you have it on all messages?
23:22 < alebrije> yep
23:22 < deen> did you try gfx_finish 0?
23:22 < alebrije> yep
23:22 < deen> gfx_threaded, gfx_asyncrender?
23:22 < alebrije> gfx_threaded, yep
23:23 < alebrije> the other one, nope
23:26 < alebrije> but if eneable asyncreander should be eneable too all threaded options?
23:26 < deen> all? i thought there is only gfx_threaded
23:27 < alebrije> gfx_threaded, and sound
23:27 < deen> Ah, it could also be related to sound!
23:28 < deen> yeah, try that on 1 too
23:28 < alebrije> and eventthreaded, :P
23:38 < alebrije> same thing, >.<
23:38 < deen> then I'm out of ideas =/
23:39 < alebrije> lol