| Time |
Nick |
Message |
| 00:00 |
kilbith |
no |
| 00:00 |
kilbith |
the text exceed way too much their emplacements |
| 00:00 |
kilbith |
this is not harmonious at all |
| 00:02 |
sapier |
screenshots please ;-) |
| 00:02 |
VanessaE |
kilbith: did you pull to latest git from less than about 2 hours ago? |
| 00:02 |
kilbith |
haven't compiled today, just took the .deb from 1h ago |
| 00:03 |
VanessaE |
idk if that's new enough, probably not |
| 00:04 |
kilbith |
well, the text excess is just for particular cases, but i still think that the scale text/gui elements ain't harmonious |
| 00:05 |
|
acerspyro joined #minetest-dev |
| 00:05 |
VanessaE |
kilbith: pull, compile, set in minetest.conf: gui_scaling = 0.85 and comment-out any font size settings |
| 00:05 |
VanessaE |
see what that does. |
| 00:05 |
kilbith |
if you choose a readable enough font size, you'll have a gross gui elements |
| 00:05 |
VanessaE |
then play around with the gui scale after that initial test. |
| 00:06 |
kilbith |
if you choose a plesant gui elements scaling, the text become hardly readable |
| 00:06 |
kilbith |
in either cases, that aint good |
| 00:07 |
VanessaE |
sapier: sounds like another vote for setting the default fonts to fixed relative scale... |
| 00:08 |
sapier |
I haven't seen a screenshot and I'm not gonna consider "i don't like the change" comments any longer |
| 00:09 |
sapier |
I can't do any tuning if ppl don't tell me WHAT is wrong ... this will always be a change no matter what we do |
| 00:11 |
sapier |
don't get me wrong I'm eager to fix it but I can't do this without your help! |
| 00:11 |
VanessaE |
you might want to wait for him to sign on again :) |
| 00:11 |
VanessaE |
I've already given all the input I can, everything further will just be more "I don't like it" :P |
| 00:11 |
sapier |
I don't think he's gonna provide the screenshot I already asked twice |
| 00:12 |
VanessaE |
he might, he's pretty good about that normally. |
| 00:12 |
acerspyro |
lol |
| 00:12 |
ShadowNinja |
Wow, the Android build is a lot better that it used to be. |
| 00:12 |
sapier |
well it's quite natural we need to tune this to get a acceptable state |
| 00:12 |
ShadowNinja |
It actually seems releasable. |
| 00:12 |
sapier |
ShadowNinja: we could have had this way before the changes are quite minor |
| 00:13 |
ShadowNinja |
I can use a 100ish viewing range. |
| 00:13 |
sapier |
well as of performance I didn't change anything |
| 00:13 |
|
n4x joined #minetest-dev |
| 00:13 |
sapier |
if there's improvement it's withing minetest core |
| 00:14 |
ShadowNinja |
sapier: Yes, probably Zeno's improvements. |
| 00:14 |
sapier |
what did he change? |
| 00:14 |
VanessaE |
what *didn't* he change would gather a shorter response ;) |
| 00:15 |
sapier |
well I've only seen the things he broke by now ;-) |
| 00:16 |
sapier |
I don't have a significant fps increase on my device ... maybe your memory is biased ShadowNinja ;-) |
| 00:16 |
VanessaE |
sapier: zeno's changes have increased performance at VE-Survival spawn by at least 50%. |
| 00:17 |
sapier |
so now you have 7fps? |
| 00:17 |
VanessaE |
what was 20 or less at 35m is now ~35 fps at ~50 meters |
| 00:17 |
VanessaE |
variable, of course, but that seems to be the average |
| 00:17 |
acerspyro |
VanessaE: when did his changes happen? |
| 00:17 |
VanessaE |
in other areas, it now hits the upper limit of 30 fps/240m but rarely |
| 00:17 |
sapier |
did you try on your tablet? I remember you had about 5 fps there when we last tried the android client |
| 00:18 |
VanessaE |
acerspyro: over the past few months |
| 00:18 |
acerspyro |
k |
| 00:18 |
VanessaE |
sapier: oh G*d no, not that poor little thing :) |
| 00:18 |
VanessaE |
I was talking about desktop performance :) |
| 00:18 |
sapier |
well it's a good benchmark |
| 00:18 |
acerspyro |
Why would god be a swear? |
| 00:18 |
VanessaE |
acerspyro: offtopic. |
| 00:18 |
VanessaE |
sapier: actuall my tab can't get to VE-Survival but on Vanilla it was like 3 fps at best. |
| 00:19 |
acerspyro |
Oh you people, such a nonsensical mystery sometimes. |
| 00:19 |
ShadowNinja |
sapier: No, it's actually unable with full viewing range now, as long as I don't explore a lot and look back. |
| 00:20 |
sapier |
well no matter why, it's good to be better now |
| 00:20 |
ShadowNinja |
I noticed that the enable/disable buttons are very touchy though. One tap and turn then off and back on before you lift your finger. |
| 00:21 |
sapier |
if they did use same code as control keys key repeat is about 0.2 s |
| 00:22 |
sapier |
which is same as on pc but there you have some mechanical delay till a button is pressed ;-) |
| 00:23 |
ShadowNinja |
sapier: Sound volume menu seems to freeze it. |
| 00:24 |
sapier |
yes that one isn't switched to formspec by now ... who did reenable it on android? thought it's hidden? |
| 00:26 |
sapier |
maybe we should write an issue for it |
| 00:32 |
|
n4x joined #minetest-dev |
| 00:32 |
|
sapier left #minetest-dev |
| 00:57 |
|
shadowzone joined #minetest-dev |
| 01:45 |
|
y joined #minetest-dev |
| 01:54 |
|
younishd joined #minetest-dev |
| 01:55 |
|
younishd joined #minetest-dev |
| 02:07 |
|
n4x joined #minetest-dev |
| 02:50 |
kaeza |
hmmmm, https://gist.github.com/kaeza/e31abc665441272ec0d8 |
| 02:52 |
hmmmm |
i'm not gonna lie that's an odd error |
| 02:52 |
hmmmm |
could it be that you somehow paired a newer set of builtin scripts with an outdated engine? |
| 02:54 |
kaeza |
git pull says up to date |
| 02:54 |
kaeza |
oh shit |
| 02:54 |
kaeza |
note to self: compile after pulling |
| 02:54 |
VanessaE |
lol |
| 02:55 |
hmmmm |
yeah that'd do it |
| 02:55 |
kaeza |
sorry hmmmm |
| 02:55 |
hmmmm |
np |
| 03:06 |
hmmmm |
hey guys, in the whole formspec crazyness, have any of you noticed if static GUIs such as the volume changer has text that gets cut off with a higher DPI setting? |
| 03:45 |
|
compunerd joined #minetest-dev |
| 04:47 |
hmmmm |
okay, I'm boggled |
| 04:47 |
VanessaE |
that can't be good :P |
| 04:47 |
hmmmm |
how do formspec tabs perform the actual tab switching |
| 04:47 |
hmmmm |
I literally am unable to figure this out |
| 04:47 |
VanessaE |
they switch out the whole formspec page |
| 04:47 |
hmmmm |
where. |
| 04:48 |
hmmmm |
i don't see it |
| 04:48 |
VanessaE |
that I don't know, but that's how other formspecs do it. a control button sets a whole new formspec from scratch., |
| 04:48 |
VanessaE |
-m |
| 04:48 |
VanessaE |
+m-, |
| 04:51 |
hmmmm |
i see where get_formspec() is being called in ui.update() |
| 04:51 |
hmmmm |
but i don't see where the tab being switched to gets inserted into ui.childlist |
| 04:52 |
hmmmm |
VanessaE, back in 0.4.5 and whatever do you remember the bottom of the transparent main menu increasing opacity in a gradient? |
| 04:53 |
hmmmm |
maybe this is an irrlicht 1.8 thing |
| 04:53 |
VanessaE |
not in the main menu, no. but I seem to remember there being a similar effect in some in-game formspecs |
| 04:53 |
hmmmm |
hrm |
| 04:53 |
hmmmm |
well whatever |
| 04:53 |
hmmmm |
I am not wasting time on such BS |
| 04:53 |
VanessaE |
(which I mimic in dreambuilder's formspec images) |
| 04:54 |
hmmmm |
i already wasted enough |
| 04:55 |
VanessaE |
so in that case you'll just rewrite the whole fucking thing ;) |
| 05:09 |
|
paramat joined #minetest-dev |
| 05:28 |
|
chchjesus joined #minetest-dev |
| 05:51 |
hmmmm |
naahhh |
| 05:51 |
hmmmm |
so i'm writing some dumb gui code |
| 05:51 |
hmmmm |
this is so stupidly easy, it should take me like an hour |
| 05:51 |
hmmmm |
i'm going to time myself. if i can't finish this in 1 hour, i'm messed in the head |
| 06:26 |
|
cib0 joined #minetest-dev |
| 06:48 |
|
Hunterz joined #minetest-dev |
| 06:58 |
|
Player_2 joined #minetest-dev |
| 07:07 |
|
gregorycu joined #minetest-dev |
| 07:08 |
|
AnotherBrick joined #minetest-dev |
| 07:16 |
|
CraigyDavi joined #minetest-dev |
| 07:23 |
paramat |
celeron55 and others, this needs to be reverted https://github.com/minetest/minetest/commit/1c9f05d792562374046e74ad3eb75988d529b15c step smoothing is now extremely mushy and sluggish, it now takes a whole second for the camera to rise when climbing a step, the camera sinks significantly down towards the stairs. i tested the old and new values on a long 1:1 staircase |
| 07:25 |
paramat |
there was nothing wrong with the old value, smoothing has to be subtle while still feeling agile and responsive |
| 07:28 |
paramat |
we really need an active audio visual manager with very similar tastes to c55 |
| 07:30 |
|
Taoki[mobile] joined #minetest-dev |
| 07:32 |
paramat |
other stupid changes to Minetest include: fall bobbing when the player has no knees, and camera-tilt on damage which is an unnecessary copy of Minecraft |
| 07:36 |
paramat |
i would trust hmmmm to be the new AV manager/decision maker |
| 07:47 |
paramat |
here's another example of mindless Minecraft copying https://github.com/minetest/minetest/pull/1953 which i am trying to sort out |
| 08:27 |
|
crazyR joined #minetest-dev |
| 08:33 |
|
crazyR joined #minetest-dev |
| 08:46 |
paramat |
anyway nevermind those side issues, i should focus on the main issue which is the step smoothing, i'll make a pull request later for the original value O/ |
| 08:46 |
|
paramat left #minetest-dev |
| 08:48 |
|
jin_xi joined #minetest-dev |
| 09:02 |
|
kilbith joined #minetest-dev |
| 09:02 |
|
gregorycu joined #minetest-dev |
| 09:32 |
|
FR^2 joined #minetest-dev |
| 09:33 |
|
rubenwardy joined #minetest-dev |
| 09:34 |
rubenwardy |
We need more moderators on the forum - there have been lots of spam left for ages recently. Bots are now replying to topics with spam. |
| 09:34 |
rubenwardy |
Or we need captchas |
| 09:37 |
|
ImQ009 joined #minetest-dev |
| 10:02 |
|
Amaz joined #minetest-dev |
| 10:11 |
celeron55 |
with only two replies this is already starting to prove people have very different requirements for what is publishable quality: https://forum.minetest.net/viewtopic.php?f=3&t=10924 |
| 10:11 |
celeron55 |
not surprising, but doesn't really help |
| 10:32 |
|
iqualfragile joined #minetest-dev |
| 10:56 |
gregorycu |
I'll reply then |
| 10:57 |
gregorycu |
Ohh Android, cbf |
| 10:58 |
|
crazyR_ joined #minetest-dev |
| 11:18 |
|
sapier joined #minetest-dev |
| 11:18 |
sapier |
https://github.com/minetest/minetest/pull/2044 merging this one in a few minutes (memory leak fix) |
| 11:30 |
kilbith |
sapier: https://github.com/minetest/minetest/issues/2077 |
| 11:31 |
kilbith |
sorry for yesterday, it was very late here and i was hurry to lay down in bed |
| 11:31 |
sapier |
no problem I'm glad someone finaly provides the information I need |
| 11:32 |
kilbith |
it's me in that issue ^ |
| 11:34 |
sapier |
is this with or without freetype? |
| 11:34 |
kilbith |
with |
| 11:34 |
kilbith |
as i said in the issue |
| 11:34 |
kilbith |
"From the up-to-date Git HEAD (compiled one hour ago with Freetype)" |
| 11:35 |
sapier |
except from the mod config tab what exactly is the problem? |
| 11:37 |
sapier |
btw they're not adapted to android at all as It didn't even work there correct till yesterday ;-) |
| 11:37 |
kilbith |
the mod config is just a minor example, the main issue is the oversizing and the adequation GUI / font scaling |
| 11:38 |
sapier |
ok so in short your complain is "fonts are to big" ? |
| 11:38 |
kilbith |
if you set something good for GUI, you have a bad result for the fonts, and inversely |
| 11:39 |
kilbith |
not just "too big" |
| 11:39 |
kilbith |
read better the issue |
| 11:39 |
sapier |
but? |
| 11:39 |
sapier |
I did that's why I'm asking |
| 11:39 |
sapier |
fonts keep exactly SAME ratio to overal form size |
| 11:40 |
sapier |
(not counting rounding errors) |
| 11:40 |
kilbith |
1.0 -> extravagant // 0.85 -> GUI is OK but fonts large & skinny // 0.75 -> fonts are OK but GUI too shy |
| 11:41 |
sapier |
so you suggest adding a variable scale factor scaling fonts in a different way then the forms? |
| 11:41 |
kilbith |
it's not simply saying "that's too big", it's a matter of proportions between the GUI and fonts, and the fonts itself |
| 11:42 |
sapier |
to me that sounds same as "fonts are to big compared to menu" which is quite same as "fonts are to big" ;-) |
| 11:42 |
sapier |
which is interesting because I'm same oppinion but VanessaE insists on bigger fonts |
| 11:42 |
kilbith |
i simply suggest to rollback to the previous scaling way |
| 11:43 |
sapier |
there was no scaling before |
| 11:44 |
kilbith |
have you seen the 0.4.11 stable screenies ? |
| 11:44 |
sapier |
yes but I'm not talking about 0.4.11 where half of scaling was disabled breaking gui on everything not being 72 dpi |
| 11:45 |
sapier |
0.4.11 has a lot of code in it just to drop the result and use something else |
| 11:46 |
kilbith |
you thinks it's tolerable to have an initial scaling like that ? https://mediacru.sh/inmOiURnWiM6 |
| 11:46 |
kilbith |
-s |
| 11:46 |
kilbith |
users are not all myopic, eh... |
| 11:47 |
sapier |
I could live with it but to be honest I don't really care as long as the result is consistent ... and not crap like the way someone "tried to fix it for 0.4.11 |
| 11:48 |
kilbith |
ok, so the tabs eat the header's space but that's not a problem... |
| 11:48 |
sapier |
if there's a common agreement to reduce the font <-> form aspect I could live with it too |
| 11:49 |
sapier |
but I'm quite sure if I do reduce it now tomorrow someone will scream out "it's to small it's to small" |
| 11:50 |
kilbith |
no, that's just obvious actually |
| 11:50 |
sapier |
if VanessaE tells same I'm gonna change it because she was the one insisting most loud on bigger size ;-) |
| 11:51 |
kilbith |
bigger OK, but i guess you had an heavy hand on levelling-up the scaling |
| 11:52 |
sapier |
nope it's linear scaling |
| 11:53 |
sapier |
if form increases by factor 2 fonts increase by factor 2 ... well as fonts and forms are way different sizes this ain't true for font sizes < 5 |
| 11:53 |
kilbith |
sorry, i don't meant "levelling-up" for say "vertical" |
| 11:53 |
kilbith |
but levelling-up like enlarging overall |
| 11:53 |
sapier |
there's no differenc in horizontal and vertical scaling |
| 11:55 |
sapier |
those "skinny" font effects are rounding issues if you scale up and down a font. Irrlicht uses bitmap fonts only thus there ain't something like cleartype adjusting the overall result later |
| 11:58 |
kilbith |
no way to "bold" them ? |
| 11:58 |
|
ImQ009 joined #minetest-dev |
| 12:00 |
kilbith |
that'd look more substancial |
| 12:00 |
sapier |
well if we "Bold" it it's gonna be bold everywhere" |
| 12:00 |
sapier |
I'm not even sure if that conversion code does support it |
| 12:02 |
sapier |
no there's no "bold" setting in it |
| 12:02 |
sapier |
we could try disabling the antialiasing |
| 12:07 |
|
Megal joined #minetest-dev |
| 12:07 |
sapier |
no no disabling antialiasing ain't a good idea |
| 12:09 |
sapier |
hmm interesting |
| 12:23 |
sapier |
well autodetecting dpi results in increase of mainmenu ... maybe we should set default dpi different |
| 12:27 |
gregorycu |
I've noticed that the engine treats keys with similar labels the same |
| 12:27 |
gregorycu |
For instance, numpad 1 is the same as keyboard 1 |
| 12:27 |
gregorycu |
Is this a bug or a feature? |
| 12:27 |
sapier |
we don't do special keymapping it's most likely irrlicht behaviour |
| 12:28 |
gregorycu |
It's us |
| 12:28 |
gregorycu |
If you look at keycode.h and operator== |
| 12:28 |
gregorycu |
We match on key Char, not the Key value |
| 12:29 |
gregorycu |
For keys that have a character |
| 12:29 |
gregorycu |
Otherwise we fall back to key value |
| 12:29 |
sapier |
true ... never seen that code before |
| 12:30 |
sapier |
is there any reason to handle num key's different? |
| 12:30 |
gregorycu |
I think this means that people can't bind the num keys how they want |
| 12:30 |
gregorycu |
When num-lock is turned on |
| 12:31 |
sapier |
yes but on the other hand they can use it for quick select |
| 12:31 |
gregorycu |
Actually, I must be mistaken |
| 12:31 |
sapier |
if we didn't do it that way they couldn't |
| 12:31 |
sapier |
unless someone adds secondary /tertiary key bindings |
| 12:31 |
gregorycu |
Oh ok |
| 12:32 |
sapier |
still your question is valid ... guess if someone wants to spend this time it should be changed |
| 12:32 |
gregorycu |
So, seemingly by luck, you can actually bind things to the numpad, because of the way operator== was written |
| 12:33 |
gregorycu |
But I think this relies on the compilers implementation of std::list |
| 12:33 |
gregorycu |
Which is kinda funny |
| 12:34 |
sapier |
actually std::list is supposed to behave identical on different compilers ;-) |
| 12:35 |
gregorycu |
What I'm suggesting is that operator== is not symettrical |
| 12:35 |
gregorycu |
symmetrical |
| 12:35 |
gregorycu |
They way it is written here |
| 12:36 |
gregorycu |
If you flip the two arguments, you can get a different result :) |
| 12:36 |
gregorycu |
Which I think means it doesn't meet the requirement for comparable |
| 12:37 |
sapier |
in which situation isn't it symmetric? |
| 12:38 |
|
jluc joined #minetest-dev |
| 12:39 |
gregorycu |
So, a KeyPress object reduced is the Char, and the Key |
| 12:39 |
gregorycu |
Char is the label, Key is the code |
| 12:39 |
gregorycu |
With me? |
| 12:40 |
sapier |
yes |
| 12:40 |
gregorycu |
Wait, I'm mistaken |
| 12:41 |
gregorycu |
Sorry |
| 12:42 |
gregorycu |
Or am I? Hang on, I'm a little tired, and I'm sick |
| 12:42 |
sapier |
no problem :-) |
| 12:46 |
gregorycu |
No, I was mistaken, both parts of the or statement are tried, if only only one part of the or statement were tried, I would be correct |
| 12:46 |
gregorycu |
If you know know what I mean, it doesn't matter |
| 12:46 |
gregorycu |
dont' know |
| 12:46 |
sapier |
ok |
| 12:46 |
sapier |
I've to leave now, if you find out something different just write it I'm gonna read the log |
| 12:46 |
|
sapier left #minetest-dev |
| 12:48 |
kilbith |
dammit, we're heavily spammed today :( |
| 12:58 |
|
younishd joined #minetest-dev |
| 13:04 |
|
ElectronLibre joined #minetest-dev |
| 13:06 |
|
ElectronLibre left #minetest-dev |
| 13:07 |
|
jluc joined #minetest-dev |
| 13:09 |
|
crazyR joined #minetest-dev |
| 13:11 |
|
ElectronLibre joined #minetest-dev |
| 13:12 |
|
gregorycu joined #minetest-dev |
| 14:11 |
|
luizrpgluiz joined #minetest-dev |
| 14:11 |
luizrpgluiz |
hi, someone has forecast will come out when the new version of mapgen v8? |
| 14:11 |
|
shadowzone joined #minetest-dev |
| 14:26 |
|
SudoAptGetPlay joined #minetest-dev |
| 14:31 |
|
exio4 joined #minetest-dev |
| 14:36 |
FR^2 |
luizrpgluiz: My crystal ball is currently out of order, and the coffee grounds aren't that specific... ;) |
| 14:37 |
|
hmmmm joined #minetest-dev |
| 14:41 |
luizrpgluiz |
kkkkkkkk |
| 15:12 |
|
Player_2 joined #minetest-dev |
| 15:28 |
|
luizrpgluiz left #minetest-dev |
| 15:46 |
|
roniz joined #minetest-dev |
| 15:52 |
|
ElectronLibre joined #minetest-dev |
| 16:07 |
|
ElectronLibre joined #minetest-dev |
| 16:17 |
|
leat joined #minetest-dev |
| 16:37 |
|
ElectronLibre joined #minetest-dev |
| 16:40 |
|
twoelk joined #minetest-dev |
| 16:51 |
|
Calinou joined #minetest-dev |
| 16:52 |
|
kaeza joined #minetest-dev |
| 16:58 |
|
Krock joined #minetest-dev |
| 17:15 |
|
casimir joined #minetest-dev |
| 17:19 |
|
rubenwardy joined #minetest-dev |
| 17:26 |
|
acerspyro joined #minetest-dev |
| 17:26 |
|
Hunterz joined #minetest-dev |
| 17:35 |
|
ElectronLibre joined #minetest-dev |
| 17:39 |
|
sapier joined #minetest-dev |
| 17:43 |
sapier |
hmmmm tabs are switched in builtin/fstk/tabview.lua L91 |
| 17:44 |
sapier |
handle_tab_buttons detects if a pressed button is actually a tab selection event and changes the active tab |
| 17:44 |
sapier |
if button ain't a tab switch button the button event is passed to the current active tab |
| 17:45 |
hmmmm |
right.. which eventually calls switch_to_tab |
| 17:46 |
hmmmm |
which to my understanding just calls on_change if it's there, saves settings, and shuffles around the current tab |
| 17:46 |
sapier |
yes switch to tab is called on changing the tabs |
| 17:46 |
sapier |
no |
| 17:46 |
hmmmm |
AHHH |
| 17:46 |
sapier |
the tab itself ain't shuffled |
| 17:46 |
hmmmm |
it sets last_tab_index there |
| 17:46 |
sapier |
it just sets which tab is used |
| 17:46 |
hmmmm |
okay i understand how it works now |
| 17:47 |
sapier |
event handling and formspec generation are separate |
| 17:47 |
hmmmm |
i know |
| 17:48 |
sapier |
it's quite primitive ... well compared to things like qt ;) |
| 17:48 |
sapier |
and complex compared to html |
| 17:48 |
hmmmm |
no I just missed the part where last_tab_index gets set |
| 17:49 |
sapier |
ok don't bother to ask |
| 17:49 |
sapier |
btw there's an updated version of fstk as pull request fixing some issues left in there |
| 17:52 |
sapier |
that version adds support for tab specific data |
| 17:53 |
sapier |
but most of the new code is adding in game support |
| 17:55 |
|
srifqi joined #minetest-dev |
| 17:58 |
sapier |
ShadowNinja is it ok now: https://github.com/minetest/minetest/pull/2051 |
| 18:16 |
|
crazyR_ joined #minetest-dev |
| 18:34 |
|
kaeza joined #minetest-dev |
| 18:42 |
|
rubenwardy joined #minetest-dev |
| 18:50 |
|
proller joined #minetest-dev |
| 18:52 |
rubenwardy |
Is this a bug? https://forum.minetest.net/viewtopic.php?f=6&t=10938 |
| 18:54 |
sapier |
seems to be |
| 18:56 |
rubenwardy |
https://github.com/minetest/minetest/blob/master/src/hud.cpp#L162 |
| 18:56 |
rubenwardy |
It does take direction into account, but incorrectly. |
| 18:56 |
sapier |
I suggest you fix it and we merge the fix ;-) |
| 18:57 |
rubenwardy |
I will try |
| 18:57 |
sapier |
thanks :-) that's no less we all do ;-) |
| 19:01 |
rubenwardy |
bloody hell, the menu is massive |
| 19:03 |
sapier |
well we enabled automatic dpi adjustment |
| 19:03 |
sapier |
we may need to do some proper baseline adjustment |
| 19:03 |
sapier |
ok we enabled for linux ... win32 implementation is still missing |
| 19:09 |
rubenwardy |
fixed it |
| 19:09 |
rubenwardy |
pushing now |
| 19:09 |
rubenwardy |
The person who wrote and documentated HUD will be embarrassed |
| 19:11 |
rubenwardy |
#2081 |
| 19:12 |
rubenwardy |
Please unignore me, ShadowNinja |
| 19:12 |
rubenwardy |
https://github.com/minetest/minetest/pull/2081 |
| 19:12 |
sapier |
that simple? :-) |
| 19:12 |
rubenwardy |
Yes. |
| 19:12 |
rubenwardy |
Lol |
| 19:12 |
sapier |
and noone noticed by now ;-) |
| 19:14 |
rubenwardy |
It's a very simple mistake |
| 19:14 |
sapier |
things like that happen quite often |
| 19:14 |
rubenwardy |
Probably from when it was "pos" and "dir" |
| 19:15 |
rubenwardy |
That was fun. I feel like I know the maze a little bit better. |
| 19:15 |
sapier |
is there a pos property? |
| 19:15 |
|
roniz_ joined #minetest-dev |
| 19:15 |
rubenwardy |
It was called "pos" before it was renamed to "position" |
| 19:16 |
rubenwardy |
According to this, anyway. https://github.com/rubenwardy/minetest/blob/hud_direction/src/script/lua_api/l_object.cpp#L48 |
| 19:16 |
sapier |
better maybe you should handle it same way as for pos, someone may have found out "dir" works and you'd break it on changing |
| 19:17 |
rubenwardy |
ok |
| 19:21 |
rubenwardy |
Updated |
| 19:23 |
rubenwardy |
rebased |
| 19:50 |
sfan5 |
sapier: can i merge #2081? |
| 19:50 |
ShadowBot |
https://github.com/minetest/minetest/issues/2081 -- Fix direction property of HUD by rubenwardy |
| 19:51 |
sapier |
seems ok |
| 19:52 |
sfan5 |
merged |
| 19:52 |
rubenwardy |
Excellent |
| 20:13 |
kilbith |
sfan5: https://github.com/minetest/minetest_game/pulls |
| 20:24 |
|
crazyR joined #minetest-dev |
| 20:26 |
|
jluc joined #minetest-dev |
| 20:30 |
|
monte joined #minetest-dev |
| 20:31 |
|
eeew joined #minetest-dev |
| 20:49 |
|
prozacgod joined #minetest-dev |
| 21:58 |
|
Amaz joined #minetest-dev |
| 21:58 |
hmmmm |
for what it's worth, i didn't write all the documentation for hud |
| 22:04 |
|
acerspyro joined #minetest-dev |
| 22:06 |
|
kaeza joined #minetest-dev |
| 22:08 |
|
fz72 joined #minetest-dev |
| 22:10 |
|
fz72 joined #minetest-dev |
| 22:12 |
|
Amaz left #minetest-dev |
| 22:19 |
kilbith |
hmmmm: https://github.com/minetest/minetest/issues/2082 |
| 22:19 |
kilbith |
and i confirm the bug: https://lut.im/m4r9B9L4/ish6XWJC |
| 22:36 |
VanessaE |
kilbith: that's an old bug |
| 22:39 |
VanessaE |
the real question is why there are holes and floating lava in the first place |
| 22:54 |
sapier |
As you both are here right know VanessaE and kilbith can you please discuss what size the default font is supposed to be ? ;-) |
| 22:54 |
acerspyro |
4 |
| 22:56 |
kilbith |
ShadowNinja: you don't label my issues/PR on git for a particular reason ? |
| 22:57 |
|
ImQ009 joined #minetest-dev |
| 22:58 |
kilbith |
if it's not important for you, i can close them |
| 22:58 |
sapier |
give him time kilbith |
| 22:59 |
kilbith |
strangely the others one have labels except mines |
| 22:59 |
acerspyro |
You're special. |
| 22:59 |
sapier |
well maybe he has already seen how hot that topic is and doesn't want to burn his fingers ;-) |
| 23:00 |
kilbith |
acerspyro, ?? |
| 23:00 |
acerspyro |
jk |
| 23:01 |
kilbith |
sounds like disdain rather |
| 23:01 |
sapier |
kilbith: btw we don't have a label for "discussion" anyway |
| 23:02 |
kilbith |
discussion ? where ? |
| 23:03 |
kilbith |
nothing opened just for discussion |
| 23:06 |
ShadowNinja |
kilbith: I missed *one*. Fixed. |
| 23:12 |
sapier |
https://github.com/minetest/minetest/pull/2051 shadow good to merge with those changes? |
| 23:18 |
VanessaE |
sapier: imho, default font size everywhere should be around 10-11 point, this seems to be common on other desktop apps, with the option to increase it of course |
| 23:19 |
kilbith |
+1 and not skinny |
| 23:19 |
sapier |
it's not about a number it's about who big in relation to formspec itself it's supposed to be kilbith doesn't like it as big as it's now |
| 23:19 |
sapier |
kilbith: tell irrlicht guys to support freetype I can't fix this |
| 23:20 |
sapier |
if for some reason scaling factor happens to cause suboptimal font width to result from the only thing we could do was switching the font in total and hope it's not just gonna switch to a different size |
| 23:21 |
VanessaE |
sapier: I think what kilbith means is font hinting needs worked on |
| 23:21 |
kilbith |
well, it's to express our wishes through the words in that case |
| 23:21 |
kilbith |
it's hard* |
| 23:22 |
sapier |
we don't have anyone to fix the font code the only thing changed by font scaling is that all those existing issues now become visible |
| 23:22 |
VanessaE |
I get the impression that fonts are "full hinting" in minetest, if it were up to me, that default would be set to "none" or "slight" (or be user-adjustable, or better take it from the desktop environment settings) |
| 23:22 |
sapier |
if there's someone having any experience in font code details help is welcome |
| 23:23 |
kilbith |
i'll make some examples with Gimp, sapier |
| 23:23 |
sapier |
we don't have any support for bold italic or any other of those types |
| 23:23 |
sapier |
we only have shadows or now shadows |
| 23:23 |
VanessaE |
sapier: it's not a bold/italic thing - it's called hinting |
| 23:23 |
sapier |
kilbith: that's as helpfull as nothing |
| 23:24 |
sapier |
ttf font is translated to bitmap by a piece of code which is just copied from some forum ... it's always been that way but by now the font size was accidentally at exactly that size where the code resulted in reasonable output |
| 23:24 |
kilbith |
that's a demonstrative way for express what we want for the adequation gui/fonts |
| 23:25 |
sapier |
ok could help |
| 23:26 |
VanessaE |
as for relative size it's simple: what the default menu had in, say, 0.4.9 before any of the fonts were changed, but increase by around 10% in size. |
| 23:26 |
sapier |
argh |
| 23:27 |
sapier |
how to increase 12 by 10$ |
| 23:27 |
sapier |
10% |
| 23:27 |
VanessaE |
well, you could use paypal :P |
| 23:27 |
VanessaE |
sorry, bad joke :) |
| 23:27 |
sapier |
I don't even have a paypal account ;-P |
| 23:27 |
VanessaE |
well approximate it, 12*1.10 = 13.2 so round it to 13. |
| 23:28 |
VanessaE |
or even step it to the next whole number cna call it 14. |
| 23:28 |
VanessaE |
and* |
| 23:28 |
sapier |
which is only 8.3 percent |
| 23:28 |
VanessaE |
eh? |
| 23:28 |
sapier |
so you're gonna complain about missing 1.7% |
| 23:28 |
VanessaE |
10 percent over 12 is 12*1.10 = 13.2 |
| 23:28 |
VanessaE |
so round it up to 14 |
| 23:28 |
sapier |
ok I was at 13 |
| 23:28 |
VanessaE |
oh right |
| 23:29 |
sapier |
14 is even 16% |
| 23:29 |
VanessaE |
I'm just going with he assumption that you're stuck with whole numbers |
| 23:29 |
kilbith |
IMO, the GUI scaling is the best at 0.75 : https://cdn.mediacru.sh/9/9gZUXU_MfGlo.png |
| 23:29 |
sapier |
well that's about the old size where we did asume 72 dpi while almost everyone has 96 |
| 23:31 |
sapier |
but that's not the problem ;-) what about fonts? |
| 23:32 |
VanessaE |
in kilbith's screenshot, the fonts are actually quite sane imho |
| 23:32 |
VanessaE |
just a TAD small for me but tolerable |
| 23:33 |
kilbith |
nah, still skinny |
| 23:33 |
sapier |
isn't that a regular screenshot? |
| 23:33 |
kilbith |
define "regular" ? |
| 23:33 |
sapier |
meaning you didn't modify it manuall did you? |
| 23:33 |
VanessaE |
kilbith: you mean the fonts' weight is too light. |
| 23:33 |
kilbith |
oh no at all |
| 23:34 |
VanessaE |
kilbith: which means fonts hinting is st to "full" instead of "none" or "slight" |
| 23:34 |
VanessaE |
set* |
| 23:34 |
VanessaE |
that's the only way to fix the font weight |
| 23:34 |
VanessaE |
is to fix the hinting. |
| 23:35 |
VanessaE |
that doesn't require bold, it's just a setting to tweak in wherever the font rendering code is being called I guess |
| 23:35 |
sapier |
tell me what you mean with hinting? we don't seem to have a way to change it |
| 23:35 |
VanessaE |
sapier: http://en.wikipedia.org/wiki/Font_hinting |
| 23:35 |
VanessaE |
I mean this. |
| 23:35 |
VanessaE |
this is the problem kilbith is fighting with |
| 23:36 |
sapier |
well guys suggest a different ttf font |
| 23:36 |
sapier |
we can't configure this codewise |
| 23:36 |
VanessaE |
it's not a font issue |
| 23:36 |
kilbith |
hinting is just for adjust properly the "shapes" of the caracters, not helps them to gain weight and consistency |
| 23:36 |
VanessaE |
kilbith: actually, it does. |
| 23:37 |
VanessaE |
it will stop the sudden change in weight by changing size. |
| 23:38 |
kilbith |
well, you're prolly right |
| 23:38 |
sapier |
ok there's a function for font hinting hidden in our code but for what I see it's enabled anyway |
| 23:39 |
VanessaE |
sapier: disable it. |
| 23:39 |
VanessaE |
(link to the function?) |
| 23:40 |
sapier |
void CGUITTFont::setFontHinting(const bool enable, const bool enable_auto_hinting) |
| 23:40 |
VanessaE |
that's the one |
| 23:40 |
sapier |
those parameters are set to true by default |
| 23:41 |
VanessaE |
set the enable flag to false. |
| 23:41 |
VanessaE |
freetype's autohinter sucks anyway :P |
| 23:41 |
sapier |
well provide a better one ;-P |
| 23:41 |
VanessaE |
heh |
| 23:42 |
VanessaE |
can't, it's illegal :P |
| 23:42 |
VanessaE |
make it user-configurable for now, see if you can read it from the OS/desktop settings some time later in the future. |
| 23:42 |
sapier |
I don't think you want it disabled |
| 23:43 |
VanessaE |
how's it differ from what the same setting on my desktop env does? |
| 23:43 |
VanessaE |
hm, I talk good engrish ;) |
| 23:44 |
sapier |
it's a little bit more blury and at some size you get white boxes instead of a font |
| 23:44 |
VanessaE |
the slight blur is normal. |
| 23:44 |
VanessaE |
you're seeing the REAL render of the font |
| 23:44 |
sapier |
white boxes instead of text ain't |
| 23:44 |
VanessaE |
but the boxes? that's weird. |
| 23:45 |
sapier |
well it's antialiased too so not the "real" but you don't want the non antialiased fonts either |
| 23:45 |
VanessaE |
well you know what I meant ;) |
| 23:45 |
VanessaE |
vertical strokes are not being artifically lined up to screen pixels anymore |
| 23:46 |
sapier |
still that change wouldn't help anything |
| 23:46 |
VanessaE |
actually it would help his issue if not for those boxes. |
| 23:46 |
sapier |
could you guys try non freetype maybe it's better ;-P |
| 23:47 |
VanessaE |
because the artificial alignment of pixels causes it to jump from one-pixel-wide strokes to two-pixel wide once it hits a certain size |
| 23:47 |
VanessaE |
whereas without hinting, the font just gets a little bigger |
| 23:47 |
VanessaE |
that's why I hate hinting. |
| 23:47 |
sapier |
no they don't seem to be bigger at all |
| 23:47 |
VanessaE |
they do. I tried it and saw the same effect. |
| 23:48 |
VanessaE |
they dont' get bigger, just thicker |
| 23:48 |
VanessaE |
so at a certain size, roughly 24 on the old scale, 16 or so on the current scale (I think), the hinting causes the weight to change. |
| 23:48 |
VanessaE |
that's what kilbith is complaining about. |
| 23:48 |
sapier |
not even to a noticeable degree at our usual size |
| 23:49 |
VanessaE |
it's a hard issue to solve; you're right that bitmap fonts might be needed to solve it for him |
| 23:50 |
sapier |
freetype fonts are converted to bitmaps for irrlicht too so I don't see how it's supposed to solve the issue |
| 23:50 |
VanessaE |
he could always supply his own bitmaps ;) |
| 23:50 |
sapier |
we can just try to find another font which looks more thick at default size ... scale it a little bit and you're gonna have same issue again |
| 23:51 |
sapier |
if you set the scaling you see exactly this effect |
| 23:51 |
sapier |
every few steps the font looks thick compared to menu and then becomes thin again till it gets thick again |
| 23:52 |
sapier |
imho we can't "fix" the issue but just get some good looking initial value |
| 23:54 |
VanessaE |
idk what to do then |
| 23:54 |
acerspyro |
magix |
| 23:54 |
VanessaE |
get the size right and let the weight take care of itself; fix whatever's broken in the hinting setting, make that user configurable |
| 23:55 |
sapier |
talk to kilbith and find something both of you can live with VanessaE |
| 23:55 |
kilbith |
yep, DejaVu Sans font is intrinsically skinny at >14, FreeSans is better |
| 23:55 |
VanessaE |
FreeSans is fine by me - I can always select another font myself as well |
| 23:55 |
VanessaE |
I'm only concerned with well-defined, consistent *sizes* throughout the program |
| 23:56 |
VanessaE |
unless a mod explicitly changes the font size, it should default to and be rendered to some specific point size, whatever that is. that's all I'm worried about at this point. |
| 23:56 |
acerspyro |
monospace |
| 23:56 |
acerspyro |
There, fixed |
| 23:57 |
sapier |
kilbith: for what I see we have liberation sans |
| 23:58 |
VanessaE |
sapier: since when? I thought the default was Dejavu? |
| 23:58 |
kilbith |
sapier: this is not i notice in my client |
| 23:58 |
kilbith |
this is the DejaVu one here |
| 23:59 |
sapier |
are you sure you're using freetype? |
| 23:59 |
kilbith |
200% surze |
| 23:59 |
kilbith |
-z |
| 23:59 |
sapier |
because dejavu is non freetype |
| 23:59 |
sapier |
and for mono fonts |
| 23:59 |
kilbith |
well, i'm not mad, i compiled with freetype |
| 23:59 |
sapier |
I don't even have a dejavu ttf file in her |
