| Time |
Nick |
Message |
| 00:11 |
|
Lunatrius joined #minetest-dev |
| 00:12 |
RealBadAngel |
est31, damn whole the code around have * and & on the left side |
| 00:13 |
RealBadAngel |
i just added one parameter to that function |
| 00:14 |
RealBadAngel |
am i supposed to edit whole drawscene.cpp or what? |
| 00:15 |
est31 |
no RealBadAngel just edit the diff :) |
| 00:15 |
est31 |
only the things you change matter |
| 00:15 |
RealBadAngel |
then in function def one parameter will look different than others |
| 00:16 |
RealBadAngel |
not to mention whole file |
| 00:16 |
est31 |
so then, thats the correct style |
| 00:16 |
RealBadAngel |
unintuitive one imho |
| 00:17 |
RealBadAngel |
having ptr next to function name looks completely idiotic |
| 00:18 |
est31 |
its in the kernel style https://www.kernel.org/doc/Documentation/CodingStyle |
| 00:18 |
|
Lunatrius joined #minetest-dev |
| 00:20 |
est31 |
ok can you at least do it in the new files? |
| 00:21 |
est31 |
like here: https://github.com/minetest/minetest/pull/2814/files#diff-f20c82d93887e9a0f4d4eeb66cc7eaa7R419 |
| 00:22 |
RealBadAngel |
ive changed the lines im touching |
| 00:24 |
est31 |
ok |
| 00:26 |
RealBadAngel |
done |
| 00:27 |
est31 |
ok so why di you make your own queue? |
| 00:27 |
est31 |
do* |
| 00:29 |
RealBadAngel |
you mean in minimap update thread? |
| 00:29 |
est31 |
yes |
| 00:29 |
est31 |
why not std::queue |
| 00:29 |
RealBadAngel |
its not iterative |
| 00:30 |
est31 |
? |
| 00:30 |
RealBadAngel |
you cant iterate over std:queue elements |
| 00:30 |
RealBadAngel |
its fifo |
| 00:30 |
RealBadAngel |
no access to anything in the middle |
| 00:30 |
est31 |
and why do you iterate? |
| 00:31 |
RealBadAngel |
because of multiple updates |
| 00:31 |
RealBadAngel |
if that happens i do cancel previous one |
| 00:31 |
est31 |
I see |
| 00:32 |
RealBadAngel |
same thing is done in mapblock mesh |
| 00:32 |
RealBadAngel |
and its all about cracks |
| 00:32 |
RealBadAngel |
those suckers are causing block updates |
| 00:33 |
RealBadAngel |
thats one of the reasons im against cracks (when done in mapblock mesh) |
| 00:33 |
RealBadAngel |
but that is kinda religion, nobody can touch it ;) |
| 00:34 |
est31 |
what I've seen in kilbith's screenshot is a bad way to do crack replacements |
| 00:34 |
est31 |
cracks shouldnt be removed :) |
| 00:34 |
RealBadAngel |
particles are way better |
| 00:35 |
est31 |
yes at the end they are good |
| 00:35 |
RealBadAngel |
what screenshot youre talking about? |
| 00:35 |
RealBadAngel |
cracks have also one nasty effect |
| 00:35 |
est31 |
#1685 |
| 00:35 |
ShadowBot |
https://github.com/minetest/minetest/issues/1685 -- Digging animations tweaks. by RealBadAngel |
| 00:36 |
RealBadAngel |
each punching new node is causing growing memory usage |
| 00:36 |
est31 |
? its not freed? |
| 00:36 |
RealBadAngel |
because for each step of crack animation new texture is made |
| 00:37 |
RealBadAngel |
one should just cut that ^ operators code, burry it deep somewhere |
| 00:37 |
est31 |
? |
| 00:38 |
RealBadAngel |
you think why minetest with dreambuilder and hdx needs 12gb of ram? |
| 00:38 |
RealBadAngel |
because texture pack is 11gb? |
| 00:39 |
est31 |
ah lol |
| 00:39 |
RealBadAngel |
happily creating new textures everywhere |
| 00:39 |
est31 |
yea |
| 00:39 |
RealBadAngel |
rotating, cracks etc |
| 00:40 |
est31 |
you added the rotating part didnt you? |
| 00:40 |
RealBadAngel |
i made that with vertices |
| 00:40 |
RealBadAngel |
^ is not my sin |
| 00:40 |
est31 |
whats a vertex |
| 00:41 |
RealBadAngel |
point in 3d space |
| 00:41 |
est31 |
so a vector? |
| 00:41 |
RealBadAngel |
its a point, not a vector |
| 00:41 |
est31 |
whats a vector then? |
| 00:42 |
RealBadAngel |
https://en.wikipedia.org/wiki/Vector_%28mathematics_and_physics%29 |
| 00:43 |
est31 |
for me thats a point in 3d space |
| 00:43 |
est31 |
isnt it |
| 00:43 |
RealBadAngel |
no, vector is (pos of point B - pos of point A) |
| 00:43 |
est31 |
yes, but you have a 0 |
| 00:43 |
est31 |
whatever |
| 00:44 |
est31 |
first entry |
| 00:44 |
est31 |
ok, so how did you do it with vertices? |
| 00:44 |
RealBadAngel |
hold on |
| 00:45 |
RealBadAngel |
https://github.com/minetest/minetest/blob/master/src/mapblock_mesh.cpp#L455 |
| 00:46 |
RealBadAngel |
whole 6dfacedir is made this way |
| 00:47 |
RealBadAngel |
instead of rotating textures (and generating new ones) face is roated in 3d space |
| 00:47 |
est31 |
thats nice |
| 00:47 |
RealBadAngel |
now lets try to make ores |
| 00:47 |
est31 |
so whats generating new textures? |
| 00:47 |
RealBadAngel |
we should display stone |
| 00:48 |
RealBadAngel |
add offset for ore face |
| 00:48 |
RealBadAngel |
and display it |
| 00:48 |
RealBadAngel |
and voila, no new combined texture needed |
| 00:50 |
est31 |
how do you mean "add offset"? |
| 00:51 |
RealBadAngel |
imagine two sheets of paper |
| 00:51 |
RealBadAngel |
put one on another |
| 00:52 |
RealBadAngel |
cut holes in that one on top, you will see the bottom one |
| 00:53 |
est31 |
why not do just a simple cache? |
| 00:53 |
est31 |
just store the textures you need |
| 00:53 |
est31 |
and if you dont have them, just remove them |
| 00:53 |
RealBadAngel |
how could you tell whats needed and whats not? |
| 00:53 |
est31 |
err if you dont need them |
| 00:53 |
RealBadAngel |
you have already defined them all |
| 00:53 |
RealBadAngel |
on startup |
| 00:54 |
RealBadAngel |
everything is here and loaded into ram |
| 00:54 |
est31 |
so change it |
| 00:54 |
est31 |
make it not load everything on startup |
| 00:54 |
est31 |
but when needed |
| 00:54 |
RealBadAngel |
good luck with lags |
| 00:54 |
RealBadAngel |
preload item visuals says hello |
| 00:55 |
est31 |
"preload item visuals" is one of the RAM generators |
| 00:55 |
RealBadAngel |
but it works to show both sides of the problem |
| 00:55 |
RealBadAngel |
how slow will be such cache |
| 00:56 |
RealBadAngel |
and how bad item visual is (new texture ofc) |
| 00:56 |
est31 |
as slow as texture generation at the start |
| 00:56 |
RealBadAngel |
instead of displaying just mesh |
| 00:56 |
RealBadAngel |
its all because we are doing everything wrong |
| 00:57 |
est31 |
true |
| 00:57 |
RealBadAngel |
instead of drawtypes that do create needed meshes we generate textures on how the object will look like in game |
| 00:57 |
RealBadAngel |
thats sick |
| 00:57 |
RealBadAngel |
game is capable of displying it already |
| 00:58 |
RealBadAngel |
why to take a picture of it for christ sake? |
| 00:59 |
est31 |
I agree, taking a picture is bad. |
| 00:59 |
est31 |
in that case |
| 01:00 |
RealBadAngel |
btw, take a look at minimap draw |
| 01:00 |
RealBadAngel |
its a mesh |
| 01:00 |
RealBadAngel |
flat, but still a mesh |
| 01:00 |
RealBadAngel |
you can freely rotate it |
| 01:01 |
RealBadAngel |
and still display it as it would be a texture |
| 01:01 |
est31 |
so? |
| 01:01 |
RealBadAngel |
now, just take a nodes and display all of them at once |
| 01:01 |
RealBadAngel |
at given positions |
| 01:02 |
RealBadAngel |
selected one can even spin around for fancy look |
| 01:02 |
RealBadAngel |
you have just imagined formspec inventory slots using real meshes |
| 01:03 |
est31 |
I agree that that is the thing to do |
| 01:03 |
est31 |
its barely adding additional draw time for the gpu |
| 01:03 |
RealBadAngel |
one of the steps to reduce ram usage |
| 01:04 |
est31 |
and it reduces ram usage |
| 01:04 |
RealBadAngel |
next thing are specialized drawtypes |
| 01:04 |
RealBadAngel |
for wires, tubes, panes etc |
| 01:04 |
est31 |
yes |
| 01:05 |
est31 |
wires and tubes have same drawtype I guess |
| 01:05 |
RealBadAngel |
almost |
| 01:05 |
RealBadAngel |
tubes are 6d |
| 01:05 |
RealBadAngel |
wires are wallmounted |
| 01:05 |
est31 |
? |
| 01:06 |
RealBadAngel |
btw, do you know how many nodefs wire that could climb the walls needs? |
| 01:06 |
est31 |
we are speaking about technic cables, and pipeworks tubes? |
| 01:06 |
RealBadAngel |
those are using the same |
| 01:06 |
RealBadAngel |
wirelike is mesecons wire |
| 01:06 |
est31 |
ok then I dont know the wire you speak about |
| 01:07 |
RealBadAngel |
single mesecons wire would need circa 1k nodedefs |
| 01:07 |
est31 |
ah isnt that raillike? |
| 01:07 |
RealBadAngel |
no its not |
| 01:08 |
RealBadAngel |
railike is specialized for rails |
| 01:08 |
RealBadAngel |
not the wires |
| 01:09 |
RealBadAngel |
but are good example. you need just one nodedef for rails |
| 01:09 |
est31 |
ah I have the code now |
| 01:09 |
est31 |
ok |
| 01:09 |
RealBadAngel |
and they are forming connections live |
| 01:09 |
est31 |
then we need wirelike too |
| 01:09 |
RealBadAngel |
to simulate that behaviour modders predefine all possible connections |
| 01:09 |
RealBadAngel |
each being a nodedef |
| 01:10 |
RealBadAngel |
a nodebox, a mesh |
| 01:10 |
RealBadAngel |
one frigging wire would need 1k meshes |
| 01:11 |
RealBadAngel |
but what about if we wanted different couloured wire? |
| 01:11 |
RealBadAngel |
another 1k |
| 01:11 |
est31 |
yes I know |
| 01:11 |
est31 |
adding drawtypes is good |
| 01:12 |
RealBadAngel |
mod that makes such tricks is even in minetest_game |
| 01:12 |
RealBadAngel |
panes mod |
| 01:14 |
est31 |
btw do we really need to refer to MinimapPixel with pointers? |
| 01:14 |
est31 |
if we have 64 bit program, then there is no advantage |
| 01:15 |
est31 |
only disadvantage by free and malloc |
| 01:15 |
est31 |
ah I see |
| 01:15 |
est31 |
not needed |
| 01:16 |
est31 |
disregard |
| 01:16 |
est31 |
it would be good to be abled to specify a cursor for round maps too |
| 01:16 |
est31 |
one which isnt rotated |
| 01:16 |
est31 |
e.g. a crosshair |
| 01:17 |
RealBadAngel |
rotated one you can do without problems |
| 01:17 |
RealBadAngel |
just draw it on overlay image |
| 01:17 |
est31 |
ah I see |
| 01:17 |
est31 |
ok |
| 01:18 |
RealBadAngel |
you can add there NESW on the borders, whatever |
| 01:18 |
RealBadAngel |
those overlays can be modified by texture packs |
| 01:19 |
est31 |
can you add the minimap to formspec too? |
| 01:20 |
RealBadAngel |
since mapper stores info about all loaded blocks it could be used to draw bigger maps |
| 01:20 |
RealBadAngel |
and display textures whenever you want |
| 01:20 |
est31 |
ok I +1 it |
| 01:20 |
est31 |
but I merge it |
| 01:20 |
est31 |
because of the \r\n |
| 01:20 |
RealBadAngel |
so for example full screen map could be possible |
| 01:21 |
RealBadAngel |
hold on a sec, i will squash it |
| 01:23 |
est31 |
also, if you want, you can specify your own name in the copyright boilerplate |
| 01:23 |
est31 |
but I guess you know that already |
| 01:24 |
est31 |
entirely your descision |
| 01:24 |
Warr1024 |
what's the policy on licenses, btw? does it need to be GPL, or just compat? |
| 01:25 |
est31 |
no GPL isnt even allowed |
| 01:25 |
RealBadAngel |
est31, void *MinimapUpdateThread::Thread() |
| 01:25 |
Warr1024 |
er, lgpl or whatever? |
| 01:25 |
RealBadAngel |
you commented that "space"? why? |
| 01:25 |
est31 |
yes minetest is lgpl 2.1+ |
| 01:25 |
Warr1024 |
it was one of those gnu ones, wasn't it? |
| 01:25 |
est31 |
yes |
| 01:26 |
Warr1024 |
sry, I'm usually way down in MIT/ISC-land |
| 01:26 |
est31 |
so we need compat yea. I guess nobody will object if they publish their code more liberally |
| 01:26 |
est31 |
RealBadAngel, while(!StopRequested()) { |
| 01:27 |
est31 |
that one? |
| 01:27 |
RealBadAngel |
ah, that ones |
| 01:27 |
RealBadAngel |
i thought it was bout ptrs again |
| 01:32 |
RealBadAngel |
est31, ok, outdated all of your comments |
| 01:49 |
|
deltib joined #minetest-dev |
| 01:58 |
|
paramat joined #minetest-dev |
| 02:05 |
est31 |
ok RealBadAngel found some other style issue |
| 02:05 |
est31 |
I make a commit which also fixes the position update bug, ok? |
| 02:12 |
paramat |
i'll push #2831 later |
| 02:12 |
ShadowBot |
https://github.com/minetest/minetest/issues/2831 -- Mgv5/mgv7 caves: Fix sand in underground caves by paramat |
| 02:19 |
hmmmm |
bug!? |
| 02:19 |
hmmmm |
why was something patched with a bug in it |
| 02:19 |
VanessaE |
bug! |
| 02:19 |
VanessaE |
:P |
| 02:19 |
hmmmm |
paramat: i looked at that, seems good |
| 02:19 |
paramat |
cool thanks |
| 02:20 |
hmmmm |
also why did you not switch to std::queue for the queue |
| 02:21 |
hmmmm |
meh |
| 02:21 |
est31 |
<est31> ok so why di you make your own queue? |
| 02:21 |
est31 |
<est31> do* |
| 02:21 |
est31 |
<RealBadAngel> you mean in minimap update thread? |
| 02:21 |
est31 |
<est31> yes |
| 02:21 |
est31 |
<est31> why not std::queue |
| 02:21 |
est31 |
<RealBadAngel> its not iterative |
| 02:21 |
est31 |
<est31> ? |
| 02:21 |
est31 |
<RealBadAngel> you cant iterate over std:queue elements |
| 02:21 |
est31 |
<RealBadAngel> its fifo |
| 02:21 |
est31 |
<RealBadAngel> no access to anything in the middle |
| 02:21 |
est31 |
<est31> and why do you iterate? |
| 02:21 |
est31 |
<RealBadAngel> because of multiple updates |
| 02:21 |
est31 |
<RealBadAngel> if that happens i do cancel previous one |
| 02:21 |
est31 |
<est31> I see |
| 02:21 |
hmmmm |
why not use std::list then... |
| 02:22 |
hmmmm |
is there any need for random access to the queue? |
| 02:22 |
est31 |
vector is indeed a bad choice |
| 02:22 |
hmmmm |
there's a lot of egregious code style errors too |
| 02:22 |
est31 |
no |
| 02:22 |
est31 |
m_queue and m_blocks_cache have to be renamed |
| 02:22 |
hmmmm |
meh |
| 02:23 |
est31 |
how can I convert vector3d<s16> to vector3d<float> ?? |
| 02:24 |
hmmmm |
v3s16 to v3f? |
| 02:24 |
est31 |
yea |
| 02:24 |
hmmmm |
there's no intToFloat? |
| 02:24 |
hmmmm |
hrmm, well for the cave code it just uses v3f(pos.X, pos.Y, pos.Z) where pos is a v3s16 |
| 02:25 |
hmmmm |
v3f posf(pos.X, pos.Y, pos.Z) |
| 02:25 |
est31 |
my code is m_minimap_update_thread->last_update_pos - data->pos |
| 02:25 |
est31 |
I'll just assign a variable |
| 02:34 |
paramat |
now pushing 2831 |
| 02:39 |
paramat |
complete |
| 02:45 |
paramat |
i'm working on the fractal mapgen. it will be a 4D fractal with a 4th dimension co-ordinate parameter to choose the 3D slice generated, this will enable a big choice of different shapes. i've also added a mode to generate all the corresponding julia sets. possibly mergeable for 0.4.13 |
| 02:47 |
est31 |
RealBadAngel, does every pixel on the minimap get converted into one pixel on the screen? |
| 02:51 |
VanessaE |
est31: no. |
| 02:51 |
VanessaE |
the image is scaled according to the window size. |
| 02:52 |
est31 |
argh dammit |
| 02:52 |
est31 |
seems I need that scaling factor |
| 02:52 |
est31 |
or find another way to do it |
| 02:55 |
paramat |
woo this minimap is fun |
| 02:56 |
VanessaE |
est31: what are you fixing anyway? |
| 02:56 |
est31 |
that slow update issue |
| 02:57 |
VanessaE |
ohhh |
| 02:57 |
est31 |
position update I mean |
| 03:08 |
|
deezl joined #minetest-dev |
| 03:09 |
paramat |
ah i see the square map doesn't rotate, so they have complimentary uses. surprisingly i prefer the round one =) |
| 03:21 |
paramat |
think i'll make my own non-solid player marker texture that doesn't cover the central area |
| 03:34 |
RealBadAngel |
est31, dont try to skip the update if position remains the same |
| 03:34 |
est31 |
? |
| 03:35 |
RealBadAngel |
i can see youre trying to do something like that, am i right? |
| 03:35 |
est31 |
no, I want to update the position faster than the minimap |
| 03:36 |
est31 |
so I've tried to update it with material.TextureLayer[0].setTextureMatrix |
| 03:36 |
est31 |
inside Mapper::drawMinimap() |
| 03:36 |
est31 |
but that doesnt work |
| 03:36 |
est31 |
that method has no effect at all |
| 03:37 |
RealBadAngel |
? mimimap runs the same fps as whole game |
| 03:37 |
RealBadAngel |
at least on my box |
| 03:37 |
est31 |
not on mine, when I turn shaders off |
| 03:37 |
est31 |
RealBadAngel, have you seen my screencast? |
| 03:37 |
est31 |
it updates the minimap perhaps thrice a second |
| 03:38 |
RealBadAngel |
why would you disable shaders? |
| 03:38 |
est31 |
RealBadAngel, thats not the point |
| 03:38 |
RealBadAngel |
shaders (final color blend) are faster than c++ code |
| 03:38 |
est31 |
If I enable them, the effect is not as strong, but still there |
| 03:39 |
est31 |
also, rotation is not affected |
| 03:39 |
est31 |
so thats very weird |
| 03:39 |
est31 |
rotation working on one hand |
| 03:39 |
est31 |
and position update not working |
| 03:39 |
RealBadAngel |
rotation has nothing to do with scanning |
| 03:39 |
est31 |
and it shouldnt |
| 03:40 |
est31 |
but I want to have position updates be faster |
| 03:40 |
RealBadAngel |
cant watch the screencast, im on mobile connection atm |
| 03:41 |
est31 |
why doesnt material.TextureLayer[0].setTextureMatrix() work, do you have an idea? |
| 03:41 |
RealBadAngel |
what you want to get with changing the texture matrix? |
| 03:42 |
est31 |
from what I see, the Mapper::drawMinimap() is called more often than an actual update to the minimap texture |
| 03:43 |
est31 |
now I just take the difference between last position the map was updated and the current position |
| 03:43 |
RealBadAngel |
draw is called each frame |
| 03:44 |
RealBadAngel |
it has to be |
| 03:44 |
RealBadAngel |
oherwise you couldnt see it |
| 03:44 |
est31 |
but the position doesnt update each frame |
| 03:45 |
RealBadAngel |
you cant help that |
| 03:45 |
RealBadAngel |
on my box minimap update is rdy faster than, so thread waits for texture to be grabbed |
| 03:46 |
est31 |
not on mine |
| 03:46 |
est31 |
only because you cant reproduce an issue doesnt mean others dont have it |
| 03:47 |
RealBadAngel |
whats your cpu? |
| 03:47 |
est31 |
amd |
| 03:47 |
est31 |
is that importannt |
| 03:47 |
RealBadAngel |
cores and speed |
| 03:47 |
est31 |
2ghz 6 cores |
| 03:47 |
RealBadAngel |
lookin for a reason, so yeah, its important |
| 03:48 |
RealBadAngel |
ovearall fps? |
| 03:48 |
est31 |
30 |
| 03:48 |
est31 |
to 40 |
| 03:48 |
RealBadAngel |
when you enable minimap, how much fps you are loosing? |
| 03:49 |
est31 |
none noticable |
| 03:50 |
RealBadAngel |
so why you think matrix operations have something to do with map update speed? |
| 03:50 |
est31 |
I dont want to improve update spee |
| 03:50 |
est31 |
d |
| 03:50 |
est31 |
I want to work around the issue |
| 03:50 |
RealBadAngel |
those are done for each and every object in scene node |
| 03:50 |
est31 |
the texture isn't up to date yes |
| 03:51 |
RealBadAngel |
this has nothing to do with draw code then |
| 03:51 |
est31 |
but at least I want to translate it by the amount the player has moved in the time the last update was |
| 03:51 |
est31 |
and that has to happen at the same place as the rotation is applied |
| 03:52 |
RealBadAngel |
i will add some test code to find locate your problem |
| 03:52 |
RealBadAngel |
will do that in my branch |
| 03:52 |
est31 |
ok |
| 03:53 |
RealBadAngel |
it looks like for some reason scan takes longer than it should |
| 03:53 |
RealBadAngel |
which is strange because most heavy operations are done in mapblock_mesh |
| 03:54 |
RealBadAngel |
and you dont see lags when loading meshes around, dont you? |
| 03:54 |
est31 |
what do you mean |
| 03:55 |
est31 |
they just appear, movement stays smooth |
| 03:56 |
RealBadAngel |
so it means that most heavy scanning operations are done also fast |
| 03:56 |
RealBadAngel |
minimap_mapblocks are created together with mapblock_mesh |
| 03:57 |
RealBadAngel |
in mapblockmesh_update_thread |
| 03:57 |
RealBadAngel |
does mode of minimap any effect on update speed for you? |
| 03:58 |
RealBadAngel |
i mean the surfacex1 vs x4 ? |
| 03:58 |
est31 |
x1 zoom is slower than x2 is slower than x4 |
| 03:59 |
RealBadAngel |
does x4 runs at acceptable speed? |
| 03:59 |
est31 |
no |
| 04:00 |
est31 |
err yes |
| 04:00 |
est31 |
or almost |
| 04:00 |
est31 |
its borderline |
| 04:00 |
est31 |
but I'd say yet |
| 04:00 |
RealBadAngel |
i see |
| 04:00 |
est31 |
yes* |
| 04:01 |
est31 |
there is a noticeable difference, but you can excuse it with the pixel-y design of minetest if you know what I mean |
| 04:03 |
RealBadAngel |
what takes most of the time is MinimapUpdateThread::getMinimapPixel |
| 04:03 |
RealBadAngel |
i mean getMap which calls above |
| 04:04 |
RealBadAngel |
since blocks are 16x16 chunks of data we need to continuosly translate node pos to block pos |
| 04:04 |
RealBadAngel |
for each and every pixel |
| 04:05 |
RealBadAngel |
thats only thing i can think of to improve the speed |
| 04:05 |
est31 |
just work around it |
| 04:06 |
RealBadAngel |
if it wont be translated you will get movement step at a size of mapblock |
| 04:07 |
est31 |
just translate by the delta pos since the last texture update |
| 04:07 |
est31 |
the drawing is smooth, but the minimap doesnt update often enough |
| 04:08 |
est31 |
so the rotation is smooth, thats my core problem |
| 04:08 |
RealBadAngel |
because those two work in separate threads |
| 04:08 |
RealBadAngel |
draw only takes new texture if scan is ready |
| 04:08 |
est31 |
so just make a position adjustment in the same thread as the rotation |
| 04:09 |
RealBadAngel |
that wont help |
| 04:09 |
RealBadAngel |
same as delta |
| 04:09 |
est31 |
why |
| 04:09 |
RealBadAngel |
because for same reason youre getting scan ready too slow |
| 04:10 |
RealBadAngel |
draw rate is 30-40 times per second |
| 04:10 |
RealBadAngel |
if mapper stays behind, it means its ready with scan less frequent |
| 04:10 |
RealBadAngel |
and you cant get another scan in the middle of it |
| 04:11 |
est31 |
I dont want to re-scan |
| 04:11 |
RealBadAngel |
so you see the last one complete |
| 04:11 |
est31 |
I just want to move the texture as far as you moved since the last scan |
| 04:12 |
paramat |
http://i.imgur.com/VXqVQZf.png testing new mountain parameters in mgv7, found this floatland rising to y = 945 (hmmmm) |
| 04:12 |
|
paramat left #minetest-dev |
| 04:12 |
RealBadAngel |
first of all you do have a few pixels margin left for that |
| 04:12 |
RealBadAngel |
those which are covered by overlays |
| 04:13 |
est31 |
ok |
| 04:13 |
est31 |
now how to move it |
| 04:13 |
hmmmm |
paramat, i hope that isn't too common |
| 04:13 |
hmmmm |
that's a little too crazy for a default mainstream mapgen |
| 04:14 |
VanessaE |
hmmmm: maybe but wow |
| 04:15 |
VanessaE |
there's something strangely appealing about the idea of playing on such a crazy map |
| 04:16 |
est31 |
RealBadAngel, https://github.com/est31/minetest/commit/81586b58ed2be68f02f2c0b8e91e3d785120f330 |
| 04:16 |
hmmmm |
then edit your parameters |
| 04:16 |
hmmmm |
don't make them the defaults |
| 04:17 |
VanessaE |
I didn't say I wanted it, just that it's "strangely appealing" :) |
| 04:17 |
* est31 |
feels the urge to finally implement VAEs so that he can give those floatlands a float-ore and when you mine too much of it, the whole floatland falls down and crashes into the ground |
| 04:18 |
VanessaE |
heh |
| 04:18 |
est31 |
and you can make your buildings fly with that ore too |
| 04:21 |
RealBadAngel |
http://irrlicht.sourceforge.net/docu/classirr_1_1core_1_1_c_matrix4.html#a2bab9633697a892f08d89c7aeee6daf6 |
| 04:22 |
RealBadAngel |
maybe you should try this one |
| 04:25 |
RealBadAngel |
est31, anyway i will add there later code to measure time for it, something runs definitely way too slow for you |
| 04:25 |
est31 |
doesnt help either |
| 04:31 |
VanessaE |
RealBadAngel: the map shifts at about 4 pixels per second for me when walking, while the world is refreshing at ~35 fps. |
| 04:32 |
VanessaE |
so, similar to est31's result |
| 04:32 |
est31 |
its biased by up to 10 when I'm flying with fast |
| 04:32 |
VanessaE |
while turning is at full fps |
| 04:32 |
VanessaE |
biased? |
| 04:32 |
est31 |
you know lagging behing |
| 04:32 |
est31 |
d* |
| 04:33 |
VanessaE |
OH |
| 04:33 |
VanessaE |
yeah I see that effect too, but it's somewhat subtle |
| 04:33 |
VanessaE |
maybe 5 pixels behind |
| 04:34 |
est31 |
try this commit to get accurate numbers https://github.com/est31/minetest/commit/8fab7f74f09680705a519c4609a559aae08a3dc1 |
| 04:35 |
est31 |
oh, I didnt mean pixels, I meant nodes |
| 04:35 |
est31 |
it will print the delta in life |
| 04:35 |
VanessaE |
ok, sec. |
| 04:36 |
VanessaE |
when talking "pixels" I mean the rendered map, so 1 pixel == ~1 node |
| 04:36 |
VanessaE |
in any case the map doesn't move perfectly fluid for me, but it's not a huge jump either. |
| 04:38 |
VanessaE |
it's mostly printing D 0 0 0 ... sometimes 0 0 (1 or -1) while I walk or fast fly |
| 04:39 |
* VanessaE |
turns shaders on.. |
| 04:41 |
est31 |
ok its about as same as bad as for without shaders |
| 04:42 |
VanessaE |
mostly -1 to +1 there, but LOTS more of non-zero values; occasionally it hits -2 or +2 |
| 04:42 |
est31 |
I have it going to 10 at most times, then jumping to 0 again |
| 04:42 |
est31 |
you are on x1? |
| 04:42 |
VanessaE |
maybe a CPU and GPU speed issue? |
| 04:43 |
VanessaE |
yes, x1 mode |
| 04:43 |
est31 |
perhaps. whats your fps? |
| 04:45 |
VanessaE |
in the "benchmark scene" RBA and I have been using, 34 fps @ 87.6m range (drawtime of 28-29) with the minimap off. With it on, 34 fps @ 72.9m, drawtime of around 28. |
| 04:46 |
VanessaE |
(the minimap costs me about 15m of view distance, or about 5 or so fps if I lock the distance) |
| 04:46 |
est31 |
I have even ~57 fps occasionally |
| 04:46 |
VanessaE |
(maybe 10 fps, need to test) |
| 04:47 |
est31 |
when I move, its around 60, but when I stand still, it falls down to ~30 |
| 04:47 |
est31 |
very weird |
| 04:48 |
VanessaE |
ok, 102 on the drawtime with the minimap off, if I lock my view range to 245m. 122 with the minimap on in that state. |
| 04:48 |
VanessaE |
so a 20% cost for me :-/ |
| 04:48 |
est31 |
hmmmm, can caves really cut into jungles, like here: http://pasteboard.co/1wJ4gPdi.png |
| 04:50 |
hmmmm |
est31: I think that's caused by paramat's recent is_ground_content patch |
| 04:51 |
est31 |
ok |
| 05:09 |
est31 |
ahhh |
| 05:09 |
est31 |
I seem to know why it doesnt work |
| 05:09 |
est31 |
lemme try sth |
| 05:25 |
est31 |
wow this irrlicht is weird |
| 05:25 |
est31 |
if you do matrix.setTextureScale(3.0,1.0); |
| 05:25 |
est31 |
then it works for the quadratic, and doesnt for the round |
| 05:26 |
est31 |
now when I remove the rotate call for the round one, it works again |
| 05:26 |
est31 |
just why is it overriding? |
| 05:27 |
|
err404 joined #minetest-dev |
| 05:38 |
|
Calinou joined #minetest-dev |
| 05:41 |
|
Megaf_ joined #minetest-dev |
| 05:41 |
|
err404 left #minetest-dev |
| 05:49 |
|
paramat joined #minetest-dev |
| 05:51 |
paramat |
hmmmm yes i should have added: it's too crazy, using this location i will tune parameters and limit the highest mountains to around 512, similar to the highest summits found before in mgv7 |
| 05:53 |
paramat |
est31, your screenshot of chopped jungles is bemusing, in my recent commit i set trees to be ground_content = false to avoid that, you're using latest mtgame? |
| 05:53 |
est31 |
no minimal |
| 05:53 |
paramat |
oh |
| 05:53 |
est31 |
and it was most likely freshly generated |
| 05:54 |
paramat |
okay yes my fault |
| 05:55 |
paramat |
will fix |
| 05:55 |
paramat |
when i last worked on minimal i edited some ground_content settings |
| 06:00 |
paramat |
however tree was set as ground content true before my commit, minimal is a rather neglected mess |
| 06:02 |
paramat |
it's a bit frustrating to work on because there's so much updating needed but i don't know how much i should do because it is after all 'minimal'. for example jungletrees and pines don't drop saplings etc.. |
| 06:05 |
paramat |
then when i do work on it i feel like i should be doing more important things, because it's such a mess =) |
| 06:21 |
|
asl97 joined #minetest-dev |
| 06:45 |
|
Jbb joined #minetest-dev |
| 06:58 |
|
paramat left #minetest-dev |
| 07:11 |
|
nore joined #minetest-dev |
| 07:37 |
|
Hunterz joined #minetest-dev |
| 07:40 |
|
kilb joined #minetest-dev |
| 07:41 |
|
asl97 joined #minetest-dev |
| 07:42 |
|
kilbith joined #minetest-dev |
| 07:53 |
|
Krock joined #minetest-dev |
| 08:04 |
|
Yepoleb joined #minetest-dev |
| 08:29 |
Hunterz |
hi, please is there any windows build with latest commits (minimap) ? |
| 08:30 |
VanessaE |
probably not yet |
| 08:30 |
VanessaE |
minimap just went in some hours ago |
| 08:30 |
est31 |
at least not here: https://forum.minetest.net/viewforum.php?f=42 |
| 08:30 |
Hunterz |
I know :) its very nice |
| 09:40 |
|
SopaXorzTaker joined #minetest-dev |
| 09:50 |
|
MinetestForFun joined #minetest-dev |
| 10:00 |
Krock |
Yay! Minimap *recompiles* |
| 10:31 |
Krock |
Hunterz, there's a windows build with minimap now.. I'm testing it right now |
| 10:33 |
Krock |
somehow it takes years to load the item definitions |
| 10:43 |
|
kilbith joined #minetest-dev |
| 11:04 |
|
selat joined #minetest-dev |
| 11:07 |
|
Krock joined #minetest-dev |
| 11:08 |
|
Calinou joined #minetest-dev |
| 11:24 |
|
kilbith joined #minetest-dev |
| 12:07 |
|
Puma_rc joined #minetest-dev |
| 12:12 |
RealBadAngel |
Krock, it can take a bit longer, minimap needs data from all the nodes |
| 12:13 |
Krock |
RealBadAngel, I've set enable_minimap to false to see if it's the minimap but it doesn't change anything |
| 12:13 |
RealBadAngel |
whats your game? |
| 12:15 |
RealBadAngel |
ah, indeed, i havent disabled fetching the colors with minimap disabled |
| 12:15 |
RealBadAngel |
i will push fix for that ASAP |
| 12:15 |
Krock |
could that color loading cause a packet time-out? I doupt that.. |
| 12:16 |
RealBadAngel |
no way |
| 12:16 |
RealBadAngel |
its only client side and after media received |
| 12:16 |
Krock |
okay, thanks. perhaps there's an other fail |
| 12:16 |
RealBadAngel |
so the delay you have must be something else |
| 12:17 |
RealBadAngel |
when i tested the time cost it was like 4-5s longer for dreambuilder game |
| 12:17 |
|
est31 joined #minetest-dev |
| 12:18 |
RealBadAngel |
hi est31, any luck with textures shifting? |
| 12:18 |
est31 |
nope |
| 12:18 |
|
FR^2 joined #minetest-dev |
| 12:20 |
RealBadAngel |
i can think of another solution for you |
| 12:20 |
RealBadAngel |
when moving scanning code (most of it) to mapblock mesh, ive decided to double scanning height |
| 12:21 |
RealBadAngel |
you could propably try old values |
| 12:22 |
RealBadAngel |
https://github.com/minetest/minetest/blob/master/src/minimap.cpp#L283 |
| 12:22 |
RealBadAngel |
second value is scan height, try setting it to 128 |
| 12:29 |
est31 |
RealBadAngel, its faster, but far from good |
| 12:30 |
RealBadAngel |
ok, lets try another thing |
| 12:30 |
RealBadAngel |
https://github.com/minetest/minetest/blob/master/src/minimap.cpp#L141 |
| 12:30 |
RealBadAngel |
uncomment that and see if it changes anything |
| 12:32 |
est31 |
I've set it to 1000 and its gotten slower |
| 12:33 |
RealBadAngel |
i mean some low value |
| 12:33 |
RealBadAngel |
not 1k :) try 1 |
| 12:33 |
est31 |
btw that loop definitely needs improvement |
| 12:33 |
est31 |
nope not faster |
| 12:34 |
RealBadAngel |
ok |
| 12:34 |
Krock |
btw, est31, why did you merge that commit with master? RealBadAngel could do it aswell |
| 12:34 |
Krock |
just wonder |
| 12:34 |
est31 |
Krock, RBA had evil \r\n line endings |
| 12:35 |
Krock |
that depends on the git settings, they can be set, so they commit as \n and read as \r\n |
| 12:35 |
RealBadAngel |
what should i set? |
| 12:35 |
est31 |
yes and a repo can override those |
| 12:35 |
est31 |
which minetest does |
| 12:36 |
est31 |
this is the strange part |
| 12:43 |
est31 |
RealBadAngel, list of things hmmm and I havve seen are bad. #2844 |
| 12:43 |
ShadowBot |
https://github.com/minetest/minetest/issues/2844 -- Minimap code and behaviour problems |
| 12:43 |
est31 |
bye for 2day |
| 12:44 |
|
est31 joined #minetest-dev |
| 12:46 |
Krock |
lol |
| 12:58 |
RealBadAngel |
well, i just measured how long get map takes |
| 12:58 |
Krock |
is it a pain to look at that number? |
| 12:59 |
RealBadAngel |
im not sure if im seeing it right |
| 13:01 |
RealBadAngel |
yeah, its a bit different, hold on |
| 13:02 |
RealBadAngel |
13-14ms |
| 13:02 |
RealBadAngel |
thats how long full scan in surface mode takes for me |
| 13:03 |
RealBadAngel |
so theoretically, on my box minimap could run at 77fps |
| 13:04 |
RealBadAngel |
and in practice minimap updates are faster than overall FPS |
| 13:04 |
RealBadAngel |
3,1Ghz dual core here |
| 13:06 |
RealBadAngel |
i need some feedback and others to test the time on different CPUs |
| 13:08 |
RealBadAngel |
est31, come back into the channel :) |
| 13:11 |
kilbith |
i use an old single core CPU, showing the minimap doesn't impact the FPS at all and the map is shown as soon as the mapblocks are generated |
| 13:12 |
RealBadAngel |
can you add some testing code to the minimap? |
| 13:13 |
kilbith |
sure |
| 13:13 |
RealBadAngel |
http://pastebin.com/tP5ukU2d |
| 13:13 |
RealBadAngel |
https://github.com/minetest/minetest/blob/master/src/minimap.cpp#L135 |
| 13:14 |
kilbith |
the output is shown in the console ? |
| 13:14 |
kilbith |
i don't see a 'cout' |
| 13:14 |
RealBadAngel |
yes, its dumped to the console |
| 13:19 |
RealBadAngel |
kahrl, nore, Calinou here? |
| 13:35 |
RealBadAngel |
anybody to help me testing code above? |
| 13:40 |
* Krock |
tries to find the source of #2842 |
| 13:40 |
ShadowBot |
https://github.com/minetest/minetest/issues/2842 -- RE-SENDING timed-out RELIABLE to 127.0.0.1 |
| 13:41 |
RealBadAngel |
Krock, can you apply the code i pasted? i need feedback |
| 13:42 |
|
selat joined #minetest-dev |
| 13:43 |
Krock |
RealBadAngel, sure, I must check an other build first |
| 13:43 |
RealBadAngel |
thx |
| 13:44 |
|
red1 joined #minetest-dev |
| 13:44 |
Krock |
gawd, if there just would be a faster way to link those .obj files.. no mater if just 1 line was changed or not, it always takes 5 minutes or longer just to create an exe |
| 13:45 |
kilbith |
.obj files are meshes |
| 13:45 |
Krock |
.obj are generally just binary files |
| 13:53 |
kilbith |
http://pastie.org/10261678 |
| 13:53 |
kilbith |
^ with crappy old CPU |
| 13:53 |
Krock |
kilbith, define "crappy old CPU" |
| 13:54 |
kilbith |
intel celeron 900, single core |
| 13:54 |
Krock |
k |
| 13:55 |
|
red1 joined #minetest-dev |
| 14:05 |
Krock |
RealBadAngel, where exactly should those messages appear? |
| 14:05 |
RealBadAngel |
in console when minimap is on |
| 14:06 |
RealBadAngel |
copy for me circa 500 lines and pastebin them |
| 14:06 |
Krock |
I enabled the minimap but when I joined the singleplayer world after waiting 2 minutes, there was no minimap and no debug text |
| 14:06 |
Krock |
blue sky and flying at 0, 0.5, 0 |
| 14:08 |
Krock |
perhaps I should un-comment the line "sleep_ms(10);" |
| 14:08 |
RealBadAngel |
no leave it commented out |
| 14:09 |
Krock |
so what should I do? I can't play in any singleplayer world |
| 14:10 |
RealBadAngel |
weird |
| 14:10 |
kilbith |
fresh new git clone maybe |
| 14:10 |
Krock |
unicode is broken again \o/ öäü are gone |
| 14:10 |
RealBadAngel |
i think so |
| 14:11 |
RealBadAngel |
Krock, indeed, try from scratch |
| 14:11 |
Krock |
RealBadAngel, already tried that - doesn't help |
| 14:11 |
Krock |
*didn't help |
| 14:12 |
RealBadAngel |
i think that you already checked minimap and it worked? |
| 14:13 |
Krock |
that's wrong |
| 14:13 |
Krock |
I tried to find the fail in my compiler but now I think something's messed up in the code |
| 14:14 |
RealBadAngel |
you are trying to compile unmodified master right? |
| 14:15 |
Krock |
yes and it compiled fine |
| 14:16 |
RealBadAngel |
but? |
| 14:16 |
Krock |
as already said, joining a world takes minutes and when I get in, the terrain doens't load |
| 14:17 |
RealBadAngel |
im checkin master now too |
| 14:17 |
kilbith |
certainly windows-specific issue then |
| 14:17 |
kilbith |
on linux everything's fine |
| 14:18 |
Krock |
I tested c6766b2 from Jun 23, (without building from scratch) and the problem didn't exist anymore |
| 14:18 |
Krock |
yes, perhaps a porting issue |
| 14:19 |
kilbith |
too bad you've no verbose |
| 14:19 |
Krock |
I got minetest's verbose mode.. doesn't help very much |
| 14:21 |
|
est31 joined #minetest-dev |
| 14:23 |
RealBadAngel |
est31, whats your cpu? |
| 14:23 |
est31 |
hardware is pretty recent |
| 14:23 |
est31 |
from this decade |
| 14:23 |
est31 |
AMD Phenom(tm) II X6 1055T |
| 14:24 |
est31 |
Krock, have you pressed f9? |
| 14:25 |
RealBadAngel |
est31, yet its 25 times slower than my 2 core intel |
| 14:25 |
RealBadAngel |
such difference is not the matter of the scanning algorithm i used |
| 14:25 |
est31 |
that cant be |
| 14:25 |
kilbith |
est31, my CPU is like 800% slower than your and performs twice more better on minimap, how possible ? |
| 14:26 |
Krock |
est31, oooh. |
| 14:26 |
RealBadAngel |
i do get 17ms average, kilbith 193ms (single core). and you with amd 6cores get 427ms |
| 14:27 |
Krock |
well, ther are no nodes to render, so it's no wonder why the times are that tiny http://pastebin.com/tcKCgRU9 |
| 14:27 |
est31 |
rule confirmed the better your hardware, the worse your experience |
| 14:27 |
RealBadAngel |
but to be sure we need more testers |
| 14:27 |
est31 |
RealBadAngel, whats your setup? |
| 14:27 |
est31 |
square map? |
| 14:27 |
RealBadAngel |
for me it looks like amd threading is fucked up |
| 14:27 |
RealBadAngel |
shape doesnt matter |
| 14:27 |
RealBadAngel |
map is always a square |
| 14:28 |
est31 |
also is the map always loaded? |
| 14:28 |
RealBadAngel |
what we do measure now is performace of a routine in a thread |
| 14:28 |
RealBadAngel |
forget fps, shape and everything else |
| 14:29 |
RealBadAngel |
we should get similar results, i do have 3,1ghz cpu vs 2,8ghz. 2 cores vs 6 cores |
| 14:29 |
RealBadAngel |
intel vs amd |
| 14:29 |
RealBadAngel |
17 ms vs 423 |
| 14:30 |
est31 |
intel is always better, and you have larger ghz |
| 14:30 |
RealBadAngel |
by 300mhz |
| 14:30 |
est31 |
but that only accounts for 3x-6x factor |
| 14:30 |
est31 |
I guess |
| 14:30 |
est31 |
you have windows RealBadAngel, dont you? |
| 14:30 |
RealBadAngel |
looking at time? i should have 70 Ghz cpu |
| 14:31 |
kilbith |
frequence is not all, a recent Atom at 1200 Mhz is more powerful than my old celeron at 2200 mhz |
| 14:31 |
RealBadAngel |
^^ that was a joke |
| 14:31 |
celeron55 |
stop hilighting me god damnit |
| 14:31 |
RealBadAngel |
est31, atm only linux |
| 14:31 |
kilbith |
oops, sorry |
| 14:31 |
celeron55 |
or alternatively make it so that people don't call me "celeron" so that i can disable that hilight |
| 14:32 |
est31 |
celeron55, what have you set to ping you? |
| 14:32 |
est31 |
c55 too? |
| 14:32 |
celeron55 |
c55 doesn't |
| 14:32 |
kilbith |
i dunno how i can name my CPU differently than celero* |
| 14:33 |
celeron55 |
it's not worth mentioning |
| 14:33 |
celeron55 |
stop talking about it! |
| 14:33 |
kilbith |
ok sorry |
| 14:33 |
celeron55 |
ok good 8-) |
| 14:33 |
RealBadAngel |
actually we have to talk bout processors |
| 14:33 |
RealBadAngel |
looks like threading doesnt work for amd (just a guess) |
| 14:33 |
celeron55 |
well i guess i'll disable the hilight then |
| 14:33 |
celeron55 |
done |
| 14:34 |
est31 |
RealBadAngel, before saying its cpu fault, perhaps we should try to ensure its no code fault? |
| 14:34 |
est31 |
you run windows, right? |
| 14:34 |
RealBadAngel |
no, linux here |
| 14:34 |
est31 |
next thing: do you try the map in singleplayer? |
| 14:35 |
est31 |
which db backend? |
| 14:35 |
RealBadAngel |
and i havent said its cpu fault. it start to look like threading code fault |
| 14:35 |
RealBadAngel |
est31 all those things are irrevelant to this code |
| 14:35 |
RealBadAngel |
i just want to know its execution time, thats all |
| 14:36 |
RealBadAngel |
it is working on data stored in ram. runs in thread. end of conditions |
| 14:36 |
est31 |
so, confirm your theory |
| 14:36 |
est31 |
but its not always hw faul |
| 14:36 |
est31 |
t |
| 14:37 |
RealBadAngel |
atm i dont check anything else just how long it takes to execute this very specific function |
| 14:37 |
est31 |
so lets test other things too |
| 14:37 |
RealBadAngel |
how it gathered needed data, whats the weather outside doesnt matter |
| 14:38 |
RealBadAngel |
i just wanna know why your amd is 25 times slower than my intel |
| 14:39 |
est31 |
ok |
| 14:39 |
est31 |
RealBadAngel, can you confirm something for me |
| 14:39 |
RealBadAngel |
sure |
| 14:40 |
est31 |
can you open your cpu overview, and search for whetrher a cpu is at 100% when minimap is activated |
| 14:42 |
RealBadAngel |
70-75% |
| 14:43 |
est31 |
because I get 100% CPU even when minimap is turned off |
| 14:43 |
est31 |
I do nothing |
| 14:43 |
est31 |
nothing at all |
| 14:43 |
est31 |
and its only since the minimap commit |
| 14:43 |
RealBadAngel |
minimap adds another thread |
| 14:44 |
RealBadAngel |
it works no matter you are sitting duck or flying |
| 14:44 |
RealBadAngel |
same as the other threads |
| 14:44 |
est31 |
do you have the 10 ms line commented in? |
| 14:44 |
RealBadAngel |
its inactive |
| 14:45 |
RealBadAngel |
i do have an idea |
| 14:45 |
RealBadAngel |
lets run a simple loop in a thread |
| 14:46 |
RealBadAngel |
doing just a simple fun math inside |
| 14:46 |
est31 |
thats the result of your while (true) stuff |
| 14:46 |
RealBadAngel |
what are you talkin about? |
| 14:46 |
est31 |
and imho a pretty serious regression |
| 14:46 |
RealBadAngel |
then you should be able to play at all since ages |
| 14:46 |
RealBadAngel |
*nt |
| 14:47 |
est31 |
one of my CPU cores is at 100% |
| 14:47 |
RealBadAngel |
its how mapblock mesh updates are done |
| 14:47 |
RealBadAngel |
since always |
| 14:47 |
RealBadAngel |
but yet you dont complain on meshes |
| 14:47 |
est31 |
constantly, even if I don't have minimap activated |
| 14:47 |
est31 |
lets see how its done there |
| 14:47 |
RealBadAngel |
the very same way |
| 14:47 |
est31 |
you have the file |
| 14:48 |
est31 |
? |
| 14:48 |
RealBadAngel |
open client.cpp and look at the start of the file |
| 14:48 |
RealBadAngel |
find mapblock mesh update thread |
| 14:48 |
RealBadAngel |
that while is made to empty the queue |
| 14:48 |
RealBadAngel |
it doest stop the thread or something |
| 14:53 |
est31 |
its using MutexedQueue |
| 14:54 |
RealBadAngel |
where? |
| 14:55 |
RealBadAngel |
i can see std::vector :P |
| 14:55 |
RealBadAngel |
the very same one you and hmmm dont like |
| 14:58 |
est31 |
ok |
| 14:59 |
est31 |
but still there is a 100% CPU |
| 14:59 |
est31 |
with minimap turned off |
| 14:59 |
RealBadAngel |
threads are running in loop |
| 14:59 |
RealBadAngel |
doing nothing also takes time |
| 14:59 |
est31 |
but you agree 100% CPU is bad isnt it? |
| 14:59 |
est31 |
for doing nothing |
| 15:00 |
RealBadAngel |
even when doing nothing cpu is always busy |
| 15:00 |
RealBadAngel |
doing nothing is a command |
| 15:01 |
RealBadAngel |
but still, we are not talking on the subject |
| 15:02 |
RealBadAngel |
i need to test something. you will have to test the same |
| 15:02 |
est31 |
agreed |
| 15:05 |
est31 |
ShadowNinja, you there? |
| 15:12 |
|
deltib joined #minetest-dev |
| 15:31 |
est31 |
but better some minimap than no minimap |
| 15:32 |
est31 |
I am writing a patch adding semaphores |
| 15:32 |
est31 |
which will remove the 100% issue |
| 15:32 |
est31 |
not the slow drawing issue |
| 15:33 |
ShadowNinja |
est31: Yep. |
| 15:34 |
est31 |
ShadowNinja, I wonder how the MeshUpdateThread works without running hot, by re-requesting and re-requesting again |
| 15:35 |
red1 |
how can I kick all players on server crash? |
| 15:36 |
est31 |
that doesnt work |
| 15:36 |
est31 |
for regular shutdowns, try this mod: https://github.com/est31/kickall |
| 15:36 |
red1 |
ok |
| 15:37 |
est31 |
but there is no feature for triggering non-regular shutdowns |
| 15:37 |
RealBadAngel |
ShadowNinja, https://github.com/minetest/minetest/issues/2844 |
| 15:37 |
RealBadAngel |
what do you think about difference in execution time? |
| 15:38 |
ShadowNinja |
RealBadAngel: IIRC you have a pretty good gfx card. |
| 15:38 |
RealBadAngel |
we are not talkin GPU now |
| 15:38 |
ShadowNinja |
CPU then. |
| 15:38 |
RealBadAngel |
the measured thing works in thread, on data stored in ram and thats cpu |
| 15:39 |
RealBadAngel |
look at kilbith, est31 and mine results |
| 15:39 |
ShadowNinja |
You might have different settings since yours is so much faster. |
| 15:40 |
RealBadAngel |
settings doesnt matter here |
| 15:41 |
RealBadAngel |
it will be the same for any kind of game, textures used and weather outside |
| 15:41 |
est31 |
really RealBadAngel? |
| 15:41 |
RealBadAngel |
what counts here is pure cpu speed |
| 15:41 |
est31 |
even if I say that i have disabled mesh cache? |
| 15:41 |
RealBadAngel |
ofc |
| 15:41 |
red1 |
how can i dectect an error from lua? |
| 15:42 |
RealBadAngel |
its not butterfly effect ;) |
| 15:43 |
RealBadAngel |
you could propably instert there simple loop repated 1kk times and measure that |
| 15:43 |
RealBadAngel |
and you still will ask one answer, why AMD is slower |
| 15:43 |
RealBadAngel |
* question |
| 15:46 |
RealBadAngel |
ShadowNinja, can you test that too? |
| 15:47 |
est31 |
also, I get one CPU core with 100%, even when minimap is disabled |
| 15:47 |
est31 |
can you test that too? |
| 15:49 |
RealBadAngel |
another thread are here |
| 15:49 |
RealBadAngel |
minimap's one is just one of them |
| 15:49 |
|
hmmmm joined #minetest-dev |
| 15:49 |
RealBadAngel |
you have saw that mapblock mesh updates thread works the very same way |
| 15:49 |
est31 |
I dont know whats happening but I dont get it for the other threads |
| 15:50 |
est31 |
You are right, there are almost no differences |
| 15:50 |
est31 |
but thats not the way to code |
| 15:50 |
est31 |
its busy polling |
| 15:50 |
* est31 |
guesses we need a new queuedworkerthread class |
| 15:51 |
RealBadAngel |
propapbly, my knowledge bout threads is next to nothing |
| 15:51 |
RealBadAngel |
i just copied for minimap one we are already using |
| 15:52 |
est31 |
ok then you arent to blame |
| 15:52 |
est31 |
but I'm fixing it for the minimap first |
| 15:52 |
est31 |
and then I do that class |
| 15:52 |
hmmmm |
so who was the second person to +1 the minimap feature |
| 15:52 |
RealBadAngel |
and it looks like everythin is fine for Intel cpus |
| 15:52 |
hmmmm |
just curious |
| 15:52 |
est31 |
hmmmm, it was me |
| 15:52 |
hmmmm |
who was the first person to +1 it |
| 15:52 |
est31 |
now I clean up (part of the) mess |
| 15:52 |
est31 |
RBA |
| 15:53 |
hmmmm |
... that |
| 15:53 |
est31 |
"mess" |
| 15:53 |
hmmmm |
is definitely not what was intended |
| 15:53 |
hmmmm |
i wouldn't agree to something so unstable being added to minetest |
| 15:53 |
est31 |
me neither if I knew it back then |
| 15:53 |
hmmmm |
this is such a massive performance regression for something so incredibly trivial |
| 15:54 |
hmmmm |
you shouldn't be comparing cpus |
| 15:54 |
hmmmm |
"oh well it's only 70% on my i7" |
| 15:54 |
est31 |
there are two issues here |
| 15:54 |
hmmmm |
it should be completely unnoticable on any cpu later than athlon 64 |
| 15:54 |
est31 |
the first one being why its slow for me |
| 15:54 |
hmmmm |
if it's not there's a problem |
| 15:54 |
RealBadAngel |
hmmm, no its working fine on single core intel cpu |
| 15:55 |
est31 |
and the second one why there is 100% CPU |
| 15:55 |
RealBadAngel |
always was |
| 15:55 |
est31 |
the first one has a big question mark |
| 15:55 |
est31 |
no idea why |
| 15:55 |
kilbith |
there was always 100% CPU |
| 15:55 |
RealBadAngel |
because of mapblock mesh update thread |
| 15:55 |
est31 |
the second one, well I'm writing a patch for it right now |
| 15:55 |
RealBadAngel |
new thread doesnt change anything |
| 15:55 |
est31 |
mapblock mesh update thread does that horrible thing too, but somehow it doesnt get cpu to 100% |
| 15:56 |
RealBadAngel |
and it itself is not a regression |
| 15:56 |
est31 |
at least for me |
| 15:56 |
RealBadAngel |
it just shows that threading for amd cpus is broken at all |
| 15:56 |
* est31 |
stops debating whether its a regression or not and continues writing the patch |
| 15:56 |
RealBadAngel |
agree |
| 15:57 |
hmmmm |
"threading for AMD cpus" |
| 15:57 |
RealBadAngel |
yes |
| 15:57 |
hmmmm |
you're trying to minimize the problem |
| 15:57 |
RealBadAngel |
VanessaE reported the same, long time before minimap was there |
| 15:57 |
hmmmm |
AMD gpus |
| 15:57 |
RealBadAngel |
no, im not minimizing it, im looking for a solution |
| 15:57 |
hmmmm |
good coders would admit there's a problem and work on figuring it out rather than denying |
| 15:58 |
est31 |
^ |
| 15:58 |
RealBadAngel |
hmmmm, i just figured out that it depends on CPU kind |
| 15:58 |
hmmmm |
it doesn't. |
| 15:58 |
hmmmm |
that's a bunch of bullshit. |
| 15:58 |
RealBadAngel |
what the code does its not important |
| 15:58 |
RealBadAngel |
only matters it runs in a thread |
| 15:59 |
RealBadAngel |
damn replace whole getMap code, throw it and put there 1kk loop |
| 15:59 |
RealBadAngel |
you will get the same effect |
| 16:02 |
RealBadAngel |
hmmmm, what CPU do you have? |
| 16:02 |
RealBadAngel |
can you run the same test? |
| 16:08 |
|
ElectronLibre joined #minetest-dev |
| 16:08 |
est31 |
ok my theory wasn't right, my patch doesnt help |
| 16:09 |
RealBadAngel |
est31, what have you tried? |
| 16:12 |
est31 |
RealBadAngel, https://github.com/est31/minetest/commit/f33cd5261bec9c94437a87213e24907b4c450710 |
| 16:13 |
est31 |
either way I think that should be pushed |
| 16:13 |
est31 |
because its the right way to do it |
| 16:13 |
RealBadAngel |
it couldnt had any impact on performance |
| 16:14 |
RealBadAngel |
as queue has usually just a few entries per second |
| 16:14 |
est31 |
yes but the for loop will rage on either way |
| 16:14 |
est31 |
so that has been optimized |
| 16:15 |
RealBadAngel |
it just collects data which another thread has made |
| 16:15 |
RealBadAngel |
data transferred are as small as v3s16 and a pointer |
| 16:15 |
est31 |
thats totally irrelevant |
| 16:15 |
est31 |
a while true stays a while true |
| 16:16 |
RealBadAngel |
time spent on it is usually 30-40ns |
| 16:16 |
est31 |
I made it a while true { block() |
| 16:16 |
est31 |
RealBadAngel, you still dont get it? |
| 16:16 |
RealBadAngel |
yes, i get it |
| 16:17 |
RealBadAngel |
but still it has no impact on performance |
| 16:18 |
est31 |
you dont get it. |
| 16:24 |
RealBadAngel |
i may not. what i can see it is doing just the same |
| 16:24 |
est31 |
ok then I try to explain |
| 16:25 |
est31 |
do you know semaphores? |
| 16:25 |
est31 |
they are a data structure to communicate between threads |
| 16:25 |
est31 |
basically, its an int |
| 16:25 |
est31 |
you have two operations: increment, and decrement |
| 16:25 |
est31 |
now the increment works instantaneously, and the decrement too, unless the int is 0 |
| 16:26 |
est31 |
if its 0, it will wait until the int is 1 (by another thread incrementing the semaphore), and then decrement |
| 16:26 |
est31 |
so what people can use is that "wait" part |
| 16:26 |
est31 |
its ideal for queues |
| 16:27 |
est31 |
every time you add to the queue, you increase, every time you remove, you decrease |
| 16:27 |
est31 |
and when you can't remove, you wait until stuff comes in |
| 16:27 |
est31 |
and not spend CPU power checking the same value again and again |
| 16:28 |
hmmmm |
maybe it's time to check out what's going on under valgrind |
| 16:28 |
est31 |
yup |
| 16:28 |
est31 |
5 mins ago I've started callgrind |
| 16:28 |
est31 |
now its at initializing nodes 61% |
| 16:28 |
est31 |
64$ |
| 16:29 |
RealBadAngel |
ok |
| 16:29 |
RealBadAngel |
i will try to optimize getMap itself to work faster |
| 16:30 |
RealBadAngel |
math here is pretty complex because i do have data in chunks, not as before got pixel by pixel |
| 16:30 |
est31 |
so! I have a scene |
| 16:31 |
|
Puma_rc joined #minetest-dev |
| 16:31 |
est31 |
now lets let it render into nothingness for some time |
| 16:31 |
RealBadAngel |
and hmmmm, getting a full scan of 8,5kk nodes real time is not trivial |
| 16:31 |
est31 |
ok now I have it |
| 16:31 |
|
TeTpaAka joined #minetest-dev |
| 16:32 |
TeTpaAka |
I also get around 400 ms on Intel. |
| 16:33 |
RealBadAngel |
TeTpaAka, whats your cpu? |
| 16:33 |
TeTpaAka |
I posted it on github |
| 16:33 |
TeTpaAka |
Its a core i5 |
| 16:33 |
est31 |
can you reproduce the "big 100%" bug, where one cpu core is at 100%, with minimap turned off? |
| 16:33 |
TeTpaAka |
Around 5 years old |
| 16:33 |
est31 |
(and not there before) |
| 16:34 |
RealBadAngel |
TeTpaAka, thx |
| 16:35 |
RealBadAngel |
est31, if you would like remove busy polling from threads you should modify other threads too |
| 16:35 |
est31 |
RealBadAngel, agreed |
| 16:35 |
RealBadAngel |
start with mesh update thread |
| 16:36 |
RealBadAngel |
client.cpp line 165 |
| 16:36 |
RealBadAngel |
i will look if we are using such mechanism elsewhere |
| 16:37 |
|
Puma_rc joined #minetest-dev |
| 16:40 |
TeTpaAka |
Confirmed, one core is always at 100%, even in pause menu, which wasn't the case before. |
| 16:40 |
RealBadAngel |
est31, httpfetch.cpp line 641 |
| 16:40 |
est31 |
ok, callgrind sais it is spending 60% of its time inside minimapupdatethread::thread() |
| 16:41 |
est31 |
inclusive |
| 16:41 |
|
CraigyDavi joined #minetest-dev |
| 16:42 |
|
Puma_rc joined #minetest-dev |
| 16:42 |
est31 |
out of some reason the size requesting plays a big role |
| 16:44 |
|
Puma_rc_ joined #minetest-dev |
| 16:45 |
RealBadAngel |
est31, maybe that sleep should be there to free time for others? |
| 16:45 |
est31 |
thats what the semaphore is for |
| 16:46 |
est31 |
its sleeping until something happens |
| 16:46 |
est31 |
much better than sleeping a bit, checking, sleeping again, checking again |
| 16:47 |
RealBadAngel |
have you checked cpu usage with you patch then? |
| 16:47 |
est31 |
yes, and I wonder why it didnt improve |
| 16:48 |
RealBadAngel |
<est31> ok, callgrind sais it is spending 60% of its time inside minimapupdatethread::thread() |
| 16:48 |
RealBadAngel |
it was with or without the patch? |
| 16:48 |
est31 |
with the patch |
| 16:49 |
RealBadAngel |
can you check how much takes meshupdatethread? |
| 16:49 |
RealBadAngel |
it is using sleep |
| 16:49 |
est31 |
11 |
| 16:49 |
VanessaE |
RealBadAngel: told you it was thread-related. :) |
| 16:50 |
RealBadAngel |
VanessaE, hi |
| 16:50 |
VanessaE |
hi |
| 16:50 |
RealBadAngel |
you were getting 100% load before minimap, right? |
| 16:51 |
VanessaE |
variably. |
| 16:51 |
VanessaE |
but you already know turning the minimap on costs me a good 5 or so fps when it should theoretically be immesurable. |
| 16:51 |
VanessaE |
(well 5+ fps or 10-15 m draw distance, depending on which is capped) |
| 16:51 |
RealBadAngel |
that 5fps cost is preparing new textures, and is done in main thread |
| 16:52 |
VanessaE |
but it's nearly always stuck using up a single core |
| 16:52 |
RealBadAngel |
so its not the cause of cpu load |
| 16:52 |
VanessaE |
(i.e. almost never expands into the other cores) |
| 16:53 |
est31 |
ahhh |
| 16:53 |
est31 |
I'm stupid |
| 16:53 |
est31 |
darmmm |
| 16:53 |
|
Puma_rc joined #minetest-dev |
| 16:53 |
VanessaE |
? |
| 16:53 |
est31 |
grr |
| 16:53 |
est31 |
I did the wait call inside the second while |
| 16:53 |
est31 |
where it makes totally no sense |
| 16:53 |
est31 |
because then its guaranteed already there is an element in there |
| 16:54 |
est31 |
ah yes |
| 16:54 |
est31 |
ok |
| 16:55 |
RealBadAngel |
so, lets wait again for that grind thingy |
| 16:55 |
est31 |
now it seems to work |
| 16:55 |
est31 |
no 100% CPU |
| 16:55 |
RealBadAngel |
but? |
| 16:55 |
est31 |
nothing but |
| 16:55 |
est31 |
CPU is calm again |
| 16:55 |
RealBadAngel |
whats the load now |
| 16:55 |
RealBadAngel |
that but |
| 16:55 |
est31 |
big regression is gone |
| 16:56 |
RealBadAngel |
can you apply the same to meshes? |
| 16:56 |
est31 |
yes |
| 16:56 |
est31 |
while it would be interesting why I can't see any issues there |
| 16:57 |
RealBadAngel |
it sleeps |
| 16:57 |
est31 |
that has no difference |
| 16:57 |
RealBadAngel |
propapbly thats why its freeing time for others |
| 16:57 |
est31 |
I've removed the sleep call, and it worked still |
| 16:57 |
RealBadAngel |
but no freeing time anymore |
| 16:59 |
RealBadAngel |
but, does freeing cpu time had any impact on getMap execution time? |
| 16:59 |
RealBadAngel |
the test we are doing before |
| 16:59 |
RealBadAngel |
were |
| 16:59 |
est31 |
lemme see |
| 17:00 |
est31 |
no |
| 17:00 |
est31 |
and it was unlikely |
| 17:00 |
est31 |
because the CPU is only occupied if it has no tasks |
| 17:00 |
RealBadAngel |
there has to be reason why code is 25 times faster for me |
| 17:01 |
RealBadAngel |
cpu speed is comparable to yours |
| 17:02 |
VanessaE |
time spent communicating with the GPU, I'd guess. you issue a GPU call, it blocks for us but not for you? so for you you can go on and do something else right after. |
| 17:03 |
RealBadAngel |
VanessaE, this code is not gpu related |
| 17:03 |
RealBadAngel |
its pure cpu and memory ops |
| 17:03 |
VanessaE |
hm |
| 17:03 |
VanessaE |
*shrug* not sure then |
| 17:03 |
RealBadAngel |
VanessaE, you have the same cpu as est31, can you run the test too? |
| 17:04 |
VanessaE |
sure. link to the correct patch? |
| 17:04 |
RealBadAngel |
grab the mainstream and open minimap.cpp |
| 17:04 |
VanessaE |
open. |
| 17:05 |
RealBadAngel |
https://github.com/minetest/minetest/issues/2844 |
| 17:05 |
RealBadAngel |
here you have code in my comment |
| 17:05 |
VanessaE |
https://github.com/minetest/minetest/issues/2844#issuecomment-116043264 |
| 17:06 |
VanessaE |
that? |
| 17:06 |
est31 |
btw RealBadAngel there is autmatically average generating code in this commit : https://github.com/minetest/minetest/commit/0b6b87154503f35d1d1cfd55c4352ff24efed4bb |
| 17:06 |
est31 |
its easy to adjust to print the sample size too |
| 17:06 |
RealBadAngel |
VanessaE, yes |
| 17:07 |
RealBadAngel |
VanessaE, it doesnt matter you will try it with minimal or dreambuilder |
| 17:07 |
RealBadAngel |
times will be the same |
| 17:07 |
VanessaE |
ok |
| 17:07 |
VanessaE |
building... |
| 17:07 |
RealBadAngel |
est31, in this commit you have messed with texture matices |
| 17:08 |
est31 |
yes but no visible change |
| 17:08 |
est31 |
also, its another thread |
| 17:09 |
VanessaE |
RealBadAngel: ok, what am I supposed to do? |
| 17:09 |
RealBadAngel |
turn minimap on |
| 17:10 |
RealBadAngel |
and copy like 500 lines from console and pastebin it to me |
| 17:11 |
VanessaE |
http://pastebin.com/GCWbRDyT |
| 17:11 |
VanessaE |
looks like it's averaging around 27ms |
| 17:11 |
RealBadAngel |
rotfl |
| 17:11 |
VanessaE |
this is an AMD Phenom II X6 1055T (2.8 GHz, 6 cores) |
| 17:11 |
RealBadAngel |
and thats funny |
| 17:12 |
VanessaE |
default window size, default textures, and I think I had shaders turned on. |
| 17:12 |
RealBadAngel |
my theory on vendor related problems is officially thrown into dustbin |
| 17:12 |
VanessaE |
lol |
| 17:12 |
RealBadAngel |
now we had one intel i5 with 400ms |
| 17:13 |
RealBadAngel |
and same kind amds one 27ms and another 427 |
| 17:13 |
VanessaE |
fwiw, the time went up a bit while I was turning around slowly to let the whole minimap fill up with loaded blocks. |
| 17:13 |
VanessaE |
(into the low 30's) |
| 17:14 |
RealBadAngel |
est31, how can you explain that? she has the same cpu as you do |
| 17:15 |
est31 |
its obviously, like I and hmmmm std::deque |
| 17:15 |
est31 |
errr |
| 17:15 |
est31 |
like i and hmmm said no cpu problem |
| 17:15 |
VanessaE |
I always compile with -O3, in Release mode, and always a full compile (make clean; rm CMakeCache; cmake . -Dblahblah... ; make -j8) |
| 17:16 |
est31 |
perhaps we had a dust of grain during cpu production, while you people had none? |
| 17:16 |
VanessaE |
I doubt it. |
| 17:16 |
est31 |
I compile debug mode |
| 17:17 |
VanessaE |
I still suspect a GPU-threading issue; race conditions resulting in a spinlock somewhere maybe |
| 17:17 |
RealBadAngel |
its weird |
| 17:18 |
est31 |
grain of dust* |
| 17:18 |
est31 |
wow sometimes I speak funny stuff |
| 17:18 |
VanessaE |
est31: right, I doubt there's a speck of wheat in your CPU ;) |
| 17:19 |
RealBadAngel |
est31, anyway i think polling patch is not related to that issue and should be merged |
| 17:19 |
RealBadAngel |
hmmmm, do you agree on that? |
| 17:21 |
est31 |
https://github.com/est31/minetest/commit/420125debd3d010fcd3e7738c43f25c8f407ab63 |
| 17:23 |
|
TeTpaAka joined #minetest-dev |
| 17:24 |
TeTpaAka |
Mine was a debug build. Now, as release, I get 29,5 |
| 17:24 |
VanessaE |
est31: ^^^ interesting. |
| 17:24 |
est31 |
yea |
| 17:24 |
est31 |
ahaaaaa |
| 17:24 |
VanessaE |
? |
| 17:24 |
est31 |
lemme try |
| 17:24 |
est31 |
too |
| 17:24 |
VanessaE |
also Debug mode compiles with -O1 doesn't it? |
| 17:25 |
RealBadAngel |
TeTpaAka, 29,5 is the average time for my test? |
| 17:25 |
TeTpaAka |
Yes, over 316 samples |
| 17:26 |
RealBadAngel |
est31, how do you build your game? |
| 17:26 |
est31 |
debug |
| 17:26 |
RealBadAngel |
:PPPPPPPPP |
| 17:26 |
RealBadAngel |
i think i should kick you in the ass ;) |
| 17:27 |
est31 |
hah |
| 17:27 |
RealBadAngel |
because of you cpu vendors were blamed :P |
| 17:27 |
est31 |
I didnt raise the blames |
| 17:27 |
est31 |
still I notice lag |
| 17:27 |
est31 |
only occasionally |
| 17:27 |
RealBadAngel |
timings please |
| 17:27 |
est31 |
but larger than before |
| 17:27 |
est31 |
umm lemme see |
| 17:28 |
|
Wuzzy joined #minetest-dev |
| 17:29 |
VanessaE |
btw it's ~28.79 ms over 604 samples, if you want an exact figure. |
| 17:29 |
est31 |
the problem is it doesnt show up in the statistics |
| 17:29 |
RealBadAngel |
i mean the test for getMap |
| 17:29 |
Wuzzy |
Any comments on <https://github.com/minetest/minetest/pull/2438>? Many people complained the tooltips were too long, but I don't know how to shorten them any further without losing information. :-/ |
| 17:29 |
RealBadAngel |
wuzzy, break lines |
| 17:30 |
RealBadAngel |
tooltips support multiline texts |
| 17:30 |
Wuzzy |
ok, and when? After 80 chars or so? |
| 17:30 |
RealBadAngel |
just use /n |
| 17:30 |
Wuzzy |
yes, sure |
| 17:30 |
est31 |
lag is most times > 1 second |
| 17:30 |
Wuzzy |
Would be a line break after 80 chars ok for you? |
| 17:31 |
RealBadAngel |
Wuzzy, its not automatic, you decide when to break the line |
| 17:31 |
Wuzzy |
That's what I am saying ... |
| 17:31 |
RealBadAngel |
btw, youre going to put book chapters in tooltips or what? ;) |
| 17:32 |
est31 |
yes |
| 17:32 |
RealBadAngel |
est, so what timings you got? |
| 17:33 |
est31 |
all < 50 |
| 17:33 |
est31 |
enough to make me satisfied :) |
| 17:33 |
VanessaE |
that's still rather slower than mine |
| 17:33 |
RealBadAngel |
thats acceptable |
| 17:34 |
RealBadAngel |
est31, now change scan height to 128 |
| 17:34 |
VanessaE |
est31: what else you got on that box? |
| 17:34 |
VanessaE |
(that could impact your speed) |
| 17:34 |
est31 |
onboard gfx |
| 17:34 |
RealBadAngel |
indeed, thats 2x slower than the very same cpu |
| 17:34 |
RealBadAngel |
est31, for that gpu doesnt count at all |
| 17:35 |
est31 |
RealBadAngel, with < 50 I can also mean average of 10 |
| 17:35 |
RealBadAngel |
copy like 500 lines for me |
| 17:35 |
RealBadAngel |
i will get an average |
| 17:36 |
RealBadAngel |
TeTpaAka, btw, thx for solving the issue :) |
| 17:36 |
est31 |
http://pastebin.com/n5VZW97V |
| 17:36 |
TeTpaAka |
No Problem. It was VanessaEs hint that made me think of the build type. |
| 17:36 |
RealBadAngel |
otherwise we could be sitting whole day lookin for solution lol |
| 17:36 |
est31 |
so the main problem is now that there is occasional, but larger lag |
| 17:36 |
est31 |
> 1 second |
| 17:36 |
est31 |
at least all 10 seconds once |
| 17:36 |
est31 |
and it doesnt show up in those stats |
| 17:37 |
VanessaE |
est31: this sounds like the main mesh thread lag I get from time to time |
| 17:37 |
VanessaE |
the whole thing just.... stalls... for about one second, not really sure what the pattern is |
| 17:37 |
VanessaE |
(most noticable with HDX, but I've seen it happen with defaults too) |
| 17:38 |
RealBadAngel |
39ms average |
| 17:38 |
RealBadAngel |
that should be enough for 25fps minimap |
| 17:40 |
RealBadAngel |
est31, can you check times with scan height set to 128? |
| 17:40 |
RealBadAngel |
im thinkin on makin a setting for that, for slower boxes |
| 17:41 |
VanessaE |
what you should be doing here is timing how long each map update takes and auto-tuning the scan height accordingly. |
| 17:41 |
RealBadAngel |
no |
| 17:41 |
RealBadAngel |
scan time will highly depend on terrain |
| 17:42 |
VanessaE |
hence auto-tuning |
| 17:42 |
VanessaE |
if it can be done (poorly) with the in-game terrain, it can be done with the minimap as well |
| 17:42 |
RealBadAngel |
that would make things appear and dissapear without reason |
| 17:42 |
est31 |
ok, can I merge the 100% CPU away commit now? |
| 17:43 |
VanessaE |
not if you apply a bit of slop to the rate at which it tunes. |
| 17:43 |
RealBadAngel |
you have my +1, one more is needed |
| 17:43 |
est31 |
its an early hotfix for a more proper solution |
| 17:43 |
est31 |
why one more? |
| 17:43 |
est31 |
thats three core maintainers needed or what? |
| 17:44 |
RealBadAngel |
i thought 2 apart from author |
| 17:44 |
RealBadAngel |
but anyway its bugfix |
| 17:44 |
VanessaE |
for a regular patch I understood it to require two +1's from other devs, but for a quick bugfix I guess that requirement is relaxed somewhat. |
| 17:45 |
est31 |
pushed |
| 17:45 |
RealBadAngel |
also please do mention in the issue you created that most regression was caused by debug build :) |
| 17:46 |
RealBadAngel |
and please let me know how 128 scan height works for you |
| 17:46 |
RealBadAngel |
i would like to know its worth to make a setting for that |
| 17:47 |
est31 |
yes it works but not that large speedup |
| 17:47 |
RealBadAngel |
the timings? |
| 17:48 |
est31 |
yes |
| 17:48 |
RealBadAngel |
btw, nice mod imho, gonna try it now: https://github.com/technomancy/calandria |
| 17:53 |
RealBadAngel |
est31, i will code now the cosmetic changes, like m_ name problem and a setting for height so we can have minimap issues closed for now |
| 17:53 |
RealBadAngel |
then since we could check VBO patch, wanna try? |
| 17:53 |
VanessaE |
ooo gimme |
| 17:53 |
est31 |
VBO? |
| 17:54 |
Calinou |
Vertex Buffer Objects |
| 17:54 |
Calinou |
makes for faster jungles |
| 17:54 |
RealBadAngel |
not only jungles |
| 17:54 |
VanessaE |
est31: keeps meshes on the GPU instead of continuously streaming them |
| 17:54 |
RealBadAngel |
lotsa of vertices in general |
| 17:54 |
est31 |
nice |
| 17:54 |
est31 |
but today, I'm out |
| 17:54 |
RealBadAngel |
that alone doubles fps in most cases |
| 17:54 |
est31 |
bye |
| 17:55 |
RealBadAngel |
:P |
| 17:55 |
VanessaE |
RealBadAngel: have you figured out a good algorithm for discarding obsolete meshes? |
| 17:56 |
RealBadAngel |
what for? removing them from hardware buffers? |
| 17:56 |
VanessaE |
because if you don't discard obsolete meshes with VBO running, you'll run out of memory. |
| 17:56 |
RealBadAngel |
it doesnt work that way |
| 17:56 |
VanessaE |
it did before. |
| 17:57 |
VanessaE |
that's precisely why the old VBO patch never got merged |
| 17:57 |
RealBadAngel |
simply if you no longer need the mesh you shall flush it from the buffer manually |
| 17:57 |
VanessaE |
that's my point |
| 17:57 |
RealBadAngel |
either by checkin when it was last time used |
| 17:57 |
VanessaE |
have you worked out when to flush? :) |
| 17:57 |
VanessaE |
that's what I thought |
| 17:57 |
RealBadAngel |
yes |
| 17:57 |
VanessaE |
a mesh that's more than ~ 5 mins old is probably old enough to flush |
| 17:57 |
RealBadAngel |
i do delete the mesh when block got unloaded |
| 17:58 |
VanessaE |
that may be too long |
| 17:58 |
VanessaE |
an active client can have thousands of loaded blocks. |
| 17:58 |
RealBadAngel |
circa 1k |
| 17:58 |
VanessaE |
I've seen it go somewhat higher than that in the distant past |
| 17:58 |
VanessaE |
around 1800 if memory serves |
| 17:58 |
RealBadAngel |
depends |
| 17:59 |
RealBadAngel |
lets say no more than 2k |
| 17:59 |
VanessaE |
how much will 2K of VBO-side meshes need? |
| 17:59 |
RealBadAngel |
no idea and no way to check it |
| 17:59 |
RealBadAngel |
irrlicht does that, its not our business |
| 17:59 |
VanessaE |
well how big is a raw minetest mesh, at worst case? |
| 18:00 |
VanessaE |
worst case I can think of is an entire 16^3 mapblock full of homedecor wine racks |
| 18:00 |
RealBadAngel |
irrlicht tries to send it to VRAM, if it fails it keep using RAM one |
| 18:00 |
RealBadAngel |
so telling irrlicht to use VBO is just a hint |
| 18:00 |
RealBadAngel |
not a directive |
| 18:00 |
VanessaE |
right |
| 18:01 |
VanessaE |
I think before, the patch was actually doing the VBO stuff somewhat more.. "manually". |
| 18:01 |
|
red-001 joined #minetest-dev |
| 18:01 |
RealBadAngel |
hint is even in the name that turns it on |
| 18:02 |
RealBadAngel |
setHardwareMappingHint(scene::EHM_STATIC); |
| 18:02 |
red-001 |
how can I get connected players in c++ |
| 18:02 |
VanessaE |
heh |
| 18:07 |
Krock |
Has anyone noticed the special character issue? A commit about converting strings or using them in formspecs remove öäü-like characters now |
| 18:07 |
Krock |
*removes |
| 18:08 |
red-001 |
anyone? |
| 18:11 |
Krock |
yes, anyone? |
| 18:12 |
Krock |
red-001, what do you plan to do? |
| 18:14 |
VanessaE |
red-001: |
| 18:14 |
VanessaE |
oops |
| 18:14 |
VanessaE |
RealBadAngel: https://github.com/freeminer/freeminer/commit/d4a711869ff339724136e4059db799e19ef956e3 |
| 18:15 |
VanessaE |
there's PilzAdam's VBO patch as added to fm. |
| 18:15 |
VanessaE |
(the repo that originally contained it has since been deleted) |
| 18:15 |
RealBadAngel |
yes, with all the flaws |
| 18:15 |
RealBadAngel |
you can find the patch in kahrl's and SN's repos |
| 18:16 |
VanessaE |
and this old comment from the related thread: https://forum.minetest.net/viewtopic.php?p=102847#p102847 |
| 18:16 |
VanessaE |
summary: VBO plus a shader tweak doubled my fps at the time. |
| 18:17 |
VanessaE |
(I'm sure the shader tweak no longer applies) |
| 18:19 |
RealBadAngel |
its here |
| 18:19 |
VanessaE |
right, I notice you wrote about that in a later post. |
| 18:19 |
VanessaE |
point was to make sure the old VBO patch is still kept in mind |
| 18:37 |
RealBadAngel |
#2848 |
| 18:37 |
ShadowBot |
https://github.com/minetest/minetest/issues/2848 -- Minimap update by RealBadAngel |
| 18:37 |
RealBadAngel |
ok, im done with it, now will make PR for VBO |
| 18:41 |
|
asl97 joined #minetest-dev |
| 18:49 |
VanessaE |
RealBadAngel: meanwhile, see your /msgs |
| 19:21 |
RealBadAngel |
hmmmm, here? |
| 19:29 |
|
zat joined #minetest-dev |
| 19:31 |
|
ElectronLibre joined #minetest-dev |
| 19:58 |
|
Gethiox left #minetest-dev |
| 20:07 |
|
Darcidride joined #minetest-dev |
| 20:09 |
|
Darcidride_ joined #minetest-dev |
| 20:28 |
|
neoascetic joined #minetest-dev |
| 20:29 |
neoascetic |
Hi all. I want to track all map changes (including by players and by mods, abms etc). Is this possible? I mean, maybe some debugging level, or any other way |
| 20:30 |
Krock |
minetest.register_on_placenode() |
| 20:30 |
Krock |
minetest.register_on_dignode() |
| 20:30 |
neoascetic |
Great, what with ABMs? |
| 20:31 |
neoascetic |
I tried to use Redis' pub/sub but it doesn't give me a block id and data beign modified |
| 20:32 |
|
asl joined #minetest-dev |
| 20:32 |
neoascetic |
Ok, it seems I may patch "register_abm" and sniff all action changes... is there a better way? |
| 20:48 |
|
Lunatrius joined #minetest-dev |
| 21:12 |
|
selat joined #minetest-dev |
| 21:18 |
asl97 |
abm using dig/place should trigger the function registed using register.on_placenode and rgister.on_dignode |
| 21:19 |
asl97 |
oh wait, left already :| |
| 21:25 |
daswort |
when was the fsaa option introduced? |
| 21:26 |
asl97 |
Apr 3, 2012 |
| 21:26 |
asl97 |
https://github.com/minetest/minetest/blame/master/minetest.conf.example |
| 21:26 |
asl97 |
https://github.com/minetest/minetest/commit/e8e73d37fb1834208dabac207593030b87db135a |
| 21:27 |
asl97 |
you can easily find out when something has been added/change using the blame feature on github |
| 21:31 |
daswort |
thx, but why isn't there a gui switch if it is present for so long? |
| 21:32 |
daswort |
*for fsaa |
| 21:32 |
asl97 |
because it still Experimental? |
| 21:34 |
daswort |
Ah thx again |
| 21:34 |
asl97 |
idk |
| 21:37 |
|
neoascetic joined #minetest-dev |
| 22:00 |
|
chchjesus joined #minetest-dev |
| 22:01 |
|
SudoAptGetPlay joined #minetest-dev |
| 22:14 |
|
chchjesus joined #minetest-dev |
| 23:25 |
|
prozacgod joined #minetest-dev |
| 23:51 |
|
proller joined #minetest-dev |
