Time Nick Message 00:00 MTDiscord If it's all header files that's the bug. 00:00 erlehmann you might have already found a bug then 00:00 erlehmann i mean, if it does not rebuild, that would mean that whatever got introduced relied *entirely* on git updating the timestamps 00:00 erlehmann hat would be … unfortunate? 00:00 erlehmann i doubt it's that, it would be too broken lol 00:01 MTDiscord Yeah, unlikely. 00:01 erlehmann but here i can see the same, it barely builds anything 00:01 erlehmann then if i go back, it just rebuilds version.cpp lol 00:01 MTDiscord We probably have list headers as sources. 00:02 erlehmann what do you mean? 00:02 MTDiscord Wait, target includes ought to handle that. 00:02 erlehmann i mean something here obv does not track the source files 00:02 erlehmann so they are only *accidentally* rebuilt 00:02 erlehmann i mean used for a rebuild 00:04 MTDiscord Does make recompile only if timestamps differ? 00:05 erlehmann i believe make tracks timestamps, yes. but 00:05 erlehmann the hook sets the timestamps of each file to the latest commit that changes it 00:05 erlehmann so *if* the file is tracked by make and changed, then a rebuild should happen 00:05 sfan5 aren't you tricking make into wrongly not rebuilding then? if you're going back a commit 00:06 erlehmann i think what matters is just that the timestamp is different 00:07 erlehmann (than the one make remembers) 00:07 sfan5 but make does not remember any timestamps 00:07 erlehmann josiah_wi i believe what happens here is that all kinds of files are not tracked (obv), but when you touch *all* files you get almost a full rebuild, enough to make it work. 00:07 sfan5 https://stackoverflow.com/questions/7507355/how-does-make-track-timestamps#7507456 00:10 MTDiscord Can I work around this by using Ninja? 00:10 erlehmann sfan5 oh, that would completely explain why bisect is broken 00:10 erlehmann with incremental builds, that is 00:26 kilbith I often get this error when playing a world from mainmenu: ERROR[Main]: ServerError: AsyncErr: Failed to bind socket (port already in use?) 00:26 kilbith on Windows 00:27 kilbith doesn't happen on Linux 00:28 sfan5 I bet it would be useful if it printed the actual OS error 00:42 MTDiscord i have the same issue, however its only on my newest hardware machine 00:45 MTDiscord ive only noticed it in singleplayer, but i dont test with server option that often 01:49 MTDiscord sfan5 and others: I just confirmed that models with broken textures work on windows with minetest 5.3, but on windows with minetest 5.5 dev they do not work. Also on linux with 5.5dev they dont work. I am using liil's animalworld mod 01:49 MTDiscord https://forum.minetest.net/viewtopic.php?t=26194 01:52 MTDiscord 5.3, working, windows 01:52 MTDiscord https://cdn.discordapp.com/attachments/747163566800633906/907447416226197564/screenshot_20211108_205122.png 01:55 MTDiscord 5.5 dev, windows, not working 01:55 MTDiscord https://cdn.discordapp.com/attachments/747163566800633906/907448329699491890/screenshot_20211108_205512.png 01:56 MTDiscord as you can see, for models that dont work, only one texture is loaded 01:56 MTDiscord the others are all either black or white 01:56 MTDiscord as far as I can tell the issue has always been on linux (going from memory) 13:37 MTDiscord I'm using mingw on windows and msys2 for dependencies. I have mine test building but it can't find any of the games/fonts/supporting MT files. I tried run_in_place=true, and now I'm trying =false, but it fails to load saying it can't find any games or any fonts 13:40 sfan5 how did you build? where's the binary? and check with --verbose 13:45 MTDiscord I built with cmake 13:45 MTDiscord Using Gcc 11 13:45 MTDiscord The binary is in /bin 13:45 MTDiscord Of the repo 13:47 MTDiscord With verbose I get the same results: Error: game specified is invalid, Error: minetest cannot continue without a valid font 13:48 MTDiscord Hurm, okay I didn't build with freetype, let me try that first 13:49 MTDiscord yeah compiling minetest without freetype has been broken for a while now 13:50 MTDiscord Gotcha, maybe list it as a full dep instead of optional? I'll make an issue for it sometime 13:51 MTDiscord it's an issue right now 13:51 MTDiscord on whether to make it required or whether bitmap fonts should be reimplemtned 13:51 MTDiscord Ah, why not both again? 13:52 MTDiscord We are an engine, seems odd to restrict the options of file types we can use 13:53 MTDiscord https://github.com/minetest/minetest/issues/11611 13:55 MTDiscord well it'd be an additional maintenance burden 13:55 MTDiscord bitmap fonts were broken for the longest time before the code for it was removed from irrlichtmt 13:56 MTDiscord the issue and its discussion goes a bit more in detail about it 14:04 MTDiscord Turning on -Werror in IrrlichtMt instantly surfaces a buffer overflow, if the error is correct. I haven't checked the code. 14:14 sfan5 submit a pr ;) 14:18 erlehmann yeah compiling minetest without freetype has been broken for a while now 14:18 erlehmann are you sure this wasn't just sfan5 removing the xml, breaking the pixel fonts, leaving only freetype? 14:19 sfan5 both, it was broken for a while in the past and I broke it again recently 14:19 erlehmann well, i think you should unbreak it *before* you discuss how to “reimplement” 14:20 erlehmann like come on, first breaking stuff and then saying “ah just deprecate” if it is a “git revert” away … 14:20 erlehmann that's a bit underhanded 14:20 erlehmann i mean even if i agree with ppl about the merits of pixely renderers for freetype 14:20 erlehmann the way it is done is creating facts, then requiring a LOT of discussion to unbreak it 14:28 MTDiscord reimplement hasnt even been decided, and it would be a waste of time to do anything currently without deciding first what the path forwards would be 14:30 erlehmann Jonathon it was removed without a decision. 14:30 erlehmann breaking stuff accidentally is one thing, breaking it on purpose is another thing 14:31 MTDiscord hmm, sure, it just magically was removed 14:31 erlehmann it was? sfan5 removed the xml parsing from irrlichtmt 14:31 MTDiscord obviously there was a decision to remove it 14:31 erlehmann without xml parsing, it simply does not work 14:32 erlehmann oh, was there? i must have missed it. 14:32 erlehmann point me to the issue 14:32 kilbith what's the point of XML fonts 14:32 sfan5 what qualifies as "decision"? two people and written record? 14:33 erlehmann i think this is the “irrlichtmt operates by different rules than minetest” thing? 14:33 sfan5 but I'll say now that any time spent discussing the removal circumstances is wasted, reimplementing it would be easy but so far no sufficient reasons/support for that could be found 14:33 MTDiscord the point of xml fonts is to be broken at coloring. bold, italic, limited in characters, and generally be a pain for mod creators trying to use fonts for such things 14:33 erlehmann kilbith right now they seem to be the only way to get non-blurry pixel fonts 14:33 sfan5 (in other words time is better spent coming up with reasons to keep them) 14:34 erlehmann “the only way to get non-blurry pixel fonts” 14:34 erlehmann i actually *want* fonts without coloring 14:34 MTDiscord good for you 14:34 erlehmann sfan5, what about “non-blurry pixel fonts” is not a good reason? 14:35 sfan5 I thought the result of the discussion in the issue was that pixel fonts are equally feasible with TTF 14:35 erlehmann try it 14:35 MTDiscord also if where trying to merge irrlicht remains eventually into minetest, keeping arround 15k lines of code doesnt help 14:35 erlehmann the problem is someone would have to rasterize them differently 14:36 MTDiscord erlehmann: or maybe read the last comment on the issue? 14:36 kilbith sounds like a upstream (freetype) issue then 14:36 MTDiscord luacontroller picture if someone else has commented on it since i looked 14:37 erlehmann Jonathon the last comment about that it does not work in recent builds? it does not work bc it was broken on purpose? 14:37 erlehmann ah that 14:37 MTDiscord no idea why its so hard for you to see https://github.com/minetest/minetest/issues/11611#issuecomment-963015579 14:37 sfan5 erlehmann: https://0x0.st/-53R.png unifont-14.0.01.ttf 14:37 sfan5 good enough? 14:38 erlehmann sfan5, which font size? 14:38 sfan5 whatever the default is 14:38 sfan5 looks less good at 18 or 20 14:39 erlehmann 16 i guess? 14:40 erlehmann well, the gist of it: there are font sizes in which it is not blurry, obv. but the question *which* font size that is may depend on dpi, at least for stuff outside of minetest i know that pretty well. 14:40 erlehmann unless you specify pont size in px and not pt 14:41 erlehmann then i'll eat my words and apologize 14:41 erlehmann so you can't easily automatically make it not blurry as far as i know 14:41 sfan5 so it seems 14:41 erlehmann (don't believe that. i need a counter example to prove it though!) 14:42 erlehmann i remember i used to have a machine where 18pt (?) was the non-blurry unifont 14:42 erlehmann it was a bit weird 14:43 erlehmann oh okay, now this is funny. if i render an example with pango on the machine i am on, 12pt is the non-blurry unifont. wtf. 14:43 erlehmann let's see how minetest behaves though. maybe all is well. 14:45 erlehmann ok, at 16pt (mt default) this looks a) not blurry b) the same size as 12pt pango 14:45 erlehmann i'll experiment some more 14:49 MTDiscord the TTF version of GNU unifont looks fine in minetest on linux but for some reason it looks worse on windows 14:49 MTDiscord actually, might be DPI differences 14:50 erlehmann Sublayer plank did you try 12pt or 18pt to get it crisp? 14:50 erlehmann maybe it just looks blurry on windows at any size 14:53 erlehmann yep 14:53 MTDiscord it's the default(?) font size of 16 on both platforms. if I set the size a bit smaller on windows it looks better, but it's still a bit blurry 14:54 erlehmann it's not a platform thing though, i just reproduced it 14:54 erlehmann you can easily reproduce it on linux by using xrandr --output $OUTPUT --dpi $WHATEVER 14:56 MTDiscord oh so it is the DPI 14:56 MTDiscord anyways I realized it's because I have the screen scaling set to 125% on windows 14:56 MTDiscord change it to 100% and it looks crisp like in the linux vm 14:56 erlehmann ah lol 14:57 erlehmann the thing is, i am not against removing “png+xml pixel fonts”, i am against removing “easy way to get non-blurry pixel fonts” 14:57 erlehmann “use unifont and adjust the font size until it isn't blurry” isn't an improvement 15:00 erlehmann sfan5, Sublayer plank you have a 90dpi screen by any chance? 15:01 MTDiscord hmm where can I check? 15:01 sfan5 my dpi is exactly 96 15:02 sfan5 for minetest that means 16pt == 16px 15:02 MTDiscord Any devs here who like debugging overflows? Unless I'm missing something obvious this one is really messy to debug. 15:02 erlehmann sfan5, ah, must be rounding then 15:06 MTDiscord The code tries to reserve length+1 array slots and then, according to the warning, overflows writing into array[length]. 15:07 erlehmann josiah_wi have you compiled it with ubsan and executed it? that usually helps a lot! 15:07 MTDiscord I usually assume no false positives but yikes, it seems like the allocator itself is broken or smth. 15:07 MTDiscord It is a compile error. 15:07 sfan5 link the code 15:08 MTDiscord irrString.h line 937 15:09 MTDiscord If the string claims to have already allocated enough it will skip the reserve() request. But I don't know how to test that. 15:10 sfan5 could be that gcc is misunderstanding the allocator, it's static analysis after all 15:12 MTDiscord Could be. I'll have to think about how to prove it though... 15:14 erlehmann the allocator is actually bugged in another way too 15:14 erlehmann i mean irrAllocator.h line 47 15:14 erlehmann there's a bool 15:14 erlehmann but minetest loves to put small ints inside the bool 15:14 erlehmann with all the stupidity that results from it 15:14 erlehmann or irrlichtmt loves to do it 15:15 MTDiscord This is probably a can of worms. Maybe we shouldn't touch it lol. 15:15 erlehmann Jonathon https://github.com/minetest/minetest/issues/11611#issuecomment-964246854 15:15 erlehmann josiah_wi, if you leave out -WError it compiles, right? 15:17 erlehmann josiah_wi the problem with bools in C++ that are not 0 or 1 is that optimizers love to convert code, e.g. a function that takes an int i and a bool b and is returning i+1 if b is true and i otherwise, will be turned into returning i+1 every time. 15:18 sfan5 i mean irrAllocator.h line 47 15:18 sfan5 what's supposed to be wrong there? 15:18 erlehmann which is valid, bc having a bool that is not 0 or 1 is undefined behaviour, so a dev would not expect it to work at all 15:23 erlehmann sfan5 i can not reproduce it rn, but my guess would be that some template has uninitialized bool params that are used later? 15:23 erlehmann sfan5 so the bug is at the calling location ig, which ironically, i can not recall 15:23 erlehmann sfan5 i'll try to debug it when it happens the next time 15:24 erlehmann sfan5, so is this pic (and the dpi thing) enough to convince you that the freetype thing needs work before the pixel fonts can go the way of the dodo? https://mister-muffin.de/p/Y6F8.png 15:25 erlehmann i think it may be a bug in minetest/irrlicht btw 15:25 erlehmann but i may be wrong 15:25 sfan5 that depends on whether it's unifont's fault or a general issue 15:25 erlehmann no, it is a general issue 15:26 erlehmann basically, you only get crisp rasterization at specific pt, but those are different for each dpi 15:26 erlehmann and i think it is at least slightly unreasonable to have users work that out themselves when it doesn't have to be that way 15:26 erlehmann i mean, the crisp pixel font stuff can be removed later, when ttf stuff works equally well 15:27 erlehmann but rn it does not 15:27 sfan5 it's still a bit weird to spent effort implementing a feature that about 10 people use (probably accidentally), is no use for modders and whose only usecase requires users to do generate a font themselves 15:28 erlehmann uh, actually fleckenstein and the whole “exactly like minecraft” crowd are big into pixel fonts 15:28 erlehmann not that i agree with them 15:28 erlehmann i am more speaking from a contributor to unifont 15:28 erlehmann i.e. i do font things from time to time 15:28 erlehmann sfan5, characterizing a git revert as “effort implementing” is … well … a bit much :P 15:29 sfan5 XML support will not be added back 15:29 sfan5 so it is effort (even if small) adding an alternate format 15:29 erlehmann but why not? you could revert that deprecate it, improve the ttf thing, revert it again. 15:30 sfan5 xml is better if it stays gone 15:31 erlehmann probably. but right now: you broke it (granted, under the impression it does not matter), there is a solution to unbreak it. breaking it. then saying “oh but not THAT solution” kinda stalls it at “any other solution”? 15:32 sfan5 btw regarding the "pixel font crowd" they won't end up using the bitmap font support 15:32 erlehmann why 15:32 erlehmann don't say colors 15:32 erlehmann IMO there is no technical debt here, since removing it in the future once the ttf works, is easy. none of it creates a dependency on anything. even adding it back in and THEN discussing how to fix it would work. 15:33 sfan5 the usecase we have identified requires 1) users to build with -DENABLE_FREETYPE=0 2) generate a pixel font that Irrlicht can read manually 3) editing advanced settings to use this font 15:33 sfan5 on the entire earth fewer than 10 people will ever do this 15:33 erlehmann you always need to edit advanced settings to use this font?! 15:34 erlehmann like for every font change 15:34 erlehmann “requires 1) users to build with -DENABLE_FREETYPE=0” why that? 15:35 sfan5 I don't think you can disable that at runtime, not sure actually 15:35 erlehmann you can disable it, but any font changes will only apply on restart 15:36 erlehmann sfan5, i just tested it. the recompilation thing is bollocks, it works here. 15:37 MTDiscord sfan5, Minetest failed to link with -flto because of missing Zlib references. I just wanted to let you know so you'd be aware this is out there. 15:37 sfan5 I see, ignore point 1 15:38 erlehmann sfan5 i don't wish to insult you, but you *are* a bit out of touch with players. saying “only 10 ppl would use it” is a bit weird if you think about how often ppl asked for unifont as a default font. ppl LIKE pixel fonts. 15:38 erlehmann which isn't all that unexpected for a pixely game 15:39 erlehmann being out of touch is normal for devs btw. 15:39 erlehmann i think fleckenstein did not encounter a bunch of mcl2 bugs bc he always compiled with luajit or had enough ram and fast internet 15:39 MTDiscord i think your the one more out of touch 15:39 MTDiscord but ? 15:40 sfan5 I thought listing three (now two) conditions was pretty clear that I am not talking about pixel fonts in general 15:40 erlehmann Jonathon in a lot of discussions i represent the “don't pull numbers out of your ass” crowd 15:40 erlehmann sfan5, uh what do you mean then? changing fonts? 15:40 MTDiscord erlehmann, until there is a way to perform an incremental build I can not debug any CMake dependency bugs. 15:41 MTDiscord Ninja is not recompiling anything now either. 15:41 MTDiscord I got one incremental build error and it fixed itself on the second try. 15:41 erlehmann josiah_wi i have an idea. there exists a patch for ninja to use hashes instead of timestamps. 15:41 erlehmann yeah, the “make only builds stuff correctly every second invocation” is a funny bug. 15:41 erlehmann liberation circuit has it also, if you use cmake to build it instead of redo 15:42 sfan5 erlehmann: people love pixel fonts, yet I've never seen anyone use the bitmap font support for it 15:42 erlehmann the worst is when it happens when you edit code 15:43 MTDiscord I don't think the benefit of fixing this is worth the effort required to get the errors to occur. 15:44 sfan5 I bet a pixel font with the XML format irrlicht reads does not even exist 15:44 sfan5 crisp pixel fonts are the only usecase we identified for bitmap support yet nobody has ever attempted or does this 15:45 sfan5 that's what I'm pointing out 15:49 Calinou you can have crisp TTF fonts, it's harder but entirely possible if the engine allows for integer scaling 15:49 Calinou plenty of games have done that, I don't see why Minetest can't 15:49 Calinou of course, you need to use a suitable font file, but that's expected 16:02 erlehmann sfan5 what should i do exactly to convince you … point at irrlicht font maker discussions? or mention the font_api mod which is all about making crisp pixel fonts out of PNGs inside minetest? 16:07 MTDiscord Font api is more about text for ents to display stuff 16:07 MTDiscord Since minetest doesnt support text entities 16:07 erlehmann well it proves ppl want non-blurry fonts across a variety of platforms 16:07 MTDiscord No, it doesnt 16:07 erlehmann oh ok 16:10 sfan5 erlehmann: that was not supposed to be an argument against them, just mentioning why it feels weird to spend effort on 16:10 erlehmann well i see no *other* explanation for the various ttf to irrlicht font converters that exist … pixel fonts are only superior in being guranteed not blurry and easy to edit with existing tools. 16:10 erlehmann otherwise, ttf wins at everything 16:11 rubenwardy there should be a font option for integer scaling to allow for non-blurry pixel fonts 16:11 rubenwardy that would solve the issue, and it much easier that making irrlicht bitmap fonts work 16:11 sfan5 the explanation for those are easy, Irrlicht does not support TTF fonts so you have to convert them 16:12 erlehmann rubenwardy then why not 1. put the non-blurry font support back in 2. make the integer scaling work 3. rip the legacy code out ? 16:12 MTDiscord LTO works when erlehmann's post checkout script isn't active. So no big issue here in current master. 16:12 sfan5 of course Minetest supports TTF fonts because we imported someone else's code to make them work 16:13 erlehmann look i am just against the recurring cycle of “rip stuff out before the replacement is ready, then being dismissive about arguments why the replacement is actually missing sth” 16:14 erlehmann i don't care what version of unifont is used 16:14 erlehmann i edit it in ascii format anyway and then convert it 16:14 erlehmann to .hex, then to ttf/bdf whatever 16:17 erlehmann oh before i forget it. did you know minecraft texture packs are TGA lol. pretty obvious why *none* of the ripped textures are going to show up on contentdb. ;) 16:18 MTDiscord since when were minecraft textures in TGA format? 16:18 erlehmann it's a bedrock vs java edition thing i think 16:21 erlehmann Sublayer plank i think java edition uses png for stuff with alpha channel and bedrock uses TGA. no idea why. 16:21 sfan5 maybe they found out that tga is smaller ;) 16:22 erlehmann nah, i bet they didn't like having to uncompress stuff 16:22 erlehmann getting ARGB is just skippign the header and copying it 16:23 erlehmann or was it ABGR? or A1R5G5B5? no idea, i don't have it here 16:24 erlehmann i think only windows 10 users will have the problem with TGA probably 16:25 erlehmann oh no 16:25 erlehmann it's on android too 16:25 erlehmann well, whatever 16:26 erlehmann search youtube for Sheep.tga if you care 18:23 MTDiscord There are two "methods for software drivers" in CBlit.h (IrrlichtMt) that are unused functions. What would be the preferred way to fix the unused function warning? 18:25 sfan5 delete them 18:32 erlehmann the software drivers were deleted by sfan5 some time back 18:33 sfan5 wow always my fault 18:33 erlehmann (i think they were bugged anyway?) 18:33 sfan5 also no, it was hecks 18:34 erlehmann oh ok 18:34 erlehmann sorry 18:34 erlehmann wow always my fault 18:34 erlehmann more like i wanted to point out you might be the expert on software drivers, but i was wrong 18:35 erlehmann i should have checked 18:35 sfan5 well 18:35 sfan5 we don't need an expert on software drivers anymore because those are gone 18:35 erlehmann look, i should just have said “sfan5 says this bc the software drivers have gone the way of the dodo” 18:37 MTDiscord irrlicht's both software renderers were absolutely ridiculous. mesa's software driver is way better than either software or burningsvideo and also gives better performance 18:38 erlehmann i tried them and they were broken 19:06 MTDiscord I don't wish anyone any ill. I know sfan deleted the software drivers, but I did not want to delete those methods without a confirmation in case we kept them for some reason. 19:07 erlehmann nah, it's good that you asked! 19:09 MTDiscord G++ thinks that CImage does not name a type. I think cmake3.5 or ccache is responsible for breaking something. 19:09 MTDiscord Putting it out there in case someone knows about this. If not, I'm rebuilding anyway so it's not too important. 19:12 erlehmann josiah_wi what is the exact error message? 19:13 erlehmann josiah_wi you probably can get rid of that error by putting “typename” before the thing that errors 19:14 erlehmann or forward declare it or whatever. it sounds like some kind of thing like that. 19:15 erlehmann wait ignore everything i claim, i have no idea 19:16 MTDiscord Thank you for the suggestions, but if this were a real error IrrlichtMt master would be spewing fire on every CI build. 19:17 MTDiscord I just built master branch with Ninja, so the generator is not at fault. 19:17 erlehmann ah 19:27 MTDiscord Fixed. I deleted one too many closing brackets in CBlit.h 20:51 MTDiscord g++ thinks it is finding a specific case where a buffer overflow is guaranteed to occur, so I can write a unit test that can prove or disprove it. Strangely, reallocating the array right before setting the null terminator vanquishes the error. 20:52 MTDiscord I am not used to g++ being that stupid. Maybe it really is just going crazy, but now I'm so deep in it I really want to find out. 21:17 sfan5 wow what Irrlicht 1.8.5 was released last monday 21:17 sfan5 just bugfixes, but still 21:20 MTDiscord Can we get in touch with the devs? And are these bugfixes we can pull in? 21:21 sfan5 those are already in Irrlicht 1.9 so we have them already 21:45 MTDiscord On the subject of bitmap fonts, ttf pixel fonts absolutely exist: https://www.fontsquirrel.com/fonts/list/classification/pixel 23:58 kilbith sfan5: 1.9's master branch is still a bit ahead ogl-es branch tho 23:59 sfan5 yeah they renamed all _IRR_ symbols to IRR_, not gonna merge that 23:59 kilbith there is more than that 23:59 kilbith https://github.com/zaki/irrlicht/commit/53bc690a