| Time |
Nick |
Message |
| 00:00 |
MTDiscord |
<Jonathon> exactly |
| 00:00 |
MTDiscord |
<Benrob0329> Take the advise of those who have been down this road before and let it die? |
| 00:00 |
MTDiscord |
<Benrob0329> Put your efforts elsewhere |
| 00:02 |
MTDiscord |
<Benrob0329> MTG, in name, legacy, contents, and role hurts the Minetest community as a whole. Something new doesn't. |
| 00:13 |
|
jordan4ibanez joined #minetest-dev |
| 00:45 |
|
AliasAlreadyTake joined #minetest-dev |
| 00:54 |
|
v-rob joined #minetest-dev |
| 01:49 |
|
v-rob joined #minetest-dev |
| 03:28 |
|
queria^clone joined #minetest-dev |
| 03:34 |
|
queria^clone joined #minetest-dev |
| 04:20 |
|
MTDiscord joined #minetest-dev |
| 05:00 |
|
MTDiscord joined #minetest-dev |
| 06:15 |
|
v-rob joined #minetest-dev |
| 06:32 |
MTDiscord |
<Sublayer plank> how's the current plan for dynamic shadows looking like? is it still going to be compiled out right before release? |
| 07:17 |
celeron55 |
i see no further response from the game team to appguru being added so i'll do it |
| 07:24 |
|
olliy joined #minetest-dev |
| 07:38 |
|
tekakutli joined #minetest-dev |
| 08:21 |
|
tekakutli joined #minetest-dev |
| 08:44 |
sfan5 |
"compiled out" looks like will be the case yes |
| 08:54 |
MTDiscord |
<ElCeejo> > compiling out a feature you just added |
| 08:54 |
MTDiscord |
<ElCeejo> https://www.youtube.com/watch?v=UzgwYhDyLH0 |
| 09:03 |
|
erlehmann joined #minetest-dev |
| 09:18 |
|
v-rob joined #minetest-dev |
| 09:26 |
|
calcul0n joined #minetest-dev |
| 09:28 |
|
erlehmann joined #minetest-dev |
| 09:52 |
|
Fixer joined #minetest-dev |
| 10:00 |
MTDiscord |
<Sublayer plank> I feel ashamed to be sharing the discord bridge with you |
| 10:13 |
sfan5 |
you can always join IRC directly ;) |
| 10:14 |
|
Topic for #minetest-dev is now Minetest core development and maintenance. Chit-chat goes to #minetest. https://dev.minetest.net/ https://github.com/minetest | FEATURE FREEZE IN EFFECT (as of 2022-01-15) |
| 10:30 |
|
erlehmann joined #minetest-dev |
| 11:00 |
|
erlehmann joined #minetest-dev |
| 11:06 |
|
appguru joined #minetest-dev |
| 11:12 |
|
erlehmann joined #minetest-dev |
| 11:22 |
|
erlehmann joined #minetest-dev |
| 11:30 |
|
appguru joined #minetest-dev |
| 11:56 |
|
appguru1 joined #minetest-dev |
| 12:37 |
MTDiscord |
<josiah_wi> SpatialAreaStore never defines the id_type it passes to the RTree constructor. |
| 12:38 |
MTDiscord |
<josiah_wi> And I suspect this is the cause of a NotSupportedException I got while writing unit tests. |
| 13:02 |
MTDiscord |
<josiah_wi> That may not be it. |
| 13:24 |
|
proller joined #minetest-dev |
| 13:41 |
|
erlehmann joined #minetest-dev |
| 13:51 |
MTDiscord |
<josiah_wi> That's not it. It has something to do with brace ininialization, initializer lists, and possibly default constructors and inheritance. |
| 13:51 |
MTDiscord |
<josiah_wi> In other words, the usual C++ terrors. |
| 13:53 |
MTDiscord |
<josiah_wi> If anybody has an idea why MySubClass var {}; would exhibit different behavior than MySubClass var; please do explain. |
| 13:59 |
erlehmann |
josiah_wi is this a direct initialization without calling constructor thing? |
| 14:00 |
erlehmann |
oh, ignore my musing, i thought of structs |
| 14:00 |
MTDiscord |
<josiah_wi> Sorry, misread this whole time. |
| 14:00 |
MTDiscord |
<josiah_wi> It's a different test that's failing. |
| 15:07 |
|
tekakutli joined #minetest-dev |
| 15:12 |
|
proller joined #minetest-dev |
| 16:08 |
MTDiscord |
<josiah_wi> Do the core devs have a strong preference about whether private members should be listed before or after public ones? |
| 17:26 |
|
Menchers joined #minetest-dev |
| 17:42 |
|
proller joined #minetest-dev |
| 18:09 |
rubenwardy |
we haven't released for 11 months, imo waiting an extra week for a dynamic shadows API to finalise isn't that significant |
| 18:09 |
rubenwardy |
how stable are shadows? |
| 18:15 |
erlehmann |
i think the more important question is: have features unrelated to shadows that were broken all been fixed? |
| 18:16 |
erlehmann |
i recall x2048 having done some work on anaglyph mode recently? |
| 18:16 |
erlehmann |
shipping something where existing features break due to a new feature is IMO way worse than shipping a partially broken new feature |
| 18:17 |
MTDiscord |
<Benrob0329> My question is: why disable shadows instead of marking them as experimental and subject to change? |
| 18:17 |
MTDiscord |
<Benrob0329> "These aren't perfect, but you can mess around with them since they're here while we finish them up" |
| 18:18 |
MTDiscord |
<Benrob0329> Sure, some games look bad with them turned on, but tonemapping got merged despite being a completely useless feature now didn't it? |
| 18:19 |
erlehmann |
past mistakes do not justify future mistakes |
| 18:19 |
MTDiscord |
<Jonathon> ^ for once i can agree |
| 18:20 |
MTDiscord |
<Benrob0329> Sure, but don't ignore my other point please. |
| 18:21 |
MTDiscord |
<Jonathon> im fine with shadows in 5.5 if something like https://github.com/minetest/minetest/pull/11944 is merged so that games/mods have control instead of the usual minetest pulling the rug out from under game/mods devs with client things they cant work around |
| 18:21 |
rubenwardy |
#11944 is the ideal implementation |
| 18:21 |
ShadowBot |
https://github.com/minetest/minetest/issues/11944 -- Proposal: API to control shadow intensity from the game/mod by x2048 |
| 18:21 |
rubenwardy |
well, minus the inefficiency if the client enables servers but the server disables them |
| 18:21 |
rubenwardy |
(as they won't be compiled out) |
| 18:22 |
MTDiscord |
<luatic> enables shadows you mean? |
| 18:22 |
rubenwardy |
yeah |
| 18:22 |
rubenwardy |
and compiled out in GLSL |
| 18:22 |
MTDiscord |
<Warr1024> Considering I had accidentally left shadows on and suffered mystery performance loss, it does seem like the current implementation is rather error-prone to leave it entirely in the hands of users. |
| 18:22 |
rubenwardy |
there's not much you can do to fix that without recompiling shaders at run time |
| 18:22 |
MTDiscord |
<luatic> I'm pretty sure the client could compile it out |
| 18:22 |
rubenwardy |
it can't |
| 18:22 |
MTDiscord |
<Jonathon> maybe 11944 should be added to 5.5 roadmap then? |
| 18:22 |
MTDiscord |
<luatic> Recompiling at run time is fine though |
| 18:23 |
rubenwardy |
that's not what the PR does |
| 18:23 |
MTDiscord |
<luatic> My shader media PR did that when it received dynamic media |
| 18:23 |
MTDiscord |
<luatic> It's very much possible |
| 18:23 |
MTDiscord |
<luatic> The PR should do that then |
| 18:23 |
MTDiscord |
<Warr1024> If all it's doing is hiding the effects of shadows without disabling the performance drain, then that's exactly zero help to me, as I've already gotten that much working just using the existing APIs. |
| 18:24 |
MTDiscord |
<Jonathon> https://github.com/minetest/minetest/pull/11699 is already in 5.5, seems reasonable to allow a competing choice as with the fonts issue |
| 18:24 |
MTDiscord |
<Jonathon> warr1024: everyone is not nodecore where they can disable time |
| 18:24 |
MTDiscord |
<josiah_wi> Is 2022 est31 the right thing to put in the copyright notice? |
| 18:25 |
MTDiscord |
<luatic> dew those copyright notices, that's what the git history is for IMO |
| 18:25 |
MTDiscord |
<josiah_wi> This is for new files. |
| 18:25 |
MTDiscord |
<Warr1024> I have at least one counterexample to your "everyone is not NodeCore" assertion :-D |
| 18:25 |
MTDiscord |
<luatic> I suppose you should just add your name there, and keep the date if it's a derivative |
| 18:25 |
MTDiscord |
<luatic> So 1942 est32, 2022 josiah_wi |
| 18:25 |
MTDiscord |
<josiah_wi> Names aren't listed anyway. |
| 18:26 |
MTDiscord |
<josiah_wi> This is engine code. |
| 18:26 |
MTDiscord |
<Jonathon> ok and? just because a janky hack works for you doesnt mean it works for everyone else |
| 18:27 |
MTDiscord |
<luatic> you didn't get the joke, did you? |
| 18:27 |
MTDiscord |
<Warr1024> You're right. We should use a different hanky hack instead, for certain. |
| 18:27 |
MTDiscord |
<luatic> logically speaking, your assertion was "for everyone it holds that they are not NodeCore", instead of "not everyone is NodeCore |
| 18:27 |
MTDiscord |
<josiah_wi> Oh, some files have a name. |
| 18:28 |
MTDiscord |
<Benrob0329> Games need APIs for a lot of graphical settings, not just shadows. I feel like that should be one player:set_graphics function rather than one specific to shadows. Pushing a poor API choice because everyone is going to complain like it's CSMs all over again is a bad idea IMO |
| 18:29 |
MTDiscord |
<Warr1024> If we can't bypass the performance cost of computing shadows rather than just doing all the work and zeroing out the visual end result, we're still putting a footgun in the hands of users, and if we're considering doing extra work to do the zeroing thing, we should at least consider disabling the footgun part too. |
| 18:30 |
MTDiscord |
<Jonathon> seems this is something that needs to be worked out, as it was in set sky, now in set_lighting(), |
| 18:30 |
MTDiscord |
<Benrob0329> If a player enabled shadows, and it looks bad, so what? They can disable it. Yes I'd like control of the graphical settings, but that shouldn't be for just one thing because shadows is the only one anyone has felt the need to actually listen to this plea on for once. |
| 18:31 |
MTDiscord |
<Warr1024> If we can, say, cut the performance impact of shadows by like 80% by stubbing out shit in a special case where intensity == 0.0 that might be good enough for a duct tape solution at least... |
| 18:32 |
MTDiscord |
<Jonathon> this is a question of how long do you want to delay 5.5 further ? |
| 18:32 |
MTDiscord |
<Benrob0329> Hell, I'd take a prototype graphics override function that only controls one or two things but can be improved after release |
| 18:32 |
MTDiscord |
<Warr1024> As it is I currently have to choose between making the game robust against incorrect settings but turning shadows into a silent fail, or making it easy to see what your settings are but having no way to know that shadows are meant to be turned off. |
| 18:33 |
MTDiscord |
<Jonathon> this is probably the fastest way to release 5.5 |
| 18:33 |
MTDiscord |
<Benrob0329> If something looks bad because players enabled something clearly marked as experimental, that is entirely their fault. |
| 18:33 |
MTDiscord |
<Warr1024> player:set_graphics() seems fine to me, even if shadows are the only thing it controls. set_sky and friends aren't necessarily all super rich APIs but they're at least extensible. |
| 18:34 |
MTDiscord |
<Warr1024> If you can get shadows hidden off the quick settings screen and mark it experimental that'd probably work alright too. |
| 18:34 |
MTDiscord |
<Benrob0329> Hidden in "all settings" for now seems fine |
| 18:35 |
MTDiscord |
<Benrob0329> I don't love it but I get it |
| 18:35 |
MTDiscord |
<Jonathon> except it will probably come back to bite like you cant tell 5.2 and 5.3 apart |
| 18:36 |
rubenwardy |
hecks is adamantly against hiding it in all settings, he wants it compiled out |
| 18:36 |
MTDiscord |
<josiah_wi> Why? |
| 18:36 |
MTDiscord |
<Jonathon> or controled ^ |
| 18:36 |
MTDiscord |
<Benrob0329> wsor: If we get protocol bumps for 5.5 -> 5.6, I think we're fine |
| 18:36 |
rubenwardy |
https://github.com/minetest/minetest/issues/11365 |
| 18:36 |
MTDiscord |
<Jonathon> benrob: i suppose, but then that means kicking clients instead of something that could have been turned off |
| 18:37 |
MTDiscord |
<Jonathon> i would be nice to support all the way back to 5.4 from 5.6 as stuff like dynamic media with the new apis works with the older client |
| 18:37 |
MTDiscord |
<Benrob0329> You'd kick someone for having "wrong" graphics settings? |
| 18:38 |
MTDiscord |
<Jonathon> people already do this for formsepcs |
| 18:38 |
MTDiscord |
<Jonathon> *formspecs |
| 18:39 |
MTDiscord |
<Benrob0329> I get technical reasons, like not wanting to convert coordinate types or needing a new element or dynamic media, but for graphics settings? |
| 18:39 |
MTDiscord |
<Benrob0329> Sounds like iron-gripping your users to me |
| 18:39 |
MTDiscord |
<Jonathon> when you get 20 complaints your game looks like garbage because im dumb and turned this on...... |
| 18:40 |
MTDiscord |
<Jonathon> or you want 5.5 to not have shadows and 5.6 to because of some improvement |
| 18:40 |
MTDiscord |
<Jonathon> easier to just support the newest version of mt that tell users to not enable something |
| 18:40 |
MTDiscord |
<Jonathon> that you have no control over |
| 18:41 |
MTDiscord |
<Benrob0329> I already have no control over client graphical settings, frankly texture filtering is a much worse problem than shadows but I'm not saying that they need to be compiled out because they're useless for most games. |
| 18:41 |
MTDiscord |
<Benrob0329> Even though they are |
| 18:42 |
MTDiscord |
<Jonathon> im just advocating for a full measure either way than a half measure |
| 18:42 |
MTDiscord |
<Warr1024> Heh ironically if I were not allowed to play a game with texture filtering on, that would probably push me toward different games. |
| 18:43 |
MTDiscord |
<Benrob0329> Shadows perform bad and look out of place at worse. I'd like a set_graphics function, but I've wanted one for years and it's likely to be controversial at best. |
| 18:43 |
MTDiscord |
<Warr1024> I'm advocating for half measures over full measures because our obsession with full measures or bust is why we keep ending up with no measures. |
| 18:44 |
|
calcul0n_ joined #minetest-dev |
| 18:44 |
MTDiscord |
<Jonathon> heh, sorta fair point |
| 18:44 |
MTDiscord |
<Warr1024> If we're talking 5.6, then set_graphics. If we're talking 5.5, bury it and ship it already... |
| 18:44 |
MTDiscord |
<Benrob0329> A half measure is fine, just not one that will bite us in the ass immediately |
| 18:45 |
MTDiscord |
<Benrob0329> If it bites us in the ass 5 minutes from now that's one thing, but I'd like to have those 5 minutes of non ass biting |
| 18:45 |
MTDiscord |
<Warr1024> Buried settings is the politically easy half measure. Nuking it and reading in 5.6 is easier to handle technically, but since it's already been hyped, expect backlash. |
| 18:45 |
MTDiscord |
<Jonathon> could expose the compile out as a option when compiling with stuff like different db backends |
| 18:46 |
MTDiscord |
<Warr1024> re-adding* |
| 18:46 |
MTDiscord |
<Jonathon> this way its only available to people who compile there own clients and then enable it in settings |
| 18:47 |
MTDiscord |
<Warr1024> Oh, non-default compile option might not be a terrible middle ground ... though the cost of extra compile process complexity, I wonder about... |
| 18:47 |
MTDiscord |
<Warr1024> Adding flags/options anywhere always sucks at least a little from a maintenance perspective. |
| 18:48 |
MTDiscord |
<Jonathon> well yeah, but right after 5.5 releases you can just revert it in favor of the api |
| 18:48 |
MTDiscord |
<Jonathon> which is what the compile out option is |
| 18:48 |
MTDiscord |
<Jonathon> *hard code out |
| 18:48 |
MTDiscord |
<Benrob0329> Anyways, I've given my 2 cents. I don't care that much either way, I've tweaked IKEA to handle them nowadays and don't use them except to test since they need some major optimisations as of right now :P |
| 18:50 |
MTDiscord |
<Warr1024> If there's something we can do to appease the portions of the community already hyped about this, without handing everyone an unlocked footgun, that'd be ideal. Either way I'd hate to delay 5.5 another X months again over one feature, so as far as I'm concerned whatever we can do to make something work... :-| |
| 18:50 |
MTDiscord |
<Jonathon> turn minetest into a rolling release platform with a updater lol |
| 18:51 |
MTDiscord |
<Warr1024> I do wonder if "middle ground" games that both need to disable shadows (don't use default skybox) but also can't use the existing duct tape (don't override sky completely) are really a thing...? |
| 18:51 |
MTDiscord |
<Jonathon> ^terrible sarcastic idea |
| 18:53 |
erlehmann |
Warr1024 what do you mean middle ground games? |
| 18:53 |
erlehmann |
Warr1024 mineclonia/mineclone2/mineclone5 all have solar panels and mob spawning based on light intensity. i.e. where it is dark, mobs spawn. |
| 18:54 |
erlehmann |
and also the solar panels do not produce light |
| 18:54 |
erlehmann |
so if someone where to enable shadows and they shade an area, they could erroneously conclude it is unsafe |
| 18:54 |
MTDiscord |
<Warr1024> I mean a game that wants to disable shadow mapping because it doesn't make sense for its skybox, but for which it can't override time of day to hack out shadows. |
| 18:55 |
erlehmann |
well we can't hack out the skybox in mineclonia to get no shadows because we have day/night mechanics |
| 18:55 |
MTDiscord |
<Warr1024> The actual shadow intensity is low enough that it's unlikely to mislead players gameplay-wise unless they have an inhuman sense of absolute light intensity. |
| 18:56 |
erlehmann |
uh, there are 15 light levels and basically there is a specific shade (7 or 8) that means mobs spawn |
| 18:56 |
erlehmann |
humans are very good at contrasts |
| 18:56 |
erlehmann |
i am not, but most people are |
| 18:56 |
MTDiscord |
<Warr1024> Mineclonia would be fine with shadows enabled. It's really only an issue for games that have skyboxes where there is no directional source. |
| 18:56 |
erlehmann |
alter? inside the box? |
| 18:56 |
MTDiscord |
<Warr1024> Humans are good at contrasts and terrible at absolutes, hence why shadows aren't really a gameplay issue. |
| 18:57 |
MTDiscord |
<Warr1024> Alter and ITB bot use fully custom skyboxes so there's no reason they can't use the TOD hack. |
| 18:57 |
erlehmann |
well, i am looking forward to getting bug reports about areas being too dark if shadows are a) compiled in and b) enabled by default |
| 18:57 |
MTDiscord |
<Warr1024> I'm looking for a hybrid case that breaks the 2 molds for which working cases have been identified. |
| 18:57 |
erlehmann |
i don't care if they are not enabled by default because then i need to do exactly nothing for it to stay the same |
| 18:58 |
MTDiscord |
<Benrob0329> They aren't, and should never be enabled by default |
| 18:58 |
erlehmann |
let me check |
| 18:58 |
MTDiscord |
<Warr1024> Don't expect reports of areas too dark. Expect reports of low fps. That's one reason why I don't see them ever enabled by default. |
| 18:58 |
erlehmann |
well i develop on a thinkpad t60 and cora recently got an even worse computer lol |
| 18:58 |
MTDiscord |
<Warr1024> They'll be enabled by default probably around the same time trilinear and MSAA are. |
| 18:58 |
erlehmann |
so we are aware of performance issues ^^ |
| 19:00 |
|
appguru joined #minetest-dev |
| 19:02 |
MTDiscord |
<Warr1024> The biggest obstacle I can see to possibly using the TOD hack is if you support multiple skyboxes for different players at the same time, some of whom would have directional lighting and some who would not. If you can just set TOD to 5:00AM for all players all the time and control sky light intensity via day night ratio and use a custom skybox, then you fall into the scope of where the hack would probably work. |
| 19:02 |
MTDiscord |
<Warr1024> Nobody likes an ugly workaround but I'd definitely prioritize issues with no workaround over ones with an ugly workaround. |
| 19:03 |
MTDiscord |
<Benrob0329> I'd rather not encourage ugly workarounds when it's trivial to just mark something as experimental |
| 19:04 |
|
v-rob joined #minetest-dev |
| 19:05 |
MTDiscord |
<Warr1024> I mean yeah, other than the fact that you're implying that marking something as experimental is NOT an ugly workaround in itself, that seems fine. |
| 19:06 |
erlehmann |
“support multiple skyboxes for different players at the same time, some of whom would have directional lighting and some who would not” – mineclonia does that, but we are in luck. the end dimension is underground. i HOPE that means it never has shadows. |
| 19:06 |
erlehmann |
like there is 21 kilometers of end sky above it i think |
| 19:07 |
erlehmann |
can someone tell me if shadows work the way i think they work, even if the terrain above has not been generated? |
| 19:07 |
MTDiscord |
<Warr1024> Haha, I ... honestly have no idea what shadows do with caves and such. I think it's based on whether there's visible terrain in a certain direction. |
| 19:07 |
erlehmann |
uh oh |
| 19:07 |
erlehmann |
well then the mcl* mods may be your case |
| 19:08 |
MTDiscord |
<Warr1024> I guess you'd have to just test it to see. |
| 19:08 |
erlehmann |
just for illustrative purposes: the end sky is literally TV static and it is a dimension where you have no day or night |
| 19:08 |
MTDiscord |
<Warr1024> If it doesn't work with dimensions then yeah, that'd probably be an issue that we can't be the first ones to think of. |
| 19:09 |
erlehmann |
oh also the nether sky is just red. no day or night too. |
| 19:09 |
erlehmann |
it is a hell dimension |
| 19:09 |
erlehmann |
but usually you do not see the sky because there is caves all around |
| 19:09 |
erlehmann |
but i will test the end thing |
| 19:09 |
MTDiscord |
<Benrob0329> Yes, we need that set_graphics function |
| 19:10 |
MTDiscord |
<Benrob0329> We also need a allow_filtering in tiles def |
| 19:10 |
erlehmann |
what's the thing with filtering? |
| 19:10 |
MTDiscord |
<Warr1024> That sounds like a good enough case then to advocate for burying shadows and discouraging users from digging them out until 5.6 at least... |
| 19:10 |
MTDiscord |
<Benrob0329> Filtering makes pixel art..not pixel art |
| 19:10 |
erlehmann |
oh yeah lol |
| 19:10 |
erlehmann |
thinks i hate it |
| 19:10 |
MTDiscord |
<Benrob0329> Unless you really crank up the minimum texture size |
| 19:10 |
erlehmann |
thanks |
| 19:10 |
MTDiscord |
<Warr1024> Filtering is another footgun. It's possible but non-trivial to filter properly. |
| 19:11 |
MTDiscord |
<Benrob0329> It's needed for higher-res textures though |
| 19:11 |
MTDiscord |
<Benrob0329> "needed" |
| 19:11 |
MTDiscord |
<Warr1024> Users need to know some arcane settings, or modders need to bake in features into textures that may not be universally desirable, to ensure filtering doesn't make stuff look ass. |
| 19:11 |
MTDiscord |
<Benrob0329> So you have to enable it for some games (like moontest) and disable it for most others |
| 19:12 |
MTDiscord |
<Benrob0329> Being able to specify when a texture should or shouldn't be filtered would be nice |
| 19:12 |
MTDiscord |
<Benrob0329> Because not all textures are alike |
| 19:12 |
MTDiscord |
<Warr1024> Or really if we could just have the option of a non-ass filtering shader ;-) |
| 19:13 |
MTDiscord |
<Benrob0329> No no, I'd like to keep the ass-filtering shader thank you :P |
| 19:13 |
MTDiscord |
<Warr1024> Basically we need to be able to specify that the game should only render a thing in a way that yields crisp edges, though some AA could be tolerable if it's done properly. |
| 19:13 |
erlehmann |
well |
| 19:13 |
erlehmann |
not necessarily |
| 19:13 |
erlehmann |
take chests |
| 19:14 |
erlehmann |
chests need crisp edges for the outlines of a lock and so on |
| 19:14 |
erlehmann |
but the body is usually more of a pixel mush |
| 19:14 |
MTDiscord |
<Benrob0329> I may add a higher resolution texture for certain effects in a game for visual effect, but still keep a mostly pixel art style. I'd like to be able to specify what can and can't be filtered |
| 19:14 |
MTDiscord |
<Benrob0329> This seems like the ideal thing to add to a tile def |
| 19:14 |
erlehmann |
i agree |
| 19:14 |
MTDiscord |
<Benrob0329> Maybe I should make an issue |
| 19:14 |
erlehmann |
yes please do |
| 19:15 |
MTDiscord |
<Warr1024> Really the biggest problem probably comes from the fact that filters treat RGBA naively and if the RGB values were discarded for fully transparent pixels, you get weird halo effects. There's a hack in the engine to mitigate that but it's not foolproof. |
| 19:15 |
erlehmann |
i saw enough mineclonia screenshots with horrible horrible filtering |
| 19:15 |
erlehmann |
and we have both stuff that needs filters and stuff where no one cares |
| 19:15 |
MTDiscord |
<Warr1024> I wouldn't say "disallow filtering" but I would say that if filtering is allowed it has to meet certain standards for pixel preservation. |
| 19:17 |
MTDiscord |
<Warr1024> The best tuning I've found is (1) turn on filtering, (2) enable texture clean transparent, (3) set texture min size fairly high, and (4) have a video card that can handle all that. You can get some decent screenshots that way, but yeah, it's not necessarily accessible to everyone. |
| 19:17 |
MTDiscord |
<Warr1024> The problem is when you want higher quality than you can spend the silicon on, you end up needing to know what compromises in setting are okay and which are gonna suck. |
| 19:19 |
MTDiscord |
<Warr1024> Texture min size basically upscales all your textures at load time into an HD pack using NN, so you get a nearest-up-linear-down effect and it ensures integer scaling. That cuts way down on blur but obviously costs memory. |
| 19:19 |
erlehmann |
CSS has an example for that |
| 19:20 |
MTDiscord |
<Warr1024> I've seen shaders that do that trick, but dynamically so it gets the same effect, requires no fine tuning, and no extra memory, but of course it's a compute/memory trade-off. |
| 19:21 |
erlehmann |
https://developer.mozilla.org/en-US/docs/Web/CSS/image-rendering |
| 19:21 |
erlehmann |
image-rendering: auto; |
| 19:21 |
erlehmann |
image-rendering: crisp-edges; |
| 19:21 |
erlehmann |
image-rendering: pixelated; |
| 19:22 |
erlehmann |
oh it lists also “smooth” and “high-quality” |
| 19:22 |
MTDiscord |
<Benrob0329> #11968 |
| 19:22 |
ShadowBot |
https://github.com/minetest/minetest/issues/11968 -- Add `allow_filtering` Option to Tiles Definition |
| 19:22 |
MTDiscord |
<Warr1024> CSS is where I got the "crisp edges" name from, but specific implementations may need to be allowed to vary on how exactly that's achieved. We want AA to be allowed if possible but not mandatory, but not arbitrary blurring is definitely anathema. |
| 19:23 |
erlehmann |
but that is the whole point of css |
| 19:23 |
erlehmann |
it has this enum with stuff that was deemed to apply to a wide range of things |
| 19:23 |
MTDiscord |
<Warr1024> That's probably fair |
| 19:23 |
erlehmann |
excepd for “pixelated” which is nearest neighbour, it says nothing about the algorithms that locks you in |
| 19:24 |
erlehmann |
so … Benrob0329 would you edit your issue so that it is not a boolean? |
| 19:24 |
MTDiscord |
<Benrob0329> Feel free to comment on alternatives |
| 19:24 |
erlehmann |
the CSS thing was a boolean in the beginning too |
| 19:24 |
erlehmann |
then they realized that is not enough |
| 19:25 |
MTDiscord |
<Benrob0329> I'm not convinced that MT would actually use it, but I'm not against it either. |
| 19:26 |
MTDiscord |
<Benrob0329> I suppose my suggestion is an MVP, if whoever implements this want to shoot for more then that's fine by me. |
| 19:27 |
MTDiscord |
<Benrob0329> I'll add a note about CSS's property though |
| 19:30 |
MTDiscord |
<Warr1024> I'm in favor of MVPs so long as we just don't paint ourselves into a weird compat corner. Probably a bool could be okay in the same way we once got away with it for use_texture_alpha and seem to have survived that transition too. |
| 19:31 |
MTDiscord |
<Benrob0329> Using string values is more future-proof, but also YAGNI |
| 19:36 |
MTDiscord |
<Jonathon> use_texture_alpha has issues with older clients |
| 19:36 |
MTDiscord |
<Jonathon> but its very slight |
| 19:43 |
|
v-rob joined #minetest-dev |
| 19:45 |
erlehmann |
uh |
| 19:45 |
erlehmann |
the stringly typed solution is *entirely* future proof if you have a default value, which you need to have anyway |
| 19:47 |
MTDiscord |
<Warr1024> Strongly typed just makes you feel stupid though if you never end up with more than 2 different supported values. |
| 19:48 |
MTDiscord |
<Warr1024> Reminds me too much of people trying to invent their own book types using the strings "Yes" and "No". One case I ran into of that also did checks like == "No" and != "yes" in different places and I could never actually decipher it. |
| 19:48 |
MTDiscord |
<Warr1024> also [sic] |
| 19:56 |
|
proller joined #minetest-dev |
| 20:04 |
erlehmann |
stringly typed |
| 20:04 |
erlehmann |
not strongly typed |
| 20:04 |
erlehmann |
and yes i want smooth, crisp-edges and pixelated |
| 20:04 |
erlehmann |
all 3 make sense for mineclonia |
| 20:08 |
MTDiscord |
<luatic> Smooth for GUIs? |
| 20:09 |
erlehmann |
more for some kind of overlays |
| 20:09 |
erlehmann |
or effects |
| 20:09 |
erlehmann |
crisp edges with everything that has clearly defined edges but also large not-one-color-but-almost areas like chests and presents |
| 20:09 |
erlehmann |
or shields, tools etc. |
| 20:10 |
erlehmann |
uh |
| 20:10 |
erlehmann |
anyone knows what the state of the item scaling is rn? |
| 20:10 |
erlehmann |
i remember it to be gnarly |
| 20:11 |
MTDiscord |
<luatic> pixelated basically |
| 20:11 |
erlehmann |
ah so the smoothie bug was fixed ig |
| 20:12 |
MTDiscord |
<luatic> the smoothie bug was not a bug, just a mislabeled setting ;) |
| 20:12 |
erlehmann |
uh tell? |
| 20:12 |
MTDiscord |
<luatic> https://github.com/minetest/minetest/issues/11753#issuecomment-1008353277 |
| 20:13 |
MTDiscord |
<Warr1024> "strongly typed" = autocorrect |
| 20:14 |
erlehmann |
the amount at which ppl tell me that “autocorrect” messed up their words it seems more like auto-incorrect |
| 20:14 |
erlehmann |
like some cursed thing where you do not have to tab-complete to get the word or choose it, but it changes what you type in |
| 20:14 |
MTDiscord |
<Warr1024> It works great for non-jargon prose, which is almost half I say. |
| 20:14 |
erlehmann |
is it like that? |
| 20:14 |
MTDiscord |
<luatic> erlehmann: it often is |
| 20:14 |
erlehmann |
like you type stuff and the computer *replaces* it? |
| 20:15 |
MTDiscord |
<luatic> usually the phone but yes |
| 20:15 |
MTDiscord |
<Warr1024> Yeah |
| 20:15 |
MTDiscord |
<luatic> it "fixes" your spelling ;) |
| 20:15 |
erlehmann |
how horrible |
| 20:15 |
erlehmann |
no offense, but it sounds like something really bad to use |
| 20:15 |
MTDiscord |
<Warr1024> Also that "regression" you posted is a regression that counter-regresses another regression. |
| 20:15 |
erlehmann |
i have only used autocomplete on maemo and there it was that you type the beginning of a word the rest becomes visible and you can press a key to get to it, like tab complete |
| 20:16 |
erlehmann |
but the other stuff i saw was that you *chose* the word, not that it silently replaces what you typed |
| 20:16 |
erlehmann |
so this is news to me |
| 20:16 |
MTDiscord |
<Warr1024> If on screen keyboards had tactile texture then it wouldn't be so much of an issue... |
| 20:17 |
erlehmann |
must be a horrible thing if you have two words that are similar but use one slightly more often than the other haha |
| 20:17 |
MTDiscord |
<Benrob0329> I disable auto-correction and just manually select the correct one if need be |
| 20:17 |
|
x2048 joined #minetest-dev |
| 20:18 |
MTDiscord |
<Warr1024> Anyway there is a lot of argument in MT about what to do when you can't exactly integer scale a thing. You have to choose between blurry and jagged, and each side is convinced that the other way is obviously wrong. At least we have options now, which is probably the only way that would ever get solved. Having those options actually work in all cases would be icing on the cake... |
| 20:18 |
|
appguru joined #minetest-dev |
| 20:19 |
MTDiscord |
<Warr1024> Hmm I guess I can try "suggest but don't correct" and see how it goes but I miss the suggestion bar often and end up with words spelled like th5 |
| 20:20 |
Pexin |
erlehmann: when people txt me and then go "oops autocorrect", every time I internally react violently: why would anyone ever use or make such a thing. if for no other reason than wasted cpu.. |
| 20:22 |
rubenwardy |
you say that, but using a phone without autocorrect is so painful |
| 20:23 |
Pexin |
using a touchscreen for Anything is painful |
| 20:23 |
erlehmann |
rubenwardy there is a difference between autocorrect (changes what you write) and autocomplete (any prefix/phoneme based input method) |
| 20:24 |
erlehmann |
both work on touch devices and the latter rarely have the issues of the former (namely, the wrong words come out) |
| 20:24 |
MTDiscord |
<Warr1024> I'm trying without autocorrect now and now it's becoming painfully clear to me how hard it is to actually type correct words into an onscreen keyboard. Suggestions help but I have to go back and correct a lot. |
| 20:24 |
MTDiscord |
<Benrob0329> Touchscreens could be great and make a lot of out keyboard vs mouse interface issues go away since you can have dedicated buttons for whatever and hit as many of them as you have fingers, but they often don't |
| 20:24 |
MTDiscord |
<Benrob0329> *our |
| 20:25 |
Pexin |
I miss my first mobile with hardware keypad |
| 20:25 |
erlehmann |
Warr1024 do you have an autocomplete option? |
| 20:25 |
MTDiscord |
<Benrob0329> They also suck for when you want to separate your UI from your display, since they inherently can't do that |
| 20:28 |
MTDiscord |
<Warr1024> Okay, autocorrect reenabled, since the error rate without it was higher than with |
| 20:32 |
erlehmann |
luatic if it “did not do that in 5.4” this sounds like a regression? https://github.com/minetest/minetest/issues/11753#issuecomment-1008353277 |
| 20:33 |
sfan5 |
not every change of behaviour is a regression |
| 20:39 |
MTDiscord |
<Warr1024> That workorder is somebody enabling a setting, then filing a bug report that enabling the setting caused the setting to take effect ... |
| 20:39 |
sfan5 |
merging #11958, game#2745 in 10m |
| 20:39 |
ShadowBot |
https://github.com/minetest/minetest_game/issues/2745 -- Redo player_api by appgurueu |
| 20:39 |
ShadowBot |
https://github.com/minetest/minetest/issues/11958 -- Optimize folder handling in 'files' mod storage backend by sfan5 |
| 21:49 |
|
Taoki joined #minetest-dev |
| 21:50 |
|
v-rob joined #minetest-dev |
| 22:00 |
|
proller joined #minetest-dev |
| 22:35 |
erlehmann |
we are having load spikes, is there anything in the minetest *engine* that could make it lag about every ten minutes? |
| 22:45 |
erlehmann |
Warr1024 could the 10 min spikes here have something to do with shadows/daylight or not at all? https://monitoring.minetest.land/d/YUpouLmWk/lua-server-monitoring-mod?var-instance=oysterity&orgId=1&refresh=10s |
| 23:41 |
MTDiscord |
<savilli> looks more like lua gc |
| 23:43 |
|
proller joined #minetest-dev |
| 23:58 |
MTDiscord |
<josiah_wi> What's good practice for ensuring thread safety? I have a class that wraps a resource that isn't thread safe, and I have a method to return a raw pointer to that resource. |
| 23:59 |
MTDiscord |
<josiah_wi> I have some concerns about this design. |
