Minetest logo

IRC log for #minetest-dev, 2014-08-17

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

All times shown according to UTC.

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:45 CraigyDavi joined #minetest-dev
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:27 Miner_48er joined #minetest-dev
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:43 sapier joined #minetest-dev
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:07 proller joined #minetest-dev
02:51 ArchZombie1y joined #minetest-dev
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:13 proller joined #minetest-dev
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 <IMeshManipulator.h>
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:34 ArchZombie1y joined #minetest-dev
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:08 OldCoder joined #minetest-dev
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:51 Hunterz joined #minetest-dev
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
06:43 Krock joined #minetest-dev
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
07:51 nore joined #minetest-dev
08:26 Calinou joined #minetest-dev
08:54 sapier joined #minetest-dev
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:10 proller joined #minetest-dev
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:18 PenguinDad joined #minetest-dev
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:47 proller joined #minetest-dev
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:02 SmugLeaf joined #minetest-dev
10:02 SmugLeaf joined #minetest-dev
10:15 sapier VanessaE are you using freetype?
10:57 proller joined #minetest-dev
11:15 proller joined #minetest-dev
11:45 Selat joined #minetest-dev
11:51 ImQ009 joined #minetest-dev
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
13:16 proller joined #minetest-dev
13:54 hmmmm joined #minetest-dev
14:03 RealBadAngel joined #minetest-dev
14:03 RealBadAngel back
14:10 eugd joined #minetest-dev
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] <sapier> 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:11 ImQ009 joined #minetest-dev
15:18 rubenwardy joined #minetest-dev
15:21 Calinou joined #minetest-dev
15:27 Selat RealBadAngle: are lines 2-4 equal to "light_f = light_f * pow(light_amount, 1.0 / 2.2);"?
16:19 Calinou joined #minetest-dev
16:29 alexxs joined #minetest-dev
16:32 Krock http://i.imgur.com/4Lrr3.gif?1
16:46 Krock !tell sfan5 http://i.imgur.com/IpMxwtR.jpg
16:46 Krock left #minetest-dev
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 casimir joined #minetest-dev
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:04 sapier left #minetest-dev
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 Miner_48er joined #minetest-dev
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:36 OldCoder joined #minetest-dev
18:39 VanessaE I'm afraid I don't remember :(
18:40 rubenwardy Any idea? Is it definitely C++ code?
18:43 khonkhortisan joined #minetest-dev
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 rubenwardy left #minetest-dev
19:08 Calinou :O
19:08 Calinou I was searching
19:09 Calinou look at hud.cpp for waypoint code
19:19 hmmmm joined #minetest-dev
19:31 hmmmm joined #minetest-dev
20:00 SmugLeaf joined #minetest-dev
20:03 nore joined #minetest-dev
21:01 hmmmm joined #minetest-dev
21:36 khonkhortisan_ joined #minetest-dev
21:37 sapier joined #minetest-dev
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/h​obbies/minetest/screenshots/Screenshot%20​-%2008172014%20-%2006%3a05%3a11%20PM.png
22:06 VanessaE And with your patch:  http://digitalaudioconcepts.com/vanessa/h​obbies/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] <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: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 PenguinDad joined #minetest-dev
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
23:13 SoniEx2 joined #minetest-dev
23:22 kahrl joined #minetest-dev

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