Time Nick Message 06:44 erlehmann why is irrlichtmt not a git submodule? 06:45 MTDiscord 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 people just don't seem to like git submodules here 07:04 MTDiscord 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:50 MTDiscord 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 10:52 pgimeno 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 12:18 erlehmann can i speed up TGA addition in any way? 12:24 MTDiscord 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 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 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 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 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 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:37 sfan5 pushing http://sprunge.us/tESEe3?diff in a few minutes 12:38 erlehmann where is the PR? 12:39 MTDiscord 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 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 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 I feel like it should be converted only if/when it gets absorbed into the core repo 12:57 MTDiscord 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 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 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 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 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 yeah I meant git blame 13:16 MTDiscord 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 It might clobber git blame and that's all. 13:20 erlehmann thanks i hate it 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 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 I just tested compiling with ENABLE_FREETYPE=OFF, it crashes on startup. best would be requiring freetype at all times 14:17 MTDiscord 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 Same 14:17 MTDiscord 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 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 Except there wasnt silence on july 7 14:19 MTDiscord 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 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 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 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 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 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 unifont would be shipped as a ttf though? 14:24 MTDiscord 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 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 to be honest I can agree 14:26 sfan5 removing features is by definition not refactoring 14:26 MTDiscord 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 Has the screenshot thing been fixed yet? 14:26 MTDiscord That you can still choose unsupported formats? 14:26 MTDiscord 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 They can 14:28 MTDiscord I have a neat hack for this 14:28 MTDiscord 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 one moment, recording for you 14:28 MTDiscord 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 https://cdn.discordapp.com/attachments/747163566800633906/886620076772573194/2021-09-12_16-30-49.mp4 14:31 MTDiscord 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 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 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 erlehmann https://irc.minetest.net/minetest-dev/2021-07-07#i_5844876 14:56 erlehmann 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: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 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: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 ^ 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 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: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 19:44 MTDiscord erlehmann: I have already sent it? 19:44 MTDiscord https://gist.github.com/appgurueu/37982038ce9b4791d452bd66d91c621c 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 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 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