| Time |
Nick |
Message |
| 00:30 |
|
doserj joined #minetest-dev |
| 01:18 |
|
ShadowNinja joined #minetest-dev |
| 01:53 |
hmmmm |
ah, i see you've already dealt with this problem to an extent before... hence BlockGenerationStatus |
| 02:15 |
|
doserj joined #minetest-dev |
| 02:36 |
|
doserj joined #minetest-dev |
| 02:57 |
|
iqualfragile joined #minetest-dev |
| 02:58 |
thexyz |
http://irc.minetest.ru/minetest/2013-02-16#i_2876764 + http://irc.minetest.ru/minetest/2013-02-17#i_2876870 |
| 02:58 |
thexyz |
crap! |
| 03:03 |
|
doserj joined #minetest-dev |
| 03:24 |
hmmmm |
is it just me, or does a lot of map.cpp seem to just repeat itself over and over and over and over |
| 03:24 |
hmmmm |
500 functions that do the same thing |
| 03:31 |
hmmmm |
anyway i came up with a clean, decent idea. in MapVoxelManipulator::emerge and ManualMapVoxelManipulator::initialEmerge, I have it set a flag if 1). the block data exists and 2). the first node of the data is CONTENT_IGNORE. i'll call this flag VMANIP_BLOCK_CONTAINS_CIGNORE or something, and i'll make block_data_inexistant into VMANIP_BLOCK_DATA_INEXIST. so m_loaded_blocks will have a u8 or something as the value instead of a bool. |
| 03:31 |
hmmmm |
i don't have to change *too* much around for this |
| 03:32 |
hmmmm |
then, in initBlockMake, after vmanip's initialEmerge(), I go through blockpos_min and blockpos_max and manually reset the VMANIP_BLOCK_CONTAINS_CIGNORE flag, leaving the border blocks the only ones that can possibly have it set |
| 03:32 |
hmmmm |
then in the vmanip blitBack and blitBackAll, I skip over blitting the block back if VMANIP_BLOCK_CONTAINS_CIGNORE is set |
| 03:33 |
hmmmm |
actually, i can't see a reason why anybody would need to know this aside from celeron.. |
| 05:08 |
|
BackupCoder joined #minetest-dev |
| 06:48 |
hmmmm |
https://github.com/kwolekr/minetest/commit/98f9d8128462808c3d65fd656bb15ede6d50b394 |
| 07:28 |
|
SpeedProg joined #minetest-dev |
| 07:41 |
RealBadAngel |
damn, solved problem flipping textures on X :) |
| 07:42 |
RealBadAngel |
its good to take a nap and come back to the problem next morning hehe |
| 07:49 |
RealBadAngel |
hmmmm, you have to define how many threads will be used? |
| 07:49 |
hmmmm |
clearly not.. see line 59 of emerge.cpp |
| 07:51 |
RealBadAngel |
so whats that for? settings->setDefault("num_emerge_threads", ""); |
| 07:51 |
hmmmm |
all settings need to be set to a default, if you don't it'll throw an exception and crash when you try to access it and it's not in minetest.conf |
| 07:52 |
hmmmm |
that field is blank instead of a number so that i can see if it was set or not with .empty() |
| 07:53 |
RealBadAngel |
so, nr of threads depends of how many cpus you have |
| 07:53 |
hmmmm |
unless you explicitly set it otherwise |
| 07:54 |
RealBadAngel |
if i do have dual core and set it to 4? |
| 07:54 |
RealBadAngel |
it gonna explode? ;) |
| 07:55 |
hmmmm |
actually with the other default settings, no, you won't notice a difference at all. you need to increase emergequeue_limit_generate and emergequeue_limit_diskonly to actually take advantage of it |
| 07:55 |
hmmmm |
i'll do that in a bit |
| 07:56 |
hmmmm |
i need to dynamically set those values based on how many threads there are too |
| 08:02 |
|
ecube joined #minetest-dev |
| 08:43 |
RealBadAngel |
https://github.com/RealBadAngel/minetest/commit/43496b0d90180742ffa38d52ec0ffedb09d14074 |
| 08:43 |
RealBadAngel |
6d facedir for meshes is ready |
| 08:43 |
RealBadAngel |
now need to rotate just nodeboxes |
| 08:48 |
|
EdB joined #minetest-dev |
| 09:36 |
|
Calinou joined #minetest-dev |
| 10:01 |
|
ffoxin joined #minetest-dev |
| 10:27 |
RealBadAngel |
http://forum.minetest.net/viewtopic.php?pid=70867 |
| 10:28 |
RealBadAngel |
some info and tools to test 6d facedir |
| 10:46 |
|
jin_xi joined #minetest-dev |
| 10:47 |
|
PilzAdam joined #minetest-dev |
| 11:40 |
|
Jordach joined #minetest-dev |
| 11:40 |
|
Jordach joined #minetest-dev |
| 12:32 |
|
kahrl joined #minetest-dev |
| 12:57 |
RealBadAngel |
ive updated my git with 6d facedir rotations for nodeboxes also |
| 12:57 |
RealBadAngel |
need to fix the old bug with need for coords to be sorted |
| 12:59 |
RealBadAngel |
also screwdriver is updated, pick the face, first use will bring there top of the node, next uses will rotate node |
| 12:59 |
|
EdB joined #minetest-dev |
| 13:00 |
RealBadAngel |
extremely easy now to place pistons or rotate stairs+ nodes |
| 13:10 |
|
rubenwardy joined #minetest-dev |
| 14:04 |
|
Taoki joined #minetest-dev |
| 15:23 |
|
troller joined #minetest-dev |
| 15:33 |
|
EdB joined #minetest-dev |
| 15:46 |
|
hmmmm joined #minetest-dev |
| 15:47 |
|
Exio joined #minetest-dev |
| 16:13 |
|
rubenwardy joined #minetest-dev |
| 16:19 |
|
EdB joined #minetest-dev |
| 16:28 |
hmmmm |
how intensive is MeshGenerationThread? |
| 16:29 |
hmmmm |
i'll ask the real question... if you can choose two non-emerge threads in particular to tie down to a specific core, which would they be? for the client? for the server only? |
| 16:34 |
VanessaE |
depends. what's the benefit of locking a thread to a specific core? |
| 16:34 |
VanessaE |
aside from core-to-core migration latency |
| 16:34 |
hmmmm |
cache coherency |
| 16:34 |
VanessaE |
hm |
| 16:36 |
VanessaE |
dunno, I can't really think of anything that would have a net benefit |
| 16:37 |
VanessaE |
I mean, the rendering code certainly, but then if you go multithreaded with that, then fat lotta good that does |
| 16:37 |
hmmmm |
woah, i did not go that far. |
| 16:37 |
VanessaE |
heh |
| 16:38 |
VanessaE |
"if you go" = "if some day months-to-years down the line, you go..." |
| 16:38 |
VanessaE |
etc. |
| 16:39 |
VanessaE |
two non-emerge threads.. |
| 16:39 |
VanessaE |
well networking and sound don't really need much, what about those? |
| 16:40 |
hmmmm |
those would be examples of things that i wouldn't bind |
| 16:41 |
VanessaE |
no idea then |
| 17:05 |
|
mrtux joined #minetest-dev |
| 17:12 |
|
mrtux joined #minetest-dev |
| 17:15 |
|
Calinou joined #minetest-dev |
| 17:47 |
|
ecube joined #minetest-dev |
| 18:08 |
hmmmm |
hmm |
| 18:09 |
hmmmm |
on windows systems, if minetest is being run in single player mode, i want the emergethreads to have PROCESS_MODE_BACKGROUND_BEGIN priority |
| 18:10 |
hmmmm |
or should i just have it BELOW_NORMAL_PRIORITY_CLASS |
| 18:10 |
hmmmm |
when in doubt leave it up to the user, with a sane default :)? |
| 18:11 |
hmmmm |
indeed, it shouldn't have a background priority since that would cause a priority inversion thanks to the envlocks |
| 18:12 |
hmmmm |
unless i were to set it in between the makeChunk calls |
| 18:13 |
|
Calinou joined #minetest-dev |
| 18:19 |
|
ffoxin joined #minetest-dev |
| 18:20 |
|
doserj joined #minetest-dev |
| 18:23 |
|
Calinou joined #minetest-dev |
| 20:24 |
thexyz |
any thoughts on this https://github.com/xyzz/minetest-stress/blob/master/examples/simple/init.lua ? |
| 20:24 |
thexyz |
jquery-like syntax for minetest modding api |
| 20:30 |
troller |
https://github.com/celeron55/minetest/pull/492 - ready for merge! |
| 20:30 |
troller |
http://servers.minetest.net/ up |
| 20:32 |
|
SpeedProg1 joined #minetest-dev |
| 21:26 |
|
pierreghz joined #minetest-dev |
| 22:02 |
|
doserj left #minetest-dev |
| 22:03 |
|
doserj joined #minetest-dev |
| 23:29 |
|
sapier joined #minetest-dev |
| 23:32 |
sapier |
https://github.com/sapier/minetest/commit/03d3af485eb36e75ca316e89a6969481efa692aa |
| 23:32 |
VanessaE |
hmmmm: in singleplayer, anything that directly faces the user should have absolute priority over that which does not - so the rendering thread(s) could be pushed up along with the code that communicates regarding your look direction and position back and forth to the server. Then the rest of the server can be basically back-burnered. |
| 23:32 |
sapier |
this is security hardening patch preserving full API compatibility to builtin io and os functions |
| 23:32 |
hmmmm |
that's a little too complicated vanessa |
| 23:32 |
VanessaE |
that should do a lot to stop the occasional hangs and lags in the client side that happen when the singleplayer server gets slow |
| 23:32 |
sapier |
at least for those functions not considered harmfull and disabled |
| 23:33 |
VanessaE |
well I guess it would be, but that's just how I'd do it if I were writing this from scratch |
| 23:34 |
sapier |
isn't everything within players view already priorized above other nodes/blocks? |
| 23:41 |
hmmmm |
yes, it's sorted in terms of distance from the player |
| 23:42 |
hmmmm |
if the block isn't within the player's sight, it doesn't get selected for sending at all |
