Time Nick Message 00:00 celeron55 the compiler can't do that because CONTENT_AIR isn't 0 00:00 celeron55 change it to be 0 and it might 00:01 hmmmm speaking of that 00:01 hmmmm is there any specific reason why the default content for a MapNode is CONTENT_AIR? 00:01 hmmmm why not CONTENT_IGNORE? 00:01 celeron55 it seems a bit odd to me too 00:02 hmmmm more importantly... would the change break anything 00:02 celeron55 it probably has some API implications 00:02 Megaf Zeno`: ? Isnt it too late at your land now? 00:02 Zeno` "would the change break anything" is the main reason I avoided it 00:02 Megaf Hi celeron55, have you ever heard about this this? -> http://urho3d.github.io/ 00:02 hmmmm i want to change it so I don't have to reset the entire buffer to CONTENT_IGNORE when allocating a blank buffer 00:02 hmmmm lol 00:02 hmmmm Megaf you silly 00:03 celeron55 Megaf: what? buildat makes heavy use of that 00:03 hmmmm celeron is already 5000 steps ahead of you 00:03 celeron55 and i have even contributed fixes to urho3d 8D 00:03 Megaf celeron55: cool 00:03 Megaf so it might run well on Raspberry Pi 00:03 Zeno` hmmmm, I'm sure it's POD. The only way (in C98) that it's not POD is if you have virtual functions, non-POD members, your own copy constructor or your own destructor 00:03 Megaf kilbith: you could try buildat on your Raspberry Pi 00:03 celeron55 Megaf: most likely not at all 00:04 celeron55 but you can try 00:04 kilbith GLES seems better supported than Irrlicht 00:04 Megaf well, it it runs, we can try to make it better, if it doesnt, like minetest, then theres not much we can do about it 00:05 Zeno` oh, the constructor 00:05 Zeno` god c++ is hard sometimes 00:05 Zeno` An aggregate is an array or a class (clause 9) with no user-declared constructors (12.1), no private or protected non-static data members (clause 11), no base classes (clause 10), and no virtual functions (10.3). 00:05 Zeno` darn 00:05 * Megaf throws C++ The Bible at Zeno` 00:06 celeron55 Zeno`: hmmmm's previous point was that C++11 defines it differently and in it it can have a constructor 00:06 hmmmm we're supposed to be "good" and use std::copy() 00:06 Zeno` after 0.4.12 maybe I'll work on that whole struct... c55, yeah I know but that would imply dropping support for non C++11 targets 00:07 hmmmm problem is that now unless we use restrict everywhere it'll place memmove() instead 00:07 celeron55 Zeno`: my point is that C++03 compilers probably handle it like it was C++11 in practice 00:07 hmmmm relying on UB is disasterous 00:07 hmmmm please, don't advocate this 00:07 celeron55 maybe i shouldn't 8) 00:08 celeron55 speaking of this, what's the C++11 support status now in the compilers that we want to support 00:08 celeron55 debian stable has had gcc 4.7 for a while now so that's not an issue anymore 00:09 Zeno` ok, I'll mark the commit as WIP since it's too late for 0.4.11 anyway (it's not a feature). And then concentrate on the actual data type itself 00:09 hmmmm I agree 00:09 Megaf celeron55: 4.9 on the upcoming Debian 8 00:09 Megaf 4.9.1 00:09 celeron55 the remaining issue might be windows, depending on things 00:09 hmmmm the only reason why we're holding back on c++11 is because I'm a luddite and I don't update my operating system 00:09 hmmmm :/ 00:09 Zeno` Centos6.x does not have a C11 compliant compiler I don't think 00:09 hmmmm there are other reasons too though 00:09 celeron55 we don't officially support your OS so you're out of luck really 8) 00:09 Zeno` and Centos6 is a LTS 00:09 hmmmm what, FreeBSD 9.1? 00:10 hmmmm minetest officially supported freebsd for a while 00:10 celeron55 if it has a proper compiler, then yes 00:10 celeron55 otherwise no 00:10 hmmmm theoretically it supports freebsd to as far back as 5.x 00:11 Zeno` I also just realised why many servers have had stuck liquids since 0.4.10 00:11 hmmmm :\ 00:11 hmmmm because celeron was right and you were wrong 00:11 hmmmm but eh 00:11 hmmmm it seemed fine to me when i looked at it 00:11 Zeno` no I'm talking about servers before my change 00:12 hmmmm oh yeah, liquid transforming has always been broken it seems 00:12 hmmmm it's a sad state of affairs 00:12 Zeno` but it's related. That loop is limited (by iterations). If the server shuts down for whatever reason then that queue might still have 100000 or more items in it 00:12 kahrl there's a PR about that IIRC 00:13 Megaf I have never had problems with liquids 00:14 celeron55 hmmmm: but seriously, you can get a recent gcc or clang on freebsd, right? 00:15 hmmmm you can, but that complicates matters because that adds a build dependency 00:15 celeron55 when will that happen then? 00:15 hmmmm more dependencies are bad 00:15 celeron55 if practically never, then we might just as well go to C++11 now because it will happen some day anyway 00:16 celeron55 if one year from now, then waiting for it is possible while probably being a bad idea 00:16 hmmmm i'm sort of scared that people will start using the bad C++11 features 00:16 celeron55 you probably understand that C++11 makes development much more enjoyable and we have like 5 freebsd users 00:16 celeron55 i'm going to rage at them and kick them out if they do, don't worry about that 00:16 Zeno` I think that the UB in the case of 2000 is fine (ROFL). The constructor does nothing wanted anyway 00:17 hmmmm i think the UB is the object lifetime 00:17 hmmmm POD has different lifetimes than non-POD types 00:17 celeron55 the important question is whether our visual studio guys are ready for C++11 00:17 Zeno` Yeah because of the destructor though (AFAIK) 00:17 celeron55 that i do not know but would like to know 00:17 Zeno` But yeah, UB is bad 00:18 hmmmm visual studio 2008 is still widely used 00:18 hmmmm wow, haha, 2008 seems like it's so recent when in fact it happened almost 7 years ago now 00:18 Zeno` I know at least 2 server operators with VPSs that do not support C++11 00:18 celeron55 it really is ancient 00:18 Zeno` One is me :) 00:19 hmmmm I look forward to the relaxed PODness rules, move constructors, and std::unordered_map 00:20 celeron55 frankly there are so little reasons to not move to C++11 now compared to before that we should arrange that to happen in the upcoming months 00:20 celeron55 so get ready if you aren't 00:21 celeron55 (personally i've been doing all my C++ programming with C++11 for two years now) 00:21 Zeno` The easiest "correct" way to fix the issue I kludge in #2000 is to remove the default value for MapNode content_t content in it's constructor so there is a constructor that does nothing. But it's too late to do that now before 0.4.11 is released 00:21 ShadowBot https://github.com/minetest/minetest/issues/2000 -- Large increase in performance by Zeno- 00:21 hmmmm what's your take on the foreach loop 00:22 celeron55 "take"? 00:22 celeron55 is there an issue with it 00:22 celeron55 my take is "it works fine, but god forbid anyone who wants to make their own iterable data types" 00:22 hmmmm just feels like it strays too far from C 00:23 celeron55 i like it and use it everywhere 00:24 celeron55 for(auto &it : container){} is lovely 00:25 hmmmm i've always had the philosophy of using C++ as a C with classes and some other convenience features 00:25 celeron55 if you ask me, this, if anything, is a convenience feature 00:26 celeron55 compared to all the inconvenience features that C++ introduces 00:26 celeron55 but i still hate C++ iterators; they have been designed in hell 00:27 celeron55 i like the guys who coded them for me for STL types 00:28 celeron55 did you see my blog post about umm... well this post: http://c55.me/blog/?p=1723 00:28 celeron55 you might like the language he is designing 00:28 celeron55 i certainly do 00:28 celeron55 https://www.youtube.com/user/jblow888/videos 00:28 celeron55 02:21 paramat hmmmmm thanks for the help i was just trying to detect if a node was in the leaves group, however i realised my idea is not good, you were quite right it's too hardcoded 03:17 paramat okay hmmmm #2001 is ready to go, please could you review? I indented the description lines more for clarity, this file has always been hard on the eyes because the description lines are only indented by one space 03:17 ShadowBot https://github.com/minetest/minetest/issues/2001 -- Update mapgen stuff in minetest.conf. Indent lines for clarity. by paramat 03:19 Tesseract sfan5: You should set up a MSVC builder and test the Windows builds now. 03:20 hmmmm are you really going to make a release with those two blockers? 03:20 Tesseract hmmmm: Those vm helpers would be great, I wrote a few functions to help with that in WorldEdit (eg, we.manip_helpers.finish(vm, data)) 03:21 hmmmm the windows freeze when selecting serverlist and the always bright wieldmesh with shaders 03:21 Tesseract hmmmm: Depends if they're fixed in time I guess. 03:22 Tesseract hmmmm: I heard the wieldmesh thing was an easy fix, but RBA wanted to do a bigger change to the weildhand. 03:24 hmmmm =/ 03:24 hmmmm so is he going to fix it or is he not going to fix it 03:35 hmmmm frankly i don't think we can count on RBA 03:35 hmmmm at least i don't count on him to get it fixed within a day 03:38 hmmmm https://github.com/minetest/minetest/commit/249749dd8c06fc7902da648d7ab0986be203888e 03:38 hmmmm who can help with testing on Windows? 03:41 paramat tumbleweed can 03:44 hmmmm so PR 2001 is not a WIP anymore? 03:45 paramat correct 03:46 paramat best pull number ever 03:48 hmmmm who is tumbleweed and how can i get in touch with him? 03:48 paramat lol 03:48 hmmmm also wasn't somebody already working on 1959? 04:22 paramat bbl 04:56 Zeno` 2005 ok to merge? 04:56 Zeno` #2005 04:56 ShadowBot https://github.com/minetest/minetest/issues/2005 -- Make limiting of the reflow liquids queue size optional by Zeno- 05:07 cg72 Zeno`?? 05:13 kaeza hmmmm, it works OK, and `src/wieldmesh.cpp:307:17: warning: unused variable 'shdrsrc' [-Wunused-variable]` 05:13 kaeza (MinGW32) 05:21 cg72 and here is what i think of this bs >>> http://codepad.org/xJ2HOsMg 05:22 cg72 go on ban me i dont care some of you have your heads up your rearends!!!! 05:24 cg72 any comments, email me gingerpollard72@gmail.com 05:27 cg72 Miner_48er hello 05:28 Miner_48er hi 05:28 Tesseract cg72: -> #minetest please. 05:29 cg72 i was just gonna link him your and is chat log ;) 05:41 hmmmm aghhh dammit 05:41 hmmmm kaeza, did you say you were goign to work on fixing #1959? 05:41 ShadowBot https://github.com/minetest/minetest/issues/1959 -- Checking public serverlist checkbox causes minetest to freeze. 05:42 Zeno` Oh yeah. I spent some time on that (most of it installing @*$(@*($( what I thought was mingw and turned out not to be mingw :() 05:44 hmmmm the current theory is that the usage of globals in a multithreaded environment caused a race condition that started affecting things when processing slowed down slightly 05:44 Zeno` hmmmm, shall I merge 2005? (get the last thing apart from that final blocker out of the road) 05:44 hmmmm yeah 05:45 Zeno` hmmmm, kaeza mentioned clicking the checkbox calls async run twice I think. Does that sound right? 05:45 Zeno` Perhaps the local is get stuck 05:45 Zeno` grr lock* 05:45 hmmmm no idea other than speculation 05:45 Zeno` can't really see how though 05:45 hmmmm haven't seen that code and i can't test it either 05:57 hmmmm $%)@#$( 05:58 hmmmm -Wextra enables a warning the specific flag doesn't exist for -Wtype-limits 05:58 hmmmm so for g++42 you can't do -Wextra -Wno-type-limits 06:00 hmmmm in fact, none of the -Wextra options exist in 4.2.2 06:08 hmmmm there is, in fact, no way to silence the tmpnam() linker warning 06:44 hmmmm has LuaJIT been broken for a very long time for anybody else? 06:44 hmmmm LuaJIT detection, to be more precise 06:44 Zeno` Why add Wno-type-limits? 06:44 hmmmm because I get flooded with annoying type limit warnings 06:44 hmmmm I guess it must be a gcc thing.. 06:45 Zeno` I use gcc and get no type limit warnings 06:46 Zeno` What's an example of one? 06:47 hmmmm minetest/src/script/lua_api/l_item.cpp:116: warning: comparison is always false due to limited range of data type 06:47 hmmmm basically all the places where serialization version constants are checked 06:48 hmmmm e.g. #define BLAH_MIN_SUPPORTED_VERSION 0 06:48 hmmmm and then sometime later during serialization or deserialization 06:48 hmmmm u32 thingversion = deSerializeThing(); if (thingversion < BLAH_MIN_SUPPORTED_VERSION) ... 06:49 hmmmm this is how all ~20 or so cases occur 06:49 Zeno` I wonder why I've never seen them. Didn't see them with TDM on Windows the other day either 06:49 hmmmm they pop up with -Wextra 06:50 Zeno` oh, I get ~~80000 warnings with -Wextra 06:50 hmmmm if -Wextra isn't defined, then it just be my compiler acting retarded =] 06:50 hmmmm any way you look at it, it's a bogus warning 06:52 Zeno` the example you gave is not a bogus warning though 06:53 Zeno` that expression *is* always true 06:53 hmmmm sure 06:53 hmmmm but it's a constant we're comparing it to 06:53 hmmmm it's not a mistake like it's made out to be 06:53 Zeno` it is a mistake, because item.wear cannot (ever) be > 65535 06:54 hmmmm oh you're talking about that precise instance 06:54 Zeno` yeah 06:54 hmmmm maybe that one is legit but 98% of them that pop up aren't 06:55 Zeno` I just uneasy about suppressing that warning I guess 06:55 hmmmm it's important to suppress bogus warnings because they make it difficult to notice actual warnings 06:56 hmmmm like the last warning i just fixed with the unused variable - i simply could not see that over the flood of nonsense warnings 06:58 Zeno` I agree there, but I (personally) have never seen a 100% bogus warning from -Wtype-limits ... Convincing myself now :) 07:03 Zeno` checked 17 so far, and so far no false warnings 07:03 Zeno` s/false/bogus 07:03 hmmmm then they ought to be fixed.. from what i personally saw, the majority of them were version-checking-related 07:04 Zeno` None of them are bogus 07:04 Zeno` I checked all 33 07:05 hmmmm perhaps you have a different definition of 'bogus' then.. 07:05 Zeno` yeah that's easily fixed. ser_ver_supported() macro is, basically, broken 07:06 Zeno` possibly :/ 07:10 Zeno` If they're "bogus" I'd prefer to fix/hide them rather than disabling the warning altogether 07:16 Zeno` like, that l_item.cpp:116 warning... something is actually broken there. Is the item supposed to be cleared if it overflows or not? 07:17 Zeno` because it's never true item.clear() can never be called so what was the intention of item.clear()? 07:18 Zeno` Hiding these by suppressing them at the compiler level is not a great idea IMHO 07:18 hmmmm got any better ideas? 07:18 Zeno` yeah manually fix them 07:18 hmmmm in any case, you're right and i never said otherwise 07:18 Zeno` or, I'll do it 07:18 hmmmm l_item.cpp:116 is busted 07:18 Zeno` but I don't know what to do about l_item.cpp:116 heh 07:19 hmmmm the logic is completely broken 07:19 Zeno` Because I'm not sure what the original intention actually was 07:19 hmmmm if the attempted wear setting results in an overflow, simply don't set it 07:19 hmmmm nothing is documented about set_wear aside from the fact that it takes "wear" as a parameter 07:20 hmmmm this documentation is so pathetic... 07:20 VanessaE er, wouldn't the expected behavior be to max it out? 07:20 hmmmm that's acceptable too 07:20 hmmmm i'm trying to think of the situation where somebody would call set_wear() with too large of a value 07:21 VanessaE "super" tool repair. 07:21 hmmmm exactly 07:21 hmmmm I'm thinking that maybe it would increment the wear every so much amount of time 07:22 hmmmm +100, +100, +100, etc. 07:22 hmmmm so who's fixing l_set_wear?? 07:22 VanessaE or something like that too. something like the equivalent to "quad damage" 07:22 hmmmm i agree that it should be MIN(luaL_checkinteger(L, 2), 65535) 07:25 hmmmm PilzAdam wrote the entire series of set_* in that file and they all handle failure in the same defective manner 07:25 hmmmm if he comes around I'd like to hear the rationale 07:30 hmmmm and then item:set_name(5) should in theory crash the game 07:34 Zeno` so... 0: original networked test with 1-byte nodes <-- that serialization version is still supported? 07:35 hmmmm technically yes 07:43 Zeno` ok well that's easy to fix 07:43 Zeno` then just the crazy ones in connection.cpp 07:44 Zeno` (peer_id <= MAX_UDP_PEERS) is checked 5 times, but nothing seems to be done if it's false (probably because it can never be false) 07:54 Zeno` so if peer_id <= MAX_UDP_PEERS is actually checked in a sensible way (not sure how) and only once then that's all but 1 of the warnings gone 08:01 Zeno` and that only remains because it's a bug 08:01 Zeno` found because of the warning :P 08:13 Zeno` https://github.com/Zeno-/minetest/commit/e517f0368b0f8b6bff49081541c0f0443e99b66c <-- all fixed 08:13 Zeno` and we don't miss stuff that might be an actual error in the futue 08:13 Zeno` night all 11:53 kilbith sfan5: https://github.com/minetest/minetest_game/pull/386 12:50 kilbith PilzAdam: 386 updated. 12:59 * Megaf_ would like a new 80386. One like the original, but built with all new technology we have. 12:59 Megaf_ I wonder how much energy would it comsume 12:59 Megaf_ consume 13:24 gregorycu So, I think I've found a bug 13:26 Krock gregorycu, get a book and kill that bug 13:26 gregorycu It may be a feature... 13:26 gregorycu It's one of those bugs that looks so bug that it can't be a bug 13:26 gregorycu Looks so big 14:13 Megaf_ gregorycu: is that a spider? 14:13 Megaf_ gregorycu: just say what you found at once. 14:13 gregorycu I cleared it up with a dev, all good 14:13 gregorycu User error 14:13 gregorycu I was said user 15:15 kilbith sfan5: https://github.com/minetest/minetest_game/pull/387 15:37 kahrl why kilbith2/kilbith3? 15:39 kilbith because haven't figure out how to submit PRs in ignoring the previous commits on the same account 15:39 kahrl make a branch for each PR 15:39 kahrl branches are much easier to manage than multiple SSH keys, IMO :P 15:40 kilbith someones has explained me but Git is mysterious env. for me 15:40 kahrl well if it works for you, no problem 15:49 kahrl all you really need to know is these four steps: 15:49 kahrl 1. git checkout -b branchname # make a new branch 15:49 kahrl 2. git add ...; git commit ... # as usual 15:49 kahrl 3. git push origin branchname # replace "origin" if your remote is called something else 15:49 kahrl and finally 4. git checkout master # switch back to the master branch 15:52 kilbith ok, i paste those steps somewhere for an eventual try later 16:20 sfan5 http://sprunge.us/FCWP << pushing in 5 minutes 16:22 PilzAdam sfan5, why does the build script fetch that from your server? 16:25 Krock PilzAdam, it's not sfan5's server :P 16:27 kilbith PilzAdam: the straw texture is original from me, you should check that closely. 16:27 PilzAdam Krock, it looks like it 16:28 PilzAdam kilbith, see my comment on the issue 16:28 hmmmm hello PilzAdam 16:28 PilzAdam hi hmmmm 16:28 hmmmm mind if I ask why you decided to clear the item on failure here https://github.com/minetest/minetest/commit/a9c0961e0c9c3b854aca34b6d582198be1cd2277 ? 16:29 PilzAdam ummm.... because.... um... how old is this? 16:30 hmmmm looks like a little over a year 16:30 Krock 0.4.10 16:30 Krock no no. 0.4.8 actually 16:30 PilzAdam I'm pretty sure I just copied it from somewhere else 16:32 PilzAdam hmmmm, what do you mean by "failure"? 16:33 PilzAdam it seems like it's the same result as if you would create a new itemstack with the same count / name / wear 16:33 hmmmm for example in l_set_wear, if the new value to set is greater than the max, instead of just setting the max you... clear all item attributes 16:33 PilzAdam a wear of > max means the item is broken 16:33 hmmmm or what if it could be getting repaired by something else in the mod and they do something like: 16:34 hmmmm minetest.set_wear(minetest.get_wear() + 100) every use 16:34 hmmmm surely that's not broken, right..? 16:34 PilzAdam thats not repairing 16:34 PilzAdam - 100 would be repairing 16:35 hmmmm oh 16:35 kilbith PilzAdam: i've never been credited for my previous textures. 16:35 hmmmm still though, why clear and not just item.wear = MYMIN(luaL_checkinteger, 65535)? 16:35 PilzAdam kilbith, this should be fixed, then; please create an issue with the list of textures for that 16:36 PilzAdam hmmmm, if you do minetest.set_wear(minetest.get_wear() + 100) each time you use a tool, you expect it to break automatically 16:36 PilzAdam and "breaking" is clearing the itemstack 16:36 kilbith nah, thank you. i don't want to bother with the licenses 16:37 PilzAdam kilbith, this may bring us in legal trouble... *shrug* 16:38 PilzAdam hmmmm, https://github.com/minetest/minetest_game/blob/master/mods/farming/api.lua#L48-51 e.g. here we just increase the wear each time 16:38 PilzAdam hmmmm, maybe it should be documented in lua_api.txt? 16:39 hmmmm i think so... 16:39 hmmmm doesn't that break when uses == 1? 16:40 PilzAdam yes, but there is no hoe with 1 use 16:47 hmmmm fair enough... anyway would you care to fix the l_set_* item code? 16:48 hmmmm and add better documentation 17:30 sfan5 ..that were some long 5 minutes 17:30 sfan5 PilzAdam: because ubuntu's mingw is very outdated 17:40 PilzAdam hmmmm, fix? what is broken? 18:53 Calinou https://github.com/minetest/minetest_game/pull/387#issuecomment-67981441 18:53 Calinou WTF 18:55 celeron55 why is kilbith ragequiting because of that 18:55 celeron55 it's a 100% valid concern 18:55 kilbith the reason is explicit 18:55 celeron55 and easy to solvev 18:55 celeron55 solve* 18:56 celeron55 and the reply already solves the issue so there's no need to close it 18:59 Krock I would love strawballs 19:01 Calinou we can make our own texture anyway, if really needed 19:01 Calinou would be sad, as the proposed one is g ood 19:02 * Krock wonders about the difference of kilbith and kilbith3 19:03 kilbith none 19:03 celeron55 that was discussed earlier here, see the same question from kahrl 19:06 Krock kilbith, why do you close good pulls? #341 is fine to discuss header images and stuff. 19:06 ShadowBot https://github.com/minetest/minetest/issues/341 -- minetest/doc/protocol.txt is far out of date 19:06 Krock no no. the one from MTG 19:07 celeron55 ShadowBot needs to support some kind of mt_game#341 style format 19:07 Krock ^ 19:08 Krock Tesseract, have you got some free time? ^^ 19:09 kilbith Krock: just tired of the constant beg for rise up the PRs, and polemical spirit. 19:09 celeron55 kilbith: you are totally allowed to just leave PRs hanging around and go do something else meanwhile, and they often have to be discussed about quite much so you have to leave room for that 19:09 Krock ^ exactly, mostly, the theme still remains 19:13 paramat i made a one-letter typo in .conf.example, fix incoming 19:46 Tesseract game#341 19:46 ShadowBot https://github.com/minetest/minetest_game/issues/341 -- New header image by kilbith 20:03 Krock :D 20:17 paramat #2008 is ready for merge 20:17 ShadowBot https://github.com/minetest/minetest/issues/2008 -- Conf.example: Fix typo in mapgen stuff by paramat 20:19 hmmmm PilzAdam: specifically, the conditions of clearing for several of the api 20:19 hmmmm 1). l_set_name - why is item.empty() part of the condition? 20:19 hmmmm 2). l_set_count - copy paste error. you forgot to modify the condition to check for an item count overflow 20:20 hmmmm 3). l_set_wear - you assign the lua integer to a u16 and then do a comparison that could never evaluate to true due to the range of the data type 20:23 hmmmm 4). l_set_metadata - on invalid metadata, you don't clear the ItemStack like you do with the rest of the set_* apis 20:23 sfan5 celeron55: the mesh-creation-is-slow problem doesn't seem to be limited to intel: https://cdn.mediacru.sh/d/dA2O0koHr3J_.png (AMD CPU + GPU, 0.4.11-rc1 win64) 20:23 hmmmm but failure is impossible because the value at index 2 is a string. if it weren't a string, it would have thrown a LuaError and it'd never get a chance to execute the conditional 20:23 celeron55 sfan5: intel is the only one that it generally *doesn't* affect 20:24 hmmmm and why are you using checklstring anyway? you don't really need the length here.... 20:24 sfan5 oh right 20:24 celeron55 sfan5: because intel uses shared memory; that makes buffer transfer fast 20:24 hmmmm item.metadata = luaL_checkstring(L, 2); 20:24 sfan5 s/doesn't seem to be limited to intel/happens on windows too/ then 20:24 celeron55 intel drivers on windows are bad 20:24 celeron55 they use different code than linux ones 20:28 celeron55 anyway, the limiting factor is the amount of opengl buffer objects; i.e. meshes should use as few meshbuffers (irrlicht terminology) as possible, in addition to there being as few meshes as possible 20:28 celeron55 this means that texture atlases should be taken into use again 20:28 sfan5 every MapBlock is a at least one mesh, correct? 20:28 celeron55 yes, which currently has one meshbuffer per texture 20:29 celeron55 one meshbuffer is one opengl object, basically 20:29 hmmmm wait, texture atlases should be used again, for intel drivers? 20:29 hmmmm or in general 20:29 celeron55 it benefits others than intel the most 20:30 celeron55 MT performs best on linux+intel currently due to... reasons 20:30 celeron55 (when comparing to the actual performance of the given hardware) 20:31 hmmmm there's a reason for that. i think you mentioned a while ago that minetest uses low-bandwidth streaming rather than bursts of data to the pipeline 20:31 hmmmm or something like that 20:31 celeron55 there are basically two performance reasons now for getting texture atlases back; one is rendering speed and one is mesh creation speed 20:32 celeron55 both are limited by object count right now 20:32 celeron55 (on modern hardware) 20:32 hmmmm i thought the need for a texture atlas went away with texture sorting 20:32 hmmmm so basically you're just looking to minimize the number of textures loaded? 20:32 celeron55 not at all 20:32 celeron55 it only helps rendering a bit 20:33 Tesseract http://sprunge.us/CJYZ?diff fixes #2006 20:33 ShadowBot https://github.com/minetest/minetest/issues/2006 -- Error when deleting a world 20:33 celeron55 that helps rendering but doesn't affect mesh creation 20:33 Tesseract (untested though) 20:33 hmmmm then how come we didn't see any real-world performance gains with the texture atlas enabled 20:33 celeron55 hmmmm: there is a large cost in creating a new opengl object; which maps to an irrlicht meshbuffer; that's the mesh creation issue 20:34 Tesseract Complies at least. 20:34 celeron55 hmmmm: it must have been tested very poorly 20:35 hmmmm so a texture atlas would help with cpu-bound mesh generation??? 20:35 celeron55 yes; there is a large cost on dedicated GPUs for each created opengl object (=meshbuffer in irrlicht) 20:35 hmmmm how would this affect multiple mesh making threads? 20:35 celeron55 when each texture is actually the same texture, you often need only one meshbuffer 20:36 celeron55 irrlicht only supports one thread so they are first given to the main thread 20:36 celeron55 if we used raw opengl we could upload them to the GPU from multiple threads (if we drop support for old cards) 20:37 celeron55 i guess that won't help much if the object count stays the same though 20:37 celeron55 or maybe it might; there are all kinds of tricks that are doable at that level 20:37 hmmmm obviously we can add options to this or auto-detect based on card 20:39 PilzAdam hmmmm, sorry, I don't have time for this now 20:39 PilzAdam can you create an issue on github for that? 20:39 hmmmm i could just do it in 5 minutes 20:40 celeron55 http://www.seas.upenn.edu/~pcozzi/OpenGLInsights/OpenGLInsights-AsynchronousBufferTransfers.pdf 20:40 celeron55 here's the full log with this channel's opengl driver guy: 20:40 celeron55 http://fpaste.org/162548/67191141/ 20:40 celeron55 if someone has time for investigating this issue 20:44 celeron55 so, well, basically there are two layers to this issue: 1) MT is using irrlicht inefficiently (no texture atlas, maybe too small meshes) and 2) irrlicht cannot provide very good performance for an open world block game like MT because it simply wasn't made for that; it's a generic engine that uses an unsuitable abstraction level for getting top performance out of hardware in this case 20:45 hmmmm i think it's the nail in the coffin for including a forked irrlicht 20:45 hmmmm (besides, you did that with urho3d) 20:45 sfan5 would it be a good tradeoff to merge 4x4x4 (or 2x2x2) "cubes" of MapBlocks? 20:45 celeron55 my urho3d fork is actually currently totally following upstream except for a bugfix that i was too lazy to PR 20:46 hmmmm if it's sufficiently compartmentalized i think we'd be able to follow upstream 20:46 hmmmm and make PRs for them concurrently 20:46 sfan5 https://github.com/minetest/minetest/pull/2008.diff << merging in 5 mins (it's paramat's typo fix) 20:46 hmmmm sfan5: sure 20:47 celeron55 sfan5: 2x2x2 would probably give a lot of benefit on modern hardware, yes 20:47 celeron55 assuming mesh upload is does not get too slow 20:48 celeron55 (it probably won't) 20:48 celeron55 2x2x2 would also destroy performance on old hardware like the laptop i originally made MT on 20:48 celeron55 too many vertices 20:48 celeron55 it should be configurable at runtime 20:49 sfan5 benchmark this once, save results in a file, load on every startup; ???; profit 20:49 celeron55 also 2x2x2 is too small for really fast hardware 20:49 sfan5 I think that might work 20:49 celeron55 on some $1000 cards you probably want 3x3x3 or even more 20:53 kahrl and why are you using checklstring anyway? you don't really need the length here.... <-- item metadata can contain NULs 20:53 hmmmm ahhh.. 22:15 Wayward_One I too have a typo fix for minetest.conf.example: https://github.com/minetest/minetest/pull/2009 22:56 paramat Wayward_One, i can include your typo fix in my next edit of .conf.example if that's okay with you 22:59 paramat i actualy have another edit of that file i'd like to do within the next hour, if there's time before release 22:59 Wayward_One Sure, go ahead :) 23:03 paramat ok i'll get working on it now. i want to state biome noises in positional format and increase indentation for the rest of the file (if that's okay with devs) 23:27 shadowzone Hi Zeno`