| Time |
Nick |
Message |
| 00:00 |
MTDiscord |
<josiah_wi> 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 |
<josiah_wi> 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 |
<josiah_wi> We probably have list headers as sources. |
| 00:02 |
erlehmann |
what do you mean? |
| 00:02 |
MTDiscord |
<josiah_wi> 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 |
<josiah_wi> 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 |
<josiah_wi> 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:24 |
|
queria^clone joined #minetest-dev |
| 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:33 |
|
queria^clone joined #minetest-dev |
| 00:42 |
MTDiscord |
<Jonathon> i have the same issue, however its only on my newest hardware machine |
| 00:45 |
MTDiscord |
<Jonathon> ive only noticed it in singleplayer, but i dont test with server option that often |
| 00:52 |
|
Alias2 joined #minetest-dev |
| 01:20 |
|
specing_ joined #minetest-dev |
| 01:22 |
|
fluxionary joined #minetest-dev |
| 01:49 |
MTDiscord |
<MisterE> 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 |
<MisterE> https://forum.minetest.net/viewtopic.php?t=26194 |
| 01:52 |
MTDiscord |
<MisterE> 5.3, working, windows |
| 01:52 |
MTDiscord |
<MisterE> https://cdn.discordapp.com/attachments/747163566800633906/907447416226197564/screenshot_20211108_205122.png |
| 01:55 |
MTDiscord |
<MisterE> 5.5 dev, windows, not working |
| 01:55 |
MTDiscord |
<MisterE> https://cdn.discordapp.com/attachments/747163566800633906/907448329699491890/screenshot_20211108_205512.png |
| 01:56 |
MTDiscord |
<MisterE> as you can see, for models that dont work, only one texture is loaded |
| 01:56 |
MTDiscord |
<MisterE> the others are all either black or white |
| 01:56 |
MTDiscord |
<MisterE> as far as I can tell the issue has always been on linux (going from memory) |
| 01:58 |
|
olliy joined #minetest-dev |
| 03:09 |
|
MTDiscord1 joined #minetest-dev |
| 03:29 |
|
queria joined #minetest-dev |
| 03:33 |
|
queria joined #minetest-dev |
| 03:42 |
|
tekakutli joined #minetest-dev |
| 04:21 |
|
kilbith joined #minetest-dev |
| 04:45 |
|
v-rob joined #minetest-dev |
| 04:45 |
|
fluxionary joined #minetest-dev |
| 04:45 |
|
pi3 joined #minetest-dev |
| 04:45 |
|
Extex joined #minetest-dev |
| 05:00 |
|
MTDiscord joined #minetest-dev |
| 05:50 |
|
pi3 joined #minetest-dev |
| 06:49 |
|
tekakutli joined #minetest-dev |
| 06:54 |
|
fluxionary joined #minetest-dev |
| 07:04 |
|
v-rob joined #minetest-dev |
| 07:08 |
|
Extex joined #minetest-dev |
| 07:46 |
|
tekakutli joined #minetest-dev |
| 07:49 |
|
ivanbu joined #minetest-dev |
| 10:13 |
|
Fixer joined #minetest-dev |
| 11:08 |
|
olliy1or joined #minetest-dev |
| 11:10 |
|
olliy joined #minetest-dev |
| 11:40 |
|
tekakutli joined #minetest-dev |
| 12:43 |
|
calcul0n_ joined #minetest-dev |
| 13:01 |
|
kilbith joined #minetest-dev |
| 13:21 |
|
specing joined #minetest-dev |
| 13:25 |
|
tekakutli joined #minetest-dev |
| 13:37 |
MTDiscord |
<exe_virus> 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 joined #minetest-dev |
| 13:45 |
MTDiscord |
<exe_virus> I built with cmake |
| 13:45 |
MTDiscord |
<exe_virus> Using Gcc 11 |
| 13:45 |
MTDiscord |
<exe_virus> The binary is in /bin |
| 13:45 |
MTDiscord |
<exe_virus> Of the repo |
| 13:47 |
MTDiscord |
<exe_virus> With verbose I get the same results: Error: game specified is invalid, Error: minetest cannot continue without a valid font |
| 13:48 |
MTDiscord |
<exe_virus> Hurm, okay I didn't build with freetype, let me try that first |
| 13:49 |
MTDiscord |
<Sublayer plank> yeah compiling minetest without freetype has been broken for a while now |
| 13:50 |
MTDiscord |
<exe_virus> Gotcha, maybe list it as a full dep instead of optional? I'll make an issue for it sometime |
| 13:51 |
MTDiscord |
<Sublayer plank> it's an issue right now |
| 13:51 |
MTDiscord |
<Sublayer plank> on whether to make it required or whether bitmap fonts should be reimplemtned |
| 13:51 |
MTDiscord |
<exe_virus> Ah, why not both again? |
| 13:52 |
MTDiscord |
<exe_virus> We are an engine, seems odd to restrict the options of file types we can use |
| 13:53 |
MTDiscord |
<Sublayer plank> https://github.com/minetest/minetest/issues/11611 |
| 13:55 |
MTDiscord |
<Sublayer plank> well it'd be an additional maintenance burden |
| 13:55 |
MTDiscord |
<Sublayer plank> bitmap fonts were broken for the longest time before the code for it was removed from irrlichtmt |
| 13:56 |
MTDiscord |
<Sublayer plank> the issue and its discussion goes a bit more in detail about it |
| 14:04 |
MTDiscord |
<josiah_wi> Turning on -Werror in IrrlichtMt instantly surfaces a buffer overflow, if the error is correct. I haven't checked the code. |
| 14:06 |
|
appguru joined #minetest-dev |
| 14:14 |
sfan5 |
submit a pr ;) |
| 14:18 |
erlehmann |
<Sublayer plank> 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 |
<Jonathon> 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 |
|
kilbith joined #minetest-dev |
| 14:30 |
erlehmann |
breaking stuff accidentally is one thing, breaking it on purpose is another thing |
| 14:31 |
MTDiscord |
<Jonathon> hmm, sure, it just magically was removed |
| 14:31 |
erlehmann |
it was? sfan5 removed the xml parsing from irrlichtmt |
| 14:31 |
MTDiscord |
<Jonathon> 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 |
<Jonathon> 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 |
<Jonathon> 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 |
<Jonathon> 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 |
<Jonathon> erlehmann: or maybe read the last comment on the issue? |
| 14:36 |
kilbith |
sounds like a upstream (freetype) issue then |
| 14:36 |
MTDiscord |
<Jonathon> 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 |
<Jonathon> 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 |
<Sublayer plank> the TTF version of GNU unifont looks fine in minetest on linux but for some reason it looks worse on windows |
| 14:49 |
MTDiscord |
<Sublayer plank> 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 |
<Sublayer plank> 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 |
<Sublayer plank> oh so it is the DPI |
| 14:56 |
MTDiscord |
<Sublayer plank> anyways I realized it's because I have the screen scaling set to 125% on windows |
| 14:56 |
MTDiscord |
<Sublayer plank> 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 |
<Sublayer plank> 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 |
<josiah_wi> 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 |
<josiah_wi> 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 |
<josiah_wi> I usually assume no false positives but yikes, it seems like the allocator itself is broken or smth. |
| 15:07 |
MTDiscord |
<josiah_wi> It is a compile error. |
| 15:07 |
sfan5 |
link the code |
| 15:08 |
MTDiscord |
<josiah_wi> irrString.h line 937 |
| 15:09 |
MTDiscord |
<josiah_wi> 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 |
<josiah_wi> 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 |
<josiah_wi> 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 |
<erlehmann> 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:22 |
|
calcul0n joined #minetest-dev |
| 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 |
<josiah_wi> 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 |
<Jonathon> i think your the one more out of touch |
| 15:39 |
MTDiscord |
<Jonathon> 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 |
<josiah_wi> erlehmann, until there is a way to perform an incremental build I can not debug any CMake dependency bugs. |
| 15:41 |
MTDiscord |
<josiah_wi> Ninja is not recompiling anything now either. |
| 15:41 |
MTDiscord |
<josiah_wi> 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 |
<josiah_wi> 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 |
| 15:52 |
|
tekakutli joined #minetest-dev |
| 15:53 |
|
Extex joined #minetest-dev |
| 15:55 |
|
v-rob joined #minetest-dev |
| 15:57 |
|
tekakutli joined #minetest-dev |
| 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 |
<Jonathon> Font api is more about text for ents to display stuff |
| 16:07 |
MTDiscord |
<Jonathon> 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 |
<Jonathon> 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 |
|
fluxionary joined #minetest-dev |
| 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 |
<josiah_wi> 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 |
<Sublayer plank> 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 |
| 16:28 |
|
Fixer joined #minetest-dev |
| 16:43 |
|
KakeruKakadu joined #minetest-dev |
| 17:29 |
|
Noisytoot joined #minetest-dev |
| 17:32 |
|
v-rob joined #minetest-dev |
| 17:58 |
|
tekakutli joined #minetest-dev |
| 17:58 |
|
v-rob joined #minetest-dev |
| 18:23 |
MTDiscord |
<josiah_wi> 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 |
<sfan5> 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 |
<Sublayer plank> 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 |
<josiah_wi> 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 |
<josiah_wi> G++ thinks that CImage does not name a type. I think cmake3.5 or ccache is responsible for breaking something. |
| 19:09 |
MTDiscord |
<josiah_wi> 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 |
<josiah_wi> 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 |
<josiah_wi> I just built master branch with Ninja, so the generator is not at fault. |
| 19:17 |
erlehmann |
ah |
| 19:18 |
|
v-rob joined #minetest-dev |
| 19:27 |
MTDiscord |
<josiah_wi> Fixed. I deleted one too many closing brackets in CBlit.h |
| 19:30 |
|
Fleckenstein joined #minetest-dev |
| 20:17 |
|
loggingbot_ joined #minetest-dev |
| 20:17 |
|
Topic for #minetest-dev is now Minetest core development and maintenance. Chit-chat goes to #minetest. https://dev.minetest.net/ |
| 20:51 |
MTDiscord |
<josiah_wi> 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 |
<josiah_wi> 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. |
| 20:54 |
|
v-rob joined #minetest-dev |
| 21:12 |
|
x2048 joined #minetest-dev |
| 21:17 |
sfan5 |
wow what Irrlicht 1.8.5 was released last monday |
| 21:17 |
sfan5 |
just bugfixes, but still |
| 21:20 |
MTDiscord |
<josiah_wi> 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:25 |
|
v-rob joined #minetest-dev |
| 21:45 |
MTDiscord |
<exe_virus> On the subject of bitmap fonts, ttf pixel fonts absolutely exist: https://www.fontsquirrel.com/fonts/list/classification/pixel |
| 22:15 |
|
v-rob joined #minetest-dev |
| 22:19 |
|
appguru joined #minetest-dev |
| 23:12 |
|
clavii joined #minetest-dev |
| 23:38 |
|
appguru joined #minetest-dev |
| 23:57 |
|
v-rob joined #minetest-dev |
| 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 |
