Time Nick Message 02:19 luizrpgluiz hi 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: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: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/minetest/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: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: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_ 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: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: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: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 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:15 * est31 is wondering why the sum of samples % isnt 100 08:15 est31 What I've got from opreport is very weird 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:33 est31 hmmmm too 08:34 nrzkt hello all 08:35 VanessaE hi 08:36 kilbith hi 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: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 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:15 est31 ok should be enough 09:15 gregorycu What are you actually measuring? What is "drawtime"? 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 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: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: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 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 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: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: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 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: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: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:40 gregorycu This is very much non-trivial to fix 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/17196117/disable-vertical-sync-for-glxgears 16:03 sfan5 i get about 7 fps more with shaders disabled 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:19 hmmmm vanessae: the heart/bubble icons were always 24 pixels on-screen... correct? 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/hobbies/minetest/screenshots/Screenshot%20-%2006162014%20-%2008%3a47%3a07%20PM.png 17:30 VanessaE http://digitalaudioconcepts.com/vanessa/hobbies/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/hobbies/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 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/hobbies/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 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/hobbies/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/hobbies/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/commit/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: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: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: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:44 JakubVanek Utopic 0.4.11 is supported (idk if it's official): https://launchpad.net/~minetestdevs/+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 21:52 Calinou who will update the changelog? 21:52 Calinou no one has touched it since 0.4.11 21:55 hmmmm I guess I will