| Time |
Nick |
Message |
| 00:45 |
|
VanessaE joined #minetest-dev |
| 01:00 |
|
not^v joined #minetest-dev |
| 01:47 |
|
Zeno` joined #minetest-dev |
| 03:13 |
|
not^v joined #minetest-dev |
| 03:13 |
|
NakedFury joined #minetest-dev |
| 03:13 |
|
hmmmm joined #minetest-dev |
| 03:13 |
|
lanxu_ joined #minetest-dev |
| 03:13 |
|
deltib joined #minetest-dev |
| 03:13 |
|
Ritchie joined #minetest-dev |
| 03:13 |
|
proller joined #minetest-dev |
| 03:14 |
|
ShadowNinja joined #minetest-dev |
| 03:14 |
|
blaise joined #minetest-dev |
| 04:16 |
|
Miner_48er joined #minetest-dev |
| 05:31 |
|
nore joined #minetest-dev |
| 05:49 |
|
Miner_48er joined #minetest-dev |
| 06:24 |
|
OldCoder joined #minetest-dev |
| 06:28 |
|
Hunterz joined #minetest-dev |
| 06:50 |
|
OldCoder joined #minetest-dev |
| 06:56 |
|
Calinou joined #minetest-dev |
| 06:56 |
|
Krock joined #minetest-dev |
| 07:01 |
|
Miner_48er joined #minetest-dev |
| 07:08 |
|
jin_xi joined #minetest-dev |
| 07:42 |
|
hmmmm joined #minetest-dev |
| 08:50 |
|
sapier joined #minetest-dev |
| 08:57 |
|
Amaz joined #minetest-dev |
| 09:12 |
|
PenguinDad joined #minetest-dev |
| 10:11 |
|
Jordach joined #minetest-dev |
| 10:27 |
sapier |
https://github.com/minetest/minetest/pull/1304 any comments or good to merge? |
| 10:28 |
sapier |
https://github.com/minetest/minetest/pull/1457 pushing in a few minutes, it's been agreed on days ago but I didn't manage to push by now |
| 10:30 |
* Calinou |
idiocracy-check |
| 10:30 |
Calinou |
passed |
| 10:33 |
Krock |
those pulls looks good |
| 10:33 |
Krock |
-s |
| 10:40 |
sapier |
https://github.com/minetest/minetest/pull/1468 I'd like to cleanup and merge this one, basically I'd remove the removal of leveled api and completely cleanup freezmelt |
| 10:40 |
sapier |
comments? |
| 10:42 |
Krock |
yes. leveled is used by snow |
| 10:42 |
sapier |
ok freezmelt seams to be already dead so cleaning up most likely wont break anything |
| 10:42 |
sapier |
seems |
| 10:43 |
Krock |
I would agree to delete freezemelt and "year_days = 30" in the example file. leveled should stay |
| 10:43 |
sapier |
that's what I intended to change about it |
| 10:43 |
Krock |
great |
| 10:45 |
sapier |
but first I'm gonna merge some simple pulls |
| 10:46 |
sapier |
merging https://github.com/minetest/minetest/pull/1477 already agreed by two core devs |
| 10:46 |
sapier |
ok actually 3 if you count me too |
| 10:47 |
Krock |
hmm, I still wonder about line 711 on the bottom |
| 10:48 |
Jordach |
has anyone noticed while trying to connect to any server that sometimes you'll connect and get stuck in this grey world? |
| 10:48 |
Krock |
removing a file when rename returned a success... |
| 10:48 |
Krock |
Jordach, every 2nd connect to my local server |
| 10:49 |
Jordach |
Krock, my VM is random |
| 10:49 |
PenguinDad |
Krock: rename returns zero on success |
| 10:49 |
sapier |
Jordach: that's a known issue for some minetest client/server combinations whats your combination? |
| 10:49 |
Krock |
PenguinDad, and false on fail? |
| 10:49 |
Jordach |
sapier, VanessaE's survival server, VM BFD server |
| 10:49 |
Jordach |
and it'll stay in this void world until it either connects or times out |
| 10:49 |
sapier |
ohh |
| 10:50 |
Krock |
I ask because there's just a "if" forboolean values |
| 10:50 |
sapier |
then it may be another issue |
| 10:50 |
Jordach |
sapier, even locally it's randomised |
| 10:50 |
sapier |
since players aren't loaded on startup a player can be immediatly deleted because of block beeing full and player object can't be added |
| 10:51 |
PenguinDad |
Krock: http://www.cplusplus.com/reference/cstdio/rename/ |
| 10:51 |
Jordach |
sapier, my last pos on VE's server was ~-17km underground |
| 10:51 |
sapier |
if you have this case you should see one of those famous maxe objects messages |
| 10:51 |
Jordach |
with no objects in range |
| 10:51 |
sapier |
are you sure about that? ;-) |
| 10:51 |
Jordach |
sapier, she's removed all mobs |
| 10:51 |
Krock |
PenguinDad, still. it doesn't return boolean |
| 10:51 |
sapier |
yes but e.g. items from digging |
| 10:52 |
Jordach |
sapier, there aren't any things in that tunnel down |
| 10:52 |
sapier |
ok then I'd guess we've got a new issue |
| 10:52 |
Jordach |
(i remove dropped items and trash lots of cobble methodically) |
| 10:52 |
Jordach |
and while we're at it, why does the password field in client randomly access violation on hitting enter |
| 10:53 |
Jordach |
https://cdn.mediacru.sh/mUbnl1fjionf.png |
| 10:54 |
Jordach |
that's where i am, and there's nobody else or other objects at that range |
| 10:54 |
PenguinDad |
Krock: 0 is false in c++ |
| 10:55 |
Krock |
PenguinDad, stupid but okay... thx |
| 10:55 |
sapier |
Jordach: I suggest creating issues for those issues as I can't fix them on the fly ;-) |
| 10:56 |
Krock |
I noticed, it _always_ throws 2 access violation when I enter my password for my server... |
| 10:58 |
sapier |
as it's reproduceable I suggest running mt in gdb and providing a full backtrace ... could help finding it |
| 10:58 |
PenguinDad |
does gdb work on windows? |
| 10:58 |
Krock |
> gdb |
| 11:01 |
sapier |
but gdb is only usefull on mingw build windows ;-) |
| 11:01 |
sapier |
maybe not even there as official one is without debugging symbols |
| 11:09 |
|
asl joined #minetest-dev |
| 11:16 |
sapier |
can someone knowing l-systems code check this one https://github.com/minetest/minetest/pull/1543 ? |
| 11:27 |
|
casimir joined #minetest-dev |
| 11:28 |
|
proller joined #minetest-dev |
| 11:36 |
|
Exio4 joined #minetest-dev |
| 11:49 |
|
ImQ009 joined #minetest-dev |
| 11:50 |
RealBadAngel |
sapier, give me a minute |
| 11:50 |
sapier |
you get two minutes ;-P |
| 11:50 |
RealBadAngel |
no, i dont need to |
| 11:51 |
RealBadAngel |
the code is ok |
| 11:51 |
RealBadAngel |
problem was with squashing them |
| 11:51 |
sapier |
can we merge it the way it is now? |
| 11:51 |
RealBadAngel |
if you solve two commits per pull problem, then yes |
| 11:52 |
RealBadAngel |
and nobody else here knows l-system code, just me |
| 11:52 |
RealBadAngel |
zeno is the only one that got it |
| 11:53 |
sapier |
why? it's two different things for what I understood for this issue two commits are fine |
| 11:53 |
RealBadAngel |
i was told once and for all, that a pull has to be single commit |
| 11:53 |
PenguinDad |
sapier: your last commit messed up inventory textures for me https://cdn.mediacru.sh/6LctUsHwhllp.png |
| 11:54 |
sapier |
what's messed up there? |
| 11:55 |
PenguinDad |
sapier: look at the obsidian glass |
| 11:55 |
RealBadAngel |
sapier, i would like to push a few quick bugfixes, will you find a minute to review them? |
| 11:55 |
sapier |
sorry I don't know what "obsidian glass" is and how it should look like ;-) |
| 11:58 |
sapier |
can you show me what's wrong? |
| 12:00 |
PenguinDad |
this is how the inventory textures should like https://cdn.mediacru.sh/KGXWClSQZVcG.png |
| 12:01 |
sapier |
hmm |
| 12:01 |
sapier |
seems like cleanup fails |
| 12:06 |
sapier |
wonder why this doesn't happen for me ... can you try adding: |
| 12:06 |
sapier |
driver->draw2DRectangle(video::SColor(0,0,0,0), core::rect<s32>(0, 0, 64, 64)); |
| 12:06 |
sapier |
to tile.cpp line 870? |
| 12:08 |
RealBadAngel |
btw, why the heck sandstone stairs/slab is breakable by hand? |
| 12:08 |
casimir |
because sandstone is |
| 12:09 |
RealBadAngel |
why? |
| 12:09 |
RealBadAngel |
since when one could dig STONE with bare hands? |
| 12:10 |
sapier |
depends of variant of sandstone ;-) |
| 12:10 |
PenguinDad |
sapier: that doesn't help |
| 12:11 |
RealBadAngel |
sapier, propably only mt variant can be dug with hands ;) |
| 12:11 |
sapier |
PenguinDad: in this cas I'm just gonna revert it and forget about that fix as preloading is disabled by now the issue became way less important |
| 12:12 |
sapier |
hmm wait ... |
| 12:12 |
sapier |
maybe drawing is just wrong |
| 12:13 |
sapier |
can you set 64, 64 to 800,600 (or what ever your screensize is) ... just for testing not as fix |
| 12:17 |
PenguinDad |
When I do that it's even more messed up |
| 12:18 |
sapier |
ok was worth a try let's forget about that fix |
| 12:19 |
sapier |
reverted |
| 12:21 |
RealBadAngel |
is github workin for you? |
| 12:23 |
sapier |
yes |
| 12:38 |
|
RealBadAngel joined #minetest-dev |
| 12:39 |
RealBadAngel |
sapier, https://github.com/RealBadAngel/minetest/commit/c8c203c35497d7ed8b3382df966dd7ef0ff525ff |
| 12:40 |
sapier |
is there any visual difference? |
| 12:40 |
RealBadAngel |
please note that finalColorBlend in shaders is already deprecated, in ::animate its done on CPU side always |
| 12:40 |
RealBadAngel |
no, there isnt |
| 12:40 |
RealBadAngel |
but youre free to try |
| 12:41 |
RealBadAngel |
only difference is more FPS when shaders enabled |
| 12:41 |
sapier |
well without knowing where to look I'll not find it anyway ... as it's way less code merge it |
| 12:41 |
RealBadAngel |
point is CPU one is done only on ratio change |
| 12:41 |
RealBadAngel |
while on GPU its calculated on each render pass |
| 12:42 |
RealBadAngel |
if some1 will stop the time flow, it will be done just on mesh refresh |
| 12:44 |
sapier |
sounds like a good idea |
| 12:44 |
RealBadAngel |
https://github.com/minetest/minetest/blob/master/src/mapblock_mesh.cpp#L1332 |
| 12:44 |
RealBadAngel |
heres ::animate |
| 12:44 |
RealBadAngel |
as you can see its already done CPU side always, no matter if shaders are used |
| 12:52 |
RealBadAngel |
next one: https://github.com/minetest/minetest/blob/master/src/content_mapblock.cpp#L381 and https://github.com/minetest/minetest/blob/master/src/content_mapblock.cpp#L222 |
| 12:53 |
RealBadAngel |
first is flowing liquid, second source |
| 12:53 |
sapier |
sorry but how shall I check the diff from lines ? |
| 12:54 |
RealBadAngel |
first have that code that makes liquids that are light sources glow or adapt to surrounding nodes |
| 12:54 |
RealBadAngel |
second doesnt |
| 12:54 |
sapier |
come one rba do at least a git diff and post it to gist |
| 12:54 |
RealBadAngel |
im showing you current state |
| 12:55 |
RealBadAngel |
somebody who made the code for flowing ones, forgot bout sources |
| 12:55 |
sapier |
you don't need to I already agreed to that https://github.com/RealBadAngel/minetest/commit/c8c203c35497d7ed8b3382df966dd7ef0ff525ff change |
| 12:56 |
RealBadAngel |
sapier, im talkin now bout another issue |
| 12:56 |
RealBadAngel |
<RealBadAngel> next one: https://github.com/minetest/minetest/blob/master/src/content_mapblock.cpp#L381 and https://github.com/minetest/minetest/blob/master/src/content_mapblock.cpp#L222 |
| 12:56 |
RealBadAngel |
this is code for liqiud drawtypes |
| 12:56 |
sapier |
that's what I meant with diff |
| 12:57 |
RealBadAngel |
ok, i will prepare the pull, hold on |
| 12:57 |
sapier |
you wrote it you know what you did change but I don't know and a single line number won't tell me ;-) |
| 12:57 |
RealBadAngel |
huh i pasted you links to unchanged code for you to see thats bwoken ;) |
| 12:58 |
RealBadAngel |
the second shall have the very same code as first does |
| 12:59 |
sapier |
am I supposed to reevaluate whats broken if you already found out? ;-) |
| 13:00 |
RealBadAngel |
nah, i will just prepare it |
| 13:00 |
sapier |
ok :-) |
| 13:02 |
RealBadAngel |
btw, thats gonna fix acid liquid issue from Carbone |
| 13:05 |
RealBadAngel |
i do have quite long list of bugfixes for today ;) |
| 13:05 |
sapier |
well if you did start creating pull requests ppl could have a look for them |
| 13:05 |
RealBadAngel |
problem is all are in very same files |
| 13:06 |
sapier |
one pull multiple commits ... allowed for minor changes |
| 13:06 |
sapier |
at least if all of them are bugfixes and not feature changes ;-) |
| 13:07 |
RealBadAngel |
for features i do have pulls open |
| 13:08 |
RealBadAngel |
thx to that folks can test them |
| 13:08 |
RealBadAngel |
and im not in hurry with them |
| 13:10 |
RealBadAngel |
btw nice to see 60fps on my box again |
| 13:12 |
|
hmmmm joined #minetest-dev |
| 13:25 |
sapier |
https://github.com/minetest/minetest/pull/1475 comments? vanessaE is running this on her servers for some days now (unless she forgot to reapply on update) ... reduces felt lag drastically |
| 13:38 |
|
eugd joined #minetest-dev |
| 13:41 |
sapier |
https://github.com/minetest/minetest/pull/1491 pushing in a few minutes |
| 13:42 |
eugd |
test |
| 13:42 |
|
eugd left #minetest-dev |
| 13:43 |
sapier |
well you won't see anything on pc version ;-) |
| 13:43 |
sapier |
at least until https://github.com/minetest/minetest/pull/1490 is merged too |
| 13:43 |
|
eugd joined #minetest-dev |
| 13:43 |
sapier |
eugd: read log ;-) |
| 13:46 |
sapier |
hmm no I was wrong :-) you can see it as "fixed" size is broken |
| 13:52 |
sapier |
https://github.com/minetest/minetest/pull/1490 comments? this is a visual change so it's most likely be controversion yet it's improving consistency quite a lot |
| 13:53 |
RealBadAngel |
sapier, offtopic, i need separate tab for shaders |
| 13:53 |
sapier |
original reason not to scale menu was because of gui elements not scaling itself as we added it we don't need that workaround |
| 13:53 |
sapier |
no |
| 13:53 |
RealBadAngel |
theres no place left |
| 13:53 |
sapier |
settings need to be cleant up anyway |
| 13:53 |
sapier |
I suggest adding subtabs |
| 13:53 |
RealBadAngel |
could work |
| 13:54 |
RealBadAngel |
i need to add about 10+ settings |
| 13:54 |
sapier |
does work http://animalsmod.bplaced.net/screenshots/v2_4/new_menu/multilevel_tabs.jpg |
| 13:54 |
RealBadAngel |
theres place for one or two more |
| 13:55 |
RealBadAngel |
that looks ok |
| 13:55 |
sapier |
maybe we need to update fstk as did some bugfixes to use it from ingame |
| 13:55 |
sapier |
but those are minor changes |
| 13:56 |
sapier |
if you need it I'm gonna merge it back to my fstk pull |
| 13:56 |
RealBadAngel |
i want to add contrast, brightness, gamma, parallax settings, bumpmapping settings, lava/water shaders settings (whole bunch of them) |
| 13:56 |
sapier |
ok I'm rebasing that pull including latest fixes from mobf |
| 13:57 |
sapier |
pushing table scrollbar scaling now |
| 13:59 |
RealBadAngel |
btw, Calinou did great job with dirt with grass node |
| 13:59 |
RealBadAngel |
i like its look |
| 14:00 |
sapier |
https://github.com/sapier/animals_modpack/blob/master/mobf_settings/tab_info.lua is an example how subtabs work |
| 14:01 |
RealBadAngel |
http://i.imgur.com/PJO3WVS.png |
| 14:01 |
sapier |
https://github.com/minetest/minetest/pull/1343 these are the changes required for them to work ... actually it's a little bit more, with this changes you could use fstk in game too |
| 14:02 |
RealBadAngel |
thx, gonna use that example |
| 14:02 |
RealBadAngel |
so merge it, we need them |
| 14:03 |
hmmmm |
oh man |
| 14:03 |
hmmmm |
so it's official, you're making a Lua irrlicht widget toolkit |
| 14:03 |
RealBadAngel |
lol |
| 14:03 |
sapier |
hmmmm did you miss it's already in? ;) |
| 14:03 |
hmmmm |
wow |
| 14:03 |
hmmmm |
all i can say is great job |
| 14:04 |
sapier |
whole menu is based upon it as I was annoyed about writing same code for each tab over and over again |
| 14:04 |
hmmmm |
but overkill... if I were you I would've been looking to integrate a pre-existing OGL widget toolkit |
| 14:04 |
RealBadAngel |
hello hmmmm |
| 14:04 |
hmmmm |
the job of minetest is to be a game |
| 14:04 |
hmmmm |
hi RBA |
| 14:04 |
hmmmm |
minetest sucks |
| 14:04 |
RealBadAngel |
hmmmm, could you at least do something with jungle grass? |
| 14:04 |
hmmmm |
I should definitely do something |
| 14:04 |
hmmmm |
I feel like a useless sack of shit who doesn't contribute anything |
| 14:05 |
sapier |
well it's been way more easy to improve main menu then rewriting everything based uppon a new toolkit ... not even talking about the discussions ;-) |
| 14:05 |
RealBadAngel |
hmmmm, all of us have such "periods" ;) |
| 14:05 |
sapier |
I did rewrite menu once ... I know what I'm talking about ;-) |
| 14:05 |
hmmmm |
jungle grass.... |
| 14:05 |
RealBadAngel |
yup |
| 14:05 |
hmmmm |
hrm |
| 14:05 |
RealBadAngel |
move it to lua side |
| 14:05 |
hmmmm |
I'd have to make an override to explicitly set the blockseed offset for a decoration |
| 14:06 |
eugd |
it's obvious menu should be lua side |
| 14:06 |
hmmmm |
and I'd also have to somehow make it share the same perlin noise as the jungle trees |
| 14:06 |
RealBadAngel |
so move the trees too |
| 14:06 |
hmmmm |
agh |
| 14:06 |
RealBadAngel |
jungles are kinda exception rite now |
| 14:07 |
RealBadAngel |
thus not moddable |
| 14:07 |
hmmmm |
but |
| 14:07 |
hmmmm |
they are disable-able |
| 14:07 |
RealBadAngel |
but thats not the point |
| 14:07 |
hmmmm |
I need to spend time coming up with an elegant non-hack solution to this |
| 14:08 |
hmmmm |
also I think decorations somehow got foobared a while ago |
| 14:08 |
RealBadAngel |
start with trashing c++ code, and do that in lua from scratch, like other things are done |
| 14:08 |
hmmmm |
did you notice how cacti gather up in clumps |
| 14:08 |
RealBadAngel |
yup, i know the code |
| 14:08 |
hmmmm |
they USED TO WORK FINE until somebody messed around with something |
| 14:09 |
RealBadAngel |
you really should develop decorations for v7 |
| 14:10 |
RealBadAngel |
v6 is too messed up |
| 14:10 |
RealBadAngel |
see caves for example |
| 14:10 |
RealBadAngel |
i cant believe theyre carved in CONTENT_IGNORE |
| 14:10 |
hmmmm |
that is not messed up |
| 14:10 |
hmmmm |
that's how it's supposed to work |
| 14:10 |
hmmmm |
is it causing problems? |
| 14:10 |
RealBadAngel |
ofc it is |
| 14:10 |
hmmmm |
how |
| 14:10 |
RealBadAngel |
see the checks |
| 14:10 |
hmmmm |
the checks? |
| 14:11 |
RealBadAngel |
theyre checking for water, lava and air |
| 14:11 |
RealBadAngel |
yes? |
| 14:11 |
RealBadAngel |
to let the cavegen do anything |
| 14:11 |
RealBadAngel |
but |
| 14:11 |
hmmmm |
☑ ☑ ☑ |
| 14:11 |
RealBadAngel |
theres no block generated yet |
| 14:11 |
RealBadAngel |
so theres no water/lava/air yet |
| 14:11 |
RealBadAngel |
check hits the floor |
| 14:11 |
hmmmm |
yes |
| 14:11 |
hmmmm |
can you come up with something better |
| 14:12 |
hmmmm |
I sure can't |
| 14:12 |
hmmmm |
this problem will sorta just go away when I add in the perlin noise defined caves in v7 |
| 14:12 |
RealBadAngel |
dont let cavegen operate on non existant block simply |
| 14:12 |
hmmmm |
you get walled-off caves then |
| 14:12 |
sapier |
hmm didn't I have some get_surface pull request by some time |
| 14:12 |
RealBadAngel |
wait a second |
| 14:13 |
hmmmm |
what would you rather, occasional messiness with lava and water, or a horizontal, straight wall of stone spanning the entire boundary of the chunk |
| 14:13 |
RealBadAngel |
caves are made on perlin, right? |
| 14:13 |
hmmmm |
they aren't right now |
| 14:13 |
hmmmm |
they're based off of pseudorandom |
| 14:13 |
RealBadAngel |
oh i see |
| 14:13 |
hmmmm |
that is the issue |
| 14:13 |
RealBadAngel |
now i get it |
| 14:13 |
hmmmm |
you can't poll a specific location to see if part of a cave is present |
| 14:14 |
RealBadAngel |
so they should be |
| 14:14 |
RealBadAngel |
and then overlayed but only on existing blocks |
| 14:15 |
casimir |
sapier: on #1490 the left handed text starts to disappear when increasing the window size. |
| 14:15 |
RealBadAngel |
this way checks for content will have sense |
| 14:16 |
RealBadAngel |
and we wont have caves in the air |
| 14:17 |
RealBadAngel |
https://github.com/minetest/minetest/blob/master/src/cavegen.cpp#L251 |
| 14:17 |
RealBadAngel |
https://github.com/minetest/minetest/blob/master/src/cavegen.cpp#L266 |
| 14:17 |
RealBadAngel |
by now above checks are obsolete |
| 14:18 |
RealBadAngel |
they never find air |
| 14:18 |
sapier |
haven't caves in air been intentionally to make surface more interesting |
| 14:18 |
sapier |
thanks casimir I'm gonna recheck |
| 14:18 |
RealBadAngel |
only check for content ignore can stop the code |
| 14:19 |
RealBadAngel |
thats why i made this pull: https://github.com/minetest/minetest/pull/1554 |
| 14:20 |
RealBadAngel |
but it really cuts off caves to surface, havent thought about nyanlands ;) |
| 14:21 |
RealBadAngel |
btw, hmmmm, v7 does pretty the same but in other way |
| 14:21 |
RealBadAngel |
there are no floating caves in v7 |
| 14:23 |
sapier |
RealBadAngel: didn't you have issues with vertlabels lately? |
| 14:28 |
hmmmm |
what?? |
| 14:28 |
hmmmm |
RealBadAngel, no |
| 14:35 |
|
jin_xi joined #minetest-dev |
| 14:38 |
hmmmm |
see my recent comment on the pull request |
| 14:38 |
hmmmm |
i need to go right now |
| 14:38 |
hmmmm |
later |
| 14:41 |
sapier |
casimir can you check again? I fixed vert label scaling |
| 15:03 |
VanessaE |
ob G*d someone PLEASE do something about these hangs in minetest_game |
| 15:04 |
VanessaE |
this is getting out of hand. |
| 15:04 |
VanessaE |
oh* |
| 15:04 |
casimir |
sapier: it works now |
| 15:05 |
sapier |
VanessaE RealBadAngel any problems with making main menu scale? |
| 15:06 |
VanessaE |
sapier: that's in mainline now? |
| 15:06 |
sapier |
not yet |
| 15:06 |
VanessaE |
link? |
| 15:06 |
sapier |
https://github.com/minetest/minetest/pull/1490 |
| 15:06 |
VanessaE |
just found it :P |
| 15:07 |
RealBadAngel |
sapier, im on the bugs right now, will play with menu propably tommorow |
| 15:07 |
VanessaE |
sapier: one minute, lemme give it a shot. |
| 15:08 |
sapier |
as font size and other gui components now scale to dpi fixed size main menu has issues. And those things not scaling have been initial reason for not scaling the menu |
| 15:08 |
sapier |
well RealBadAngel as this is a gui change I already expect someone to complain right after merge ;-) |
| 15:08 |
sapier |
no matter when it's merged |
| 15:08 |
VanessaE |
http://xkcd.com/303/ |
| 15:09 |
VanessaE |
wow |
| 15:09 |
RealBadAngel |
sapier, we are developing soft, nobody expects dev to be stable |
| 15:10 |
VanessaE |
sapier: the scaling seems to work, but there's one caveat: the spacing between elements doesn't really look good. |
| 15:10 |
sapier |
"nobody expects dev to be stable" I'll quote you ;-) |
| 15:10 |
VanessaE |
about the pause menu: frankly, it's too big with my window maximized. |
| 15:11 |
sapier |
did you maximize manually or per config file? |
| 15:11 |
VanessaE |
manually. |
| 15:11 |
VanessaE |
sapier: what I mean is, for example, the size of a button doesn't change, only its position does. I'm not sure this is desireable |
| 15:11 |
sapier |
there's a mayor difference |
| 15:11 |
|
khonkhortisan joined #minetest-dev |
| 15:11 |
sapier |
font size can#t be changed on the fly by now |
| 15:12 |
VanessaE |
I never use the config file to set window size. |
| 15:12 |
VanessaE |
wait, let me qualify that: |
| 15:12 |
VanessaE |
the HEIGHT of the buttons doesn't change |
| 15:12 |
VanessaE |
but the width does. |
| 15:12 |
VanessaE |
and the spacing between them does |
| 15:12 |
VanessaE |
as well as the size of elements like list boxes et al. |
| 15:12 |
sapier |
yes because height depends on font size |
| 15:13 |
VanessaE |
I'm not sure if the overall effect is desirable. |
| 15:13 |
sapier |
in current menu you'll not be able to read text if you set screen to maximized via config |
| 15:13 |
VanessaE |
the pause menu is definitely way too big: LOTS of wasted space there. |
| 15:14 |
sapier |
even if you set per config? |
| 15:15 |
VanessaE |
? |
| 15:16 |
sapier |
screenW/screenH .... hmm maybe it'd be more easy to find a way to fix the fonts too ... give me a couple of minutes |
| 15:16 |
VanessaE |
um |
| 15:16 |
VanessaE |
that's stupid. |
| 15:16 |
VanessaE |
I'm not gonna set those values. |
| 15:16 |
sapier |
well try it ;-) right now menu is gonna be broken if you do ;-) |
| 15:17 |
VanessaE |
no, better to just disable menu scaling on PCs |
| 15:17 |
sapier |
that won't change the menu beeing broken because fonts still scale |
| 15:17 |
VanessaE |
it makes sense on tablets, but not on PC, frankly. |
| 15:17 |
VanessaE |
or maybe some kind of scale-to-fit would make more sense on a PC\ |
| 15:17 |
sapier |
did you realize theres 4k screens getting more and more popular on pc too? |
| 15:18 |
VanessaE |
yes but 99% of PC users don't have 4k screens |
| 15:18 |
sapier |
you don't wanna have a fixed size 6cm menu on that screen |
| 15:18 |
sapier |
still why criple a feature we already haveß |
| 15:18 |
VanessaE |
I would venture a guess that most PC users have a 1920x1080 screen or smaller. |
| 15:18 |
VanessaE |
I'm not saying to cripple it. |
| 15:18 |
sapier |
"most" is not a reason to criple it on high end machines |
| 15:18 |
VanessaE |
I'm saying that this implementation will not work into the future without some way to "fill" all of that unused space. |
| 15:18 |
sapier |
especially if current way of doing it is briken |
| 15:19 |
VanessaE |
the pause menu has no reason to be scaled at all except to fit the font, simply. |
| 15:19 |
sapier |
but it doesn't fit the font |
| 15:19 |
VanessaE |
I know. |
| 15:20 |
VanessaE |
the main menu, on the other hand, definitely needs to have its elements fill it. for example the world list and server list should take up the majority of their respective tabs. |
| 15:20 |
sapier |
because you need to change the distances too just making a button bigger for bigger fonts doesn't help |
| 15:20 |
VanessaE |
instead, you have all this wasted, blank space around the buttons |
| 15:20 |
VanessaE |
and all that blank space to the right of the server list, above the name/password field. |
| 15:20 |
sapier |
come on vanessaE set screenW and screenH and have a look at it then you know what I'm talking about |
| 15:20 |
VanessaE |
grrrrr |
| 15:21 |
sapier |
you'd be first to complain about "broken menu" if it was you used to set your window size that way |
| 15:21 |
VanessaE |
no effect. |
| 15:22 |
sapier |
do a screnshot ;-) |
| 15:22 |
VanessaE |
looks the same whether I maximize using my window manager or with those values |
| 15:22 |
sapier |
what's your screen size? |
| 15:23 |
VanessaE |
ok, one secong. |
| 15:23 |
VanessaE |
second* |
| 15:24 |
VanessaE |
1600x1200, two screens. |
| 15:25 |
VanessaE |
ok, on the left is 1560x1180 set via the config file. on the right, no setting at all and simply maximized via my window managerhttp://digitalaudioconcepts.com/vanessa/hobbies/minetest/screenshots/minetest-maxi.png |
| 15:25 |
VanessaE |
oops. hit enter too soon,. |
| 15:25 |
VanessaE |
http://digitalaudioconcepts.com/vanessa/hobbies/minetest/screenshots/minetest-maxi.png |
| 15:25 |
sapier |
hmm seems there's another bug because for me it looks this way |
| 15:26 |
VanessaE |
I set the size slightly short of my actual screen size int he left image to account for the window manager's decorations |
| 15:27 |
VanessaE |
which way? |
| 15:27 |
|
Calinou joined #minetest-dev |
| 15:29 |
sapier |
http://imgur.com/0jLxCqA,QzhXsIO this is how it looks for me without the patch |
| 15:29 |
VanessaE |
yes, that's consistent with mine also except of course I use a larger font (bad eyes) |
| 15:30 |
VanessaE |
consistent without the patch that is |
| 15:30 |
sapier |
well did you see the captions on text boxes overlaying buttons? |
| 15:30 |
VanessaE |
and with? |
| 15:30 |
VanessaE |
oh sure, with the larger font yeah |
| 15:30 |
VanessaE |
I've noticed that. |
| 15:31 |
Calinou |
I use larger font because of wasted space |
| 15:31 |
VanessaE |
but scaling the menu with DPI doesn't fix that - you have to scale the menu to fit its content to fix that |
| 15:32 |
Calinou |
like that here: https://cdn.mediacru.sh/l6hoDN5w-BBK.png |
| 15:32 |
sapier |
http://imgur.com/VXUAuQO,OFGc6qn |
| 15:32 |
Calinou |
(hey, it's the same font settings as Warsow console) |
| 15:32 |
sapier |
this is the patched version |
| 15:32 |
VanessaE |
omg, the old dirt texture |
| 15:32 |
VanessaE |
I didn't know we still had that mode :D |
| 15:33 |
sapier |
well actually I made it work again for last version because of an issue |
| 15:33 |
sapier |
do you see difference between manually and automatic? |
| 15:33 |
VanessaE |
of course I can see the difference, sapier, but that doesn't fix the root issue which is that elements can't shift around |
| 15:33 |
VanessaE |
menu scaling with DPI is good |
| 15:33 |
sapier |
they don't shift around |
| 15:33 |
VanessaE |
don't get me wrong |
| 15:34 |
VanessaE |
but you can't leave all that empty space |
| 15:34 |
VanessaE |
it looks bad. |
| 15:34 |
Calinou |
all menu elements should scale with DPI, this is how you properly support high-DPI screens |
| 15:34 |
Calinou |
which are more and more common |
| 15:34 |
Calinou |
let's do that better than Minecraft |
| 15:34 |
VanessaE |
either group everything together, or keep the menu small but make IT fit its contents, or don't scale. |
| 15:34 |
VanessaE |
everything == group the buttons together, group the checkboxes together, etc. |
| 15:34 |
sapier |
calinou this is what we actually do right now (well almost all) only thing missing is checkbox |
| 15:36 |
sapier |
damn vanessaE that doesn't fix the issue and I wont write dozends of new menus for each screen size and dpi level created the next 5 years on various platforms ... and I know you wont gonna do this too ;-P |
| 15:36 |
VanessaE |
nonnonono |
| 15:36 |
VanessaE |
you're not listening |
| 15:36 |
VanessaE |
don't you know what grouping is in a menu? |
| 15:36 |
sapier |
we don't have grouping and we wont get it anytime soon |
| 15:37 |
VanessaE |
then you can't scale the menu. |
| 15:37 |
VanessaE |
simple as that. |
| 15:37 |
sapier |
then you're gonna fix the font size issues? |
| 15:37 |
VanessaE |
nope |
| 15:37 |
sapier |
so we're gonna remove the screen width settings? |
| 15:38 |
VanessaE |
if the fix looks worse than the bug, then the solution is to discard the "fix" until a better one can be found/ |
| 15:39 |
sapier |
you're telling me this http://imgur.com/VXUAuQO,OFGc6qn#0 looks worse then that http://imgur.com/0jLxCqA,QzhXsIO#1??????? |
| 15:40 |
VanessaE |
grrr |
| 15:40 |
VanessaE |
try it with a 5:4 display. |
| 15:40 |
VanessaE |
STOP USING YOUR G*D DAMNED SCREEN ASPECT TO SCALE WITH! |
| 15:41 |
VanessaE |
sorry, this is a real thorn in my side here. |
| 15:41 |
sapier |
that's celerons decision and he did make clear he doesn't want this to change ;-) |
| 15:41 |
VanessaE |
did you not look at how spread apart the menu items are in my screenshots? |
| 15:42 |
sapier |
yes but in your example not even buttons are different so I guess there's another issue |
| 15:42 |
VanessaE |
without your patch, my screenshots would have looked identical to yours EXCEPT that on mine, those labels do NOT overwrite like is shown in http://i.imgur.com/QzhXsIO.png |
| 15:43 |
VanessaE |
I just noticed the problem you were describing. I have never seen this effect. |
| 15:43 |
VanessaE |
I've only seen the text fields overwrite the labels instead, and then only just barely. |
| 15:43 |
sapier |
that's no surprise as you already said you don't use the screenW/screenH settings but there are ppl out there using it |
| 15:43 |
sapier |
I don't use them too |
| 15:44 |
* VanessaE |
fumes |
| 15:47 |
VanessaE |
rule #1 with a user interface. don't clutter it. rule #2: don't leave lots of empty space. |
| 15:51 |
VanessaE |
right now, we're pretty close to having rule #1 figured out. the UI isn't really cluttered. but with this scaling patch, you badly violate rule #2. that's my complaint. |
| 15:52 |
sapier |
and without it you violate rule "make it work for everyone" |
| 15:52 |
VanessaE |
it already works for everyone :P |
| 15:52 |
VanessaE |
here's an idea: |
| 15:52 |
VanessaE |
make the menu SCALE up. |
| 15:52 |
VanessaE |
as in, zoom the whole damn thing |
| 15:52 |
sapier |
it works for YOU ... for what I remember you're not everyone |
| 15:52 |
VanessaE |
like a magnifying glass. |
| 15:53 |
sapier |
the only way to do this is completely changing formspec behaviour ... I don't have any problem to do this but it's you to do the fighting |
| 15:54 |
VanessaE |
it's the only way to solve the problem right. |
| 15:54 |
VanessaE |
but it has to be made available on a per-formspec basis and disabled by default. |
| 15:55 |
VanessaE |
otherwise you'll get things like Unified Inventory taking up half of the wall in my computer room if it could ;) |
| 15:55 |
sapier |
that's not possible with reasonable ammount of work and maintainable complexity |
| 15:56 |
VanessaE |
a scaling factor scattered throughout the code, set once at program start, calculated from screen DPI, is complex? |
| 15:56 |
sapier |
I will not fix a bug each week because of some parameter in some obsucre formspec not beeing pased correct between 100 pointers and parts of minetest |
| 15:56 |
VanessaE |
I realize it would be a lot of work. |
| 15:56 |
sapier |
right now there ain't a scattered parameter |
| 15:57 |
sapier |
theres exactly one dpi value any gui element handles that value what you want is something passed from upper layer of a form down to last pixel for it to know if it shall handle dpi or not |
| 15:57 |
eugd |
player inventory are just another inventory, right? |
| 15:57 |
eugd |
they're not special case in any way? |
| 15:57 |
VanessaE |
sapier: nononono |
| 15:57 |
VanessaE |
I'm talking about something used at the rendering layer |
| 15:58 |
sapier |
there's nothing at rendering layer |
| 15:58 |
VanessaE |
sapier: well whatever you call the layer that turns a formspec element into an image on the screen then |
| 15:58 |
sapier |
especially as that change is not related to dpi |
| 15:58 |
VanessaE |
call it a renderer or rasterizer..whatever |
| 15:58 |
sapier |
but how inventorysizes are handled by minetest |
| 15:59 |
VanessaE |
the proper place to apply the scaling is at the last step before the on-screen image is created, |
| 15:59 |
sapier |
no it aint |
| 15:59 |
VanessaE |
yes, it is. |
| 15:59 |
VanessaE |
let the rendering engine do it's fucking jov!@ |
| 15:59 |
VanessaE |
job! * |
| 15:59 |
sapier |
no it isn't because in this case you'd scale up background too |
| 16:00 |
VanessaE |
yes, and? |
| 16:00 |
VanessaE |
we already do that anyway |
| 16:00 |
sapier |
our engine is irrlicht you have to live with it's limitations unless you want to rewrite it |
| 16:00 |
sapier |
we can't just take some region of screen and scale it up without messing up everything |
| 16:01 |
VanessaE |
what? |
| 16:01 |
VanessaE |
who said anything about scaling up a chunk of screen? |
| 16:02 |
VanessaE |
I'm talking about scaling the vertexes, screen coordinates, or whatever the damn things are at this layer, before they're drawn |
| 16:02 |
sapier |
(17:59:14) VanessaE: the proper place to apply the scaling is at the last step before the on-screen image is created, |
| 16:02 |
sapier |
we can't do that because user input is bound to original positions |
| 16:02 |
sapier |
so unless you wanna rewrite irrlichts gui handling we HAVE to rezize the individual gui elements |
| 16:03 |
VanessaE |
in other words you already have to tell irrlicht "draw this image at these screen coordinates at size X*Y". I'm saying right HERE is the place to apply the scaling to X and Y. |
| 16:03 |
sapier |
that's a completely different things, what you see is two different mechanisms (sometimes) colliding |
| 16:03 |
sapier |
one is the sane dpi/gui_scaling_factor handling |
| 16:04 |
VanessaE |
whether it's an image, or a button, or a checkbox, or whatever - you're telling irrlicht you wanna draw something on the screen at SOMEWHERE, at some specific size. THAT draw event is where you need to apply your scaling tweak. |
| 16:04 |
sapier |
the other one is minetests translation of positions to inventorylocation coordinates |
| 16:04 |
VanessaE |
we don't care about inventory location coordinates. DOn't translate those. |
| 16:04 |
VanessaE |
they're already relative. |
| 16:04 |
VanessaE |
leave them alone |
| 16:04 |
sapier |
if we change later one I'll not write any code restoring old behaviour |
| 16:05 |
VanessaE |
that's an API issue, not a scaling issue |
| 16:05 |
sapier |
it is |
| 16:05 |
sapier |
because position is defined to be x-,y-th part of your screen |
| 16:06 |
VanessaE |
yeah, Xth/Yth part of the screen relative to the start of the formspec, but they're still relative coordinates. |
| 16:06 |
sapier |
with any screen no matter of it's size having exactly X and Y split parts |
| 16:06 |
VanessaE |
as they're already defined by something that itself will scale up/down with your scaling tweak, you don't need to change them |
| 16:07 |
VanessaE |
it's like saying "I want X percent of this" and if "this" suddenly gets larger, you don't have to adjust your X percent to compensate to get a larger amount - you already get the larger amount by virtue of having requested a percent instead of some exact count of items. |
| 16:08 |
sapier |
you don't say I want X percent |
| 16:08 |
VanessaE |
yes, you're doing exactly that with the UI elements |
| 16:08 |
VanessaE |
think about it: |
| 16:08 |
VanessaE |
well, formspec inventory slots that it |
| 16:08 |
VanessaE |
is |
| 16:08 |
sapier |
you say place menu at x-th part of my screen with length y |
| 16:08 |
VanessaE |
NONONO |
| 16:08 |
VanessaE |
stop |
| 16:08 |
VanessaE |
halt |
| 16:08 |
VanessaE |
alto |
| 16:08 |
VanessaE |
freeze |
| 16:08 |
sapier |
api will always exactly mimicry your screen aspect |
| 16:08 |
VanessaE |
dammit I said stop |
| 16:09 |
VanessaE |
you're not getting Xth part of the screen's pixels - you're getting Xth part of the formspec's inventory slots - but those SLOTS will change in size! |
| 16:09 |
VanessaE |
the pixels won't. |
| 16:09 |
VanessaE |
so if you scale those slots, your Xth part changes to follow |
| 16:09 |
VanessaE |
you're trying to apply your scaling thinking to both parts at the same time |
| 16:10 |
sapier |
that's what I'm saying vanessae a formspec doesn't define a fixed aspect but only slot positions |
| 16:11 |
VanessaE |
exactly. |
| 16:11 |
sapier |
so unless that is changed it will look exactly this way ... the current fixed size is a hack no more |
| 16:11 |
sapier |
it's done by "claiming" a fixed screensize of 800x600 ... but that doesn't work for everything |
| 16:11 |
VanessaE |
if you apply your scaling uniformly to their initial positions, then it'll work just fine. |
| 16:12 |
sapier |
no it doesn't work |
| 16:12 |
VanessaE |
why/ |
| 16:12 |
VanessaE |
? |
| 16:12 |
sapier |
because it messes up formspecs slot concept |
| 16:12 |
sapier |
positioning will be done by slots but size by exact values ... that's not gonna work |
| 16:12 |
VanessaE |
then fix both? |
| 16:12 |
VanessaE |
where's the issue here? |
| 16:13 |
sapier |
the only way to fix is is droppingt the slot concept in total |
| 16:13 |
sapier |
but I wont implement switchable behaviour |
| 16:13 |
VanessaE |
*facepalm* |
| 16:14 |
VanessaE |
there's nothing inherently wrong with using positioning as slots, other than it being as arbitrary as using em's or points or meters. |
| 16:14 |
VanessaE |
it's just another measure |
| 16:14 |
sapier |
there is |
| 16:14 |
VanessaE |
you're conflating two issues here |
| 16:14 |
sapier |
because size and width for all elements is given in slot relative values too |
| 16:14 |
VanessaE |
I thought we were talking about fixing this scaling issue? |
| 16:14 |
VanessaE |
you're talking about trying to fix the API |
| 16:14 |
VanessaE |
I know that |
| 16:15 |
VanessaE |
I may suck at formspecs, but I *have* used them some, you know :P |
| 16:15 |
VanessaE |
(I suck at them because frankly the syntax is shit) |
| 16:15 |
VanessaE |
but anyway, |
| 16:15 |
sapier |
so what's your suggestion redefining api to make positions slot but size absolute? |
| 16:15 |
VanessaE |
don't touch the API at all! |
| 16:15 |
VanessaE |
not right now |
| 16:15 |
VanessaE |
this is the wrong time to do it |
| 16:15 |
sapier |
then explain how you suggest it to be |
| 16:16 |
VanessaE |
I don't suggest making any changes to it right now. |
| 16:16 |
sapier |
it's always gonna be wrong, right now we have a broken main menu |
| 16:16 |
VanessaE |
the syntax sucks because it uses unnamed, positional-dependent fields. |
| 16:16 |
sapier |
and to be honest I consider it to be selfish if you just don't notice it because you're not affected |
| 16:17 |
VanessaE |
the main menu IS broken, I accept that |
| 16:17 |
VanessaE |
and I do have glitches in it too |
| 16:17 |
VanessaE |
just not to the same degree as you have |
| 16:17 |
sapier |
i'm not talking about glitches but about unusability |
| 16:17 |
sapier |
a button slightly shifted right is a glitch |
| 16:17 |
VanessaE |
unusable maybe, on a widescreen monitor. I get that. |
| 16:17 |
sapier |
not full text overwritten by other menus |
| 16:18 |
VanessaE |
which is why I repeat: don't use the screen aspect ratio for anything meaningful. |
| 16:18 |
VanessaE |
it's stupid to rely on it |
| 16:18 |
sapier |
I don have widescreen as well as 4:3 |
| 16:18 |
VanessaE |
and this is exactly why. |
| 16:18 |
VanessaE |
when I say glitches, I mean glitches. |
| 16:18 |
VanessaE |
gimme a minute. |
| 16:18 |
sapier |
yet full formspec system bases on screen aspect ratio no matter if you like it or not |
| 16:19 |
VanessaE |
and that's why it's broken. |
| 16:20 |
VanessaE |
if I threw a 3:1 aspect screen at it, but it was 6000x2000 and 100 DPI, minetest would break horribly. |
| 16:20 |
VanessaE |
yet, there would be ample screen space and the DPI would be within 1 percent of what I am using now. |
| 16:21 |
VanessaE |
THAT is why you don't use aspect ratio for this. |
| 16:21 |
VanessaE |
and if you think I'm joking, remember this: |
| 16:21 |
VanessaE |
4k screens were pretty much unheard of 10 years ago. |
| 16:21 |
Calinou |
2048 × 1536 was cool back then |
| 16:22 |
VanessaE |
which is 4:3 and not 4k. |
| 16:22 |
sapier |
4k screens are <500 bucks and they're quite impressive imho they'll spread very fast the coming year |
| 16:22 |
VanessaE |
sapier: the majority of the world (read: 95% or more) does not pay 500 bucks for a monitor. |
| 16:23 |
VanessaE |
for a TV, maybe you'll get 20% of the world to pay that price. |
| 16:23 |
VanessaE |
if the tv is big enough. |
| 16:23 |
Exio4 |
i thought 200 was too much |
| 16:23 |
Calinou |
the current 600 € ones are bad: some are 30 Hz, most have bad colours |
| 16:23 |
VanessaE |
I paid under $200 for the two 1600x1200 monitors I run now. |
| 16:23 |
Calinou |
also, you need a lot of graphics card power for Ultra HD gaming |
| 16:24 |
VanessaE |
(for the pair, that is) |
| 16:24 |
Calinou |
most AAA gamers that do this use SLI/CrossFire |
| 16:25 |
VanessaE |
sapier: without your patch, this is the worst I get from a menu glitch (maximized. at 800x600, it's obviously the same) http://digitalaudioconcepts.com/vanessa/hobbies/minetest/screenshots/Screenshot%20-%2008162014%20-%2012%3a27%3a20%20PM.png |
| 16:25 |
VanessaE |
so don't sit there and tell me "it only works for you". I will sit here and tell YOU that it is only broken that badly for YOU. |
| 16:26 |
Calinou |
yeah, Password field eats on the field above |
| 16:26 |
Calinou |
happens to me too |
| 16:26 |
Calinou |
Credits menu is slightly broken too |
| 16:26 |
sapier |
you did mee my screenshot without patch |
| 16:27 |
VanessaE |
yesI did |
| 16:27 |
VanessaE |
and your screenshot says that for you it's really broken |
| 16:27 |
VanessaE |
I suggest that for you, some glitch exists in your setup that you didn't account for in the menu, LIKE SCREEN RATIO. |
| 16:27 |
VanessaE |
as in don't fucking use it to draw a menu that has nothing to what-so-fucking-ever do with aspect ratio |
| 16:27 |
* VanessaE |
grumbles |
| 16:28 |
VanessaE |
sapier: I'm getting pissed here because we're not talking about displaying a fucking movie. it's a menu. |
| 16:29 |
VanessaE |
aspect ratio simply doesn't enter into it. |
| 16:29 |
sapier |
you're not pissed because of this happening in inventory and any other in game form |
| 16:30 |
VanessaE |
I'm pissed because you keep dancing around the issue and you KNOW it. |
| 16:31 |
VanessaE |
you know as well as I do what the proper way is to fix it without changing the API. |
| 16:31 |
VanessaE |
at least generally. |
| 16:31 |
VanessaE |
(I don't know the code, obviously) |
| 16:31 |
|
asl joined #minetest-dev |
| 16:32 |
sapier |
we don't have to change api but only api behaviour if slot's aren't related to aspect ratio any longer there wouldn't be an issue |
| 16:34 |
sapier |
define minetest slots are x-th part of screen height and quadratic ... then there might be 20 or 40 slots in x direction but aspect ratio would be preserved |
| 16:37 |
sapier |
but keep in mind we'd have to rewrite mainmenu as right now "beloved" aspect ratio of slots is 3:2 |
| 16:38 |
sapier |
wrong 4:3 |
| 16:41 |
VanessaE |
that's just it |
| 16:41 |
VanessaE |
slots have always been assumed to be roughly 1:1 to most people |
| 16:41 |
VanessaE |
and 4:3'ish in display |
| 16:41 |
VanessaE |
no one realistically expects them to be any different |
| 16:41 |
sapier |
I can't change ppl assuming wrong things |
| 16:42 |
VanessaE |
because they look like ass if you try to display them differently. |
| 16:42 |
VanessaE |
have you EVER seen a screenshot from minetest that showed it any differnet? |
| 16:42 |
VanessaE |
different* |
| 16:42 |
VanessaE |
or a complaint from someone who thought they should look different? |
| 16:43 |
VanessaE |
look, monitors have had square pixels for like 20 years now |
| 16:43 |
VanessaE |
just because the display's dimensions are non-square doesn't mean the *pixels* are. |
| 16:44 |
VanessaE |
in fact I'd venture a guess that it's closer to 30 years that square pixels have been the norm |
| 16:44 |
sapier |
still slots are defined 4:3 ... I can't change history |
| 16:45 |
VanessaE |
then just draw them at a fixed ratio. |
| 16:45 |
VanessaE |
jeez |
| 16:45 |
VanessaE |
how hard is that? |
| 16:45 |
VanessaE |
you don't even need to calculate the damn ratio at all here |
| 16:45 |
sapier |
not at all but I refuse to make it a optional thing |
| 16:46 |
VanessaE |
if you assume square pixels, and that's a fair assumption here (we don't target Commodore 64), then you don't have to even consider aspect ratio of such an element. |
| 16:46 |
VanessaE |
you just have to consider relative sizes at draw time |
| 16:46 |
VanessaE |
granted, it works out to having an aspect ratio anyway but only in those elements |
| 16:46 |
VanessaE |
but this is all just math in your element placement code |
| 16:47 |
VanessaE |
the CPU doesn't care if you have two multiply terms or three, the compiler will optimize it down anyway |
| 16:48 |
sapier |
but I do care if I have to pass a "old_style_aspect_ratio" calculation throughout minetest |
| 16:49 |
VanessaE |
ok I was damned close btw: VGA defined pixels as square in 1987. |
| 16:49 |
VanessaE |
so 27 years. |
| 16:49 |
VanessaE |
no you don't. |
| 16:49 |
VanessaE |
throw it the hell out |
| 16:50 |
VanessaE |
we're talking scale-or-don't scale, here. |
| 16:50 |
Calinou |
can't DPI be calculated regardless of aspect ratio? |
| 16:50 |
sapier |
so any complaints about slot size beeing fixed 4:3 having variable number of x slots go to you |
| 16:50 |
VanessaE |
not one-weird-aspect-ratio-versus-good-one |
| 16:50 |
VanessaE |
Calinou: of course it can. |
| 16:50 |
sapier |
dpi is faked on pc |
| 16:50 |
sapier |
you can't calculate a dpi value by definition |
| 16:51 |
VanessaE |
you can always just ASK the user, you know (read: config variable) |
| 16:51 |
sapier |
it's a technical value specified by screen but pc screens usually don't provide that value |
| 16:51 |
VanessaE |
assume 100 DPI, unless otherwise specified, on PC> |
| 16:52 |
VanessaE |
you have to have some DPI value to calculate with, so allowing the user to configure it wouldn't add any complexity |
| 16:52 |
sapier |
I'll not change the current dpi faking algorithm without you to persuade celeron not to increasegui elements on screen sizes with y > 1024 and y > 1200 |
| 16:52 |
VanessaE |
celeron55: well how about it? |
| 16:52 |
VanessaE |
celeron55: for once can you weigh in on this instead of just saying "but I don't care anymore"? |
| 16:53 |
sapier |
last time I was complaining about those strange numbers he said they have to stay that way |
| 16:53 |
|
EvergreenTree joined #minetest-dev |
| 16:53 |
celeron55 |
what |
| 16:53 |
VanessaE |
well, weren't they other weird values before? |
| 16:53 |
sapier |
and to be honest as we just don't know the screen dpi any algorithm faking is is as good as another |
| 16:53 |
celeron55 |
that comment was only about the hotbar |
| 16:54 |
sapier |
true but I'll not add a different scaling facor for each damn gui element |
| 16:54 |
celeron55 |
what *is* the issue? |
| 16:54 |
sapier |
slot sizes beeing variable aspect ratio |
| 16:55 |
celeron55 |
why? |
| 16:55 |
VanessaE |
celeron55: no, the issue is scaling formspecs up without being able to re-arrange or re-size the individual elements to properly fill the new space |
| 16:55 |
|
zat joined #minetest-dev |
| 16:55 |
celeron55 |
i haven't suggested making slot sizes have variable aspect ratio |
| 16:55 |
VanessaE |
sapier is trying to conflate two other issues. |
| 16:55 |
sapier |
because for slot sizes screen is just divided in parts |
| 16:55 |
sapier |
celeron55: you've written it that way ;-) |
| 16:56 |
celeron55 |
well what the fuck |
| 16:56 |
celeron55 |
make them have static aspect ratio |
| 16:56 |
sapier |
ok decision done ... I'll create a pull making slots only honor height of screen and having fixed 4:3 aspect ratio |
| 16:57 |
VanessaE |
um... |
| 16:57 |
sapier |
that's gonna fix your issue VanessaE |
| 16:57 |
VanessaE |
shouldn't they honor the height of the *formspec* ? |
| 16:57 |
sapier |
no because height of formspec is given in slot sizes |
| 16:57 |
VanessaE |
right, derp. |
| 16:58 |
VanessaE |
I was thinking about the rendered size that time. |
| 16:58 |
VanessaE |
however, that's just one element that isn't even the root of the issue anyway |
| 16:59 |
VanessaE |
unless you figure you can carry that same idea over to everything else. |
| 16:59 |
VanessaE |
but then you're gonna break tablets I expect (rotate the screen to portrait) |
| 17:00 |
VanessaE |
so you should probably honor the smallest dimension rather than simply the window height. |
| 17:00 |
VanessaE |
(also, rotated monitors e.g. XRandR) |
| 17:00 |
sapier |
minetest has fixed rotation on android |
| 17:01 |
sapier |
a scaling menu doesn't fix all form factors but at least a way bigger range then a fixed one |
| 17:01 |
VanessaE |
ok so Android is a non-issue, but you should still account for the above. |
| 17:03 |
sapier |
what am I supposed to do below the smallest dimension? thet's what I meant with wont fix all form factors ... once menu just doesn't fit screen it wont be displayed correct |
| 17:04 |
|
rubenwardy joined #minetest-dev |
| 17:04 |
|
Calinou joined #minetest-dev |
| 17:06 |
VanessaE |
um |
| 17:06 |
VanessaE |
I mean measure the width and height and pick whichever is smaller. |
| 17:06 |
VanessaE |
use that. |
| 17:06 |
VanessaE |
don't just use the screen height alone. |
| 17:06 |
VanessaE |
s/screen/window/ |
| 17:07 |
VanessaE |
that *will* fix all form factors. |
| 17:07 |
VanessaE |
as long as you're not talking about something insane like 10000x500 or something equally ridiculous. |
| 17:07 |
sapier |
I decided for height because of consistency issues, dpi is already faked based on height so doing it different for slot sizes will result in strange effects |
| 17:08 |
VanessaE |
you have to pick the smaller_of(height, width) because what if the user is playing on a rotated screen? |
| 17:08 |
VanessaE |
both of mine can rotate. |
| 17:08 |
VanessaE |
(though I don't use that feature) |
| 17:08 |
|
BlockMen joined #minetest-dev |
| 17:10 |
sapier |
so you get smaller distances but increased image size on screen beeing 400x1025 ... |
| 17:10 |
sapier |
well it's your decision ... don't complain later |
| 17:16 |
VanessaE |
that's the whole point... |
| 17:16 |
VanessaE |
if you go with 1025 (1024?) as the correct measure, you'd get a menu that wouldn't even fit on the screen in that case. |
| 17:17 |
sapier |
no it's not it's nothing technical just a decision the dpi algorithm is arbitrary |
| 17:17 |
VanessaE |
... |
| 17:17 |
VanessaE |
a menu that would be sized right if the screen size were chosen at 400, assume the menu just about fills the width. |
| 17:17 |
sapier |
there's no reason to do it this or another way |
| 17:17 |
VanessaE |
now size that menu for 1025. |
| 17:18 |
VanessaE |
suddenly the meny is twice as large as the screen |
| 17:18 |
VanessaE |
FAIL. |
| 17:18 |
VanessaE |
menu* |
| 17:18 |
BlockMen |
nore, i would say no for now, but i will test it by time and then give my final opinion on it->https://github.com/minetest/minetest_game/pull/301 |
| 17:18 |
sapier |
yes but that's result of decision to do it this way |
| 17:18 |
VanessaE |
jeez, am I the only one who can visualize what one rectangle would look like when placed onto another rectangle of a different size and orientation? :P |
| 17:19 |
nore |
ok |
| 17:19 |
sapier |
just explain to me why my menu items increase in a 400x2000 menu but the space between them gets smaller |
| 17:20 |
VanessaE |
sapier: because you chose a badly contrived example again? |
| 17:20 |
nore |
(it could also be added as an option, with the current oregen as the default) |
| 17:20 |
VanessaE |
sapier: if your menu gets badly misshapen in that instance, it's because you fucked up. |
| 17:20 |
VanessaE |
I won't sugar-coat this. |
| 17:20 |
sapier |
no I didn't that's what's gonna happen if you fix the slots but don't fix the dpi algorithm |
| 17:21 |
VanessaE |
sapier: did I not say earlier to just assume a fixed DPI of 100 on PCs, and let the user configure it for something else if it's wrong? |
| 17:21 |
VanessaE |
since you yourself said that PC monitors can't be trusted to give a valid DPI value |
| 17:22 |
VanessaE |
it's either that or have your code go online to some database and pick the DPI from some vetted list of monitors. |
| 17:22 |
sapier |
celeron55 do you agree to not scaling any gui elements automatically? ... |
| 17:22 |
sapier |
as I said I WILL NOT ADD A DIFFERENT SCALING FACTOR FOR EACH GUI ELEMENT |
| 17:23 |
sapier |
most likely a different one autodetecting which user is logging on |
| 17:23 |
VanessaE |
who said anything about adding different algos per element? |
| 17:23 |
VanessaE |
only you keep suggesting this, not me. |
| 17:23 |
sapier |
you said fixed assume 100 dpi that's gonna result in hotbars having fixed size too |
| 17:23 |
VanessaE |
um. |
| 17:23 |
VanessaE |
*headdesk* |
| 17:23 |
celeron55 |
i'm fine with having a fixed DPI on PCs as long as there's an easy slider to set it to whatever a user wants |
| 17:24 |
sapier |
irrlicht doesn't support sliders |
| 17:24 |
VanessaE |
yes it does. |
| 17:24 |
celeron55 |
well something to set it |
| 17:24 |
VanessaE |
pause menu, "sound volume". |
| 17:24 |
sapier |
no it doesn't ... we've something different but usability is a little bit ... well see your self in settings |
| 17:25 |
sapier |
it's a scrollbar VanessaE not a slider |
| 17:25 |
VanessaE |
ah, well it certainly works well enough |
| 17:25 |
celeron55 |
well it's basically the same thing :P |
| 17:25 |
sapier |
the difference is you can drag around a slider while this doesn't work very well with a scrollbar |
| 17:26 |
celeron55 |
well, for now just buttons for some useful DPIs could be fine |
| 17:26 |
celeron55 |
also, same thing for font sizes |
| 17:26 |
celeron55 |
font size has been missing from settings for too long (altough, there's no mechanism in place for changing it at runtime, needs work) |
| 17:27 |
sapier |
I'm just doing this change |
| 17:28 |
sapier |
should've done it before VanessaE wouldn't have even noticed any problem ... now shes complaining because of her way of doing it would be slightly glitched |
| 17:29 |
VanessaE |
I am complaining because you were about to make the main menu look like crap for even more people than you propose is already the case. |
| 17:29 |
celeron55 |
sapier: do you think having buttons for, say, 70dpi, 100dpi, 130dpi and 160dpi in settings would work? |
| 17:30 |
VanessaE |
celeron55: fwiw X had a standard 75DPI setting. |
| 17:30 |
VanessaE |
but that was uears ago |
| 17:30 |
VanessaE |
years* |
| 17:31 |
sapier |
I'd suggest a dropdown not buttons |
| 17:31 |
sapier |
RealBadAngel: could you please add a GUI subtab on adding the subtabs to settings too ? ;-) |
| 17:34 |
RealBadAngel |
oke doke |
| 17:35 |
RealBadAngel |
and vote for dropdown too |
| 17:35 |
RealBadAngel |
buttons would look dumb in best case |
| 17:36 |
RealBadAngel |
celeron55, blue channel of a vertex is supposed to hold light source value, yes? |
| 17:37 |
celeron55 |
one of them holds daytime light, one of them holds nighttime light |
| 17:37 |
celeron55 |
and nighttime light equals light source |
| 17:37 |
RealBadAngel |
thats r and g |
| 17:37 |
celeron55 |
umm... wait |
| 17:38 |
RealBadAngel |
r - day, g - night, b - lightsource |
| 17:39 |
RealBadAngel |
im asking because b is being fed with different values |
| 17:39 |
RealBadAngel |
once nodedef light source value, once encoded one |
| 17:39 |
RealBadAngel |
video::SColor c = MapBlock_LightColor(255, l, decode_light(f.light_source)); |
| 17:39 |
RealBadAngel |
this is for each and every special drawtype |
| 17:40 |
RealBadAngel |
while regular nodes hold here plain one from nodedef |
| 17:41 |
celeron55 |
i don't remember what's up with that |
| 17:41 |
celeron55 |
i think regular nodes should probably have that too |
| 17:41 |
celeron55 |
because shaders don't handle node light decoding |
| 17:42 |
RealBadAngel |
shaders do not bother bout it anymore |
| 17:42 |
RealBadAngel |
it is inconsistent in the engine |
| 17:43 |
celeron55 |
well i guess you can somehow mirror this logic in wherever the stuff is done now |
| 17:43 |
RealBadAngel |
def light source is in range 0-15, while decoded 0-255 |
| 17:43 |
RealBadAngel |
oops, 8-255 |
| 17:43 |
RealBadAngel |
light table sets 8 for light level = 0 |
| 17:44 |
RealBadAngel |
and thats the real problem |
| 17:44 |
celeron55 |
i know; i don't really understand what the question is |
| 17:44 |
RealBadAngel |
i cannot detect light sources properly |
| 17:45 |
RealBadAngel |
because blue channel have different values for different drawtypes |
| 17:45 |
RealBadAngel |
grass have 0, stone slab 8 |
| 17:45 |
celeron55 |
why are you continuing this |
| 17:45 |
RealBadAngel |
to get the idea behind why it was coded that way |
| 17:46 |
celeron55 |
it's a bug that they are handled differently |
| 17:46 |
celeron55 |
if that wasn't already clear |
| 17:46 |
RealBadAngel |
imho b should carry not encoded light source, do you agree? |
| 17:47 |
RealBadAngel |
we can apply reading on table the very same place as shading is done |
| 17:47 |
celeron55 |
i think it should always carry a decoded light source value but my knowledge about this thing is outdated because you've been changing it so much |
| 17:47 |
celeron55 |
then it's comparable to all the other values that are found in the values |
| 17:47 |
RealBadAngel |
actually i havent touched the lights so far |
| 17:47 |
celeron55 |
in the color values at that point i mean |
| 17:48 |
celeron55 |
anyway, my point is, decode all the things in the same step and not all around the place |
| 17:48 |
RealBadAngel |
ok |
| 17:48 |
celeron55 |
i don't know where that should be |
| 17:48 |
RealBadAngel |
a sec |
| 17:48 |
celeron55 |
but maybe do it in such a way that if we decide it should be done in shaders again, it's not going to be a pain in the ass |
| 17:49 |
celeron55 |
i mean, the step that you removed from them |
| 17:50 |
RealBadAngel |
https://github.com/minetest/minetest/blob/master/src/mapblock_mesh.cpp#L1142 |
| 17:50 |
RealBadAngel |
here, each vertex has to pass this code, no matter what drawtype |
| 17:51 |
RealBadAngel |
and here im failing thx to decoding the light too early for all the special drawtypes , so light_source = 0 is 8 |
| 17:52 |
RealBadAngel |
so together with faces shading, encoding could be done |
| 18:00 |
RealBadAngel |
so, Calinou, sorry but fixing acid will take a bit longer than i thought ;) |
| 18:01 |
|
asl joined #minetest-dev |
| 18:02 |
Calinou |
OK |
| 18:04 |
RealBadAngel |
but at least i know what to do |
| 18:05 |
RealBadAngel |
almost the same applies to nodeboxes |
| 18:20 |
RealBadAngel |
BlockMen, is there a reason for sandstone being able to dug by hand? |
| 18:21 |
BlockMen |
idk, didnt add that |
| 18:21 |
RealBadAngel |
imho thats worth bug label |
| 18:22 |
RealBadAngel |
sandstone, stairs and slabs you can dig by hand |
| 18:22 |
BlockMen |
feel free to open an issue |
| 18:22 |
RealBadAngel |
for such obvious one you could just make a commit |
| 18:25 |
VanessaE |
RealBadAngel: I used to dig sandstone by hand in my grandmother's yard. |
| 18:25 |
VanessaE |
it occurs naturally in dirt in eastern Kansas. |
| 18:26 |
VanessaE |
(as kids, we used to use it as a sort of "chalk" to draw on sidewalks with) |
| 18:26 |
VanessaE |
granted they weren't 1x0.5x1 meter blocks, but you get the point. |
| 18:26 |
|
CraigyDavi joined #minetest-dev |
| 18:28 |
RealBadAngel |
idk, imho it should be diggable with at least wooden pick |
| 18:29 |
RealBadAngel |
i cannot imagine one sitting there and scratching block of sandstone with his nails to cut 1m cube of it ; |
| 18:29 |
RealBadAngel |
;) |
| 18:35 |
Exio4 |
i don't imagine anyone cutting an 1m wood cube with their bare hands eithers |
| 18:35 |
BlockMen |
RealBadAngel, but i dont want do that now |
| 18:35 |
VanessaE |
when remodeling this house, I kinda did :) |
| 18:35 |
BlockMen |
and idk what the other think/say about that |
| 18:36 |
BlockMen |
so opening an issue is best right now :P |
| 18:53 |
|
CraigyDavi joined #minetest-dev |
| 19:03 |
|
Miner_48er joined #minetest-dev |
| 19:13 |
|
NakedFury joined #minetest-dev |
| 19:17 |
|
BlockMen left #minetest-dev |
| 19:25 |
Calinou |
what are the causes for failing to publish server on list? |
| 19:25 |
Calinou |
some friends keep having a lot of trouble doing it, it doesn't work |
| 19:36 |
sfan5 |
which error msg? |
| 19:43 |
|
rubenwardy left #minetest-dev |
| 19:46 |
|
casimir joined #minetest-dev |
| 19:52 |
|
CraigyDavi joined #minetest-dev |
| 19:52 |
|
ShadowNinja joined #minetest-dev |
| 19:52 |
|
blaise joined #minetest-dev |
| 19:53 |
|
hmmmm joined #minetest-dev |
| 19:53 |
|
deltib joined #minetest-dev |
| 19:54 |
|
RealBadAngel joined #minetest-dev |
| 19:54 |
|
PenguinDad joined #minetest-dev |
| 19:54 |
|
^v joined #minetest-dev |
| 19:54 |
|
Ritchie joined #minetest-dev |
| 20:52 |
|
kahrl joined #minetest-dev |
| 21:18 |
|
eugd joined #minetest-dev |
| 21:27 |
eugd |
test |
| 21:32 |
kahrl |
mine |
| 22:02 |
eugd |
std::map<s16, MapBlock*> m_blocks; |
| 22:02 |
eugd |
can someone give me a quick c++ tutorial run-down of this line? |
| 22:03 |
eugd |
what do the less-than/greater-than brackets signify, as opposed to normal brackets? |
| 22:03 |
eugd |
or parenthesis |
| 22:04 |
eugd |
and i am assuming the little s16 is how the size of the map is initialized, but is that really all a map needs? |
| 22:04 |
sfan5 |
uh |
| 22:04 |
sfan5 |
that defines a key-value map that maps s16 to a MapBlock* |
| 22:05 |
eugd |
what's with the brackets though, what do they mean in c++, opposed to "()" or "{}" |
| 22:05 |
Exio4 |
template params |
| 22:05 |
eugd |
ok i can google that |
| 22:05 |
eugd |
thanks |
| 22:12 |
sfan5 |
https://forum.minetest.net/viewtopic.php?f=7&t=9940 |
| 22:12 |
sfan5 |
someone look at that |
| 22:12 |
eugd |
the little 's16' thing |
| 22:12 |
eugd |
is a custom-defined name, right? |
| 22:13 |
eugd |
where is that defined, some header? |
| 22:13 |
sfan5 |
yes |
| 22:13 |
sfan5 |
s16 -> int16_t -> signed short (for x86(_64)) |
| 22:13 |
eugd |
yeah |
| 22:13 |
eugd |
is there some namespace for those, or is that unnecesarry? |
| 22:13 |
eugd |
and where are they defined? |
| 22:13 |
sfan5 |
probably irrlichttypes.h |
| 22:13 |
sfan5 |
anyway |
| 22:14 |
* sfan5 |
goes to bed |
| 22:14 |
eugd |
a major reason for this is to make large changes throughout the entire codebase easier, right? |
| 22:15 |
eugd |
and it's all irrelevant performance-wise, written pout at compile? |
| 22:15 |
eugd |
*out |
| 22:20 |
kahrl |
eugd: well it's not like we would one day decide to make s16 a 32-bit unsigned integer |
| 22:21 |
eugd |
that's exactly what i'm wondering |
| 22:21 |
eugd |
increasing world size |
| 22:21 |
kahrl |
it has nothing to do with that |
| 22:21 |
kahrl |
the reason the traditional int/long/... types are not used is because they have different sizes on different platforms |
| 22:22 |
kahrl |
leading to obscure bugs |
| 22:22 |
eugd |
so the custom names aren't anything to do with easier large changes? |
| 22:22 |
kahrl |
yeah |
| 22:22 |
eugd |
rather just redefining based on platform? |
| 22:23 |
kahrl |
making the world larger would require much more changes than just a different data type |
| 22:23 |
eugd |
to memory management backend and such |
| 22:24 |
eugd |
but can or are these custom names used for this kind of thing? |
| 22:24 |
kahrl |
the database you mean? |
| 22:24 |
kahrl |
these names are used for all sorts of things |
| 22:26 |
kahrl |
you'd need to rewrite the blockpos <-> integer conversion, the network protocol, many little things in the server and client code if you want to increase the world size |
| 22:26 |
kahrl |
plus the corresponding compatibility code |
| 22:39 |
|
CraigyDavi` joined #minetest-dev |
| 22:40 |
|
proller joined #minetest-dev |
| 23:42 |
gentoobro |
why would you need a bigger world? is 64 kilometers cubed not enough? has anyone actually used/explored the entire world? |
| 23:45 |
gentoobro |
(does anyone who plays minetest even have at least 5PB of drive space?) |
| 23:55 |
Zefram_Fysh |
travelling 31 km horizontally is totally feasible |
| 23:56 |
Zefram_Fysh |
reaching the edge of the world is a pretty sucky result |
| 23:56 |
Zefram_Fysh |
you don't have to explore the entire world to run into the edge and find it annoying |
