| Time |
Nick |
Message |
| 00:15 |
|
YuGiOhJCJ joined #minetest-dev |
| 00:28 |
|
Baytuch joined #minetest-dev |
| 00:49 |
|
Baytuch joined #minetest-dev |
| 01:00 |
|
noodles[m] joined #minetest-dev |
| 01:04 |
|
Baytuch joined #minetest-dev |
| 01:10 |
kilbith |
if not, then the "release early / release often" model cannot scale on MT because it effectively makes us lose weeks of productivity during the freeze |
| 01:13 |
|
Alias joined #minetest-dev |
| 01:23 |
|
Baytuch joined #minetest-dev |
| 01:30 |
|
Baytuch joined #minetest-dev |
| 01:50 |
|
YuGiOhJCJ joined #minetest-dev |
| 02:33 |
|
fluxionary joined #minetest-dev |
| 04:00 |
|
MTDiscord joined #minetest-dev |
| 05:54 |
|
calcul0n joined #minetest-dev |
| 05:58 |
|
calcul0n joined #minetest-dev |
| 07:16 |
|
hlqkj joined #minetest-dev |
| 07:52 |
|
Baytuch joined #minetest-dev |
| 08:04 |
|
Baytuch joined #minetest-dev |
| 08:44 |
MTDiscord |
<FatalError> why is anti-aliasing off by default? |
| 08:44 |
MTDiscord |
<FatalError> it makes the game look like shit 99.9% of the time in my experience |
| 08:44 |
MTDiscord |
<FatalError> every laptop ive had anyway |
| 08:45 |
MTDiscord |
<FatalError> better question, why the fuck doesnt it work the way it should either |
| 08:45 |
MTDiscord |
<FatalError> you still see the sharp pixelated edges |
| 08:48 |
MTDiscord |
<ROllerozxa> "you still see the sharp pixelated edges" 16x textures tend to do that lol |
| 08:48 |
|
Baytuch joined #minetest-dev |
| 08:53 |
MTDiscord |
<FatalError> no I mean... I can see the pixels on my screen |
| 09:00 |
|
Baytuch joined #minetest-dev |
| 09:07 |
|
Baytuch joined #minetest-dev |
| 09:26 |
|
appguru joined #minetest-dev |
| 09:28 |
|
Baytuch joined #minetest-dev |
| 09:32 |
|
erle joined #minetest-dev |
| 09:38 |
|
Baytuch joined #minetest-dev |
| 09:41 |
MTDiscord |
<luatic> bruh |
| 09:41 |
MTDiscord |
<ROllerozxa> antialiasing can't exactly magically increase the pixel density of your monitor |
| 09:41 |
MTDiscord |
<luatic> you need supersampling to get rid of those edges |
| 09:42 |
MTDiscord |
<luatic> you could tell GL to render the triangles antialiased |
| 09:42 |
MTDiscord |
<luatic> but that comes with blending issues around the edges IIRC |
| 09:42 |
MTDiscord |
<ROllerozxa> mmye |
| 09:42 |
MTDiscord |
<luatic> anyways @FatalError, once again seasoned, the antialiasing you're using is a texture interpolation only thing |
| 09:42 |
MTDiscord |
<luatic> and the antialiasing you'd have to use for smooth edges - MSAA / supersampling - is buggy |
| 09:42 |
MTDiscord |
<ROllerozxa> I wonder how irrlicht does the antialiasing? the minetest antialiasing is basically just telling irrlicht to do x amount of AA |
| 09:42 |
MTDiscord |
<luatic> ~cdb gop |
| 09:43 |
MTDiscord |
<luatic> ~cdb go |
| 09:43 |
|
HuguesRoss joined #minetest-dev |
| 09:43 |
MTDiscord |
<ROllerozxa> this is minetest-dev, I don't think that works here |
| 09:43 |
MTDiscord |
<luatic> oof |
| 09:43 |
MTDiscord |
<luatic> anyways, we're spamming -dev again |
| 09:43 |
MTDiscord |
<luatic> sorry |
| 09:44 |
MTDiscord |
<luatic> Anyways, here's what I wanted to quote from the Go Readme: > Smooth GUI image scaling should be enabled (gui_scaling_filter = true) > Enable trilinear texture filtering (trilinear_filter = true), mipmapping (mip_map = true) & anisotropic filtering (anisotropic_filter = true) for smoother board appearance > Consider enabling multi-sample anti-aliasing (msaa = 2) for smooth board edges if it doesn't trigger a nasty rendering bug on your |
| 09:44 |
MTDiscord |
setup |
| 09:44 |
MTDiscord |
<luatic> Nasty rendering bug is https://github.com/minetest/minetest/issues/9072 |
| 09:45 |
sfan5 |
the setting is called `fsaa` |
| 09:45 |
MTDiscord |
<luatic> Indeed it is, thanks, will correct |
| 09:46 |
MTDiscord |
<luatic> I've had it disabled anyways since I have the nasty rendering bug ;) |
| 09:46 |
sfan5 |
"I wonder how irrlicht does the antialiasing" it just tells the driver to do it as described in GL_ARB_multisample |
| 09:55 |
|
Baytuch joined #minetest-dev |
| 10:25 |
|
appguru joined #minetest-dev |
| 10:56 |
schwarzwald[m] |
Who insured that `util/string.h` won't be mistaken for the `<string.h>` STL header? |
| 11:02 |
schwarzwald[m] |
s/insured/ensured/ |
| 11:03 |
|
olliy joined #minetest-dev |
| 11:13 |
|
Baytuch joined #minetest-dev |
| 11:23 |
|
YuGiOhJCJ joined #minetest-dev |
| 11:38 |
|
Noisytoot joined #minetest-dev |
| 11:40 |
sfan5 |
that's probably always included via <cstring> |
| 11:41 |
sfan5 |
and/or perhaps the util folder is never directly added to the include path |
| 11:41 |
schwarzwald[m] |
I think the latter is correct. Seems risky, though. |
| 11:43 |
sfan5 |
the only #include <string.h> outside of lib/ is in src/util/sha256.c |
| 11:43 |
schwarzwald[m] |
There are also some <string.h> includes in Irrlicht. |
| 11:44 |
schwarzwald[m] |
And all <cstring> includes technically include it indirectly as well. |
| 11:44 |
schwarzwald[m] |
Maybe we could rename the file to `string_ext.h` or something just to be safe. |
| 11:47 |
sfan5 |
<cstring> is ensured to always include the system header |
| 11:48 |
sfan5 |
or at least libstdc++ does, no idea if the standard mandates this |
| 12:18 |
|
appguru joined #minetest-dev |
| 12:32 |
rubenwardy |
<> will include SYSTEM includes first |
| 12:34 |
sfan5 |
IIRC it wasn't that simple, search the issue tracker for "event.h" |
| 12:55 |
|
behalebabo joined #minetest-dev |
| 13:04 |
erle |
schwarzwald[m] are you saying this a problem? https://mister-muffin.de/p/rfx6.png |
| 13:06 |
erle |
like, should there be no relation between src/util/sha256.o and /usr/include/string.h? |
| 13:07 |
erle |
i do believe that having a single C file in the source code is a bit weird |
| 13:16 |
schwarzwald[m] |
I do not fully understand why, but <cstring> will include the wrong header if the util directory is added directly to the include paths. I haven't been able to produce a minimum reproducible example yet. |
| 13:19 |
rubenwardy |
you shouldn't add the util directly to the include paths |
| 13:19 |
schwarzwald[m] |
Why not? |
| 13:29 |
schwarzwald[m] |
I will comply anyway, but I'm curious what the reasons are. |
| 13:32 |
rubenwardy |
same reason you don't add other directories to the include path |
| 13:34 |
rubenwardy |
it blurs the directories together |
| 13:34 |
schwarzwald[m] |
Ah, so we keep the include paths prefixed in the src dir so it's clear where the includes are coming from? |
| 13:55 |
|
proller joined #minetest-dev |
| 14:02 |
|
Baytuch joined #minetest-dev |
| 14:23 |
|
m42uko joined #minetest-dev |
| 15:46 |
|
Baytuch joined #minetest-dev |
| 15:56 |
|
proller joined #minetest-dev |
| 16:33 |
|
Baytuch joined #minetest-dev |
| 16:42 |
|
Baytuch joined #minetest-dev |
| 16:44 |
|
Baytuch joined #minetest-dev |
| 16:46 |
|
vampirefrog joined #minetest-dev |
| 16:50 |
sfan5 |
yes |
| 17:09 |
|
vampirefrog joined #minetest-dev |
| 17:47 |
|
Yad joined #minetest-dev |
| 17:47 |
|
Baytuch joined #minetest-dev |
| 17:56 |
|
Baytuch joined #minetest-dev |
| 18:25 |
|
Baytuch joined #minetest-dev |
| 19:04 |
fluxionary |
does anyone know if there's an existing issue about the fact that mouse-click events are triggered twice, both when pressing and releasing the button? |
| 19:05 |
sfan5 |
doubt it |
| 19:05 |
MTDiscord |
<LandarVargan> Mac? |
| 19:06 |
fluxionary |
alright, i'll try to make one and document what i understand as best as i can |
| 19:07 |
fluxionary |
LandarVargan: is that a question to me? no, linux, though i think the issue is probably cross-platform. |
| 19:09 |
erle |
fluxionary include repro instructions that are as exact as possible, i'll try on linux |
| 19:10 |
fluxionary |
erle: i might have found some related issues |
| 19:10 |
fluxionary |
the most common way this manifests is when a player tries to drag something from one inventory to another, but the wrong item ends up in the other inventory (and the intended item ends up replacing the wrong item in the first inventory) |
| 19:11 |
erle |
i have indeed encountered that bug! |
| 19:11 |
fluxionary |
you can repro just by moving the mouse while click-picking up something. |
| 19:11 |
erle |
but i do not see the connection |
| 19:11 |
erle |
and never filed it (mea maxima culpa) |
| 19:12 |
fluxionary |
https://github.com/minetest/minetest/issues/4477 seems to be describing the same thing, at least in part |
| 19:13 |
sfan5 |
that sounds like a focus mistake, not what you're describing |
| 19:14 |
fluxionary |
yeah, i think i'm gonna make a new issue and include repro instructions and a video |
| 19:14 |
|
YuGiOhJCJ joined #minetest-dev |
| 19:15 |
erle |
fluxionary FYI: the inventory bug happens more often when dragging under lag conditions. since inventory drawing is for some reason extremely heavy, it is more likely to occur the more things you see. you can try that in devtest i think. |
| 19:16 |
erle |
client lag conditions i mean (rendering lag), not network lag or server lag |
| 19:16 |
fluxionary |
seems reasonable. i bet i can replicate it by manually setting a lower max frame rate tho |
| 19:18 |
fluxionary |
actually i can replicate it very easily w/out lag |
| 19:23 |
|
YuGiOhJCJ joined #minetest-dev |
| 19:40 |
fluxionary |
https://github.com/minetest/minetest/issues/12596 |
| 20:06 |
|
appguru joined #minetest-dev |
| 20:27 |
|
Baytuch joined #minetest-dev |
| 20:55 |
|
Baytuch_2 joined #minetest-dev |
| 21:20 |
|
Baytuch joined #minetest-dev |
| 21:22 |
|
Yad joined #minetest-dev |
| 21:57 |
|
appguru1 joined #minetest-dev |
| 22:05 |
|
Baytuch joined #minetest-dev |
| 22:34 |
|
panwolfram joined #minetest-dev |
| 22:58 |
|
YuGiOhJCJ joined #minetest-dev |
| 23:37 |
|
erle joined #minetest-dev |
| 23:47 |
|
Baytuch joined #minetest-dev |
