| Time |
Nick |
Message |
| 02:06 |
deivid |
anyone here? |
| 02:18 |
RealBadAngel |
whats up? |
| 02:23 |
deivid |
I'm trying to make the blocks draw partially based on distance, but I don't know how to do it, currently the renderMap gets all the meshes from the block and draws them |
| 02:23 |
deivid |
s/blocks/nodes |
| 02:23 |
RealBadAngel |
theres a bit of code called farmesh |
| 02:24 |
RealBadAngel |
maybe you should look for it |
| 02:24 |
deivid |
thanks |
| 02:25 |
RealBadAngel |
it was supposed to do somethin like you mentioned but im not sure of its state right now |
| 02:25 |
|
VanessaE joined #minetest-dev |
| 02:25 |
RealBadAngel |
wb VanessaE |
| 02:25 |
VanessaE |
thanks. |
| 02:54 |
hmmmm |
hey vanessa, have you been looking at my branch at all? |
| 02:55 |
hmmmm |
i need real-world testing |
| 02:55 |
hmmmm |
lots of it |
| 02:55 |
hmmmm |
specifically, single player |
| 02:56 |
VanessaE |
I've been waiting for you to tell me to try it :-) |
| 02:57 |
VanessaE |
didn't want to pester you about it |
| 02:57 |
hmmmm |
oh.. |
| 02:57 |
hmmmm |
sorry |
| 02:57 |
hmmmm |
you see, i'm having a pretty big problem i've been unable to resolve |
| 02:57 |
VanessaE |
oh? |
| 02:58 |
hmmmm |
and i don't think there's a solution at all for it |
| 02:58 |
hmmmm |
so i need to see if people think it's actually a problem or not |
| 02:58 |
hmmmm |
or maybe it's just i see a problem with hyperthreading |
| 02:58 |
hmmmm |
it's just that i* |
| 02:59 |
VanessaE |
does it matter if I'm using minimal? |
| 03:00 |
hmmmm |
not at all |
| 03:00 |
VanessaE |
ok, it's up, in singleplayer mode, with a new map |
| 03:00 |
hmmmm |
wait wait |
| 03:00 |
hmmmm |
gotta change some configuration settings.... |
| 03:00 |
* VanessaE |
waits |
| 03:00 |
VanessaE |
ok, shoot |
| 03:00 |
hmmmm |
first off, set num_emerge_threads = 4, then emergequeue_limit_generate = 4, emergequeue_limit_diskonly = 20 |
| 03:01 |
VanessaE |
ok, done |
| 03:01 |
hmmmm |
so tell me with those settings, if singleplayer is too choppy |
| 03:02 |
hmmmm |
and by choppy i don't mean the block loading really, i mean the responsiveness of the gameplay |
| 03:02 |
VanessaE |
it seems respectable at this setting actually. |
| 03:02 |
VanessaE |
an occasional frame hiccup, but I've always seen those every so often |
| 03:02 |
VanessaE |
nothing I'd call "choppy" by a long stretch |
| 03:02 |
hmmmm |
ever since 0.4.4, anyway :p |
| 03:03 |
hmmmm |
okay, you sure about that? |
| 03:03 |
VanessaE |
lemme test more |
| 03:03 |
hmmmm |
then it must be because of my hyperthreading |
| 03:04 |
VanessaE |
well, there is a weird glitch when I jump, but it might be an optical illusion. |
| 03:04 |
hmmmm |
jump? not related to my stuff |
| 03:04 |
VanessaE |
movement seems... mm, ... sharp? |
| 03:04 |
VanessaE |
but no, it seems smooth enough to me |
| 03:06 |
hmmmm |
when sapier asked you to try out his fix for the hangups, you had to run minetestserver as root, right? |
| 03:06 |
VanessaE |
nope, I was running it as a normal user, as always |
| 03:06 |
VanessaE |
same here |
| 03:06 |
hmmmm |
really? |
| 03:06 |
VanessaE |
yup, I never run things as root unless I have to |
| 03:06 |
hmmmm |
if that's the case, then it was a placebo |
| 03:06 |
VanessaE |
heh, one hell of a placebo then :-) |
| 03:07 |
VanessaE |
still, it was only a marginal effect |
| 03:07 |
hmmmm |
under Linux, thread priorities have no effect unless it uses a real-time scheduling policy, and you need to be root in order to switch to a real-time scheduling policy |
| 03:08 |
VanessaE |
bit of mapgen lag there (new terrain) |
| 03:09 |
hmmmm |
if that's all, then that's fine... what i'm concerned is stuttering in the rendering |
| 03:09 |
VanessaE |
naw, the rendering quality seems good |
| 03:09 |
VanessaE |
certainly no regression that I can see |
| 03:10 |
VanessaE |
in fact, you know...I'm starting to wonder if this is maybe a little smoother than I'm used to |
| 03:10 |
VanessaE |
lemme torture it a little --> HDX |
| 03:10 |
hmmmm |
what's HDX? |
| 03:10 |
VanessaE |
my HD texture pack |
| 03:10 |
hmmmm |
oh |
| 03:11 |
VanessaE |
there's a slight stutter |
| 03:11 |
VanessaE |
nothing serious |
| 03:11 |
VanessaE |
not enough to worry about anyway |
| 03:11 |
hmmmm |
alright |
| 03:12 |
VanessaE |
I'd put it at "bottom of the To-do list: tune rendering smoothness" |
| 03:12 |
VanessaE |
as in, practically lowest priority |
| 03:13 |
* VanessaE |
turns on some extra gfx settings |
| 03:13 |
hmmmm |
i just want to make sure it's perfect |
| 03:14 |
VanessaE |
oops |
| 03:14 |
VanessaE |
got it to dump core |
| 03:14 |
VanessaE |
http://pastebin.com/Pu1Tv2Pb |
| 03:15 |
VanessaE |
started a new map after installing minetest_game and turning on my usual settings. |
| 03:15 |
VanessaE |
hm, it didn't actually generate a core file though |
| 03:15 |
VanessaE |
*shrug* |
| 03:16 |
hmmmm |
hm |
| 03:16 |
hmmmm |
now why doesn't it say which thread made it crash |
| 03:16 |
hmmmm |
oh i'm just blind |
| 03:16 |
VanessaE |
lol |
| 03:17 |
hmmmm |
yeah i dunno, the mesh update thread is totally not my area |
| 03:17 |
VanessaE |
unrelated glitch then |
| 03:17 |
hmmmm |
i don't know anything about it, and i'm totally unfamiliar with that code |
| 03:17 |
VanessaE |
there we go |
| 03:17 |
VanessaE |
256px HDX, minetest_game, with all my usual settings |
| 03:17 |
hmmmm |
doesn't have anything to do with the textures |
| 03:18 |
hmmmm |
it just generates the mesh |
| 03:18 |
VanessaE |
well no, but bigger textures will slow the video card down some, which would make any stuttering perhaps a little more apparent. Still, it seems perfectly acceptable |
| 03:18 |
hmmmm |
would you have any problem with this being merged to master? |
| 03:19 |
VanessaE |
so far it seems reasonable to me; perhaps I should deploy this on the server for a while maybe? |
| 03:19 |
hmmmm |
well, sure if you'd like, i'm not really concerned about that though |
| 03:19 |
hmmmm |
i'm mostly concerned with single player stuttering, which doesn't seem to be bad |
| 03:20 |
VanessaE |
woof! look at those cores go |
| 03:20 |
hmmmm |
oh yeah |
| 03:20 |
VanessaE |
this is able to max out four of 6, plus 50% of the other two |
| 03:20 |
hmmmm |
you might want to crank it down to 3 cores or something, since you do other things on your computer while you host that |
| 03:21 |
VanessaE |
this is smooth as cotton (not quite silk ;-) ) |
| 03:21 |
VanessaE |
roll it out. |
| 03:21 |
hmmmm |
well i've gotta ask more people |
| 03:21 |
hmmmm |
i mean i don't want to screw things up |
| 03:21 |
VanessaE |
right, that's fair |
| 03:22 |
VanessaE |
in that case, let's just say "no, I see no problem with merging it to master" then. |
| 03:23 |
VanessaE |
hm, a little stutter there, probably frequency scaling lag |
| 03:26 |
RealBadAngel |
hey hmmm |
| 03:26 |
RealBadAngel |
im testing it too and noticed a glitch |
| 03:26 |
hmmmm |
what's that |
| 03:27 |
RealBadAngel |
hold on for screenshot |
| 03:27 |
VanessaE |
huh. <offtopic> interesting cavegen bug. Bunch of caves cut off abruptly at z=-672.5 </offtopic> |
| 03:27 |
hmmmm |
agh the cut-off cave bug is what you're talkign about RBA? |
| 03:29 |
VanessaE |
http://digitalaudioconcepts.com/vanessa/hobbies/minetest/screenshots/screenshot_4207625953.png |
| 03:29 |
VanessaE |
in case you were wondering. |
| 03:29 |
hmmmm |
i know |
| 03:29 |
hmmmm |
that's caused by my fix for the CONTENT_IGNORE blocks |
| 03:30 |
VanessaE |
anywho, I think we're good from the standpoint of your latest updates. |
| 03:30 |
hmmmm |
with one emergethread this wasn't a problem |
| 03:30 |
RealBadAngel |
http://i.imgur.com/8NtVY4Q.jpg |
| 03:30 |
hmmmm |
woah. |
| 03:30 |
VanessaE |
RealBadAngel: shame on you for using jpg for screenshots :-) |
| 03:30 |
hmmmm |
now that is a problem |
| 03:30 |
VanessaE |
hmmmm: I see than with the current upstream mapgen from time to time also, though usually it's a horizontal cut, not vertical |
| 03:30 |
RealBadAngel |
tree is cut like on mapblock border |
| 03:30 |
hmmmm |
it is |
| 03:31 |
VanessaE |
the top of a moretrees tree may fail to appear when spawning from a planted sapling, f.ex |
| 03:31 |
VanessaE |
that* |
| 03:31 |
|
VanessaE left #minetest-dev |
| 03:32 |
|
VanessaE joined #minetest-dev |
| 03:32 |
VanessaE |
oops/ |
| 03:33 |
VanessaE |
whoa. New problem |
| 03:34 |
VanessaE |
we don't care about map loader/mapgen lag at all? got a sudden, extreme spike here while the game was minimized to handle that screenshot - it's still stuck. |
| 03:34 |
VanessaE |
one core is maxed, but the game's responding otherwise. /status, movement, etc. |
| 03:34 |
hmmmm |
hmmm |
| 03:35 |
VanessaE |
no mods - just minetest_game |
| 03:35 |
hmmmm |
i think i've seen something like that before |
| 03:35 |
hmmmm |
it un-freezes though |
| 03:35 |
hmmmm |
i need a good way to dump the current status of the queues |
| 03:35 |
VanessaE |
oh no. |
| 03:35 |
RealBadAngel |
i must say game is workin way faster imho |
| 03:36 |
VanessaE |
are we pushing into tens of thousands again? :-) |
| 03:36 |
hmmmm |
no |
| 03:36 |
VanessaE |
hah ok |
| 03:36 |
hmmmm |
more like the 3s or the 4s |
| 03:36 |
RealBadAngel |
got 25fps with max view distance |
| 03:37 |
VanessaE |
oh fuck |
| 03:37 |
VanessaE |
camera update got turned off. |
| 03:37 |
hmmmm |
haha.. |
| 03:38 |
VanessaE |
(how? I didn't hit that key?) |
| 03:38 |
hmmmm |
it's good to know that's not my problem :P! |
| 03:38 |
VanessaE |
lol |
| 03:38 |
hmmmm |
i still think it's a good idea to have a way to reset queues manually perhaps.. |
| 03:39 |
RealBadAngel |
well |
| 03:39 |
RealBadAngel |
and it is starting in no time with preloaded items visuals |
| 03:39 |
VanessaE |
that said, it is starting to lag a little, but no appreciable effect on FPS (as if that were likely anyway) |
| 03:40 |
RealBadAngel |
wow |
| 03:40 |
RealBadAngel |
2-3s to launch the game |
| 03:41 |
RealBadAngel |
shit |
| 03:41 |
RealBadAngel |
i had this off, sorry :) |
| 03:42 |
VanessaE |
let's see what happens when I put moretrees on this now. |
| 03:42 |
hmmmm |
hrmm |
| 03:43 |
hmmmm |
well the client rendering thread isn't stuttering as much as i expected |
| 03:43 |
hmmmm |
but i definitely need to fix the caves/trees getting cut off |
| 03:43 |
VanessaE |
hoo... this is decidedly more laggy than before |
| 03:45 |
VanessaE |
one core spiked (client/rendering), with occasional spikes of 3 or more cores right when the generated world appears |
| 03:46 |
hmmmm |
sounds normal enough |
| 03:46 |
VanessaE |
but it's taking several seconds at a time without any appreciable CPU usage, then huge CPU spikes as the new land appears |
| 03:46 |
hmmmm |
hmm |
| 03:47 |
hmmmm |
okay, thanks. i'll figure something out |
| 03:48 |
VanessaE |
lemme guess, that locking issue again? |
| 03:48 |
hmmmm |
no, it's completely different |
| 03:48 |
VanessaE |
oh ok |
| 03:49 |
VanessaE |
this is new: |
| 03:49 |
VanessaE |
during those lags, the server isn't responding to commands |
| 03:49 |
VanessaE |
(usually it continues to respond even if the terrain is being withheld) |
| 03:51 |
hmmmm |
weird.. i have no explanation for that |
| 03:51 |
hmmmm |
what respond did you give it exactly? |
| 03:52 |
VanessaE |
/time 6000 |
| 03:52 |
VanessaE |
usually I just do /status, but it was getting dark, so.. |
| 03:52 |
VanessaE |
by "respond" I mean the server's talkback in the chat area, not the terrain/light level/etc |
| 04:29 |
|
thexyz joined #minetest-dev |
| 04:30 |
|
sfan5|OFF joined #minetest-dev |
| 04:32 |
|
TB`oFF|Vibe-X joined #minetest-dev |
| 04:40 |
hmmmm |
pfffffft.... race condition in the thread logging thing |
| 04:40 |
VanessaE |
oops! |
| 04:40 |
VanessaE |
haha |
| 04:42 |
hmmmm |
log_register_thread is also not threadsafe |
| 04:42 |
hmmmm |
i would like to avoid a mutex.. |
| 04:43 |
VanessaE |
I'm headed off to bed, I'll read/respond/test again when I return. |
| 04:43 |
VanessaE |
Night :-) |
| 04:54 |
|
ffoxin joined #minetest-dev |
| 04:54 |
deivid |
hmmm are you still here? |
| 04:54 |
hmmmm |
hello..? |
| 04:54 |
deivid |
hi |
| 04:55 |
deivid |
I'm going to start working on minetest, because I like the idea |
| 04:55 |
deivid |
I work as a programmer so I'm ready to start; should I just check the github issues? |
| 04:56 |
deivid |
I'm going to start with something simple until I get used to the structures/etc |
| 04:57 |
hmmmm |
a lot of the issues are either already being taken care of, or aren't really issues, or are really hard to fix the right way and the fixes that are offered are cruddy |
| 04:57 |
hmmmm |
like i guess you could start by doing that |
| 04:58 |
deivid |
uhm, ok |
| 05:00 |
hmmmm |
but don't be disappointed if you can't find anything that's decent to work on |
| 05:54 |
deivid |
I tested minetest on a window manager without reparenting (awesomewm) and it won't draw anything at all unless I minimize it and then restore it |
| 06:07 |
hmmmm |
sounds like an awesomewm problem or an Irrlicht problem... |
| 06:07 |
hmmmm |
either way, we can't fix that |
| 06:07 |
celeron55 |
F00: i agree with convenience over reality; i believe it's the all-around design principle in a game like this |
| 06:09 |
F00 |
I think perhaps the dev builds will allow for some more community feedback before 0.4.5 |
| 06:13 |
hmmmm |
celeron we need to talk about multiple mapvoxelmanipulators with overlapping areas of the map |
| 06:13 |
F00 |
My feeling is that hitting water should result in some sort of exponential decel, whereas climbable nodes should do the usual magic instant stop |
| 09:18 |
|
Calinou joined #minetest-dev |
| 09:43 |
|
jin_xi joined #minetest-dev |
| 10:40 |
|
darkrose joined #minetest-dev |
| 11:02 |
|
rubenwardy joined #minetest-dev |
| 11:04 |
|
SpeedProg joined #minetest-dev |
| 12:56 |
|
troller joined #minetest-dev |
| 13:28 |
|
troller joined #minetest-dev |
| 13:53 |
|
proller joined #minetest-dev |
| 14:10 |
|
hmmmm joined #minetest-dev |
| 14:27 |
|
rubenwardy joined #minetest-dev |
| 14:29 |
|
DpEpsilon joined #minetest-dev |
| 14:47 |
|
DpEpsilon joined #minetest-dev |
| 15:10 |
|
rubenwardy joined #minetest-dev |
| 15:11 |
|
Jontte joined #minetest-dev |
| 15:51 |
|
PilzAdam joined #minetest-dev |
| 16:09 |
|
Calinou joined #minetest-dev |
| 16:46 |
hmmmm |
sooo |
| 16:47 |
hmmmm |
looks like celeron never got back to me about that |
| 16:55 |
|
zeruel joined #minetest-dev |
| 17:00 |
|
david_asd joined #minetest-dev |
| 17:02 |
|
iqualfragile joined #minetest-dev |
| 17:08 |
|
troller joined #minetest-dev |
| 17:19 |
troller |
celeron55, https://github.com/celeron55/minetest/pull/492 |
| 17:26 |
|
rubenwardy joined #minetest-dev |
| 17:31 |
celeron55 |
hmmmm: i didn't bother saying anything as you went away |
| 17:31 |
hmmmm |
anyway do you have any ideas on how to handle that |
| 17:31 |
celeron55 |
troller: you don't need to touch it for now; it will be merged once somebody is unlazy enough |
| 17:31 |
celeron55 |
troller: remind after a week if that hasn't happened |
| 17:32 |
hmmmm |
i worked around the problem it causes but people are complaining about the side effects enough, so there needs to be some better way |
| 17:32 |
celeron55 |
what is the workaround? |
| 17:33 |
hmmmm |
if a block that came from initialEmerge was created 'blank' (filled with all CONTENT_IGNORE) and it is a border block, it won't be written in the blit back |
| 17:34 |
hmmmm |
the side effects of this are obviously going to be cut-off caves and trees |
| 17:35 |
celeron55 |
well, a good solution probably requires some kind of a merge strategy? |
| 17:35 |
hmmmm |
no, a good solution requires a mutex |
| 17:35 |
hmmmm |
but that's not a smart solution |
| 17:35 |
celeron55 |
you could disallow starting to generate a chunk adjacent to a chunk that is being generated |
| 17:36 |
celeron55 |
that will probably create large latencies in some cases |
| 17:36 |
hmmmm |
that's true, but it would complicate emergethread logic by a bit |
| 17:37 |
hmmmm |
plus there would still be a problem since the chunks being generated won't be close enough |
| 17:37 |
hmmmm |
if it's a checkerboard pattern of generation you'd still have two chunk borders sharing the same block |
| 17:38 |
celeron55 |
well, then there is the MC way |
| 17:38 |
celeron55 |
that will surely work |
| 17:38 |
hmmmm |
what is the MC way again? |
| 17:39 |
celeron55 |
except for content generated by mods, because there is no well established framework for them to generate the needed kinds of predictability |
| 17:40 |
celeron55 |
it generates chunks in parallel so that it over-generates every discrete thing in such an area that everything that might touch the chunk gets generated, and discards the parts that aren't relevant |
| 17:40 |
troller |
celeron55, squash it again? |
| 17:41 |
celeron55 |
troller: feel free to |
| 17:45 |
celeron55 |
this really is a hard problem 8) |
| 17:45 |
celeron55 |
and mojang once again isn't as dumb as people think |
| 17:47 |
celeron55 |
i think just merging the results so that "most interesting" things are preserved would work just fine |
| 17:48 |
celeron55 |
that is, trees and caves preferred over ground, and so |
| 17:48 |
celeron55 |
but it's pretty much up to whoever (=hmmmm) who implements it |
| 18:01 |
hmmmm |
i don't like mojang's idea, and i did consider keeping only the most interesting parts |
| 18:05 |
hmmmm |
so anyway here's what i was thinking |
| 18:05 |
hmmmm |
if a node is content_ignore, just don't write anything |
| 18:05 |
hmmmm |
leave it the way it is |
| 18:06 |
hmmmm |
the obvious downside to that is now we can't use memcpy |
| 18:13 |
hmmmm |
so you go to generate a chunk, you grab the borders, a couple of which are blank cignore blocks. you leave the envlock. another emergethread goes to grab blocks, it gets a blank block as well, your second thread finishes first and writes the terrain to the block, the first thread finishes and writes all of the nodes that are not content_ignore to that block |
| 18:14 |
hmmmm |
in the same manner, your terrain generator grabs a block that's mostly content_ignore but has some caves in it or whatever. it generates its terrain, then it goes to blit it back, but only overwrites the content_ignore nodes, leaving the caves that were generated intact |
| 18:17 |
hmmmm |
hmmmmmmmmmmmmmmmmmmmmmm... i'll just do this, and then when i go to finally add in the SSE noise things, i'll add in an SSE optimized version of this as well |
| 18:18 |
|
BackupCoder joined #minetest-dev |
| 18:18 |
celeron55 |
umm... |
| 18:18 |
celeron55 |
how are you going to handle air? |
| 18:19 |
hmmmm |
air is just as valid of a block i'd say |
| 18:19 |
celeron55 |
what about trees then? |
| 18:19 |
hmmmm |
trees are the same as caves |
| 18:19 |
celeron55 |
you didn't really solve anything as far as i can see, what you said is roughly what happens already |
| 18:20 |
celeron55 |
oh well whatever, i guess you'll figure it out |
| 18:20 |
hmmmm |
well the difference is that i do all of this in the blit back |
| 18:20 |
hmmmm |
so i'm comparing with the most recent version of the block |
| 18:21 |
celeron55 |
hmm, now i get it |
| 18:22 |
celeron55 |
umm... maybe |
| 18:22 |
hmmmm |
by the way, why did you do that stuff with the vmanip/mapblock "copyTo" and "copyFrom"? i found that confusing and verbose |
| 18:22 |
celeron55 |
dunno |
| 18:23 |
hmmmm |
and a lot of stuff in map.cpp is repetitive |
| 18:23 |
hmmmm |
i want to clean that up someday |
| 18:28 |
|
proller__ joined #minetest-dev |
| 18:49 |
|
doserj joined #minetest-dev |
| 19:12 |
|
rubenwardy1 joined #minetest-dev |
| 22:08 |
hmmmm |
hey if you're still around i need to ask you about the profiler things |
| 22:08 |
hmmmm |
what is the difference between add and avg |
| 22:17 |
|
Taoki joined #minetest-dev |
