| Time |
Nick |
Message |
| 00:00 |
celeron55 |
wait what, i failed to actually remove these mods |
| 00:02 |
celeron55 |
what i described was still the combination of homedecor+moreblocks+paragenv7 |
| 00:02 |
celeron55 |
if that can barely make it, i'll have no issues whatsoever |
| 00:03 |
celeron55 |
yes, minetest_game+paragenv7 starts at under 90MB |
| 00:03 |
paramat |
lol |
| 00:04 |
celeron55 |
and i start on a typical mini island with nowhere to go, thank you mgv5 |
| 00:06 |
celeron55 |
having travelled some distance, it's 187M |
| 00:07 |
celeron55 |
the generation speed is quite slow |
| 00:07 |
celeron55 |
how much more speed do you think you can get out of this? |
| 00:09 |
sapier |
none map generation is primary bottleneck on android devices |
| 00:09 |
paramat |
a little more, not sure how significant |
| 00:09 |
sapier |
once map is there it's ok but I've never seen a device beeing capable to generate it as fast as you can walk ... maybe latest quad core phones |
| 00:10 |
paramat |
generating the trees is slow but you can control the density of those |
| 00:11 |
paramat |
except ... jungles don't look right unless they're thick, it's fun to jump from tree to tree |
| 00:11 |
celeron55 |
well, v6 generates quite fast enough |
| 00:12 |
celeron55 |
lol good luck jumping from tree to tree on a touchscreen, or getting on a tree in the first place |
| 00:12 |
paramat |
otherwise i would suggest ethereal or BFD that use the core biome API |
| 00:14 |
paramat |
well, paragenv7 needs updating anyway so i'll do that, give me a day and you could try it again with the slight performance increases |
| 00:16 |
kilbith |
ShadowNinja: tabs instead of the checkboxes, and description below the list would be OK for you ? |
| 00:16 |
kilbith |
checkbox* |
| 00:18 |
kilbith |
lemme know here, will read the logs tomorrow. 'night. |
| 00:20 |
paramat |
an alternative would be me squeezing paragenv7 into the biome API and trees into schematics, that would speed things up a lot. need a few days for that |
| 00:20 |
paramat |
but not difficult. all trees would be identical though apart from rotation |
| 00:22 |
|
sapier left #minetest-dev |
| 00:22 |
celeron55 |
i do know the speed of the biome api and schematic trees and it would be very beneficial to this |
| 00:23 |
celeron55 |
as i said, i don't care for map generator changes for this so it's fine to use an unstable api |
| 00:24 |
paramat |
okay well i'm happy to do that it's not much work |
| 00:24 |
celeron55 |
can you recall what parameter of v5 changes the height of the terrain |
| 00:26 |
celeron55 |
i mean, like, the steepness of the hills |
| 00:27 |
celeron55 |
it's np_factor i think |
| 00:31 |
paramat |
yeah factor, but that's range limited, so icrease 'scale' of np_ground instead |
| 00:31 |
paramat |
*increase |
| 00:36 |
celeron55 |
with np_ground i can also decrease the general amount of water too |
| 00:36 |
celeron55 |
let's see |
| 00:37 |
celeron55 |
wait, how can these even be set in the first place |
| 00:39 |
celeron55 |
if i try to copy mgv5_np_ground from map_meta.txt to the game's minetest.conf, it fails saying "terminate called after throwing an instance of 'SettingNotFoundException'" "Setting [mgv5_np_ground] is a group." |
| 00:40 |
celeron55 |
oh well, i'll just modify the engine source |
| 00:40 |
celeron55 |
#yolo |
| 00:41 |
paramat |
the params need to be in group format because eased noise is specified, see docs |
| 00:42 |
hmmmmm |
paramat, you could use my tree schematic, but it doesn't have y slice probabilities |
| 00:42 |
paramat |
or rather see .coonf.example |
| 00:42 |
celeron55 |
this page mentions nothing about that http://dev.minetest.net/Mapgen_Parameters |
| 00:43 |
hmmmmm |
lol that's outdated |
| 00:43 |
celeron55 |
paramat: i wrote them in group format because that's the format they were in in map_meta.txt |
| 00:43 |
paramat |
thanks hmmmm but i'll save schematics from paragenv7 since those appletrees are different |
| 00:44 |
paramat |
yeah sorry i just realised you probably got it right |
| 00:44 |
paramat |
another way to increase performance is to use non-eased 3D noise, but the cave width will have to be retuned |
| 00:45 |
paramat |
i understand original v5 was non eased and spikier |
| 00:47 |
hmmmmm |
hrmmm so you're running into memory problems |
| 00:47 |
hmmmmm |
lots of stuff in minetest sacrifice low memory usage for execution speed |
| 00:48 |
hmmmmm |
i know it'd probably make an insiginificant difference, but i bet some memory could be saved by not allocating like 3-4 buffers for each noise object |
| 00:48 |
celeron55 |
no i'm not |
| 00:48 |
paramat |
to un-ease 3D noise delete the noise 'flags' parameter |
| 00:48 |
celeron55 |
it happened only because i attempted to run homedecor on a mobile phone |
| 00:48 |
hmmmmm |
oh.. vanessae's mods seem to target power users |
| 00:49 |
celeron55 |
which is frankly ludicrous, but i tried it |
| 00:49 |
hmmmmm |
[07:39 PM] <celeron55> if i try to copy mgv5_np_ground from map_meta.txt to the game's minetest.conf, it fails saying "terminate called after throwing an instance of 'SettingNotFoundException'" "Setting [mgv5_np_ground] is a group." |
| 00:49 |
hmmmmm |
that shouldn't happen... |
| 00:51 |
hmmmmm |
somebody tried using get() directly on mapgen params which is bad, Settings::getNoiseParams() should always be used instead which reads it as a table just fine |
| 00:51 |
hmmmmm |
if i recall correctly, i fixed all instances of that, so it a mod must be the culprit |
| 00:51 |
hmmmmm |
s/it// |
| 00:52 |
celeron55 |
why would a mod read mgv5 parameters |
| 00:52 |
celeron55 |
that isn't happening |
| 00:56 |
hmmmmm |
shrug |
| 00:56 |
hmmmmm |
i just tried doing exactly what you said and i don't get the error |
| 00:57 |
hmmmmm |
it's either a mod, or it was a bug that got fixed between now and when the binaries you're using were built |
| 00:58 |
celeron55 |
that would be between 0.4.11 and master; can you confirm the possibility? |
| 00:58 |
hmmmmm |
why not just try disabling all mods |
| 00:59 |
celeron55 |
i have rather lot going on right now, this issue is not my priority |
| 00:59 |
hmmmmm |
i hadn't made any changes to settings between 0.4.11's release and now |
| 00:59 |
celeron55 |
i'm moving on already |
| 01:04 |
|
Player-2 joined #minetest-dev |
| 01:05 |
hmmmmm |
hrmmm |
| 01:15 |
|
paramat left #minetest-dev |
| 01:17 |
|
Robby joined #minetest-dev |
| 01:18 |
|
shadowzone joined #minetest-dev |
| 01:38 |
|
Robby joined #minetest-dev |
| 01:43 |
|
Megaf joined #minetest-dev |
| 01:45 |
ShadowNinja |
celeron55: I feal like releasing to the play store now would just be a good way to accumulate a lot of unfavorable reviews. |
| 01:46 |
ShadowNinja |
kilbith:No, keep the checkbox, and the description is good at the side. |
| 01:46 |
celeron55 |
ShadowNinja: i will not give any value to this comment unless you can tell me WHEN to release it instead |
| 01:47 |
hmmmmm |
once client-side scripting has been established and most of the lingering issues have been solved |
| 01:47 |
celeron55 |
what, that's like 2 years of development |
| 01:47 |
hmmmmm |
not so |
| 01:47 |
ShadowNinja |
celeron55: When it's faster and less hacky and buggy. I can't really specify exactly when though. |
| 01:47 |
celeron55 |
no that's not how minetest's releases have ever been made |
| 01:47 |
hmmmmm |
did you see my client side scripting requirement list |
| 01:48 |
celeron55 |
no |
| 01:48 |
ShadowNinja |
There are definitely a lot of bugs, I have like two lists, and I've heard of a few more today. |
| 01:48 |
hmmmmm |
also, i have greater confidence in minetest stability with the new releasing procedures |
| 01:48 |
hmmmmm |
celeron55: the tl;dr is that I have a solid plan and now all there's left is to execute it |
| 01:48 |
celeron55 |
what's the timeline |
| 01:49 |
hmmmmm |
that i don't know unless i make this more than a one man thing |
| 01:49 |
ShadowNinja |
celeron55: Usually it's just "release when enough stuf's accumulated, usually a few months." |
| 01:49 |
hmmmmm |
the only reason i've had this burst of activity is because of the long christmas vacation |
| 01:50 |
hmmmmm |
after all this development i'd still have to say things aren't in a 'happy place' yet |
| 01:51 |
celeron55 |
waiting for longer for what i'm doing (longer than maybe letting paramat do a quick port of paragenv7 on the old biome api) makes no sense; you aren't focusing on the things that people will not like about this anyway |
| 01:51 |
celeron55 |
the largest issue with this is that the UI is shit |
| 01:51 |
celeron55 |
but that's not on your list |
| 01:51 |
hmmmmm |
well for what it's worth, I am working on an options menu right now |
| 01:52 |
celeron55 |
and the main issue with the UI is that it's not scaled to the full screen and the scrollbars don't function like you'd expect and stuff like that |
| 01:52 |
hmmmmm |
that part is all sapier |
| 01:52 |
celeron55 |
which is quite deeply rooted to the nature of irrlicht and formspecs |
| 01:52 |
celeron55 |
yes, this is a reason i don't have to wait for you |
| 01:52 |
hmmmmm |
kahrl and sapier do formspec, i don't |
| 01:53 |
hmmmmm |
formspec and irrlicht gui related things are a totally different brand of nasty that i'm not willing to step foot into |
| 01:53 |
hmmmmm |
so i don't get it |
| 01:53 |
celeron55 |
the other issue is performance, but you aren't doing anything to that either; you're just making things that are now not even considerable to run on this thing a bit more considerable; it won't affect the speed of this set-up that i'm going to ship on the play store |
| 01:54 |
hmmmmm |
in order to make the GUI good you basically need to create your own widget toolkit |
| 01:54 |
celeron55 |
i'm mostly replying to shadowninja |
| 01:54 |
hmmmmm |
i don't think we'll be successful hacking on more irrlicht stuff |
| 01:55 |
hmmmmm |
mesh making I could work on a bit, but i'm not overflowing with graphics knowledge |
| 01:58 |
ShadowNinja |
celeron55: There were a number of significant performance improvements recently. The UI code is big and sapier's the only one that really knows it. I don't know much about anything Irrlicht either. |
| 01:58 |
hmmmmm |
those were all cpu bound though |
| 01:59 |
hmmmmm |
and consisted of removing C++-isms that add slowness |
| 01:59 |
ShadowNinja |
RBA, kahrl, and you probably know the audiovisual stuff best. |
| 01:59 |
celeron55 |
yes, the fact that there were improvements means further improvements are likely to be much harder and now it's a good time to publish it |
| 01:59 |
hmmmmm |
I'd rather not publish it until the outstanding mobile formspec issues get fixed |
| 01:59 |
* ShadowNinja |
pulls up one of his bug lists. |
| 02:01 |
celeron55 |
i've solely worked on making the current android port work in a reasonable manner focusing on the general user experience for 12 hours now |
| 02:01 |
celeron55 |
i can tell you that this was totally unusable when i started and now it's much less so |
| 02:01 |
ShadowNinja |
celeron55: http://pastebin.ubuntu.com/9679921/ |
| 02:01 |
celeron55 |
and i can tell you that i'm not going to spend much more than this on it for now |
| 02:02 |
ShadowNinja |
celeron55: Other users are probably going to have scaling issues like you, and they aren't going to accept "edit this text file" as a solution. |
| 02:03 |
celeron55 |
i didn't edit any text file |
| 02:04 |
celeron55 |
you don't have to jump now that the player climbs 1-node steps by just walking |
| 02:04 |
celeron55 |
users don't care about logcat or logs whatsoever |
| 02:04 |
celeron55 |
crouch is... questionably useful in any case |
| 02:04 |
ShadowNinja |
celeron55: Dodn't you have to edit minetest.conf to set gui_scaling? |
| 02:05 |
celeron55 |
i don't have multi-second lag in singleplayer once the map has generated, and you generally end up in a situation like that after a while |
| 02:05 |
celeron55 |
ShadowNinja: no, i just restarted the game; it fails to save the settings which is handy |
| 02:05 |
|
twoelk|2 joined #minetest-dev |
| 02:06 |
celeron55 |
and the default scale works kind of okay for tablets; it's not optimal but usable |
| 02:06 |
ShadowNinja |
celeron55: Um, well that's a significant bug. |
| 02:07 |
celeron55 |
yeah but doesn't matter if you just hit "singleplayer" and build a house to kill some time |
| 02:08 |
ShadowNinja |
celeron55: You should remove the settings menu if it doesn't actually work persistently. It worked before. |
| 02:08 |
celeron55 |
lol |
| 02:08 |
celeron55 |
you should work on it instead of arguing with me about things i already know better |
| 02:08 |
kahrl |
why not add a line like this in GUIFormSpecMenu somewhere: if (formspec size > screen size) { reduce the scaling factor until this is no longer the case } |
| 02:09 |
kahrl |
very simplistically speaking of course |
| 02:09 |
celeron55 |
it should go the other way too on android so that the screen would always be fully used |
| 02:09 |
kahrl |
true |
| 02:10 |
celeron55 |
anyway, my point is, we can't get a polished android experience with this technology |
| 02:11 |
celeron55 |
we just can't; we can only declare a point where it's sufficiently non-horrible to be given to users without wasting their time |
| 02:11 |
hmmmmm |
i agree... wtf is the point of having unused space on the mainmenu on a mobile device |
| 02:11 |
hmmmmm |
note that i don't even have a mobile device so i can't go testing or working on that |
| 02:12 |
celeron55 |
be glad you don't, you couldn't tolerate the total non-quality MT is on such 8))) |
| 02:12 |
kahrl |
about the performance issues, how much could a texture atlas help on mobile? |
| 02:12 |
hmmmmm |
from what celeron says, a lot |
| 02:13 |
celeron55 |
in this case, dunno |
| 02:13 |
kahrl |
we already had some code for doing that so it shouldn't be completely out of reach to add that |
| 02:13 |
hmmmmm |
he wants us to readd the texture atlas |
| 02:13 |
celeron55 |
my device feels like being limited by vertex count, in which case texture atlases and opengl object counts do not matter |
| 02:14 |
celeron55 |
and neither VBOs |
| 02:14 |
celeron55 |
but i'm not sure |
| 02:14 |
hmmmmm |
do we have an overdraw problem, I wonder? |
| 02:15 |
celeron55 |
i mean, this is running at a view range of 20 |
| 02:15 |
celeron55 |
i can't open the profiler to check what the meshbuffer counts are though |
| 02:15 |
ShadowNinja |
hmmmmm: Yes, because the culling is no good. |
| 02:15 |
celeron55 |
probably <50 |
| 02:16 |
hmmmmm |
supposedly the hardware occlusion culling blows horribly |
| 02:16 |
hmmmmm |
that's the reason why I put that entire thing on pause |
| 02:17 |
celeron55 |
there's no hardware occlusion culling |
| 02:17 |
hmmmmm |
occlusion query rather |
| 02:17 |
celeron55 |
and that's a heavy operation anyway |
| 02:18 |
celeron55 |
in buildat i have the option to use urho3d's generic occlusion culling capability (it's just a flag you set for each mesh); i'm not sure how it works but it kind of varies between improving and degrading performance, depending on what one is looking at |
| 02:19 |
hmmmmm |
soo much work needs to be done on the client side :/ |
| 02:19 |
celeron55 |
i think i ended up just turning it off |
| 02:19 |
hmmmmm |
celeron, you should work on minetest with us! |
| 02:19 |
hmmmmm |
it'll be great i promise |
| 02:21 |
kahrl |
something I've just noticed while looking at the game in wireframe mode: |
| 02:21 |
kahrl |
the maximum number of identical-material faces that are ever combined into one is 2 |
| 02:21 |
hmmmmm |
caves get drawn, right? :/ |
| 02:21 |
celeron55 |
i won't spend a lot of my time on a thing that i personally won't use; that's just a matter of fact |
| 02:21 |
kahrl |
that might explain the vertex count problem |
| 02:21 |
hmmmmm |
ahh |
| 02:22 |
hmmmmm |
celeron, why don't you use it? |
| 02:22 |
celeron55 |
kahrl: even with allowing chains of 16, with smooth lighting the most benefit you get is generally like 10% |
| 02:22 |
hmmmmm |
because of the problems or you just don't care for it anymore |
| 02:23 |
celeron55 |
kahrl: because you need the vertices for setting the lighting |
| 02:23 |
celeron55 |
in caves you don't get even that |
| 02:23 |
celeron55 |
not even with non-smooth lighting |
| 02:23 |
kahrl |
is there any downside to allowing chains of 16? |
| 02:23 |
celeron55 |
it just is an almost useless optimization, buildat doesn't do it at all for this reason |
| 02:24 |
kahrl |
I mean if you make the terrain less hilly on android, the benefit will be greater |
| 02:24 |
kahrl |
and in a cave there is not that much to render anyway (assuming the occlusion culling doesn't completely fail) |
| 02:24 |
celeron55 |
texture atlases become a problem when you need to connect vertices of rotated nodes and have a repeated texture on them 8) |
| 02:25 |
celeron55 |
minetest originally had stripes of 16 textures in the atlas for this purpose |
| 02:25 |
kahrl |
ah I see |
| 02:25 |
celeron55 |
well, it still would work as long as grass nodes don't get facedir set on them |
| 02:26 |
celeron55 |
and if they would, it wouldn't be tileable anyway |
| 02:26 |
celeron55 |
trying to maintain that 10% optimization with this texture-based style is a losing game 8) |
| 02:26 |
celeron55 |
unless you actually generate combined textures for mapblocks on the fly |
| 02:27 |
celeron55 |
that's what the one guy did that has the blog with 100 posts with the voxel engine that isn't in actual use |
| 02:27 |
kahrl |
heh |
| 02:28 |
kahrl |
that sounds incredibly expensive if you use HD textures though |
| 02:28 |
celeron55 |
if you generated them like that, you'd probably get a 2x or more optimization on regular generated grass |
| 02:28 |
celeron55 |
it probably is |
| 02:29 |
celeron55 |
the modern solution to all of this would probably be some shader code which can rotate textures or something |
| 02:30 |
celeron55 |
this all is weird because other games don't deal with these kinds of issues |
| 02:35 |
celeron55 |
this will finish uploading in 15 minutes: http://packages.8dromeda.net/minetest/Minetest-0.4.11-8dromeda-1-rc1.apk.part |
| 02:35 |
celeron55 |
i'll make a poll on the forum tomorrow asking whether people think it's a fine enough initial official google play release |
| 02:36 |
celeron55 |
(there's 8dromeda all over that url because my google play account is with that name too; it's under what i develop my solo projects) |
| 02:37 |
celeron55 |
oops, i mean, http://packages.8dromeda.net/minetest/Minetest-0.4.11-8dromeda-1-rc1.apk |
| 02:37 |
kahrl |
ok, judging by http://tomcc.github.io/images/cull_after.jpg, MCPE doesn't need face combining |
| 02:38 |
kahrl |
afaik they also have multiple textures for some common nodes that are chosen pseudo-randomly so it wouldn't work anyway |
| 02:40 |
celeron55 |
hmmmmm: after 1 year of development, i was interested in a different game than the community and it's gone to that direction for all the time |
| 02:40 |
celeron55 |
since then, i mean |
| 02:41 |
hmmmmm |
you were looking to make an actual game kind of game |
| 02:41 |
hmmmmm |
what do you think about voxellands/minetest classic |
| 02:41 |
celeron55 |
yes; not a house builder |
| 02:41 |
hmmmmm |
but programming is fun |
| 02:41 |
hmmmmm |
the game part of minetest is writing mods 8) |
| 02:41 |
celeron55 |
i have better projects for programming |
| 02:41 |
VanessaE |
+ |
| 02:41 |
hmmmmm |
this is your fault |
| 02:41 |
hmmmmm |
you did it with the addition of lua api |
| 02:42 |
celeron55 |
well frankly it was the best the project could have had; you all are here because of it |
| 02:42 |
hmmmmm |
i have a lot more work to do on it thanks to modding |
| 02:43 |
hmmmmm |
it's apparently not enough to do task X |
| 02:43 |
hmmmmm |
it needs to be completely configurable, have an excellent interface, have every single edge case working 100%, documented, etc. |
| 02:43 |
hmmmmm |
honestly i came here because i wanted to figure out how to make the terrain flatter so i could actually build buildings |
| 02:44 |
celeron55 |
you don't have to make the content thanks to modding |
| 02:44 |
hmmmmm |
hahaha yes you do |
| 02:44 |
hmmmmm |
the assets suck ass |
| 02:44 |
celeron55 |
if there weren't modding you'd have to yourself imagine the biomes that the users want, and the mobs and everything |
| 02:44 |
hmmmmm |
nobody's made half decent sounds |
| 02:44 |
celeron55 |
and chances are because they would be yours, nobody would help you |
| 02:44 |
celeron55 |
and everyone would complain |
| 02:45 |
hmmmmm |
they seem to lap up minecraft though |
| 02:45 |
hmmmmm |
they love that shit |
| 02:45 |
hmmmmm |
they EAT the slop! |
| 02:45 |
celeron55 |
frankly, i might work on minetest if i could make money of it |
| 02:46 |
hmmmmm |
haha |
| 02:46 |
celeron55 |
but that's not going to happen |
| 02:46 |
hmmmmm |
hey have you updated noise.cpp in buildat lately? |
| 02:46 |
twoelk|2 |
from the mc players I know it is more a combination of love and hate |
| 02:46 |
celeron55 |
i'm not working on buildat, so no |
| 02:46 |
hmmmmm |
oh, you should, it's gotten better |
| 02:46 |
hmmmmm |
more organized |
| 02:49 |
celeron55 |
anyway, the charm of minetest originally was that i could slap together any kind of crap i wanted with the amount effort i felt like and publish it, and people had fun with it |
| 02:49 |
celeron55 |
it's pretty difficult to do that now |
| 02:50 |
hmmmmm |
why do you suppose that is? |
| 02:50 |
celeron55 |
there are these pesky other people around that think they're developers or something |
| 02:51 |
hmmmmm |
haha |
| 02:53 |
celeron55 |
i mean |
| 02:53 |
celeron55 |
after all these concerns that were now said, i don't feel like putting the apk up on google play at all anymore |
| 02:53 |
celeron55 |
i feel like moving to work on my solo projects where i don't need to listen to naysayers |
| 02:54 |
celeron55 |
and put anything i want on google play |
| 02:54 |
celeron55 |
and elsewhere |
| 02:55 |
ShadowNinja |
Forum poll sounds good. I'd like to see your fixes merged though. |
| 02:55 |
celeron55 |
most of them are hacks, not fixes |
| 02:56 |
ShadowNinja |
Well, made into fixes and merged them. :-) |
| 03:19 |
hmmmmm |
i am getting so upset with irrlicht |
| 03:19 |
|
kaeza joined #minetest-dev |
| 03:19 |
hmmmmm |
it's not calling the correct (useful) constructor |
| 03:55 |
hmmmmm |
we desperately need to fix config files |
| 03:56 |
hmmmmm |
prefix options that affect the client with cl_, server options with sv_ |
| 03:56 |
hmmmmm |
or perhaps wrap them in a settings group |
| 04:03 |
* kaeza |
mumbles something about [sections] |
| 04:04 |
VanessaE |
or just split them into separate files. |
| 04:04 |
VanessaE |
we can already do that now |
| 04:05 |
VanessaE |
(after a fashion) |
| 04:10 |
hmmmmm |
true |
| 04:11 |
hmmmmm |
i'm just thinking how easily it can get jumbled up if you don't use minetest.conf.example |
| 04:11 |
VanessaE |
indeed. |
| 04:11 |
hmmmmm |
anyway |
| 04:11 |
hmmmmm |
i'm not so sure how i'm going to do this |
| 04:12 |
hmmmmm |
right now i have the options menu taking up the entire screen |
| 04:12 |
hmmmmm |
sort of ugly with the text in the background though and the transparency |
| 04:12 |
hmmmmm |
what do you guys think? |
| 04:12 |
hmmmmm |
really? big menus like that deserve the entire screen |
| 04:26 |
|
selat joined #minetest-dev |
| 04:47 |
ShadowNinja |
hmmmmm: There should be several pages of settings. Eg, xonotic has audio, video, effects, user, misc, player... |
| 04:48 |
hmmmmm |
i have it: |
| 04:48 |
hmmmmm |
Game Options, Video Options, Sound Options, Control Options, Multiplayer Options |
| 04:49 |
hmmmmm |
things like view bobbing amount and fall bobbing amount should probably go into a Player Options |
| 04:49 |
hmmmmm |
Multiplayer Options should be changed to Server Options or something |
| 04:57 |
|
Miner_48er joined #minetest-dev |
| 04:58 |
|
chchjesus__ joined #minetest-dev |
| 05:04 |
hmmmmm |
hmm |
| 05:04 |
hmmmmm |
android doesn't have tooltips so i need another way to explain the options for mobile |
| 05:06 |
VanessaE |
press-and-hold for a popup? |
| 05:06 |
hmmmmm |
no idea how to do this or even attempt to |
| 05:06 |
VanessaE |
or maybe a widget that you can drag around that gives help as it crosses over an item? |
| 05:07 |
hmmmmm |
i like the second idea |
| 05:07 |
VanessaE |
if screens that could detect hovering a finger (like on Galaxy S4) were more common, I'd just suggest that |
| 05:07 |
ShadowNinja |
hmmmmm: There are a lot of visual options, said game splits it into video and effects, you hay have to do something similat. |
| 05:08 |
hmmmmm |
yeah |
| 05:08 |
hmmmmm |
shaders and related things should count as being an effect |
| 05:09 |
ShadowNinja |
hmmmmm: Also, the current setup if pretty horrible, with 5+ lines to handle just setting every indifidual option. That should be cleaned. |
| 05:09 |
hmmmmm |
then there's shit like screen dpi that i have no idea aboy |
| 05:09 |
hmmmmm |
about* |
| 05:09 |
ShadowNinja |
That would be video. |
| 05:09 |
hmmmmm |
my way takes like 5 lines total |
| 05:10 |
hmmmmm |
whoever coded most of the current shit is dum |
| 05:10 |
ShadowNinja |
aniso, mip-map, etc are also effects. |
| 05:10 |
hmmmmm |
nope |
| 05:10 |
hmmmmm |
that's definitely video options tab material |
| 05:10 |
ShadowNinja |
video is just basic stuff like resolution. |
| 05:11 |
ShadowNinja |
At least that's how xonotic does it. |
| 05:11 |
hmmmmm |
they're dum |
| 05:11 |
ShadowNinja |
It works well. |
| 05:12 |
hmmmmm |
i could poop on a piece of paper that has 'options' written on it and that'd work well |
| 05:13 |
hmmmmm |
we just need to have *an* options page |
| 05:13 |
hmmmmm |
as it exists it's quite pathetic |
| 05:14 |
hmmmmm |
so I'm thinking things such as dpi, hud options, tooltip delay amount, etc... they need to go into some sort of "2d gui" settings section |
| 05:14 |
hmmmmm |
tooltip show delay shouldn't even be user-configurable. that's just configuration insanity |
| 05:16 |
|
Wayward_One joined #minetest-dev |
| 05:16 |
hmmmmm |
so fahnny quit message |
| 05:16 |
Wayward_One |
i couldn't resist xD |
| 05:45 |
|
chchjesus joined #minetest-dev |
| 06:14 |
|
prozacgod joined #minetest-dev |
| 06:22 |
|
paramat joined #minetest-dev |
| 06:23 |
paramat |
hmmmmm in 0.4.11 stable the z component of 2D perlinmap size is actually necessary to avoid crashes, z=1 is required |
| 06:24 |
paramat |
otherwise 'Error in `./minetest': corrupted double-linked list: 0x00007f89b82170d0' |
| 06:24 |
paramat |
either that or segfault |
| 06:29 |
|
OldCoder joined #minetest-dev |
| 06:37 |
|
Hunterz joined #minetest-dev |
| 06:55 |
|
paramat left #minetest-dev |
| 06:56 |
hmmmmm |
hrmmm |
| 06:56 |
hmmmmm |
well that's interesting |
| 06:56 |
hmmmmm |
i checked it out, and it shouldn't be necessary |
| 06:57 |
hmmmmm |
reason being that when you pass the Z component into the ctor it compares <= 1 for deciding whether or not it's 3d |
| 06:57 |
hmmmmm |
rather > 1 |
| 06:58 |
hmmmmm |
so if z is 0 (which it is as the default value) or a negative number, then is3d == false |
| 06:58 |
hmmmmm |
ahhhhh |
| 06:58 |
hmmmmm |
that only works for the noise buffer, not the interpolation buffer |
| 06:58 |
hmmmmm |
i need to fix this |
| 07:00 |
hmmmmm |
when i initially looked at it, i was pleasantly surprised at how the problem of not having to specify a z param works itself out but i guess i was wrong |
| 07:24 |
|
paramat joined #minetest-dev |
| 07:27 |
paramat |
hmmmmm, i was just looking at your lvm mapgen example, should update_liquids be before write_to_map or after? i have always placed it after, in your example it is before |
| 07:27 |
hmmmmm |
actually it doesn't matter |
| 07:27 |
paramat |
okay good |
| 07:28 |
hmmmmm |
hrmm |
| 07:28 |
hmmmmm |
wondering if I should add a "Show Advanced Options" button for the Video tab |
| 07:40 |
|
paramat left #minetest-dev |
| 07:46 |
VanessaE |
hmmmmm: +1 |
| 07:47 |
hmmmmm |
what's an advanced option is up for debate however |
| 07:47 |
hmmmmm |
i'm going to leave that up to you people to decide |
| 07:47 |
VanessaE |
hmmmmm: anything your average dumb user won't understand :PO |
| 07:47 |
VanessaE |
:P |
| 07:47 |
VanessaE |
really though, all the shader stuff belongs there probably |
| 07:47 |
hmmmmm |
well I have the basic options as: |
| 07:48 |
hmmmmm |
video driver, resolution, fullscreen, vsync, mipmaps, anisotropic filtering, bilinear/trilinear filtering, fsaa, smooth lighting |
| 07:48 |
VanessaE |
hrm |
| 07:49 |
hmmmmm |
advanced.. oh man, that's a clusterfuck |
| 07:49 |
VanessaE |
smooth lighting is a basic thing, video driver and fullscreen too, resolution maybe also. the rest? advanced. |
| 07:49 |
hmmmmm |
enable_particles, enable_waving_*, enable_fog, directional_colored_fog, etc. |
| 07:49 |
hmmmmm |
well |
| 07:49 |
hmmmmm |
on the scale from basic to really freaking advanced |
| 07:49 |
hmmmmm |
those are fairly basic compared to the other things |
| 07:49 |
VanessaE |
true |
| 07:50 |
hmmmmm |
like... desynchronized mapblock texture animation? |
| 07:50 |
hmmmmm |
parallax occlusion bias? |
| 07:50 |
VanessaE |
but the average user won't know what FSAA even *does* or that ^^ one either |
| 07:50 |
hmmmmm |
yes they do |
| 07:50 |
hmmmmm |
they see it in like every video game ever |
| 07:50 |
VanessaE |
(and desync, you almost never want to expose, btw) |
| 07:51 |
VanessaE |
ok I'll agree with you on FSAA I guess |
| 07:51 |
VanessaE |
I'm too used to dealing with kids that don't even know how to google something :-/ |
| 07:51 |
hmmmmm |
i'm sure the average PC gamer will notice their game looks all pixelly and say to themselves, "i'm going to look in the graphics options menu and see if i can find "antialiasing" or "aa" or "fsaa" " |
| 07:55 |
|
jluc joined #minetest-dev |
| 07:56 |
hmmmmm |
what do you guys think about biomes overriding settings such as water_wave_height/water_wave_length/water_wave_speed? |
| 07:56 |
hmmmmm |
or enable_clouds |
| 07:56 |
hmmmmm |
if you're in hell you probably don't... want clouds |
| 07:56 |
hmmmmm |
or an alien planet |
| 07:57 |
VanessaE |
actually that's not a bad idea |
| 07:57 |
VanessaE |
I've wanted, for a long while, to be able to specify the cloud height from the server at least. |
| 07:58 |
VanessaE |
and disabling clouds would be surely wanted on e.g. moontest |
| 07:58 |
hmmmmm |
on minecraft i think clouds are decided server-side |
| 07:59 |
VanessaE |
(I forgot/wasn't ware that the wave height/speed/length was configurable) |
| 07:59 |
VanessaE |
aware* |
| 08:00 |
leat |
/bye |
| 08:00 |
leat |
whoops |
| 08:27 |
|
leat joined #minetest-dev |
| 08:45 |
|
jin_xi joined #minetest-dev |
| 09:01 |
|
kilbith joined #minetest-dev |
| 09:15 |
|
leat joined #minetest-dev |
| 09:27 |
kilbith |
sfan5, the local map saving ought 1) save in its own dir 2) save the worldmods |
| 09:27 |
sfan5 |
worldmods? |
| 09:28 |
sfan5 |
how exactly is it supposed to do that |
| 09:28 |
sfan5 |
it could theortically generate lua code with the node/item definition received from the server, but I'm not going to implement that |
| 09:28 |
kilbith |
i mean download the respective mods for each world and put them in /worldmods |
| 09:28 |
sfan5 |
download from where? |
| 09:30 |
kilbith |
from the server ofc |
| 09:30 |
sfan5 |
the server only sends itemdefs, nodedefs and textures to the cleint |
| 09:30 |
sfan5 |
client* |
| 09:30 |
sfan5 |
not the full mods |
| 09:31 |
sfan5 |
there is zero lua code being transferred between client and server |
| 09:32 |
kilbith |
ok and it's not technically possible to fetch the mods dir to local ? |
| 09:32 |
sfan5 |
no |
| 09:32 |
sfan5 |
not technically possible |
| 09:33 |
kilbith |
hmm, ok |
| 09:33 |
kilbith |
that's a bit embarrassing |
| 09:33 |
sfan5 |
<sfan5> it could theortically generate lua code with the node/item definition received from the server, but I'm not going to implement that |
| 09:43 |
kilbith |
well, i added your feature in the Client tab: https://cdn.mediacru.sh/z/zuEcbEJK9prO.jpg |
| 10:01 |
|
ImQ009 joined #minetest-dev |
| 10:08 |
celeron55 |
hmmmmm: it's already possible to disable clouds independently for each player by setting a non-default sky with the set_sky function; but i guess biomes could control how the default sky looks |
| 10:08 |
celeron55 |
so then you'd end up using that functionality only if you want to do something really special or don't use native biomes |
| 10:08 |
celeron55 |
it's a parallel implementation though, which will cause problems when people want something in between but can't have it |
| 10:10 |
celeron55 |
it should probably be something like override_sky() which could affect any individual part of the sky and not just override everything |
| 10:22 |
|
selat joined #minetest-dev |
| 10:24 |
|
leat joined #minetest-dev |
| 10:47 |
|
ImQ009 joined #minetest-dev |
| 11:02 |
|
kaeza joined #minetest-dev |
| 11:08 |
celeron55 |
has somebody broken profiler_print_interval? |
| 11:08 |
celeron55 |
i'm setting it to 10 and enabling info-level logging, but nothing comes up in logs |
| 11:17 |
celeron55 |
no, i'm giving up |
| 11:17 |
celeron55 |
what the fuck |
| 11:17 |
celeron55 |
this "improved" configuration phase at start-up is ridiculously convoluted |
| 11:18 |
celeron55 |
fix this shit, i'm out |
| 11:21 |
celeron55 |
all i wanted to do is find out what is taking so much processing time per frame on my phone, but apparently i can't do it |
| 11:27 |
|
proller joined #minetest-dev |
| 11:29 |
|
leat joined #minetest-dev |
| 12:03 |
|
leat joined #minetest-dev |
| 12:14 |
|
cib0 joined #minetest-dev |
| 12:20 |
|
sapier joined #minetest-dev |
| 12:24 |
sapier |
ShadowNinja: why don't you just go an help fixing the android bugs on your list instead of insisting on "I told there's a bug" ... there are some bugs on it which don't even require major knowledge about android to be fixed |
| 12:25 |
sapier |
e.g. your shader config "BUG" |
| 12:25 |
sapier |
or the log "bug" |
| 12:25 |
sapier |
or "inventory fields debug" |
| 12:27 |
sapier |
hmmmm celeron55 android ain't only phones but tablets too and tablets may have screensizes up to small pc's so there unused space in menu might be better than having large distances between controls |
| 12:27 |
sapier |
just to be back at main android issue ... the big range of device types |
| 12:29 |
celeron55 |
well, true |
| 12:30 |
sapier |
"ShadowNinja hmmmmm: There should be several pages of settings. Eg, xonotic has audio, video, effects, user, misc, player..." well someone promised to do this change about 6 months ago |
| 12:30 |
celeron55 |
the size should be set in such a way that it tries to be physically a certain size |
| 12:30 |
celeron55 |
and if that doesn't fit on the screen, then whatever fits |
| 12:31 |
sapier |
actually I try to do this, yet it's very simplistic and my have bugs in combinationwith new font scaling code |
| 12:31 |
celeron55 |
on my phone's screen the menus are way smaller than what fits on the screen, and physically they are sized for insects |
| 12:31 |
sapier |
android evaluates dpi as well as screen size and trys to set a sane gui_scaling default ... well what I found on my devices to be sane .. I don't put my hand into fire this is true for other devices too |
| 12:32 |
sapier |
yes that's been same for me after gui scaling too |
| 12:32 |
sapier |
wait |
| 12:32 |
sapier |
ShadowNinja: did merge the two menus |
| 12:32 |
sapier |
and simple menu didn't have fixed menu size as complex has |
| 12:32 |
sapier |
maybe that difference was lost |
| 12:33 |
sapier |
let me check |
| 12:33 |
sapier |
no he did it correct |
| 12:37 |
sapier |
I guess I found the issue with our font's they seem to handle dpi different then formspec |
| 12:38 |
sapier |
I gues they're adjusted to dpi twice |
| 12:40 |
sapier |
grr they're not adjusted at all because of that silly half disabling font size hack ... ok back to beginning to find the real issue |
| 12:43 |
|
chchjesus joined #minetest-dev |
| 12:44 |
sapier |
reenabling the font size scaling as it's been meant to behave fixes the issue ... yet there have been complaints about the font size scaling |
| 12:44 |
sapier |
let's see if now menu size is correct on my phone too |
| 12:46 |
sapier |
Zeno for what I remember you did the workaround can you tell me what exactly you tried to fix? |
| 13:41 |
|
twoelk joined #minetest-dev |
| 13:55 |
|
crazyR joined #minetest-dev |
| 13:56 |
|
shadowzone joined #minetest-dev |
| 14:08 |
sapier |
celeron55 I found out why menu is so small ... it's related to in game controls |
| 14:08 |
sapier |
the scaling factor is same and it's adjusted to make controls in game work |
| 14:08 |
sapier |
increasing the scaling makes controls overlap |
| 14:16 |
celeron55 |
yes, they will overlap a bit when the menu is at a reasonable size on the small screen |
| 14:16 |
celeron55 |
also, some menus are much larger than others and they should be automatically limited to fit the screen |
| 14:16 |
celeron55 |
so i guess the in-game UI should be limited similarly to them |
| 14:17 |
sapier |
I agree that they should but I fear we can't do this without causing sideeffects like font scaling did |
| 14:17 |
sapier |
and there someone just disabled the font scaling to get rid of them ;-) |
| 14:18 |
sapier |
btw if you reenable it android menu fonts match the formspec size and look fine |
| 14:19 |
celeron55 |
what do you mean someone disabled font scaling |
| 14:19 |
sapier |
guiFormSpecMenu.cpp about line 78 |
| 14:19 |
sapier |
select_font_by_line_height selects correct font size for formspec size |
| 14:19 |
sapier |
but it's just been disabled and provides default font size |
| 14:20 |
celeron55 |
why |
| 14:20 |
|
leat joined #minetest-dev |
| 14:20 |
sapier |
because some ppl haven't been happy with fonts doing correct scaling. I haven't found out till now WHAT exactly they didin't like |
| 14:20 |
celeron55 |
just change it back, it's obviously the right thing to do |
| 14:21 |
celeron55 |
scaling a pixel-positioned UI like this doesn't make sense if fonts don't scale along with it |
| 14:21 |
celeron55 |
or, makes very little sense |
| 14:21 |
sapier |
I guess some ppl did design their oversized formspecs with small fontsize in mind so those formspecs might now have fonts overlapping gui elements |
| 14:22 |
celeron55 |
what do they expect? development to completely stop? |
| 14:22 |
sapier |
but I don't really know everytime I did ask what exactly is wrong I didn't get a answer |
| 14:22 |
celeron55 |
they can stay at 0.4.11 if they don't want development |
| 14:23 |
sapier |
I guess we could add automatic scale down if a formspec exceeds display size |
| 14:24 |
sapier |
not sure how much has to be changed but I guess it's limited |
| 14:26 |
sapier |
ok fixed the progress bar jumping on asset copy |
| 14:27 |
sapier |
guess I'm gonna push there changes in a few minutest just testing them on different devices |
| 14:27 |
|
kilbith joined #minetest-dev |
| 14:29 |
|
cib0 joined #minetest-dev |
| 14:52 |
|
ImQ009_ joined #minetest-dev |
| 14:52 |
|
leat joined #minetest-dev |
| 14:57 |
|
leat joined #minetest-dev |
| 15:02 |
|
leat joined #minetest-dev |
| 15:04 |
sapier |
https://github.com/minetest/minetest/pull/2057 merging in a few minutes, only non android change is re-enabling of font scaling |
| 15:08 |
|
leat1 joined #minetest-dev |
| 15:12 |
sapier |
I made ShadowNinjas buglist to issues ... well I don't understand why he doesn't do this himself, bugs can't be fixed if they're only known to him as he refuses to fix them too |
| 15:16 |
sapier |
celeron55 I just pushed a bunch of fixes for android, not all we did talk about yesterday |
| 15:20 |
|
paramat joined #minetest-dev |
| 15:21 |
|
shadowzone joined #minetest-dev |
| 15:26 |
sapier |
Ok after checking all of shadows list I could only fix a single of his complaints, everything else either "works for me" or is a matter of taste/design. Performance issues depend on particular devices, I don't know what device he's using. |
| 15:27 |
|
hmmmm joined #minetest-dev |
| 15:28 |
sapier |
e.g. the chat window .. it's a formspec so it behaves like one. And in formspecs there could be more then one text field so closing it immediatly ain't a good idea in general |
| 15:28 |
sapier |
We could replace the formspec chat window by a native android one, yet if there are plans to remove it in favour of console why do this? |
| 15:32 |
paramat |
hmmmm i need a more general way to switch off clouds (while keeping the day-night cycle/blue sky/sun/moon/stars), not a way only usable within biomes. something better than this https://github.com/paramat/flexrealm/blob/master/init.lua#L187 which fails to work properly when playing singleplayer, it leaves my .conf modified so i always have to edit it to re-enable clouds |
| 15:33 |
paramat |
must go, exhausted |
| 15:33 |
|
paramat left #minetest-dev |
| 15:35 |
hmmmm |
I agree, a lot of audio-visual effects are left as config options that have an impact on gameplay |
| 15:35 |
hmmmm |
what I think would be smarter is to leave clouds as configurable with a client-side |
| 15:35 |
hmmmm |
client-side mod |
| 15:36 |
hmmmm |
you know I really don't like adding more server/client packets for asstarded things like enabling and disabling clouds |
| 15:38 |
hmmmm |
leaving all of these things for client-side modding is good because it builds up more pressure for getting the client side modding done |
| 15:38 |
sapier |
why? ;-) |
| 15:38 |
sapier |
there's no developer who really wants it by now |
| 15:39 |
sapier |
I never heared anyone (except you) demand it who actually does work |
| 15:40 |
hmmmm |
because the people who really want it are modders, not developers |
| 15:42 |
sapier |
do those modders know that these mods would be 100% independent of the mods they do now? |
| 15:42 |
hmmmm |
they wouldn't |
| 15:42 |
sapier |
of course they would |
| 15:42 |
hmmmm |
a server-side mod is able to create client-side mod dependencies |
| 15:42 |
|
Wayward_One joined #minetest-dev |
| 15:42 |
hmmmm |
the user is directed to download the client-side mods from a trusted repository like mmdb |
| 15:43 |
sapier |
no because if there was a ways for them to communicate you'd immediatly get huge security implications |
| 15:43 |
hmmmm |
I realize that |
| 15:43 |
hmmmm |
as long as we strap down the GPU access as well we should be fine |
| 15:43 |
sapier |
btw there's two different things |
| 15:43 |
hmmmm |
having them communicate is pretty much necessary |
| 15:43 |
sapier |
client side lua AND client side mods |
| 15:43 |
sapier |
both are quite different |
| 15:44 |
kahrl |
I thought they were called OTTO and ZEUS |
| 15:44 |
sapier |
yes kahrl they are but I don't know if hmmmm alread knows the names |
| 15:45 |
|
PilzAdam joined #minetest-dev |
| 15:45 |
sapier |
;-) |
| 15:45 |
sapier |
seems the names are silly enough to get remembered |
| 15:45 |
sapier |
so OTTO is security critical ZEUS ain't ;-) |
| 15:45 |
sapier |
as long as ZEUS doesn't have communication capability to server |
| 15:46 |
hmmmm |
how is this any different from running a website's javascript |
| 15:46 |
|
leat1 joined #minetest-dev |
| 15:47 |
kahrl |
I could only remember them because there was a play with Zeus at the Hans-Otto in Potsdam ;) |
| 15:47 |
sapier |
OTTO ain't different (except of testing effort) |
| 15:47 |
sapier |
ZEUS is more like a browser style theme |
| 15:48 |
sapier |
kahrl captial letters are required ;-) |
| 15:48 |
sapier |
hmmmm I assume you actually want OTTO and not ZEUS |
| 15:49 |
|
ImQ009 joined #minetest-dev |
| 15:50 |
hmmmm |
i have no idea what otto and zeus are |
| 15:50 |
sapier |
OTTO is lua code sent from server mod to client |
| 15:50 |
sapier |
automatically no manual install by client |
| 15:50 |
hmmmm |
i thought we decided against OTTO |
| 15:51 |
sapier |
I don't know about a decision like that |
| 15:51 |
sapier |
OTTO is basically identical to javascript |
| 15:51 |
sapier |
except of the testing of course |
| 15:51 |
hmmmm |
right |
| 15:52 |
hmmmm |
what i meant to say is that this is no more dangerous than javascript |
| 15:52 |
sapier |
it is ... not by design but by confidence in code correctness |
| 15:52 |
sapier |
even javascript does have issues every now and then it's quite likely we'll have more |
| 15:53 |
sapier |
and ZEUS with client server communication added is no less dangerous then OTTO but way more inconvenient |
| 15:55 |
hmmmm |
ZEUS is less likely to be malicious though |
| 15:55 |
sapier |
no it ain't if there's client server communication ... at least if zeus aint a limited home brew language |
| 15:56 |
hmmmm |
oh, because they can execute instructions from the server effectively making it OTTO? |
| 15:56 |
hmmmm |
yeah, that's essential for making things work |
| 15:56 |
sapier |
exactly |
| 15:57 |
sapier |
so only real usecase for ZEUS is modifying the look and feel of client ... well nice but nothing I'd spend time on ;-) |
| 15:58 |
sapier |
while OTTO is valuable and I may even implement it soon |
| 15:58 |
sapier |
especially as most parts are already done |
| 15:59 |
hmmmm |
woah, one thing at a time here :/ |
| 15:59 |
hmmmm |
we need to get the gui working on android well |
| 15:59 |
hmmmm |
from what i understand, the menus don't take up all the available screen space on android... what's up with that? it's a mobile device |
| 15:59 |
sapier |
hmmmm write issues for what you feel not to work! don't do it like shadow |
| 16:00 |
sapier |
menu taking all available space on my tablet would look crazy |
| 16:00 |
sapier |
there's no one solution for all ;-) |
| 16:01 |
sapier |
we're gonna have to do some tuning and find heuristics to decide best |
| 16:02 |
PilzAdam |
sapier, https://github.com/minetest/minetest/commit/083d19b3fc8f60468e124c801296c13b66c41abc#diff-65f34680878a6bd86f3a59ebc0c06c6dL93 wtf? |
| 16:02 |
sapier |
but that's not gonna work the "i change it this way because it looks best on my device"-way ;-) |
| 16:02 |
PilzAdam |
have you fixed the issues with the font scaling? |
| 16:02 |
sapier |
what exactly? |
| 16:02 |
sapier |
of course |
| 16:02 |
sapier |
works for me |
| 16:02 |
sapier |
at least all "issues" anyone told me |
| 16:03 |
PilzAdam |
nothing changed for me |
| 16:03 |
PilzAdam |
the text is like 200% bigger now |
| 16:03 |
|
cib0 joined #minetest-dev |
| 16:03 |
sapier |
did you fix your gui scaling? |
| 16:04 |
PilzAdam |
I don't want to change the size of inventory images |
| 16:04 |
PilzAdam |
I want to change the size of the font |
| 16:04 |
sapier |
you can't |
| 16:04 |
PilzAdam |
yes, thats the issue |
| 16:04 |
sapier |
you couldn't really do this before either |
| 16:04 |
sapier |
it's not an issue |
| 16:04 |
PilzAdam |
it worked perfectly fine |
| 16:05 |
celeron55 |
can't there be a setting that by default is disabled but if it is set to a value, the value is directly used as the font size with no scaling whatsoever? |
| 16:05 |
sapier |
vanessaE has a nice cartoon there ... about some spacebar heating processor |
| 16:05 |
celeron55 |
then pilzadam and other old-timey desktop users can use that setting |
| 16:05 |
VanessaE |
http://xkcd.com/1172/ |
| 16:06 |
PilzAdam |
celeron55, that only fixes a part of the problem |
| 16:06 |
sapier |
well he can set the font size smaller so it's gonna behave same but I won't add a if then else else else cascade everywhere wher dpi screen size and font size is used |
| 16:06 |
PilzAdam |
another thing is that I want a bigger hotbar, but not a bigger inventory |
| 16:06 |
sapier |
noone ever will be able to debug this |
| 16:06 |
VanessaE |
sapier: xkcd always has a relevant cartoon :) |
| 16:06 |
PilzAdam |
one setting for everything GUI related is stupid |
| 16:06 |
sapier |
why? |
| 16:07 |
sapier |
do you wanna have a different setting per formspec element name? |
| 16:07 |
PilzAdam |
the inventory scales with my window size while the hotbar doesn't |
| 16:07 |
sapier |
or maybe even per formspec id |
| 16:07 |
PilzAdam |
I don't want to change the GUI scale factor when resizing my window |
| 16:07 |
sapier |
of course that could be added you'd just have to write your own client config per server/mod |
| 16:07 |
celeron55 |
we should just rip out all UI and implement it properly from scratch |
| 16:07 |
celeron55 |
and obsolete every mod that has any UI |
| 16:08 |
VanessaE |
celeron55: define "properly" |
| 16:08 |
celeron55 |
it's the only way to win |
| 16:08 |
celeron55 |
taking all learned concerns into account |
| 16:08 |
sapier |
celeron55 we just mad it consistent causing all those complains ... do you expect a new one beeing consistend wouldn't cause same complains? |
| 16:09 |
PilzAdam |
also why is the status text (e.g. when chaning noclip) moved to the center of the screen? |
| 16:09 |
PilzAdam |
it used to be in the bottom left corner |
| 16:09 |
sapier |
the only way to consider all those complains would be adding some sort of html + css mechanism where each user could specify his own css ;-) |
| 16:09 |
celeron55 |
i was wondering that too, it was changed by someone recently (i saw the commit) |
| 16:09 |
celeron55 |
i think it's a stupid change |
| 16:10 |
sapier |
I haven't changed that PilzAdam |
| 16:10 |
sapier |
at least not intentionally |
| 16:10 |
celeron55 |
PilzAdam: can you make a list of what UI things you want to configure separately, given that everything must fall under some setting |
| 16:11 |
celeron55 |
i think it is very unclear until you do that |
| 16:11 |
celeron55 |
the scaling of them, i mean |
| 16:11 |
sapier |
well I guess we need two different scale factors for hud and formspec anyway so maybe PilzAdams issues would be solved this way |
| 16:11 |
PilzAdam |
celeron55, what I personally want now or what would be good to have generally? |
| 16:12 |
celeron55 |
PilzAdam: something that can be implemeted and that also is usable on everywhere where minetest is used |
| 16:12 |
VanessaE |
sapier: font size in a formspec, font size in the main menu (and related), HUD scaling ... those are the three I can see an immediate need for, if you were to fully re-enable your font patches |
| 16:12 |
VanessaE |
(c55 ^^) |
| 16:13 |
celeron55 |
when every person decides to require one part of the UI to be exactly the same as before, with enough people no parts of the UI can change at all and we will be left with no way whatsoever to make this work on different screen sizes |
| 16:13 |
sapier |
formspec is formspec I'll not implement different scale factors for them ... best I'd provide is implement per formspec configurable form size |
| 16:13 |
celeron55 |
VanessaE: relative to what? pixels? window size? screen size? dpi? |
| 16:13 |
sapier |
font size |
| 16:13 |
celeron55 |
VanessaE: each otherr? |
| 16:13 |
celeron55 |
-r |
| 16:13 |
sapier |
meaning you can specify a different then default font size for each text in a formspec |
| 16:14 |
VanessaE |
celeron55: relative to physical screen size, I suppose. |
| 16:14 |
VanessaE |
I dunno, I'm just going from my own experience when his font patches were enabled. |
| 16:15 |
celeron55 |
well experience is what we need, not guesswork |
| 16:15 |
VanessaE |
the HUD would be relative to some sane "standard size" (perhaps the usual height as seen in an 800x600 window from several versions ago) |
| 16:16 |
sapier |
right now font size keeps aspect to form size |
| 16:16 |
sapier |
if form spec is shown at twice size the fonts are shown twice as high too |
| 16:17 |
VanessaE |
sapier: which looks like total ass, frankly. |
| 16:17 |
celeron55 |
well, it's exactly what one wants on the 400x300...1920x720 2.5"...15" androids |
| 16:17 |
VanessaE |
but that takes a back seat to "gazonga fonts in the inventory, dinky fonts in the main menu" |
| 16:18 |
celeron55 |
i mean, 400x300 15" ... 1920x1080 2.5" |
| 16:18 |
VanessaE |
celeron55: sure -- on an Android display, but you do NOT want it on a desktop usually |
| 16:18 |
sapier |
so how do you think it should behave VanessaE |
| 16:18 |
VanessaE |
right, I got that. |
| 16:18 |
VanessaE |
sapier: a consistent size on the desktop, regardless of window size. |
| 16:18 |
celeron55 |
that's what the problem seems to be |
| 16:19 |
sapier |
always keep your 10 pixels font even if screen has 100dpi? |
| 16:19 |
PilzAdam |
the problem is (I guess), that formspecs are not good at defining a GUI that would work with different font sizes |
| 16:19 |
VanessaE |
like EVERY OTHER DAMNED APPLICATION. |
| 16:19 |
sfan5 |
^ |
| 16:19 |
sapier |
even my tablet doesn't have enough physical size to show my desktop sized menu! |
| 16:19 |
VanessaE |
sapier: no, keep my font at 13 point (note, points -- not pixels) regardless of 96 or 200 DPI screens, or 800x600 window or 1600x1200 window |
| 16:19 |
celeron55 |
sapier: what if you just scale the formspecs and UI according to *display* size, not *window* size? does that even make any sense? |
| 16:20 |
celeron55 |
it might not make |
| 16:20 |
VanessaE |
celeron55: then big formspecs - probably even the standard inventory - will exceed the default window bounds. |
| 16:20 |
celeron55 |
VanessaE: wut? |
| 16:20 |
sapier |
hmm would be worth a try but would break for almost anyone |
| 16:20 |
celeron55 |
that's what already happened previously |
| 16:21 |
VanessaE |
celeron55: nevermind - misread. |
| 16:21 |
celeron55 |
and what happens if you have a consistent size like you wanted |
| 16:21 |
VanessaE |
I don't get what's so fucking hard about reading the screen DPI from the OS's windowing system? |
| 16:22 |
VanessaE |
celeron55: what happens is what happens now - fonts remain readable at any window size and there isn't any of this mishegas about fonts suddenly becoming monster-sized just because the window is bigger. |
| 16:22 |
celeron55 |
has anyone even tried getting the DPI from the OS |
| 16:22 |
sapier |
yes I did |
| 16:22 |
sapier |
it's not possible on pc right now |
| 16:22 |
celeron55 |
what happened |
| 16:22 |
VanessaE |
bullshit |
| 16:23 |
sapier |
there are some discussions about implementing it in future irrlicht versions |
| 16:23 |
VanessaE |
then don't use irrlicht to query it. |
| 16:23 |
sapier |
well it's the only consistent way unless you wanna implement a separate way for each and every os |
| 16:24 |
sapier |
but I have to leave no I'm gonna read the logs later |
| 16:24 |
|
sapier left #minetest-dev |
| 16:24 |
VanessaE |
"each and every OS" meanwhile there are only three windowing systems you need to worry about. |
| 16:24 |
VanessaE |
X11, Windows, and OS-X. |
| 16:24 |
celeron55 |
true |
| 16:25 |
VanessaE |
and if you can't get DPI sanely, assume a standard default that the user can easily change. |
| 16:25 |
|
Peon501 joined #minetest-dev |
| 16:25 |
PilzAdam |
celeron55, I thought about that list with UI settings, and it turns out that missing settings aren't really the problem |
| 16:25 |
VanessaE |
or get it from...*gasp* the user's window manager |
| 16:26 |
PilzAdam |
there are 2 problems that currently annoy me: 1) some things scale with the window size (formspecs, except mainmenu) and others don't (version string in the top left; hotbar) 2) when scaling up, everything is scaled up instead of realigned |
| 16:26 |
PilzAdam |
2) causes these gigantic fonts on larger screens |
| 16:27 |
VanessaE |
PilzAdam: 2. is precisely the problem I'm arguing against as well |
| 16:27 |
PilzAdam |
if we had a proper definition of our UI's, then we could scale things up properly instead of just "zooming in" |
| 16:28 |
VanessaE |
a quick google says Windows from XP on up, and X11 all have API calls to query the screen DPI |
| 16:29 |
PilzAdam |
we basically just need 2 settings if these problems are fixed: 1) a gui scale factor 2) how windows size scales the GUI |
| 16:29 |
|
roniz joined #minetest-dev |
| 16:30 |
PilzAdam |
so we need layout managers (like in Qt or swing) to define formspecs |
| 16:37 |
|
Calinou joined #minetest-dev |
| 16:38 |
PilzAdam |
or we allow Lua to define a function that gets the window size as parameter to layout the formspec |
| 16:38 |
PilzAdam |
this would only work with client size Lua, though |
| 16:38 |
Calinou |
client can send its window size to server. |
| 16:38 |
Calinou |
then server can work with it |
| 16:38 |
Calinou |
of course, there should be a reasonable min/max to avoid fakes |
| 16:38 |
VanessaE |
Calinou: s/window size/screen size/ |
| 16:38 |
VanessaE |
or send both |
| 16:39 |
Calinou |
window or screen size? the Minetest window size is probably more relevant |
| 16:39 |
VanessaE |
what's a reasonable max? |
| 16:39 |
Calinou |
eg. don't allow width > 4096 |
| 16:39 |
Calinou |
but that's not really necessary |
| 16:39 |
Calinou |
in case a client would send something like 50000 to try crashing server |
| 16:39 |
VanessaE |
there are some screens beyond that rez :) |
| 16:39 |
VanessaE |
oh yeah |
| 16:40 |
|
Peon501_ joined #minetest-dev |
| 16:54 |
VanessaE |
bottom line is, no other standard app does this whole "scale every damn thing just because we can" routine. |
| 16:54 |
VanessaE |
not if they're trying to stick to your standard buttons/checkboxes/lists widgets paradigm anyway |
| 16:59 |
|
est31 joined #minetest-dev |
| 17:00 |
est31 |
hmmmm there is a srp implementation not requiring libgmp |
| 17:00 |
est31 |
only openssl |
| 17:22 |
|
Hunterz joined #minetest-dev |
| 17:44 |
|
rubenwardy joined #minetest-dev |
| 18:14 |
|
Krock joined #minetest-dev |
| 18:36 |
|
cib0 joined #minetest-dev |
| 18:45 |
sfan5 |
pushing in 5 minutes: http://sprunge.us/GbBd?diff |
| 18:46 |
Krock |
looks like a hack. isn't it poss to chack if EXISTING_MINETEST_DIR is empty? |
| 18:46 |
Krock |
*check |
| 18:46 |
sfan5 |
this is what I'm doing |
| 18:46 |
Krock |
but it looks like the old way failed somehow |
| 18:47 |
Krock |
and now you're just adding dummy text and checking the result of it |
| 18:47 |
sfan5 |
*sigh* |
| 18:47 |
sfan5 |
-d "" is probably true |
| 18:47 |
sfan5 |
and "x$var" = "x" is a perfectly fine way to check whether the var is empty |
| 18:47 |
Krock |
mhm okay |
| 18:48 |
sfan5 |
Krock: http://stackoverflow.com/a/9097530 |
| 19:00 |
|
chchjesus joined #minetest-dev |
| 19:21 |
|
Miner_48er joined #minetest-dev |
| 19:30 |
hmmmm |
est31: cool, but I'm not the one interested in strengthening the authentication. i just recommended using SRP as an alternative to challenge response if you were going to strengthen it |
| 19:31 |
hmmmm |
like I said before... auth is FUBAR but it's just a crappy game, not important things such as SSH or online banking or whatever |
| 19:31 |
hmmmm |
people who use their "real" passwords for minetest are fools |
| 19:31 |
VanessaE |
but...but...players might lose tens of thousands of minegeld! :P |
| 19:45 |
|
russia_nekto joined #minetest-dev |
| 19:45 |
russia_nekto |
hi every1 |
| 19:45 |
russia_nekto |
want to ask, how minetest rendres settings menu ? |
| 19:46 |
VanessaE |
it |
| 19:46 |
VanessaE |
it's an Lua formspec |
| 19:46 |
russia_nekto |
but where? |
| 19:46 |
hmmmm |
it uses IGUIEnvironment |
| 19:46 |
russia_nekto |
therey is only gettest |
| 19:46 |
|
leat joined #minetest-dev |
| 19:46 |
russia_nekto |
core.show_keys_menu() |
| 19:46 |
hmmmm |
oh |
| 19:47 |
hmmmm |
that's the script api for showing the key menu |
| 19:47 |
russia_nekto |
where is it placed? |
| 19:47 |
hmmmm |
the real work is done in src/guiKeyChangeMenu.cpp |
| 19:48 |
russia_nekto |
so , render code is there? |
| 19:49 |
hmmmm |
it doesn't "render" the GUI elements, but it places them and handles events from them |
| 19:49 |
hmmmm |
the rendering is done inside of irrlicht |
| 19:49 |
russia_nekto |
ok. i got it. |
| 19:49 |
russia_nekto |
wait i take a look in this cpp |
| 19:50 |
russia_nekto |
i have one more Q |
| 19:50 |
|
crazyR joined #minetest-dev |
| 19:51 |
hmmmm |
yes..? |
| 19:54 |
russia_nekto |
i have seen this cpp |
| 19:54 |
russia_nekto |
is it true , that keys placed in enum? |
| 19:55 |
russia_nekto |
another Q: how to unbind key ? or clear the key ? |
| 19:56 |
est31 |
hmmmm, I could implement srp, but I need to get insight in how minetest contributing works. any small issue I can fix? |
| 19:58 |
russia_nekto |
hmmmm: i want to add invert_mouse options to GUI but it seems to be not so fast to do |
| 19:58 |
hmmmm |
hmmm |
| 19:58 |
Calinou |
russia_nekto, look at how other booleans are added in the Lua code |
| 19:58 |
hmmmm |
russia_nekto: you accomplish this by writing to the g_settings entry by that name |
| 19:58 |
Calinou |
you will have to add some space though |
| 19:59 |
Calinou |
else, your checkbox will fly over the clouds |
| 19:59 |
Calinou |
you could add mouse_sensitivity slider too… |
| 19:59 |
hmmmm |
coincidentally I'm already working on an all-encompassing options menu which includes that |
| 19:59 |
hmmmm |
est31, I have no idea :/ |
| 19:59 |
russia_nekto |
hmmmm: nice to hear |
| 20:00 |
russia_nekto |
one more Q: is is possible to render some texture under invetory menu? want to light some beauty to this grey boxes |
| 20:02 |
russia_nekto |
and Chest menu too |
| 20:02 |
est31 |
http://irc.minetest.ru/minetest/2014-09-22#i_3940514 |
| 20:02 |
est31 |
I'll write a PR |
| 20:03 |
russia_nekto |
what is PR? |
| 20:03 |
sfan5 |
pull request |
| 20:03 |
est31 |
pull request |
| 20:04 |
russia_nekto |
:) |
| 20:04 |
|
sapier joined #minetest-dev |
| 20:04 |
russia_nekto |
PR for what u`ll write? |
| 20:05 |
est31 |
wget 'url' && mv here there → git clone |
| 20:05 |
est31 |
simpler and better |
| 20:05 |
|
proller joined #minetest-dev |
| 20:05 |
sapier |
VanessaE we've got already 3 windowing systems on linux |
| 20:05 |
VanessaE |
sapier: we have one. X11. |
| 20:05 |
sapier |
x11 wayland and the ubuntu stuff |
| 20:06 |
VanessaE |
oh you mean those upstarts? |
| 20:06 |
VanessaE |
fuck them. |
| 20:06 |
VanessaE |
(the ubuntu one is Mir or some such I think) |
| 20:06 |
sapier |
doesn't help they're gonna be used in near future |
| 20:06 |
|
Player_2 joined #minetest-dev |
| 20:06 |
russia_nekto |
one more Q: is is possible to render some texture under invetory menu? want to light some beauty to this grey boxes |
| 20:07 |
VanessaE |
russia_nekto: there's a formspec command for that, yes |
| 20:07 |
VanessaE |
sapier: my point is, getting the DPI of the user's screen is a basic function. |
| 20:07 |
russia_nekto |
can u explain more detail? |
| 20:08 |
VanessaE |
russia_nekto: take a look at the lua_api.txt file in doc/ |
| 20:08 |
russia_nekto |
i need to call formspec with texture arg? |
| 20:08 |
VanessaE |
I don't remember the command, but it's just an extra field you add to the default inventory formspec is all |
| 20:08 |
sapier |
well it should and I'm not against it but the problems we're argueing about are not caused by dpi |
| 20:09 |
VanessaE |
sapier: they're caused *exactly* by not knowing the screen DPI |
| 20:09 |
|
Warr1024 joined #minetest-dev |
| 20:09 |
sapier |
our problem is based on two historicyl issues |
| 20:09 |
VanessaE |
sapier: because then you're measuring everything in pixels instead of points or mm or something else physical |
| 20:09 |
sapier |
1) requirement to make menu exactly same (pixel wise) size as on 800x600 |
| 20:09 |
sapier |
and 2) requirement do to do some other adjustment |
| 20:09 |
sapier |
obviously those requirements don't match |
| 20:10 |
VanessaE |
no one said the *menu* has to be exactly the same. the argument is that the fonts have to be the same - you can't go blowing a font that's sized to 13 points in the main menu, up to 50 point sized in-game just because the window size changed. no application I know of does that. |
| 20:10 |
sapier |
well this HAS ben told when the old one was replaced by formspec |
| 20:10 |
VanessaE |
that's because too much changed all at once |
| 20:11 |
sapier |
I'm the first one to drop this if there's an agreement to it |
| 20:11 |
sapier |
actually on android it IS dropped |
| 20:11 |
VanessaE |
besides, our current menu isn't really the same as it used to be. |
| 20:11 |
sapier |
it is |
| 20:11 |
VanessaE |
it didn't used to have the game selector on the bottom did it? |
| 20:12 |
VanessaE |
or the Texture Packs tab |
| 20:12 |
sapier |
last version did have |
| 20:12 |
VanessaE |
I'm comparing to the C++ menu |
| 20:12 |
sapier |
texture packs tab doesn't change the overall size |
| 20:12 |
VanessaE |
and we don't have those vertical labels along the left anymore either |
| 20:12 |
VanessaE |
so it's not "exactly the same" as before |
| 20:12 |
sapier |
we do |
| 20:12 |
|
ImQ009 joined #minetest-dev |
| 20:12 |
VanessaE |
um, no we don't. I'm looking at it :) |
| 20:13 |
sapier |
at least I have those vertical labels don't they work for you |
| 20:13 |
VanessaE |
I don't even see them, I thought kahrl removed them |
| 20:13 |
VanessaE |
hell, "Client" tab clearly lacks the room for a vert label |
| 20:14 |
sapier |
hmm you're right we don't have them .... who did remove them? |
| 20:14 |
sapier |
I didn't do this for sure |
| 20:14 |
VanessaE |
kahrl did |
| 20:14 |
VanessaE |
581efea60e8fad18b9a2fc9d544f014e2ac693f8 |
| 20:14 |
russia_nekto |
VanessaE: background[<X>,<Y>;<W>,<H>;<texture name>] this assigns bg? |
| 20:14 |
sapier |
I see |
| 20:14 |
VanessaE |
russia_nekto: yep, I think that's the one. |
| 20:15 |
sapier |
well as I said I always preferred scaling main menu it's just not been accepted by that time |
| 20:15 |
VanessaE |
just add that to the formspec code that sets the inventory |
| 20:15 |
sapier |
we didn't have proper formspec scaling by that time maybe it's better now |
| 20:15 |
russia_nekto |
VanessaE: can u answer where is a call for formspec for inventory? |
| 20:16 |
VanessaE |
russia_nekto: I don't know, try digging around in builtin/ |
| 20:16 |
russia_nekto |
ok. |
| 20:16 |
russia_nekto |
anybody knows how to find formspec call for inventory ? |
| 20:18 |
sapier |
well I'm gonna implement the x11 screen dpi code for testing purposes ... but I don't think that's gonna solve everything |
| 20:18 |
sapier |
I think we need more pieces to get it into a shape everyone can live with |
| 20:21 |
VanessaE |
according to MSDN, sapier: there are also calls for WinXP through 8.1 |
| 20:21 |
VanessaE |
s/sapier: // |
| 20:21 |
sapier |
I still don't think this solves the issues |
| 20:21 |
VanessaE |
well, if you know the screen DPI, you can compute font size as a function of *points* rather than pixels |
| 20:21 |
sapier |
you can try it set screen_dpi variable manually |
| 20:22 |
VanessaE |
then it doesn't matter if you have 800x600 or 16000x12000 |
| 20:22 |
sapier |
no because font size is not relative to screen dpi but to formspec |
| 20:22 |
VanessaE |
I mean absolute size |
| 20:22 |
sapier |
later one is relative to screen dpi |
| 20:22 |
VanessaE |
it should NEVER be relative to formspec. ever. |
| 20:22 |
sapier |
EVER |
| 20:23 |
VanessaE |
EVER. :) |
| 20:23 |
sapier |
because that's the only consistent way of scaling the forspec as a whole |
| 20:23 |
Sokomine |
i'm testing celeron's new android build. as the topic seems to be the formspecs...have you considered doing one for android where the main actions are more like icons, and lists to select from fullscreen? |
| 20:23 |
sapier |
because some of our formspec elements depend on font size |
| 20:23 |
VanessaE |
why do they depend on font size at all? |
| 20:23 |
sapier |
that's silly I know but that's the way it is |
| 20:24 |
VanessaE |
you're talking about the height of a button for example? |
| 20:24 |
sapier |
tell this to the guys who initially implemented buttons and text fields |
| 20:24 |
sapier |
even labels depend on font size |
| 20:24 |
Sokomine |
:-/ |
| 20:24 |
VanessaE |
then change the code so that the button height depends on the *rendered* font size. |
| 20:24 |
sapier |
I can't |
| 20:24 |
VanessaE |
yes you can. |
| 20:24 |
Sokomine |
guess people don't line up in order to rewrite formspecs... |
| 20:24 |
sapier |
Well it's not I can't as I can't write the code it's I can't because YOU don't accept it |
| 20:25 |
sapier |
remember our discussion with zefram? |
| 20:25 |
russia_nekto |
repeat: anybody knows how to find formspec call for inventory menu in lua scripts ? |
| 20:25 |
VanessaE |
sapier: look, no UI in existence on a desktop tolerates the kind of font scaling you're trying to push through |
| 20:25 |
sapier |
I already fixed it but YOU (and others) didn't want that fix |
| 20:25 |
VanessaE |
it just does. not. work. |
| 20:25 |
Sokomine |
isn't that something based on irrlicht? |
| 20:26 |
sapier |
It's not MY font scaling this is YOUR style of font scaling vanessaE I just accepted it for peace reason and now I have to defend YOUR requirement AGAINST you? ironic |
| 20:26 |
* VanessaE |
sighs |
| 20:27 |
sapier |
I tried to fix the formspec alignment and font dependencys but that'd have broken any single existing formspec so you didn't want it |
| 20:27 |
VanessaE |
it's not my style of font scaling, sapier. it's just how desktops work. you don't go fucking around with peoples' font settings (or looking like you do) just because those settings seem "wrong" in certain cases. |
| 20:27 |
|
exio4 joined #minetest-dev |
| 20:28 |
sapier |
well I can't change the fact that I can't travel back in time and fix the bug in current formspec positioning ... and if I fix it now it's gonna break existing things |
| 20:28 |
sapier |
you don't want existing things to be broken so I can't fix the bug ... quite simple |
| 20:28 |
hmmmm |
I suggest we break things and move forward |
| 20:28 |
hmmmm |
this next release is going to be quite a doozy so it's justified |
| 20:29 |
VanessaE |
hmmmm: break things in what way? so that every last mod that has some kind of formspec has to be rewritten and ends up incompatible with 0.4.11? |
| 20:29 |
VanessaE |
(and prior)_ |
| 20:29 |
hmmmm |
possibly |
| 20:29 |
hmmmm |
it depends on how difficult it is to do the rewriting |
| 20:29 |
hmmmm |
maybe we could do an automatic conversion or add a compatibility mode |
| 20:29 |
sapier |
hmmmmm I'm not gonna do this if there ain't a common agreement on it. I'm not gonna spend another week of develompent for trash |
| 20:29 |
hmmmm |
I definitely won't trash it |
| 20:30 |
|
n4x joined #minetest-dev |
| 20:30 |
hmmmm |
again... spacebar CPU heater |
| 20:30 |
hmmmm |
there's always going to be some people upset with changes |
| 20:30 |
russia_nekto |
devs, is there a predefined name of file for background texture for inventory menu ? |
| 20:30 |
hmmmm |
i don't know |
| 20:30 |
VanessaE |
this goes WAY beyond just breaking someone's workflow |
| 20:31 |
VanessaE |
russia_nekto: no, there isn't. |
| 20:31 |
sapier |
https://github.com/minetest/minetest/pull/1561 that's the prototype |
| 20:31 |
sapier |
most is already done yet ppl didn't want it |
| 20:31 |
VanessaE |
http://digitalaudioconcepts.com/vanessa/hobbies/minetest/screenshots/Screenshot%20-%2001062015%20-%2003%3a32%3a24%20PM.png |
| 20:31 |
VanessaE |
explain this, hmmmm |
| 20:31 |
VanessaE |
this is HEAD, right now. |
| 20:32 |
VanessaE |
before the font changes, that chat font you see behind the formspec just happens to be about the size that everything inside the formspec also was. |
| 20:33 |
sapier |
looks like an exact scale up of 800x600 formspec |
| 20:33 |
sapier |
no disorted font locations, nothing hidden |
| 20:33 |
VanessaE |
http://digitalaudioconcepts.com/vanessa/hobbies/minetest/screenshots/Screenshot%20-%2001062015%20-%2003%3a34%3a38%20PM.png |
| 20:33 |
sapier |
if modders don't want this they can tell a formspec to not to be scaled |
| 20:33 |
VanessaE |
how about this one then? |
| 20:34 |
sapier |
how is it gonna look like on 800x600? |
| 20:35 |
hmmmm |
christ |
| 20:35 |
hmmmm |
this is so FUBAR |
| 20:35 |
VanessaE |
before, the fonts would be correct at any reasonable window size. Now, they're just as broken at any window size. |
| 20:35 |
hmmmm |
erm |
| 20:35 |
sapier |
no the fonts havent been correct |
| 20:35 |
sapier |
the fonts have been SAME size |
| 20:35 |
VanessaE |
they were correct as in they didn't overflow their fields. |
| 20:35 |
sapier |
them beeing readable was by accident only |
| 20:35 |
sapier |
they haven't been readable on high dpi devices |
| 20:37 |
sapier |
btw any modder can make his formspecs use fixed size |
| 20:37 |
sapier |
then it's gonna stay exactly the way it was by now |
| 20:37 |
sapier |
with all positive and negative effects |
| 20:37 |
sapier |
hmm |
| 20:37 |
sapier |
if we did change the default to fixed sizes would this make everyone happy? |
| 20:38 |
VanessaE |
define "fixed size". |
| 20:38 |
sapier |
SAME as now |
| 20:38 |
VanessaE |
fixed to a certain pixel height, or fixed to a certain POINT size? |
| 20:38 |
sapier |
everything as broken as now |
| 20:38 |
VanessaE |
yeah, actually that probably would solve most of the issue |
| 20:39 |
VanessaE |
but you still need to change the calculations so that fonts are sized in points and based on DPI |
| 20:39 |
sapier |
hmm well no it'd not be same every formspec would look like now on 800x600 |
| 20:39 |
VanessaE |
otherwise this is just gonna happen again sooner or later. |
| 20:39 |
sapier |
exactly that way |
| 20:40 |
sapier |
screen dpi is independent if you believe this to change anything TRY it ... it's not gonna help |
| 20:41 |
VanessaE |
it's only independent if your calculations treat it wrongly. if you've got a 12-point font, it should display at precisely 4.233 mm high on any screen |
| 20:41 |
sapier |
screen_dpi is the config setting you have to change, default is 300 |
| 20:41 |
VanessaE |
regardless of DPI, but you have to know the screen DPI to calculate how tall to actually render the font |
| 20:42 |
VanessaE |
300? who the hell has a DPI that high except some retina screens? |
| 20:42 |
VanessaE |
that's laser printer resolution there |
| 20:44 |
sapier |
wait sorry my test value is 300 |
| 20:44 |
sapier |
set is 72 |
| 20:44 |
VanessaE |
well that's better :P ... 72's a tad low, most screens are closer to 100 |
| 20:44 |
russia_nekto |
devs, i have one idea. |
| 20:44 |
russia_nekto |
i think if u route your will to make some simple file structure for artists to allow them change minetest skin (main menu, inventory , hud and etc) what will rise players. because beuaty is why i play in games. |
| 20:44 |
russia_nekto |
as i digged today there is no fast technique to beuatify menus in minetest. |
| 20:44 |
russia_nekto |
so please, think of that. |
| 20:44 |
VanessaE |
but you get what I'm saying |
| 20:44 |
VanessaE |
russia_nekto: there's a mod for that. |
| 20:45 |
russia_nekto |
VanessaE: where to read about that mod? |
| 20:45 |
VanessaE |
russia_nekto: please check the minetest forums and take further questions there or to #minetest |
| 20:45 |
russia_nekto |
no help? |
| 20:45 |
VanessaE |
russia_nekto: this channel is for core development discussion, not general questions |
| 20:46 |
russia_nekto |
is it general? |
| 20:46 |
VanessaE |
#minetest is. |
| 20:46 |
VanessaE |
please go there. |
| 20:46 |
jin_xi |
VanessaE: does the entity detach crash happen on specific locations (any coordinate multiple of 200?) |
| 20:46 |
russia_nekto |
i mean my idea is general? |
| 20:47 |
VanessaE |
jin_xi: I wasn't able to determine it, since it was a production server I didn't really have much chance to try to reproduce it. |
| 20:47 |
VanessaE |
s/determine it/determine that/ |
| 20:48 |
VanessaE |
russia_nekto: yes. |
| 20:48 |
russia_nekto |
u thnk beuaty is not corre? |
| 20:49 |
VanessaE |
russia_nekto: this channel is for discussion of the engine code and the like. go to #minetest and ask your questions there, please |
| 20:53 |
sapier |
VanessaE https://gist.github.com/sapier/95e7c31c69419502977e |
| 20:54 |
sapier |
replace getDisplayDensity in porting.cpp by this version |
| 20:54 |
russia_nekto |
the beauty gives inspiration. gives players and again gives inspiration to do more and loop here. |
| 20:54 |
VanessaE |
sapier: the irony here is that if you set the default font scaling to fixed, then you could just as well set the main menu to auto-scale (with "fixed" turned on) to replicate the in-game behavior :P |
| 20:54 |
VanessaE |
ok, lemme try that |
| 20:54 |
russia_nekto |
VanessaE: you advice to ask in #minetest doesnt helps. |
| 20:55 |
sapier |
no because I won't change font scaling |
| 20:55 |
sapier |
only formspec scaling |
| 20:55 |
VanessaE |
sapier: I was kidding :P |
| 20:55 |
kilbith |
russia_nekto: we don't care, move away. |
| 20:55 |
|
Warr1024 joined #minetest-dev |
| 20:55 |
sapier |
hmm |
| 20:56 |
russia_nekto |
kilbith: sad really sad |
| 20:56 |
VanessaE |
sapier: trying that patch... |
| 20:56 |
VanessaE |
russia_nekto: your questions are of a general nature. this is not the place to ask them. |
| 20:56 |
sapier |
XCloseDisplay(x11display); |
| 20:56 |
sapier |
add this somewhere after the float lines |
| 20:56 |
sapier |
but prior return |
| 20:56 |
VanessaE |
sapier: ok, added. |
| 20:57 |
* VanessaE |
re-recompiles. |
| 20:57 |
sapier |
crap |
| 20:57 |
sapier |
doesn't work |
| 20:57 |
* VanessaE |
stops. |
| 20:58 |
sapier |
hmm wtf why does it work now |
| 20:58 |
sapier |
try it |
| 20:58 |
sapier |
and tell me your dpi error log should be flooded |
| 20:59 |
VanessaE |
ok, I'll try |
| 21:00 |
* VanessaE |
waits for compile script... |
| 21:01 |
VanessaE |
there we go.... |
| 21:01 |
VanessaE |
16:02:08: ERROR[main]: DPIH: 96 DPIW: 96 |
| 21:01 |
VanessaE |
[ 5.620] (II) fglrx(0): DPI set to (96, 96) |
| 21:01 |
VanessaE |
so that's a match |
| 21:01 |
sapier |
but it doesn't fix your issues does it? |
| 21:02 |
VanessaE |
well aside from the font being REALLY BIG now,... lemme turn the size down first |
| 21:03 |
VanessaE |
testing... |
| 21:04 |
VanessaE |
haha |
| 21:04 |
VanessaE |
Maximum number of clients reachedSegmentation fault (core dumped) |
| 21:05 |
VanessaE |
yep, it keeps dieing with that error when I try to start a world |
| 21:05 |
|
proller joined #minetest-dev |
| 21:05 |
VanessaE |
however, with the font size set to 15 in my config, it's approximately consistent with what I had before, but the formspec is larger on the 800x600 window than before |
| 21:05 |
VanessaE |
(larger even, than it was before your patch) |
| 21:06 |
VanessaE |
I mean the main menu. |
| 21:07 |
VanessaE |
specifically, the formspec is *wider*, but the height seems about the same. |
| 21:08 |
sapier |
does anyone know how to find out the correct screen number? hardcoding 0 doesn't work for multidisplay scenarios |
| 21:08 |
sapier |
stop messing around with font adjustment size |
| 21:09 |
sapier |
you cannot use it same way then before ... if you insist on messing around there I'm just gonna change the setting name to custom_font_size_adjustment |
| 21:09 |
sapier |
which is it's actual meaning by now |
| 21:10 |
|
VanessaE joined #minetest-dev |
| 21:10 |
VanessaE |
er......X didn't like that,. |
| 21:10 |
VanessaE |
that last run actually crashed it. had to REISUB. |
| 21:10 |
VanessaE |
what I was about to say was that in-game formspecs, while wider than they should be, had the correct font sizes now, consistent with the main menu. |
| 21:11 |
|
russia_nekto left #minetest-dev |
| 21:11 |
sapier |
Didn't we solve that issue a couple of days ago when I merged the patch I gave you weeks ago? |
| 21:12 |
VanessaE |
apparently not :) |
| 21:12 |
VanessaE |
I'd take a screenshot, but I expect it'll crash X again. |
| 21:12 |
sapier |
well it's not gonna work on mutlihead at all |
| 21:12 |
VanessaE |
I was also trying to say that I'm not able to see the world in the server I connected to, but I can see my HUD, inventory, and chat. |
| 21:13 |
sapier |
x11 doesn't provide per display information |
| 21:13 |
VanessaE |
ah lemme guess, your code picked up 3200x1200 then |
| 21:13 |
VanessaE |
(2* 1600x1200) |
| 21:13 |
sapier |
I don't even think the numbers are correct |
| 21:14 |
sapier |
no 5120x1080 |
| 21:15 |
VanessaE |
I mean from mine |
| 21:15 |
sapier |
according to x11 it's 1368x292 mm |
| 21:15 |
sapier |
most likely it did yes |
| 21:15 |
VanessaE |
[ 5.220] (II) fglrx(0): clock: 162.0 MHz Image Size: 367 x 275 mm |
| 21:16 |
VanessaE |
maybe because I don't use xinerama? |
| 21:16 |
sapier |
maybe |
| 21:16 |
sapier |
292 is right for first screen |
| 21:17 |
sapier |
maybe for second too but third is 320 and only 1024 pixels |
| 21:18 |
sapier |
it'd be nice to know what would be calculated on 1280x1024 as well as a 4k screen |
| 21:18 |
VanessaE |
looks like you can also read it from XRandR |
| 21:18 |
sapier |
so a fourth dpi source ;-) |
| 21:18 |
VanessaE |
heh |
| 21:19 |
VanessaE |
well I suppose that's available on Wayland and Mir also |
| 21:19 |
VanessaE |
hm, no... there's a tool for that |
| 21:19 |
VanessaE |
bleh |
| 21:19 |
sapier |
nice to know we've got 4 for linux ... not even started with windows osX ... hopefully bsd uses same as linx |
| 21:20 |
sapier |
+u |
| 21:21 |
VanessaE |
meanwhile since that test patch makes things...rather unstable, I'll remove it now |
| 21:24 |
ShadowNinja |
sapier: I found a bug. Type a long character like 'a' or 'M' into the password field, and compare to a short character like 'i' or 'j'. |
| 21:24 |
ShadowNinja |
A lot of them rather. |
| 21:24 |
sapier |
and? |
| 21:24 |
ShadowNinja |
Until it exceeds the field width. |
| 21:24 |
sapier |
what's gonna happen? |
| 21:24 |
ShadowNinja |
See what happens to the cursor, it's set wrong. |
| 21:25 |
sapier |
fix it ;-) |
| 21:25 |
sapier |
guess it's there for some time |
| 21:25 |
ShadowNinja |
sapier: I don't know how. |
| 21:26 |
ShadowNinja |
sapier: My guess is that it's calculating the offset for the text, but printing *s, which puts it off if it doesn't have the exact length of a *. |
| 21:26 |
ShadowNinja |
It doesn't work well for the name field either though -- it just doesn't adjust enough for any character. |
| 21:27 |
* ShadowNinja |
goes back to log reading... |
| 21:27 |
sapier |
but content of the password field is done by irrlicht itself I don't think we're doing something on our own? |
| 21:31 |
est31 |
ShadowNinja, did you get a ping when I amended my PR? |
| 21:35 |
ShadowNinja |
est31: Erm, what do you mean? |
| 21:35 |
est31 |
https://github.com/minetest/minetest/pull/2073 |
| 21:35 |
ShadowNinja |
sapier: Yes, it's likely an Irrlicht bug, unless it's related to FreeType. |
| 21:36 |
ShadowNinja |
est31: Oh, no. |
| 21:37 |
sapier |
well ShadowNinja irrlicht doesn't support freetype at all and our freetype to irrlicht code contains bugs |
| 21:37 |
sapier |
especially for font details like width height character distances (up/down left/right) |
| 21:37 |
sapier |
I tried to understand it but gave up as you need a lot of font specific knowledge I don't have |
| 21:40 |
ShadowNinja |
sapier: I didn't make issues because at the time the Android port wasn't merged. |
| 21:42 |
sapier |
it's in there about a quarter of a year ShadowNinja that's not a good excuse ;-) |
| 21:42 |
sapier |
but that's not really relevant can you check those issues which I couldn't verify? They might be fixed already |
| 21:45 |
sapier |
making hud scale independent from formspec is a minor change ShadowNinja do you have time to test? |
| 21:46 |
ShadowNinja |
sapier: I'll re-check soon, but I don't have a 0.4.11 build. |
| 21:46 |
sapier |
It's not gonna be 0.4.11 it's based uppon latest master |
| 21:47 |
sapier |
VanessaE I just merged the X11 dpi code ... case someone wants to provide same for windows ;-) |
| 21:47 |
VanessaE |
sapier: that commit works, but you should check how the HUD in dreambuilder behaves with it |
| 21:47 |
ShadowNinja |
sapier: I'm not sure what you mean. Does the size of the displayed formspec change the size of the hud elements? if so that's definitely broken. |
| 21:48 |
sapier |
VanessaE that doesn't matter, dpi detection is required if we wanna do it correct ... unless we wanna wait for irrlicht to implement it we have to take the ugly way of implementing it separate for each screen compositor |
| 21:49 |
sapier |
no |
| 21:49 |
VanessaE |
sapier: just saying, it throws off the HUD elements' positioning at small screen sizes |
| 21:49 |
sapier |
ShadowNinja: the gui_scaling factor affects both |
| 21:49 |
ShadowNinja |
sapier: Can you make a recent build for me? |
| 21:49 |
sapier |
but as I realized lately you have to change it to a quite low value to get working hud on at least some phones |
| 21:49 |
* VanessaE |
turns gui_scaling down from 1.0 to 0.8 and removes her font size settings |
| 21:49 |
sapier |
using that small value causes menu to be quite small |
| 21:50 |
sapier |
yes I'm gonna upload a recent apk for oyu |
| 21:50 |
VanessaE |
ok houston we have a problem |
| 21:51 |
sapier |
one? :-) |
| 21:51 |
VanessaE |
http://digitalaudioconcepts.com/vanessa/hobbies/minetest/screenshots/Screenshot%20-%2001062015%20-%2004%3a51%3a21%20PM.png |
| 21:51 |
VanessaE |
look at those two signs. |
| 21:51 |
sapier |
we've got a bunch of vanessaE |
| 21:51 |
VanessaE |
I'm pretty sure that's not what was fed to the GPU :P |
| 21:51 |
sapier |
what's wrong with them? |
| 21:52 |
VanessaE |
they are defined in the code and on disk with a wood texture. |
| 21:52 |
sapier |
and? |
| 21:52 |
VanessaE |
this is mesh corruption here |
| 21:52 |
sapier |
I don't see how this could be related to dpi calculation change ;-) |
| 21:52 |
hmmmm |
looks to me like a bug with the mod that creates those signs |
| 21:52 |
VanessaE |
hmmmm: it was fine earlier today. |
| 21:52 |
hmmmm |
=/ |
| 21:53 |
VanessaE |
I don't see how it could be related either but *shrug* |
| 21:53 |
* VanessaE |
restarts |
| 21:53 |
VanessaE |
(the client) |
| 21:53 |
VanessaE |
textures are fine on the second ruin |
| 21:53 |
VanessaE |
run* |
| 21:54 |
VanessaE |
that's the first time I've seen in-game corruption of textures on my system. I also note that the game's window decorations were also corrupted |
| 21:54 |
VanessaE |
on the first run |
| 21:55 |
sapier |
wtf |
| 21:55 |
sapier |
since when is android using xorg? |
| 21:55 |
VanessaE |
since never? I thought it had its own windowing system? |
| 21:56 |
sapier |
but it seems to set XORG_USED define |
| 21:56 |
hmmmm |
uh oh |
| 21:56 |
sapier |
wait |
| 21:56 |
VanessaE |
what? |
| 21:56 |
sapier |
my fault |
| 21:56 |
hmmmm |
phew |
| 21:57 |
sapier |
wrong ifndef cascade |
| 21:58 |
VanessaE |
hm, in-game graphics seem fine on subsequent runs. must be that roving memory corruption bug? |
| 21:59 |
VanessaE |
anyway with gui_scaling at 0.85 and no font size settings, the UIs and fonts are usable now. this is acceptable to me at least. :) |
| 22:00 |
VanessaE |
(will be moreso if you set the default to fixed) |
| 22:00 |
sapier |
well only 665 other users to satisfy |
| 22:00 |
VanessaE |
haha |
| 22:11 |
sapier |
didn't someone provide a file exchange server for minetest? |
| 22:12 |
VanessaE |
I think Krock runs something like that doesn't he? |
| 22:12 |
VanessaE |
(at least for skins) |
| 22:12 |
VanessaE |
(and mods) |
| 22:17 |
sapier |
http://www.fileconvoy.com/dfl.php?id=g897117ee8502eefc99960535676e62f7b46488772 ShadowNinja, link valid for about 2 days |
| 22:23 |
|
cib0 joined #minetest-dev |
| 22:27 |
sapier |
of course anyone else is free to test and give feedback too ;-) |
| 22:28 |
ShadowNinja |
sapier: The menu is scalled too small. Usable, but it't 7.5cm X 4cm. |
| 22:28 |
ShadowNinja |
scaled* |
| 22:28 |
sapier |
did you delete your minetest.conf before? |
| 22:29 |
sapier |
it may have the old setting there |
| 22:29 |
ShadowNinja |
Nope... |
| 22:29 |
sapier |
please try again |
| 22:30 |
ShadowNinja |
sapier: Still a bit small, but better. 9cm X 4.5cm. |
| 22:32 |
ShadowNinja |
sapier: pitch limiting is fixed... |
| 22:32 |
sapier |
ok you should be able to do finetuning by changeing the gui_scaling in settings |
| 22:32 |
ShadowNinja |
Jumping too. |
| 22:32 |
sapier |
ok I'm closing those issues |
| 22:33 |
ShadowNinja |
And chat closing... |
| 22:33 |
sapier |
well that's most likely still there, as chat is a regular formspec right now there's no reasonable fix |
| 22:36 |
ShadowNinja |
sapier: Aaaand SIGABRT. |
| 22:36 |
|
acerspyro joined #minetest-dev |
| 22:36 |
ShadowNinja |
In ConnectionReceiveThread. |
| 22:36 |
sapier |
hmm do you have more information? out of memory? |
| 22:37 |
sapier |
can you post the full error log? |
| 22:37 |
ShadowNinja |
Yep, one minute. |
| 22:42 |
ShadowNinja |
PMd. |
| 22:43 |
acerspyro |
ShadowNinja: Did you really send him the full log via PM, line by line? |
| 22:45 |
sapier |
nope he sent me a link ;-) |
| 22:45 |
ShadowNinja |
acerspyro: No, of course not. It's like 200 lines. |
| 22:45 |
acerspyro |
lol ok phew |
| 22:47 |
|
kaeza joined #minetest-dev |
| 22:48 |
|
prozacgod joined #minetest-dev |
| 22:48 |
ShadowNinja |
sapier: You can remove the "Fly mode" checkbox from the main menu now, since there's an in-game button. |
| 22:49 |
sapier |
true but those buttons are quite ugly my display isn't even big enough to show all of them |
| 22:49 |
sapier |
resulting in multiple buttons beeing drawn on top of each other |
| 22:49 |
acerspyro |
There's an in-game button? Since? |
| 22:50 |
|
FR^2 joined #minetest-dev |
| 22:50 |
sapier |
I don't know but it's not a well tested final solution ... I'd suggest providing a settings menu |
| 22:50 |
kilbith |
sapier: can you test the PR 2054 on android for me please ? i can't actually |
| 22:50 |
sapier |
I don't think those settings are changed each minute |
| 22:50 |
ShadowNinja |
acerspyro: https://github.com/minetest/minetest/commit/62feade05da387cd6b230e7a0edf558c6fd7c099 |
| 22:50 |
sapier |
#2ß54 |
| 22:50 |
sapier |
#2054 |
| 22:50 |
ShadowBot |
https://github.com/minetest/minetest/issues/2054 -- Reorganizing client and settings tabs by kilbith2 |
| 22:51 |
acerspyro |
Oh, android? |
| 22:53 |
sapier |
And buttons not required for gameplay shouldn't be on main screen |
| 22:54 |
sapier |
#2054 breaks settings tab on android |
| 22:54 |
ShadowBot |
https://github.com/minetest/minetest/issues/2054 -- Reorganizing client and settings tabs by kilbith2 |
| 22:55 |
sapier |
but looks like it could be fixed |
| 22:55 |
sapier |
you'll have to move tha andoid specific settings block below the middle column |
| 22:55 |
kilbith |
hmm. |
| 22:56 |
acerspyro |
Scroll bars are a thing |
| 22:56 |
sapier |
right now it's overlapping |
| 22:56 |
sapier |
no scrollbars without containers and formspec doesn't support those |
| 22:56 |
kilbith |
i'd like a screenie |
| 22:57 |
kilbith |
or just fix that in my PR, sapier |
| 22:57 |
kilbith |
if it's painless enough |
| 22:58 |
sapier |
http://imgur.com/L34g1yl |
| 22:59 |
kilbith |
oh yes, i'll move that further downward |
| 22:59 |
sapier |
btw as you're optimizing the settings menu, could you make anisotropic bi/trilinear filtering a drop down? ;-) |
| 23:00 |
kilbith |
yes |
| 23:00 |
VanessaE |
no |
| 23:00 |
sapier |
a little bit to the left too ;-) |
| 23:00 |
VanessaE |
aniso is not mutually exclusive with bi/tri |
| 23:01 |
sapier |
are you sure? |
| 23:01 |
VanessaE |
the latter two can be in a drop-down, but don't put aniso in with them. |
| 23:01 |
VanessaE |
I am positive. |
| 23:01 |
sapier |
ok if you tell this it's most likely rigth as I wasn't sure about it |
| 23:01 |
VanessaE |
aniso defines the filtering applied over a mipmap, bi/tri is an after-effect, or at least that's how it's supposed to work |
| 23:01 |
VanessaE |
some drivers are busted though |
| 23:01 |
sapier |
so it's no-filtering/bi-linearfiltering/tri-linear filtering |
| 23:01 |
VanessaE |
yes |
| 23:02 |
VanessaE |
now for the other part, you can put them into a dropdown also: none -> mipmap only -> mipmap + aniso |
| 23:02 |
VanessaE |
(you'll never use aniso without mipmap) |
| 23:03 |
sapier |
no-mipmapping please |
| 23:04 |
sapier |
unless you want to add a description line too ;-) |
| 23:04 |
kilbith |
2 dropdowns then ? |
| 23:04 |
sapier |
yes one no-mipmap/mipmap/mipmap + aniso |
| 23:04 |
sapier |
the other one |
| 23:04 |
sapier |
no filtering/bi-linear filtering/tri-linear filtering |
| 23:05 |
kilbith |
noted |
| 23:05 |
sapier |
wait "no mipmap" of course |
| 23:05 |
sapier |
space instead of - |
| 23:08 |
|
zat joined #minetest-dev |
| 23:14 |
sapier |
https://github.com/minetest/minetest/pull/2074 the hud gui scaling split |
| 23:15 |
VanessaE |
from a quick check, lgtm |
| 23:15 |
VanessaE |
but I didn't test :P |
| 23:17 |
|
y joined #minetest-dev |
| 23:17 |
* VanessaE |
tests. |
| 23:18 |
VanessaE |
yep, works for me |
| 23:24 |
|
loggingbot_ joined #minetest-dev |
| 23:24 |
|
Topic for #minetest-dev is now Minetest core development and maintenance. Chit-chat goes to #minetest. Consider this instead of /msg celeron55. http://irc.minetest.ru/minetest-dev/ http://dev.minetest.net/ |
| 23:32 |
|
EvergreenTree joined #minetest-dev |
| 23:53 |
VanessaE |
it seems direct3d8/direct3d9 are not showing up for some people as a video driver option, while opengl et al. are. |
| 23:53 |
VanessaE |
on Windows that is |
| 23:56 |
sapier |
well someone wanted them to be hidden I guess there's a bug |
| 23:56 |
sapier |
for what I remember the list is provided by irrlicht |
| 23:57 |
|
Sokomine joined #minetest-dev |
| 23:57 |
kilbith |
i *hate* the new font rendering, the menu is totally fucked up with the french words |
| 23:58 |
sapier |
yes the full driver list is checked against irrlicht support if irrlicht tells NO we don't show it |
| 23:58 |
kilbith |
s/rendering/scaling |
| 23:58 |
acerspyro |
kilbith: how so |
| 23:58 |
sapier |
kilbith: screenshots please, did you remove manual font adjustments from your config file? |
| 23:59 |
sapier |
do you use a custom font? |
