| 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 |
