Time |
Nick |
Message |
00:24 |
|
salamanderrake joined #minetest-dev |
01:00 |
|
ch98 joined #minetest-dev |
01:54 |
|
EdB joined #minetest-dev |
03:13 |
|
Miner_48er joined #minetest-dev |
04:37 |
|
neko259 joined #minetest-dev |
05:16 |
|
emptty joined #minetest-dev |
05:31 |
|
VanessaE joined #minetest-dev |
06:09 |
|
tango_ joined #minetest-dev |
06:19 |
|
tango_ joined #minetest-dev |
07:10 |
|
darkrose joined #minetest-dev |
07:10 |
|
darkrose joined #minetest-dev |
07:16 |
|
VanessaE joined #minetest-dev |
07:52 |
|
VanessaE joined #minetest-dev |
08:54 |
|
Calinou joined #minetest-dev |
09:28 |
|
rubenwardy joined #minetest-dev |
09:29 |
|
sapier joined #minetest-dev |
09:29 |
|
thk joined #minetest-dev |
09:54 |
|
Calinou joined #minetest-dev |
10:26 |
|
proller joined #minetest-dev |
10:43 |
sapier |
https://github.com/minetest/minetest/pull/724 added minizip support to mainmenu (NO libarchive) |
10:44 |
sapier |
I need the changes done for minetest dir detection as I don't want to redo this plz push those changes or at least tell me where to find them |
11:02 |
|
PilzAdam joined #minetest-dev |
11:03 |
|
Calinou joined #minetest-dev |
11:23 |
|
sapier1 joined #minetest-dev |
11:39 |
|
proller joined #minetest-dev |
11:50 |
|
rubenwardy joined #minetest-dev |
11:54 |
|
ImQ009 joined #minetest-dev |
12:21 |
|
proller joined #minetest-dev |
12:29 |
|
proller joined #minetest-dev |
12:37 |
|
proller joined #minetest-dev |
13:19 |
|
rubenwardy joined #minetest-dev |
13:26 |
|
BrandonReese_ joined #minetest-dev |
13:29 |
|
salamanderrake joined #minetest-dev |
13:48 |
|
serengeor joined #minetest-dev |
14:16 |
kahrl |
sapier: I'm currently rebasing a merge of your and my path function additions to master |
14:16 |
kahrl |
I have some questions about CopyDir |
14:16 |
kahrl |
is there a reason why it uses "r" and "w" as IO modes instead of "rb" and "wb"? |
14:17 |
kahrl |
also can it be fooled into an infinite recursion by symlink backreferences, and is that a problem? |
14:21 |
kahrl |
also is there any reason you used C style IO instead of streambuffers (not a problem, just wondering)? |
14:23 |
sapier |
aren't rb/wb same as rb/wb nowadays? |
14:23 |
sapier |
r/w |
14:24 |
|
Calinou_ joined #minetest-dev |
14:24 |
sapier |
c style no special I just thought c++ classes are a little bit too big for that simple operations |
14:24 |
kahrl |
they are different on windows, unless that changed recently |
14:25 |
kahrl |
r converts \r\n to \n and w converts \n to \r\n |
14:25 |
sapier |
ok I'm not very common to windows development so if it's better to use rb use it |
14:25 |
kahrl |
microsoft fail: http://stackoverflow.com/questions/7250720/ofstreamoperatorstreambuf-is-a-slow-way-to-copy-a-file |
14:25 |
kahrl |
so stdio is good here |
14:26 |
kahrl |
if microsoft had implemented this well it would be as simple as destfile << srcfile.rdbuf(); |
14:26 |
kahrl |
to copy a whole file |
14:27 |
sapier |
not much of a difference as you need to open it first and handle whatever exceptions that might occur if you use c++ code |
14:27 |
kahrl |
true |
14:28 |
sapier |
failing to install a mod shouldn't make minetest crash :) |
14:28 |
sapier |
is anyone working at mod handling? |
14:29 |
sapier |
mod functions are distributed throughout minetest which is a real pain |
14:29 |
rubenwardy |
what do you mean by "mod handling"? |
14:29 |
rubenwardy |
script api? |
14:29 |
sapier |
dependency management current modlist, mod datatype |
14:29 |
sapier |
s |
14:30 |
sapier |
no not the api |
14:30 |
rubenwardy |
a ha |
14:30 |
sapier |
the mod management |
14:30 |
kahrl |
sapier: I think there's a problem in the while(!feof(...)) loop |
14:30 |
kahrl |
in case an IO error happens, fread keeps returning zero |
14:31 |
sapier |
file line? |
14:31 |
kahrl |
in CopyDir |
14:31 |
kahrl |
filesys.cpp, dunno which line that is in whatever branch |
14:31 |
sapier |
found it |
14:32 |
sapier |
shouldn't fread return -1? |
14:32 |
sapier |
in case of error? |
14:32 |
kahrl |
man page says it returns 0 |
14:33 |
sapier |
true but I don't se an error? |
14:33 |
kahrl |
return type is size_t so -1 doesn't exist |
14:33 |
kahrl |
well, if an IO error happens feof(sourcefile) will return 0 |
14:33 |
kahrl |
so it becomes an infinite loop |
14:34 |
kahrl |
ferror(sourcefile) needs to be checked |
14:34 |
sapier |
oh true we need to check for ferror too |
14:34 |
sapier |
yes |
14:34 |
sapier |
do you fix it? |
14:34 |
kahrl |
yeah |
14:35 |
|
EdB joined #minetest-dev |
14:35 |
kahrl |
should the size of readbuffer be BUFSIZ? |
14:36 |
kahrl |
I heard it's an optimized value for this kind of operation |
14:36 |
sapier |
don't know what value is set there but I don't care about the exact buffersize either |
14:39 |
sapier |
doesn't seem to be very special to me ... I guess the optimal buffersize is to dependent on your os and hardwar |
14:44 |
sapier |
why does everyone do same thing different in mt community? serverlist is done in plain binary data modlist uses some strange forced json header .. |
14:50 |
kahrl |
i'm splitting of the file copy part because it's too deeply nested |
14:50 |
kahrl |
off* |
14:51 |
sapier |
no problem |
14:51 |
kahrl |
what do I call it? I was going for CopyFile but I realized that that is a bad idea |
14:52 |
kahrl |
perhaps CopyFileContents |
14:54 |
sapier |
why not CopyFile? |
14:54 |
kahrl |
CopyFile is a macro in windows.h |
14:55 |
sapier |
oh |
14:55 |
sapier |
MyCopyFIle? :-) |
15:04 |
|
hmmmm joined #minetest-dev |
15:07 |
|
Jordach joined #minetest-dev |
15:07 |
|
Jordach joined #minetest-dev |
15:26 |
sapier |
what about moving json code to separate files? |
15:27 |
sapier |
translating datastructures from json to internal representations lots of code that only makes functions less readable |
15:31 |
kahrl |
CopyFileContents now looks a bit ugly but should handle all error cases |
15:31 |
kahrl |
http://paste.dy.fi/5Yi |
15:33 |
sapier |
I'm not sure if this is correct |
15:34 |
sapier |
and the readbuffer within while is problematic too |
15:34 |
sapier |
if(readbytes != sizeof(readbuffer)) this is not a safe indicator for eof |
15:35 |
sapier |
I'm not sure if fread could be interrupted by an interrupt |
15:35 |
sapier |
returning a partial read in this case |
15:39 |
kahrl |
hmm the c standard says: "The fread function returns the number of elements successfully read, which may be less than nmemb if a read error or end-of-file is encountered." |
15:39 |
kahrl |
the standard draft I just downloaded, actually |
15:40 |
sapier |
I'm not sure but does this exclude temporary read errors? |
15:40 |
kahrl |
mathematically speaking it can be less in other situations too (it's an "if and only if" |
15:40 |
kahrl |
) |
15:40 |
kahrl |
it's not* |
15:41 |
sapier |
I'd feel more safe if there was used feof instead of implicit documentation knowledge |
15:42 |
kahrl |
I'll replace it with if(feof(sourcefile) || ferror(sourcefile)) |
15:42 |
kahrl |
what's the problem about the readbuffer? |
15:43 |
sapier |
it's pushed to stack on each loop |
15:43 |
kahrl |
I don't think any modern compiler works that way |
15:43 |
sapier |
you did program it that way ;-) compiler needs to do what you say |
15:44 |
sapier |
-needs + has to |
15:44 |
sapier |
of course depending on optimization level different compilers will do different things |
15:44 |
kahrl |
I'm sure this is optimized even on -O0 |
15:44 |
sapier |
I don't think so |
15:45 |
sapier |
you told him to create a new variable on each loop not doing this is an optimization |
15:47 |
kahrl |
it's an optimization that costs nothing, not even causing debug problems |
15:48 |
kahrl |
besides this function is IO bound anyway |
15:49 |
sapier |
no matter I'd not rely on compiler optimization if I don't have to |
15:50 |
sapier |
but of course thats an oppinion |
15:55 |
kahrl |
http://paste.dy.fi/5SE |
15:56 |
kahrl |
the subq $10016, %rsp is done outside of the loop even on -O0 |
15:59 |
sapier |
with your gcc |
15:59 |
kahrl |
with any modern compiler |
15:59 |
sapier |
proove "any" ;-) |
16:00 |
kahrl |
define any compiler that doesn't do this as not modern ;) |
16:00 |
Calinou_ |
inb4 clang |
16:01 |
sapier |
do what you can't avoid to do ... but don't blame a compiler doing what you tell him to do |
16:01 |
kahrl |
meh. I don't care enough about this to continue to argue |
16:01 |
sapier |
me too |
16:02 |
sapier |
i guess in 99.9999% of all cases both options will result in same binary code |
16:10 |
kahrl |
I just took the diff of two diffs |
16:10 |
kahrl |
would that be considered a second derivative? |
16:11 |
sapier |
lol |
16:16 |
VanessaE |
not to change the subject, but can someone please explain this: http://digitalaudioconcepts.com/vanessa/hobbies/minetest/screenshots/Screenshot%20-%2006102013%20-%2012:12:02%20PM.png |
16:16 |
VanessaE |
(namely the horrible performance in this scene - and this is a fresh sign-on, so this view is the only thing currently loaded) |
16:17 |
PilzAdam |
VanessaE, hows the same scene with fancy leaves disabled? |
16:19 |
VanessaE |
PilzAdam: about the same. http://digitalaudioconcepts.com/vanessa/hobbies/minetest/screenshots/Screenshot%20-%2006102013%20-%2012:18:26%20PM.png |
16:19 |
VanessaE |
1 fps difference. and this is without aniso/mipmap/filters or shaders. |
16:20 |
PilzAdam |
well, turn the shaders on |
16:20 |
Calinou |
with shaders on I also get this problem PilzAdam |
16:20 |
VanessaE |
shaders are usually on. they cost me a few more fps. |
16:20 |
Calinou |
25 FPS with shaders + AA + AF + filtering on with default pack |
16:20 |
Calinou |
(570 with nvidia 319.17) |
16:21 |
VanessaE |
there's a serious performance regression here. |
16:21 |
Calinou |
VanessaE: not a regression, it happens since always |
16:21 |
VanessaE |
Calinou: I used to get far better performance than what I get now with scenes like that ^^^^^ |
16:21 |
Calinou |
ah |
16:22 |
Calinou |
I always had 30-ish FPS on your server spawn |
16:22 |
VanessaE |
(and for the record, I only displayed the F6 profiler for your reference, not mine) |
16:22 |
PilzAdam |
VanessaE, try reducing the nodeboxes in your mods? |
16:23 |
VanessaE |
PilzAdam: if you'll look at that scene, there aren't that many. |
16:23 |
VanessaE |
and only three low-poly objects by me are even visible there |
16:24 |
VanessaE |
(the two types of fences and the lights. total of about 10 nodeboxes between those three nodes. |
16:25 |
VanessaE |
plus you can see moreblocks/stairsplus nodes in there, which as you know only consist of one or sometimes two nodeboxes per object. |
16:25 |
VanessaE |
the roofing on the grey stone building consists of four nodeboxes per tile I think. |
16:25 |
VanessaE |
no, make that two. |
16:26 |
VanessaE |
underground are two long columns of pipes, which consist of about a dozen nodeboxes apiece, but since they're not visible, they shouldn't be affecting the draw time. |
16:27 |
PilzAdam |
oh, they do AFAIK |
16:27 |
VanessaE |
why? |
16:27 |
PilzAdam |
the whole mapblock is rendered |
16:27 |
VanessaE |
that's STUPID |
16:27 |
PilzAdam |
make it better then |
16:27 |
VanessaE |
if I could, I would. |
16:27 |
PilzAdam |
if you could then you would know that its not stupid |
16:28 |
PilzAdam |
so stop judging things you dont understand |
16:28 |
VanessaE |
don't tell me I don't understand. I was screwing around with 3d rendering stuff before Minetest ever existed. On machines far less capable. |
16:28 |
VanessaE |
there's something going badly wrong here. |
16:29 |
VanessaE |
I'm just trying to catch it before it gets any worse. |
16:29 |
PilzAdam |
I would rather blame the nodeboxes |
16:30 |
VanessaE |
ok, then explain this: |
16:31 |
VanessaE |
wait, lemme get a better shot first. |
16:32 |
VanessaE |
http://digitalaudioconcepts.com/vanessa/hobbies/minetest/screenshots/Screenshot%20-%2006102013%20-%2012:31:24%20PM.png |
16:32 |
VanessaE |
there are a metric shitload of nodeboxes in this shot. |
16:32 |
VanessaE |
far more than in the sub-30 fps shots |
16:32 |
VanessaE |
inside that green building is a large mesecons circuit. Under the road, pipes. alpha glass in the background. signs all over the place. glass here and there. |
16:33 |
PilzAdam |
how many nodeboxes do you have per pipe node? |
16:33 |
VanessaE |
lemme re-check |
16:34 |
VanessaE |
about 40 per. |
16:34 |
VanessaE |
(about half as many visible faces though) |
16:34 |
PilzAdam |
and how many pipe nodes were rendered? |
16:34 |
VanessaE |
(because many of them are overlapped) |
16:34 |
VanessaE |
in that last shot? |
16:34 |
PilzAdam |
in the 28 FPS |
16:35 |
VanessaE |
in the 28 fps shot there are probably 130 pipes or so, none visible. |
16:35 |
VanessaE |
in the 48 fps one about the same number. |
16:35 |
PilzAdam |
so, 5200 nodeboxes |
16:36 |
VanessaE |
roughly. |
16:36 |
PilzAdam |
you want to say me that in the 48 FPS shot are more? |
16:36 |
VanessaE |
about the same number - I know what I built under that road. |
16:37 |
kahrl |
if stuff is under the road it might be occlusion culled |
16:38 |
PilzAdam |
VanessaE, the road are nodeboxes, right |
16:38 |
VanessaE |
kahrl: then why this? http://digitalaudioconcepts.com/vanessa/hobbies/minetest/screenshots/Screenshot%20-%2006102013%20-%2012:03:47%20PM.png |
16:38 |
VanessaE |
PilzAdam: the sidewalks and roughly 5% of the asphalt. |
16:39 |
kahrl |
VanessaE: note the larger number of blocks drawn |
16:39 |
VanessaE |
kahrl: yes - but note it's a shot of the sky |
16:39 |
VanessaE |
why is it drawing all the stuff that's off-screen? |
16:39 |
kahrl |
nearby blocks are always drawn, and occlusion culling isn't always exact |
16:40 |
VanessaE |
then I submit that the occlusion culling is broken :) |
16:45 |
|
neko259 joined #minetest-dev |
16:51 |
|
Calinou joined #minetest-dev |
16:53 |
|
proller joined #minetest-dev |
16:53 |
VanessaE |
kahrl: isn't there *something* that can be done? It didn't used to be this bad. |
16:54 |
kahrl |
I don't remember any recent changes in the occlusion culling code |
16:54 |
PilzAdam |
there was a fix in isBlockInSight() method |
16:55 |
kahrl |
oh, right |
16:56 |
kahrl |
VanessaE: try reverting 1369503aba and compare |
16:58 |
VanessaE |
Another comparison: 51fps, sure - but with 223 vertices being drawn when there are precisely 2 vertices visible. http://digitalaudioconcepts.com/vanessa/hobbies/minetest/screenshots/Screenshot%20-%2006102013%20-%2012:56:29%20PM.png |
16:59 |
VanessaE |
223k drawn that is |
16:59 |
VanessaE |
kahrl: ok |
17:01 |
VanessaE |
compiled, waiting for the client to load the map around it |
17:02 |
VanessaE |
that's actually slightly worse. |
17:03 |
VanessaE |
http://digitalaudioconcepts.com/vanessa/hobbies/minetest/screenshots/Screenshot%20-%2006102013%20-%2001:02:28%20PM.png |
17:03 |
VanessaE |
I entered the world in exactly the view shown here, so there was never an opportunity to see anything but the one node I'm looking at there. |
17:10 |
VanessaE |
strange, shouldn't the mesh processing basically die down after a couple of seconds? |
17:10 |
VanessaE |
hm, there is something causing the mesh code to run while near the spawn, but I see nothing changing |
17:11 |
VanessaE |
(except the clouds of course) |
17:11 |
VanessaE |
num_processed_meshes keeps jumping between 0 and 5 or 6 every couple of seconds |
17:11 |
kahrl |
ABMs? |
17:12 |
VanessaE |
dunno, I don't see anything changing other than a player that just ran past me |
17:12 |
VanessaE |
I know there are abms that run the pipes |
17:12 |
VanessaE |
but those just replace one node with another |
17:13 |
kahrl |
that causes a mesh update |
17:13 |
kahrl |
sapier: I pushed my stuff here: https://github.com/kahrl/minetest/commits/pathfunctions |
17:14 |
sapier |
thanks I'll merge to luamainmenu |
17:14 |
VanessaE |
I've noticed mesh updates lately have gotten really laggy - they spike the client's draw time |
17:14 |
VanessaE |
others have reported the same thing |
17:14 |
VanessaE |
hmmmm mentioned it as well |
17:17 |
PilzAdam |
AFAIK hmmmm said that mesh genration is genereally slow |
17:17 |
PilzAdam |
not that it become worse |
17:17 |
VanessaE |
yes |
17:18 |
VanessaE |
and I've noticed it getting worse overall. |
17:26 |
|
nyuszika7h joined #minetest-dev |
17:57 |
VanessaE |
oh wow, severe entity duplication bug in pipeworks |
17:59 |
VanessaE |
can someone try this circuit please and tell me if it's my code or the engine's entity duplication bug? |
18:01 |
VanessaE |
http://digitalaudioconcepts.com/vanessa/hobbies/minetest/screenshots/Screenshot%20-%2006102013%20-%2001:59:26%20PM.png |
18:01 |
VanessaE |
every time an item hits a split in a pipe, it is duplciated |
18:01 |
VanessaE |
duplicated* |
18:01 |
VanessaE |
and it's replicated several times on exiting a pipe. |
18:01 |
VanessaE |
this code has not been changed in months |
18:19 |
VanessaE |
in fact it seems like any time an item even changes direction at all |
18:46 |
sfan5 |
celeron55: In case you care: I got minetestserver running on android, chat is buggy (probably because wchar_t is differnt on android) and commands don't work, but gameplay itself should completly bugfree |
18:56 |
VanessaE |
actually scratch that thing about the duplication, it's not a bug. it's something nore did in my code. |
18:56 |
VanessaE |
s/nore/Nore/ |
18:57 |
ShadowNinja |
VanessaE: Has he fixed my duplication bug yet? |
18:59 |
VanessaE |
dunno |
19:00 |
VanessaE |
how does that one manifest itself? |
19:01 |
VanessaE |
->$minetest |
19:01 |
VanessaE |
->#minetest |
19:16 |
sapier |
what do you think about this gui for online modstore? http://imgur.com/4h7nrGA |
19:17 |
PilzAdam |
there are buttons missing to switch the page |
19:18 |
sapier |
no ^ and v are only shown if you're not already at top/bottom ... but I guess this looks strange somehow |
19:18 |
sapier |
the "scrollbar" ;-) |
19:30 |
|
Taoki joined #minetest-dev |
19:55 |
|
Taoki joined #minetest-dev |
20:06 |
|
Taoki joined #minetest-dev |
20:25 |
|
proller joined #minetest-dev |
21:40 |
Exio |
sfan5: what libc are you using? |
22:43 |
|
smoke_fumus joined #minetest-dev |
23:14 |
|
NakedFury joined #minetest-dev |
23:25 |
|
proller joined #minetest-dev |
23:36 |
|
Taoki joined #minetest-dev |
23:52 |
|
iqualfragile joined #minetest-dev |
23:53 |
|
iqualfragile joined #minetest-dev |