| 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/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] <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 |
