Minetest logo

IRC log for #minetest-dev, 2015-02-08

| Channels | #minetest-dev index | Today | | Google Search | Plaintext

All times shown according to UTC.

Time Nick Message
00:12 acerspyro joined #minetest-dev
00:24 shadowzone_ joined #minetest-dev
00:53 jin_xi joined #minetest-dev
01:18 luizrpgluiz joined #minetest-dev
01:51 luizrpgluiz left #minetest-dev
02:13 Player_2 joined #minetest-dev
02:17 luizrpgluiz joined #minetest-dev
02:19 luizrpgluiz hi
02:27 Player_2 joined #minetest-dev
02:28 Wayward_One joined #minetest-dev
02:29 luizrpgluiz left #minetest-dev
02:43 Kalabasa joined #minetest-dev
02:44 proller joined #minetest-dev
03:27 paramat joined #minetest-dev
03:30 Miner_48er joined #minetest-dev
03:32 paramat a simple mapgen PR ready for merge #2267
03:32 ShadowBot https://github.com/minetest/minetest/issues/2267 -- Mgv7: Limit mountain height to positive only by paramat
03:47 hmmmm hrmm
03:47 hmmmm i'm not sure what that does in practice
03:48 hmmmm VanessaE, are you around?
03:57 paramat no problem it can wait until after release. its more to allow clever floatland-area usage in future with custom noiseparams
03:59 est31 dunno, but hasnt c55 said that there should be a release branch now?
03:59 est31 if there is, then please consider merging #2225, read the last comment.
03:59 hmmmm if we can get a release out in a day or so it shouldn't matter
03:59 ShadowBot https://github.com/minetest/minetest/issues/2225 -- Fixes for minetest.get_(all_)craft_recipe(s) by gregorycu
04:01 hmmmm hrmm?  what do you mean by "there is no functional requirement"?
04:04 FR^3 joined #minetest-dev
04:04 FR^3 joined #minetest-dev
04:15 FR^3 joined #minetest-dev
04:25 FR^3 joined #minetest-dev
04:33 hmmmm est31:  I would be willing to merge that but I'm not really sure what you mean by the last comment in the PR
04:34 est31 the label by shadowninja
04:34 est31 so if you merge it it can be that you get a merge conflict I'm not sure
04:35 est31 because two commits edited the same file
05:03 paramat =D http://i.imgur.com/8NPApq4.png i emulated mudflow by only placing a biome node if supported by all 9 nodes below
05:09 hmmmm joined #minetest-dev
05:17 selat joined #minetest-dev
05:43 hmmmm est31, but the commit it conflicts with also seems to 'fix' the get_craft_recipies api
05:43 est31 #222 gets also fixed by the PR
05:43 ShadowBot https://github.com/minetest/minetest/issues/222 -- Non-ascii key crashes the game
05:43 est31 hmmmm see the first message
05:44 est31 comment*
05:44 est31 and not 222 but 2222
05:44 est31 :)
05:46 hmmmm https://github.com/minetest/minetes​t/issues/2222#issuecomment-71860311    ??
05:54 hmmmm eh... 2222 is fixed by the same commit that's already there
05:55 hmmmm i'm looking at the actual code in 2225 and it's pretty wonky
05:55 hmmmm why would i merge 2225 when all the craft recipe functions are already fixed as of HEAD?
06:06 Megaf_ joined #minetest-dev
06:18 paramat left #minetest-dev
06:19 est31 hmmmm:  ah understood you wrongly, its to fix #2210
06:19 ShadowBot https://github.com/minetest/minetest/issues/2210 -- getCraftRecipes implementation is very slow
06:19 est31 yoll find a lua example there with realistic dreambuilder conditions
06:32 gregorycu joined #minetest-dev
06:33 gregorycu How are we all
06:33 gregorycu So, I'm looking at the render loop, and half(!) the time is spent setting up the shaders
06:33 gregorycu That seems pretty crap, to be honest
06:34 hmmmm setting up the shaders?
06:34 hmmmm like what do you mean
06:34 gregorycu setPixelShaderConstant etc/
06:34 gregorycu GameGlobalShaderConstantSetter::onSetConstants
06:35 gregorycu The interesting this is that the values are cached on the GPU, and a lot of the time we send the same value that we sent last time
06:36 hmmmm the gpu transfer is the thing taking most of the time??
06:36 gregorycu Well... half of the time
06:36 gregorycu Half of the render loop
06:36 hmmmm that's quite incredible
06:37 gregorycu I've just done another perf run with latest code, I'll post a screenie somewhere
06:38 hmmmm so... just cache the values and don't call setPixelShaderConstant if it's equal to the last set value?
06:38 gregorycu Yes
06:39 gregorycu That would be an effective way of doing it
06:39 hmmmm i also see a g_settings->getBool("enable_fog")
06:39 gregorycu You could probably be a little smarter, some shader settings hinge of game settings
06:39 hmmmm sorry... haven't been keeping up with what's going on in minetest, what is the current state of your 'cache fog setting' patch?
06:39 gregorycu Yes
06:40 hmmmm has that been completely merged?
06:40 hmmmm as i recall, there was a deadlock issue under pthread platforms
06:41 gregorycu_ joined #minetest-dev
06:41 gregorycu_ I have really shit internet at the moment
06:41 gregorycu_ Yeah, that was fixed
06:42 gregorycu_ I omitted a line when I rebased (by accident)
06:42 gregorycu_ Basically the line that I missed was the one that changes g_settings->getBool("enable_fog") to m_enableFog
06:42 hmmmm hrmm
06:43 gregorycu__ joined #minetest-dev
06:44 gregorycu Oh, Zeno fixed that
06:44 est31 what
06:44 hmmmm if I recall, you were complaining about not using C++11 for its mutex operations
06:45 hmmmm specifically because of inconsistent behavior between recursive mutexes
06:45 gregorycu This is a sore topic for some
06:45 hmmmm i just looked at jmutex for windows and it uses critical sections, which aren't recursive... what's up with that then?
06:45 hmmmm i don't get how that's possible
06:45 gregorycu I believe they are recursive...
06:45 hmmmm critical sections i thought not
06:46 gregorycu Um... just by the way, this is not an issue anymore
06:46 gregorycu I mean, it's good for an academic discussion, but it doesn't matter with regards to minetest
06:46 hmmmm sure, i was just saying that it'd be weird and indicative of another problem if I'm correct about critical sections
06:47 hmmmm ahh nevermind, it seems like it is
06:47 gregorycu Cool
06:47 gregorycu Anyway, Zeno pulled my rebase fix, which was a one-liner
06:48 gregorycu I know he is doubtful, but it does give a perf improvement
06:48 hmmmm what is it
06:49 gregorycu Bear with me for 2 minutes, and I'll get a screenshot
06:50 gregorycu It's 8% by the way, but one moment
06:51 gregorycu Are you familiar with sampling profiling?
06:51 hmmmm not that term... no.. do you mean looking at massif output?
06:52 gregorycu I don't know what massif is
06:52 hmmmm errm
06:52 hmmmm i meant to say callgrind
06:52 gregorycu No
06:53 gregorycu There are two ways to profile, instrumentation (which is used by callgrind) and sampling
06:53 gregorycu Sampling just looks at the callstack of the application every "so often"
06:53 hmmmm ahhh
06:53 hmmmm that sounds prone to errorneous results
06:53 gregorycu "so often" is a small amount of time
06:54 gregorycu So you get thousands of samples
06:54 est31 third way is to edit the code
06:54 gregorycu Editing the code is what instrumentation effectively does
06:54 est31 aha interesting
06:55 gregorycu I'm pretty sure, anyway
06:56 gregorycu So, at the end of the day, with sampling, you effectively get a an analysis of where the app spends most of its time
06:56 hmmmm so anyway, you used this instead of instrumentation I suppose?
06:56 gregorycu Yes
06:56 gregorycu Where can I upload a pic?
06:56 hmmmm you need a very large number of samples in order to get effective data
06:56 hmmmm imgur.com?
06:56 hmmmm 1000 samples isn't going to cut it
06:57 gregorycu With the latest run I had 16.7k samples
06:57 gregorycu More samples, the better, but I get quite consistant results
06:58 gregorycu http://i.imgur.com/ULOyZdY.png
06:58 hmmmm ahh this is visual studio's profiler
06:58 gregorycu Yes
06:59 gregorycu So, what that shows is that 2.64% of the applications time was spent inside Settings::getBool
06:59 gregorycu 34.85% of the time was spent inside ClientMap::renderMap
07:00 hmmmm well renderMap is pretty heavyweight and it's hard to change
07:00 gregorycu That's fine
07:00 gregorycu The thing is, Settings::getBool makes up a portion of that time
07:00 gregorycu It's a tree
07:00 hmmmm it iterates through all of the sectors, culls out ones not in the view frustrum, then does some sort of broken occlusion culling, etc.
07:01 hmmmm yeah am aware
07:01 hmmmm i thought we discussed optimizing settings before?
07:01 gregorycu We are
07:01 gregorycu So yeah, doing the maths, 2.64 / 34.85 ~= 7.5%
07:02 gregorycu Settings::getBool is about 7.5% of the render time
07:02 gregorycu Where "render time" is how long the app spends in renderMap
07:02 gregorycu Follow what I mean?
07:03 hmmmm yes
07:03 gregorycu Cool
07:03 gregorycu Anyway, I was looking at the code that sets up the shaders
07:03 gregorycu ShaderCallback::OnSetConstants
07:04 gregorycu 16.82% of the application time, or 48% of the time spent in renderMap
07:05 gregorycu This is not good
07:06 gregorycu Anyway, I'd love it if someone on linux could back up these figures
07:06 hmmmm right, I thought we established this about 31 minutes ago
07:06 hmmmm oh
07:06 hmmmm sorry, I'm not on linux
07:06 * est31 is
07:06 est31 what to download/execute whatever?
07:07 gregorycu I said this stuff 31 minutes ago, but I didn't have the data visible to you guys
07:08 gregorycu Honestly est31, I am not sure what tools you need to run to get this data
07:08 gregorycu But yeah, master would be good enough, I just need ballpark, to discount some severe problem on my system
07:09 hmmmm what's *wrong* with callgrind though?
07:09 est31 gonna try that
07:10 * est31 builds MT without luajit
07:10 gregorycu I was under the impression that callgrind does instrumentation, which is destructive
07:11 hmmmm obviously it removes its own overhead out of the equation
07:12 gregorycu Cool, I avoid instrumentation on windows as it seems to be somewhat innaccurate
07:12 gregorycu But callgrind may be different, I just need ballpark anyway
07:12 hmmmm nah, i think you're right, callgrind wouldn't work here since the values it produces are estimates based on instruction count
07:13 hmmmm obviously if code spends a lot of time doing low-level memory transfers to the gpu then it won't pick that up
07:13 hmmmm and what's more is that it'd be OS independent.  there's no real reason why you'd need to test it in linux as well
07:14 est31 even if its only an issue for win, it should be fixed, yes, but still testing is good
07:15 gregorycu I suppose my only... comment
07:15 gregorycu Is that this stuff seems so obvious, I mean 50% of the render time
07:16 est31 dammit this callgrind hangs in the nodedef phase
07:16 est31 and Im starting no dreambuilder here
07:16 est31 *just* mt_game with technic
07:16 gregorycu Another good thing about sampling is it doesn't slow down your app
07:23 Krock joined #minetest-dev
07:24 gregorycu I gotta run, but I'll be back in a few hours
07:24 est31 k#
07:24 * est31 s still waiting on callgrind
07:25 Hunterz joined #minetest-dev
07:39 VanessaE hmmmm: I am here now.
07:39 hmmmm hey
07:39 VanessaE (for a bit anyway)
07:39 hmmmm VanessaE, about the formspec scaling issue
07:39 hmmmm to clarify
07:39 hmmmm does this happen with formspecs that *do* have a size element specified?
07:41 VanessaE that I'm not sure of as I've never looked at the main menu code, however UI formspec does use a lot of specifically-sized elements if I recall right
07:41 VanessaE s/UI/Unified Inventory/
07:41 VanessaE that's the formspec you saw in that three-part screenshot yesterday
07:41 hmmmm main menu code formspecs are special though
07:42 hmmmm i'm gonna be honest, I have no idea wtf i'm doing with the formspec code
07:42 hmmmm that shit's such a mess
07:42 VanessaE heh
07:43 hmmmm it's a more complicated issue that can't be fixed quickly
07:43 VanessaE when the whole mess erupted, Zeno added those if's around the code to disable it
07:43 hmmmm well that has to do with the font size
07:43 VanessaE maybe we just need something like that, if android { (do all that shit) }
07:43 VanessaE ah
07:44 hmmmm it's not that trivial at all... large chunks of code are moved around and changed
07:44 VanessaE mmmh
07:44 hmmmm as far as the hud size problem
07:45 VanessaE I feel as others do though that to outright revert that commit (assuming it can be gracefully done)...well that's "elephant gun to kill a rat" territory...
07:45 hmmmm looking at it right now, the hotbar seems fine so far, but the health and breath bars are definitely a problem
07:45 VanessaE yeah
07:45 VanessaE hotbar though used to scale up with window size, now it doesn't (so it has almost the opposite issue as formspecs)
07:46 VanessaE those health bars are a complete confusion though - I haven't the faintest idea how their positioning works
07:46 ImQ009 joined #minetest-dev
07:46 VanessaE and to complicate matters:
07:46 hmmmm so you WANT the hotbar to scale with the window size?
07:46 hmmmm that I can easily fix
07:46 VanessaE yeah
07:46 VanessaE "But wait, there's more!"
07:47 VanessaE damn it where is it
07:47 VanessaE ah
07:47 VanessaE #2262
07:47 ShadowBot https://github.com/minetest/minetest/issues/2262 -- Subgame banner is hidden for wide windows
07:47 hmmmm weird.
07:47 VanessaE ^^^^ because THAT one scales with one window dimension, while the formspec scales against the other window dimension
07:47 VanessaE height vs width, that is
07:48 hmmmm yeah i'll check it out
07:48 hmmmm that's completely different from hud though
07:48 est31 why should the hotbar scale with the window size
07:48 VanessaE yep, I know
07:48 est31 I like it the other way
07:48 VanessaE I only mention it because it's affected by the scaling of the main menu
07:48 hmmmm est, because it used to
07:48 VanessaE which in turn is affected by window size
07:49 VanessaE (I don't know when that particular issue started though)
08:08 gregorycu_ joined #minetest-dev
08:13 deltib joined #minetest-dev
08:15 * est31 is wondering why the sum of samples % isnt 100
08:15 est31 What I've got from opreport is very weird
08:28 kilbith joined #minetest-dev
08:29 est31 side note: its pretty dumb to profile shaders when you havent enabled them
08:30 est31 11% spent in __dubsin??
08:30 est31 10 in __cos_sse2
08:32 est31 gregorycu: what shader options to enable
08:32 nrzkt joined #minetest-dev
08:33 est31 hmmmm too
08:34 nrzkt hello all
08:35 VanessaE hi
08:36 kilbith hi
08:38 gregorycu_ joined #minetest-dev
08:39 gregorycu__ joined #minetest-dev
08:50 gregorycu_ joined #minetest-dev
08:52 gregorycu__ joined #minetest-dev
09:08 gregorycu I'm back
09:09 gregorycu est31: I have no idea what options to turn on, I'm just running with default settings
09:09 gregorycu Heck, shaders may be turned off and it still is badly performant
09:09 est31 yea got some results
09:09 est31 but dont back your fact
09:09 est31 however only made a few draws
09:10 est31 should make more...
09:10 est31 s/fact/observation/
09:10 gregorycu_ joined #minetest-dev
09:11 gregorycu_ hmmmm suggested that they may not match up
09:11 gregorycu_ Can I see the results?
09:12 est31 I'll do a second run with more than just a dozen draws
09:12 est31 540 drawtime right now
09:12 gregorycu__ joined #minetest-dev
09:12 est31 1k
09:13 est31 gregorycu_: have you opened the logs page to recieve what we are writing you? I guess shitty internet means your connection can lag out before we send you stuff
09:14 gregorycu Yeah, I got the logs page open
09:14 gregorycu 450 and 1k
09:14 gregorycu 540
09:14 SopaXorzTaker joined #minetest-dev
09:15 est31 ok should be enough
09:15 gregorycu What are you actually measuring? What is "drawtime"?
09:15 jin_xi joined #minetest-dev
09:16 est31 drawtime is the value that shows up when you press f5 once
09:16 est31 I guess it tells you how long the last render loop took
09:17 est31 5.76% of all time in shadersource::getShader
09:17 gregorycu Ok, I'll have to see what that measures
09:17 est31 it just means callgrind makes mt slow :)
09:17 est31 I guess it is just 1/fps
09:20 est31 so how to share :)
09:20 gregorycu How long is spent in ClientMap::renderMap
09:20 est31 2.96 %
09:20 gregorycu ?
09:20 decimalguy joined #minetest-dev
09:20 est31 inclusive whatever that means
09:20 gregorycu Oh, exclusing
09:20 gregorycu 2.96 inclusive?
09:21 est31 exclusing 0.02%
09:21 gregorycu ...
09:21 est31 so yes
09:21 gregorycu Do you get a steady 60 fps? And is your machine a beast?
09:22 est31 nono not 60 fps
09:22 est31 the fps is quite slow
09:22 est31 machine is no beast
09:22 est31 not regarding gfx
09:23 est31 it has good ram and cpu but not excellent
09:23 est31 however, you rarely need more :)
09:23 gregorycu_ joined #minetest-dev
09:24 gregorycu_ Oh...
09:25 gregorycu_ It's probably excluding time spent in kernal/GPU calls
09:25 est31 settings: http://pbrd.co/1ItxYpa benchmark table: http://pbrd.co/1Ity8gp
09:26 gregorycu__ joined #minetest-dev
09:27 gregorycu Is there a tree view or something?
09:28 est31 no :(
09:28 est31 there is some map
09:28 est31 that visualizes the cost
09:29 ElectronLibre joined #minetest-dev
09:29 est31 http://pbrd.co/1ItzDeH
09:30 est31 example
09:30 est31 you also have other view
09:31 est31 s
09:31 est31 you can get a relative overview just like in a tree view
09:31 est31 so yes
09:31 est31 there is some sort of a tree view
09:31 gregorycu http://i.imgur.com/ULOyZdY.png
09:32 gregorycu Are you able to show this subtree in the tree
09:34 est31 http://pbrd.co/1ItAJXB
09:37 gregorycu I don't know why your render loop is such a tiny slice of your app time
09:38 gregorycu I don't know why your render loop is such a tiny slice of your app time
09:38 gregorycu Oops
09:38 gregorycu So, the shader stuff is about 20% for you
09:38 gregorycu 22%
09:39 est31 22?
09:40 gregorycu ClientMap::renderMap is 2.96%, ShaderSource::onSetConstants is 0.63%
09:40 gregorycu 0.63 / 2.96 = 22%
09:41 gregorycu ShaderSource::onSetConstants is a subset of the time of renderMap
09:41 est31 ah
09:41 est31 yes
09:42 Calinou joined #minetest-dev
09:42 gregorycu For me (with latest) it's 44%
09:43 est31 I'm not on very latest
09:43 gregorycu I can see that, but that's fine
09:43 est31 Im at d902bd31
09:43 gregorycu Latest basically removes the call to Settings::getBool
09:43 gregorycu (On the left side of that tree)
09:45 gregorycu I have different settings than you, I'll retry
09:48 est31 Ive disabled 3d clouds to be abled to navigate in mainmenu
09:49 gregorycu lol,seriously?
09:49 est31 yea :)
09:49 est31 while calllgrind is on of course
09:49 est31 otherwise its fine
09:53 Aaron1011 joined #minetest-dev
09:53 Aaron1011 joined #minetest-dev
09:54 cib0 joined #minetest-dev
09:55 gregorycu ...
09:56 gregorycu I've been looking at the ground while profiling to make sure I get the worst case
09:56 gregorycu (Maximum number of fps, maximum number of shader settings)
09:56 gregorycu I decided to do a profile run while looking into the distance
09:57 gregorycu renderMap: 59.64%, OnSetConstants 36.04%
09:57 gregorycu 60%
09:58 MattJ joined #minetest-dev
09:59 est31 not for me :\
09:59 gregorycu Are you running around in your test?
10:00 est31 no
10:00 est31 you
10:00 gregorycu No
10:13 PilzAdam joined #minetest-dev
10:20 gregorycu_ joined #minetest-dev
10:25 gregorycu_ joined #minetest-dev
10:26 Megal_ joined #minetest-dev
10:27 gregorycu__ joined #minetest-dev
10:41 Aaron1011 joined #minetest-dev
11:09 gregorycu What's actually interesting, is that only some shader settings are expensive to send
11:09 gregorycu I don't know a lot about shaders, to be honest
11:18 Krock Is zlib used by gettext?
11:33 gregorycu Did you want me to find out?
11:34 Krock yeah
11:38 gregorycu Doesn't look like it
11:52 gregorycu This is interesting
12:04 blaze joined #minetest-dev
12:09 gregorycu Ok, where is hmmm when you need him
12:10 gregorycu Sleeping is not a good excuse
12:11 est31 lol
12:11 gregorycu est31 I will share my finding with you
12:11 est31 which
12:11 gregorycu We appear to set the shader settings WAY more frequently than once a frame
12:11 est31 oh no
12:12 gregorycu I ran it for about 6000 frames, and there were 1.9M shader settings updates
12:12 Calinou should be once per frame?
12:13 gregorycu It's cached on the GPU, so you only need to send things that are updated
12:13 gregorycu But yes, once per frame would be better
12:13 gregorycu Than... lots per frame
12:13 jin_xi joined #minetest-dev
12:14 gregorycu I can't even contemplate what sort of degradation on performance this is having
12:14 gregorycu When I say 1.9M shader settings updates, I mean every global in the shader was updated
12:14 sfan5 that doesn't happen with shaders disabled, does it?
12:15 gregorycu that's a very good question, I'll have a look
12:16 gregorycu Thanks goodness, no it doesn't
12:17 sfan5 so if i disable shaders minetest should perform better?
12:17 gregorycu I believe so, I'm about to test that
12:21 gregorycu Yeah
12:21 gregorycu Like 150fps looking around, as opposed to 70 or something
12:22 gregorycu Hard to quantify
12:26 sfan5 hm
12:26 sfan5 my fps is capped to 60 for some reason
12:26 Calinou vsync? fps_max = 60 ?
12:26 sfan5 and minetest still sleeps in mainloop even when i set fps_max = 0
12:26 Calinou it should not
12:26 sfan5 also there should be a divide-by-zero when fps_max is 0
12:26 Calinou fps_max = 0 is meant for benchmarking, so no sleeping should be done
12:27 sfan5 nvm
12:27 gregorycu I set it to 1000
12:27 sfan5 it doesn't sleep anymore
12:27 sfan5 it still doesn't go above 60 though
12:29 sfan5 apparently you can divide by 0
12:29 gregorycu My maths teachers were wrong all this time
12:29 gregorycu Are there multiple entries in the config
12:29 gregorycu (With the same key?)
12:29 sfan5 no
12:30 sfan5 https://github.com/minetest/minetest​/blob/master/src/game.cpp#L4085-4087
12:31 gregorycu It's a float
12:31 gregorycu Divide by zero is allowed
12:31 sfan5 for what reason?
12:32 gregorycu Don't know
12:32 gregorycu But the result is infinity
12:34 sfan5 i guess 4294967295 is supposed to be infinity
12:35 sfan5 if (fps_timings->busy_time < frametime_min) { [...]
12:35 sfan5 unless rendering the frame also takes infinity time it should try to sleep
12:35 sfan5 or am i not understanding this right?
12:37 gregorycu I'm sure you'd figure it out if you wanted to
12:37 gregorycu But can you be bothered?
12:37 sfan5 wait what
12:38 sfan5 1000 / 0.0 is apparently 50
12:38 gregorycu lol
12:39 sfan5 g_settings->getFloat("fps_max")=0
12:39 sfan5 frametime_min=50 fps_timings->busy_time=12
12:39 sfan5 (fps_timings->busy_time < frametime_min) == true
12:39 gregorycu Um... check the bits on the float
12:39 sfan5 the float does not matter
12:39 sfan5 it gets converted to u32 and used
12:39 gregorycu What gets converted to u32?
12:39 sfan5 1000 / fps_max
12:39 sfan5 https://github.com/minetest/minetest​/blob/master/src/game.cpp#L4085-4087
12:39 gregorycu A floating point value, with possibly the +inf bit set and junk values elsewhere
12:43 sfan5 nevermind
12:43 sfan5 it was the pause fps
12:44 sfan5 (u32) (1000 / 0.0) seems to be 0
13:36 MinetestForFun joined #minetest-dev
13:40 gregorycu This is very much non-trivial to fix
13:42 MinetestForFun joined #minetest-dev
13:44 Amaz joined #minetest-dev
13:45 JakubVanek joined #minetest-dev
13:46 JakubVanek joined #minetest-dev
13:48 JakubVanek sfan5: what OS do you have? on linux on Mesa is vsync everywhere
14:08 Calinou Nouveau and Intel force v-sync by default indeed
14:08 Calinou proprietary NVIDIA driver doesn't
14:11 sfan5 JakubVanek: linux & intel
14:16 JakubVanek found this (for glxgears, but should work): http://stackoverflow.com/questions/1719​6117/disable-vertical-sync-for-glxgears
14:33 luizrpgluiz joined #minetest-dev
14:37 DevilMayhem joined #minetest-dev
14:52 kilbith joined #minetest-dev
14:53 DFeniks joined #minetest-dev
15:02 acerspyro joined #minetest-dev
15:14 nore joined #minetest-dev
15:14 luizrpgluiz left #minetest-dev
15:40 ElectronLibre joined #minetest-dev
15:42 kilbith joined #minetest-dev
16:01 prozacgod joined #minetest-dev
16:03 sfan5 i get about 7 fps more with shaders disabled
16:06 SopaXorzTaker joined #minetest-dev
16:14 CraigyDavi joined #minetest-dev
16:28 ElectronLibre joined #minetest-dev
16:40 DFeniks joined #minetest-dev
16:41 Calinou joined #minetest-dev
16:59 rubenwardy joined #minetest-dev
17:10 hmmmm joined #minetest-dev
17:11 hmmmm guys?
17:11 hmmmm sfan?
17:12 * VanessaE pokes hmmmm
17:12 hmmmm hello
17:12 hmmmm I looked at the HUD thing and the icons are all the same size as they used to be
17:14 VanessaE unless something has changed in the last couple of days, they don't scale with window size anymore.  it used to be that they'd be equivalent to hud_scale = 0.7 or thereabouts, at 800x600, and hud_scale=1.0 or close to it at 1600x1200, as measured with current code.
17:17 SopaXorzTaker joined #minetest-dev
17:19 hmmmm vanessae:  the heart/bubble icons were always 24 pixels on-screen... correct?
17:19 OldCoder joined #minetest-dev
17:19 VanessaE yep
17:19 VanessaE HUD also refers to the hotbar, btw
17:20 hmmmm the only problem imaginable might be that the offset is slightly different
17:20 VanessaE that explains the confusion here :)
17:20 VanessaE anyway yeah they were always ~24 pixels (unless a texture pack supplied larger images, for a while there that broke it, but that was fixed).
17:21 VanessaE the complaint you're probably thinking of though is that some games like carbone and dreambuilder have hotbars that are larger than 8 slots, so with the hotbar scaling issue as it currently stands, one side effect is that the hotbar no longer fits into one row
17:22 VanessaE so it takes two rows now (at default window size), making the health bar overlap it
17:26 VanessaE so two fixes are needed - health/breath bars (and whatever else is added above them by a mod) need to shift upward to stay clear of the hotbar, then the hotbar scaling has to be fixed
17:27 hmmmm isn't there a simple solution to this?
17:27 hmmmm have an option to tie hud_scaling to window resolution
17:27 VanessaE at one time, it was
17:28 hmmmm why is it not now.
17:28 VanessaE that broke when all this stuff went awry.
17:28 VanessaE I've no idea what the rationale was.
17:29 VanessaE I'm sure Zefram or sapier explained it at the time, but damned it I can remember it
17:29 hmmmm i don't see any problems with making hud_scaling dependent upon window res
17:29 hmmmm with a certain option set of course
17:29 hmmmm i don't want to force this onto everybody
17:29 VanessaE me neither - with one proviso:
17:29 VanessaE that the scaling be dependent on something that takes both height and width into account.
17:29 hmmmm what resolution would hud_scaling = 1.0 be though
17:30 VanessaE http://digitalaudioconcepts.com/vanessa/h​obbies/minetest/screenshots/Screenshot%20​-%2006162014%20-%2008%3a47%3a07%20PM.png
17:30 VanessaE http://digitalaudioconcepts.com/vanessa/h​obbies/minetest/screenshots/Screenshot%20​-%2006192014%20-%2005%3a34%3a41%20AM.png
17:30 VanessaE those two should give a fair representation of the HUD at two different sizes, before it all broke
17:31 hmmmm that kind of scaling functionality isn't critical though
17:31 hmmmm it's not a blocker
17:32 hmmmm the health/breath statbars overlapping with the hotbar IS a blocker and it's easily fixed by modiying the offset
17:33 VanessaE this is what it does now, just fyi:
17:33 VanessaE http://digitalaudioconcepts.com/vanessa/h​obbies/minetest/screenshots/Screenshot%20​-%2002082015%20-%2012%3a36%3a31%20PM.png
17:33 VanessaE (for the sake of having a current image)
17:33 hmmmm well, that is a very small screen
17:33 VanessaE that's the default window size.
17:33 hmmmm and an overly-large hotbar
17:34 VanessaE that's the hotbar scaling being screwed up.
17:34 VanessaE it used to take one row.
17:34 VanessaE besides, the image here is just for reference
17:35 acerspyro The fuck with this wm theme o.o
17:35 hmmmm acerspyro:  I am really getting pissed off with you
17:35 VanessaE acerspyro: XFCE "Keramik", recolored to purple.
17:35 acerspyro hmmmm: good, I talk once and you get pissed off. gg.
17:35 twoelk joined #minetest-dev
17:35 hmmmm acerspyro:  Tihs channel is for development discussion only.  Criticising people's WM themes is NOT dev talk
17:35 acerspyro VanessaE: Oh, I see.
17:35 hmmmm christ..
17:36 VanessaE ANYway
17:36 hmmmm I don't know, some people might like the hotbar stacking thing
17:36 hmmmm that part comes down to personal preference
17:36 hmmmm what doesn't come down to personal preference is the fact that they overlap eachother
17:36 VanessaE here's that same screen, at 1600x1200:  http://digitalaudioconcepts.com/vanessa/h​obbies/minetest/screenshots/Screenshot%20​-%2002082015%20-%2012%3a39%3a49%20PM.png
17:37 hmmmm yeah... gross
17:37 hmmmm I am ashamed to be associated with hud.cpp at this point :(
17:37 hmmmm look at that trainwreck
17:38 hmmmm well :) just kidding
17:38 VanessaE heh
17:38 acerspyro left #minetest-dev
17:38 hmmmm the root problem here is not that it doesn't scale to the window size
17:38 hmmmm it's that drawing offsets are dependent upon eachother
17:39 hmmmm and the dynamic hud statbar isn't designed that way
17:40 VanessaE when the whole statbar thing was being revamped, I advocated for relative slot positioning for these sorts of things, because I just knew that sooner or later something like this was gonna happen
17:40 hmmmm fwiw the second screenshot would probably look normal if the breath bar were present
17:40 VanessaE (though I didn't expect it to happen in precisely thisd manner)
17:40 VanessaE yeah, the left/right positioning of the two statbars is fine, never had a problem with that.
17:41 VanessaE just didn't feel like taking a swim ;)
17:42 VanessaE http://digitalaudioconcepts.com/vanessa/h​obbies/minetest/screenshots/Screenshot%20​-%2002082015%20-%2012%3a45%3a18%20PM.png
17:43 VanessaE versus default window size, worse case with those statbars etc: http://digitalaudioconcepts.com/vanessa/h​obbies/minetest/screenshots/Screenshot%20​-%2002082015%20-%2012%3a46%3a07%20PM.png
17:43 VanessaE ouch.
17:48 hmmmm :|
17:48 hmmmm https://github.com/minetest/minetest/commi​t/15c037614f6f7193cef4bfd1da45d83ef2fef393
17:48 hmmmm it's the best i can do right now
17:48 hmmmm in order to 100% fix statbars as they exist right now, we'd need to add in 'slot' functionality rather than positioning by pixels
17:49 VanessaE *looks at commit*
17:49 VanessaE inb4 pr*ller complains about whitespace fixes :P
17:49 VanessaE nice touch of caching size_factor.
17:49 hmmmm i'd hope it got optimized anyway...
17:49 hmmmm but it probably didn't
17:49 VanessaE kinda surprised that wasn't already done actually.
17:50 * VanessaE gives it a try
17:50 hmmmm did you notice I also fixed the compatibility code lol
17:51 hmmmm hearts were drawn for breath
17:52 VanessaE HAH!
17:52 hmmmm anyway let's release
17:52 VanessaE I didn't catch that before
17:52 hmmmm seriously
17:52 VanessaE lemme check this out
17:52 hmmmm sfan5:  are you there
17:52 VanessaE FAIL
17:53 VanessaE that had no effect on the statbars, at least in dreambuilder
17:53 VanessaE or rather, no effect to get them out of the way of the two-row hotbar
17:53 hmmmm right..
17:53 hmmmm all I did was modify an offset
17:53 VanessaE oh ok
17:54 hmmmm like I said
17:54 VanessaE oh yeah I can see the difference now
17:54 VanessaE derp
17:54 hmmmm if I actually wanted to fix that, then I'd have to add slots to the hud
17:54 hmmmm the implementation of which can get rather tricky
17:54 VanessaE can you at least restore the hotbar scaling?
17:54 VanessaE that'll workaround the problem for now I think
18:03 sfan5 hmmmm: yes
18:04 hmmmm sfan5:  hi!
18:04 hmmmm are you around to make official release builds?
18:04 hmmmm and if so for what platforms?
18:05 sfan5 when? now?
18:05 sfan5 platformsdd
18:05 sfan5 are win32 and win64
18:05 sfan5 (mingw ofc)
18:05 hmmmm I need to bump the version
18:05 hmmmm first
18:06 hmmmm I can do win32 MSVC
18:06 hmmmm but not win64 yet
18:17 jin_xi joined #minetest-dev
18:18 hmmmm i installed visual studio express on the VM i was testing MSVC-specific things with, so no 64 bit compiling
18:18 hmmmm i can't download it from msdn either because that site never works, all my downloads error after like 10 minutes
19:27 kilbith joined #minetest-dev
19:30 kilbith joined #minetest-dev
19:47 MattJ Hmm, any plans to package 0.4.11 for Ubuntu 14.10?
19:47 Krock How about 0.4.12 when it's ready?
19:47 MattJ or 0.4.12 when it's ready :)
20:07 MichaelRpdx joined #minetest-dev
20:16 hmmmm erm
20:17 hmmmm so I am downloading VS 2008 professional right now, I should be able to do all 4 builds on my own
20:17 hmmmm like 2 hours remaining :p
20:27 MinetestForFun joined #minetest-dev
20:31 MinetestForFun joined #minetest-dev
20:36 Vexyl joined #minetest-dev
20:41 JakubVanek joined #minetest-dev
20:42 ElectronLibre joined #minetest-dev
20:44 kilbith joined #minetest-dev
20:44 VanessaE joined #minetest-dev
20:44 JakubVanek Utopic 0.4.11 is supported (idk if it's official): https://launchpad.net/~minete​stdevs/+archive/ubuntu/stable
20:46 VanessaE that repo is official.
20:46 JakubVanek oh only 0.4.10 :(
20:46 VanessaE however 0.4.12 is about to be released
20:48 shadowzone joined #minetest-dev
20:55 shadowzone joined #minetest-dev
21:16 kilbith joined #minetest-dev
21:40 JakubVanek joined #minetest-dev
21:52 Calinou who will update the changelog?
21:52 Calinou no one has touched it since 0.4.11
21:55 ElectronLibre left #minetest-dev
21:55 hmmmm I guess I will
22:02 roniz joined #minetest-dev
22:52 decimalguy left #minetest-dev
22:56 Player_2 joined #minetest-dev
23:18 Wayward_One joined #minetest-dev

| Channels | #minetest-dev index | Today | | Google Search | Plaintext