Time  Nick        Message
05:34 kahrl       if I'm going to implement nodebox support in the software raytracer, I basically have two options:
05:34 kahrl       1. check every face of each nodebox for each pixel (sample, once supersampling is implemented)
05:35 kahrl       or 2. calculate bounding boxes (in projection space) for each nodebox face and only check faces whose bounding box contain the current pixel
05:36 kahrl       which would probably require an intricate data structure if it's going to be fast
05:36 kahrl       so I'm thinking of moving to a rasterizer approach instead
06:34 celeron55_  kahrl: irrlicht does have way more features than the menu can currently use; the formspec layer is mostly (but not fully) the limiting factor
06:40 celeron55_  but it's true that even without the formspec bottleneck, irrlicht wouldn't be as good as one'd want
06:43 kahrl       if it's impossible to define a generic table or treeview or listbox formspec element, one could also make very specific serverlist or modlist formspec elements
06:45 kahrl       for example the flags: the serverlist element could display them as icons
07:58 kahrl       rasterizer basics in pseudo code: http://paste.dy.fi/5OR
08:00 kahrl       :11s/TP/A
08:01 kahrl       :21s/dst/src
08:05 kahrl       :108s/vl do/vr do
08:06 kahrl       I should have uploaded this in an etherpad instead :D
16:31 sapier      kahrl yes writing our own gui would give us full freedom but it's way more work than using irrlichts features ... I once tried to implement a simple gui tk in opengl decades ago. I was young and unexperienced but it's not a task to be done in a week ... I'd expect this to require about 3 months full time development until it supports at least basic concepts
16:32 sapier      speaking of treeview celeron is right that's not a limitation of irrlicht but formspec, I didn't implement formspec treeview because it'd be by far most complex thing formspec would support ... and textlist already added another level of complexity
16:59 sapier1     https://gist.github.com/sapier/6030971 quick and dirty draft how treeview could look like in formspec ... implementation is way more work
17:10 celeron55_  sapier1: i have a good feeling about this; it's a bit like making the next PJP
17:10 celeron55_  PHP*
17:10 celeron55_  *evil grin*
17:11 sapier1     did you forget a "dont"? :-)
17:12 sapier1     imho formspec shouldn't be made even more complex it'd be time for a sharp cut to add a new/existing gui description language
17:13 celeron55_  if formspecs are replaced with anything, my proposal would be a client-side lua API that allows the same functionality
17:15 sapier1     that'd be a solution with lots of things to add before anything will be visible again
17:15 BlockMen    why gets https://github.com/minetest/minetest/pull/772 not merged?
17:15 proller     sapier1, good place for json ;)
17:15 sapier1     not at all
17:15 sapier1     if client side lua there's no need for json
17:15 celeron55_  sapier1: pretty much any solution will have a lot of work involved
17:16 proller     long positional arrays is very bad
17:16 sapier1     of course
17:16 proller     its must be key-value
17:16 sapier1     converting 10 times back and forward is even worse
17:16 proller     but better than current
17:17 proller     and json covertor is very fast
17:17 sapier1     of course ... do I understand correctly that you want to implement this?
17:17 celeron55_  8))
17:18 proller     i want, but i have 1-3 hours of free time per week
17:18 celeron55_  i really don't see anything else worth it except a client-side lua API
17:18 sapier1     hmm I guess you'd be finished by hmm christmas
17:19 sapier1     yes client side lua is already on todo list but I guess formspec replacement won't be the first thing to be done
17:20 Exio4       sapier1: add a single thing in your todo list
17:20 Exio4       "rewrite minetest"
17:20 Exio4       you'll end faster doing that ;P
17:20 sapier1     my todo list is a queue
17:20 Exio4       hehe
17:21 sapier1     I don't have any skills for shaders etc so I guess I won't be capable of rewriting minetest ;-)
17:21 sapier1     and I don't want to do that
17:22 Exio4       it was a joke, as your "TODO" list are mainly 10k commits.. :P
17:22 sapier1     I suggest not adding more complex things to formspec and delay redesign to some time after clientside lua
17:23 Exio4       like the formspec menu, scriptapi separation..
17:23 sapier1     scriptapi was moving only ... mostly
17:23 BlockMen    oh, sapier, btw formspec. can i set a transparent bg-color at the new box element?
17:24 sapier1     it already should be transparent ... order of element definition within formspec is order of drawing so you should specify the box first if it shall be a background
17:25 BlockMen    hmm..ok. seems i had an issue then. thx
17:25 sapier1     exio4 rewriting formspec the client side lua way won't be a 10k commit
17:25 Exio4       more like 20k?
17:26 sapier1     I'd even expect more but at least in that area
17:27 Exio4       the client-side lua will be more than 10k, i guess, no idea how much would the formspec rewrite be
17:27 sapier1     I don't think so client side lua engine itself should be quite compact
17:28 sapier1     server <-> client lua transmission is hard to guess
17:28 celeron55_  a client-side GUI system could be made as a self-contained library and released by itself too for the benefit of any program (or at least any that uses irrlicht, if it requires irrlicht as the backend)
17:28 sapier1     and of course adding this in lua is meant to add more impressive gui elements
17:28 celeron55_  that will make the time a bit more worth it
17:29 sapier1     I'd guess there already are opengl toolkits
17:29 sapier1     but I don't know if we could use them along with irrlicht
17:29 Exio4       irrlicht can be using opengl, or not
17:30 sapier1     argh ... ok next difficulty level ... almost forgot about it
17:30 sapier1     opengl/directx dual toolkit ... I won't do that for sure :-)
17:30 Exio4       hehe
17:30 celeron55_  well there are toolkits that can use any renderer i guess
17:30 Exio4       it can be using a software renderer too!
17:31 sapier1     yes should be fast enough for gui
17:31 celeron55_  (and such could be made to use irrlicht then)
17:35 sapier1     still writing a complete tk is even more complex I guess it'd be a project on it's own
17:36 sapier1     I'd prefere kicking irrlicht developers ass to add those features we need ;-)
17:38 kahrl       as long as some minetest stuff only works in irrlicht 1.7, new irrlicht features are not useful
17:39 sapier1     we could include irrlicht sources too ... way less work then writing everything from scratch ... still I'd prefere not to do that
17:39 kahrl       the bundling (including modified sources) is bad enough already, don't add more librarie
17:39 kahrl       s
17:40 sapier1     so no "quick" solution at all
17:40 kahrl       why would you need to write everything from scratch?
17:40 kahrl       we already have intlGUIEditBox.cpp, for example
17:41 sapier1     that's been one of the suggestions in this discussion ... all meaning the gui toolkit only
17:42 sapier1     hmm you suggest only replacing parts with irrlicht code do I understand correct?
17:43 kahrl       if we need to make our gui elements for some reason, we could use the approach of building on irrlicht's elements's source code, yes
17:43 celeron55_  interfacing with some of the irrlicht internals isn't really possible
17:44 celeron55_  it limits what can be done in parts
17:44 kahrl       one of the downsides of using interfaces everywhere, but it has other benefits
17:44 celeron55_  irrlicht mostly hides itself behind virtual interfaces
17:44 sapier1     so we can only guess if it'd fix our problems
17:45 sapier1     I know I was looking for the textlist scrollbar ... but that isn't provided on top
17:47 kahrl       sapier1: you could walk the children of the listbox
17:48 sapier1     I still wouldn't know the previous scroll state
17:48 kahrl       well I don't know what you were trying to do
17:49 kahrl       oh, for fixing the problem that clicking on an element moves it to the bottom?
17:49 sapier1     atm if you click a element within a textlist that element is scrolled to bottom
17:49 sapier1     yes
17:50 kahrl       what happens in the code when the user clicks on an element?
17:51 sapier1     an event is sent and formspec is updated
17:51 sapier1     e.g. to show information about the now selected mod
17:51 Exio4       is the whole "mainmenu" re-created?
17:51 sapier1     formspec update results in recreation of menu ... exactly
17:52 Exio4       oh man, formspec is too limited
17:53 sapier1     maybe adding a more smart update mechanism specialy for texlists could be possible ... but no guarantee it'd fix anything
17:54 Exio4       well
17:54 sapier1     most easy option would be saving old scroll position prior cleanup and reuse that value uppon recreation
17:54 Exio4       did anyone try your big commit?
17:54 Exio4       why isn't it merged yet?
17:55 sapier1     but that option isn't available ... pilzadam did complain about using doubleclick to select mods so I had to readd old version ... made it configurable
17:55 Exio4       ew
17:55 Exio4       i actually like the double click to selecting mods, it is pretty intuitive
17:56 kahrl       huh? it isn't discoverable at all
17:56 sapier1     what isn't discoverable?
17:56 kahrl       you might as well tell the user to select a mod and press "e"
17:56 Exio4       what is the first thing you do ẅhen you don't know how to select something? double click!
17:57 Exio4       when*
17:57 sapier1     kahrl doubleclick is a well know selection method as far as I know
17:57 sapier1     but we don't need to argue again there's an option so everyone can decide what she/he wants
17:57 kahrl       I don't know any GUI where the only way to enable/disable options is double click
17:57 kahrl       the only widespread way I know is checkboxes
17:57 Exio4       what about "adding both"?
17:58 NakedFury   as far as I know double clicking IS the selection method. hell how do you start a program on computers? you double click its icon or shortcut
17:58 kahrl       NakedFury: starting a program != enabling an option
17:58 NakedFury   add double clicking and also add the check boxes.
17:58 kahrl       and options are not a solution because noobs (who would be the ones running into the problem) don't know about options
18:02 sapier1     kahrl checkboxes to select elements from a list cause lots of mouse moving
18:03 kahrl       sapier1: draw a checkbox next to each list element. done.
18:03 kahrl       I know, I know, formspec ;)
18:03 sapier1     exactly ;-
18:03 sapier1     )
18:04 sapier1     checkboxes are already readded and enabled by default
18:04 sapier1     those who like doubleclick can disable old style mod selection in settings ... if ppl think it's useless it can be removed if not maybe we can remove checkboxes ;-)
18:06 sapier1     btw pressing two fingers on a glass sliding them isn't a intuitive way for enlargeing too yet it's often used as example for intuitive gui ;-)
18:06 kahrl       about the scroll problem again: as far as I can tell, guiFormSpecMenu calls Environment->addListBox etc. each time the menu is regenerated
18:06 kahrl       would it be possible to instead reuse the listbox from the previous incarnation?
18:07 Exio4       it re-creates the whole formspec menu every time you do something, actually
18:07 sapier1     I thought about this yes ... it'd require to decide if the checkboxes content still matches the definition
18:07 sapier1     it could work but I can't tell for sure until I tried
18:09 sapier1     at least as long as content of listbox isn't changed
18:16 NakedFury   cant the formspec or menus be done in another engine?
18:17 sapier1     what do you mean with engine?
18:18 NakedFury   well if ijm saying crap ignore it but use something else if irrlicht version is not working.
18:18 sapier1     formspec isn't designed for gui data persistence that's the main issue
18:18 sapier1     we can hide this most of time but not everywhere
18:19 NakedFury   so couldnt we use say unity for formspec type stuff?
18:19 NakedFury   thats an example
18:20 sapier1     that was one of the suggestions replacing irrlicht gui elements by some other tookits elements (special case for this version is writing our own tk)
18:21 kahrl       NakedFury, the problem isn't irrlicht really, it's formspec
18:22 kahrl       I agree with c55 that client-side lua for GUI would probably be the best long-term approach
18:24 sapier1     me too but it's nothing to be done in a few hours and to be honest atm I've almost no interest in repeating mainmenu rewrite fights ;-) maybe in a couple of months ;-)
18:45 BlockMen    https://github.com/minetest/minetest/blob/master/src/guiFormSpecMenu.cpp#L1307 does that mean, that it would be possible to add a pressed image for image buttons?
18:47 BlockMen    #L1179  is the correct line
18:48 sapier1     1179?
18:49 sapier1     this is tabheader for me not related to image buttons at all
18:49 sapier1     for imagebutton if formspec supported specifying 2 textures the irrlicht gui element would support it yes
18:55 BlockMen    L1116 to L1189 is ImageButton
18:56 BlockMen    and ok, then i will add support for
18:57 sapier1     ok my fault did look at 1197
18:57 sapier1     but my answer is stil valid if formspec did support it irrlicht would
18:59 BlockMen    ya, thought so, thanks
18:59 BlockMen    do you know what m_gamedef != 0 means here? https://github.com/minetest/minetest/blob/master/src/guiFormSpecMenu.cpp#L1167
19:00 sapier1     yes I needed to add that check to avoid crashes when using formspec from mainmenu. Within mainmenu gamedef isn't available
19:01 kahrl       tbh I find that whole setup a bit weird
19:01 kahrl       couldn't GUIEngine (for example) implement gamedef and only provide a TextureSource?
19:01 BlockMen    sapier, ic
19:02 kahrl       that would also make it easier to fix any leaks that might happen
19:02 sapier1     no
19:03 sapier1     did you have a look what interfaces need to be implemented for gamedef? ;-)
19:03 kahrl       they can return NULL
19:03 kahrl       for example the client returns NULL when asked for craftdef manager
19:03 sapier1     still 20 interfaces for some textures?
19:04 kahrl       20 interfaces?
19:04 sapier1     ok 10 still ..
19:04 Exio4       wouldn't it be faster, as the texture could be cached somewhere?
19:04 kahrl       Exio4: possibly, not sure if irrlicht does that
19:05 sapier1     I don't think we have a speed problem for gui ... so no need to fix a problem that doesn't exist
19:05 kahrl       well, implementing gamedef seems cleaner to me than having an if ... else ... each time a texture is need
19:05 kahrl       needed*
19:06 kahrl       but whatever, not really important
19:06 sapier1     imho it's not at all cleaner to add two dummy classes each 10 dummy interfaces just to read a texture :-)
19:08 Exio4       i'm more concerned about the speed
19:08 Exio4       caching would speed the things up in systems with very slow-IO
19:08 Exio4       *cough*any phone around*cough*netbooks
19:08 Exio4       :P
19:09 sapier1     exio4 there are about 15 + modstore screenshot count images within gull mainmenu
19:09 sapier1     4 of them might be larger than icon size
19:09 Exio4       ah
19:09 sapier1     I guess even netbooks can handle this
19:09 Exio4       i should try to compile MT in my netbook
19:09 Exio4       it'll take "only" 30 minutes
19:10 kahrl       as long as they are not reloaded each time you select something, it's fine
19:10 sapier1     the big ones aren't reloaded at all the others are
19:11 kahrl       fine enough
19:11 sapier1     ok at all isn't quite true ... of course they need to be loaded if they are hidden
19:12 hmmmm       o
19:12 Exio4       p
19:12 hmmmm       was cleaning my keyboard
19:13 sapier1     :-) exio4 you could test it on a netbook it'd be interesting to know .. I gues switching from singleplayer to other tabs and back will be most critical event
19:14 sapier1     if this works fine everything else most likely will do too
19:14 hmmmm       I don't see anything wrong with GUIEngine implementing a TextureSource (if that's what it does)
19:15 hmmmm       and yeah, a Gamedef is pretty damn heavyweight
19:15 sapier1     I wouldn't have a problem with texture source but that wouldn't be enough
19:16 sapier1     so why bother if I still need to handle missing gamedef
19:16 hmmmm       oh, you need a gamedef for a texturesource?
19:16 hmmmm       that's kinda dumb and i think ought to be changed
19:16 sapier1     formspec uses gamedef to get texturesource as well as item ...
19:17 sapier1     so I need to check for gamedef beeing available in any case prior accessing it
19:17 hmmmm       see, this is ridiculous
19:18 hmmmm       i don't like that entire setup and it turns out to be inefficient abstraction
19:18 sapier1     that's not a problem as there aren't items in mainmenu :) if someone tried to show a inventory there I don't have any concerns in driving him crazy because it doesn't show up :)
19:21 BlockMen    can this work? -> https://github.com/BlockMen/minetest/commit/70f4e4f97f8d594553646affbdb789ce2c21fcd3
19:23 sapier1     yes
19:23 sapier1     but don't forget to update lua_api.txt
19:24 BlockMen    ok :)
19:24 sapier1     wait
19:25 sapier1     you need to update the parts.size() == 7 part too
19:26 sapier1     it's required to be >= 7 now
19:28 kahrl       sapier1: maybe instead of passing a gamedef to guiFormSpecMenu, one could pass a TextureSource and an ItemDefManager
19:28 kahrl       and the ItemDefManager part could be NULL if it's in the main menu
19:30 BlockMen    sapier1, where??
19:30 ShadowNinja BlockMen: You should probably set the new one to >= 8 too.
19:31 sapier1     that only matters if someone wants to add a nineth parameter
19:31 sapier1     L1139 in original code
19:32 BlockMen    oh...right
19:32 BlockMen    ShadowNinja, why?
19:33 BlockMen    you mean that ? -> https://github.com/BlockMen/minetest/commit/70f4e4f97f8d594553646affbdb789ce2c21fcd3#L0R1189
19:33 sapier1     kahrl yes that'd be possible and would improove code
19:34 sapier1     no
19:36 sapier1     https://github.com/minetest/minetest/blob/master/src/guiFormSpecMenu.cpp#L1139
19:36 ShadowNinja 1149 & 1176
19:37 BlockMen    sapier1, i ment ShadowNinja. 1139 is correct now
19:37 BlockMen    *+ed
19:37 BlockMen    ShadowNinja, why >= 8 ??
19:38 ShadowNinja BlockMen: To make adding more fields easier.
19:38 sapier1     I'd expect ppl to read and understand code prior adding fields without asking ;-)
19:39 ShadowNinja Why does the menu have two cloud objects?
19:39 sapier1     if we do so all == checks should be replaced in that file
19:39 ShadowNinja There is a global one, and a GUIEngine one.
19:40 sapier1     global one isn't available from gui
19:40 BlockMen    sapier1, agree
19:40 ShadowNinja Hmmm, why?
19:40 BlockMen    i will let ==
19:40 sapier1     because the global one needs to be present after gui is closed while gui cleans up everything it uses
19:42 ShadowNinja sapier1: Then let main() manage the clouds.
19:42 sapier1     I can't do that
19:43 sapier1     they need to be updated by guiengine processing loop
19:44 ShadowNinja Where is GUIEngine::run() called?
19:44 sapier1     https://github.com/minetest/minetest/blob/master/src/guiEngine.cpp#189
19:46 sapier1     btw those clouds have been within old c++ mainmenu too
19:46 sapier1     I guess the global ones have been added later
19:48 ShadowNinja Hmmm, so currently main() just creates and deletes it. Perhaps there could be a global menucloud update function that it would call. That way we wouldn't copy code from the loading screen.
19:49 ShadowNinja That way we only have g_menuclouds
19:49 sapier1     but that'd add additional dependencys and really global variables
19:49 Exio4       sapier1: trying the lua main menu
19:49 Exio4       takes a bit to load, then it is pretty fast
19:49 sapier1     you know global variables == BAD
19:49 sapier1     exceptions just proove that rule ;-)
19:50 ShadowNinja Yes, but it would also fix the bug where the clouds change when the loadinc screen opens.
19:50 Exio4       outside the part of not being able to enable "mods" in my run in place build
19:50 sapier1     if this is the last bug to be fixed I'd be glad to fix it ;-)
19:50 Exio4       the new main menu does what the old one did in a pretty fast way?
19:51 sapier1     hmm run in place still not working? :-/
19:52 Exio4       no idea, with the latest latest commit, but the build i used yesterday doesn't work here
19:52 Exio4       will try on my desktop with an updated build
19:52 Exio4       this is slow to compile, play and all ;P
19:53 sapier1     I didn't change something related to mods in general yesterday
19:53 Exio4       sapier1: switching tabs is pretty fast, outside the first time "loading" it is pretty fast here
19:54 Exio4       anything that is "resource expensive" that i could try on my netbook?
19:54 sapier1     I gues first time is starting up lua engine
19:54 Exio4       probably
19:54 sapier1     switching from singleplayer to other tabs
19:54 sapier1     and of course online modstore
19:55 Exio4       the online modstore is slow here because my shitty network, i have other bottleneck in that case :P
19:56 kahrl       ah, that's why my code isn't working!
19:56 kahrl       irrlicht multiplies matrices in the "wrong" order
19:56 Exio4       what?
19:56 kahrl       fun
19:56 Exio4       irrlicht has brainfuck bindings? didn't know ;P
19:56 kahrl       http://irrlicht.sourceforge.net/forum/viewtopic.php?t=37594
19:57 Exio4       sapier1: the only "bad side" is the loading time, but after that, it works pretty well
19:57 PilzAdam    kahrl, would it be a good idea to add a flag to itemdef that disables generating inventory visuals? in mods like stairs+, pipeworks or the mesecons wire there are many nodes that are never shown in the inventory
19:58 kahrl       PilzAdam, maybe
19:58 Exio4       will they get generated in runtime if you use /giveme?
19:59 Exio4       would*
20:00 kahrl       I think they should
20:00 kahrl       so, add a flag, and check it in client.cpp:2891
20:00 kahrl       should do it
20:02 kahrl       well, or add a function similar to ItemDefManager::getAll that returns only items with the flag, and call it in client.cpp:2885
20:03 kahrl       that way the progress bar would be more accurate
20:07 VanessaE    oh G*d yes, please
20:07 VanessaE    (the aforementioned flag)
20:08 VanessaE    though it wouldn't apply to stairsplus, because everything it has IS shown in the inventory, by way of the circular saw
21:28 kahrl       I implemented the software rasterizer for inventorycube, a single inventorycube call now takes between 35 and 80 microseconds
21:29 VanessaE    how long was it before?
21:29 kahrl       around 150 microseconds with the raytracer version
21:29 VanessaE    ouch
21:29 VanessaE    nice improvement
21:30 kahrl       it's still a bit glitchy and I need to add antialiasing (increasing the duration a bit again)
21:30 kahrl       I think for antialiasing I'll just let it render to a 128x128 texture and scale it to 64x64
21:30 VanessaE    that should work, as long as the scale method is something better than nearest neighbor
21:31 kahrl       don't know about that
21:32 kahrl       anyway, pushed what I have to my optimize_invtex branch
21:32 VanessaE    well if you render to 128px and scale down without a good algorithm, you'll end up with worse results than rendering directly to 64px
21:32 kahrl       yeah
21:35 VanessaE    ok, I'll bite. :)
21:43 VanessaE    24 seconds to sign in, 141 seconds total.
21:44 VanessaE    wonder if I missed a step somewhere.  hrm.
21:44 VanessaE    (that's 20 seconds faster than upstream, but about 15 seconds slower than your best from the other day)
22:24 kahrl       well I don't know why it would be faster for me but so much slower for you
22:25 kahrl       maybe cache properties, but can they have such a large effect?
22:25 kahrl       and you didn't add or update any mods since then?
22:28 VanessaE    well recall I'm testing with those 512px textures and a very large game (though nothing in HDX has been updated since my last test, so the times should have been similar)
22:28 kahrl       true, maybe they cause a different memory access pattern
22:29 VanessaE    best way to stress test something is to beat the shit out of it ;)
22:29 kahrl       though in theory it shouldn't be much different
22:29 Exio4       kahrl: what did you do for making it faster? (to the algorithm)
22:29 kahrl       Exio4: rasterization instead of raytracing
22:30 Exio4       ah
22:30 kahrl       VanessaE: also the raytracer used optimized access to img_dst through img_dst->lock(), the rasterizer uses img_dst->setPixel()
22:30 kahrl       maybe that makes a difference
22:30 kahrl       I wanted to use the simple way to get it working first
22:31 VanessaE    I take it the raytrace version is what I tested last time then?
22:31 VanessaE    (I don't remember)\
22:31 kahrl       yeah
22:31 VanessaE    hm
22:32 Exio4       VanessaE: can you try two times?
22:32 VanessaE    sure
22:32 Exio4       doing the test, disconnect and try again
22:32 kahrl       Exio4: right, it could be related to disk cache too
22:32 Exio4       i was writing that :P
22:32 VanessaE    THAT is possible
22:32 Exio4       "maybe the cache was doing its job"
22:33 VanessaE    as my machine's been rebooted a couple of times since the last test
22:35 VanessaE    24s to sign in, 141 seconds total.
22:37 VanessaE    odd.  I wonder why the slow-down.
22:37 VanessaE    with my box, who the hell knows :-)
22:38 kahrl       is the cpu using the same frequency?
22:38 VanessaE    hm, good question
22:38 kahrl       well, you could retry the old version
22:38 VanessaE    yep, all 6 cores are maxed out at 2.8GHz
22:39 kahrl       strange
22:39 Exio4       disable two cores and overclock it!
22:39 * Exio4     runs
22:39 Exio4       :P
22:39 VanessaE    (I got tired of ondemand mode causing little stalls in the game, so I locked it on 'performance' mode)
22:39 Exio4       ondemand is pretty sucky for games, yeah
22:42 kahrl       it could be due to a difference in cpu architecture
22:42 kahrl       the rasterizer and raytracer use different patterns of integer and FPU instructions, maybe my cpu just handles the new one better than yours
22:43 VanessaE    possible.  mine's a Phenom II X6, if that matters
22:43 Exio4       kahrl: that is what i'm thinking
22:43 VanessaE    (here's the part where calinou would normally insert some snarky comment ;) )
22:44 Exio4       kahrl: where is the old code, btw?
22:45 kahrl       the rasterizer has no branches in the inner loop, the raytracer does, maybe my i5 doesn't handle those well
22:45 kahrl       wait, no, forgot that getPixel and setPixel have branches
22:45 kahrl       Exio4: git checkout kahrl/optimize_invtex^
22:52 Exio4       oh
22:52 Exio4       didn't see the old commit was still here
23:00 Exio4       57804 is the average with the older
23:01 Exio4       of whatever unit it is :P
23:01 Exio4       recompiling/compiling the new one
23:01 kahrl       INFO[main]: inventorycube took 68000ns
23:01 kahrl       now that reminds me of my old calculator
23:03 Exio4       damn, the lua menu took like 4s to start :P
23:04 Exio4       50998 the average with the newer
23:04 VanessaE    where are you getting these averages from?
23:04 Exio4       list=(`grep inventorycube ~/.minetest/debug.txt | sed 's/.*took \([0-9]*\)[a-z]s/\1/' | sort`); b=0;a=0; for i in ${list[@]}; do let a++; let b=b+$i; done; let c=b/a; echo $c
23:05 Exio4       inb4 it sucks
23:06 Exio4       it was a loop coded because didn't want to open a shell or make a correct version :P
23:07 VanessaE    holy shit on a shingle
23:07 VanessaE    156089.
23:07 VanessaE    I better run that again with a clean debug.txt
23:07 Exio4       of course
23:08 Exio4       if not, it'll be taking all the numbers
23:10 VanessaE    148060
23:11 VanessaE    er 148460
23:12 hmmmm       [06:45 PM] <kahrl> the rasterizer has no branches in the inner loop,  <----- really really good candidate for SSEing
23:13 kahrl       hmmmm: I realized that was wrong
23:13 hmmmm       aw
23:14 hmmmm       so wait a minute, how long does the inventory cube generation take precisely
23:14 hmmmm       on vanessae's setup
23:14 kahrl       well, I just pushed a new commit
23:14 Exio4       [18:28:52] <+kahrl> I implemented the software rasterizer for inventorycube, a single inventorycube call now takes between 35 and 80 microseconds
23:14 Exio4       ah
23:14 hmmmm       i'm talking total time
23:14 kahrl       Exio4: now 15 to 30 microseconds here :D
23:15 kahrl       usually 15
23:15 VanessaE    hmmmm: the above number is with kahrl's latest commit (well, not the one he *just* pushed), 512px textures as usual for such tests.
23:15 hmmmm       24 seconds?
23:16 hmmmm       that's "to log in"
23:16 VanessaE    24s to sign in, 141 seconds total
23:16 kahrl       holy fsm, the average is actually 14087ns
23:16 VanessaE    so 117s for the rendering part.
23:16 Exio4       kahrl: how did you calc it? :P
23:16 kahrl       Exio4: guess how ;)
23:17 Exio4       ;P
23:17 hmmmm       wow if it is 141 seconds, then additional attempts at optimization are not misguided
23:17 Exio4       17398ns here, kahrl
23:17 kahrl       that's pretty good, eh?
23:18 VanessaE    hmmmm: the odd thing is the best time I got was a few days ago, 125s (so ~99 to 101s for the rendering step)
23:18 Exio4       yeah :P
23:18 hmmmm       odd
23:18 VanessaE    now it's actually slowed down, inexplicably.
23:18 Exio4       i'm using a bulldozer x6100 and it takes less here
23:18 Exio4       i don't get it
23:18 Exio4       well, maybe the turbo frequency is doing something
23:19 kahrl       VanessaE: slowed down every with the very newest commit?
23:19 kahrl       s/every/even
23:19 hmmmm       ahh yes that would make a big difference
23:19 VanessaE    kahrl: haven't tried the one you just pushed.  gimme a few mins.
23:25 VanessaE    139 seconds, 43075 for the average thingy
23:26 Exio4       using your game, 21.4k is my average with the last commit
23:26 Exio4       (vs the 17.4k i have with default game?)
23:27 Exio4       all of this with 16x though, i found what happens :P
23:27 kahrl       VanessaE: do you know how that average compares to the raytracer?
23:27 VanessaE    kahrl: no, but if you can point me to that raytrace commit, I'll try that against git HEAD if you like.
23:28 kahrl       https://github.com/kahrl/minetest/commit/c27edccd062cda1cbb5a36b44715ce22020fb171
23:28 VanessaE    bingo
23:28 VanessaE    ok, gimme a few.
23:33 VanessaE    here goes.
23:35 VanessaE    141 seconds.
23:35 VanessaE    wtf?
23:36 VanessaE    131901 for the average
23:36 VanessaE    wtF?
23:37 Exio4       better than before but not that 'good'
23:38 VanessaE    yeah but it was 43075 just before.
23:38 VanessaE    (when the time was 139s)
23:38 VanessaE    there's something really strange going on here.
23:43 VanessaE    just to be sure, lemme see how git HEAD performs.
23:43 NakedFury   hey guys what are you performing here?
23:44 VanessaE    speed tests of the texture rendering code
23:44 Exio4       ehm, texture rendering?
23:44 Exio4       only inventorycube
23:44 VanessaE    well that part
23:44 VanessaE    just being generic :P
23:45 Exio4       and well, by checking, 697 calls are about 14.5~ms
23:45 Exio4       where is the slow part?
23:47 Exio4       for me, that is
23:50 VanessaE    163 seconds with git HEAD.  131901 for the average.
23:50 VanessaE    so the base speed is still accurate to within a second or so.
23:51 Exio4       count: 697 nodes, total: 14.450ms, average: 20732ns
23:51 kahrl       how did you get the average with git HEAD?
23:51 Exio4       with your game
23:51 Exio4       kahrl: that, too
23:51 kahrl       it doesn't print the inventorycube timing
23:51 VanessaE    kahrl: nevermind, that was in error
23:51 Exio4       VanessaE: are you cleaning your debug.txt before every test?
23:51 VanessaE    the 163 seconds still stands.
23:51 VanessaE    Exio4: indeed so.
23:52 Exio4       count: 69 nodes, total: 1.204ms, average: 17449ns
23:52 VanessaE    yeah, just ignore that average, that musta been an old $c value from before or something
23:52 kahrl       well, I think inventorycube is optimized enough :)
23:52 Exio4       yeah
23:52 kahrl       now need to remove the graphical glitches and add antialiasing
23:52 VanessaE    so yeah, your code is definitely faster than HEAD, but I still wonder where that 125s disappeared to
23:53 Exio4       if it doesn't gets over 20ms with 700 nodes "inventorycube(d)" here, i guess it is very optimized :P
23:53 kahrl       VanessaE: more programs running in the background now?
23:53 VanessaE    kahrl: nope, just a couple of terminals and my web browser with a paused youtube video, same as before.
23:53 Exio4       the kernel should be pretty good when sharing resources unless she is running something really intensive
23:54 Exio4       (6 'real' cores, not shared like bulldozer's or hyperthreading)
23:54 kahrl       VanessaE: I've seen gnash sometimes use up considerable CPU time with a paused youtube video
23:54 PilzAdam    lol gnash
23:55 Exio4       ^ nvidia developer
23:55 VanessaE    kahrl: I just checked, it uses practically zilch when paused (this is 'real' flash though)
23:55 Exio4       :>
23:57 Exio4       what others thing about loading would need to be optimized?
23:57 Exio4       (i wonder)
23:57 kahrl       VanessaE: if you comment out the part between '// "Interior"' and 'delete[] solidity' in extrudeARGB, how does loading take?
23:58 VanessaE    lemme check.
23:58 kahrl       how long*
23:58 PilzAdam    Exio4, speeding up mapblock mesh genration would be generally an improvement
23:58 PilzAdam    and you would "see" the world faster when joining
23:59 kahrl       Exio4: if nodebox support was added to inventorycube, that might give another speedup