Time |
Nick |
Message |
00:27 |
|
sokomine joined #minetest-dev |
01:56 |
|
djcyberslash joined #minetest-dev |
02:29 |
|
djcyberslash joined #minetest-dev |
02:51 |
|
aoper joined #minetest-dev |
03:01 |
|
SpeedProg joined #minetest-dev |
03:07 |
|
Mallot1 joined #minetest-dev |
03:20 |
|
ffoxin joined #minetest-dev |
04:57 |
|
ch98 joined #minetest-dev |
05:08 |
|
neko259 joined #minetest-dev |
05:53 |
|
celeron55 joined #minetest-dev |
06:26 |
|
Taoki[laptop] joined #minetest-dev |
06:53 |
|
Jordach joined #minetest-dev |
06:53 |
|
Taoki[mobile] joined #minetest-dev |
07:04 |
|
darkrose joined #minetest-dev |
07:04 |
|
darkrose joined #minetest-dev |
08:29 |
|
Calinou joined #minetest-dev |
09:03 |
|
serengeor joined #minetest-dev |
09:38 |
|
proller joined #minetest-dev |
10:09 |
|
PilzAdam joined #minetest-dev |
11:09 |
|
Zeg9 joined #minetest-dev |
11:43 |
|
Calinou joined #minetest-dev |
13:21 |
|
proller joined #minetest-dev |
13:51 |
|
bulldog98 joined #minetest-dev |
13:58 |
|
Kacey joined #minetest-dev |
13:58 |
|
Kacey left #minetest-dev |
14:02 |
|
whirm joined #minetest-dev |
14:05 |
|
bulldog98 joined #minetest-dev |
14:05 |
bulldog98 |
hi I'm prepering a performance impovement for minetest (just rewritten for loops), and I wanted to know if I should do a commit per file or a huge commit to propose a pull request on github |
14:06 |
thexyz |
what did you change? |
14:06 |
bulldog98 |
.size() out of the for loop, if the loop didn't changed the size of the vector |
14:07 |
thexyz |
and is there any performance increase? |
14:08 |
bulldog98 |
there should, because it removes an n from the functions O-time |
14:09 |
bulldog98 |
eg. simply going over a list changes form O(n²) to O(n) |
14:09 |
thexyz |
.size() is O(1) for vectors |
14:09 |
bulldog98 |
ah ok, didn’t know that |
14:10 |
thexyz |
it is not specified for lists |
14:10 |
thexyz |
(it's specified in c++11 though) |
14:10 |
thexyz |
it's safer to assume that list's size() is O(N) |
14:11 |
bulldog98 |
also I found a g_settings->getU16("media_fetch_threads") which should be O(log(n)) |
14:16 |
thexyz |
well that's probably true |
14:19 |
thexyz |
but I don't think this is important |
14:19 |
thexyz |
this code isn't called very often |
14:19 |
bulldog98 |
true |
14:25 |
|
proller_ joined #minetest-dev |
14:45 |
|
Zeg9 joined #minetest-dev |
14:47 |
|
Calinou joined #minetest-dev |
15:04 |
|
rubenwardy joined #minetest-dev |
15:06 |
|
ch98 joined #minetest-dev |
15:26 |
|
NakedFury joined #minetest-dev |
15:34 |
|
hmmmm joined #minetest-dev |
15:43 |
|
proller joined #minetest-dev |
15:50 |
|
ch98 joined #minetest-dev |
15:55 |
proller |
we need in somesthing ~auto profiling |
15:56 |
proller |
or lot of #if PROFILE ...count here .... #endif |
16:04 |
|
Calinou joined #minetest-dev |
16:16 |
|
Taoki[laptop] joined #minetest-dev |
16:36 |
|
BlockMen joined #minetest-dev |
16:41 |
|
SpeedProg1 joined #minetest-dev |
16:51 |
|
EdB joined #minetest-dev |
16:58 |
|
proller joined #minetest-dev |
17:20 |
|
neko259 joined #minetest-dev |
17:21 |
|
BlockMen joined #minetest-dev |
17:31 |
|
Calinou joined #minetest-dev |
17:35 |
|
PilzAdam joined #minetest-dev |
17:54 |
|
BackupCoder joined #minetest-dev |
17:59 |
|
Mallot1 joined #minetest-dev |
18:05 |
|
salamanderrake joined #minetest-dev |
18:05 |
|
proller joined #minetest-dev |
18:05 |
celeron55 |
PilzAdam: what do you think would be needed in order to minetest_game getting good sounds? |
18:05 |
PilzAdam |
arent the current sounds good enough? |
18:06 |
Calinou |
grass sound is low quality |
18:06 |
celeron55 |
certain important ones of the new ones are ridiculously bad |
18:06 |
celeron55 |
for example grass and sand walking sounds |
18:07 |
Calinou |
sand is low quality too |
18:07 |
Calinou |
really, we can afford 320kbps oggs... :P |
18:07 |
celeron55 |
i wonder what would be needed to get people to care about these kinds of details and _actually_ make them better when they see they're bad |
18:07 |
celeron55 |
Calinou: they're not low quality, they're simply bad sounds |
18:08 |
proller |
want to merge https://github.com:443/minetest/minetest/pull/830/files |
18:08 |
Calinou |
"i wonder what would be needed to get people to care about these kinds of details" like in any FOSS game, people who critisize it, but actually work on it to improve |
18:19 |
celeron55 |
Calinou: yeah, where do i buy those? |
18:19 |
Calinou |
nowhere, they don't exist |
18:19 |
celeron55 |
i give lollipops |
18:20 |
celeron55 |
proller: that's quite a lot of stuff... humm |
18:20 |
celeron55 |
proller: what's your end goal with all this stuff you're doing? |
18:21 |
proller |
rain & snow now working in lua module |
18:22 |
proller |
goal - to make game more dynamic and intresting |
18:22 |
proller |
season change |
18:22 |
proller |
water freeze at winter |
18:23 |
|
sfan5_ joined #minetest-dev |
18:25 |
celeron55 |
are you sure you can manage those ABMs to not be terrible resource hogs? |
18:25 |
celeron55 |
...and other stuff too |
18:26 |
hmmmm |
proller, hey. |
18:26 |
hmmmm |
I looked at what you did, and my biggest problem with it is storing temperature/humidity in the mapblocks |
18:27 |
celeron55 |
that's what i inspected at first too; it appears it's not stored on disk but is transferred over network |
18:27 |
proller |
celeron55, no problem to decrease chance/ inc interval if it will slow |
18:27 |
celeron55 |
some kind of a document on this would be good |
18:27 |
hmmmm |
there are lots of problems with this |
18:27 |
proller |
yes, no need to store, but need to transfer to use in cloud/fog generation later |
18:27 |
hmmmm |
with sending that much more data |
18:27 |
proller |
8 bytes in mablock? |
18:28 |
celeron55 |
lol 8D |
18:28 |
hmmmm |
oh, i thought it was a value for each point in the mapblock |
18:28 |
hmmmm |
derp |
18:28 |
proller |
no, |
18:28 |
proller |
no need in big precision for now |
18:28 |
celeron55 |
my viewpoint on this is that it's cool if it works, but it could end up being a disaster if it doesn't |
18:28 |
hmmmm |
still though, a mapblock serialization bump is kinda... if you're adding a field, why not keep the version the same, and put it in the try/catch block |
18:28 |
hmmmm |
right |
18:29 |
proller |
it works on my server |
18:29 |
hmmmm |
"works for me" is what you said about finite liquids and we know how that turned out :p |
18:29 |
|
salamanderrake joined #minetest-dev |
18:29 |
proller |
celeron55, and its now disabled by default |
18:29 |
proller |
it cant works with old liquids 8) |
18:30 |
proller |
hmmmm, i can make try/catch, but i think version up is more correct |
18:30 |
hmmmm |
anyway proller |
18:30 |
hmmmm |
I was going to change heat and humidity to u8 values |
18:31 |
celeron55 |
the version bump is correct in my opinion |
18:31 |
proller |
heat can be negative |
18:31 |
proller |
s8 ? |
18:31 |
celeron55 |
i think we can conclude that this really needs testing, but on the other hand requiring that isn't fair because we know that nobody will care to test anything anyway |
18:31 |
celeron55 |
8) |
18:32 |
proller |
but +128c is not very big.. |
18:32 |
hmmmm |
i don't know.... letting it be signed is okay I guess, you just need it to map it to certain values |
18:33 |
hmmmm |
with a u8, we'd be able to have it range from something more sane like 208 to -40 |
18:33 |
hmmmm |
it doesn't matter |
18:33 |
hmmmm |
it's just what's being stored internally |
18:33 |
proller |
4 bytes economy.. |
18:33 |
hmmmm |
well it adds up when you have maps of these values |
18:33 |
proller |
how average block size now? |
18:34 |
hmmmm |
i would like it if heat/humidity values were consistent throughout minetest |
18:34 |
celeron55 |
i would use s16 for both |
18:34 |
proller |
but minetest uses f32 |
18:35 |
proller |
s16 ++ |
18:35 |
hmmmm |
right now? yes |
18:35 |
proller |
like it |
18:35 |
hmmmm |
like I said, I wanted to change that |
18:35 |
hmmmm |
heat/humidity should be discrete values anyway for something i have planned |
18:35 |
celeron55 |
but it doesn't really matter what it stores in RAM, the network protocol just needs to be adjusted |
18:35 |
celeron55 |
oh well, if hmmmm has some plans, then those might matter |
18:35 |
hmmmm |
consistency matters |
18:36 |
hmmmm |
celeron, well not really in this case |
18:36 |
hmmmm |
proller's heat/humidity has a granularity of a mapblock while I use it at the granularity of a node |
18:36 |
proller |
will change to s16... 5 mins.. |
18:36 |
hmmmm |
s16 fine, whatever |
18:36 |
celeron55 |
what should this be consistent with? you should, like, tell |
18:36 |
hmmmm |
the whole biome shit |
18:37 |
celeron55 |
well just say what the biome shit does so proller can do the same thing :P |
18:37 |
hmmmm |
i don't really have specific plans because i haven't started this |
18:37 |
hmmmm |
but the thing is to have biomedefmanager have a biome cache |
18:38 |
hmmmm |
each mapblock has an approximate temperature with proller's thing, and each biome has its specific tempeature point, so somehow I can combine the two to "guess" a temperature for specific nodes without having to explicitly store the values |
18:39 |
hmmmm |
well nevermind this, like i said, none of it is done at the moment |
18:39 |
celeron55 |
oh whatever, it's not that persistent as it's just a properly versioned network protocol change |
18:39 |
celeron55 |
the real question is if we want to go to this direction |
18:39 |
hmmmm |
it's just that i plan on using discrete values for heat and humidity with my stuff, so it ought to be the same for consistency purposes |
18:39 |
hmmmm |
this direction? what do you mean, hardcoded weather effects? |
18:39 |
celeron55 |
i guess proller might be dedicated enough to pull it to a reasonable end result |
18:40 |
hmmmm |
I personally wouldn't want that, this seems totally like a mod thing. but it's optional. |
18:40 |
celeron55 |
well, weather at all; and if to do it this way, and whatever like that |
18:40 |
celeron55 |
those big questions |
18:41 |
hmmmm |
erm |
18:41 |
hmmmm |
these issues aside |
18:42 |
hmmmm |
proller, if you're writing code for source files that aren't "yours", you should try to be clean about it all |
18:42 |
hmmmm |
stop with the 100+ column lines, at the very least |
18:42 |
celeron55 |
whether this should be a mod or not depends on what we consider being the scope of the engine |
18:42 |
hmmmm |
the soft limit is 80, the hard limit is 90 |
18:42 |
proller |
ok |
18:42 |
celeron55 |
...and that scope isn't defined well at all |
18:43 |
hmmmm |
and you have a Settings:: call right in your ServerMap::get*() |
18:43 |
hmmmm |
you're not concerned with that??? |
18:44 |
hmmmm |
also, can you try to please put if blocks on separate lines |
18:44 |
hmmmm |
if (env->getGameTime() - block->humidity_time < 10) return block->humidity; for example is better like if (env->getGameTime() - block->humidity_time < 10) \n\t return block->humidity; |
18:45 |
hmmmm |
that whole "if block on the same line" was only ever used in scriptapi things, and for redundant things such as type checks |
18:45 |
hmmmm |
if it were up to me, i would have none of it at all |
18:45 |
celeron55 |
so... i take this as hmmmm not objecting the merging of that, once it's tidied up? |
18:46 |
hmmmm |
yes |
18:46 |
hmmmm |
aside from code style, there are other things that need to be cleaned up but require effort on my part in order to make it happen |
18:46 |
hmmmm |
e.g. setting sensible ranges for the biome temp/humidity points |
18:46 |
proller |
hmmmm, settings called every 10 seconds, result is cached in mapblock |
18:47 |
hmmmm |
that's fine then |
18:47 |
hmmmm |
by the way, sorry I haven't been around the past week or so, been having interviews |
18:49 |
celeron55 |
okay, it is then decided that minetest will have, at some extent, built-in handling for weather (particular weathers will hopefully be defined by mods) |
18:50 |
proller |
hmmmm, no priblem, its got better in this time 8) |
18:50 |
celeron55 |
i have a feeling that this actually de-fuzzies the scopes of multiple things; maybe for the better... |
18:51 |
celeron55 |
or maybe not. but i don't have the experience to really tell that 8-) |
18:52 |
celeron55 |
proller: i'd prefer to hear the opinion of kahrl at least still |
18:53 |
celeron55 |
and someone else just in case someone has some good points |
18:53 |
celeron55 |
so don't merge until tomorrow or so |
18:54 |
BlockMen |
hey, not that topic, but can someone tell me where i find this function? -> https://github.com/minetest/minetest/blob/master/src/hud.cpp#L209 |
18:55 |
|
Taoki[laptop] joined #minetest-dev |
18:55 |
celeron55 |
in irrlicht's documentation |
18:55 |
celeron55 |
it's an irr::gui::IGUIFont pointer |
18:56 |
celeron55 |
http://irrlicht.sourceforge.net/docu/annotated.html |
18:56 |
celeron55 |
every minetest developer should have that bookmarked 8) |
18:57 |
|
BlockMen5233 joined #minetest-dev |
18:59 |
BlockMen5233 |
celeron55, thx. and im not "that much dev" yet that i have things like that bookmarked :P |
19:06 |
BlockMen |
am i right, that it is impossible to change the font color of irrlicht gui buttons? -> http://irrlicht.sourceforge.net/docu/classirr_1_1gui_1_1_i_g_u_i_button.html |
19:11 |
|
Calinou joined #minetest-dev |
19:17 |
proller |
switched to s16, reformated |
19:33 |
|
BlockMen joined #minetest-dev |
19:36 |
celeron55 |
BlockMen: you can set the color for all of them with the skin color thing (http://irrlicht.sourceforge.net/docu/classirr_1_1gui_1_1_i_g_u_i_skin.html) |
19:36 |
celeron55 |
i think it's impossible individually |
19:36 |
celeron55 |
this is the list of "gui skin colors" that can be set http://irrlicht.sourceforge.net/docu/namespaceirr_1_1gui.html#abd15860fde29833c48daff5f95d5467a |
19:37 |
celeron55 |
some such colors are set around main.cpp:1460 |
19:38 |
celeron55 |
including that button text color, actually |
20:04 |
BlockMen |
ic, thx |
20:40 |
|
smoke_fumus joined #minetest-dev |
20:45 |
|
RealBadAngel joined #minetest-dev |
21:10 |
|
xrogaan joined #minetest-dev |
21:10 |
|
xrogaan joined #minetest-dev |
21:31 |
|
ffoxin joined #minetest-dev |
21:57 |
PilzAdam |
is it intentional that sky.cpp has not license header? |
22:50 |
|
RealBadAngel joined #minetest-dev |
23:01 |
kahrl |
celeron55: well, I'm not crazy about hardcoding all these things, to say the least |
23:02 |
kahrl |
but if the others want it in, okay |
23:03 |
kahrl |
anyway, I can easily see the getHeat/getHumidity thing causing frametime spikes every 10 seconds in singleplayer |
23:03 |
kahrl |
if you have a cpu with only few cores |
23:05 |
kahrl |
and of course the ABM can be a resource hog as celeron55 mentioned |
23:17 |
|
BlockMen left #minetest-dev |
23:50 |
hmmmm |
i am against it as well for that matter |
23:50 |
hmmmm |
(i didn't really want to be the only negative guy here) |
23:51 |
hmmmm |
like i've been saying all along..... it feels like a lua thing. it really does. |
23:51 |
PilzAdam |
I think that it should be done in Lua, too |
23:51 |
PilzAdam |
I also cant see what the finished thing will look like |
23:52 |
hmmmm |
i'm just going by what I see in the source.. if karhl says there are lagspikes every 10 seconds, that's a huge killer |
23:53 |
hmmmm |
hm |
23:53 |
hmmmm |
maybe proller can push it to a separate branch |
23:53 |
PilzAdam |
I already suggested that proller should do it in a fork first |
23:53 |
hmmmm |
well he did (his own fork) |
23:54 |
hmmmm |
proller:weather |
23:54 |
PilzAdam |
I mean, finish it in a fork first, balance the gameplay and stuff |
23:54 |
hmmmm |
oh, yeah. |
23:54 |
hmmmm |
i can see why he wouldn't want to do that, though. |
23:55 |
PilzAdam |
I fear that it will end up like finite liquids: they were pushed too early into upstream, and now nobody improves them |
23:55 |
hmmmm |
big stuff that everybody agrees on (e.g. scriptapi separation, main menu lua, so on) was pushed right away |