Time |
Nick |
Message |
00:03 |
ShadowNinja |
PilzAdam: How about "LGPL-2.1+ and CC-BY-SA-3.0 and MIT and Apache-2.0". That's in rough order of significance (Core, core textures, library code, fonts). |
00:03 |
ShadowNinja |
I don't know if this field is processed though, if not I'd use commas and less "and"s. |
00:04 |
PilzAdam |
replace the first 2 "and"s with , |
00:04 |
PilzAdam |
and what about the <updatecontact> field? |
00:08 |
|
CraigyDavi joined #minetest-dev |
00:32 |
ShadowNinja |
[project_license] is not valid: SPDX ID 'LGPL-2.1+, CC-BY-SA-3.0, MIT' unknown |
00:32 |
ShadowNinja |
^ Seems the ands are needed. |
00:34 |
ShadowNinja |
I've made these changes: http://sprunge.us/fNeB?diff |
00:37 |
|
LemonLake joined #minetest-dev |
00:38 |
VanessaE |
ShadowNinja: we need to stop calling it "infinite-world" since it's hardly so... |
00:38 |
ShadowNinja |
VanessaE: I changed it to near-infinite. |
00:38 |
VanessaE |
that works, |
00:38 |
VanessaE |
I was about to suggest that. |
00:39 |
VanessaE |
that reminds me, did nore's super-huge-worlds patch ever get past that last bug? |
00:40 |
ShadowNinja |
!seenany nore |
00:40 |
ShadowBot |
ShadowNinja: I saw nore in #minetest-dev 6 hours, 2 minutes, and 28 seconds ago quiting (Ping timeout: 265 seconds) |
00:41 |
ShadowNinja |
Hmmm, haven't seen much of him recently, but seems like he's been around. |
00:41 |
VanessaE |
he has, yes |
00:41 |
VanessaE |
said he's not had much time for coding though |
00:41 |
ShadowNinja |
I never heard that he fixed it though. |
00:53 |
RealBadAngel |
VanessaE, ShadowNinja he left (pinged out) just when i asked him about microblocks |
00:54 |
RealBadAngel |
and thats suspicious |
00:54 |
VanessaE |
naw |
00:54 |
VanessaE |
RealBadAngel: ---> bug report #minetest-technic |
00:54 |
RealBadAngel |
comin |
00:54 |
VanessaE |
he probably was afk anyways |
00:54 |
RealBadAngel |
i know |
00:55 |
VanessaE |
the ping out was probably like with minetest. you highlighted him, causing his client to finally try to respond, but it ain't there so ping timeout :) |
01:40 |
|
zat joined #minetest-dev |
02:07 |
ShadowNinja |
~tell sapier I can't exit the key change menu on your latest Android build. |
02:07 |
ShadowBot |
ShadowNinja: O.K. |
02:11 |
RealBadAngel |
~tell sapier why esc doesnt work as formspec exit? |
02:11 |
ShadowBot |
RealBadAngel: O.K. |
02:15 |
ShadowNinja |
Inventory cubes render properly now, but not for the right item, eg mese renders as lava, and they're upside-down. |
02:27 |
|
proller joined #minetest-dev |
02:32 |
RealBadAngel |
they dont render properly in all cases |
02:33 |
RealBadAngel |
ive seen many items made out out random data noise |
02:34 |
RealBadAngel |
some of them also on black background |
02:34 |
RealBadAngel |
and most of them upside down |
02:34 |
VanessaE |
last build I tried many of the inventory cubes just rendered as a simple, white square |
02:35 |
VanessaE |
prior to that, when they did render, they were inverted |
02:35 |
VanessaE |
rendered properly, but inverted and on some sort of solid color background (similar to RBA) |
02:35 |
RealBadAngel |
i have to make it all same way as wielded |
02:36 |
RealBadAngel |
rendered by engine, not us |
02:36 |
RealBadAngel |
it seems we cannot handle correctly all the cases |
02:37 |
RealBadAngel |
and we will get rid of that fuckin preload item visuals once and for all |
02:37 |
VanessaE |
get rid of it and use the G*d damned in-world actual objects. |
02:38 |
VanessaE |
what reason is there to render to texture at all anyway? |
02:38 |
RealBadAngel |
next to none |
02:39 |
RealBadAngel |
and i want selected item to spin :) |
02:39 |
RealBadAngel |
that will be cool |
02:39 |
VanessaE |
what will you do with objects that provide a wield/inventory image? :) |
02:40 |
RealBadAngel |
pass them to extrude |
02:41 |
VanessaE |
ew. |
02:41 |
VanessaE |
the same extrude routine I disable on my client because it's so slow when using an HD texture pack |
02:41 |
RealBadAngel |
it has to be fixed |
02:42 |
* VanessaE |
pokes kahrl |
02:42 |
RealBadAngel |
or moved outta engine |
02:42 |
VanessaE |
I don't know that it can be; disabling it altogether should be offered in the menu or .conf |
02:42 |
RealBadAngel |
which could be even better |
02:42 |
VanessaE |
out of the engine and into what? |
02:42 |
VanessaE |
can't do it in a shader, not everyone has them |
02:42 |
RealBadAngel |
script? |
02:43 |
VanessaE |
eh? |
02:43 |
VanessaE |
you're not suggesting pre-caching them |
02:43 |
RealBadAngel |
pre making them |
02:43 |
VanessaE |
well actually, |
02:43 |
VanessaE |
that's not such a bad idea really |
02:43 |
VanessaE |
*can* they be cached? |
02:43 |
VanessaE |
generate them once, load the generated results next time around instead of re-doing them every damn time |
02:44 |
* VanessaE |
wonders how big HDX's "mushroom spores" item image (512px) would be as a mesh :P |
02:44 |
VanessaE |
that one is far and away the WORST ever image I've passed to the extrude routine |
02:45 |
VanessaE |
https://github.com/VanessaE/hdx-512/blob/master/mushroom_spore.png |
02:45 |
VanessaE |
this. |
02:45 |
VanessaE |
go ahead. I triple-dog-dare you to let Minetest try to extrude that. |
02:59 |
|
Exio4 joined #minetest-dev |
03:46 |
|
kahrl joined #minetest-dev |
03:46 |
|
dulrich joined #minetest-dev |
03:46 |
|
deltib joined #minetest-dev |
03:47 |
|
Exio4 joined #minetest-dev |
03:53 |
|
dulrich_ joined #minetest-dev |
04:12 |
|
Miner_48er joined #minetest-dev |
05:58 |
|
Hunterz joined #minetest-dev |
06:18 |
|
darkrose joined #minetest-dev |
07:21 |
|
CheapSeth joined #minetest-dev |
07:40 |
|
whiskers75 joined #minetest-dev |
07:46 |
|
Fresh_m__ joined #minetest-dev |
07:50 |
|
tomreyn joined #minetest-dev |
08:49 |
|
LemonLake joined #minetest-dev |
09:35 |
|
sapier joined #minetest-dev |
09:37 |
sapier |
~tell RealBadAngel Ahh the key change menu ... I almost forgot about it ... yea thats an open issue as key events don't reach it correct. Same for escape and menus, it's lost somewhere within stack or doesn't even exist for most android devices. |
09:37 |
ShadowBot |
sapier: O.K. |
09:54 |
|
restcoser joined #minetest-dev |
10:14 |
|
vifino joined #minetest-dev |
10:20 |
|
PenguinDad joined #minetest-dev |
10:45 |
|
ImQ009 joined #minetest-dev |
10:59 |
|
grrk-bzzt joined #minetest-dev |
11:01 |
|
PilzAdam joined #minetest-dev |
11:08 |
|
Jordach joined #minetest-dev |
11:17 |
|
kahrl joined #minetest-dev |
11:40 |
|
NakedFury joined #minetest-dev |
11:46 |
|
kaeza joined #minetest-dev |
11:58 |
|
grrk-bzzt joined #minetest-dev |
12:31 |
|
iqualfragile joined #minetest-dev |
12:34 |
|
Zeitgeist_ joined #minetest-dev |
12:46 |
|
Gethiox joined #minetest-dev |
13:15 |
|
nore joined #minetest-dev |
13:38 |
|
Exio4 joined #minetest-dev |
13:54 |
|
werwerwer_ joined #minetest-dev |
14:14 |
|
proller joined #minetest-dev |
14:15 |
|
Megaf joined #minetest-dev |
14:25 |
|
hmmmm joined #minetest-dev |
14:27 |
Megaf |
#1345 |
14:27 |
ShadowBot |
https://github.com/minetest/minetest/issues/1345 -- Lua feature to hide player nametags |
14:27 |
LemonLake |
thanks megaf |
14:28 |
Megaf |
;) |
14:28 |
LemonLake |
Yeah, can you give me your opinion on that please? |
14:29 |
Exio4 |
lots of opinions, noone is coding it though |
14:31 |
Megaf |
Now, let's see whos faster to compile minetest server. 4 ARMv7 core at 2,1 GHz running make -j 4 or One AMD Athlon XP 2800+ at 2067MHz running make -j 1 |
14:34 |
|
grrk-bzzt joined #minetest-dev |
14:39 |
|
Piggybear87 joined #minetest-dev |
15:08 |
|
kaeza joined #minetest-dev |
15:09 |
|
SEx2 joined #minetest-dev |
15:09 |
|
kaeza joined #minetest-dev |
15:12 |
|
kaeza joined #minetest-dev |
15:16 |
|
ImQ009 joined #minetest-dev |
15:23 |
|
SoniEx2 joined #minetest-dev |
15:32 |
|
Megaf_ joined #minetest-dev |
15:42 |
|
sapier joined #minetest-dev |
15:43 |
sapier |
megaf, I'd expect the athlon xp to be faster, what's the real result? |
15:44 |
|
MichaelRpdx joined #minetest-dev |
15:45 |
Megaf |
sapier; Athlon XP http://paste.debian.net/102693/ |
15:45 |
Megaf |
sapier; ODroid U3 http://paste.debian.net/102694/ |
15:45 |
Megaf |
sapier; when running 4 jobs at once ARM is really faster |
15:46 |
Megaf |
but with a single job, Athlon is waaay faster |
15:46 |
sapier |
that's interesting, I'd expected arm to be slower even on 4 core ... guess I need to rethink a little bit |
15:46 |
Megaf |
So, minetest, at the moment, runs better on freaking old and energy not eficient hardware that on new and energy efficient hardware |
15:46 |
sapier |
wait it's a xp 1800 so 1.5ghz? |
15:47 |
Megaf |
now, ARM will use 5 Watts and Athlon close to 150 Watts |
15:47 |
Megaf |
sapier; 2800+ |
15:47 |
sapier |
the difference is arm is risc while athlon is xisc |
15:47 |
Megaf |
2083 MHz |
15:47 |
sapier |
cisc |
15:47 |
sapier |
ok so almost same frequency |
15:47 |
Megaf |
sapier; actually, all x86 CPUs are RISC internaly |
15:47 |
Megaf |
they have a translation layer |
15:48 |
sapier |
no they aren't |
15:48 |
sapier |
transmeta tried that once ... with little success |
15:49 |
Megaf |
sapier; so, can you see how faster and more efficient minetest server would be if it hada modern design? |
15:49 |
sapier |
of course modern cpu's have parts beeing similar to risc and cisc architecture in their design but still x86 cpu's are optimized for cisc command set |
15:49 |
Megaf |
it could run faster burning 90% less energy |
15:50 |
sapier |
optimizing minetest towards more parallelism will take a lot of time ... it wont be done tomorrow |
15:51 |
Megaf |
It should be done from the bery begining |
15:51 |
Megaf |
very* |
15:51 |
sapier |
while this is our overall direction don't expect it to happen within a year |
15:51 |
Megaf |
That's my poing |
15:51 |
Megaf |
the time it will take to change, it shorter than the time it will take to start from scrach |
15:52 |
sapier |
Almost all projects I saw that started from the beginning did to exactly same mistakes that have been done before |
15:53 |
sapier |
if you start from the beginning you'll be where minetest is now in about two years |
15:53 |
sapier |
but minetest will have evolved for 2 years, so you're competing to that future minetest version by the time |
15:56 |
|
Calinou joined #minetest-dev |
15:58 |
sapier |
but megaf, arm devices ARE limited, that's why "cloud" services are advertised that loud nowadays |
15:58 |
sapier |
all things that require cpu power are done in cloud ... where those energy hungry but fast x86 cpu's are most common |
16:01 |
Megaf |
they are limited yes, but they have some pretty neat extensions too |
16:01 |
Megaf |
things that x86 need lots of cycles and software to do, ARM do in a single cycle, via hardware |
16:01 |
sapier |
extensions not usefull if you're just doing generic control flow |
16:02 |
sapier |
usually it's the other way round cisc is doing things in one step while risc requires several |
16:02 |
sapier |
and x86 processors have extended api features today too |
16:03 |
Megaf |
RISC can do several little things faster than CISC |
16:03 |
Megaf |
heh |
16:03 |
Megaf |
but CISC do a huge thing faster than RISC |
16:03 |
sapier |
I'd not sign that as a general statement |
16:04 |
Megaf |
anyway, the compiler should do a better job too |
16:04 |
sapier |
yes if minetest was compiled for intel using icc it'd most likely run way faster |
16:05 |
sapier |
and of course there might be a lot of suboptimal algorithms in too |
16:05 |
Megaf |
I wonder what the best compiler and compiling options for ARM would be |
16:06 |
sapier |
arm recently switched to llvm as default compiler so maybe latest version of clang might be optimal |
16:06 |
sapier |
that's a difference to gcc on x86 too ... intel doesn't really improve gcc for their architecture |
16:07 |
sfan5 |
I just read a small part of the conversation... But have we come to blaming the compiler for Minetest's slowness now? |
16:08 |
sapier |
no |
16:08 |
|
Calinou_ joined #minetest-dev |
16:09 |
sapier |
we're just talking about the influence of compiler on comparing arm to x86 |
16:09 |
sapier |
of course comparing those is quite difficult |
16:15 |
hmmmm |
not only that, but how do you know how agressive and time-consuming the optimizations for each architecture are |
16:16 |
hmmmm |
so i wouldn't say they're comparable unless you're cross compiling to the same architecture |
16:17 |
sapier |
true using compile time of minetest to benchmark the architecture is even less telling |
16:39 |
|
proller joined #minetest-dev |
16:39 |
|
Exio4 joined #minetest-dev |
16:51 |
|
zat joined #minetest-dev |
16:52 |
Exio4 |
that is what i told him |
17:34 |
sapier |
great we need to update all png files |
17:35 |
sapier |
"PNG warning: iCCP: Not recognizing known sRGB profile that has been edited" is the message shown on recent libpng implementations |
17:36 |
VanessaE |
PNGcrush them while you're at it |
17:37 |
VanessaE |
(or optipng or whatever your favorite shrink tool is) |
17:37 |
sapier |
well I wont do that right now but it's something to put on todo list |
17:38 |
sapier |
I'm looking for the reason why inventory items are still broken ... having wrong textures shown may be a hint about some memory handling issues |
17:39 |
sapier |
I found a few error cases that aren't handled properly within minetest, but none of those cases have been this problem |
17:44 |
|
kaeza joined #minetest-dev |
18:06 |
|
Garmine joined #minetest-dev |
18:40 |
|
grrk-bzzt joined #minetest-dev |
18:47 |
|
Piggybear87 joined #minetest-dev |
18:55 |
|
Calinou joined #minetest-dev |
19:04 |
|
diemartin joined #minetest-dev |
19:06 |
|
grrk-bzzt joined #minetest-dev |
19:13 |
sapier |
Thats crazy android emulator claims to support GL_BGRA textures but actually doesn't ... resulting in broken textures ... I wonder if those broken textures some ppl experience are same issue |
19:13 |
sapier |
hmm most likely not as on emulator there's no texture at all |
19:27 |
|
proller joined #minetest-dev |
19:43 |
VanessaE |
G*d damn will someone PLEASE FIX THE FUCKING WATER OPACITY? |
19:43 |
VanessaE |
(where it randomly switches between opaque and translucent for no discernible reason) |
19:44 |
|
Gethiox joined #minetest-dev |
19:45 |
sapier |
*g* I haven't even seen that one yet |
19:48 |
sapier |
VanessaE you do have that inventory item bug do you? |
19:48 |
VanessaE |
sapier: yeah, with that May 18 build at least |
19:49 |
VanessaE |
prior to that one when you still called it Minetest-Debug.apk, it was fine |
19:50 |
|
proller joined #minetest-dev |
19:50 |
sapier |
may 18? that's quite old :-) but I havent done anything supposed to fix it till today. I'm compiling right now. It's actually a fix for emulator not showing correct textures. but error message was same you have |
19:51 |
VanessaE |
I haven't seen a new build link from you since then |
19:51 |
VanessaE |
you don't exactly public a forum page with your builds : |
19:51 |
VanessaE |
:P |
19:51 |
VanessaE |
publish* |
19:52 |
VanessaE |
I gotta run, bbl |
19:52 |
sapier |
https://forum.minetest.net/viewtopic.php?f=3&t=9389 |
19:52 |
VanessaE |
oh, so you DO publish one :P |
19:52 |
VanessaE |
fine, *bookmarked* |
19:52 |
VanessaE |
bbl now :) |
20:06 |
|
RealBadAngel joined #minetest-dev |
20:29 |
sapier |
if there aren't additional comments I'm gonna merge 1332 in a few minutes |
20:45 |
RealBadAngel |
#1332 |
20:45 |
ShadowBot |
https://github.com/minetest/minetest/issues/1332 -- Small cleanup of hud add/remove code by sapier |
20:46 |
RealBadAngel |
^^ created clickable link to read it ;) |
20:46 |
RealBadAngel |
im ok with it |
20:51 |
PilzAdam |
https://github.com/minetest/minetest/commit/18fe277d949a82fcc6fbc47c734df514d3ea1f52 |
20:51 |
PilzAdam |
there was a reason why the items didn't have "wielditem" visuals before |
20:52 |
sapier |
:-) if you tell the reason we others would know it too ;-) |
20:52 |
sapier |
pushing 1332 now |
20:52 |
PilzAdam |
inventory_image is supposed to override the texture of dropped items |
20:52 |
sapier |
maybe we should fix it and add a comment telling this |
20:53 |
PilzAdam |
also why did RealBadAngel change the size of the items? |
20:54 |
sapier |
don't items now "grow" if they're more? |
20:54 |
RealBadAngel |
PilzAdam, item entity size now represents size of a stack |
20:54 |
PilzAdam |
thats stupid |
20:54 |
RealBadAngel |
no its not |
20:54 |
PilzAdam |
do you use the bows and arrows mod? |
20:55 |
RealBadAngel |
no i dont |
20:55 |
RealBadAngel |
its badly coded |
20:56 |
RealBadAngel |
and i asked you many times about your opinion but lately you have chosen not to respond at all |
20:56 |
RealBadAngel |
so please do not comment with something like that |
20:56 |
PilzAdam |
you asked for my opinion and don't want to hear it now? |
20:57 |
RealBadAngel |
now? i keep asking weeks ago |
20:57 |
RealBadAngel |
but ok, go on |
20:57 |
sapier |
comments on #1302 |
20:57 |
ShadowBot |
https://github.com/minetest/minetest/issues/1302 -- Add daemon support for linux like operating systems by sapier |
20:58 |
PilzAdam |
your way of stacking items on the ground only works for nodes |
20:58 |
sapier |
what's missing? |
20:59 |
sapier |
I don't want mobs to automerge ... just to be sure ;-) |
20:59 |
PilzAdam |
2 torches don't merge together into one big |
20:59 |
sapier |
well they shouldn't |
20:59 |
sapier |
at least not if they're placed |
21:01 |
RealBadAngel |
PilzAdam, they cant merge because of max items per stack |
21:01 |
RealBadAngel |
if max = 1 they simply cant |
21:01 |
PilzAdam |
stack_max of torches is 99 |
21:02 |
RealBadAngel |
ouch |
21:02 |
RealBadAngel |
lemme check it out |
21:03 |
RealBadAngel |
they do merge |
21:04 |
RealBadAngel |
and grow the size |
21:04 |
PilzAdam |
thats the problem |
21:04 |
RealBadAngel |
please explain |
21:05 |
PilzAdam |
merging items doesn't make sense for items that aren't nodes |
21:06 |
RealBadAngel |
we are not talking nodes here but item entities |
21:07 |
PilzAdam |
if you throws 2 sticks together IRL they don't merge into one big stick |
21:07 |
PilzAdam |
do you know how minecraft handles the merging of dropped items? |
21:08 |
RealBadAngel |
i dont care bout mc |
21:08 |
PilzAdam |
they display the amount of items in the stack visually, but limit it to something like 4 or so |
21:08 |
PilzAdam |
it's way more intuitive and realistic |
21:09 |
RealBadAngel |
since when IRL mergeing is limited to 4? |
21:09 |
RealBadAngel |
have i missed some EU paper on that? |
21:09 |
PilzAdam |
the visual representation is limited to 4 |
21:10 |
PilzAdam |
I don't have anything against the merging itself, just the visual representation you chose is bad |
21:10 |
RealBadAngel |
by now visual size can range from 0.15 -> minimal size of an item |
21:10 |
RealBadAngel |
to 0.3 - maximum size |
21:11 |
RealBadAngel |
if it is a full stack (max_count) then size = 0.3 |
21:11 |
RealBadAngel |
there are no steps (like that 4 from mc) |
21:12 |
RealBadAngel |
stack of 5 will be slightly bigger than of 4 |
21:13 |
PilzAdam |
I'm not sure if you understood what I said |
21:20 |
RealBadAngel |
you said that possible sizes are 4 |
21:21 |
RealBadAngel |
at least i get it that way |
21:22 |
PilzAdam |
then you got it wrong |
21:23 |
PilzAdam |
when there are more than 1 item in the item_entity stack, it should display several items, and not a big one |
21:27 |
RealBadAngel |
how? |
21:28 |
RealBadAngel |
a few items spinning at same pos? we had that before |
21:28 |
RealBadAngel |
and THAT was wrong |
21:34 |
PilzAdam |
http://hydra-media.cursecdn.com/minecraft.gamepedia.com/6/6f/Item_entities.png?version=b9efd484f545042faed5f251511e8d05 |
21:34 |
PilzAdam |
see the sand and torches |
21:35 |
RealBadAngel |
hmmm |
21:36 |
RealBadAngel |
thats a good idea, but slightly different way |
21:36 |
RealBadAngel |
if theres more than one stack make them offset |
21:37 |
RealBadAngel |
i will code that |
21:37 |
RealBadAngel |
that will eliminate flickering |
21:37 |
RealBadAngel |
thx for the idea |
21:37 |
PilzAdam |
also don't use the "wielditem" visual; it doesn't respect the inventory_image |
21:38 |
PilzAdam |
either use the old way of displaying items with an inventory_image, or code a new visual similar to "wielditem" that uses inventory_image |
21:40 |
RealBadAngel |
thats gonna change, i will change it to use real time rendering of the item/node |
21:40 |
RealBadAngel |
for all the elements |
21:41 |
RealBadAngel |
so inventory_image will become obsolete |
21:41 |
RealBadAngel |
for that extrude routine have to improved in the first place |
21:42 |
PilzAdam |
no, inventory_image is supposed to define the texture of the item, in all it representations |
21:42 |
PilzAdam |
don't break the API |
21:42 |
RealBadAngel |
thats unaceptable that node/item looks different way wielded/placed |
21:42 |
RealBadAngel |
shaders have to be applied |
21:43 |
RealBadAngel |
it have to be rendered |
21:43 |
RealBadAngel |
and not in faulty code like preload item visuals |
21:44 |
RealBadAngel |
engine is capable of doing that without any problem |
21:44 |
RealBadAngel |
problem was just our implementation |
21:45 |
PilzAdam |
don't break the API |
21:45 |
RealBadAngel |
it will be broken sooner or later |
21:45 |
RealBadAngel |
and it wont be me to break it |
21:45 |
RealBadAngel |
so dont worry |
21:46 |
RealBadAngel |
im a modder too, i can take care of my own business |
21:47 |
RealBadAngel |
in fact all the engine changes i do, i do for modding |
21:48 |
PilzAdam |
not using inventory_image is breaking the API |
21:48 |
PilzAdam |
you already broke it |
21:48 |
RealBadAngel |
yup |
21:48 |
RealBadAngel |
it is using wielded |
21:48 |
RealBadAngel |
real 3d objects |
21:49 |
sapier |
could we stop accusing ppl and just fix the issue it doesn't seem to be a big one |
21:49 |
RealBadAngel |
so no more sprites staring at you in a magical way |
21:50 |
RealBadAngel |
which was imho one of biggest mt fails all the time |
21:50 |
sapier |
btw RealBadAngel shaders are actively disabled for inventory items, if you want them to look same as nodes the fix would be minor |
21:50 |
PilzAdam |
sapier, just reverting RealBadAngel's commit without explaining why isn't good either |
21:50 |
sapier |
for what I read about the discussion that wielditem thingy is just a small part of it ... am I wrong about that? |
21:51 |
RealBadAngel |
sapier, shaders will apply to everything, but not yet |
21:51 |
RealBadAngel |
code is not ready for it |
21:51 |
sapier |
and the multiple entities instead of one is better then what rba implemented too yes, but what was added is still better then it was before (at least in my oppinion) |
21:52 |
RealBadAngel |
multiple entities can refer to many stacks at same pos |
21:52 |
RealBadAngel |
which should be offseted to avoid rendering textures at same coords |
21:52 |
sapier |
I meant display as multiple entities not really multiple entities |
21:53 |
RealBadAngel |
make a poll about it |
21:54 |
RealBadAngel |
2 or 3 votes are not enough to decide whats best |
21:54 |
RealBadAngel |
especially if 1 is pro, 2nd con and 3rd not decided |
21:54 |
RealBadAngel |
;) |
21:55 |
sapier |
I'm pushing #1302 in a few minutes |
21:55 |
ShadowBot |
https://github.com/minetest/minetest/issues/1302 -- Add daemon support for linux like operating systems by sapier |
22:05 |
|
ImQ009 joined #minetest-dev |
22:11 |
RealBadAngel |
so, PilzAdam, the conclusion, if you want the items to behave different way, just ask ppl about it |
22:24 |
|
vifino joined #minetest-dev |
22:24 |
|
vifino joined #minetest-dev |
22:27 |
hmmmm |
hmmm |
22:28 |
hmmmm |
closing stderr and stdout will make any attempts to write to them fail which might cause bugs |
22:28 |
hmmmm |
why wouldn't you redirect them to /dev/null instead? what about stdin? |
22:29 |
hmmmm |
why not just use daemon()? |
22:29 |
hmmmm |
man 3 daemon |
22:30 |
sapier |
*smile* you're about 4 minutes to late but O'll check if those things really cause issues |
22:30 |
hmmmm |
at the very least, you should s/fclose(stdout);/freopen("/dev/null", "w", stdout); |
22:30 |
sapier |
while this is not supposed to happen I'll still write the fix for it |
22:31 |
hmmmm |
although |
22:32 |
hmmmm |
/dev/null is common on unix-like systems, it's not a part of the POSIX standard |
22:32 |
sapier |
seems like daemon would already do everything for us |
22:32 |
sapier |
I'll just change it to use that function ... couldn't you have mentioned that one the last weeks ;-) |
22:33 |
hmmmm |
sorry, I haven't been looking at what's being said in the channel |
22:33 |
sapier |
:-) no problem |
22:33 |
hmmmm |
eh, all of this reaks of platform dependent stuff |
22:33 |
hmmmm |
"if it's not Windows, then it's unix-like!" |
22:33 |
sapier |
yes so lack of /dev/null isn't an issue at all |
22:33 |
hmmmm |
it's as much of an issue as depending on /var |
22:34 |
hmmmm |
or is it |
22:34 |
sapier |
we don't depend as you can specify your own pidfile |
22:36 |
RealBadAngel |
btw, are we heading for next stable release anytime soon? |
22:37 |
sapier |
hmm daemon has a problem ... I can't create a pidfile on using it |
22:38 |
|
ImQ009 joined #minetest-dev |
22:42 |
sapier |
I fixed the redirections |
22:45 |
RealBadAngel |
^^ ? |
22:45 |
RealBadAngel |
i would like to merge shaders code |
22:45 |
sapier |
did someone test it yet? |
22:46 |
RealBadAngel |
there were 2 issues found thx to testing, fixed them |
22:46 |
sapier |
if it just a small bugfix I guess it's always fine to merge |
22:47 |
RealBadAngel |
no, its not small bugfix |
22:47 |
RealBadAngel |
its huge rewrite |
22:47 |
sapier |
I'd feel better if it was tested by a little bit more then two ppl |
22:48 |
RealBadAngel |
it is already tested |
22:48 |
RealBadAngel |
code is frozen since one month already |
22:48 |
sapier |
ok, do you have time the next week to fix bugs? ;-) |
22:49 |
RealBadAngel |
ive made bugfixes for the frozen state already |
22:49 |
RealBadAngel |
nothing serious tho |
22:49 |
RealBadAngel |
just issues with water animations (ive disabled them for water surface shaders) |
22:49 |
sapier |
I just want to avoid same thing to happen as with glowing water ;-) |
22:50 |
sapier |
while Imho that was one of the more nice bugs :-) |
22:50 |
RealBadAngel |
hehe |
22:50 |
RealBadAngel |
btw, that code improves performance greatly when using shaders |
22:51 |
RealBadAngel |
before shaders were compiled and assigned on each refresh |
22:51 |
sapier |
ok so you don't have a 120h work week next week? ;-) |
22:51 |
RealBadAngel |
now it takes place only on startup |
22:51 |
RealBadAngel |
and whats most important you can have a shader per tile |
22:52 |
|
LemonLake joined #minetest-dev |
22:52 |
RealBadAngel |
lets say water surface tile |
22:52 |
RealBadAngel |
which simply leads to water with reflections and refraction |
22:53 |
sapier |
you don't have to persuade me your fixes usually are better :-) but as any major changes they contain bugs |
22:54 |
|
LemonLake left #minetest-dev |
22:54 |
RealBadAngel |
ofc i can avoid that |
22:55 |
RealBadAngel |
cant |
22:55 |
RealBadAngel |
glsl is a bitch |
22:55 |
RealBadAngel |
it works different on each setup |
22:55 |
sapier |
yes we know how different different cards react |
22:56 |
RealBadAngel |
but on the other hand i cant find those bugs without making folks use it |
22:56 |
sapier |
so if you've time to fix occuring bugs no problem, but don't merge something like that if you already know you wont have time to fix the next weeks ;-) |
22:56 |
RealBadAngel |
last days im rather active |
22:57 |
RealBadAngel |
and that wont change rather |
22:58 |
Megaf |
folks, I'd like to use the -O3 flag for GCC when running make |
22:58 |
Megaf |
how do I do that? |
22:59 |
RealBadAngel |
idk, sapier? |
22:59 |
sapier |
edit src/CMakeLists.txt |
22:59 |
Megaf |
Thanks |
23:00 |
sapier |
be carefull about what you change if you do a release build changing debug flags wont have an effect of course ;-) |
23:00 |
RealBadAngel |
btw, somebody should add statement to the channel that Minecraft is not a guideline for us |
23:00 |
sapier |
we already know that ;-) |
23:00 |
RealBadAngel |
PA dont |
23:01 |
sapier |
he knows too |
23:01 |
Megaf |
Well, I still have no idea where I insert a flag |
23:01 |
sapier |
not beeing a guideline doesn't disallow having a look at how things have been solved there |
23:01 |
sapier |
megaf look for -O2 |
23:01 |
RealBadAngel |
ofc, i do have mc server in my git |
23:01 |
RealBadAngel |
and i do read it |
23:02 |
Megaf |
sapier; could not find |
23:02 |
RealBadAngel |
but i dont want mt to act exactly as mc does |
23:03 |
sapier |
because release is already built -O3 |
23:03 |
Megaf |
hm |
23:04 |
Megaf |
so how can I make it optmize even more? I'm taking a look at this sapier http://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html |
23:04 |
sapier |
more then O3? |
23:04 |
Megaf |
nope, 3 is max |
23:04 |
sapier |
I'd not recommend that unless you really know what you're doing |
23:05 |
Megaf |
-Ofast |
23:05 |
Megaf |
That's the deal |
23:06 |
sapier |
just because it's called fast it doesn't have to be faster then -O3 |
23:10 |
sapier |
but you can check in docs what's difference both are aliases only |
23:11 |
Exio4 |
-Ofast is -O3 + unsafe math callz |
23:12 |
sapier |
not a good idea |
23:12 |
Exio4 |
unsafe math callz in x86 are complaint |
23:12 |
sapier |
hmm |
23:12 |
sapier |
we already do that so it's most likely irrelevant for what we do |
23:14 |
Megaf |
The compiler should be able to tell what could be parellized too |
23:14 |
sapier |
I agree with "it should" ... but for real life examples compiler cant tell that one |
23:15 |
sapier |
that's not a thing about implementation but a theoretical impossibility |
23:15 |
Megaf |
interesting doc right here http://www.cmake.org/Wiki/CMake_Performance_Tips#Build_CMake_binary_with_optimization_enabled |
23:16 |
Exio4 |
sapier: functional programming |
23:16 |
sapier |
still a compiler can't tell what can be parallelized and what can't ... at least not in general ... for some special cases that might work automaticaly. but that's what parallel languages are used for to explicitly tell compiler what is safe to paralellize |
23:17 |
Exio4 |
what do you define by "safe" |
23:17 |
Exio4 |
without side-effects? |
23:17 |
sapier |
save as in doesn't cause data or control races |
23:17 |
Exio4 |
basically something purely functional |
23:18 |
sapier |
even there it's not possible to tell for all cases |
23:19 |
sapier |
and as usuall if compiler can't be sure about its supposed to not use parallelism |
23:21 |
Megaf |
I was thinking, I know it's not possible, but... In the case of my ODroid U3, it's CPU have to do the USB thing, the TCP thing, the MapGen, ServerThread. All that are running on a single core. If was possible to tell the software to use one core for USB thing, one core of TCP thing, one core for ServerThread and another core for MapGen, we would have a much more efficient system, and fast |
23:22 |
Exio4 |
that is the job of the kernel's scheduler |
23:22 |
sapier |
actually linux is supposed to do load balancing and it works for me. if that doesn't work for you you should find out why |
23:24 |
Megaf |
well, It's not doing that very well in my case |
23:27 |
sapier |
maybe wrong kernel configuration? |
23:27 |
Megaf |
maybe |
23:29 |
Exio4 |
do you see just a single core maxed out and all but that core idling? |
23:37 |
sapier |
hmm if it's not a configuration bug could it be 3 cores waiting for IO while only one remains for mt? |
23:39 |
|
restcoser joined #minetest-dev |
23:44 |
|
ImQ009 joined #minetest-dev |
23:57 |
|
ImQ009 joined #minetest-dev |
23:57 |
Megaf |
Exio4; 99.9% on a single core and at most 11% on any other core |
23:57 |
|
us`0gb joined #minetest-dev |
23:57 |
Megaf |
[20:37:55] <sapier> hmm if it's not a configuration bug could it be 3 cores waiting for IO while only one remains for mt? |
23:57 |
Megaf |
Yep |
23:57 |
Megaf |
IO wait is a nightmare |
23:57 |
Exio4 |
the main problem probably is locked lua |
23:58 |
Exio4 |
more like all the stuff waiting for lua |
23:58 |
sapier |
if those cores are really waiting for io nothing we de would change anything |
23:58 |
|
OldCoder joined #minetest-dev |
23:58 |
Exio4 |
his server has a hell lot of mods, doesn't it? |
23:58 |
Megaf |
Exio4; nope |
23:59 |
sapier |
no he's just using a arm device with crapy drivers |
23:59 |
sapier |
e.g. if your network driver does busy waiting for a packet to be received that core is locked no matter what we do |