| Time |
Nick |
Message |
| 00:30 |
|
Fractalis joined #minetest-dev |
| 00:38 |
|
Fractalis joined #minetest-dev |
| 00:38 |
|
hlqkj1 joined #minetest-dev |
| 00:40 |
|
hlqkj1_ joined #minetest-dev |
| 01:02 |
|
I_am_6r1d joined #minetest-dev |
| 01:33 |
|
EvergreenTree_ joined #minetest-dev |
| 01:33 |
|
_0_ joined #minetest-dev |
| 01:34 |
|
jomat_ joined #minetest-dev |
| 01:36 |
|
EvergreenTree_ joined #minetest-dev |
| 01:37 |
|
EvergreenTree_ joined #minetest-dev |
| 01:39 |
|
Emojiwiki joined #minetest-dev |
| 01:42 |
Emojiwiki |
Foward from Discord |
| 01:42 |
Emojiwiki |
Emojidiscord: I got this message while compiling which said I should use minetest's irrlicht fork. I know what happend, but I don't want to globally install minetest's fork of it. How to compile without globaly install irrlicht fork? |
| 01:42 |
Emojiwiki |
Rubenwardy: You need to use Minetest's Irrlicht fork now (with some solution) |
| 01:42 |
Emojiwiki |
Emojidiscord: I download and compiled irrlicht at /home/foobar/irrlicht with -DBUILD_SHARED_LIBS=OFF on irrlicht then used -DIRRLICHT_INCLUDE_DIR=/home/foobar/irrlicht in minetest but got the same error as not installed the fork |
| 01:42 |
Emojiwiki |
Rubenwardy: there are other settings, `IRRLICHT_LIBRARY` probably |
| 01:42 |
Emojiwiki |
Emojidiscord: Same (photo https://cdn.discordapp.com/attachments/369137254641303560/819020372304461834/unknown.png ) |
| 01:42 |
Emojiwiki |
(Continue to IRC) |
| 01:43 |
Emojiwiki |
PS: I am Emojidiscord |
| 01:43 |
rubenwardy |
the conversation: https://rwdy.uk/JwHBh.png |
| 01:44 |
rubenwardy |
the fact that IRRLICHT_INCLUDE_DIR and IRRLICHT_LIBRARY exists implies that it's using a legacy cmake module :( |
| 01:44 |
Emojiwiki |
I am using the ninja compiler, is it the reason? |
| 01:53 |
Emojidiscord |
Using cmake `-DIRRLICHT_LIBRARY=/home/foobar/irrlicht/lib/Linux/libIrrlicht.` but failed. |
| 01:57 |
rubenwardy |
are you missing an a? |
| 01:57 |
rubenwardy |
of copy and past issue |
| 01:57 |
rubenwardy |
*or |
| 01:57 |
rubenwardy |
you might need to delete CMakeCache.txt and CMakeFiles and rerun cmake. Somethings things stick around |
| 02:02 |
Emojidiscord |
missing an a: no, just copy and paste typo |
| 02:02 |
Emojidiscord |
rubenwardy delete cache and makefiles: still buggy |
| 02:02 |
Emojidiscord |
makefiles -> cmake files |
| 02:11 |
Emojidiscord |
finally success |
| 02:46 |
|
I_am_6r1d joined #minetest-dev |
| 03:30 |
|
mw__ joined #minetest-dev |
| 03:54 |
|
mw__ joined #minetest-dev |
| 04:22 |
|
mw__ joined #minetest-dev |
| 05:00 |
|
MTDiscord joined #minetest-dev |
| 05:09 |
MTDiscord |
<Techy5> Why is the deleteblocks command so agonizingly slow? Something like /deleteblocks here 32 takes maybe 15-30 seconds. For comparison, deleting those mapblocks using my external program takes less than a second, and MT regenerates the area in a couple seconds when I join the game again. |
| 05:17 |
MTDiscord |
<Techy5> I tried deleting a 100+ node radius, and it pretty much crashed the game. Again, deleting blocks with SQL + letting MT regenerate them took only a few seconds. |
| 05:43 |
|
indiana joined #minetest-dev |
| 06:45 |
|
olliy joined #minetest-dev |
| 07:44 |
|
proller joined #minetest-dev |
| 07:56 |
nerzhul |
the transition is not so easy |
| 08:00 |
|
ShadowNinja joined #minetest-dev |
| 09:37 |
sfan5 |
rubenwardy: what is a "legacy cmake module"? |
| 10:24 |
|
proller joined #minetest-dev |
| 10:30 |
|
hlqkj joined #minetest-dev |
| 10:32 |
|
Fixer joined #minetest-dev |
| 10:39 |
|
calcul0n_ joined #minetest-dev |
| 10:48 |
|
freshreplicant[m joined #minetest-dev |
| 11:24 |
|
kb1000 joined #minetest-dev |
| 11:24 |
|
Zughy[m] joined #minetest-dev |
| 11:24 |
|
Newbyte joined #minetest-dev |
| 11:24 |
|
giov4[m] joined #minetest-dev |
| 11:28 |
|
hlqkj1_ joined #minetest-dev |
| 11:44 |
Zughy[m] |
free PR to merge: #11038 |
| 11:44 |
ShadowBot |
https://github.com/minetest/minetest/issues/11038 -- Builtin: Italian translation by Zughy |
| 11:45 |
|
hlqkj1 joined #minetest-dev |
| 12:01 |
|
Lunatrius joined #minetest-dev |
| 12:24 |
|
tech_exorcist joined #minetest-dev |
| 13:34 |
|
tech_exorcist joined #minetest-dev |
| 13:37 |
|
tech_exorcist joined #minetest-dev |
| 14:10 |
|
hlqkj1 joined #minetest-dev |
| 14:29 |
|
z812 joined #minetest-dev |
| 14:30 |
sfan5 |
rubenwardy: can you push this to gitlab so I can see if the ci runs? https://github.com/sfan5/minetest/tree/cmakestuff1 |
| 14:31 |
rubenwardy |
remember that minetest/minetest pushes to GL automatically |
| 14:31 |
rubenwardy |
<sfan5> rubenwardy: what is a "legacy cmake module"? |
| 14:31 |
rubenwardy |
It uses variables rather than targets |
| 14:32 |
sfan5 |
does minetest/minetest push to gitlab even if it's not the master branch? |
| 14:32 |
sfan5 |
i'll just try |
| 14:46 |
rubenwardy |
yeah |
| 15:28 |
|
z812 joined #minetest-dev |
| 15:32 |
|
DS-minetest joined #minetest-dev |
| 15:33 |
|
z812 joined #minetest-dev |
| 15:38 |
|
z812 joined #minetest-dev |
| 16:01 |
Krock |
What's the purpose of m_nnlistsizes within NodeResolver? |
| 16:01 |
Krock |
why is it even needed? |
| 16:05 |
Krock |
most of the node resolver code seems totally superfluous. it's just an overcomplicated queue |
| 16:15 |
|
Wuzzy joined #minetest-dev |
| 16:26 |
|
tech_exorcist joined #minetest-dev |
| 16:31 |
|
tech_exorcist joined #minetest-dev |
| 16:34 |
sfan5 |
¯\_(ツ)_/¯ |
| 16:35 |
|
v-rob joined #minetest-dev |
| 16:41 |
Wuzzy |
oh wow, you people actually forked irrlicht. i can't believe it. what's that thing about? |
| 16:42 |
MTDiscord |
<Jordach> a long list of reasons that would be considered paste spam |
| 16:42 |
Wuzzy |
haha |
| 16:42 |
MTDiscord |
<Jordach> look it builds under the fancy smanchy M1 Mac |
| 16:43 |
Wuzzy |
have there already been changes to the "Minetest irrlicht"? |
| 16:43 |
MTDiscord |
<Jordach> yes |
| 16:43 |
MTDiscord |
<Jordach> that said, since the difference between M1 and AX CPUs isn't a great deal, an official iOS build isn't hard to do |
| 16:44 |
v-rob |
I'll brag a bit -- my push for SDL2 revitalized interest in having the fork |
| 16:46 |
v-rob |
However, it'll be really nice to fix bugs instead of working around them. |
| 16:47 |
MTDiscord |
<Jordach> if you holler at me i can print macOS M1 builds |
| 16:47 |
MTDiscord |
<Jordach> i cannot build Intel however |
| 16:47 |
MTDiscord |
<appguru> yes, fixing bugs! |
| 16:47 |
|
numzero joined #minetest-dev |
| 16:47 |
MTDiscord |
<appguru> especially related to bones |
| 16:48 |
MTDiscord |
<appguru> I can't get bones to work |
| 16:48 |
Wuzzy |
Who wants to bet that the big Irrlicht release comes out next week, because Murphy's law? ? |
| 16:48 |
v-rob |
If they have SDL2, I'm happy |
| 16:49 |
MTDiscord |
<Jonathon> isnt minetest irrlicht based on 1.9 anyways? |
| 16:49 |
v-rob |
Yeah |
| 16:50 |
v-rob |
To be precise, the OGL-ES branch for Android support |
| 16:50 |
DS-minetest |
So, do we want to decouple minetest from irrlicht or do we want to merge it? |
| 16:50 |
MTDiscord |
<Jonathon> so not that big of a deal if 1.9 where to release in a week |
| 16:51 |
v-rob |
It's kind of a consensus that we're unlikely to ever change from Irrlicht, but I don't think we're going to go all-in either. |
| 16:53 |
DS-minetest |
i see |
| 16:55 |
v-rob |
That doesn't mean we can't use advanced Irrlicht features, but just that I don't think there will be drastic changes in that direction |
| 16:55 |
numzero |
advanced features? aka OpenGL 2.1? |
| 16:56 |
v-rob |
No, the absolutely fantastic software drivers, of course |
| 16:57 |
v-rob |
The future's in software renderers, as anyone knows |
| 16:57 |
numzero |
btw Mesa supports OpenGL 4.6 in software |
| 16:57 |
numzero |
as a reference implementation IIRC, to compare hardware drivers against |
| 16:59 |
v-rob |
Software renderers aren't necessarily bad, especially when you don't have a GPU (such as on a 15 MHz Motorola 68K embedded system on which I program on occasion) |
| 17:00 |
numzero |
exactly |
| 17:00 |
numzero |
Intel HD doesn’t count as a GPU too IIRC |
| 17:02 |
MTDiscord |
<Jordach> macOS does support OpenGL 4.1 |
| 17:02 |
v-rob |
But Minetest on the Burning's Video software driver can barely break 30 fps, so they're no good for us :) |
| 17:03 |
MTDiscord |
<Jordach> the only thing burning with that driver is Intel CPUs |
| 17:03 |
v-rob |
Ha |
| 17:06 |
numzero |
btw macOS supports OpenGL core profile only IIRC so MT has to use OpenGL 2.1 there (last version before profile split) |
| 17:06 |
MTDiscord |
<Jordach> https://support.apple.com/en-us/HT202823 ? |
| 17:07 |
MTDiscord |
<Jordach> ah |
| 17:07 |
MTDiscord |
<Jordach> Mac OS will report the GL version to be 2.1 to GL apps that don't explicitly set a couple of flags before opening the window. |
| 17:07 |
MTDiscord |
<Jordach> https://stackoverflow.com/questions/19658745/why-is-my-opengl-version-always-2-1-on-mac-os-x |
| 17:07 |
MTDiscord |
<Jordach> simple fix |
| 17:08 |
MTDiscord |
<Jordach> afaik my M1 enabled Air also supports 4.1 |
| 17:08 |
numzero |
https://www.khronos.org/opengl/wiki/Core_And_Compatibility_in_Contexts#OpenGL_3.2_and_Profiles |
| 17:08 |
numzero |
is the note on MacOSX correct? |
| 17:09 |
MTDiscord |
<Jordach> kind of incorrect these days |
| 17:10 |
MTDiscord |
<Jordach> glfwWindowHint(GLFW_OPENGL_PROFILE, GLFW_OPENGL_CORE_PROFILE); is basically what switches 2.1 backwards compatibility mode off |
| 17:10 |
MTDiscord |
<Jordach> fortunately it's a real simple #ifdef |
| 17:13 |
numzero |
Jordach: explain please. Do you mean it is now possible to create an OpenGL 3+ compatibility context on MacOS? |
| 17:13 |
MTDiscord |
<Jordach> has been since mavericks |
| 17:14 |
MTDiscord |
<Jordach> which supports macs as far back as 2008 |
| 17:19 |
v-rob |
On a different note, I'm looking into making a 4x4 transformation matrix and/or quaternion API, but I don't know whether or not it should be modelled after the vector API. |
| 17:19 |
v-rob |
Specifically, should it use metatable methods or standalone functions, and should the functions modify in place or return a new matrix/quaternion? |
| 17:23 |
DS-minetest |
I think, creating new tables all the time isn't a big problem because luajit can sink them away |
| 17:24 |
v-rob |
It's definitely more convenient. A metatable vector API that returns copies could do v1:dot(v2):dot(v3), which is nicer than v1:dot(v2); v1:dot(v3) |
| 17:25 |
DS-minetest |
(might be the wrong terminology or wrong reson, sry) http://wiki.luajit.org/Allocation-Sinking-Optimization |
| 17:26 |
DS-minetest |
regarding metatable vs. standalone functions, I'd say allow both |
| 17:26 |
v-rob |
Sure, that's how all metatables work |
| 17:28 |
v-rob |
Like string.upper(str) and str:upper() |
| 17:28 |
|
ircSparky joined #minetest-dev |
| 17:28 |
|
ircSparky joined #minetest-dev |
| 17:29 |
DS-minetest |
(not necessarily, you can set a metatable {__index=local_table_of_functions} and the user can't get functions from that local_table_of_functions without having an instance) |
| 17:29 |
v-rob |
OK, most metatables then :) |
| 17:30 |
v-rob |
Also, there was some controversy over vectors having x, y, and z keys instead of an array. Which is better for quaternions to use internally then? Because __index can emulate both. |
| 17:30 |
MTDiscord |
<appguru> I'd prefer arrays |
| 17:30 |
DS-minetest |
I'd prefer arrays too. |
| 17:31 |
DS-minetest |
the emulation via __index seems to be slower |
| 17:32 |
|
Taoki joined #minetest-dev |
| 17:32 |
v-rob |
Yes, __index would slow things down, but then array-based quaternions would be inconsistent with key-based vectors, which would be weird |
| 17:33 |
DS-minetest |
it would be more weird having both vectors and quaternions having x, y and z, I think |
| 17:37 |
sfan5 |
<v-rob> However, it'll be really nice to fix bugs instead of working around them. |
| 17:37 |
sfan5 |
you have probably seen already: #11040 |
| 17:37 |
ShadowBot |
https://github.com/minetest/minetest/issues/11040 -- Revisit Irrlicht workarounds |
| 17:37 |
v-rob |
Yes |
| 17:38 |
v-rob |
Although there's no possibility of merging our GUI elements back into Irrlicht because they are too integrated with the current formspec code, e.g. StyleSpec, in case there was any thought of that. |
| 17:39 |
DS-minetest |
Then remove the GUI element classes from irrlicht and copy them to minetest. |
| 17:41 |
v-rob |
In the line of Irrlicht bugs, IVideoDriver::getViewPort doesn't return the actual viewport for render textures since it uses glViewPort without calling setViewPort, which causes some funky bugs. See https://github.com/minetest/minetest/pull/10801/files#diff-81c0cf94b1691085508abec134d3e6f96b26d5a131cc009a8bb424c1f13ebb15R170-R174 |
| 17:42 |
v-rob |
I wouldn't be surprised if that's caused problems with render textures for us in the past |
| 17:47 |
v-rob |
Back to matricies: I think the best course of action is to use core::matrix4 to do the actual calculations, but if I use a full userdata, that essentially renders ipairs impossible |
| 17:47 |
v-rob |
And hence things like minetest.serialize would break on matricies |
| 17:48 |
DS-minetest |
doing it in lua is much faster |
| 17:48 |
v-rob |
True, but then all calculation have to be copied, and matrix calculations are pretty complex |
| 17:48 |
DS-minetest |
especially if you don't even use luajit's ffi lib, which minetest currently doesn't |
| 17:49 |
DS-minetest |
Do you mean implementation-wise? |
| 17:49 |
v-rob |
Yes, and some matrix calculations are pretty complex |
| 17:50 |
v-rob |
Like inverses |
| 17:50 |
DS-minetest |
Not for 3x3 matrices. |
| 17:50 |
MTDiscord |
<appguru> Why can't you operate on the Lua table? |
| 17:50 |
MTDiscord |
<appguru> Like, from C++ |
| 17:51 |
MTDiscord |
<y5nw> Too much overhead |
| 17:51 |
MTDiscord |
<appguru> If you do decide in favor of userdata, just add an iterator like matrix4:ipairs() |
| 17:52 |
v-rob |
Right, but that still breaks minetest.serialize, table.copy, minetest.write_json, mod-written iterators, etc |
| 17:52 |
MTDiscord |
<y5nw> LuaJIT recognizes the __ipairs metamethod but not the non-JIT Lua :\ |
| 17:52 |
v-rob |
Not at least in 5.1. 5.2 recognizes __ipairs and __len |
| 17:53 |
MTDiscord |
<appguru> well, it would have all the issues of userdata |
| 17:53 |
MTDiscord |
<y5nw> IMO we might be able to solve certain problems simply by dropping (non-JIT) Lua 5.1. I saw earlier some code with bitwise operations in Lua and that was horrifying to me (not talking about it further here) |
| 17:53 |
DS-minetest |
afaik it must fall back to interpreter whenever a normal lua c api function involved, for obvious reasons. and I don't know in what way ipairs would differ there |
| 17:54 |
MTDiscord |
<appguru> one could override ipairs |
| 17:54 |
MTDiscord |
<appguru> or pairs and next, for that matter |
| 17:54 |
MTDiscord |
<appguru> but it would definitely hurt performance somewhat |
| 17:54 |
v-rob |
Ugh, don't want to go down that path just for matricies |
| 17:54 |
MTDiscord |
<appguru> Dropping Lua 5.1 support in favor of LuaJIT would be great. |
| 17:54 |
|
z812 joined #minetest-dev |
| 17:54 |
DS-minetest |
ah, for seraialize you mean. I think the bigger problem is type returning "userdata" |
| 17:54 |
MTDiscord |
<appguru> LuaJIT has gotos :D |
| 17:55 |
MTDiscord |
<appguru> And a ton of other handy features |
| 17:55 |
MTDiscord |
<y5nw> Sounds like we can have BASIC modding now with goto |
| 17:55 |
MTDiscord |
<appguru> Plus the performance benefit |
| 17:55 |
v-rob |
How much overhead would C++ operations on a Lua table be? C++ operations would have to copy the array to a matrix and then return a new table, but Lua access with e.g. [] would be faster than full userdata |
| 17:55 |
MTDiscord |
<appguru> nah goto is just handy for exiting multiple loops |
| 17:55 |
MTDiscord |
<appguru> alternative is a local function |
| 17:56 |
DS-minetest |
I would love a drop of Lua5.1. but on the other this would mean that we support less cpu architectures, no? |
| 17:56 |
MTDiscord |
<y5nw> The problem with accessing Lua tables from C is that you need to access it via lua using rawgeti() (etc) where the overhead adds up |
| 17:56 |
v-rob |
Well, `continue` would be nice, but it doesn't work on repeat...until loops, so it's not in Lua yet |
| 17:56 |
MTDiscord |
<y5nw> Afaik LuaJIT already supports the ones that are quite commonly used. ARM and x86 at least, afaik |
| 17:57 |
rubenwardy |
<v-rob> True, but then all calculation have to be copied, and matrix calculations are pretty complex |
| 17:57 |
rubenwardy |
you'd also have the overhead of calling functions to C++ |
| 17:57 |
MTDiscord |
<appguru> continue and other handy stuff is why I'm planning a preprocessor |
| 17:57 |
DS-minetest |
yeah, but think about the future, what about eg. RiscV? |
| 17:57 |
MTDiscord |
<Jordach> Fun fact LuaJIT doesn’t currently compile on ARM64 |
| 17:57 |
MTDiscord |
<appguru> non-LuaJIT has inacceptable performance |
| 17:57 |
Krock |
errorstream appears to bes too slow in fatal_error_fn/sanity_check_fn |
| 17:57 |
v-rob |
Is lua_rawgeti() actually that bad? It accesses the array part directly without __index |
| 17:57 |
Krock |
weird. it's supposed to be flushed |
| 17:58 |
MTDiscord |
<y5nw> v-rob: not on its own, but when you have a lot of that calls the overhead adds up |
| 17:58 |
v-rob |
Hmm, I see |
| 17:59 |
DS-minetest |
As a modder I wouldn't use a 3x3matrix/quaternion/similar lua library that's implemented in C/C++. The call overhead is too big. |
| 17:59 |
v-rob |
I guess pure Lua it is then |
| 17:59 |
|
z812 joined #minetest-dev |
| 18:00 |
MTDiscord |
<y5nw> I tried to rewrite part of a mod in C. The interfacing time alone took longer than running in pure Lua IIRC. That's how bad it is (not sure about FFI though) |
| 18:01 |
v-rob |
In terms of just rotations, quaternions can do anything 3x3 matricies can do, right? |
| 18:01 |
DS-minetest |
FFI in luajit is really fast (even faster than calling a library function via the plt in C) and also pretty easy. but you'll need to be a trusted mod |
| 18:01 |
v-rob |
Or is there something 3x3 matricies are better at? |
| 18:02 |
MTDiscord |
<y5nw> If you have it as a lua table of 9 elements you might not really need to port that to C IMO |
| 18:03 |
|
z812 joined #minetest-dev |
| 18:03 |
v-rob |
I want 4x4 matricies for the full benefit of translations (for use with e.g. entities), but I'm wondering if 3x3 matricies have any extra benefits over quaternions. |
| 18:04 |
DS-minetest |
if you do a 90° rotation with quaternions, I wonder if vectors with integral numbers suddenly get tiny errors |
| 18:05 |
DS-minetest |
mods that does stuff like mesecons (neighbor rules that need to be rotated) will want to compare their rules with == |
| 18:05 |
DS-minetest |
matrices can do that |
| 18:10 |
|
z812 joined #minetest-dev |
| 18:14 |
|
z812 joined #minetest-dev |
| 18:18 |
|
z812 joined #minetest-dev |
| 18:21 |
v-rob |
Hmm, from what I can see, quaternion rotations by things like 90 will be fine if you normalize the quaternion afterwords. |
| 18:24 |
v-rob |
So I'll probably hold off on 3x3 matricies in favor of quaternions and 4x4 matricies for now. |
| 18:25 |
v-rob |
Either way, it'll be nice to not have to work with Euler angles |
| 18:27 |
DS-minetest |
If you want to do * with vectors, it will be very useful for you to have metatables on vectors, btw. #11039 |
| 18:27 |
ShadowBot |
https://github.com/minetest/minetest/issues/11039 -- Add metatables to lua vectors by Desour |
| 18:28 |
v-rob |
Does that PR handle C++ code, like push_v2f? |
| 18:29 |
v-rob |
that is, v3f |
| 18:29 |
DS-minetest |
yes |
| 18:29 |
DS-minetest |
oh, no, not push_v2f |
| 18:29 |
v-rob |
Sounds great. I'll have to review |
| 18:29 |
DS-minetest |
only 3d vectors |
| 18:29 |
v-rob |
Yes, that was a typo. I'm used to working with 2D coordinates for formspecs |
| 18:34 |
Krock |
> game tests pass |
| 18:35 |
Krock |
> unittests fail |
| 18:35 |
Krock |
fml |
| 18:36 |
DS-minetest |
how can I run only some unittests? (ie. those that don't trigger the hundreds of lines of warnings) |
| 18:37 |
Krock |
I fixed it by commenting those warnings |
| 18:37 |
DS-minetest |
in minetest with --run-unittests I mean |
| 18:38 |
Krock |
for some reason g_settings is just empty or invalid when these messages are printed |
| 18:39 |
|
tech_exorcist joined #minetest-dev |
| 18:40 |
DS-minetest |
that helped, thanks |
| 18:41 |
|
z812 joined #minetest-dev |
| 18:41 |
DS-minetest |
though it's still difficult to find the failed test. why doesn't it say which unittests failed in the summary? |
| 18:42 |
sfan5 |
ctrl+f FAIL |
| 18:42 |
DS-minetest |
hm, yes, ok |
| 18:44 |
v-rob |
Gee, vector.length is kinda inefficient. One square and one square root could be eliminated |
| 18:45 |
|
proller joined #minetest-dev |
| 18:46 |
Krock |
sfan5: #11011 updated but I have no clue how to test the Mts save/load stuff |
| 18:46 |
ShadowBot |
https://github.com/minetest/minetest/issues/11011 -- Schematic: Fix crash after node resolving by SmallJoker |
| 18:47 |
v-rob |
math.sqrt(x^2 + y^2 + z^2) is equivalent to math.hypot(x, math.hypot(y, x)) |
| 18:49 |
DS-minetest |
math.hypot is implemented in lua and does two multiplications, one division and one sqrt. I think I've seen a discussion about length's implementation a while ago |
| 18:49 |
v-rob |
The sqrt in the inner hypot gets immediately cancelled by the square in the outer hypot |
| 18:56 |
* DS-minetest |
can't find the discussion anymore, maybe it never happened. |
| 18:58 |
v-rob |
Well, it's a pretty small change anyway |
| 18:59 |
v-rob |
I also like #10324, separate constructors are nice |
| 18:59 |
ShadowBot |
https://github.com/minetest/minetest/issues/10324 -- Split vector.new into 3 constructors by Desour |
| 18:59 |
v-rob |
I'll review those vector PRs soon |
| 19:00 |
DS-minetest |
yey, thx |
| 19:34 |
|
BuckarooBanzai6 joined #minetest-dev |
| 19:35 |
|
bodqhrohro_ joined #minetest-dev |
| 19:36 |
|
olliy_ joined #minetest-dev |
| 19:43 |
|
amk joined #minetest-dev |
| 21:47 |
|
Wuzzy joined #minetest-dev |
| 21:49 |
|
proller joined #minetest-dev |
| 23:32 |
|
kilbith joined #minetest-dev |
| 23:33 |
kilbith |
man I'm about to give up with Minetest and do something else; I'm horrified about what users are reporting on the Discord server |
| 23:33 |
kilbith |
lemme show you |
| 23:33 |
kilbith |
https://media.discordapp.net/attachments/369137254641303560/819305254230556690/unknown.png |
| 23:34 |
kilbith |
https://cdn.discordapp.com/attachments/369137254641303560/819318734769618954/unknown.png |
| 23:34 |
kilbith |
https://cdn.discordapp.com/attachments/369137254641303560/819319194428112956/unknown.png |
| 23:35 |
kilbith |
glitches, nodes drawn over the player model, suddenly broken styling for field[], and `setFrameLoop` from Irrlicht plays an animation much much faster now |
| 23:37 |
|
luk3yx joined #minetest-dev |
| 23:39 |
luk3yx |
kilbith: Hopefully that will be fixed well before 5.5.0 is stable, I'm guessing the Irrlicht change happened early on to catch these bugs so they can be fixed before a release. I can file an issue on GitHub if you want |
| 23:40 |
kilbith |
my ass, neither sfan5 or anyone else is qualified in core team to fix these rendering issues in irrlicht |
| 23:41 |
sfan5 |
? |
| 23:41 |
kilbith |
forking irrlicht is a really bad move until you can find qualified people to maintain a 3D engine |
| 23:42 |
sfan5 |
you say that as if the act of forking has somehow introducted these bugs |
| 23:42 |
kilbith |
I'm just disillusioned right now tbh |
| 23:42 |
kilbith |
yes it does, I pull commits on the daily basis asshole |
| 23:43 |
sfan5 |
misunderstanding my point is no grounds for insulting me |
| 23:43 |
sfan5 |
these bugs exist in Irrlicht 1.9, they would have hit us sooner or later when we would have switched to it as it was released |
| 23:44 |
luk3yx |
So should I open an issue? If so should I include the crosshair bug in the same one or open a separate issue for that? |
| 23:44 |
sfan5 |
I didn't expect severe issues but it's just as luk3yx says, adding it earlier serves as means to test it and see if everything still works alright |
| 23:44 |
sfan5 |
luk3yx: yes |
| 23:45 |
sfan5 |
another interesting point here is that we've always been using irr1.9 on Android (an older revision though), so that means those bugs may or may not always have existed on Android (did nobody notice?) |
| 23:46 |
sfan5 |
anyway please provide a mod to test, I assume I can just install i3 |
| 23:46 |
sfan5 |
? |
| 23:46 |
luk3yx |
I was using i3, yes |
| 23:47 |
luk3yx |
The latest one (according to the content browser at least) from https://content.minetest.net/packages/jp/i3/ |
| 23:48 |
luk3yx |
And (I complained about this on Discord earlier) the crosshair seems to be misaligned |
| 23:48 |
sfan5 |
huh seems like model[] renders the model with the wrong size and angle for a single frame (or is that relating to something i3 does?) |
| 23:49 |
kilbith |
what is the "wrong size and angle"? |
| 23:50 |
MTDiscord |
<Jonathon> https://cdn.discordapp.com/attachments/747163566800633906/819356564120535051/unknown.png |
| 23:50 |
sfan5 |
https://0x0.st/-ZMt.jpg looks like this when switching tabs |
| 23:50 |
luk3yx |
That's the good crosshair image @Jonathon |
| 23:50 |
MTDiscord |
<Jonathon> https://cdn.discordapp.com/attachments/747163566800633906/819356666331267072/unknown.png |
| 23:50 |
MTDiscord |
<Jonathon> ^bad |
| 23:50 |
MTDiscord |
<Jonathon> vs good |
| 23:51 |
MTDiscord |
<Jonathon> (above) |
| 23:51 |
luk3yx |
Weird, I don't have that issue |
| 23:51 |
luk3yx |
And the model issue I was having doesn't seem to occur in first person |
| 23:51 |
luk3yx |
Or when I'm in the "items" tab with the boat craft guide entry open (this has a model at the top-right) but if I switch back to the main tab the boat model is broken |
| 23:52 |
kilbith |
sfan5, before irrlicht 1.9 it was showing like that: https://user-images.githubusercontent.com/7883281/109045805-4f450600-76d4-11eb-90f7-b99ab939246a.png |
| 23:52 |
sfan5 |
@Jonathon looks like it's just rotated, but the better question here is thy is that not symmetric? |
| 23:52 |
luk3yx |
That's the object crosshair |
| 23:52 |
sfan5 |
s/thy/the crosshair/ |
| 23:52 |
luk3yx |
The normal crosshair has a similar issue but it's easier to see in that one |
| 23:52 |
sfan5 |
oh |
| 23:53 |
sfan5 |
kilbith: sure that still works https://0x0.st/-ZMw.jpg |
| 23:53 |
sfan5 |
it's just temporarily wrong |
| 23:55 |
kilbith |
and now we might understand that we better have waited a *stable* version of irrlicht? |
| 23:56 |
kilbith |
because the whole picture is a disaster |
| 23:56 |
sfan5 |
I'm sure the users who cannot input characters in their native language will be delighted to know their bug is not going to be fixed for another 5 years |
| 23:57 |
kilbith |
you decided to fork from 1.9 not 1.8.4 |
| 23:57 |
sfan5 |
that's a valid point |
| 23:58 |
luk3yx |
sfan5: Is it broken for you in third person view? |
| 23:58 |
sfan5 |
but the reason there is that 1.8 is a dead end, we eventually need to switch anyway and that 1.8 does not have Android support |
| 23:59 |
sfan5 |
luk3yx: first a different question, by misaligned you mean that the top line of the crosshair is 1px longer than the bottom one? |
