Minetest logo

IRC log for #minetest-dev, 2013-11-05

| Channels | #minetest-dev index | Today | | Google Search | Plaintext

All times shown according to UTC.

Time Nick Message
00:40 Taoki joined #minetest-dev
00:51 VanessaE celeron55: still want me to try that 0.3 map?  it's explored enough for a basic test at least.
00:52 VanessaE oh, aside:  0.3.3 with HDX 512px is way faster than 0.4.x with 256px
00:53 VanessaE does that mean anything to you?
00:58 Taoki joined #minetest-dev
02:02 zat1 joined #minetest-dev
02:08 EvergreenTree joined #minetest-dev
02:14 VanessaE well I brought that world over.  0.4.4 with minetest_game, no mods, all graphics setting turned off so that it resembles 0.3.3 as closely as possible (e.g. no shaders, 2d clouds, no fancy trees, no aniso/mipmap/trilin, no nuthin'), 0.4-git gets about 1/3 of the performance 0.3.3.
02:17 general3214 joined #minetest-dev
02:18 VanessaE or close to it.   0.3.3:  60 fps with a view range of ~300 and tree-overloaded terrain.  0.4-git, 35-50 fps, view range of 235, over comparable but not-quite-so-overloaded terrain from the same map.
02:19 VanessaE depending on where I look, and this is really simple terrain, my fps and view range drop lower, perhaps 35 fps and a range of < 200
02:20 VanessaE 0.3.3 was running 512px HDX, 0.4-git is running 256px HDX
02:20 VanessaE there is *definitely* a huge regression somewhere.
02:29 VanessaE on my creative server, looking north from the spawn (the "acid test"), with 0.4-git and everything turned off that I can possibly turn off except for smooth lighting (since 0.3.3 had that turned on), unlock my max and wanted fps and unlock the min/max view range...   36 fps with a view range of 103, and the scenery is fairly simple as minetest worlds go.
02:32 VanessaE and that's with pilzadam's VBO patch btw.
02:35 VanessaE when I turn all my usual settings back on, but leave the fps and view range settings unlocked, it goes to ~38 fps at a view range of 58.
02:35 VanessaE so I lose a lot because of my settings, but even the lowest settings at 256px can't compete with 0.3.3's default settings and 512px, so something's wrong.
03:06 loggingbot_ joined #minetest-dev
03:06 Topic for #minetest-dev is now Minetest core development and maintenance. Chit-chat goes to #minetest. Consider this instead of /msg celeron55. http://irc.minetest.ru/minetest-dev/ http://dev.minetest.net/
03:07 hmmmm any comments or concerns before I push?
03:07 * VanessaE shrugs
03:08 VanessaE I have no concerns
03:08 VanessaE but I could raise holy hell and it wouldn't matter, since I ain't a core dev :)
03:09 VanessaE note for the logs, since loggingbot didn't catch it:  hmmmm is talking about pushing 7fa1b96c and fec65d04 from https://github.com/kwolekr/minetest/commits/master
03:10 hmmmm well I'd rather get some kind of feedback before I do it
03:10 VanessaE lemme pull it real quick.
03:11 VanessaE hm
03:12 VanessaE doesn't compile for me.
03:12 VanessaE http://pastebin.com/njG2yt5P
03:15 ShadowNinja I notice minetest_game doesn't have a 0.4.8 milestone. Should I add one?
03:15 VanessaE ShadowNinja: good idea.
03:18 VanessaE hm, looks like it was fec65d04 that broke it.
03:19 ShadowNinja VanessaE: Can you confirm the trees-without-leaves bug? (I wouldn't be surprised as that code is terribly messed up)
03:20 VanessaE ShadowNinja: cy1 reported same on my server but lemme check with git HEAD.
03:21 * VanessaE waits for them to grow.
03:21 VanessaE yup, they're busted.
03:21 VanessaE checked in singleplayer, git HEAD, minetest_game
03:30 VanessaE hmmmm: *poke*
03:39 mrtux joined #minetest-dev
04:11 VanessaE my G*d why is the mese pick SO SLOW now?
04:11 VanessaE (it's about the same speed as the hand)
04:19 ShadowNinja VanessaE: It got nerfed on non-stone nodes when diamond was added
04:19 VanessaE ugh :-/
04:19 ShadowNinja (Actually it got nerfed on all nodes)
04:20 VanessaE for me, diamond and mese picks seem to be about the same speed on any nodes they're used on
04:21 VanessaE mese is special, imho, and should be elevated back to the fastest tool in the game
04:21 ShadowNinja Of course really diamond should be wood-level. Like obsidian is a fragile volcanic glass...
04:22 ShadowNinja ^ I agree.
04:22 ShadowNinja But diamond is more "special".
04:22 VanessaE or rather, fastest *set* of tools.
04:22 VanessaE bah, diamond is a normal material.  mese is specific to minetest
04:22 ShadowNinja (Acording to PilzAdam)
04:23 VanessaE diamond is hard, but brittle.  it should cut fast but wear out fast too
04:23 VanessaE mese is supposed to be practically magical.  the only thing faster than a mese pick should be a maptools admin pick
04:24 ShadowNinja Agreed.
04:27 hmmmm alright there ya go
04:27 hmmmm it should work now vanessae
04:27 VanessaE trying...
04:32 VanessaE it builds and works.  the hex value pluggen in should translate directly to a value, yes?
04:33 VanessaE plugged-in*
04:33 hmmmm it gets 'translated' when you start the game
04:33 VanessaE 0x8000 -> 32768?  nope.avi.  it became 17424951366025516154
04:33 hmmmm odd
04:33 VanessaE well, #8000 rather.
04:34 hmmmm um, #8000 is not the format of hex I accept
04:34 hmmmm why would you expect that?
04:34 VanessaE o9h hell
04:34 VanessaE I read that wrong :P
04:34 Warr1024 joined #minetest-dev
04:34 VanessaE that's better.
04:34 VanessaE 0x works as expected.
04:34 VanessaE this is good, I think.
04:35 VanessaE (I mentally translated "hex" into "#" because I was thinking about formspec color codes :P )
04:36 VanessaE I like that it remembers the last seed entered
04:36 hmmmm i suppose it would be worth adding # for hex as well if people expect it
04:36 VanessaE naw, it was just a brain-o
04:37 Warr1024 only for hex values of exactly 6 (or 8) digits :-)
04:38 VanessaE hmmmm: now if you wanted to be a showoff, you'd accept $ syntax also :D
04:38 VanessaE 0x8000 -> $8000
04:39 hmmmm that's pretty confusing
04:40 hmmmm see, in HTML the # prefix means hex
04:40 hmmmm (or does it mean color? shrug)
04:40 hmmmm in 6502 assembly and many others of the era, $ means hex
04:40 hmmmm in 6502, # means numerical constant
04:40 VanessaE it's 6502/Motorola syntax
04:40 VanessaE yeah
04:40 hmmmm so like
04:40 hmmmm I can't possibly have both of them represent hex
04:40 hmmmm that's bordering on ridiculous
04:41 VanessaE heh
04:41 kaeza don't forget &H8000
04:41 kaeza :P
04:41 hmmmm FUCK vb
04:41 kaeza :<
04:42 hmmmm but anyway 0x is pretty universal, no?
04:42 Warr1024 so basically putting any shit in front of or behind a number makes it hex.
04:42 VanessaE oh sure.
04:42 VanessaE Warr1024: what, no love for octal? :)
04:42 Warr1024 let's not forget 0644 for octal :-D
04:42 hmmmm or the 0o prefix
04:43 hmmmm (i honestly forget what uses that)
04:44 VanessaE oh also, # is only a numeric constant, but you still have to indicate hex with a $ also.  LDA #$20 for example.
04:44 Warr1024 I think I've seen hex done with just an x prefix.
04:44 VanessaE at any rate, 0x is fine.  the $ thing was meant tongue-in-cheek
04:45 mrtux joined #minetest-dev
04:46 hmmmm ohh.... was it a really good idea to move tree growing and grass abms out to lua
04:46 hmmmm they were there for speed
04:48 VanessaE aside from trees having been broken by doing so, the benchmarks suggested that on average it would only impose like a 0.01% penalty
04:48 VanessaE (or 0.1%, I forget which)
04:49 VanessaE Warr1024: verilog uses x"1234" for hex.
04:50 hmmmm i'd have to see it to believe it
04:50 VanessaE er VHDL does I mean
04:50 Warr1024 good lua code isn't that much slower than decent c/c++ code.
04:50 hmmmm ol
04:50 hmmmm lol*
04:50 VanessaE I thought that notation seemed odd (I've programmed a bit in verilog)... there's rather a large difference between the two :)
04:51 hmmmm if that were true why did we spend like an eternity moving things back into C++ as an api for lua to call
04:52 VanessaE hmmmm: well I guess in this case it's because the speed gain wasn't worth losing the ability to override the sapling growth
04:52 Warr1024 hmmmm: I don't know.  As I understand it, more than 99% of my CPU is spent running c code anyway, not lua.
04:52 Warr1024 in fact, it's almost all that mesh building stuff.
04:52 hmmmm if that were really the main problem, i'd rather add something in to override sapling growth
04:53 hmmmm warr1024, but that's the client eating that CPU, not the server.
04:53 Warr1024 yeah, the server doesn't eat cpu until it's mapgen time.
04:53 hmmmm and Lua needs to lock the environment and so on while it's doing whatever, so the entire server basically comes to a halt
04:54 ShadowNinja The difference was 130ms to 150ms. And sapling spawning doesn't have to be terribly fast because of it's low interval and chance.
04:54 VanessaE hmmmm: wouldn't the proper solution there be to find ways not to lock the environment?
04:54 Warr1024 that's only really a problem with bad lua code, though...
04:54 hmmmm vanessae, contact sapier about that
04:54 hmmmm :p
04:54 VanessaE yeah yeah I know :P
04:55 hmmmm ahh oh wow we got new core devs
04:55 hmmmm when did that happen
04:55 VanessaE a few days ago
04:55 ShadowNinja ~3 days ago.
04:56 hmmmm shows how much i've been out of it
04:56 VanessaE well you had shit to do
04:56 hmmmm not really, at this point it's just that i'm not doing anything at all
04:56 hmmmm completely unmotivated
04:56 VanessaE ugh.  don't I know that.
04:58 ShadowNinja I'm trying to get a err unc passed to lua_pcall(get tracebacks for obscure crashes). Should I just add a global function to s_base, pr is there a way to/should I use member functions?
04:59 ShadowNinja errfunc*
05:05 general3214 joined #minetest-dev
05:07 ShadowNinja s_base.cpp 136 and 137 have to be added before all lua_pcall()s basically.
05:16 hmmmm true
05:17 hmmmm a method is a function just the same as a global, it'd just be trickier to get it registered
05:17 hmmmm unless you're really confident you know what you're doing with the lua crap i'd avoid it
05:18 ShadowNinja hmmmm: What do you think would be the best way to do this? loadScript_ErrorHandler is currently static.
05:19 ShadowNinja gcc complains about using members.
05:19 hmmmm I don't really see what's wrong with a global error handler like that
05:19 salamanderrake joined #minetest-dev
05:19 ShadowNinja Alright, but perhaps it should be remaned?
05:20 ShadowNinja renamed*
05:20 hmmmm eh.. please leave it
05:23 werwerwer_ joined #minetest-dev
05:24 hmmmm https://github.com/proller/minetest/commit​/5df0621a661a9b36a8626d5d9e52590e588e5309#​diff-18513665750ef5adf42b5ec29e14162eL1321
05:24 hmmmm proller
05:25 hmmmm nvm disregard that
05:25 hmmmm it's initialized elsewhere
05:48 darkrose joined #minetest-dev
05:48 darkrose joined #minetest-dev
05:55 VanessaE um, was something about overall formspec handling changed in one of these last few commits?
05:56 VanessaE suddenly, Unified Inventory's formspec (which uses custom background images) is being overlaid by the squares for the various inventory slots.
05:57 VanessaE http://digitalaudioconcepts.com/vanessa/​hobbies/minetest/screenshots/Screenshot%​20-%2011052013%20-%2012:56:15%20AM.png
05:58 hmmmm https://github.com/minetest/minetest/commi​t/25edae00ea1d5a9af4a6599fc7c200bb810fbd49
05:58 hmmmm it seems like someone reworked formspecs
05:58 VanessaE annnd...broke them.
06:03 VanessaE I wonder if that ^^^ commit is also why creative mode duplicates tools/weapons when you move them around in the inventory?
06:03 hmmmm why don't you revert to the one before it and find out?
06:04 VanessaE eh, that one seems to be a Unified Inventory bug actually.
06:04 VanessaE doesn't happen with the default creative
06:07 VanessaE checking the formspec issue
06:26 Ritchie joined #minetest-dev
07:13 VanessaE rebased my 6d facedir pull.
08:06 smoke_fumus joined #minetest-dev
08:21 Akien joined #minetest-dev
09:54 ImQ009 joined #minetest-dev
09:56 proller joined #minetest-dev
10:02 werwerwer joined #minetest-dev
11:21 EvergreenTree joined #minetest-dev
11:33 werwerwer joined #minetest-dev
11:44 proller joined #minetest-dev
12:27 zat joined #minetest-dev
12:35 proller joined #minetest-dev
12:41 proller joined #minetest-dev
12:41 troller joined #minetest-dev
12:41 Akien joined #minetest-dev
12:59 troller https://github.com/minetest/minetest/pull/983
13:03 BlockMen joined #minetest-dev
13:05 BlockMen VanessaE, its not broken. The difference is that item slots are always drawn now, but if you dont like them you can set the color transparent, like that:""istcolors[#8880;#C0C0C0]", see lua-api for more details ;)
13:06 BlockMen s/"/l
13:21 hmmmm joined #minetest-dev
13:33 BlockMen left #minetest-dev
14:00 sfan5[iPod] joined #minetest-dev
14:08 iqualfragile joined #minetest-dev
14:45 SpeedProg joined #minetest-dev
14:48 jojoa1997 joined #minetest-dev
14:58 general3214 joined #minetest-dev
15:05 proller joined #minetest-dev
15:08 proller hmmmm, need to approve https://github.com/minetest/minetest/pull/892
15:16 smoke_fumus|2 joined #minetest-dev
16:08 Akien joined #minetest-dev
16:19 proller joined #minetest-dev
16:29 PilzAdam joined #minetest-dev
16:36 PilzAdam ShadowNinja, FYI the diamond tools were hmmmm's idea
16:37 VanessaE diamond wasn't a bad idea, but mese should still be the fastest.
16:37 VanessaE and at its present speed, it's WAY too slow
16:37 VanessaE at least on non-stone nodes.
16:38 PilzAdam of course you need mese shovel/axe for non-stone nodes
16:38 VanessaE joined #minetest-dev
16:39 VanessaE bah
16:39 VanessaE ctrl-A, you schmuck, not ctrl-Q.
16:40 VanessaE anyway, I guess it's not so bad, but really, a mese pick on wood or dirt is nearly as slow as the hand
16:41 VanessaE I understand the need for balance of course.
16:41 PilzAdam its not "nearly" as slow, its exactly the same speed
16:41 ShadowNinja I've fixed VanessaE's no-backtrace issue(I just have to apply it to a few more functions). Example output now: http://pastebin.ubuntu.com/6365584/
16:41 VanessaE a shovel should be faster than a pick on dirt, but nearly instant, compared to a few seconds?
16:42 VanessaE that's what I mean by way too slow
16:42 PilzAdam the system we use in minetest_game is that every tool just defines the digging time for one special group (i.e. cracky for picks), all the other times are taken from the hand
16:42 VanessaE a mese pick is supposed to be FAST on everything.  Maybe slower than using a more appropriate tool, sure, but as slow as the hand is not right at all.
16:43 PilzAdam ah, you got that wrong, the mese pick is supposed to be fast on stone only
16:43 PilzAdam since its a pick
16:43 VanessaE "supposed to be" == "how it historically has behaved"
16:44 VanessaE I don't mean it needs to be massively overpowered like the 0.3.3 pick was :)
16:44 PilzAdam things have changed
16:44 VanessaE know.
16:44 VanessaE I know*
16:45 * VanessaE shrugs
16:46 proller ShadowNinja, undefined, ?
16:46 proller http://servers.minetest.net/
16:47 ShadowNinja Hmmm, I thought humanTime had a check for that. It seems to work for age...
16:48 ShadowNinja proller: Oh, add "return seconds;" after the for loop in humanTime.
16:49 proller and maybe add popular ?
16:49 ShadowNinja proller: Or rather "return seconds + 's';".
16:49 proller ok
16:50 proller http://minetest.setun.net:8000/
16:54 smoke_fumus joined #minetest-dev
16:55 VanessaE with so many servers in the list, we've got a bad selection bias going on now
16:56 VanessaE less-popular servers end up down off the bottom of the list, and people don't like to scroll
16:56 VanessaE so the less popular ones have less chance to improve that rank
16:57 VanessaE maybe they should be in order my ping time or uptime or something?
16:57 VanessaE by*
16:57 proller ping now useless, need to make processing ping packet by serverthread
16:58 proller for player - better to play on full server
16:59 VanessaE that means a mostly empty server will never get full.
17:00 VanessaE maybe just randomize the list order then each time the client is started.
17:00 VanessaE or alpha order by the server name
17:00 VanessaE or alpha/numeric order by IP
17:01 VanessaE just something that is not tied to the number of users on the server.
17:02 ShadowNinja VanessaE: This should fix your traceback issue: http://ix.io/8UP
17:02 Gethiox3 joined #minetest-dev
17:03 proller http://minetest.setun.net:8000/ - now with  players:   players/limit average/top
17:03 ShadowNinja It starts, but I might have added the function to the stack incorrectly of something like that, so it should be tested on a real server for a bit.
17:03 VanessaE proller: change the header also.
17:03 proller it will toooo long 8(
17:04 VanessaE proller: two lines, duh :)
17:04 VanessaE ShadowNinja: ok, I'll apply it
17:04 proller f5
17:05 VanessaE proller: good, but put something other than a space between the two pairs, or display those pairs on separate lines also
17:06 proller f5
17:06 VanessaE meh
17:07 VanessaE put 'em on separate lines.
17:08 sapier joined #minetest-dev
17:10 proller no, splitting lines too bad
17:10 VanessaE why?
17:10 VanessaE it's already split in the description column.
17:10 sapier VanessaE I wonder why your performance evaluations give that different result to mine
17:10 VanessaE it won't change the overall table formatting.
17:10 proller not everywhere
17:10 proller only on small screen
17:11 proller if larger 1150px - in one line
17:11 VanessaE http://digitalaudioconcepts.com/vanessa/​hobbies/minetest/screenshots/Screenshot%​20-%2011052013%20-%2012:10:53%20PM.png
17:11 proller https://github.com/proller/minetest/commit​/a8e78b76f6d32f7f77bddf4919ebbdf445d4dc9e
17:11 VanessaE ^^^^ 1280x1024 screen
17:12 VanessaE that's how small it has to get to keep each entry on one line (firefox 25)
17:12 VanessaE ShadowNinja: your patch is in service now.
17:13 sapier hmmm lua doesn't need to lock the environment it's broken design why the environment needs to be locked
17:13 proller will commin if no objections ^^^
17:13 VanessaE sapier: how do your results differ from mine (and what results, anyay?)
17:13 celeron55 it would be better to not make subcolumns with commas
17:14 sapier http://imgur.com/bfMsr3r,1ProJQP#1
17:14 celeron55 but make them actual columns or subcolumns (which is done by making them visually different to a "full" column)
17:14 sapier those results I posted them yesterday 23:20
17:14 sapier for me minetest 0.3.2 performance is almost exactly same as 0.4.7
17:14 proller celeron55, too many  columns
17:15 sapier there's even a small + for 0.4.7 yet not enough to really count it
17:15 VanessaE sapier: ah, right.  didn't see.   yeah, for me the difference is stark, almost jarring.
17:15 ShadowNinja VanessaE: I seem to have missed a few uses of lua_pcall, but most should be covered.
17:15 sapier that's what I wanna find out ... it may give a hint where to look for the regression you suffer from
17:17 VanessaE ShadowNinja: I'm sure we'll find out shortly :P
17:17 VanessaE in fact, lemme see if I can force that one assert.
17:17 sapier whyt do you want to cover shadow?
17:18 sapier VanessaE what os and graphics card graphics api do you run minetest?
17:19 VanessaE sapier: Linux, OpenGL 4.3.12614, ATI HD 6870.
17:19 proller next step to servers list - make page about every server with full info
17:20 sapier ok I've got nvidia graphics ... maybe we need someone to check if this is a relevant difference
17:22 Calinou joined #minetest-dev
17:23 sapier hmm my old laptop is ati graphics ... I'm gonna try
17:24 VanessaE ShadowNinja: your changes weren't enough to produce a backtrace from the vector lib.  Is there some change I need to make there also?
17:25 VanessaE (I'm using the technic chainsaw + item_drop bug as a basis)
17:28 salamanderrake joined #minetest-dev
17:30 EvergreenTree joined #minetest-dev
17:38 ShadowNinja VanessaE: Must have been one of the pcalls I missed. Lemme get this to compile and I'l give you an updated patch.
17:38 VanessaE ok
17:39 sapier shadow you did push the error function right in front of the pcall ?
17:40 ShadowNinja sapier: No, I push it at the begining of the function. Should I push it there?
17:42 sapier depends on what you're doing pcall from c++ main loop or pcall from lua-c++ call
17:43 sapier the lua stack handling isn't exactly easy to understand so if you don't exactly know what you're doing you most likely will do wrong ... I learned this the hard way ;-)
17:43 ShadowNinja Should it be before on a Lua->C++ call? With a lua_pop() after?
17:44 ShadowNinja Drat: PANIC: unprotected error in call to Lua API (bad argument #8 to '?' (function expected, got string))
17:44 sapier if you're in main loop it's done this way no idea what is correct if you do a c++ -> lua --> c++ ->lua call
17:45 sapier that's what happens if you messed up stack
17:46 ShadowNinja Yea, I guesed. Lemme see if I can find where this heppened...
17:46 sapier I already tried to fix those lua calls but didn't spend much time on it when I didn't succeed immediatly
17:49 sapier VanessaE where did you get 0.3.3 from?
17:49 VanessaE sapier: from the Minetest git repo, 0.3-stable branch
17:50 sapier ok so not 0.3.2 tag but 0.3 branch thx
17:50 VanessaE yup
17:51 VanessaE "Minetest-c55 0.3.3" is what it reports in the game anywaty
17:51 VanessaE anyway*
17:53 VanessaE fps seems more variable now than before, but it definitely performs better than 0.4.x for me
17:53 ShadowNinja Alright, fixed it. c_content.cpp or c_internal.cpp. sapier: can you figure out how I should add the errfunc to script_run_callbacks?
17:54 ShadowNinja The errfunc is named script_error_handler.
17:55 sapier no I don't know how to do that I'd have to look same way you'd have to look and I'm looking for vanessaE's performance issues
17:56 VanessaE sapier: for example, I'm holding a solid 30 fps with a view range of 287 over complex, tree-overloaded terrain right now in 0.3.3
17:56 VanessaE (with default textures)
17:57 sapier VanessaE I don't expect typical 0.4 to be faster then 0.3 as noone will avoid using 0.4 features yet if one avoids it it should be almost as fast as 0.3 ... as this doesn't seem to be true for your environment I try to figure out why
17:57 ShadowNinja VanessaE: Any better? (Probably not though) https://github.com/ShadowNinj​a/minetest/tree/pcall_errfunc
17:58 sapier did you have a look at my screenshots vanessae? is that situation comparable to what you test?
17:59 VanessaE sapier: hold, I'm doing another test.
17:59 VanessaE ShadowNinja: gimme a few mins.
18:07 VanessaE oh sure, NOW it's gonna make a liar out of me!
18:07 sapier ok with exatly same view I have about 50% more frames in 0.4 than in 0.3
18:07 sapier at least in some situations
18:08 VanessaE as soon as these damn clouds move out of the way of the f5 I'll upload screenshots.
18:09 sapier at least on nvidia gtx260 0.4 has slightly better performance than 0.3
18:10 sapier wait irrlicht 1.7.3
18:10 sapier do you have 1.8?
18:11 VanessaE 0.3.3:  http://digitalaudioconcepts.com/vanessa/​hobbies/minetest/screenshots/Screenshot%​20-%2011052013%20-%2012:59:39%20PM.png
18:11 VanessaE 0.4-git http://digitalaudioconcepts.com/vanessa/​hobbies/minetest/screenshots/Screenshot%​20-%2011052013%20-%2001:09:38%20PM.png
18:11 VanessaE and it's 1.8 for the 0.4-git build, 1.7.3 for the 0.3.3 build
18:11 VanessaE the 0.4-git build has several patches on it to help with client fps
18:12 VanessaE (vbo, strip the fps from the title bar, etc)
18:12 ShadowNinja https://github.com/minetest/minetest/pull/954 <-- Wasn't this intentionally disabled? And why was it if so?
18:12 sapier maybe it's not a minetest 0.3 -> minetest 0.4 but a irrlicht 1.7 -> irrlicht 1.8 problem?
18:13 VanessaE sapier: could be.  when I posted the initial report, both were running 1.7.x
18:13 sapier what framerate is 0.4.7?
18:13 werwerwer_ joined #minetest-dev
18:13 VanessaE but why does 0.3.3 perform better with 512px textures than 0.4-git does with 256px?
18:13 ShadowNinja Can someone else agree #934?
18:13 sapier vanessa it doesn't ;-)
18:13 VanessaE 0.4 was pushing 60 fps, hence the "liar" part.
18:13 sapier at least not generaly
18:14 VanessaE sapier: in a few mins I will try it again, just to be 100% sure.
18:15 VanessaE ShadowNinja: reset back to my local HEAD, added your revised patch, compiling it now.
18:15 sapier I'm currently testing on radeon xpress 200m ... same libs for both builds
18:16 sapier sorry if this sounds rude but I consider comparing builds with different libs useless for performance comparison
18:16 Jordach joined #minetest-dev
18:17 VanessaE ShadowNinja: still not enough to get a backtrace.
18:18 ShadowNinja :-|
18:18 sapier I forgot how to enable fly ... yes I know "again" ... can someone help me?
18:19 ShadowNinja sapier: Are you familiar enough with Lua to fix this? Or do you know someone that is?
18:20 sapier I guess I could find out how to fix it but it's not a thing to be done in 5 min for me .. I would've already done if it was
18:20 sapier fly? ;-)
18:21 VanessaE *sigh* now my computer is gonna make a big liar out of me *grumble loudly*
18:22 ShadowNinja sapier: There are just a few calls to go, I got most of them.
18:23 ShadowNinja Alright, read_items done.
18:25 sapier shadow it's NOT just a view calls to go it's doing it without messing lua stack ;-P
18:25 VanessaE 0.3.3, HDX 512:  http://digitalaudioconcepts.com/vanessa/​hobbies/minetest/screenshots/Screenshot%​20-%2011052013%20-%2001:22:19%20PM.png
18:25 VanessaE 0.4=-git, HDX 512: http://digitalaudioconcepts.com/vanessa/​hobbies/minetest/screenshots/Screenshot%​20-%2011052013%20-%2001:24:18%20PM.png
18:25 ShadowNinja Yes.
18:25 sapier great I can't test on my old laptop it instantly crashes 0.4
18:26 VanessaE (fps was respectable then, comparable to 0.3.3)
18:26 ShadowNinja VanessaE: I notice a different bug: "Minetest [Main Menu]"
18:26 VanessaE ShadowNinja: I removed the fps display from the titlebar.  gives me a couple fps gain.
18:26 sapier 0.4.7 seems to be faster as your view distance is bigger
18:27 sapier especialy xfce seems to behave quite ugly for title bar updates
18:29 sapier VanessaE maybe you misinterpret 0.4 beeing slower because in usual environment it actually is slower ... not because of regression but because of new features require more cpu power
18:29 sapier or graphics power
18:30 sapier everything I found out by now give 0.4 a slight performace benefit to 0.3 (and your screenshots seem to show same)
18:30 VanessaE sapier: and notice how complex the terrain is.  Now, watch what happens when I go into my creative server, exact same settings as in the screenshot above:
18:30 VanessaE http://digitalaudioconcepts.com/vanessa/​hobbies/minetest/screenshots/Screenshot%​20-%2011052013%20-%2001:29:54%20PM.png
18:30 VanessaE 35 fps in that shot.
18:31 sapier yes? with quite a lot more non 1 block meshes
18:32 sapier I'd guess there are a lot of those meshes within viewing range but yet hidden by others in that screenshot too
18:32 VanessaE maybe a few - streetlamps, some mesecons, some slabs.  whoop-de-doo.
18:33 sapier guess 0.3 would behave as bad as 0.4 if this was possible there ... seems to be a generic fault of the way minetest (0.3/0.4) is doing rendering ... at least thats best explantation that matches the results
18:33 ShadowNinja sapier: Moving around the insertion only changes the error message. Any help?
18:34 sapier if you do add a function to stack within a lua called c++ you mess up the stack you need to make sure it's exactly same as before
18:35 sapier so if yo do a pcall afterwards you need to push parameters for that call AFTER the error handler
18:35 sapier if you pass parameters from outer lua call to a inner one you even need to pop the parameters push the error handlers and push back the parameters
18:36 VanessaE now watch what happens when I view that map with no content at all:
18:36 VanessaE http://digitalaudioconcepts.com/vanessa/​hobbies/minetest/screenshots/Screenshot%​20-%2011052013%20-%2001:35:20%20PM.png
18:36 sapier that'S why I didn't do it it's quite easy to mess it up
18:36 VanessaE (it's an older version of the map before the structure to the right was finished)
18:36 VanessaE 60fps in this map.
18:36 sapier I guess 60 is same as 0.3?
18:37 VanessaE yes
18:37 Zeitgeist_ joined #minetest-dev
18:37 VanessaE like I said, today my computer wants to make a big liar out of me.
18:37 sapier I guess this prooves 0.4 not having a regression but 0.4 design to be bad for features that have been added
18:38 sapier yet 0.4 design is same as 0.3 design ;-)
18:38 sapier no VanessaE it's good we did this investigation so we know we should be extremely carefull to add more complexity to our sceens as we already hit performance borders of our engine design
18:39 sapier now where are the 3d engine guys we need a better engine design! ? ;-)
18:41 VanessaE http://digitalaudioconcepts.com/vanessa/​hobbies/minetest/screenshots/Screenshot%​20-%2011052013%20-%2001:40:26%20PM.png
18:41 sapier what does 934 actually do?
18:41 VanessaE 60 fps in this shot, exactl same map files, roughly the same position, pitch and yaw, and I made to load up as much map as I could possily expect to see in each case.
18:42 sapier but obviously different blocks loaded
18:42 VanessaE you can't tell me that it takes 8 times as much GPU power to display the "real" world as it takes to display the "no content" world, since the GPU doesn't really give a shit what it is displaying
18:42 sapier my best guess is this is a clipping issue
18:43 VanessaE clipping?
18:43 sapier hidden things beeing rendered/processed where they shouldn't be processed
18:43 VanessaE I figured that's what you meant.
18:44 sapier actually the gpu gives a lot if it has to display 4*100*x or 400*100*x polygons ;-)
18:44 VanessaE under that black street is a bunch of heavy nodebox-based items (pipes, mesecons, some other stuff).  If I can't see it, the GPU shouldn't be wasting its time with it
18:45 VanessaE it's the only possible explanation.
18:45 sapier yes it shouldn't be wasting the time but who is actualy building the scene? that's not done by gpu
18:46 VanessaE well sure, but surely the CPU isn't sitting there building and sending meshes constantly is it
18:46 ShadowNinja I've tried inserting the function in multiple places... sapier: Where should I put the function given this stack? <return value = nil><table><are1><arg2>...<argN>
18:47 VanessaE (as in re-sending the whole local map for every frame)
18:47 sapier I don't know I havent done much with 3d engine by now
18:47 ShadowNinja arg1*
18:47 sapier shadow I'm not exactly sure I did understand lua stack fully I'm far from qualified to give errro free answers ;-)
18:48 * ShadowNinja tries using rand(1, lua_gettop(L))
18:48 sapier if I would try to fix this I would have to do it by trial and error to learn more about stack behaviour too
18:49 sapier LOL
18:49 sapier are you crazy?
18:49 sapier you do understand what a stack is shadow?
18:50 sapier those numbers you get from lua_gettop() are quite similar to the memory adresses you see in debuger backtrace
18:51 ShadowNinja sapier: Yes, I have a basic understanding of how the Lua stack works.
18:51 sapier you can't get a random memory address and expect it do do anything sane
18:51 ShadowNinja sapier: Yes, that was a joke. ;-)
18:51 sapier ohhhhhh .... ok you got me
18:54 sapier who did add those vbo things?
18:54 VanessaE pilzadam
18:55 sapier is there a way to restore old behavior? 0.4 crashes in st_draw_vbo (inside of 3d driver) on my (outdated) ati while 0.3 didn't
18:58 PilzAdam are you using my vbo branch?
18:59 sapier no thought those things have already been merged?
19:00 PilzAdam there are memory leaks, and we havent found a way to fix them
19:01 VanessaE PilzAdam: Taoki would tell you those alleged memory leaks aren't as feared.
19:01 Taoki Actually I thought they're fixed
19:01 VanessaE however there is a performance drop over time as old data stacks up instead of being discarded, but that's not exactly a memory leak.
19:02 Taoki If the memory isn't completely abandoned and forgotten there, it's likely not a memory leak per say. Still not desired of course... though IMO not as drastic either
19:02 sapier hmm I guess there is something else that has changed in 0.4 causing it to crash on not quite fresh amd mobile gpu
19:04 sapier https://github.com/minetest/minetest/issues/984 the stack of crash it's 100% reproduceable
19:12 VanessaE sapier: Fisher-Price version:  All game content present, only the texture files have been deleted, forcing the engine to render flat, basically-textureless meshes.  28 fps, view range of 129:  http://digitalaudioconcepts.com/vanessa/​hobbies/minetest/screenshots/Screenshot%​20-%2011052013%20-%2002:11:09%20PM.png
19:13 VanessaE and that's after flying up and down a bit to make sure what's under the street is loaded,
19:13 VanessaE this proves conclusively that my texture pack is NOT the cause of the regression.
19:13 VanessaE there's just no way in hell that a high end GPU should render that ^^ at anything less than 60 fps and a 300m view range.
19:14 sapier no I didn't expect the texture pack to be source of slow down imho it's HOW engine renders nodeboxes
19:14 VanessaE people have claimed to me before that my texture pack is the cause.
19:14 VanessaE I wanted to prove it was not.
19:14 sapier I assume if you remove all nodeboxes it's gonna be as performant as 0.3
19:14 VanessaE you know that randomly-colored world almost looks "kid friendly" doesn't it? :)
19:15 sapier textures will only matter if you reach limit of video memory as most people have at least 256mb you need big texture packs
19:15 VanessaE right
19:16 sapier yes it's a interesting look without textures :-)
19:16 VanessaE though without texture compression, it's a lot easier to hit that ceiling that you might think.
19:16 sapier yes maybe ... yet that's another issue and for sure not a "regression" ;-)
19:16 VanessaE right
19:17 sapier a regression is a bug that wasn't there before ... whatever causes that slowdown was there in 0.3 too without nodebox it hasn't been revealed
19:18 VanessaE well at any rate, I've done about all I can with these screenshots.
19:19 sapier yes I guess now it's up to the engine guys to find out why our engine can't handle those additional faces added by nodeboxes
19:19 sapier but I don't exactly know who the "engine guys" are
19:31 proller joined #minetest-dev
19:42 proller 934 is good
19:43 proller but need to default alias
19:48 VanessaE menawhile, will someone PLEASE do something about the G*d-awful-slow texture extrude routine?  I've got a few 512px textures that, together, take about 1 full minute to render by themselves
20:02 ShadowNinja Is there any reason not to add Lua 5.2 support?
20:03 VanessaE it will break some mods, it's not 100% backward compatible to 5.1
20:03 VanessaE other than that, no :P
20:03 VanessaE of course luajit is basically only 5.1
20:04 PilzAdam ShadowNinja, we want to be sure that a mod runs on every Minetest build
20:04 PilzAdam different Lua versions just make things complicated
20:06 ShadowNinja Hmmm, LuaJIT compatability may be an issue. But Lua 5.2 is about 99% compatible, and you shouldn't depend on depreciated Lua functions anyway.
20:06 sapier what are those 1%
20:06 sapier ?
20:07 VanessaE with my luck, that 1% would include every mod I've written :P
20:11 ShadowNinja Ah, no, we can use -DLUAJIT_ENABLE_LUA52COMPAT
20:11 sapier does 5.2 have any benefits to 5.1?
20:11 ShadowNinja Although we have to check the system library to make sure it is built wit that, or build our own.
20:12 ShadowNinja sapier: Yes, eg, __len works and other metamethods were added.
20:12 sapier what does __len do and what metamethods are you talking about
20:13 sapier reading "meta" I always think "shit yet more things to prohibit when implementing client side lua"
20:13 ShadowNinja sapier: __len returns a objects length(when using #o) also __lt __le __pairs __ipairs...
20:14 sapier whats lenght of an arbitrary object?
20:15 sapier yet those things shouldn't be a cause to not add it yet what are those incompatible differences ppl talk about?
20:15 ShadowNinja sapier: Whatever you define it as, eg the length of a vector is sqrt(x^2+y^2+z^2).
20:16 ShadowNinja unpack was moved to table.unpack(we can alias it if it isn't already)...
20:16 sapier ok so a nice to have ... still I'm more interested in things that don't work
20:16 ShadowNinja math.mod and string.gfind were removed.
20:18 ShadowNinja goto isn't a valid variable name anymore(pretty non-important).
20:18 BlockMen joined #minetest-dev
20:18 sapier now I'm against 5.2
20:18 ShadowNinja http://www.lua.org/work/doc/manual.html#8
20:18 ShadowNinja Why so?
20:19 sfan5 hm
20:19 sapier if goto is not a valid variable name it's most likely added and I hate languages supporting goto for code style issues
20:20 sfan5 __lt, __le and __len metamethods allow shit like a < #b < (foo > bar) do things nobody understands, don't they?
20:20 sfan5 +to
20:20 sapier most likely
20:21 ShadowNinja Yes, but that doesn't mean you have to use them.
20:22 ShadowNinja And that isn't the only feature added.
20:22 ShadowNinja Lua 5.2's goto if fairly limited to prevent unreadable code.
20:23 sapier I'm not concerned about things I use but about things other mods do
20:24 VanessaE GOTO \:D/
20:24 sapier goto is for people just starting to learn programming only
20:25 sapier or hardware developers actually writing nice assembler code with c
20:25 ImQ009 joined #minetest-dev
20:25 ShadowNinja goto can be usefull, eg to jump out of nested loops.
20:26 proller sapier, or for complex algorithms
20:27 ShadowNinja Although I personall haven't used it yet.
20:27 ShadowNinja +y
20:27 sapier actuall NO you don't need goto for complex algorithms unless you actually need it to prevent others from maintaining your code
20:27 proller no.
20:27 proller some things is very hard to write without goto
20:27 proller they very rare, but exist
20:28 sapier so 99.9% goto makes code worse while it improves in 0.1% ... I'll take that 0.1%
20:29 proller most peoples do not know how use goto
20:31 sapier that doesn't stop them from using it
20:31 ShadowNinja sapier: You assume that because goto is available everyone will use it to write unreadable code.
20:31 proller lets start party: #983 #980 #956 #895 #892
20:31 sapier I learned the hard way if it can be done bad it will be done bad yet I'm still looking for a must have feature in 5.2 justifying to add it
20:32 proller #983 is simplests
20:33 sapier wtf they use goto to implement break ...
20:37 sapier ok I assume most things in 5.2 are acceptable ... I'm a little bit concerned about the bitoperations ... those could result in different calculation results
20:37 ShadowNinja sapier: Look for one here: http://lua-users.org/wiki/LuaFiveTwo
20:38 ShadowNinja Not sure what you mean, but LuaJIT has BitOp if you need it.
20:38 sapier http://www.inf.puc-rio.br/~ro​berto/talks/novelties-5.2.pdf this is better
20:39 * ShadowNinja shrugs
20:43 sapier but shadow don't we have enough bugs to fix do we really need to add a new source of unknown bugs?
20:45 sapier 983 seems to be fine
20:45 kahrl I don't see any problem with goto used as in "goto fail; ... fail: error handling code"
20:46 kahrl it's not harder to understand than "break" or exception handling
20:47 sapier goto this; goto dothat; goto antotherthingbetweenthisandthat
20:48 sapier it's not the legit cases goto is feared for but all those silly usages
20:48 kahrl you can write functions with 42 arguments
20:48 kahrl do we ban functions?
20:48 sapier yet I'll not veto for goto It's useless to open up that discussion again
20:49 kahrl well I guess the_game makes it look like we ban functions ;-)
20:50 sapier true ... we should add a rule "DO NEVER EVER INCREASE LINE NUMBER OF THE_GAME" ... so everyone is forced to create those functions that should be there
20:51 sapier kahrl do you agree to 983 too?
20:55 proller next not-very-complex thing: #980
20:55 Zeg9 joined #minetest-dev
20:56 sapier I'm not sure about auto respawn
20:57 proller bots useless without it
20:57 sapier yes but bots are a debug feature only
20:58 proller in my server self killing is fun, and respawn message is annoying
21:01 sapier we should add n new client side settings page
21:01 sapier it is client side only isn't it?
21:01 proller yes
21:01 proller but setting - its for other pull
21:03 sapier I still dislike that pull it doesn't stick to the rule "one change one commit" and those changes are neither just a small cleanup/bugfix nor related
21:04 proller split it 3 pulls?
21:04 sapier we'd add auto_respawn setting with commit message "null driver fixes" ;-(
21:05 sapier I think 2 are enough everything else seems to be performance improvement
21:05 proller autorespawn, /0 fixes, performance
21:06 proller but no
21:06 sapier is it correct to use 1 instead?
21:06 proller yes
21:06 proller all about make bots possible
21:06 sapier yes but don't you hide errors by doing it that way?
21:07 proller doing everything hides errors
21:07 proller simpler do nothing
21:07 sapier I'm not talking about fixing but usually a division by zero is a bug
21:08 sapier in this case you'd just divide by one which hides the actual bug "dividion by zero"
21:08 proller this bug only for 0-sized display
21:10 sapier isn't tiledef[j].animation.aspect_w sent by server?
21:11 proller maybe it calculated
21:14 sapier line 137 it's from server so yes it shouldn't crash ... if I remember correct 1 is default value on server side too ... you should check this is true and add a comment why it's safe to assume 1 in case of 0
21:18 proller 137?
21:18 proller all this checks saves from crash
21:19 sapier nodedef.cpp there are the de/serialization functions so it's sent
21:19 sapier yes but you still change a value transmitted by server
21:20 proller i make /x?x:1
21:20 EvergreenTree joined #minetest-dev
21:20 proller no matter from where x
21:21 sapier you can only do this if you're sure 0 is not a valid value for x ;-)
21:22 proller 0 always invalid in y/x case, also y%x
21:23 sapier yes but you need to check if that variable is used ONLY there if you fix it there and other locations use 0 you create a inconsistent state within client
21:24 sapier so if you're sure 0 is invalid you could fix it at deserialization location to ensure noone ever uses 0 as it's value
21:24 proller i need join all my pulls in one...
21:25 sapier why do you always merge things not related to each other in a single commi
21:25 sapier t
21:25 proller becausse i trying to make one thing. here was working bot
21:25 proller in other pulls - liquid-weather stuff
21:26 proller sometimes i cant change one line in separate pulls
21:26 sapier I'm not gonna agree to multi commits if those things aren't at least related or bugfixes not changeing behaviour
21:26 proller also need updating 1-2-3- months every
21:27 sapier so if you want to get them merged you're free to ask someone else to agree
21:28 sapier I'm not sure what you name your pulls but I feel the name most time doesn't reflect the actual changes
21:29 sapier no offence maybe this is due to language missmatch only
21:29 proller because i usually start from one thing, and add more in next 3 months
21:30 sapier 956 --> no, imho feature enhancement for 0.4.9
21:31 sapier I do so too proller but if you do completely different things create a different pull request ... I know it's anoying to work with different minetest trees not containing other fixes
21:32 proller my all completely different things in different pull requests
21:32 sapier yes but at lest this one looks like a "collected various fixes" commit ;-)
21:33 sapier maybe you should call it that way
21:38 sapier 895, there's no need to change default max user value for liquid levels
21:38 proller every server can work with 50+ clients
21:39 proller this value was decreased from 100 because current servers unplayable at 10+ players
21:39 sapier it's not related to the fix don't try to push changes like that as trojan horses
21:39 sapier I think 15 is to small to yet it's not to be changed in this special commit ;-)
21:39 proller no problem, i will remove this line
21:40 sapier #max_simultaneous_block_sends_server_total = 100500 if the comment for this line is right I don't think that number is sane
21:41 proller i can remove this variable
21:41 proller its only for lag
21:41 sapier what is it supposed to do?
21:42 proller to not send blocks if too many players
21:43 sapier is it actually possible to send that many blocks?
21:44 proller it limited by max_players*max_simultaneo​us_block_sends_per_client
21:45 sapier it's good style to remove unused variables so yes better remove it
21:56 ShadowNinja sapier: #971 fixes #910?
21:58 sapier yes but it needs as much testing as possible
21:59 ShadowNinja sapier: It works under both Windows and Linux?
21:59 sapier tested in linux windows mingw build and windows vs2012 build
22:12 ShadowNinja Ok, then I agree with it. We should be able to relese 0.4.8 soon after that.
22:13 sapier no we need at least 884 and maybe 977 or the httpfetch variant of fixing that bug
22:18 kahrl sapier: sorry, I was gone, anyway doesn't matter now does it ;)
22:19 kahrl I'd have said to split the commit into two but meh
22:19 sapier which commit?
22:19 kahrl https://github.com/minetest/minetest/pull/983
22:20 sapier yes but those changes are that obvious correct no need to even mention ;-)
22:20 Gethiox4 joined #minetest-dev
22:20 kahrl well they might make it so that #862 needs a rebase
22:21 kahrl no big deal anyway...
22:21 kahrl I'll have to merge the useragent thing into httpfetch somehow when I have time
22:21 kahrl aka: in a year :P
22:22 sapier kahrl we need httpfetch or my async changes for 0.4.8
22:22 kahrl yes
22:22 kahrl I have no idea which one would be preferable
22:22 kahrl or a preference
22:23 sapier so either you should complete it or review the async things (which I intend to extend in 0.4.9 for scriptapi usage)
22:23 kahrl I have no time to do either of those
22:23 kahrl but there's not much that needs to be done to finish httpfetch, any dev could probably do it
22:23 sapier ok so someone else needs to check the async things
22:23 kahrl more testing would probably be nice
22:24 sapier ok if it's almost done I probably have a look at it
22:24 kahrl list of what needs to be done in httpfetch: http://irc.minetest.ru/minetest-dev/2013-11-04 at the top
22:24 kahrl plus the useragent thing
22:24 sapier yet I guess I'd be a little bit biased ;-)
22:27 sapier I guess async could use httpfetch too so maybe it's just removing the special serverlist handling from httpfetch
22:27 kahrl yeah that could work
22:28 sapier I'd prefere the generic async aproach to special lua api calls done async
22:29 sapier in best case we can do anythin async after cleaning up minetests internal datastructures
22:29 sapier yet that's quite a long way to go atm
22:30 kahrl this probably means some API breakage in the future related to APIs that can be called from async, locking, etc... as long as it's only in the mainmenu, no problem at all
22:31 sapier I'd prefere without api breakage
22:31 kahrl if the old api can be supported cleanly, sure
22:32 sapier yes of course it's to early to tell I'd add the calls one by one
22:32 sapier as done in mainmenu there are some calls missing there too
22:32 sapier but I guess calling a fileselect dialog from async never will be possible it'd be insane
22:33 kahrl it could be done with fork() ;)
22:34 sapier *g* not exactly usefull ;-)
22:52 BlockMen5233 joined #minetest-dev
22:55 mrtux joined #minetest-dev
23:02 zat ping celeron55
23:08 troller joined #minetest-dev
23:15 BlockMen left #minetest-dev

| Channels | #minetest-dev index | Today | | Google Search | Plaintext