| Time |
Nick |
Message |
| 00:13 |
|
sapier joined #minetest-dev |
| 00:56 |
|
Taoki joined #minetest-dev |
| 01:50 |
|
Miner_48er joined #minetest-dev |
| 03:39 |
|
ffoxin joined #minetest-dev |
| 04:18 |
|
ch98 joined #minetest-dev |
| 04:21 |
|
NakedFury joined #minetest-dev |
| 04:24 |
|
neko259 joined #minetest-dev |
| 05:34 |
|
sapier joined #minetest-dev |
| 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:02 |
|
NakedFury joined #minetest-dev |
| 07:11 |
|
hmmmmm joined #minetest-dev |
| 07:16 |
|
darkrose joined #minetest-dev |
| 07:44 |
|
Calinou joined #minetest-dev |
| 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 |
| 08:51 |
|
Calinou joined #minetest-dev |
| 08:53 |
|
Zeg9 joined #minetest-dev |
| 08:56 |
|
iqualfragile joined #minetest-dev |
| 09:35 |
|
SpeedProg joined #minetest-dev |
| 09:59 |
|
Zeg9 joined #minetest-dev |
| 10:02 |
|
proller joined #minetest-dev |
| 10:12 |
|
Zeg9 joined #minetest-dev |
| 10:25 |
|
Zeg9 joined #minetest-dev |
| 10:33 |
|
iqualfragile joined #minetest-dev |
| 10:44 |
|
PilzAdam joined #minetest-dev |
| 11:01 |
|
Calinou joined #minetest-dev |
| 11:02 |
|
smoke_fumus joined #minetest-dev |
| 11:18 |
|
Zeg9_ joined #minetest-dev |
| 11:28 |
|
Zeg9 joined #minetest-dev |
| 11:43 |
|
proller joined #minetest-dev |
| 13:55 |
|
serengeor joined #minetest-dev |
| 14:45 |
|
Zeg9 joined #minetest-dev |
| 14:57 |
|
hdastwb joined #minetest-dev |
| 15:04 |
|
Calinou joined #minetest-dev |
| 15:07 |
|
iqualfragile joined #minetest-dev |
| 15:11 |
|
PilzAdam joined #minetest-dev |
| 15:23 |
|
VanessaE joined #minetest-dev |
| 15:33 |
|
NakedFury joined #minetest-dev |
| 15:53 |
|
hmmmm joined #minetest-dev |
| 16:08 |
|
proller joined #minetest-dev |
| 16:27 |
|
sapier joined #minetest-dev |
| 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:58 |
|
sapier1 joined #minetest-dev |
| 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:01 |
|
ecube joined #minetest-dev |
| 17:01 |
|
ecube joined #minetest-dev |
| 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 joined #minetest-dev |
| 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:32 |
|
ecube_ joined #minetest-dev |
| 17:35 |
|
ecube joined #minetest-dev |
| 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 |
|
ecube_ joined #minetest-dev |
| 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 |
|
ecube joined #minetest-dev |
| 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:16 |
|
Jordach joined #minetest-dev |
| 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:20 |
|
neko259 joined #minetest-dev |
| 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:28 |
|
sapier joined #minetest-dev |
| 18:37 |
|
sapier left #minetest-dev |
| 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 |
|
PilzAdam joined #minetest-dev |
| 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 |
|
proller joined #minetest-dev |
| 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:41 |
|
salamanderrake joined #minetest-dev |
| 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:47 |
|
iqualfragile joined #minetest-dev |
| 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 |
| 20:46 |
|
ch98 joined #minetest-dev |
| 20:56 |
|
BlockMen left #minetest-dev |
| 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:36 |
|
ecube joined #minetest-dev |
| 21:36 |
|
ecube joined #minetest-dev |
| 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) |
| 21:50 |
|
sapier1 left #minetest-dev |
| 21:51 |
|
ch98 left #minetest-dev |
| 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 |
