Minetest logo

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

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

All times shown according to UTC.

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

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