Time Nick Message 00:01 proller on 'road' server peoples build road to ~26km 00:02 proller half road 3 blocks width 00:02 proller and 11km high 00:03 proller with teleports any world size is small 00:21 eugd this debate about 'need' is silly for the simple reason we don't 'need' minetest at all. however goals of variable world dimensions (because really the cubic world shape is massively underutilized), and minecraft compatibility mode, are both highly desirable 00:56 eugd in the code there are references to chunks, and blockpos_min/blockpos_max 00:57 eugd 'chunk' = mapblock? 00:58 eugd ah nvm found it 01:41 blaise hello, could anyone tell me what is causing this? I'm afraid it might be in minetest core.. http://pastebin.com/6YCaxvNt 01:44 sapier https://github.com/minetest/minetest/pull/1561 implements in game font size modification support ... well actually you can even use fonts with different sizes same time now 01:45 sapier and automatic dpi faking is already removed as I didn't want to write faking code just to remove it with next commit 02:51 ArchZombie1y Are there any plans to migrate this code base to C++11? 02:53 ArchZombie1y And if I made patches converting it, would they be accepted? 03:01 blaise you'll never know unless you try, eh? 03:08 VanessaE ArchZombie1y: there has been some talk here and there that "it would be nice" basically, but no one has decided that it should be done 03:08 VanessaE most likely, if you made a patch, you will have to be the one to stick around for a long while getting it merged 03:28 ArchZombie1y I might just fork then 03:28 ArchZombie1y if it's gonna be a pain in the butt 03:33 VanessaE well not so much a pain in the butt, as much as people around here are...picky. 04:01 ArchZombie1y is it just me or is minetest rendering itself without window borders? :/ 04:02 VanessaE that doesn't happen on my box. 04:02 VanessaE (Xubuntu 14.04) 04:03 ArchZombie1y I am using ubuntu 14.04 04:04 ArchZombie1y I did pull from git though 04:04 ArchZombie1y reverting to the last release and i'll try it again 04:06 ArchZombie1y If this doesn't work I'll try getting mate 04:08 ArchZombie1y same deal with the version release 04:08 ArchZombie1y seems to be a unity integration issue 04:21 ArchZombie1y what is "// CLANG SUCKS DONKEY BALLS" for? 04:21 VanessaE just what it seems like, one of the devs inserting a snarky comment into the code :P 04:24 ArchZombie1y I was wondering if it was a reference to a bug 04:24 ArchZombie1y #include 04:24 VanessaE I seem to remember a discussion about it, but damned if I can remember the details 04:25 ArchZombie1y what on earth? 04:25 ArchZombie1y this engine, names it header files... such crappy caps... 04:25 ArchZombie1y and not irrlicit/bla ? 04:25 ArchZombie1y :/ 04:26 VanessaE for the longest time, there wasn't a clear set of code style guidelines 04:26 VanessaE and they're only now being hammered out 04:27 * VanessaE pokes ShadowNinja 04:27 VanessaE he's the style ... person. ;) 04:27 ArchZombie1y I think that's an issue with irrlichit. 04:28 VanessaE perhaps 04:29 ArchZombie1y what're the most used/modified classes in this game? 04:30 VanessaE that I don't know 04:31 VanessaE wish the main devs were here. I'm a Lua person, not C++ 04:35 ArchZombie1y ok, the game works properly in mate 04:55 ArchZombie1y looks like cmake is borked on ubuntu for c++11 :/ 04:55 ArchZombie1y I have to manually edit the cmake config files 04:55 ArchZombie1y by that I mean cmake_config.h 04:55 ArchZombie1y cmake_config.h:29:26: error: invalid suffix on literal; C++11 requires a space between literal and identifier [-Werror=literal-suffix] 04:55 ArchZombie1y #define CMAKE_BUILD_INFO "BUILD_TYPE="CMAKE_BUILD_TYPE" RUN_IN_PLACE=1 USE_GETTEXT=0 USE_SOUND=1 USE_CURL=1 USE_FREETYPE=0 USE_LUAJIT=0 STATIC_SHAREDIR=." 04:58 ArchZombie1y oh wee more C++11 incompatible headers :/ 05:10 ArchZombie1y Does it build debug or release by default 05:10 VanessaE I'm not sure. 05:11 VanessaE I've always explicitly specified the built type 05:12 ArchZombie1y what do you type for that? 05:12 VanessaE -DCMAKE_BUILD_TYPE=Debug (or Release) 05:13 ArchZombie1y ok thanks 05:13 VanessaE (why it isn't either all caps or all lowercase, I'm unsure) 05:15 ArchZombie1y Cmake is very stupid -_- 05:15 ArchZombie1y it's doing some weird crap 05:17 ArchZombie1y In file included from /home/ryan/minetest/src/game.cpp:40:0: 05:17 ArchZombie1y I fucking deleted the line including that header. 05:17 ArchZombie1y What the flying fuck 05:18 VanessaE yu know, you and hmmmm would get along well :) 05:18 VanessaE you and he seem a lot alike :) 05:22 ArchZombie1y ah, cmake module... I think 05:22 ArchZombie1y I hope this isn't part of fucking cmake itself. 05:23 ArchZombie1y and maybe haha 05:23 ArchZombie1y I'm partial to autotools myself 05:23 ArchZombie1y being that it tends to actually work 05:30 ArchZombie1y I'd like to switch from cmake to autotools >:( 05:30 ArchZombie1y any... maybe it will work this time... 05:30 RealBadAngel kahrl ? 05:30 ArchZombie1y nope 05:31 ArchZombie1y it broooke 05:32 ArchZombie1y > cmake > change one file > have to restart compile from begging? 05:32 hmmmm VanessaE: what..? 05:33 ArchZombie1y *beginning 05:33 VanessaE ah, he IS awake. 05:33 VanessaE hmmmm: I was merely comparing ArchZombie1y's typing style to yours. you two seem quite similar. when you get on a rant, you're actually very similar to the above. 05:34 hmmmm err... okay... 05:34 VanessaE it's a compliment :) 05:39 ArchZombie1y I /think/ it was being weird because gettext is also a system header or something... 05:39 ArchZombie1y I hope it compiles this time 05:39 ArchZombie1y I replaced all gettext with gettexth 05:39 ArchZombie1y *gettextx 05:52 ArchZombie1y oh of course not :) 06:12 ArchZombie1y compiled for C++11 by major noobhacking 06:12 ArchZombie1y how do I show Fps? 06:21 ArchZombie1y can we purge jthread from the face of the earth? :) 06:26 * ArchZombie1y sighs 06:27 ArchZombie1y It looks like there's a lot of work to be done here tearing out crap :/ 06:31 VanessaE fps is in the F5 display 07:00 ArchZombie1y can I remove the fps cap? 07:03 Krock F5 07:07 ArchZombie1y I mean, can I make it go above 60 fps? 07:07 ArchZombie1y my laptop can handle it :P 07:15 ArchZombie1y it always sticks at exactly 60 fps :/ 07:16 Krock that's vsync 07:16 Krock for me it always sticks at 20 fps and I'm happy with that 07:26 * ArchZombie1y used /set vsync false and it didn't help :( 07:26 ArchZombie1y the problem is I can't figure out if my changes sped up anything 07:27 ArchZombie1y since my fps is capped at 60 either way -_- 07:30 * hmmmm bashes head against keyboard 07:30 hmmmm another C++11 guy 07:30 hmmmm great 07:30 hmmmm what is the fascination with C++11? just because something new any shiny exists means it should be used? 07:37 ArchZombie1y because it's faster/better? :/ 07:37 ArchZombie1y very rarely do you get something both faster and easier to use 09:03 sapier lol ... why do ppl always believe new things are faster ... new and fast have NOTHING in common. Case you need an example WinXP <-> Vista. 09:03 sapier If something is faster it's not because it's new but because those who designed it made it faster. As of C++11 speed doesn't depend on language but on compiler to do it. 09:04 sapier And those compilers are reason why we don't switch to support C++11 yet. Right now we still support compilers not having c++11 support and we wont add #ifdef c++11 everywhere around code. 09:04 sapier Why ? because major benefit of c++ is some code can be written way more readable ... Guess what ... having ifdefs around would make this benefit useless. And yes there are other good things too, yet nothing really >>"necessary"<<. 09:05 sapier Once all our supported compilers do support C++11 code will be accepted ... Yet there most likely wont be a "convert to c++11" commit nor do I believe it would be accepted as a single commit. 09:08 sapier Which compilers don't support c++11? debian oldstable gcc (partial support only) as well as our windows compiler msvc2008 09:11 sapier ArchZombie1y did you ever read http://blog.newrelic.com/2014/05/05/open-source_gettingstarted/ or something similar? If you did and believe it ain't true ... it is! 09:13 Calinou Vista can boot faster than XP 09:14 sapier I didn't benchmark it on each possible hardware 09:14 Calinou but Windows 8 is faster than 7 in every way 09:14 Calinou people telling you the inverse are wrong 09:14 sapier yes faster removed 09:14 Calinou lol 09:15 sapier whoever did design that gui didn't ever try it on a pc 09:16 Calinou you can boot to desktop as of 8.1 09:16 Calinou do it 09:16 sapier well at least win8 did show up ios gui wasn't an advancement but purely technical limited to "play" devices instead of real work tools 09:17 sapier Calinou: why should I even consider installing a os beeing a step back in usability while there's a better one left and next one will fix the issues? ;-) 09:18 sapier there's simply now way to create a truly unified gui for keyboard/mouse <--> touchscreen interaction ... usecases are too different 09:19 sapier could someone check https://github.com/minetest/minetest/pull/1561 09:24 Calinou Windows 7 isn't better: its file copy dialog is worse (and copies files slower), its task manager is much worse (can't report bandwidth properly), it's not flat design (ugly)… 09:25 Calinou Windows 8 is also cheaper these days 09:25 Calinou there's absolutely no reason to keep Windows 7 in 2014 09:25 sapier still the gui is crap 09:26 sapier and using win8 gui is inconveniant for typical work usecases ... I'm not talking about the usual private person having 3 programs using nothing else 09:29 sapier at least microsoft keeps their rule ... one good .. one bad ... one good ... one bad ;-) 09:33 Calinou it's been one good, one good, one good, one good so far. 09:33 Calinou Vista had upsides too 09:33 Calinou these upsides were “worth” the downsides 09:34 Calinou (note that when I talk about Windows, it's in comparison to other Windows versions, not involving other operating systems) 09:34 sapier EVERYTHING has upsides but yet the overall sum was negative on vista 09:35 sapier and messing up ui is one of easiest ways to turn overall sum negative ;-) 09:37 Calinou if you organize the Moern UI properly, you may end up liking it; also don't forget about Windows + X 09:37 Calinou (spawns a dropdown menu with links to shutdown, command line…) 09:37 sapier I will never end up liking a ui designed for having a fixed small set of applications only 09:38 sapier hiding all my running applications on starting a new one 09:38 sapier assuming user to have a single screen only 09:39 sapier while those limits are true for almost all consumers they're often wrong for developers 09:39 Calinou it's possible to use Windows 8 without using the Modern UI often anyway 09:40 sapier still they forgot about that cool feature called "browsable menu" ... lots of linux ui's did same because of apple started that crazy thing due to lack of screen size on their first devices 09:41 Calinou there are third-party applications for it 09:41 Calinou and many people barely use the start menu anyway (thanks to the quick launch bar) 09:41 Calinou you can work your way around it 09:41 sapier of course ... but I tend to call a os bad if you need third party applications to do genuine os work 09:43 sapier not telling linux is better ... as I said they did mimicry apple way to much too ... forgetting about apple doing lots of thing to work around hardware limitations not present on pc 09:43 Calinou that applies to all Windows versions then 09:43 Calinou eg. 7-Zip, Geany/Notepad++… 09:43 sapier file compression and editing are applications ... starting a application isn't a application 09:45 sapier win8 optimized application start to one single usecase .. yes they're turning it back step by step but they haven't reached the level they have been before for a lot of usecases 09:48 sapier btw we're possibly about to mess up the gui too by forcing formspec aspect ratio to 4:3 so we should test it quite carefully 09:50 Calinou I'm on 16:9 list most people 09:50 sapier you mist likely will see a in game change 10:15 sapier VanessaE are you using freetype? 12:01 sapier can someone explain to me why irrlicht is such a bitch about it's own font format? ;) 12:38 RealBadAngel and i wonder whats gonna be faster, two times pow + multiply inside or one multiply * sqrt 12:39 RealBadAngel light_f = pow(light_f, 2.2f); // gamma -> linear space 12:39 RealBadAngel light_f = light_f * light_amount; 12:39 RealBadAngel light_f = pow(light_f, 1.0f/2.2f); // linear -> gamma space 12:39 RealBadAngel or : light_f *=sqrtf(light_amount); 12:40 sapier well I guess you should consider numeric limitations too for those calculations 12:41 RealBadAngel not really, theyre converted from and back to u8 12:41 RealBadAngel https://github.com/RealBadAngel/minetest/blob/master/src/mapblock_mesh.cpp#L278 12:42 sapier so what's the typical range? 1-20? 12:42 RealBadAngel so precision doesnt really matter so much 12:42 RealBadAngel this is 0-255 12:42 sapier true should be fine 12:43 sapier you'll have to benchmark ... but I'd not be sure if result will be valid for different processors 12:50 RealBadAngel it feels like it should be faster 12:53 RealBadAngel and yes i have to put there my own timers 12:56 sapier well why not make it loop 100000 times and see what's faster 13:03 RealBadAngel average for sqrt is 580ns, for pow way: 1000ns with spikes as 1880ns 13:03 RealBadAngel so twice as fast 13:07 RealBadAngel another bottleneck bites the dust ;) 13:09 RealBadAngel brb, need to boot into android for a moment 14:03 RealBadAngel back 14:36 RealBadAngel sapier, did even better 14:39 RealBadAngel http://pastebin.com/tixYAzST 14:39 sapier performance difference? 14:43 RealBadAngel 620ns vs 1100-1200ns 14:50 VanessaE sapier: [08-17 06:18] VanessaE are you using freetype? <--- yep. 14:51 VanessaE RealBadAngel: and it still looks the same? 14:52 RealBadAngel yes 14:55 sapier VanessaE: didn't you use your own font some time? 14:55 VanessaE sapier: ages ago. but I've been using freetype for a long while now. 14:56 sapier very strange 15:27 Selat RealBadAngle: are lines 2-4 equal to "light_f = light_f * pow(light_amount, 1.0 / 2.2);"? 16:32 Krock http://i.imgur.com/4Lrr3.gif?1 16:46 Krock !tell sfan5 http://i.imgur.com/IpMxwtR.jpg 17:13 sapier VanessaE Celeron55 fixing the formspec scaling might only be possible while breaking a lot of formspec based mods 17:14 sapier reason is different formspec elements use different ways to calculate their position, resulting in different effective scaling beeing aplied 17:16 Zefram_Fysh they all use funny offsets and funny ways of calculating size, but they all agree on what is meant by differences in specified position 17:16 Zefram_Fysh it'd be nice to have a cleaner way to specify sizes and positions, but the current funny rules aren't incompatible with changes to overall form scale 17:16 sapier don't exactly no what you mean but pos 2,3 means something different for a button or a field 17:17 sapier they are 17:17 Zefram_Fysh pos 2,3 means different things for button and field, yes, but both button and field agree that pos 3,4 is exactly one inventory slot below and to the right of pos 2,3 17:17 sapier because if I fix the scalings of the elements they base uppon the resulting offsets will change 17:19 Zefram_Fysh if you scale the inventory slot size so that the form fits the screen, all position and size calculations can be based on the scaled slot size, and all elements will have the same relationships as before. except for text size not scaling with inventory slots, which is another problem 17:19 celeron55 sapier: i would guess it's possible to do it without too large changes in positioning 17:20 sapier current formspec positioning is like taking 10 different arithmetics and setting parameters to those values where at screen size X,Y all elements are positioned correct 17:20 celeron55 mods can't rely on very precise positioning anyway so they can cope with a bit of change 17:20 sapier all elements will still be close to where they've been before ... but with some offset 17:21 VanessaE define "with some offset: 17:21 sapier one thing for example some elements use padding plus spacing others only spacing 17:21 VanessaE are we talking about 2 pixels here, or 200? 17:21 Zefram_Fysh can you give an example of what would yield the kind of offset you're talking about? 17:22 sapier if I apply scaling factor to all of them the offset between those not using padding and the one using it will grow 17:22 Zefram_Fysh the padding and spacing can scale the same as everything else does 17:23 sapier X * 0.75 + Y * 0.75 = Y1 * 0.75 BUT 17:23 sapier X * 1.0 + Y * 1.0 != Y1 * 1.0 17:23 sapier well X changes too 17:24 sapier so actually it's X1 in second example 17:24 Zefram_Fysh the engine already scales forms, in pixel terms, as the window size changes. this already causes some changes to layout where text is concerned, because text doesn't scale. if you apply the same kind of scaling to fit larger forms into the window, that would only cause the kinds of layout shift that we're already accustomed to, and wouldn't be any more problem than we already have 17:24 VanessaE you're doing your math wrong. 17:24 VanessaE it's not X*0.75+Y*0.75, it would be (X+Y)*0.75 17:25 sapier Zefram_Fysh: actually I made a patch for text to scale but it's not enough 17:25 VanessaE at least if I'm reading you correctly. 17:25 sapier maybe I'm not even reading my self correct with all that crude arithmetics I read the last hours 17:29 VanessaE plus, since when were there any absolute positioning measured in pixels in a formspec? 17:30 VanessaE (in the HUD, there is, but we're not talking about that) 17:30 sapier calculation is done in different ways some use absolute values others relative ones 17:30 VanessaE the bottom line is, if you're not measuring in pixels, you have the freedom to scale EVERYTHING by the same factor. 17:31 sapier in theory yes ... in practice theres some history ;-P 17:31 VanessaE "Well history is about to change." 17:31 VanessaE and it's not theory. it's math. 17:31 sapier yes but in this particular case it's most likely gonna break positioning 17:31 VanessaE basic geometry :) 17:32 VanessaE (you wanna turn math back into theory, go talk to Stephen Hawking or something :P ) 17:32 Zefram_Fysh you can scale overall without affecting the relationships between the funny ways of calculating positions and size 17:33 VanessaE sapier: just apply the same scale factor to every. single. item. on. the. screen. that. can. be. placed. moved. or. sized. 17:33 VanessaE every coordinate. every size field. the whole smash. 17:33 VanessaE I'd give it a 95% chance that, provided you used a sane initial DPI calculation, nothing of substance will change in any mod. even Unified Inventory will probably survive. 17:33 sapier well that's not gonna work because there are some variable scaling factors applied to different things right now 17:34 VanessaE did you try it? 17:34 sapier thus even if I apply same factor uppon them those will result in form getting disorted 17:34 Zefram_Fysh you have to be careful at which stage you apply the scaling factor, that's all 17:34 VanessaE Zefram_Fysh: already been down that road. :-/ 17:34 Zefram_Fysh you don't scale the numbers specified in the formspec directly 17:34 VanessaE sapier is being stubborn :) 17:35 VanessaE apply your scaling factor at the final pass-it-to-irrlicht step 17:35 sapier guys if you believe this to be simple I'll gladly wait for your solution to be ready in half an hour ;-P 17:35 VanessaE sapier: every junior high school student knows this is simple :) 17:35 VanessaE you're just overcomplicating it :P 17:36 sapier well then make that student work on totally messed up base and see what's gonna be the result. If I'd be allowed to just start without history It'd be easy but then we'd have to rewrite any single formspec 17:38 Zefram_Fysh I'm satisfied that it's simple, though there's quite a bit of it to do. the scaling is done separately for each formspec element type. I *have* delved quite a bit in the relevant code, researching stuff for unified_inventory. I'd offer to provide a patch, but you don't like the manner in which I submit patches 17:53 VanessaE sapier: you keep talking from the standpoint of writing formspecs, as if you're adapting them. you're not. you're scaling them. it's no different than scaling up an image file (aside from it not getting blurry) 17:54 VanessaE scaling != adapting. 17:54 VanessaE if you scale X and Y by the same factor, the only thing that happens is it gets bigger or smaller. if you scale all such objects and their positions accordingly, the whole thing gets bigger or smaller. 17:54 VanessaE that's all. 17:55 sapier VanessaE: if you did look at the code you'd see positions are calculated like x1*x2+y1*y2+z1*z2 ... eech x1 to z2 scaled by a different factor depending on different things and sometimes even depending on each other 17:56 sapier while basic task is moving 1,2 to 1.1 2.2 this can right now only be done by sorting out the mess below 17:56 VanessaE (x1*x2)*scale+(y1*y2)*scale+(z1*z2)*scale 17:56 VanessaE there. 17:56 VanessaE problem solved. 17:56 sapier yes but y2 is scaled implicit by x1 for some things so you're gonna apply it twice 17:57 VanessaE multiplication is commutative. it doesn't matter if X depends on Y or Y depends on X. you're doing it this *at the final output* 17:57 sapier argh 17:58 sapier let's try again 17:58 sapier X1 = scalefactor * DEFAULT_VALUE ---> X1 Stored as it's a formspec member 17:58 sapier now another gui element s drawn 17:58 sapier there position is calculated 17:58 VanessaE and there's your first mistake. 17:59 sapier that's not my mistake that's how formspec does this things 17:59 VanessaE then get rid of it. 17:59 sapier what the hell am I talking about the last hours? 17:59 * VanessaE double facepalms 17:59 VanessaE is or is not "scalefactor" the thing you've been proposing to add? 18:00 sapier but fixing that mess WILL result in changed positions 18:00 Zefram_Fysh hang on. sapier seems to be tying together two possible changes that don't actually need to happen together 18:00 VanessaE Zefram_Fysh: already been there, too. 18:01 VanessaE :) 18:01 sapier goddamn those things are both partial within code you can't fix one without touchin the other 18:01 Zefram_Fysh I can see how to fix them separately 18:02 sapier << giving up ppl never ever having changed that crapy code seem not to understand problem isn't the task but the history 18:02 Zefram_Fysh having a more coherent way to specify form element positions and sizes doesn't even have to break compatibility with existing formspecs. more than one way of specifying these things can coexist indefinitely 18:03 sapier yes zefram_fysh go write second parser in parallel autodetecting which one to use for this formspec 18:03 sapier well at least we have a version number now so you might even have a chance to do 18:03 VanessaE sapier: don't give up. just stop being stubborn :) 18:03 Zefram_Fysh autodetect? I would naturally use non-clashing syntax 18:04 sapier oohhhh yes we're adding a field_NEW_VERSION and passwd_NEW_VERSION ... 18:04 Zefram_Fysh but, as I already said, the scaling can be fixed without changing how formspecs specify position 18:04 VanessaE actually, strike that - don't give up AND direct your stubbornness toward a graceful solution 18:05 VanessaE I don't know fuck all about C++ compared to Lua, or I'd have already attempted to fix it. 18:05 Zefram_Fysh well, that was productive 18:08 Zefram_Fysh the form handling C++ code is a bit more complicated than you imagine. there's some nastiness due to switching between floating-point and integer (pixel) coordinates, which complicates the issue of where the scaling goes, but that's not insuperable 18:09 VanessaE I'm sure it's complicated, but the math of scaling an object according to DPI or some other arbitrary factor is still simple 18:09 Zefram_Fysh actually the integerisation is for some elements done too early, slightly screwing up element alignment at lower resolutions 18:09 Zefram_Fysh yes. in principle the scaling is simple, and the simple scaling is perfectly achievable in the current code 18:10 rubenwardy Where is the code that draws the player names? 18:14 VanessaE um..... 18:15 rubenwardy I am currently searching through the code, but I haven't found it yet. 18:26 rubenwardy Okay, Minetest doesn't draw actually have floating player names. It is just an optical illusion 18:27 Zefram_Fysh yeah, the player names are more part of the HUD than part of the world 18:28 rubenwardy I can't see any code to draw the player's names 18:31 VanessaE it used to be in minetest, but it relies on a default irrlicht font 18:31 VanessaE I've changed it once ages ago with a patch I think I got from xyz or kahrl 18:31 VanessaE I've long since lost that patch 18:35 rubenwardy Where is it? 18:39 VanessaE I'm afraid I don't remember :( 18:40 rubenwardy Any idea? Is it definitely C++ code? 18:43 Zefram_Fysh I don't see any Lua HUD code that mentions player names 18:44 rubenwardy It isn't rendered by hud.cpp 18:44 Calinou fully C++ 18:44 Calinou really 18:44 Calinou no Lua is involved in player names 18:44 Calinou since always 18:45 Calinou http://paste.ubuntu.com/8073500/ 18:45 Calinou this may be of use 18:45 Calinou list of grep results 18:45 Calinou it always uses the fallback Irrlicht font 18:59 rubenwardy content_cao.cpp 960 18:59 rubenwardy found it 19:08 Calinou :O 19:08 Calinou I was searching 19:09 Calinou look at hud.cpp for waypoint code 21:40 sapier ok done .... it's gonna break almost any formspec out there but it'S working now 21:42 sapier suggerstions how to fix it without breaking code are welcome ... but my new suggestion at least results in button dropdown textlist label checkbox ... beeing drawn at 1,1 beeing really drawn at same screen position 21:49 Zefram_Fysh where can I find your patch? 21:50 sapier hmm wait a second ... seems like I just broke it again 21:52 VanessaE you still haven't defined just how badly existing formspecs will break. 21:52 VanessaE how about a practical example? 21:52 VanessaE show us Unified Inventory with your patch 21:52 VanessaE but without any tweaks to that mod 21:53 sapier https://github.com/minetest/minetest/pull/1561 21:53 sapier VannessaE ... for what? it's brokne 21:53 sapier all textfields and buttons are about 40pixels off (depends on scaling of course) 21:54 VanessaE THAT is what I meant by "just how badly" 21:54 Zefram_Fysh we have some difficulty grasping the nature of the breakage, because we don't see any need for breakage at all 21:54 VanessaE 40 pixels at what DPI and window size? 21:54 VanessaE 40 pixels for you, it's half way off the screen. 40 pixels for me, it's half a millimeter. 21:54 VanessaE (ok that's an exaggeration) 21:55 sapier ok for the lazy ones 1/3 of formspec scales based uppon font size another 1/3 based uppon a imaginated image size not beeing relate to that formspec element at all ... the next 1/3 is some mixed mode where x and y scale different or even based on both 21:55 VanessaE (in fact on my screens, 40 pixels is around 1.2 cm or so) 21:56 sapier font's are usually within a range of 8-20 so the loose a lot of precision for scaling 21:56 VanessaE sapier: SCREENSHOTS dammit 21:56 VanessaE show us unified inventory with your patch 21:57 VanessaE that's as extreme a formspec as you'll generally find in practice 21:57 VanessaE (save for the main menu) 21:57 sapier no it ain't as I didn't touch inventory item positioning 21:57 VanessaE it has way more than just inventory slots. 21:57 sapier forms like mainmenu and mobf_settings are way more affected 21:58 VanessaE image buttons, text labels, a search field, some other stuff I'm forgetting 21:58 sapier yes those are the messed up things 21:59 VanessaE Unified Inventory uses these things. 21:59 VanessaE oh screw it. I'll do it myself. 21:59 sapier yes still it's about 10% of screen 21:59 sapier http://imgur.com/BKe7hWE 22:00 VanessaE NOW I see what you've been trying to say. 22:00 sapier all formspecs out there fix the button/textfield missalignment on their own 22:01 VanessaE fix the aspect scaling on the image buttons and you've got 90% of the issue 22:01 sapier but as I had to separate font based from image based scaling (and those offsets are created by image offset) you get this effect 22:01 VanessaE actually scratch that 22:01 sapier image buttons do now behave exactly same as regular buttons 22:01 VanessaE the images are just too big for their buttons now 22:02 sapier same positioning same size ... sideeffect is you can get higher buttons too 22:02 sapier guess the buttons need to be increased 22:02 Zefram_Fysh you could change text sizing, and even positioning, without also changing the sizing and positioning of purely image-based elements. the image buttons shouldn't need to be changed 22:03 VanessaE sapier: wait. let me get screenshots up first. 22:03 sapier goddamn what's so difficult to understand that there's two different scaling bases in this menu 22:05 sapier and one of those bases is font size which lacks of arithmetic precision because it's a small integer 22:05 VanessaE ew. 22:05 VanessaE sapier: you broke it worse than you thought. 22:05 sapier show me I didn't see all issues for sure 22:06 VanessaE git HEAD (well, almost): http://digitalaudioconcepts.com/vanessa/hobbies/minetest/screenshots/Screenshot%20-%2008172014%20-%2006%3a05%3a11%20PM.png 22:06 VanessaE And with your patch: http://digitalaudioconcepts.com/vanessa/hobbies/minetest/screenshots/Screenshot%20-%2008172014%20-%2006%3a08%3a33%20PM.png 22:06 VanessaE that is just plain wrong 22:06 VanessaE FAIL of the highest order 22:06 sapier well didn't you want it to not scale? 22:07 VanessaE when did I say not to scale it? 22:07 sapier still that's a minor change as relative sizes now are correct 22:08 VanessaE did you notice the size of the HUD ? 22:08 VanessaE if the relative sizes were correct then the buttons' contents would still fit in your patch 22:08 sapier it's fixed in this version 22:09 sapier as the manual dpi setting is already in there 22:09 VanessaE what's the assumed DPI? 22:09 sapier 800x600 default value so 2 levels below what you did have befroe 22:11 sapier 96 for what I remember try setting screen_dpi to something like 140 22:11 VanessaE well I was obviously wrong about not scaling by default, for some reason I had it in my head that things already didn't. maybe I was thinking about that fucked up HUD stepped scaling thing. 22:14 sapier you can try the gui_scaling setting in settings ;-) 22:14 sapier it'd even be better as this will scale fonts up too 22:15 VanessaE screen_dpi = 55 is about the right setting to get the right size -- but that's only useful if I maximize the game window. 22:15 sapier 55? 22:15 VanessaE in other words, yeah. scale formspecs by default 22:15 VanessaE yeah, 55. 22:15 sapier wrong direction ... there's a calculatione rror 22:15 sapier actually it's supposed to get bigger on bigger values 22:15 VanessaE um 22:15 VanessaE wrong 22:16 VanessaE DPI = dots per inch 22:16 VanessaE lower numbers = lower rez = things will be bigger 22:16 sapier yes and for more dpi you need bigger items to get same screen size 22:16 VanessaE right 22:16 VanessaE but if you turn up DPI, the image should get smaller. 22:16 sapier so if you set your screen to have higher dpi the menu should increas it's pixel size 22:17 VanessaE eh...that seems counter-intuitive. 22:17 VanessaE but I get your point 22:17 VanessaE better you should be using a unitless scaling factor in the config 22:18 sapier why? you configure your screen parameters not your gui scaling factor ... that's a different value 22:18 VanessaE maybe because virtually no one actually knows their screens' DPI? 22:18 VanessaE but everyone can figure out a scale factor. 22:18 VanessaE 1x, 2x, 3x.... 22:18 sapier ok slow down open settings tab and look to the lower left corner ... NOW 22:19 VanessaE I see it of course. 22:19 VanessaE GUI sc ale factor. 22:19 VanessaE scale* 22:19 sapier don't try to use 3 22:19 VanessaE currently in the middle of its range, and no unit shown 22:19 VanessaE just a slider with no value 22:19 sapier put your mouse over it 22:19 VanessaE oh, mouseover to get the value 22:20 sapier well on 1920x1080 I can get up to 2.8 22:21 sapier and there the vert labels are to small ... another undiscovered bug ... like some elements scaling their x coordinates based uppon y scaling factor ... 22:22 sapier btw in Test tab you see the new alignment 22:22 VanessaE Ok, took the DPI setting out of the .conf and tweaked that slider a bit. 1.78 gives me what I had before your patch, at least for the formspec (the HUD is bigger but I can see all of it). BUT the whole thing is still bigger than the default window size so it's only useful with a maximized window. 22:23 sapier well we can add a "gui and game scaling factor ..." 22:25 VanessaE ... 22:25 VanessaE now I'm confused what we're really trying to solve here. 22:25 VanessaE (I didn't recall this GUI scale function existed) 22:25 sapier actually we have to solve the whole deal as we're at the point where fixing a single issue always results in making anothe one worse 22:26 sapier meaning, font scaling, gui scaling, formspec positioning 22:26 VanessaE right. 22:27 * VanessaE re-checks it with git HEAD just to compare. 22:27 sapier downside is fixing formspecs means all formspecs out there will be messed up slightly 22:27 sapier on good side, formspec x and y values between different elements get finaly identical 22:28 sapier lol I even have to fix the progress bars ... 22:29 VanessaE git HEAD, with that scaling factor set where I just had it...um..er.... just don't ask ;-) 22:29 sapier messed up fonts? 22:30 VanessaE actually no 22:30 VanessaE um 22:30 VanessaE er... 22:30 VanessaE REALLY FUCKING HUGE formspecs ;) 22:30 sapier :-) 22:30 sapier well there the dpi factor is applied on top of it 22:30 VanessaE [08-17 18:25] Ok, took the DPI setting out of the .conf and tweaked that slider a bit. 1.78 gives me what I had before your patch, at least for the formspec (the HUD is bigger but I can see all of it). BUT the whole thing is still bigger than the default window size so it's only useful with a maximized window. 22:30 VanessaE "took the DPI setting out" 22:31 sapier yes but head doesn't have a setting but does it automaticaly based on y window size ;-) 22:31 VanessaE so that "really fucking huge" is git HEAD with just the gui_scaling leftover from testing your patch a few mins ago 22:31 VanessaE oh ok 22:31 VanessaE what do you say I put things back to normal :) 22:32 VanessaE there, that's more like it. 22:32 sapier ok obviously we need a autoscaling formspec mode too ... well I've got an Idea how to do it 22:33 VanessaE I'd say just auto-scale everything with the window size like before, except for the pause menu perhaps 22:33 VanessaE (that one just needs some basic reformatting because frankly, all that unformatted text on the left looks like ass) 22:35 sapier you know that you didn't like the "like before" before? ;) 22:35 VanessaE huh? 22:36 VanessaE what can I say, I get confused easily :P 22:38 VanessaE btw, travis failed on your pull. 22:38 VanessaE (though obviously it works for me) 22:39 sapier interesting ... well it's far from mergeable by now 22:40 * VanessaE tries to look at the code and goes cross-eyes 22:40 VanessaE eyed* 22:50 VanessaE I see what you mean about a few of these elements' widths being dependent on height/vice versa 22:51 VanessaE oh, btw: 22:51 VanessaE 96 DPI? bzzzt 22:51 VanessaE + // 72 is default dpi value we base uppon 22:51 VanessaE + return 72.0/g_settings->getFloat("screen_dpi"); 22:52 VanessaE who has a 72 DPI screen, that isn't 30 years old? O_o 22:52 sapier yes ... that's a workaround from font_engine code without formspec fixes 22:53 VanessaE or are you basing that on points? 22:53 sapier about 10 years crt's used to be 72 22:53 VanessaE 30 was a joke :P 22:54 sapier microsoft claimed them to be 96 ... internally the did arithmetic magic to get down to 72 22:55 sapier but not even close to the "magic" formspec does and calls it "scaling" 23:12 VanessaE heh