| Time |
Nick |
Message |
| 00:00 |
paramat |
so now get_mapgen_params and biome api changes are in i can try getting some biomes into MTgame, however since tree schems will take time to create (and schems unstable) how about i add beaches and plains biomes with grasses and flowers for now? then at least v5/v7 will look good |
| 00:22 |
paramat |
then i'll aim to get a complete set of biomes finished, with trees, for next stable. i plan to use lua tables for tree schems, it's actually the easiest way currently |
| 00:54 |
|
paramat left #minetest-dev |
| 01:58 |
hmmmm |
lots of work on biomes coming up soon |
| 02:00 |
hmmmm |
there's so much work to do on EVERYTHING |
| 02:01 |
hmmmm |
i blew my entire christmas vacation on trying to get minetest to a happy place but it still needs work to get there |
| 02:02 |
|
kaeza joined #minetest-dev |
| 02:25 |
hmmmm |
https://github.com/minetest/minetest/commit/ca89e63b27a2548a7615fcf4943c22f88818f6eb |
| 02:29 |
|
shmancelot joined #minetest-dev |
| 02:39 |
hmmmm |
hahahahaha |
| 02:39 |
hmmmm |
on_generated has been being called with the incorrect blockpos for a very long time |
| 02:40 |
hmmmm |
s/being// |
| 02:40 |
hmmmm |
actually since 0.4-dev |
| 02:42 |
|
prozacgod joined #minetest-dev |
| 03:18 |
|
Zeno` joined #minetest-dev |
| 03:19 |
|
paramat joined #minetest-dev |
| 03:20 |
paramat |
i'm using recent git 5e2 and can't get decorations to appear, i'm suspecting the addition of height min/max (which is very useful) |
| 03:20 |
hmmmm |
does reverting that one make them work?? |
| 03:20 |
hmmmm |
personally they work for me... |
| 03:22 |
|
acerspyro left #minetest-dev |
| 03:22 |
paramat |
i see, i haven't bisected yet, hope this is my mistake |
| 03:23 |
paramat |
discovered while testing my biomes branch is MTgame https://github.com/paramat/minetest_game/commit/9cafad476a036bd1cbd7401acb1f164e4abe2b23 |
| 03:23 |
paramat |
*in |
| 03:35 |
paramat |
guess it's bisect time.. BTW people seem a little confused about your v7 vote, they don't know how extreme your proposed 'modification' will be, and some are voting yes because they would like to see v7 improved (as i would, i almost voted yes at first) |
| 03:42 |
paramat |
personally the only reason i can see to trash v7 is if it was embarrassingly bad, which of course it isn't (indev was much much worse). seems obvious to me to have more choice and variety |
| 03:43 |
paramat |
good thing we're not a democracy heh |
| 03:43 |
hmmmm |
it's not going to look much the same |
| 03:43 |
hmmmm |
let's put it that way |
| 03:44 |
hmmmm |
the fundamental approach i took to terrain is flawed.. i used 2d noise composed with 3d noise to get nice properties of both and i ended up with the worst instead |
| 03:45 |
hmmmm |
v5 using 3d as the base and 2d as a height factor is much better |
| 03:46 |
paramat |
well, if it's kept i'm offering to maintain it, make improvements, and come up with alternative noiseparams for use in .conf |
| 03:47 |
hmmmm |
offer accepted |
| 03:47 |
paramat |
i've been playing with using the 3D noise to create floatlands throughout the atmosphere, this being the advantage of the separate 2D and 3D noises |
| 03:47 |
paramat |
cool man |
| 03:48 |
hmmmm |
you know the thing about mapgens is that what we consider crappy algorithms can turn out to be really awesome with the right noise parameters |
| 03:48 |
hmmmm |
eh |
| 03:48 |
hmmmm |
floatlands is supposed to be a realm thing |
| 03:48 |
hmmmm |
which ties in with the biome thing |
| 03:48 |
hmmmm |
you probably saw BIOME_TYPE_AETHER |
| 03:48 |
paramat |
yes i keep seeing that |
| 03:49 |
paramat |
there have been requests recently for extra 'levels' above/below |
| 03:49 |
hmmmm |
it's probably a good idea to bump the priority of working on the biome system |
| 03:50 |
paramat |
so of course i've been wondering if v7 aether/nether is coming |
| 03:50 |
paramat |
..in v7 |
| 03:50 |
hmmmm |
i haven't determined how this is going to work yet |
| 03:51 |
paramat |
apart from the requests, i feel any new mapgen should make full use of the vertical space |
| 03:51 |
hmmmm |
my original idea was to have aether/nether independent of the mapgen but i'm not sure that's a great idea |
| 03:51 |
hmmmm |
so each mapgen should define a generateTerrain() for each biome type |
| 03:52 |
paramat |
agreed they shouldn't be independant of mapgen |
| 03:52 |
hmmmm |
the actual terrain is easy for those |
| 03:53 |
paramat |
in my lua mapgen i keep seeing ways of just tweaking the normal realm to create stuff above and below |
| 03:53 |
hmmmm |
it can't be too much more difficult than 2d noise * 3d noise > threshhold for aether and carve out negative space with 3d noise for nether |
| 03:53 |
hmmmm |
finer details aside |
| 03:54 |
hmmmm |
perhaps there should be a "default" generateTerrain() for aether/nether defined in mapgen.cpp and then each mapgen can leave it unimplemented if they don't want to do anything special |
| 03:54 |
paramat |
yep, for a 3D noise mapgen just changing how 'noise gradient' behaves can generate all 3 types of reallm |
| 03:55 |
hmmmm |
with all this stuff, how am I supposed to find time to work on OGL lightmaps and the emergethread disk queueing |
| 03:55 |
hmmmm |
:/ |
| 03:55 |
hmmmm |
or what about the lua ABM context switching cleanup |
| 03:57 |
paramat |
i don't expect you to do all these things as well, i can do the simpler / time consuming work on mapgen |
| 03:58 |
hmmmm |
and then any of the things on the dev wiki TODO list... hah |
| 03:58 |
hmmmm |
minetest is a full time job |
| 03:58 |
paramat |
you know i'm the 'mapgen tea boy' |
| 03:58 |
hmmmm |
lol |
| 03:58 |
hmmmm |
care for a cuppa? |
| 03:58 |
paramat |
funny i don't drink caffeine |
| 03:59 |
paramat |
anyway here's my mapgen that does all 3 realms just by altering 'noise gradient' https://forum.minetest.net/viewtopic.php?f=9&t=10481 |
| 04:00 |
hmmmm |
tea doesn't necessarily contain caffeine, does it? |
| 04:00 |
hmmmm |
I'm looking for a minecraft-like nether |
| 04:00 |
paramat |
yeah more underworldy |
| 04:01 |
hmmmm |
in any case this requires modifying light levels |
| 04:01 |
hmmmm |
client side biome effects |
| 04:01 |
hmmmm |
they're going to be necessary if this is to be successful |
| 04:01 |
paramat |
i also realised adjusting how noise gradient behaves can create planets/dyson spheres/dyson cubes/tube worlds |
| 04:01 |
paramat |
yeah lighting =P |
| 04:02 |
hmmmm |
i'm going to add something very dangerous to the modding api that only very responsible people can use |
| 04:03 |
paramat |
too bad i miss out |
| 04:03 |
hmmmm |
nah, it's intended for you |
| 04:03 |
hmmmm |
i am trying to come up with signing mechanisms |
| 04:03 |
hmmmm |
if I don't, it WILL be abused and cause tons of crashes and people whining and moaning |
| 04:03 |
|
Miner_48er joined #minetest-dev |
| 04:04 |
hmmmm |
you probably realize what it is I'm talking about, right? |
| 04:06 |
paramat |
signing ... mirror-image mapgens? |
| 04:07 |
paramat |
symmetry through signing of co-ords erm.. |
| 04:07 |
hmmmm |
huh? |
| 04:08 |
paramat |
guess not =) |
| 04:08 |
hmmmm |
control over envlock from on_generated :p |
| 04:08 |
hmmmm |
crazy, huh |
| 04:08 |
paramat |
multi-threaded lua mapgen? |
| 04:09 |
hmmmm |
that not so much, because there's still scriptlock |
| 04:09 |
hmmmm |
just so that ServerThread doesn't hang while map is generating |
| 04:09 |
hmmmm |
that's the #1 problem with lua mapgens |
| 04:09 |
paramat |
yes |
| 04:09 |
hmmmm |
here's a really easy solution. but the dumb people |
| 04:11 |
paramat |
this would be a more powerful form of threaded lua mapgen i guess, control over when to thread? |
| 04:12 |
hmmmm |
the problem is that i can't think of a good way to stop other people from impersonating you |
| 04:12 |
hmmmm |
because open source |
| 04:13 |
paramat |
lol. well anyway that is indeed dangerous |
| 04:13 |
hmmmm |
we can't communicate with a 3rd party server |
| 04:13 |
paramat |
i would be happy enough with multi-threaded lua mapgen for the masses |
| 04:14 |
hmmmm |
it's either restricted to certain people or nothing at all |
| 04:14 |
hmmmm |
there's simply too much potential for abuse |
| 04:14 |
paramat |
crumbs |
| 04:15 |
paramat |
i thought it would be for everyone, c55 was considering it a priority |
| 04:15 |
paramat |
just for LVM seemed doable |
| 04:16 |
paramat |
anyway, if that can be done yes please |
| 04:16 |
paramat |
if not ill do it in core |
| 04:16 |
hmmmm |
the only safe way is to add checks !EVERYWHERE! to every single api |
| 04:16 |
hmmmm |
ugh |
| 04:17 |
hmmmm |
i have a solution for this actually |
| 04:17 |
hmmmm |
alright, i can do it the safe way |
| 04:19 |
paramat |
to be clear i have no resistence to coding core mapgen now, just haven't got around to it |
| 04:20 |
paramat |
'riverdev' mod is a monster and needs to be done in core |
| 04:20 |
hmmmm |
lua mapgens are nicer because you don't need to generalize as much |
| 04:20 |
paramat |
they are more relaxing too |
| 04:21 |
paramat |
'leisure coding' core is a bit stressful |
| 04:22 |
paramat |
i like to hide away and work independantly with lua stuff, i miss it actually |
| 04:26 |
hmmmm |
http://fpaste.org/164229/14199135/ |
| 04:26 |
hmmmm |
:p |
| 04:26 |
hmmmm |
i'm busy for a while |
| 04:26 |
paramat |
me too |
| 04:32 |
|
paramat left #minetest-dev |
| 04:58 |
VanessaE |
all right, this shit has to stop |
| 04:58 |
VanessaE |
Minetest for windows needs a proper installer |
| 04:58 |
VanessaE |
not this zip file shit |
| 04:59 |
VanessaE |
I'm trying to help someone through just unzipping the file and they can't even figure out what a zip is. |
| 05:02 |
hmmmm |
minetest might not be for them :p |
| 05:04 |
VanessaE |
eh.. |
| 05:04 |
Zeno` |
7z self-extracting archives are probably the easiest solutions for Windows |
| 05:04 |
VanessaE |
Zeno`: +1 |
| 05:12 |
VanessaE |
so, what about it? |
| 05:12 |
VanessaE |
is there some reason not to switch to that like, right now? |
| 05:20 |
|
Wayward_One joined #minetest-dev |
| 05:36 |
|
sol_invictus joined #minetest-dev |
| 05:44 |
|
paramat joined #minetest-dev |
| 05:47 |
paramat |
i assume if height_min and height_max are left out of a decoration definition it will still work? now bisected and commit 863379a breaks decos |
| 05:48 |
paramat |
the biomes work okay though |
| 05:50 |
hmmmm |
hahaha |
| 05:51 |
hmmmm |
do you see why? :) |
| 05:51 |
hmmmm |
i bet it works if you specified a height_min/height_max |
| 05:51 |
paramat |
i'll try adding that in ... |
| 05:57 |
paramat |
erm it still doesn't work with those params in |
| 05:59 |
paramat |
anyway that bool that triggers continue may be the error? |
| 05:59 |
hmmmm |
how is that logically possible |
| 06:00 |
hmmmm |
did you see this? this is what i figured the problem is: https://github.com/minetest/minetest/commit/b589353d89a5a5cd2dd999a13ca039079bee0ece |
| 06:00 |
paramat |
well i can't see the error |
| 06:00 |
paramat |
swapped |
| 06:01 |
paramat |
oh yeah see it now |
| 06:02 |
hmmmm |
it works for me after my fix... so |
| 06:02 |
paramat |
will compile and test! |
| 06:03 |
hmmmm |
oh uh oh |
| 06:03 |
hmmmm |
i see a larger problem |
| 06:03 |
hmmmm |
with decosimple anyway |
| 06:08 |
hmmmm |
really need to start being more careful with naming things |
| 06:11 |
paramat |
still doesnt work |
| 06:17 |
paramat |
are -32000 and 32000 safe to use as height limits? i always see 31000 instead |
| 06:18 |
paramat |
wow v7 with super-amplified 3D noise is stunning |
| 06:18 |
paramat |
mgv7_np_mountain = 0, 16, (250, 350, 250), 5333, 5, 0.68, 2.0 |
| 06:25 |
paramat |
yes it's simple decos which don't appear for me |
| 06:31 |
paramat |
oh there's 2 height_max parameters! |
| 06:31 |
hmmmm |
yea |
| 06:31 |
paramat |
good grief |
| 06:31 |
hmmmm |
the height_min/height_max is wrong terminology |
| 06:31 |
hmmmm |
it should be y_min/y_max |
| 06:31 |
hmmmm |
if i do that, i'll break compatibility though! |
| 06:32 |
paramat |
http://i.stack.imgur.com/9y9uk.gif |
| 06:32 |
hmmmm |
i set height_max to 20 for grass and i got |
| 06:32 |
hmmmm |
an interesting result |
| 06:33 |
hmmmm |
also i discovered that if you cut the bottom node of one of these... grass trees... all the nodes on top will fall down |
| 06:34 |
hmmmm |
and what's more is that the dropped items like seeds gather together if they fall on top of one another |
| 06:34 |
hmmmm |
very convenient feature |
| 06:35 |
hmmmm |
so I was wasting time making this http://i.imgur.com/QHkKgYT.jpg |
| 06:48 |
hmmmm |
okay, NOW try it https://github.com/minetest/minetest/commit/9b0d77a549e4c29c9c189ff2a454568fa9746c1e |
| 07:09 |
paramat |
okay |
| 07:12 |
paramat |
ah because grass is 'attached node', nice |
| 07:27 |
paramat |
now works, thanks, big relief |
| 07:39 |
paramat |
enough stress and excitement for one day, time to watch sci-fi anime |
| 07:39 |
hmmmm |
you and your anime... |
| 07:39 |
hmmmm |
is it a new show or what? |
| 07:41 |
|
Hunterz joined #minetest-dev |
| 07:47 |
paramat |
i'm currently watching 3 series from last year. i get withdrawl symptoms with anime. the average anime is more imaginative and has better design and story than any hollywood live-action film |
| 07:47 |
|
paramat left #minetest-dev |
| 07:48 |
hmmmm |
i've gotta catch up on the past 3 seasons |
| 08:30 |
|
Krock joined #minetest-dev |
| 09:01 |
|
Amaz joined #minetest-dev |
| 09:11 |
|
kilbith joined #minetest-dev |
| 09:23 |
|
nore joined #minetest-dev |
| 09:26 |
|
ImQ009 joined #minetest-dev |
| 09:40 |
|
crazyR joined #minetest-dev |
| 10:29 |
|
PilzAdam joined #minetest-dev |
| 10:45 |
|
chchjesus joined #minetest-dev |
| 11:06 |
|
kilbith joined #minetest-dev |
| 11:08 |
|
cib0 joined #minetest-dev |
| 11:14 |
|
jin_xi joined #minetest-dev |
| 11:18 |
|
ImQ009 joined #minetest-dev |
| 11:37 |
|
Megaf joined #minetest-dev |
| 12:19 |
|
dzho joined #minetest-dev |
| 12:19 |
|
dzho joined #minetest-dev |
| 12:26 |
|
exio4_ joined #minetest-dev |
| 12:48 |
|
Zeno` joined #minetest-dev |
| 12:49 |
Zeno` |
kahrl, #2017... any reason why your gist isn't merged? |
| 12:49 |
ShadowBot |
https://github.com/minetest/minetest/issues/2017 -- facedir > 23 causes segfault in client |
| 12:51 |
Zeno` |
I will merge #1851 soon. Bug fix |
| 12:51 |
ShadowBot |
https://github.com/minetest/minetest/issues/1851 -- Cleanup updateCameraDirection and fix random input not working by Zeno- |
| 12:53 |
|
fz72 joined #minetest-dev |
| 12:54 |
Zeno` |
Also #2026 |
| 12:54 |
ShadowBot |
https://github.com/minetest/minetest/issues/2026 -- Fix endian.h include for FreeBSD by AMDmi3 |
| 13:05 |
|
exio4 joined #minetest-dev |
| 13:11 |
|
cib joined #minetest-dev |
| 13:12 |
Zeno` |
comments on #1967, please |
| 13:12 |
ShadowBot |
https://github.com/minetest/minetest/issues/1967 -- Add display_gamma option for client by Zeno- |
| 13:16 |
Krock |
Zeno`, I'm not sure if that feature is used by regular players. Also, this could be confusing when the server uses an other light tabe and (as example) the plants won't grow |
| 13:20 |
Zeno` |
Doesn't affect the server |
| 13:20 |
Zeno` |
Gamma correction (and brightness and contrast, but I'm not going to do that at this point) are common game options |
| 13:21 |
Zeno` |
the light table is a *display* value, not something used for ABMs etc |
| 13:21 |
Krock |
Can't te screens do that? |
| 13:21 |
Krock |
*the |
| 13:22 |
Krock |
whatever. I'm not sure if that should be merged |
| 13:23 |
|
T4im joined #minetest-dev |
| 13:24 |
Zeno` |
screens? |
| 13:24 |
Zeno` |
You want me to adjust my monitor for one game? :) |
| 13:26 |
Zeno` |
My monitor is calibrated and I (for one) am not going to change anything on the monitor just for minetest. Many people have complained about this simple feature being missing for a long time. All monitors are different and this fixes that problem by letting the user set a "correction" |
| 13:27 |
Zeno` |
It will also stop 500 #if 0 #endif variants of light_table heh |
| 13:30 |
Zeno` |
I'm not sure why it's not easy to understand that people's monitors (and eyesight) are different :/ |
| 13:30 |
Zeno` |
and there is no one size fits all solution |
| 13:50 |
Megaf |
Hi Zeno` |
| 13:50 |
Megaf |
Zeno`: memory leak on server side is fixed indeed |
| 13:50 |
Megaf |
Zeno`: but client leak is not |
| 13:51 |
pitriss |
Zeno`: I support your set gamma patch |
| 13:52 |
pitriss |
Zeno`: my monitor is also set up properly but I know many ppl who will find this useful |
| 14:05 |
Zeno` |
I'm just making some changes so it's even more obvious that this (light_table) is a client thing only |
| 14:05 |
Zeno` |
pushed |
| 14:07 |
Zeno` |
I'll merge before I go to sleep I guess... otherwise it'll never happen |
| 14:11 |
|
jluc joined #minetest-dev |
| 14:13 |
Zeno` |
waiting for Travis |
| 14:14 |
Krock |
did someone agree the merge? |
| 14:14 |
Zeno` |
yes, pitriss |
| 14:14 |
Zeno` |
and MegaF |
| 14:15 |
Krock |
I thought devs must agree or am I wrong? |
| 14:17 |
Zeno` |
Well, if that were the case nothing would ever get merged unfortunately :( |
| 14:18 |
Zeno` |
and shadowninja kind of agreed (apart from his comment that it may affect servers, which I've now addressed... the code isn't even there for servers now) |
| 14:18 |
Zeno` |
I'm still not sure why you're so opposed to it |
| 14:19 |
Krock |
Okay, the range is limited and the defaults equal the current light table |
| 14:19 |
Krock |
nothing speaks against it |
| 14:21 |
|
Player_2 joined #minetest-dev |
| 14:24 |
|
SmugLeaf joined #minetest-dev |
| 14:24 |
Zeno` |
This will all become obsolete when (if?) GPU lighting is implemented anyway. When that's done there's probably no way to get the actual light value |
| 14:25 |
Zeno` |
displayed light value* |
| 14:31 |
|
zat joined #minetest-dev |
| 15:01 |
|
shadowzone joined #minetest-dev |
| 15:03 |
|
Wayward_One joined #minetest-dev |
| 15:09 |
|
exio4 joined #minetest-dev |
| 15:24 |
|
roniz joined #minetest-dev |
| 15:25 |
|
exio4 joined #minetest-dev |
| 15:26 |
|
n4x joined #minetest-dev |
| 15:36 |
|
werwerwer joined #minetest-dev |
| 15:43 |
Ritchie |
hello |
| 15:44 |
Ritchie |
Zeno`: i support your gamma patch too |
| 15:45 |
Ritchie |
Zeno`: can i ask what monitor do you have that you said you have it calibrated? |
| 15:46 |
Zeno` |
It's not an expensive monitor. I have 3x SyncMasterS22B300 monitors that I've calibrated with Spyder2 |
| 15:48 |
Ritchie |
i have a cheap LCD screen "ProView" but i have now a chance to buy used EIZO FlexScan F67 with low price |
| 15:48 |
Zeno` |
But I'm not changing brightness/contrast/gamma on the monitor for the only game in existence without the ability to change those values (at least gamma) when it's an easy fix :) |
| 15:48 |
Ritchie |
yes i agree with you |
| 15:49 |
|
chchjesus__ joined #minetest-dev |
| 15:49 |
Zeno` |
The EIZO is much better than a ProView |
| 15:49 |
Zeno` |
about 1000x better probably |
| 15:51 |
Ritchie |
http://www.prad.de/en/guide/screen3350.html |
| 15:52 |
|
cib0 joined #minetest-dev |
| 15:52 |
Ritchie |
i bought it in university accomodation for 0.5l slivovitze:D |
| 15:53 |
Ritchie |
-e |
| 15:57 |
|
troller joined #minetest-dev |
| 15:58 |
cib0 |
"We want to document most or all of Minetest core with Doxygen-style code comments. The system for extracting information from those comments is not yet ready, but once we have comments in that format, it should be relatively simple to implement. " what |
| 15:58 |
cib0 |
"is not yet ready"? |
| 15:59 |
Zeno` |
Tesseract, I've updated #1967 to make it completely obvious that it does not affect server stuff. Merge? |
| 15:59 |
ShadowBot |
https://github.com/minetest/minetest/issues/1967 -- Add display_gamma option for client by Zeno- |
| 16:00 |
Zeno` |
cib0, where did you get that quote from? |
| 16:00 |
cib0 |
http://dev.minetest.net/Engine_documentation |
| 16:00 |
Zeno` |
I think it's ready |
| 16:00 |
Zeno` |
That page is probably outdated |
| 16:00 |
cib0 |
If it is that page should probably contain a link to an online version of the docs, too. :) |
| 16:01 |
cib0 |
"Last modified January 2013" yup |
| 16:01 |
Zeno` |
Well, there are no online docs yet (AFAIK) but the " system for extracting information from those comments" is in place |
| 16:02 |
Zeno` |
i.e. https://github.com/minetest/minetest/blob/master/doc/Doxyfile.in |
| 16:04 |
Zeno` |
Could probably do with some improvement, but at least it's in place :) |
| 16:09 |
|
fz72 joined #minetest-dev |
| 16:14 |
|
kaeza joined #minetest-dev |
| 16:17 |
Zeno` |
Ok, since there are no problems I'll merge in 30 minutes |
| 16:21 |
|
hmmmm joined #minetest-dev |
| 16:25 |
|
Wayward_One joined #minetest-dev |
| 16:26 |
celeron55 |
what the hell |
| 16:27 |
celeron55 |
yes, that page is very outdated and it gives a wrong idea about what we can accept as contributions in that area |
| 16:28 |
celeron55 |
i added a notice to it |
| 16:33 |
kaeza |
#minetest-doc is also dead. would it be OK to redirect here instead? |
| 16:44 |
hmmmm |
argh |
| 16:45 |
hmmmm |
if minetest didn't have lua modding capabilities i bet it would be half the size |
| 16:46 |
VanessaE |
(Score:-1, Troll) |
| 16:46 |
VanessaE |
:P |
| 16:47 |
hmmmm |
no sarcasm here |
| 16:47 |
hmmmm |
consider something trivial like adjustable light |
| 16:47 |
hmmmm |
normal games just... adjust the light |
| 16:47 |
VanessaE |
well half the size it might be, but it would also have like 1 percent of the userland activity also |
| 16:48 |
hmmmm |
instead if minetest wants to adjust the light there needs to be: |
| 16:48 |
hmmmm |
- a lua api to do so |
| 16:48 |
hmmmm |
- documentation on it |
| 16:48 |
hmmmm |
- server -> client transfer |
| 16:48 |
hmmmm |
- actually adjusting the light |
| 16:49 |
hmmmm |
- also a protocol version bump |
| 16:49 |
|
mpa1212 joined #minetest-dev |
| 16:49 |
VanessaE |
well |
| 16:50 |
VanessaE |
consider the flipside to that code-size coin: does the total amount of code lead to a reduction on performance, maintainability, etc.? |
| 16:50 |
hmmmm |
then some time later modders want to do x y and z with the api so you have to maintain it |
| 16:50 |
hmmmm |
well, it certainly decreases developer happiness |
| 16:50 |
VanessaE |
(on performance, I mean assume a game with no mods installed) |
| 16:51 |
VanessaE |
well, I'll grant you that :P |
| 16:51 |
Brains |
Of course, you didn't have to implement all those things that the modders did with your api... So, write good and popular APIs. (If you manage to figure out how to do that repeatably, retire to a moderately sized island and invite your peers.) |
| 16:53 |
hmmmm |
it's difficult to think of minetest as a game because of these reasons |
| 16:53 |
hmmmm |
there's so much more overhead and it does so much more than simply 'be entertaining' |
| 16:53 |
hmmmm |
very little focus these days on audiovisuals and graphics |
| 16:54 |
hmmmm |
although there's lots of work that could be done there |
| 16:54 |
Brains |
It is getting hard for even big games to be successful without modding capabilities. *shrug* |
| 16:54 |
VanessaE |
hmmmm: haven't I been complaining about the lack of focus on A/V for a while now? (with exceptions to what RBA has done recently) |
| 16:54 |
Zeno` |
ahem |
| 16:54 |
VanessaE |
and zeno :) |
| 16:54 |
Zeno` |
:P |
| 16:55 |
VanessaE |
(though I lumped your stuff under performance, not AV) |
| 16:55 |
Zeno` |
fair enough I guess ;) |
| 16:56 |
VanessaE |
hmmmm: there's two problems though - not enough coders who can do it, and not enough skills among those we have who already can. |
| 16:56 |
hmmmm |
there's simply too much shit todo |
| 16:56 |
hmmmm |
how long have i been wanting to add the nether |
| 16:56 |
VanessaE |
I mean, I've seen screenshots of some seriously "next level shit" to quote Will Smith, and those things are just way WAY beyond what Minetest can do given the current skill level we have at our disposal |
| 16:57 |
hmmmm |
250+ commits later and i still didn't get to that |
| 16:57 |
hmmmm |
what do you mean? |
| 16:57 |
VanessaE |
I mean nice AV effects, shadows, bloom, etc |
| 16:57 |
hmmmm |
oh, AV effects |
| 16:57 |
VanessaE |
things that irrlicht itself probably can't even do |
| 16:57 |
cib0 |
There's always a balance to be found between simplicity, flexibility and features.. |
| 16:57 |
hmmmm |
of course irrlicht can't do that |
| 16:58 |
VanessaE |
but which, if used to proper degree would look really good in minetest |
| 16:58 |
hmmmm |
in any case, we're right up against a wall because of irrlicht |
| 16:58 |
hmmmm |
it's probably a smart idea to fork it and include the source |
| 16:58 |
hmmmm |
modify that |
| 16:58 |
VanessaE |
hmmmm: I dunno about that..... |
| 16:58 |
hmmmm |
really. |
| 16:59 |
hmmmm |
it's either that or start using raw opengl |
| 16:59 |
VanessaE |
honestly? that's a better idea imho |
| 16:59 |
hmmmm |
you don't work with any of this though |
| 16:59 |
VanessaE |
yeah I know |
| 16:59 |
hmmmm |
how could you believe your opinion holds a lot of weight |
| 16:59 |
VanessaE |
but my point is, what happens if by some miracle irrlicht actually develops along similar lines as you're proposing maintaining in your own fork? |
| 17:00 |
hmmmm |
awesome stuff, but that won't happen |
| 17:00 |
VanessaE |
do you switch back to mainline? |
| 17:00 |
hmmmm |
irrlicht is optimized for typical "game" games |
| 17:00 |
hmmmm |
and there's nothing preventing us from contributing back |
| 17:00 |
hmmmm |
if they don't accept our contributions, no sweat. |
| 17:00 |
Zeno` |
there's an easier way |
| 17:01 |
VanessaE |
well since my opinions seem to hold little weight, I'll just shut up. |
| 17:01 |
Zeno` |
"abstracting" the rendering engine |
| 17:01 |
cib0 |
Go away. :| |
| 17:01 |
cib0 |
:P |
| 17:01 |
Zeno` |
this could probably be done in a few weeks |
| 17:01 |
exio4 |
as long as you don't use objects for that, we'll hug you Zeno` |
| 17:02 |
cib0 |
Looks like I'm the only one who believes the audio-visuals are just fine? |
| 17:02 |
hmmmm |
and you'll be fighting with the irrlicht interface then |
| 17:02 |
hmmmm |
who said you'll be able to get your paws on irrlicht private resouces |
| 17:02 |
hmmmm |
resources |
| 17:03 |
Zeno` |
Why would I have to? |
| 17:03 |
hmmmm |
because you might need to |
| 17:04 |
hmmmm |
i'm not sure what's involved to do all the things we want to do yet |
| 17:04 |
Zeno` |
Not really... irrlicht versions/build will just not be able to do some things other backends can do (maybe) |
| 17:05 |
Zeno` |
The main problem is the server and other parts of shared/common code use irrlicht types; but that's not *too* hard to change |
| 17:06 |
kilbith |
hmmmm, it seems have a bug with the mapgen: https://lut.im/w1GAF3IJ/FwXbqJNt (latest git, that happen here and there) |
| 17:07 |
hmmmm |
nothing changed the output |
| 17:07 |
kilbith |
large rectangular pieces of hundreds nodes |
| 17:08 |
Krock |
kilbith, use 0.4.10 and 0.4.11 and compeare those |
| 17:08 |
hmmmm |
there was a period in 0.4.10-dev where output got messed up a little |
| 17:08 |
Krock |
*compare |
| 17:08 |
hmmmm |
it could be that the map seed got messed up, make sure that's set correctly in both versions where it works properly and doesn't work properly |
| 17:08 |
VanessaE |
hmmmm: can we PLEASE get a "delete this block from the database" command? |
| 17:09 |
hmmmm |
thought there already was one |
| 17:09 |
VanessaE |
to fix that ^^ after the fact? |
| 17:09 |
VanessaE |
there isn't, afaik |
| 17:09 |
VanessaE |
there was supposed to be, SN propose such |
| 17:09 |
hmmmm |
you can do //regen, no? |
| 17:09 |
hmmmm |
for some mods |
| 17:09 |
VanessaE |
that doesn't delete blocks from the mapgen database. |
| 17:10 |
VanessaE |
s/mapgen/map/ |
| 17:16 |
VanessaE |
(fwiw, //regen I think is a command in the 'mg' mod but it just triggers lua mapgen code to overwrite what's there. that doesn't do any good for forcing the base mapgen, e.g. mgv6 to regenerate an area that was botched) |
| 17:17 |
|
Player_2 joined #minetest-dev |
| 17:18 |
kilbith |
hmmm, i may know why that happens now, the seed changes whenever you enter in the *same* world |
| 17:18 |
kilbith |
hmmmm ^ |
| 17:19 |
hmmmm |
you have a random seed set? |
| 17:19 |
kilbith |
yes |
| 17:20 |
hmmmm |
yes, i see the problem |
| 17:20 |
hmmmm |
this could be related to the map_meta.txt error |
| 17:20 |
hmmmm |
you say this started happening recently? |
| 17:21 |
kilbith |
yes, since today |
| 17:21 |
kilbith |
i wander on the map whenever you push new commits |
| 17:23 |
hmmmm |
do things work fine before 5e2753c7? |
| 17:23 |
kilbith |
haven't tested |
| 17:24 |
kilbith |
built after 9b0d77a |
| 17:28 |
hmmmm |
whoopsies |
| 17:28 |
* Krock |
makes a troutslap ready |
| 17:28 |
|
Calinou joined #minetest-dev |
| 17:30 |
|
proller joined #minetest-dev |
| 17:30 |
|
minetestforfun joined #minetest-dev |
| 17:31 |
hmmmm |
kilbith, try this https://github.com/kwolekr/minetest/commit/a3d7203be5777010f13bf5465667028b920f4a29 |
| 17:38 |
|
proller joined #minetest-dev |
| 17:38 |
|
rubenwardy joined #minetest-dev |
| 17:40 |
|
neoascetic joined #minetest-dev |
| 17:40 |
neoascetic |
https://github.com/minetest/minetest/blob/master/src/CMakeLists.txt#L110 |
| 17:41 |
neoascetic |
why we need this statement? why not always simply process cmake_config.h.in? |
| 17:46 |
|
Amaz left #minetest-dev |
| 17:47 |
celeron55 |
it allows easier building for platforms that don't really have cmake easily available |
| 17:48 |
celeron55 |
i actually used that to my benefit this year so there's that |
| 17:49 |
celeron55 |
mostly it's a historical thing from the time when minetest natively supported a visual studio project |
| 17:50 |
celeron55 |
it could be removed i guess |
| 17:51 |
hmmmm |
hey celeron, what approach are you taking for improving vertex buffering in buildat? |
| 17:58 |
rubenwardy |
#buildat |
| 17:58 |
celeron55 |
umm... regarding to what exactly? |
| 17:59 |
|
proller joined #minetest-dev |
| 17:59 |
hmmmm |
well i was under the impression that buildat had the same fundamental problem as minetest does with mesh rendering due to the vertex buffering |
| 18:00 |
celeron55 |
well it's a bit similar but it uses so much larger buffers and it has functioning texture atlasing |
| 18:00 |
celeron55 |
so it really doesn't have an issue |
| 18:00 |
rubenwardy |
Two core developers agree! https://github.com/minetest/minetest/pull/1977#issuecomment-68335991 |
| 18:01 |
celeron55 |
or, well |
| 18:01 |
rubenwardy |
#1977 |
| 18:01 |
celeron55 |
i mean, that part of it is very unfinished |
| 18:01 |
celeron55 |
and it has compromises that maybe shouldn't be there |
| 18:01 |
hmmmm |
rubenwardy, was it rebased to the current revision of the API? |
| 18:01 |
celeron55 |
so whether it's aacceptable completely depends on where you set the bar |
| 18:01 |
rubenwardy |
See shadowninja's commt |
| 18:02 |
hmmmm |
hmm |
| 18:02 |
rubenwardy |
(s)he'll do it soon, probably |
| 18:02 |
celeron55 |
buildat's goal is more about flexibility than performance so it does not concern me a lot |
| 18:02 |
hmmmm |
ahh, taking the technically easy way out |
| 18:02 |
hmmmm |
is urho3d any better than irrlicht in that regard? |
| 18:02 |
Zeno` |
it should be merged now |
| 18:02 |
hmmmm |
irrlicht seems to be optimized for generic game-games |
| 18:03 |
celeron55 |
there's not that much you can do with performance in the end if you don't get the thing done in the first place - and you probably won't if you try something too fancy |
| 18:03 |
Zeno` |
I suspect it needs rebasing again though :( |
| 18:03 |
hmmmm |
it doesn't use any fancy buffering modes |
| 18:03 |
celeron55 |
frankly buildat is probably already too intricate to take off |
| 18:05 |
celeron55 |
hmmmm: urho3d is optimized zero amount for open world games like irrlicht (and all others); it's just more modern (basically it uses an opengl 2 style with some requirements from ogl3 while irrlicht is from the opengl1 era) |
| 18:05 |
celeron55 |
i don't know if an open source engine exists that is designed for this kind of stuff |
| 18:05 |
celeron55 |
i'm not surprised if it does not |
| 18:06 |
hmmmm |
i'm no stranger to minecraft-like games |
| 18:06 |
hmmmm |
before i discovered minetest, i was going to write one from scratch along with the graphics engine |
| 18:07 |
hmmmm |
sorta wondering if I should continue on that mess |
| 18:07 |
rubenwardy |
It is up to you. We can't stop you. Diversity is good. |
| 18:08 |
rubenwardy |
Of course we like you contributing. |
| 18:08 |
hmmmm |
no, i mean the dynamic-world graphics engine |
| 18:08 |
Zeno` |
where is the main bottleneck? |
| 18:09 |
celeron55 |
well, you could try, but make damn sure you find an easy way to include the boatload of model and animation support that is needed for a real game |
| 18:09 |
rubenwardy |
CPU to GPU |
| 18:09 |
celeron55 |
urho3d handles that absolutely effortlessly for buildat |
| 18:09 |
celeron55 |
and irrlicht adequately for minetest |
| 18:10 |
rubenwardy |
buildat is very slow for me - I guess I need a gaming PC. |
| 18:10 |
hmmmm |
originally it was going to be sparse voxel octree-based |
| 18:10 |
Zeno` |
irrlicht is the bottleneck? |
| 18:10 |
hmmmm |
no, irrlicht is just old |
| 18:10 |
kilbith |
hmmm: i confirm that your patch works, thanks |
| 18:11 |
celeron55 |
rubenwardy: try lowering the rendering distance that is hardcoded in... umm... let me find it |
| 18:11 |
celeron55 |
rubenwardy: assuming you are trying to run games/digger, see games/digger/main/client_lua/init.lua |
| 18:11 |
Zeno` |
hmmmm, if irrlicht is not the bottleneck then how can switching to something more modern help? |
| 18:12 |
hmmmm |
?? it can't, it could make things a little better |
| 18:12 |
hmmmm |
this was discussed before |
| 18:14 |
Calinou |
we have a CPU bottleneck somewhere |
| 18:14 |
kilbith |
hmmmm, the versionning is wrong on your fork: https://lut.im/1JeIGBa7/SihLfMQ1 |
| 18:14 |
Calinou |
probably by scene node abuse or such |
| 18:15 |
kilbith |
(i use linux) |
| 18:15 |
hmmmm |
whaa? |
| 18:15 |
rubenwardy |
Much better, celeron55, it's now about 30 FPS rather than 1 FPS. |
| 18:16 |
rubenwardy |
@160 |
| 18:16 |
Zeno` |
hmmmm, perhaps I directed the question at the wrong person |
| 18:17 |
hmmmm |
the bottleneck is uploading meshes to the gpu |
| 18:17 |
Zeno` |
celeron55... <celeron55> hmmmm: urho3d is optimized zero amount for open world games like irrlicht (and all others); it's just more modern (basically it uses an opengl 2 style with some requirements from ogl3 while irrlicht is from the opengl1 era) |
| 18:17 |
Zeno` |
how is that an issue? |
| 18:17 |
hmmmm |
again.. read up |
| 18:18 |
Zeno` |
I have read up and I can assure you that it's not the issue |
| 18:18 |
hmmmm |
it definitely is. what brand of gpu do you have? |
| 18:18 |
Zeno` |
nvidia |
| 18:18 |
hmmmm |
then check your profiler in the debug menu, look at num_meshes_processed |
| 18:19 |
celeron55 |
hmmmm: are you not interested in just implementing texture atlases and mapblock mesh combining? |
| 18:19 |
celeron55 |
it would get the mesh upload performance to a totally acceptable level |
| 18:20 |
Calinou |
is the old texture atlas code of any use now? |
| 18:20 |
hmmmm |
sure, but I can't help but wonder if I'd be able to eke out some more performance by changing some buffering modes |
| 18:20 |
hmmmm |
i've been reading that chapter in that OpenGL Insights book |
| 18:20 |
celeron55 |
well the thing that is achievable if these pre-made engines are not used is that meshes could be uploaded from other threads |
| 18:20 |
celeron55 |
it's the main difference |
| 18:21 |
Calinou |
also, what about VBOs, that are currently used in Freeminer? |
| 18:21 |
Calinou |
helped greatly in jungles |
| 18:22 |
celeron55 |
well the situation with them of course is specific to irrlicht |
| 18:22 |
hmmmm |
could've sworn we had vbo support for a while now, which can be enabled via the config |
| 18:22 |
hmmmm |
unsynchronized buffers with multiple worker threads |
| 18:23 |
Zeno` |
ok I just looked. GPU is not struggling at all |
| 18:23 |
celeron55 |
they don't help much without big meshes though, and big meshes rarely happen without texture atlasing and mapblock mesh combining! |
| 18:23 |
hmmmm |
i wanted to run multiple MeshMakeThreads |
| 18:23 |
hmmmm |
gah |
| 18:23 |
celeron55 |
(that's why you see a difference in jungles; they are the only place with big meshes) |
| 18:23 |
hmmmm |
could just make mapblocks larger 8) |
| 18:23 |
hmmmm |
16x16x16 is pretty arbitrary |
| 18:24 |
celeron55 |
then you leave out support for old intel laptops |
| 18:24 |
celeron55 |
maybe it's acceptable |
| 18:24 |
Calinou |
wouldn't that break all maps? and what about map size? |
| 18:25 |
celeron55 |
but you can't make them too large, it starts causing other issues due to data size |
| 18:25 |
celeron55 |
yes it will break everything |
| 18:25 |
celeron55 |
that's why i talk about combining them at runtime |
| 18:25 |
hmmmm |
i'll add that and see where it gets me |
| 18:26 |
celeron55 |
oh also, in addititon to "old intel laptops", mobile devices need the small meshes too |
| 18:26 |
celeron55 |
they neither can render a huge amount of vertices |
| 18:26 |
celeron55 |
i mean, android |
| 18:27 |
celeron55 |
buildat apparently happens to use 32x32x32 chunks (=MT mapblocks) |
| 18:28 |
celeron55 |
there's no map saving at all so it's easily changeable :P |
| 18:31 |
|
neoascetic joined #minetest-dev |
| 18:34 |
|
AnotherBrick joined #minetest-dev |
| 19:05 |
VanessaE |
hmmmm: you asked earlier about VBO support. no, we don't have it in minetest but there is a now-outdated pull for it. I've used it in the past, and it worked well. Whether it's still as performant, I don't know. It never made it in because it causes memory leaks (outdated/obsolete meshes aren't deleted) |
| 19:11 |
hmmmm |
perhaps it should be rebased. i'd merge it in a second. |
| 19:12 |
VanessaE |
well until the leak/obsolete meshes issue is solved, I think it'll be vetoed even faster |
| 19:13 |
rubenwardy |
* if it works correctly |
| 19:13 |
VanessaE |
ah, here it is: https://github.com/ShadowNinja/minetest/tree/vbo |
| 19:14 |
VanessaE |
I guess it never got a proper pull request, but anyway there's the code. |
| 19:27 |
|
ImQ009 joined #minetest-dev |
| 19:28 |
|
celeron55 joined #minetest-dev |
| 19:35 |
hmmmm |
there is no leak |
| 19:36 |
hmmmm |
it's just vastly increased memory usage |
| 19:39 |
VanessaE |
ask Pilzadam. |
| 19:39 |
hmmmm |
that's what i understood |
| 19:39 |
VanessaE |
according to him I think it was, memory will just keep increasing as new meshes are generated and fed to the GPU |
| 19:39 |
VanessaE |
the old ones are never thrown out |
| 19:39 |
hmmmm |
hhrmm |
| 19:40 |
hmmmm |
but freeminer added this? |
| 19:40 |
VanessaE |
yep, apparently |
| 19:40 |
VanessaE |
whether/how they fixed that issue, idk |
| 19:40 |
hmmmm |
they probably didn't fix the issue |
| 19:40 |
hmmmm |
by freeminer we mean proller |
| 19:40 |
VanessaE |
heh |
| 19:41 |
VanessaE |
inb4 some snide remark from him ;) |
| 19:42 |
rubenwardy |
How dare Freeminer take our code, make a better game and don't allow us to take it back. |
| 19:42 |
rubenwardy |
The GPL -> LGPL move failed |
| 19:42 |
Calinou |
yes we know :/ |
| 19:42 |
rubenwardy |
If we moved back, we could nick their code |
| 19:42 |
VanessaE |
"better" is quite subjective here. |
| 19:42 |
Calinou |
if Minetest was GPL they could switch to AGPL :p |
| 19:43 |
hmmmm |
freeminer is waaaay inferior to minetest |
| 19:43 |
rubenwardy |
better -> some optimisations |
| 19:43 |
hmmmm |
those optimizations aren't actual optimizations and they're buggy as shit |
| 19:43 |
Calinou |
Freeminer feels broken when you play it |
| 19:43 |
rubenwardy |
They optimised things and added things that we don't have |
| 19:43 |
rubenwardy |
Oh, okay |
| 19:43 |
Calinou |
stuff like coloured text is very useful, and we can merge it |
| 19:43 |
hmmmm |
proller told you he optimized things but they simply omit essential steps |
| 19:43 |
Calinou |
but the PR has been abandoned and no dev approved it |
| 19:43 |
hmmmm |
leading to bugs in edge cases |
| 19:43 |
rubenwardy |
Just look how he did these things, and subtly copy them |
| 19:44 |
hmmmm |
I did look at them and I'm not copying any of it |
| 19:44 |
hmmmm |
it sucks ass |
| 19:44 |
rubenwardy |
Well, look at it in despair and do it your own way. |
| 19:44 |
hmmmm |
despair? |
| 19:44 |
rubenwardy |
Loss of all hope |
| 19:44 |
hmmmm |
I'm not exactly weeping over freeminer |
| 19:45 |
hmmmm |
if you think it's better than minetest, that's fine. you go play freeminer |
| 19:45 |
rubenwardy |
(loss of all hope because it is a bad way of doing it, to clarify) |
| 19:45 |
rubenwardy |
I prefer Minetest |
| 19:46 |
|
shadowzone joined #minetest-dev |
| 19:50 |
hmmmm |
here's a typical Freeminer "fix" or "optimization": https://github.com/freeminer/freeminer/commit/877ef2f5dcaa341c76a9abe073cbea5bba63ddae#diff-34f48ad91ac6c202ac60b0348ae90e30R160 |
| 19:51 |
hmmmm |
like... are you shitting me |
| 19:52 |
rubenwardy |
Wow |
| 19:52 |
hmmmm |
and here's another "fix" for his "optimization": https://github.com/freeminer/freeminer/commit/bef8bdb61b9fb8addcb1389c44efaf14cee155a7 |
| 19:53 |
hmmmm |
which basically invalidates 99% of the advantage gained from the optimization |
| 19:53 |
hmmmm |
but the optimization wasn't really necessary to begin with |
| 19:53 |
hmmmm |
freeminer is soo awesome |
| 19:53 |
rubenwardy |
Lol |
| 19:54 |
hmmmm |
I want you to seriously go through the commit logs, subtract Merge commit messages, and count the number of them that begin with the word "fix" |
| 19:54 |
hmmmm |
perhaps also subtract the trivial ones like "remove comment" |
| 19:54 |
rubenwardy |
Discard any that were ported from MT |
| 19:55 |
rubenwardy |
https://github.com/freeminer/freeminer/commit/88bde8e8e9d8a75ae3fa05444993f4815d1334f1 |
| 19:55 |
rubenwardy |
"Fix merge" |
| 19:55 |
hmmmm |
this is why he's not a minetest core dev |
| 19:56 |
rubenwardy |
This is why I'm not a Minetest core dev: https://github.com/rubenwardy/NodeBoxEditor/blob/master/src/FileDialog.cpp#L85 |
| 19:56 |
hmmmm |
that's in bad taste but it's not invalid |
| 19:57 |
Brains |
Heh, I had a dickens of a time convincing people that delete this was valid if not exactly the best taste... |
| 19:58 |
rubenwardy |
"bad taste"? Like bad code style/structure? |
| 19:58 |
hmmmm |
yes |
| 19:58 |
rubenwardy |
Okay |
| 19:58 |
hmmmm |
the "C++ way" is to perform deinitialization in the destructor |
| 19:58 |
hmmmm |
so "delete fileobject" should actually be the thing to close the file handle |
| 19:59 |
rubenwardy |
ah, that makes sense |
| 19:59 |
hmmmm |
RAII and all that great stuff |
| 19:59 |
hmmmm |
RAII is retarded and doesn't need to exist if it weren't for exceptions |
| 19:59 |
hmmmm |
C++ is a shit language |
| 20:00 |
rubenwardy |
Why does Irrlicht use drop rather than delete? |
| 20:00 |
rubenwardy |
ie node->drop(); delete node; |
| 20:03 |
rubenwardy |
Ah, grab() |
| 20:03 |
Kray |
do you even know the point of RAII |
| 20:03 |
Kray |
it is not that you manually do it |
| 20:03 |
Kray |
but you use proper memory management |
| 20:03 |
Kray |
as in unique_ptr or shared_ptr |
| 20:03 |
exio4 |
it is poor man's garbage collection |
| 20:04 |
Kray |
if it wasn't for the fact C++ doesn't have special syntax to make it less verbose, this is superior way to do memory management |
| 20:04 |
hmmmm |
and if you used unique_ptr/shared_ptr, you wouldn't need a destructor |
| 20:04 |
Kray |
garbage collection doesn't guarantee object lifetime and features possible performance issues |
| 20:04 |
Kray |
u wot |
| 20:04 |
Kray |
it is the destructor doing all the work |
| 20:04 |
Kray |
which is being invoked by the memory container |
| 20:05 |
hmmmm |
maybe if there was a special piece of syntax that told the compiler to automatically manage this thing |
| 20:05 |
hmmmm |
like I said... destructors are unnecessary |
| 20:05 |
Kray |
do you even know what you are talking about |
| 20:06 |
Kray |
if you have some kind of a file handle, you obviously need to close it |
| 20:06 |
Kray |
which is done in the destructor |
| 20:06 |
hmmmm |
what's the difference between file->close(); |
| 20:06 |
hmmmm |
and delete file; |
| 20:06 |
hmmmm |
you're assuming that RAII simply needs to exist |
| 20:06 |
Kray |
delete file; is unnecessary when you manage your memory properly |
| 20:07 |
Kray |
you don't need to do anything to clean up after you |
| 20:07 |
Kray |
the file gets closed when you can no longer access the thing using the file automatically |
| 20:07 |
Kray |
as in, when the unique_ptr or last shared_ptr gets deinitialized from heap |
| 20:08 |
Kray |
if you write modern c++ you write 0 new or delete statements |
| 20:08 |
hmmmm |
you use files how often? |
| 20:08 |
Kray |
this is not just about files |
| 20:08 |
hmmmm |
like 1% of the time? |
| 20:08 |
Kray |
this is everything memory |
| 20:08 |
rubenwardy |
Why use new when you can use malloc? |
| 20:08 |
hmmmm |
99% of destructor usage is memory management |
| 20:10 |
hmmmm |
this all simply confirms my point that the concept of constructors/destructors is necessary only because of exceptions |
| 20:11 |
hmmmm |
just because other languages jumped on the RAII train doesn't mean you have to. it simply requires you to write more code to do the same task |
| 20:11 |
kahrl |
I've read new/delete based code and smart pointer based code, I've always found the latter much harder to follow |
| 20:11 |
kahrl |
anyway shared_ptr is boost or C++11 so this kind of moot for minetest |
| 20:11 |
kahrl |
this is* |
| 20:11 |
|
nore joined #minetest-dev |
| 20:12 |
Kray |
hmmmm: it requires you to write more code and remember to do all deinitializations and stuff yourself |
| 20:12 |
Kray |
more code to do same thing AND more ways to introduce bugs |
| 20:12 |
hmmmm |
again, not if your language had some kind of "auto-deallocate" |
| 20:12 |
rubenwardy |
destructors are overrated. Just do pvariable = NULL; |
| 20:13 |
hmmmm |
you're stuck in the C++ mode of thinking |
| 20:13 |
rubenwardy |
Easy |
| 20:13 |
hmmmm |
if C++ does it, it must be the correct way to do it, I guess |
| 20:13 |
Kray |
C++ does shitload of stuff so wrong it's not even funny |
| 20:14 |
Kray |
but RAII is simply superior |
| 20:14 |
hmmmm |
I don't know about you, but I can't see it |
| 20:14 |
rubenwardy |
What have I started? |
| 20:14 |
Kray |
i write C# for living and otherwise it is genuinely a good language, but i miss so much C++ style guaranteed object lifetime |
| 20:15 |
rubenwardy |
c# is good, except it is pretty much Windows only. |
| 20:15 |
hmmmm |
RAII has nothing to do with object lifetime. |
| 20:15 |
Kray |
RAII has everything to do with object lifetime |
| 20:16 |
rubenwardy |
C# is a powerful laser rifle strapped to a donkey, when taken off the donkey the laser doesn't seem to work as well. http://img.svbtle.com/ddmvewfmbobm0g.png |
| 20:16 |
hmmmm |
are you sure you know what you're talking about? |
| 20:16 |
hmmmm |
:) |
| 20:16 |
Kray |
>In RAII, holding a resource is tied to object lifetime |
| 20:16 |
Kray |
t: wikipedia |
| 20:16 |
hmmmm |
holding a resource |
| 20:17 |
hmmmm |
holding. a. resource. |
| 20:17 |
hmmmm |
that doesn't affect the object lifetime at all |
| 20:17 |
Kray |
RAII is the concept of object lifetime |
| 20:17 |
hmmmm |
no it's not |
| 20:17 |
hmmmm |
object lifetime is something separate |
| 20:17 |
Kray |
when the object begins to exist, i.e. you allocate it dynamically or from the heap, it is initialized |
| 20:17 |
hmmmm |
there is no such thing as the 'heap' |
| 20:17 |
hmmmm |
that's an implementation specific detail and it doesn't belong in this discussion |
| 20:18 |
Kray |
you know full well what i mean |
| 20:18 |
hmmmm |
stop saying that |
| 20:18 |
rubenwardy |
Go to PM? |
| 20:18 |
Kray |
when the object is no longer accessible, it is denitialized and its lifetime ends |
| 20:18 |
kahrl |
btw, here's a more recently rebased version of the vbo patch: https://github.com/kahrl/minetest/tree/vbo |
| 20:18 |
VanessaE |
kahrl: ah, that's a bit better :) |
| 20:19 |
hmmmm |
but how does initialization and deinitialization have anything to do with the object's lifetime |
| 20:19 |
hmmmm |
I can initialize an object 5 lines later in C |
| 20:19 |
Kray |
are you serious |
| 20:19 |
rubenwardy |
Well, they generally mark the start and the end |
| 20:19 |
hmmmm |
yes, I am serious |
| 20:19 |
Kray |
the object is initialized when it begins to exist |
| 20:19 |
hmmmm |
with RAII |
| 20:19 |
Kray |
it is denitialized when it ceases it |
| 20:19 |
hmmmm |
yes |
| 20:19 |
Kray |
yes, with RAII |
| 20:19 |
hmmmm |
so are you saying that everything in the world uses RAII because it's so awesome? |
| 20:20 |
hmmmm |
my point is that RAII does not dictate anything about object lifetime |
| 20:20 |
Kray |
wat |
| 20:20 |
hmmmm |
an object's lifetime is a separate concept from initialization and deinitialization. RAII combines the two. |
| 20:20 |
Kray |
it is even in the initialism itself |
| 20:20 |
Kray |
Resource Acquisition Is an Initialization |
| 20:21 |
hmmmm |
RAII is the concept that they should be one in the same |
| 20:21 |
hmmmm |
but they don't need to be |
| 20:21 |
hmmmm |
RAII mechanisms combine the two to happen concurrently |
| 20:22 |
hmmmm |
so like I said, RAII has nothing to do with object lifetime. |
| 20:22 |
hmmmm |
in the sense that it does not affect object lifetime |
| 20:22 |
hmmmm |
RAII makes events dependent upon an object's lifetime however |
| 20:22 |
hmmmm |
are you seriously arguing with this? |
| 20:23 |
Kray |
by now you are just generating nonsense to make it seem like you have an argument |
| 20:23 |
hmmmm |
you're a C++ fanboy with his RAII head stuck so far up his ass he can't see anything different |
| 20:24 |
|
crazyR joined #minetest-dev |
| 20:24 |
hmmmm |
you can set some default values by adding a piece of syntax to do that in the class declaration. you can manage memory by adding a piece of syntax to tell the compiler to clear it at the end of the object's lifetime. there is no need for constructors or destructors. |
| 20:25 |
hmmmm |
it leads to nothing more than adding more tasks to a programmer's todo list that makes coding less enjoyable |
| 20:25 |
celeron55 |
i actually agree with hmmmm in "RAII is retarded and doesn't need to exist if it weren't for exceptions", but some of the things you're saying is not right |
| 20:25 |
hmmmm |
"oh gotta define a constructor for this" |
| 20:26 |
celeron55 |
or, well, not that it's completely retarded, but it's not a necessary thing in a language |
| 20:26 |
hmmmm |
it's retarded because it poisoned the well |
| 20:26 |
celeron55 |
hmmmm: did you watch some of the videos i linked to you previously? |
| 20:26 |
hmmmm |
case in point: kray thinks it's the only way existing |
| 20:26 |
hmmmm |
no |
| 20:26 |
celeron55 |
because what you're now saying is like taken almost directly from them |
| 20:26 |
celeron55 |
...and the guy proceeds to start designing his own language after the ranting videos |
| 20:26 |
Kray |
222010 +hmmmm my point is that RAII does not dictate anything about object lifetime |
| 20:27 |
hmmmm |
haha :( I found myself |
| 20:27 |
Kray |
this is so incredibly wrong statement |
| 20:27 |
hmmmm |
I was designing a "new-C" a year ago |
| 20:27 |
hmmmm |
this is one of the major things |
| 20:27 |
hmmmm |
Kray, tell me |
| 20:28 |
Kray |
RAII is a model of object lifetime |
| 20:28 |
Kray |
no one who has any kind of understanding of what it is can state that RAII doesn't dictate anything about object lifetime |
| 20:28 |
hmmmm |
it's a model of initializing and deinitializing on object lifetime events |
| 20:28 |
hmmmm |
RAII told me that the object dies when it falls out of scope - right? |
| 20:28 |
Kray |
on object lifetime events that it dictates |
| 20:28 |
hmmmm |
but wait that happens with C too |
| 20:28 |
hmmmm |
C doesn't have RAII |
| 20:29 |
hmmmm |
what is going on here |
| 20:29 |
Kray |
on lifetime events that are necessary for it to work |
| 20:29 |
celeron55 |
hmmmm: watch all of this stuff later once you have time, starting from "Ideas about a new programming language for games.": https://www.youtube.com/user/jblow888/videos |
| 20:29 |
Kray |
on lifetime events that don't exist in garbage collected languages |
| 20:29 |
hmmmm |
haha |
| 20:29 |
hmmmm |
celeron55: is it more like C than it is a better C++? |
| 20:29 |
celeron55 |
it's also in my blog http://c55.me/blog/?p=1723 |
| 20:29 |
celeron55 |
hmmmm: yes, the guy hates C++ in the same way as I and you |
| 20:29 |
hmmmm |
alright |
| 20:30 |
hmmmm |
so I'm nowhere near being alone in that I want a better C and C++ is the wrong way to go |
| 20:30 |
celeron55 |
he is going to publish it free and open source later, but he's keeping it to himself until it's proper |
| 20:30 |
hmmmm |
I started writing down some design concepts for my language but I never did anything about it because i have no time and better things to do |
| 20:30 |
hmmmm |
I bet you did the same thing, right? |
| 20:30 |
celeron55 |
no i haven't done such |
| 20:30 |
celeron55 |
i'm too much of a practical person |
| 20:30 |
celeron55 |
8) |
| 20:31 |
hmmmm |
does his new-C language have optional garbage collection? |
| 20:31 |
celeron55 |
no |
| 20:31 |
hmmmm |
there's one difference |
| 20:32 |
celeron55 |
watch the videos for your entertainment at some point, let's discuss them then 8) |
| 20:32 |
|
acerspyro joined #minetest-dev |
| 20:32 |
celeron55 |
i recommend them to Kray too |
| 20:34 |
hmmmm |
i'l check it out |
| 20:34 |
hmmmm |
i'd much rather get some of the biome crap done though |
| 20:40 |
|
Miner_48er joined #minetest-dev |
| 20:40 |
hmmmm |
wish the videos were in text format.. I read a lot faster than I do listen to some guy in front of a webcam |
| 20:43 |
celeron55 |
yeah; you really have to watch them at some time when you're not in the mood of doing anything |
| 20:43 |
celeron55 |
or do some cooking or stuff while listening |
| 20:43 |
hmmmm |
i can't multitask |
| 20:44 |
celeron55 |
or, just sit back and throw efficency in the thrash, it's a hobby anyway |
| 20:44 |
celeron55 |
trash* |
| 20:44 |
celeron55 |
+i |
| 20:45 |
celeron55 |
i'm *watching* a 3-hour live streamed podcast at the moment, about videogames 8D |
| 20:45 |
hmmmm |
i suppose i could eat while watching videos, because eating is more automatic than other things |
| 20:45 |
celeron55 |
because... well, i got enough done today already |
| 20:47 |
celeron55 |
i enjoy listening to that guy, he's not bad or uninteresting at speaking at all |
| 20:47 |
hmmmm |
i like this guy so far |
| 20:52 |
kahrl |
I tend to watch videos (well, some) at increased speed |
| 20:52 |
kahrl |
you can listen faster than talk |
| 20:55 |
celeron55 |
i find myself burning out easily if i'm "efficient" so i find long videos to be quite convenient |
| 20:55 |
celeron55 |
put a few in a day and it's much harder to overwork yourself 8) |
| 20:58 |
kahrl |
yeah, I watch the "serious" videos at increased speed so I have more time to watch non-serious stuff at normal speed to relax :P |
| 20:59 |
kahrl |
"serious" = mostly lectures from my uni or some MOOC |
| 21:08 |
|
J_L joined #minetest-dev |
| 21:12 |
|
josh joined #minetest-dev |
| 21:13 |
Guest32871 |
Hey guys I just was noticing this glitchy behavior, think it's worth filing an issue? Video of the problem https://www.dropbox.com/s/i7zfklip3g85gwq/out.ogv?dl=0 |
| 21:13 |
Guest32871 |
(Namely, the seeing through walls) |
| 21:15 |
hmmmm |
yeah i noticed that too |
| 21:15 |
hmmmm |
file an issue about it... it started recently |
| 21:15 |
kahrl |
this is with the default FOV, right? |
| 21:16 |
Guest32871 |
Yes |
| 21:16 |
|
roniz joined #minetest-dev |
| 21:17 |
kahrl |
any idea when it started happening? |
| 21:17 |
Guest32871 |
kahrl: No idea, I just downloaded the game today :) |
| 21:18 |
kahrl |
ah okay |
| 21:18 |
kahrl |
there was a similar bug a long time ago (#718) but only with increased FOV, so yours is not a duplicate |
| 21:18 |
kahrl |
definitely file an issue |
| 21:19 |
celeron55 |
it seems like you have to be exactly at that position relative to mapblocks for it to happen |
| 21:23 |
VanessaE |
I've noticed it too, and have for a long while. |
| 21:23 |
VanessaE |
didn't think to mention it. |
| 21:24 |
Guest32871 |
celeron55, kahrl: It would be helpful to include my game save or something to reproduce the issue I'm thinking. Where could I find some such save file? |
| 21:24 |
VanessaE |
it's really noticable if you have a lot of map loaded up, and you fly high in order to take a wide-angle screenshot (e.g. a world preview image for a server topic) |
| 21:24 |
VanessaE |
(default FoV) |
| 21:26 |
celeron55 |
it's probably not the same issue |
| 21:27 |
celeron55 |
it's in the same system but a different issue |
| 21:27 |
celeron55 |
those close mapblocks aren't supposed to be handled by the same calculation as the very far ones |
| 21:31 |
kahrl |
Guest32871: I assume a game save won't be necessary, just include the coordinates and which direction you're facing |
| 21:31 |
kahrl |
just make a screenshot with the F5 debug info enabled |
| 21:39 |
Guest32871 |
kahrl, celeron55, VanessaE, hmmmm : https://github.com/minetest/minetest/issues/2032 |
| 21:41 |
|
crazyR_ joined #minetest-dev |
| 21:49 |
kahrl |
Guest32871: yeah, I can reproduce that when I load your world |
| 21:52 |
kahrl |
also when I build a similar staircase in another world at the same coordinates |
| 21:54 |
|
shadowzone joined #minetest-dev |
| 21:54 |
Guest32871 |
Interesting |
| 21:56 |
kahrl |
easiest way to reproduce this is to stand at x=z=0 and dig down until the F5 info shows y = -2.5 |
| 21:56 |
kahrl |
then jump |
| 22:06 |
|
fz72 joined #minetest-dev |
| 22:07 |
|
cody2 joined #minetest-dev |
| 22:15 |
|
MinetestForFun joined #minetest-dev |
| 22:35 |
kahrl |
https://gist.github.com/kahrl/4c0dbb62b3bd67666c03 |
| 22:35 |
kahrl |
not sure if that is the best way to fix it but it works |
| 22:36 |
kahrl |
the issue is that the camera is just outside the radius given by block_max_radius but still close enough that the FOV check below fails |
| 22:38 |
kahrl |
perhaps the FOV check can be fixed but I don't have any idea how |
| 22:51 |
Guest32871 |
Wow that was fast! |
| 23:30 |
|
RealBadAngel joined #minetest-dev |
| 23:30 |
RealBadAngel |
hi |
| 23:32 |
celeron55 |
kahrl: yeah, and it occurs because of that due to block visibility not being updated every frame |
| 23:32 |
celeron55 |
or... umm... maybe |
| 23:33 |
celeron55 |
at least it might be part of what is going on but whatever, if that works in practice, it's fine |
| 23:37 |
RealBadAngel |
the issue looks like wrong positioned camera or somethin like that |
| 23:38 |
RealBadAngel |
block visibility cannot be updated every frame |
| 23:39 |
RealBadAngel |
it is done in mapblock mesh updates only |
| 23:41 |
RealBadAngel |
only way to make those faces invisible is imho the position of the camera |
| 23:49 |
celeron55 |
lol don't start |
| 23:50 |
celeron55 |
you're going to the wrong direction and already just embarras everybody |
| 23:50 |
celeron55 |
+s |
| 23:51 |
RealBadAngel |
just a thought, im not sure |
| 23:55 |
RealBadAngel |
on the other hand mesh updates doesnt care about face visibility, only irrlicht can eliminate visible faces |
| 23:55 |
RealBadAngel |
i mean depending on camera position |
| 23:56 |
RealBadAngel |
notice that happens on jumps, changing camera position |
