Minetest logo

IRC log for #minetest-dev, 2021-09-12

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

All times shown according to UTC.

Time Nick Message
01:18 olliy joined #minetest-dev
03:40 fluxionary joined #minetest-dev
03:57 hendursaga joined #minetest-dev
04:00 MTDiscord joined #minetest-dev
04:49 fluxionary joined #minetest-dev
06:44 erlehmann why is irrlichtmt not a git submodule?
06:45 MTDiscord <Sublayer plank> same reason why minetest_game isn't a git submodule
06:58 erlehmann i do not know the reason
06:59 erlehmann though i must say i like it if irrlichtmt is not tightly coupled to the game
07:00 erlehmann because if it is properly abstracted and anyone refucktors the renderer so it runs slower on my computer, i can just use the old version, right?
07:03 MTDiscord <Sublayer plank> people just don't seem to like git submodules here
07:04 MTDiscord <Sublayer plank> also irrlicht is supposed to be disappearing... eventually and the rest of it just be absorbed into minetest. the rendering rewrite is probably going to be a part of it
07:16 specing joined #minetest-dev
07:50 MTDiscord <luatic> https://github.com/minetest/minetest_game/pull/2894 should be merged now
07:58 erlehmann luatic this bug is hilarious
07:58 erlehmann luatic what if i name my player creative_trash lol
07:59 erlehmann ah i get it
07:59 erlehmann > This is becauce the detached creative inventory has the name "creative_[playername]", but the detached trash inventory has the name "creative_trash". So for the player "trash", there is a naming collision.
08:00 erlehmann https://github.com/minetest/minetest_game/issues/2777
08:05 queria^clone joined #minetest-dev
08:06 hendursa1 joined #minetest-dev
08:25 tekakutli joined #minetest-dev
10:16 calcul0n__ joined #minetest-dev
10:29 calcul0n joined #minetest-dev
10:43 Fixer joined #minetest-dev
10:52 pgimeno <sfan5> that's just you holding return for too long  <--  not my experience, if I try to force-keep return pressed it's not so fast as when it sometimes directly starts. I think there's something broken. But it's unrelated to crashes for me.
10:53 pgimeno I looked into that but not for too long, and I didn't see anything
11:01 Fixer joined #minetest-dev
11:57 appguru joined #minetest-dev
12:18 erlehmann can i speed up TGA addition in any way?
12:24 MTDiscord <Warr1024> Are you running into problems with people playing dev builds and having stuff actually not working now, or are you just nervous that a release may happen with it still not readded?  It does seem to be rather firmly on the 5.5 roadmap...
12:28 MTDiscord <Warr1024> Looks like TGA readding is #11598, which is trivial, but depends on irr#64 being merged first, which is ... non-trivial in volume, but looks like all it does is undelete some files that used to be there anyway, so shouldn't be TOO hard to review.
12:28 ShadowBot https://github.com/minetest/minetest/issues/11598 -- Readd TGA to the list of valid texture formats. by rollerozxa
12:28 ShadowBot https://github.com/minetest/irrlicht/issues/64 -- Readd TGA format support by rollerozxa
12:29 MTDiscord <Warr1024> The only discussion attached to these seem to be just more pointless arguments about how wrong the decision to remove it in the first place was, and not related to re-adding them.  There doesn't seem to be any significant resistance so far to re-adding them.
12:30 erlehmann Warr1024 i am the person running the dev builds and i am getting other kinds of texture errors that i want to make sure are not caused by the fallout of tga removal
12:30 MTDiscord <Sublayer plank> yeah the code in the irrlicht PR is identical to what used to be before its removal... I think with the CR LF line endings intact as well
12:30 erlehmann they seem to be a different issue
12:30 erlehmann i'll investigate
12:30 MTDiscord <Warr1024> erlehmann, are you able to apply these patches to your own builds and test them yourself?  Hearing some positive test results (doesn't have to be from a core dev) would be good.
12:31 erlehmann Warr1024 yes i think i can do that. i'll try now.
12:31 erlehmann Warr1024 btw did you see the solution i posted for faster rebuilds?
12:31 MTDiscord <Sublayer plank> of course it'd be good if someone could read it through (which can probably be said for the entirety of irrlicht) but that would preferrably be done independent of the PR, I just added it back and don't really have the knowledge to see that the code itself is alright
12:32 erlehmann well as long as it *works* i don't care if the prev code had CR LF line endings lol
12:33 erlehmann i'll check it out
12:33 hendursaga joined #minetest-dev
12:35 tekakutli joined #minetest-dev
12:37 sfan5 pushing http://sprunge.us/tESEe3?diff in a few minutes
12:38 erlehmann where is the PR?
12:39 MTDiscord <Sublayer plank> the TGA one?
12:39 erlehmann sfan5, btw: your local git installation seems to be missing the email
12:39 erlehmann no for the thing sfan5 just posted
12:39 sfan5 no, I intentionally removed the email from the paste
12:39 erlehmann ah
12:39 erlehmann sensible
12:41 erlehmann oh i see https://github.com/minetest/minetest/issues/11610
12:44 erlehmann so i guess sfan5 makes an emergency bugfix without review bc it is obvious what broke
12:44 MTDiscord <Warr1024> If line endings are inconsistent, then I would prefer if we took the opportunity to fix them before re-adding the files.  However, if there is contention about it that would cause this not to get merged, then I would rather have the functionality work and be merged and be a little ugly for now than die on that hill...
12:44 erlehmann (it is not to me, but i guess to whoever authored or approved the original code)
12:51 MTDiscord <Sublayer plank> a large part if not the entirety of the irrlicht codebase has CRLF line endings, and while I don't think we're converting it to LF anytime soon (it would cause merge conflicts and history wiping), I don't know what the consensus is on code additions on the scale of entire files being added
12:56 erlehmann pls don't change it for the sake of git diff working
12:56 erlehmann like keep the original
12:57 MTDiscord <Sublayer plank> I feel like it should be converted only if/when it gets absorbed into the core repo
12:57 MTDiscord <Warr1024> I'd probably make CRLF the unfortunate standard.  If we try to change it mid-stream we'd create a diff barrier.  If we try to filter-branch or something to get rid of the barrier, we'd create a potentially worse one in being unable to compare our history with that of other branches.  I think we may need to accept that we're stuck with that standard.
12:57 MTDiscord <Warr1024> I'd make sure that all NEW files though follow whatever the majority convention is in the codebase, even if it's ugly.
12:58 erlehmann yeah
12:59 MTDiscord <Warr1024> If I were to merge a project like irrmt into a project like MT myself, I'd probably do it in a history-preserving way (e.g. you can merge unrelated branches) but unfortunately MT's standard is actually the opposite of that, i.e. there's a good chance it'd just go in as a single squashed commit with only the previous version of MT as a parent.  However, at that time, might as well fix all the line ends, indentation, and any other code
12:59 MTDiscord beauty standards.
13:10 erlehmann Warr1024 if you merge irrlichtmt into minetest proper in a history preserving way, the hecktest fileformat massacre commit makes ”git log -p” unusable, if you merge it as a squash, the resulting commit probably does the same.
13:11 erlehmann i know that bc merging mineclone2 history into mineclone5 history resulted in an abomination of a commit that makhes a bunch of tools very slow or segfault
13:11 erlehmann (it was merged as a squash)
13:12 erlehmann i thinnk
13:12 erlehmann hmm
13:12 erlehmann i have to look it up, but too large commits are a problem anyway
13:12 pgimeno <erlehmann> pls don't change it for the sake of git diff working  <--  git diff has options --ignore-space-at-eol, --ignore-space-change which mitigate that. GNU diff (which can be used with git) has option --strip-trailing-cr to address exactly that.
13:12 erlehmann pgimeno oh i did not know!
13:12 erlehmann thank you
13:14 MTDiscord <Warr1024> Well, part of the problem with git diff is that a lot of 3rd party tools for navigating and analyzing git history offer a completely different set of "smart" options for handling "cosmetic" changes, so in general it's safest to only assume the most naive common denominator.
13:15 pgimeno I noted of a good opportunity for normalizing the newlines in the repo when there were no affected PRs open, but the relevant devs didn't consider it worth doing. And no Sublayer plank, that doesn't wipe history.
13:15 pgimeno It might clobber git blame and that's all.
13:16 MTDiscord <Sublayer plank> yeah I meant git blame
13:16 MTDiscord <Warr1024> Haha, yeah, what to do when you inherit a very large and very long-lived mistake that's hurting nobody very much but everybody a little...
13:16 pgimeno and guess what, git blame has an option to ignore whitespace
13:20 erlehmann <pgimeno> It might clobber git blame and that's all.
13:20 erlehmann thanks i hate it
13:28 Desour joined #minetest-dev
14:06 erlehmann ok who of you removed support for fonts?
14:06 erlehmann like seriously
14:06 erlehmann look in the fonts folder
14:07 erlehmann there are fonts
14:07 erlehmann they do not work
14:08 erlehmann is this another case of “functionality was removed because someone™ had no idea what is in use” or something else?
14:09 MTDiscord <Sublayer plank> did you attempt building minetest without freetype?
14:09 erlehmann what option is that?
14:10 erlehmann -DUSE_FREETYPE=0 i guess
14:12 sfan5 I removed all XML code from IrrlichtMt
14:13 sfan5 non-freetype fonts were broken for a long time, only recently fixed all while still being incomplete and incompatible with modern features needed by some GUI elements
14:14 erlehmann i just tested them
14:15 erlehmann look, what i don't get is: why do you remove features without ANY kind of discussion? or documentation. given that you did not removet the fonts themselves, i guess you did not even realize this would affect something?
14:16 erlehmann i mean i am not using the feature, but the “let's gut the engine” thing seems more like “let's delete whatever i think is not in use” than “let's delete what actually *is* not in use”
14:16 MTDiscord <Sublayer plank> I just tested compiling with ENABLE_FREETYPE=OFF, it crashes on startup. best would be requiring freetype at all times
14:17 MTDiscord <luatic> I'm fine with requiring Freetype
14:17 sfan5 again with this "I bet you did not realize", I know well that removing XML broke the non-freetype fonts we have
14:17 MTDiscord <Jonathon> Same
14:17 MTDiscord <luatic> But when removing a "feature" (or fallback, in this case), please do so properly.
14:17 erlehmann sfan5, then why did you not remove them?
14:17 sfan5 I mentioned it at the time in -dev, nobody cared
14:17 MTDiscord <luatic> Meaning: The XML & PNG font stuff as well as the compile switch USE_FREETYPE should have been removed too.
14:18 erlehmann sfan5, is silence consent for you?
14:18 sfan5 yes
14:18 erlehmann ooof
14:19 MTDiscord <Jonathon> Except there wasnt silence on july 7
14:19 MTDiscord <Jonathon> And the 6th
14:20 erlehmann link?
14:20 sfan5 I didn't specifically set out to stop non-freetype from working it just so happened that it also relied on XML
14:20 Krock huh? bitmap fonts no longer work?
14:20 MTDiscord <luatic> oooof
14:20 sfan5 the functionality could be preserved by swapping out xml for a simpler format but so far nobody has said they want that
14:20 erlehmann “you got blood on my knife mate, i just ran and you stood in the way”
14:21 erlehmann the xml thing is as simple as it gets, you can write those files by hand
14:21 erlehmann disclaimer: have written animated svg by hand
14:21 MTDiscord <Jonathon> You ok'd it krock lol
14:21 erlehmann but srsly look into them
14:21 sfan5 we need an xml reader, not a writer
14:22 erlehmann probably
14:22 MTDiscord <Jonathon> The reason for it going away was irrlicht had its own non compliant spec from the logs
14:22 erlehmann i don't care for font formats, but you could at least make an issue about stuff you remove that seems to be working at least on some configurations (non-freetype minetest does not crash immediately here)
14:22 erlehmann users won't look here
14:23 erlehmann and it should be documented
14:23 erlehmann what was removed and why
14:23 MTDiscord <Sublayer plank> users will just build with the default options of building with freetype enabled
14:23 sfan5 anyway removing bitmap font support has been discussed before and "we don't really need it" pretty much was the consensus so I assumed that's the way it was going anyway in the long run
14:24 MTDiscord <Jonathon> Just dont give users the option to not compile with freetype
14:24 erlehmann well i *kinda* happen to have worked on unifont and there is an isssue about making unifont the fallback font due to its emoji support and it is a 16x8 / 16x16 bitmap font
14:24 erlehmann Jonathon yeah either you rip it out and document it and so on
14:24 erlehmann or you let it in
14:24 sfan5 no, unifont is not a bitmap font
14:24 MTDiscord <Sublayer plank> unifont would be shipped as a ttf though?
14:24 MTDiscord <luatic> This was half-ripped out, that's the issue.
14:24 sfan5 it's a TTF file like all others
14:24 erlehmann but “i refucktored it and then it broke, nobody cared” is bad stewardship
14:25 erlehmann sfan5 you can get a unifont ttf of course, but it will be a bit weird
14:25 MTDiscord <luatic> Refactoring should make code more maintainable, creating dead files is not the way to go.
14:25 erlehmann compared to the crispy clear bitmap well whatever i don't care about fonts
14:25 erlehmann yeah
14:25 erlehmann leaving litter everywhere when removing features is not nice
14:26 MTDiscord <Sublayer plank> to be honest I can agree
14:26 sfan5 removing features is by definition not refactoring
14:26 MTDiscord <luatic> Same kinda goes for hecks trimming stuff like TGA support
14:26 sfan5 no idea why erlehmann uses the wrong term here
14:26 erlehmann i wrote “refucktoring”
14:26 erlehmann on purpose
14:26 MTDiscord <luatic> Has the screenshot thing been fixed yet?
14:26 MTDiscord <luatic> That you can still choose unsupported formats?
14:26 MTDiscord <Sublayer plank> there's still now removed file extensions in src/client/client.cpp from the irrlichtmt unused feature axing
14:27 erlehmann you can still choose unsupported fonts too!
14:27 erlehmann that's how i got to it, i found the fonts and wondered about them
14:27 erlehmann i hope mods/games can not contain fonts
14:27 sfan5 they can't
14:27 erlehmann good
14:27 erlehmann because that would mean figuring out if contentdb has fonts of that type
14:27 erlehmann :)
14:28 MTDiscord <luatic> They can
14:28 MTDiscord <luatic> I have a neat hack for this
14:28 MTDiscord <luatic> You can set settings at load time and it works
14:28 erlehmann lol tell
14:28 erlehmann luatic show
14:28 erlehmann fleckenstein will love this
14:28 MTDiscord <luatic> one moment, recording for you
14:28 MTDiscord <luatic> it's client-side though
14:28 sfan5 Krock: yes, they no longer do. if there's interest in preserving them it can be done
14:29 sfan5 (https://irc.minetest.net/minetest-dev/2021-07-07#i_5844916)
14:29 Krock oh. I totally missed that
14:29 Desour last time I tried, bitmap fonts were by far more performant than freetype ones
14:29 Krock performance is the only benefit
14:29 sfan5 did you try before or after I optimized font rendering?
14:30 Desour before, I think
14:30 Krock like 3 years before
14:30 Desour ^yes
14:30 erlehmann as someone who has worked on a bitmap font, the whole “convert your stuff to ttf” process is extremely unnecessary bloat
14:30 Krock with bulk rendering, stuff surely improved
14:31 MTDiscord <luatic> https://cdn.discordapp.com/attachments/747163566800633906/886620076772573194/2021-09-12_16-30-49.mp4
14:31 MTDiscord <Sublayer plank> does freetype have bitmap font functionality available?
14:32 erlehmann btw, “Drop XML implementation, related code and dependent features” would benefit from an enumeration what was dropped.
14:33 erlehmann in general, from the commit messages for the things that remove features it is not easy to figure out if it was intentional (fonts) or not (TGA)
14:33 erlehmann to break existing features i mean
14:33 erlehmann if you mention it though it is very clear the feature was meant to go into the trash
14:33 MTDiscord <luatic> https://gist.github.com/appgurueu/37982038ce9b4791d452bd66d91c621c
14:33 Desour a fully filled chat still increases my drawtime by ca. 7 ms
14:34 erlehmann Desour how do you benchmark?
14:36 Desour erlehmann: I just looked what the debug info said about the drawtime. and it was just a *very* rough "benchmark"
14:36 erlehmann so what is faster?
14:37 erlehmann btw, does requiring freetype break support for any platform where it worked previously?
14:37 Desour well, I can't test bitmap fonts anymore with recent minetest, can I?
14:37 erlehmann that's important
14:37 erlehmann Desour, only the irrlichtmt “irrlicht without features” library was ubdated, go back to just before the xml removal commit
14:38 erlehmann i guess?
14:38 erlehmann minetest will still happily try to load xml fonts and fail at it
14:38 erlehmann like you can select them
14:39 erlehmann src/client/fontengine.cpp still contains code for that
14:41 Desour btw. the behaviour after changing the freetype setting and not the font_path setting is still pretty bad for endusers: it aborts with an error message in terminal, and won't start again until you change minetest.conf
14:42 sfan5 I created an issue so we don't forget #11611
14:42 ShadowBot https://github.com/minetest/minetest/issues/11611 -- Remove (or preserve) non-TTF font support
14:42 erlehmann thx sfan5
14:43 erlehmann sfan5, could you elaborate on “it only provides a limited character set”
14:43 MTDiscord <MNH48> appgurueu / luatic , don't mind me starring your gist there on your github... I just want to see if I could display complex writing system (eg. thai, arabic, japanese, rejang, mongolian) in Minetest using that way
14:43 erlehmann > It would be possible to preserve this by switching XML out for a simpler text format that is read from Irrlicht.
14:44 sfan5 @MNH48 just switching fonts won't make it work https://github.com/minetest/minetest/issues/11455#issuecomment-883810565
14:44 erlehmann unifont has a very simple one https://en.wikipedia.org/wiki/GNU_Unifont#.hex_format
14:44 sfan5 also Japanese already works
14:45 erlehmann > I like the look of Unifont. It's not a thick pixel font like Minecraft's, and it's not a bland sans-serif either. I haven't actually tested it in game, but I'll bet it looks better. On the other hand, I will not support an emoji font.
14:45 erlehmann this is funny, bc unifont contains a lot of emoji
14:48 erlehmann “It would be possible to preserve this by switching XML out for a simpler text format that is read from Irrlicht.” is a great tactic to not get this solved easily, bc it moves the goalposts from “revert the change” to “if you want this, you have to put in real actual work, because no reverting”
14:49 erlehmann i have seen this often, surely it is rarely meant like that, but it makes it very hard for ppl to support continuing a feature if it means it is more than git revert or copying old code
14:49 pgimeno @luatic https://irc.minetest.net/minetest-dev/2021-07-07#i_5844926
14:55 fluxionary joined #minetest-dev
14:55 erlehmann https://irc.minetest.net/minetest-dev/2021-07-07#i_5844876
14:56 erlehmann <specing> What's the apple hostility against the GPL about?
14:57 erlehmann specing, GPL2 forbids stuff that apple likes, like keeping source secret and GPL3 extends that to forbidding a) not allowing users to run their code on their device b) giving users the code and then threatening them with software patents
14:59 sfan5 erlehmann: "limited character set" well check what you see here and consider how complete it is https://raw.githubusercontent.com/minetest/minetest/master/fonts/mono_dejavu_sans_180.png
15:01 sfan5 if it's decided that we want to keep I would probably be the one writing the new code too (I broke it after all) but I don't want to spend time on something that will end up binned anyway
15:09 sfan5 Desour: #9386
15:09 ShadowBot https://github.com/minetest/minetest/issues/9386 -- Disabling FreeType fonts causes Minetest to crash on startup
15:16 erlehmann sfan5 consider the following http://unifoundry.com/pub/unifont/unifont-13.0.06/unifont-13.0.06.bmp http://unifoundry.com/pub/unifont/unifont-13.0.06/unifont_plane1-13.0.06.bmp
15:17 erlehmann i mention it bc if big fonts break it, it's not that useul
15:17 erlehmann useful
15:17 erlehmann like i have had a bunch of naive font rendering approaches just lag out when loading unifont (in other apps)
15:19 erlehmann the funniest are so-called “immediate mode GUIs” which basically try to render everything in every frame and are a) beloved by ppl who have no idea about performance b) breaking horribly if you give them a font that supports unicode, because they try to allocate giant textures
15:19 fluxionary joined #minetest-dev
15:20 sfan5 I know that unifont is very complete but what matters are the bitmap fonts we have in MT
15:20 sfan5 unless someone puts in the work to find a new one and make it compatible with whatever Irrlicht wants
15:21 erlehmann let me look how much work that would be
15:23 erlehmann “Disabling FreeType fonts causes Minetest to crash on startup” can not generally be true because i am able to start minetest with freetype disabled. but let's see if i can crash it.
15:24 sfan5 maybe read more than the issue title
15:24 erlehmann ok
15:24 erlehmann caught me
15:24 erlehmann ah lol i accidentally switched to the xml fonts and then to a newer minetest and … it does not start at all lol
15:24 erlehmann … are those possibly the fallback fonts? or have i messed it up myself?
15:26 * Desour tried to test non-freetype fonts again, with irrlichtmt dc2246d. But he can't get it to work. it seems to be some problem with CGUIFont not being able to load the fonts
15:27 sfan5 dc2246d is after the XML removal
15:27 sfan5 simply reset to 1.9.0mt2 if you want to test that
15:27 erlehmann Desour check out irrlichtmt 1.9.0mt2
15:28 Desour oh. I've used that commit because it was before the "Delete lots of unused features (#48)" commit x)
15:28 ShadowBot https://github.com/minetest/minetest/issues/48 -- Install icon and .desktop file on Unix systems by jnumm
15:46 erlehmann joined #minetest-dev
15:46 erlehmann Desour lately every second commit is “delete lots of features” ;)
15:47 erlehmann sfan5 Desour is this the bitmap font? https://mister-muffin.de/p/XnO0.png
15:47 erlehmann bc if it is, on my machine the feature 100% worked before it became roadkill
15:47 Desour ok, the displayed drawtime seems to be somewhat misleading. but my fps with freetype font still goes down to 43 fps, and stays 60 with non-freetype (tested with mono_dejavu_sans_9.xml, by filling chat with /mods)
15:48 erlehmann (in caes anyone asks, the sign is not a joke, it is perfectly possible to do c crimes with lua)
15:49 erlehmann Desour wait, it is possible for the game to no longer become slow when some clown fills the screen with nonsense?
15:49 erlehmann i always turned chat off then to keep it playable tbh
15:53 erlehmann OH LOL
15:53 erlehmann Desour i still get an fps drop with bitmap font, but it stays playable
15:54 erlehmann with freetype, even on a faster machine, some user filling the chat with junk can totally make the game miserable apart from all the chat content being displayed
15:54 pgimeno wouldn't chat best be rendered to an FBO to avoid that? it's not that chat text changes every frame
15:54 erlehmann well i'd say removing bitmap font should be seen as a performance regression. the fps difference is *so much* that i want to use it *right now* actually.
15:57 erlehmann pgimeno yeah everything could be better. but right now a performance knob was removed that is really useful
15:58 erlehmann i also think it is ridiculous that the xml format is like that, but i want that damn rendering speedup
15:59 Desour it would be much more useful if the performance of the ttf fonts was fixed
15:59 erlehmann pie in the sky discussion
15:59 erlehmann it can still be fixed once the original thing is repaired
16:00 erlehmann then only if the ttf performance is good (and portable!) enough, i'd remove the old thing
16:00 Extex joined #minetest-dev
16:01 erlehmann like come on, the difference for me is going from >30 fps to <20 with freetype fonts
16:01 erlehmann i can't imagine ppl *not* using bitmap fonts if they know about that
16:02 erlehmann i already told ppl to try it lol
16:02 erlehmann bc it's so damn useful
16:05 Desour interesting, formspec label[]s are rendered much faster. (tried with 100 label[]s with random text created with math.random, tostring and table.concat)
16:05 erlehmann Desour with freetype or bitmap?
16:05 Desour freetype
16:06 erlehmann weird
16:06 pgimeno hm ISTR something discussed about text... is it possible that it uses one draw call per character or something?
16:06 erlehmann any formspec where i can see that in action Desour ?
16:06 sfan5 do both have shadows?
16:07 sfan5 I mean the labels vs chat but in fact missing shadows is also something enabling bitmap fonts do
16:07 sfan5 pgimeno: not anymore but this change is not in 5.4
16:08 Desour I think I can see some shaddow at the label[] text
16:08 Desour erlehmann: wait a moment
16:08 erlehmann ha i found a crash
16:08 erlehmann you will be delighted
16:10 erlehmann ok so first, entirely unrelated to the crash, you can make this funny thing by sending a mesh apparently: https://mister-muffin.de/p/5y9K.txt
16:10 pgimeno erlehmann: you do realize that writing all that stuff here in chat without posting it as bug reports won't get you anything done, right? if pestering developers in IRC until they do what you want is your way of getting things done, then you're hindering development
16:10 pgimeno I've lost track of how many things you've reported, and I haven't seen a single issue posted on GH
16:10 MTDiscord <Jonathon> ^
16:11 sfan5 I think lack of github account may be a factor
16:12 Desour erlehmann: https://0x0.st/-x1i.lua
16:12 pgimeno there's also the forums, I believe bug reports are accepted in the forums too
16:12 erlehmann ok ok
16:13 erlehmann ok i get it, i should open issues
16:13 erlehmann tbh i thought if “committing directly to master without review” is ok, you don't really follow process anyway, but i don't want to make it worse by spamming here
16:14 sfan5 there is a process for committing small fixes directly to master
16:14 sfan5 you are showing your ignorance
16:14 erlehmann ok!
16:14 erlehmann i did not know indeed
16:15 erlehmann but i want you to not ignore me for annoying you, so i make issues
16:18 sfan5 Desour: I took a quick look at chat and formspec and both render the text line-by-line
16:18 sfan5 which I think is inherent to the process for both (not decided by the font impl)
16:19 sfan5 in principle freetype rendering is just as efficient, (in absence of colors) it uses one draw call for the shadows and one for the text itself
16:23 erlehmann what would be the title of the issue for something like this btw? https://mister-muffin.de/p/f70k.txt
16:23 sfan5 is that a segfault or not
16:25 sfan5 confirmed: bitmap font also draws line-by-line in both cases
16:25 sfan5 are you sure the extra performance is not just because there are no font shadows?
16:25 Desour I also just took a look at label and chat
16:26 Desour the chat text in the statictext is reset at every frame. maybe that's the problem
16:27 sfan5 that shouldn't affect rendering performance
16:27 erlehmann sfan5 my C++ knowledge is limited, is calling a null pointer (that seems to be what it does) a segfault?
16:28 erlehmann i mean apparently minetest was able to do this twice before it segfaulted
16:28 erlehmann so i have no idea why it did not die after the first time
16:28 erlehmann prob because UB, anything can happen etc. pp.
16:29 sfan5 sounds like it's more of a theoretical issue then
16:29 sfan5 well not really but whatever
16:29 erlehmann yeah, more of a theoretical segfault here
16:29 erlehmann the process still exited with a status code indicating error
16:30 erlehmann shortly afterwards
16:30 Desour >sfan5> that shouldn't affect rendering performance
16:30 Desour but it is
16:30 erlehmann yeah measure measure measure
16:30 sfan5 Desour: how do you know
16:30 Desour I've just tested it by only updating every 10 frames, and it's fast
16:30 sfan5 okay that works
16:30 MTDiscord <josiah_wi> How are you debugging this? I'd be interested to give it a go. I have basic experience reading assembly in case that's necessary.
16:30 sfan5 but that's no different between freetype and no-freetype is it?
16:30 sfan5 not*
16:31 pgimeno erlehmann: calling a member function of an object with value NULL is not necessarily a segfault, because the function is not necessarily stored as a pointer in the object
16:32 erlehmann Desour, could you explain to me what the string “)ae,jghdyblfkghdkyvhbldfbhyhdlfh,kvsjdfhykdjfb,kdsjbfjsdhbfkjdsbhf]” means in https://0x0.st/-x1i.lua ?
16:33 Desour erlehmann: it was some keyboard mash. but that line is commented out anyways
16:34 erlehmann ah
16:34 erlehmann i thought it was of significance
16:34 erlehmann (i saw it was commented out though)
16:34 erlehmann luatic where is your neat hack btw?
16:47 calcul0n joined #minetest-dev
16:55 Desour #11612
16:55 ShadowBot https://github.com/minetest/minetest/issues/11612 -- Fix performance of chat rendering by Desour
17:01 sfan5 does this also apply to the chat console?
17:02 Desour no
17:02 sfan5 the fix or the perf issue?
17:03 Desour both
17:04 erlehmann the chat console is the one that actually matters to me (and other players who get lagged by spammers) :/
17:04 erlehmann but good that something is better!
17:05 Desour to be clear, the chatconsole is the f10 thing, right?
17:05 erlehmann i have it bound on t
17:06 Desour it's kinda hard to see the fps through the text, but it's 60 for me, afaik
17:06 erlehmann ah
17:06 erlehmann neat
17:06 Desour maybe I'd need much more text to make it lag
17:06 sfan5 ok so here's the thing: I think the performance problem is not with rendering but if the clients does a lot it will delay rendering, thus reducting fps anyway
17:07 sfan5 for example all the word wrapping in StaticText::updateText
17:12 Desour even with 10000 medium long strings, the chatconsole doesn't get slow for me. (receiving the chat messages is very slow though)
17:15 Desour CGUIStaticText::breakText looks indeed pretty heavy
17:28 appguru joined #minetest-dev
18:11 fluxionary joined #minetest-dev
19:15 specing_ joined #minetest-dev
19:44 MTDiscord <luatic> erlehmann: I have already sent it?
19:44 MTDiscord <luatic> https://gist.github.com/appgurueu/37982038ce9b4791d452bd66d91c621c
19:48 longerstaff13 joined #minetest-dev
19:49 Pexin /6
19:55 rubenwardy erlehmann: I said it 's a good idea
20:00 erlehmann rubenwardy, what, removal of pixel font support?
20:00 erlehmann sorry very sleepy
20:00 erlehmann i read later and try to understand
20:02 rubenwardy sorry, my scroll was wrong
20:03 rubenwardy sfan5 did post in the IRC about removing bitmap font support, requiring freetype. I said that's a good idea
20:03 MTDiscord <luatic> yeah, I agreed on that
20:03 rubenwardy it reduces the complexity by not having different configurations
20:03 rubenwardy you can still have pixel fonts with TTF
20:03 MTDiscord <luatic> in particular because I want to do a TTF media PR
20:03 rubenwardy yeah, custom fonts would be nice
20:04 rubenwardy "my scroll was wrong" => meaning that I didn't realise how long the message was ago
20:04 rubenwardy "I said that's a good idea" => well, I at least thought that :D
20:11 fluxionary_ joined #minetest-dev
20:25 proller joined #minetest-dev
21:38 flux__ joined #minetest-dev
22:21 proller joined #minetest-dev
22:24 Extex joined #minetest-dev
23:19 calcul0n joined #minetest-dev
23:54 Alias2 joined #minetest-dev
23:54 Extex joined #minetest-dev

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