Minetest logo

IRC log for #minetest-dev, 2021-10-31

| Channels | #minetest-dev index | Today | | Google Search | Plaintext

All times shown according to UTC.

Time Nick Message
00:00 hendursaga joined #minetest-dev
00:45 MTDiscord <exe_virus> for the record, the TGA version of that single default_acacia_bush_sappling was larger than png by 25 bytes.
00:54 MTDiscord <exe_virus> For a test of the simplest image: a 1x1 dot of RGB = 0,0,0, we get:  JPEG: 284 bytes PNG: 67 bytes TGA: 48 bytes WEBP: 30 Bytes
01:00 AliasAlreadyTake joined #minetest-dev
01:33 MTDiscord <exe_virus> Also, there's been new developements that are quite relevant to this discussion: Webp2 is being worked on, AVIF is awesome, so is JPEG-XL, and there's BPG. I.e. There's a lot of active development on the subject.  I was not aware of all of them because they're all 2019+. Last time I did all the research was... 2019 haha
01:35 Extex joined #minetest-dev
01:36 olliy joined #minetest-dev
01:40 MTDiscord <exe_virus> Interesting, this site is super helpful for testing: https://squoosh.app/   It lets you play with compression sizes and comparisons in real time. Looks like webp2 when it's done will be a better replacement: it's a solid 19 bytes for the single black dot. For the acacia bush, it comes out at 66 Bytes, vs png's 151 and webp's 102. Now I wonder if we should just wait to support webp2 when its released
01:46 v-rob joined #minetest-dev
02:03 MTDiscord <Jordach> xkcd standards pls
02:32 pgimeno joined #minetest-dev
02:53 hendursaga joined #minetest-dev
03:00 v-rob joined #minetest-dev
03:02 v-rob I never saw what was the problem with plain PNG, or JPEG if you have a huge texture.  It's not like the difference is more than a few bytes for the vast majority of textures regardless of format...
03:02 v-rob And every image editor under the sun will support them
03:28 queria joined #minetest-dev
03:30 MTDiscord <exe_virus> It's a decent compression nowadays. I'll have to test with webp2, but webp1 compressed MTG textures is a solid 20% smaller than current pngs.   Based on my testing with acacia bush, I'd expect the webp2 sizes to be almost 50% of the original PNG sizes.   It matter because of bandwidth reductions, both for cdb hosting and server new player joins. Lowering that barrier always increases player uptake
03:31 MTDiscord <exe_virus> As for support, webp has gimp support, so that one makes a lot of sense
03:31 MTDiscord <exe_virus> And it's not like we're dropping jpeg or png support
03:31 MTDiscord <exe_virus> Just trying to get more bang for the buck on our game engine
03:34 queria joined #minetest-dev
03:45 v-rob joined #minetest-dev
04:00 MTDiscord joined #minetest-dev
04:01 specing_ joined #minetest-dev
04:09 tekakutli joined #minetest-dev
04:23 MTDiscord <exe_virus> As for lossy compression, AFIV is about 20% of the original size for equal quality compared to jpeg. So that discussion for lossy is quite quite important
04:24 MTDiscord <exe_virus> i.e. 60 KB->9.63B (sorry, 16% of original in my test case)
07:36 MTDiscord joined #minetest-dev
08:05 hendursa1 joined #minetest-dev
09:54 erlehmann joined #minetest-dev
09:58 tech_exorcist joined #minetest-dev
10:02 erlehmann i have found a case in which shaders make an object black, no shaders make it white
10:02 erlehmann very unfunny
10:02 erlehmann i am bisecting the issue
10:30 MTDiscord <luatic> The "single pixel" is biased towards low overhead formats. v-rob makes a good point: PNG support is ubiquitous. WebP support is not.
10:31 erlehmann luatic the single pixel is obv the extreme case to figure out the minimum amount of overhead, not a true benchmark
10:32 erlehmann btw, for anyone wondering what i meant with the dependencies being underspecified: every time you have to delete CMakeCache.txt to actually get minetest to build, you probably have encountered such a bug.
10:33 erlehmann one way i managed to get to that is during bisection, by building a commit much newer than 5.4.1, then trying to build 5.4.1.
10:34 erlehmann it fails, unless I delete CMakeCache.txt – even if i instruct make to build everything (from which i conclude the problem is cmake)
10:35 proller joined #minetest-dev
10:38 Fixer joined #minetest-dev
11:27 MTDiscord <exe_virus> Just because it's ubiquitous, doesn't mean we can't support newer formats also. Heck we have .b3d, the least ubiquitous 3d object format, and we won't probably rip that out ever
11:30 erlehmann oh i'm sure some clown will advocate for that eventually
11:34 erlehmann anyways, does *anyone* have an idea how this could happen? the book is supposed to be textured: https://mister-muffin.de/p/Dm8y.png
11:35 erlehmann with shaders, book is solid black. without shaders, book is solid white.
11:40 MTDiscord <exe_virus> What image format?
11:40 MTDiscord <exe_virus> And can you post that file?
11:41 MTDiscord <exe_virus> Wait, this might be related to a certain compression for png, is this an optimized png with transparency?
11:41 MTDiscord <exe_virus> Long story short there's a big with AMD built-in GPUs with transparency and I believe mipmaps when the png is in a compressed filter mode, very very specific
11:42 MTDiscord <exe_virus> Bug*
11:44 sfan5 textures are expanded to RGBA in software before they touch the cpu, such details will never affect the rendering result
11:48 erlehmann this is the enchantment table, the bug happens in mineclone2 and mineclonia from 5.4.0 onwards (i did not check older versions)
11:49 erlehmann so cora said it works in 5.4, but only with shaders and does not work in 5.5-dev
11:50 erlehmann exe_virus, i'll look for the file
11:50 calcul0n__ joined #minetest-dev
11:57 MTDiscord <exe_virus> It's affected it before sfan5. When we compressed mtg default textures using optipng a couple months ago we had to restrict it from some filtering options on transparency pngs because I think we did something wrong with the binary alpha rendering.
11:58 erlehmann yeah if anyone says “this can't be happening” during debugging, it's best to not believe them until you checked
11:58 erlehmann software bugs are literally dark magic
11:58 MTDiscord <exe_virus> Oh don't worry, sfan5 knows that
11:58 erlehmann i have the file
11:58 erlehmann exe_virus how do i determine if the png is bad?
11:58 MTDiscord <exe_virus> Host it somehow and post a link haha
11:59 MTDiscord <exe_virus> I'll have to test it today sometime
11:59 erlehmann i can do that but this *screams* for some code that outputs a warning on bad pngs
11:59 MTDiscord <exe_virus> Nah, it's not the pngs fault
12:00 erlehmann uh?
12:00 MTDiscord <exe_virus> How dare it use its own format
12:00 erlehmann oh well, on PNGs the engine can't handle
12:00 MTDiscord <exe_virus> Right, we should just handle them better
12:00 erlehmann or warn if you can't
12:01 erlehmann exe_virus this is the code for the bad entity https://git.minetest.land/Mineclonia/Mineclonia/src/branch/master/mods/ITEMS/mcl_enchanting/init.lua#L174
12:01 erlehmann i mean the bugged entity
12:03 erlehmann exe_virus is that enough?
12:03 erlehmann i actually expect this not to be bugged everywhere
12:03 sfan5 @exe_virus that's not about filtering options but about throwing away colors for pixels that are transparent, these are meaningful to Minetest since they're used for opaque leaves
12:04 erlehmann uh, why would anyone throw away colors for pixels that are transparent? you need those for blending
12:04 erlehmann but yes, that seems the PNG optimizers fault
12:04 erlehmann or rather the fault of whoever chose the options
12:04 sfan5 well it's fine for most things
12:05 erlehmann i run into this kind of bug usually when i encounter naive gradient implementations
12:06 erlehmann they tend to try to blend to transparent black
12:06 erlehmann which works as well as you think it would, not at all
12:06 MTDiscord <exe_virus> Ah gotcha, thanks sfan
12:06 sfan5 OpenGL does that too
12:07 pgimeno it should work in premultiplied alpha mode I believe
12:07 erlehmann yeah pgimeno
12:07 MTDiscord <exe_virus> Yeah my test plan is to run mt in debug mode and to see if the file loads differently
12:07 erlehmann true
12:07 MTDiscord <exe_virus> For each version
12:07 MTDiscord <exe_virus> Maybe I can dump the contents or something easy
12:07 erlehmann exe_virus additional information, i compile with clang++
12:08 erlehmann uh, or rather i don't
12:08 MTDiscord <exe_virus> Haha, no worries it shouldn't be that kind of big
12:08 erlehmann what does “IrrlichtMT project is missing a CMake target?!” mean?
12:08 MTDiscord <exe_virus> You need to configure the project basically
12:08 erlehmann there is already code that has 100% different results when compiled with gcc or clang (the biome UB)
12:08 MTDiscord <exe_virus> IrrlichtMT specifically
12:09 erlehmann but i did build irrlichtmt in lib/irrlichtmt
12:09 erlehmann like cmake . && make -j8 -B
12:09 MTDiscord <exe_virus> "shrug?" I don't have that much build experience sadly
12:09 erlehmann the build system is so cursed
12:15 erlehmann nevermind, i fixed it, i had irrlichtmt1.9.0mt0 by accident
12:15 erlehmann i once again want to remind everyone that git submodules exist
12:16 erlehmann like, if you are tightly coupling a library to an application program (removing/changing interfaces), there should be a way to automagically make it work
12:16 erlehmann so far the CI seems to just paper over it
12:17 erlehmann by hardcoding irrlichtmt version tag for the nightlies
12:19 sfan5 breaking build system changes are annoying when bisecting but we should be past that now
12:23 erlehmann sfan5, a bunch of shell scripts that try to reproducibly build a specific version of mt, good idea or bad?
12:24 sfan5 good obviously but I don't think they should be put into the repo if that's what you're thinking of
12:24 erlehmann why not
12:25 erlehmann like what is the problem with making it easier to build mt?
12:27 sfan5 needing to automatically build arbitrary revisions is a specialized usecase, normal people just clone master and read the instructions
12:27 erlehmann look, normally, the build system would be able to handle that
12:27 erlehmann uh
12:27 erlehmann packagers for distributions need that
12:28 MTDiscord <Sublayer plank> packagers just have their own buildscript they maintain usually
12:28 erlehmann the build system is stupid though, and i doubt i'll be able to change that. a bunch of scripts that made “the canonical binary” would help so much.
12:28 sfan5 packagers don't need arbitrary revisions, they need to build releases which happens at most twice a year
12:29 erlehmann and by “i doubt i'll be able to change that”, i mean every time i point out pain points, it is “not a big deal”, or an “edge case”
12:29 sfan5 additionally packagers would never use that script no matter how super convenient it is
12:29 erlehmann uh, i build arbitrary revisions. and i know an arch linux packager of my own software, that guy packages every little revision.
12:30 erlehmann also, some server admins do not run master, but patch it
12:31 sfan5 I was thinking of packages maintained by the distribution, unofficial packagers can do whatever of course
12:32 erlehmann look, forget about it. i already figured out there seems to be little interest in small, incremental improvements. but you should know that i am not the only person debugging minetest and trying out different versions and it has become harder, not easier, to do that. i am merely the most obnoxious ones.
12:32 erlehmann one
12:32 erlehmann the last person i encouraged to report difficulties to the devs flat-out rejected it
12:33 erlehmann you should really try to not reject convenience things bc *you* don't need them
12:33 sfan5 I am not preventing you from writing that script or publishing it
12:33 erlehmann yeah but if i publish it on some random website it won't help for the future
12:34 pgimeno left #minetest-dev
12:34 erlehmann sfan5, would a single script that compiles the current revision fit in though?
12:35 erlehmann i mean like the CI stuff, but actually using the appropriate version of irrlichtmt
12:35 erlehmann and not hidden in CI stuff
12:37 sfan5 would that script just clone irrlichtmt and run cmake + make?
12:37 erlehmann no, it would also make sure that all the workarounds are applied
12:38 sfan5 so it'd delete all build files first too
12:38 erlehmann i think you need to delete CMakeCache.txt in both directories and give make the -B option
12:39 erlehmann also for compiling with OGLes it would need to change stuff
12:39 sfan5 giving make any funny options sounds like it'd contribute to breaking it
12:39 erlehmann do you even know what make -B does?
12:39 sfan5 yes
12:39 erlehmann well, how can unconditionally making all targets break anything?
12:40 erlehmann it's the *only* way to get a reliable result with make
12:40 erlehmann you know, this is bikeshedding
12:42 sfan5 not all targets are for compiling files, cmake also does some internal stuff so I'm just guessing that it's not totally safe
12:42 erlehmann i just want to contribute to minetest so i can finally do meaningful code reviews (which is about the only thing i am really interested in) :/
12:45 sfan5 anyway what I had in mind with my question is that the script would have to be configurable for users to pass arbitrary options to cmake
12:45 sfan5 or perhaps swap 'make' for 'ninja'
12:45 sfan5 so if it's just about irrlichtmt maybe a script that clones the right revision of irrlichtmt would be better (and leave the rest for the user)
12:46 erlehmann ninja is equally broken as make for this purpose, but i don't particularly care which broken system you use
12:46 erlehmann > the script would have to be configurable for users to pass arbitrary options to cmake
12:46 erlehmann ofc
12:50 calcul0n_ joined #minetest-dev
13:50 MTDiscord <exe_virus> No worries, I have been thinking about running a new mine test repo for test scripts, build scripts, etc. Basically one that has extraneous stuff that we don't want mucking up the main repo
13:51 MTDiscord <exe_virus> Then hopefully I toss on a CI to it and it runs whenever a new commit goes to minetest master
13:51 MTDiscord <exe_virus> Or irrlichtmt
13:52 MTDiscord <exe_virus> At the end of the day it's nearly impossible to make build scripts better, because there is no way to enforce the same system on every single dependency, especially old libraries. Just be thankful most are at least on cmake now
13:53 MTDiscord <exe_virus> This isn't python where there is only one way to do things haha
14:01 erlehmann exe_virus pretty sure i know how to make build scripts incrementally better at least on linux, but almost everyone stops listening once i start with “strace the compiler so you 100% get all dependencies”
14:52 proller joined #minetest-dev
14:53 olliy1or joined #minetest-dev
15:35 fluxionary joined #minetest-dev
15:40 MTDiscord <exe_virus> Well, put it in a repo and I'll look at it sometime soon, this is a long term learning process haha. We're also slow to adopt change as a community, so there's that. We eventually make the needed changes basically every time, it just takes time;)
15:51 Extex joined #minetest-dev
16:02 specing_ joined #minetest-dev
16:25 olliy joined #minetest-dev
16:31 erlehmann sofar does the parkour in “inside the box” rely on sneak jump glitches? if yes, you should probably look at this PR https://github.com/minetest/minetest/pull/11367
16:57 tech_exorcist joined #minetest-dev
17:07 MTDiscord <GreenXenith> ITB disables sneak grabbing entirely
17:14 rubenwardy #11567 is marked as needs approval, but has active discussion. Worth deciding on something
17:14 ShadowBot https://github.com/minetest/minetest/issues/11567 -- Use an sqlite database for the media cache by Desour
17:15 rubenwardy I'm not too worried about one time downloads, but any issues with locks from multiple MT instances could be a problem for me (as I often start multiple at the same time to test something)
17:19 MTDiscord <exe_virus> For the record, zlib compression yields no gains for pngs and jpeg, but does helped with plaintext awful .obj
17:20 rubenwardy What's the plan for irrlichtmt? Is it being reduced in size, rewriting, and then eventually merged into the minetest/minetest repo?
17:21 MTDiscord <Sublayer plank> the sqlite media cache PR feels overengineered tbh
17:21 rubenwardy yeah I agree, it's complicated
17:25 MTDiscord <Sublayer plank> anyways yeah irrlichtmt is supposed to be absorbed into minetest soon enough
17:26 MTDiscord <Sublayer plank> most of the rendering code will probably be thrown out for hecks' rendering engine in the near future
17:31 MTDiscord <exe_virus> Nice
17:31 erlehmann joined #minetest-dev
18:02 Krock will merge #11467 #11722 game#2904 game#2888 in 15 minutes
18:02 ShadowBot https://github.com/minetest/minetest_game/issues/2904 -- Add Japanese translation by nogajun
18:02 ShadowBot https://github.com/minetest/minetest_game/issues/2888 -- Use itemstack name in door on_place by LoneWolfHT
18:02 ShadowBot https://github.com/minetest/minetest/issues/11467 -- Add joystick layout for DragonRise GameCube controller by Izzette
18:02 ShadowBot https://github.com/minetest/minetest/issues/11722 -- Apply shadow only to the naturally lit part of the fragment color by x2048
18:06 Extex joined #minetest-dev
18:17 Krock merging
18:36 tech_exorcist joined #minetest-dev
18:38 hendursaga joined #minetest-dev
18:45 hendursaga joined #minetest-dev
19:26 tech_exorcist joined #minetest-dev
19:26 Wuzzy joined #minetest-dev
19:32 Wuzzy #11665
19:32 ShadowBot https://github.com/minetest/minetest/issues/11665 -- Decouple liquid pointing from liquidtype by Wuzzy2
19:44 erlehmann regarding https://github.com/minetest/minetest/pull/11367 – does this influence “sneak glitch fence jumping”?
19:45 erlehmann when a player wants to jump across a fence that is too high
19:45 erlehmann they press sneak
19:45 erlehmann to get on the fence
19:45 erlehmann that has been a game mechanic since forever i think?
19:45 erlehmann would be a shame if something happened to it
19:53 Wuzzy only if Sneak Glitch is enabled. but obviously this PR needs testing since it touched move code
20:07 erlehmann i am really irritated by the desire of some developers to change APIs in mostly-backwards-incompatible ways in the name of elegance when they could just as well introduce a new function that does what they want.
20:08 erlehmann Wuzzy the rail/road end tile thing looks very nice
20:09 Wuzzy thx
20:10 erlehmann > Under the new rules, non-roadmap non-bugfix PRs have 7 days to be concept approved, otherwise they should be closed.
20:10 erlehmann LOL
20:12 MTDiscord <Jonathon> the roadmap is a joke
20:12 erlehmann with the amount of reviews that are going on vs amount of open PRs, i suspect a lot of stuff will be closed soon
20:12 rubenwardy people complain when we don't have one, people complain when we do
20:13 rubenwardy can't win in open source
20:13 erlehmann nah, having one is good
20:15 tech_exorcist joined #minetest-dev
20:37 erlehmann i think the 7 days thing is a perfect rule to get rid of all these annoying contributors
20:37 erlehmann the drive-by PRs that fire code into the general direction of minetest
20:37 erlehmann and then speed off, only to reload
20:39 sfan5 are you being sarcastic
20:40 MTDiscord <Jonathon> unfortunately they probably arent
20:40 erlehmann only half. when i was maintaining things 10 years ago, it was a problem that github popularized the drive-by shooting style of PR where ppl would dump a bunch of code, then vanish
20:40 rubenwardy it doesn't really stop drive-by PRs necessarily - our rules on Action needed / draft PRs helps with that
20:41 rubenwardy it allows us to focus on PRs that are most needed right now, by codafying what that means
20:42 erlehmann sfan5, the other half is “ppl like cora and fleck are maintaining their own clients” btw.
20:43 erlehmann they are probably not the only ones and i doubt it is primarily for cheating in all cases
20:43 MTDiscord <Jordach> oh it is
20:43 MTDiscord <Jordach> i guarantee it#
20:47 erlehmann i shouldn't have mentioned that
20:48 erlehmann good night
20:48 erlehmann left #minetest-dev
21:30 Extex joined #minetest-dev
21:37 Extex joined #minetest-dev
21:56 v-rob joined #minetest-dev
22:05 longerstaff13 joined #minetest-dev
22:06 proller joined #minetest-dev
22:21 rubenwardy merging #11110 and #11656 in 10
22:21 ShadowBot https://github.com/minetest/minetest/issues/11110 -- Fix number of tool uses being off by 1..32767 by Wuzzy2
22:21 ShadowBot https://github.com/minetest/minetest/issues/11656 -- Add variable to use existing IrrlichtMt build by JosiahWI
22:21 rubenwardy #9847 is something easy to review
22:21 ShadowBot https://github.com/minetest/minetest/issues/9847 -- Add bitop library by Lejo1
22:22 rubenwardy sfan5: would you like me to merge #11729 and #11690 as well?
22:22 ShadowBot https://github.com/minetest/minetest/issues/11729 -- [no squash] Buildbot improvements by sfan5
22:22 ShadowBot https://github.com/minetest/minetest/issues/11690 -- Update Android to new dependency repo by sfan5
22:22 sfan5 yes
22:22 sfan5 re 9847 might be worth adding an unittest that starts up a script env and checks for the library
22:23 sfan5 (not necessarily in that PR)
22:23 sfan5 the opportunity could also be used to verify that the basics of the sandbox is working
22:23 sfan5 s/ is / are /
22:23 rubenwardy is that something we've done before? Other than dev test
22:24 rubenwardy well, devtest's integ tests don't run in CI (unless they do, I vaguely recall work on that)
22:24 sfan5 testing script env from unittests would be a first
22:24 sfan5 I haven't found any tests inside devtests that could be run in an automated fashion during integration tests
22:25 rubenwardy the tests I wrote are intended to run automatically
22:25 rubenwardy although, I can't remember how they exit on success/failure
22:28 v-rob joined #minetest-dev
22:28 rubenwardy https://github.com/minetest/minetest/tree/master/games/devtest/mods/unittests
22:28 rubenwardy looks like they use `assert()`
22:28 rubenwardy so on failure, it would crash with code 1
22:28 rubenwardy and on success it would keep running
22:28 rubenwardy so just need to solve the halting problem
22:29 sfan5 oh huh that stuff is there
22:56 Extex joined #minetest-dev
23:03 v-rob joined #minetest-dev
23:30 sfan5 hmm something about automatially copying the mingw files didn't work
23:30 v-rob joined #minetest-dev
23:31 sfan5 runtime_dlls=
23:31 sfan5 -DEXTRA_DLL="$runtime_dll" \
23:31 sfan5 spot the mistake
23:32 rubenwardy 🤦
23:32 rubenwardy at least it's not a mistake that would delete player's worlds. That's something I was worried about with the Android scoped migration
23:33 sfan5 copying worlds first in the migration was a good idea actually, the later you do the more likely the user is going to interrupt it
23:34 rubenwardy Implying that was intentionly considered
23:35 MTDiscord <Jonathon> heh, number of open prs just got axed a lot
23:35 rubenwardy in true halloween fashion

| Channels | #minetest-dev index | Today | | Google Search | Plaintext