| Time |
Nick |
Message |
| 01:33 |
|
specing_ joined #minetest-dev |
| 04:00 |
|
MTDiscord joined #minetest-dev |
| 06:29 |
|
hlqkj joined #minetest-dev |
| 08:00 |
|
ShadowNinja joined #minetest-dev |
| 08:33 |
|
ssieb joined #minetest-dev |
| 09:11 |
|
calcul0n_ joined #minetest-dev |
| 09:18 |
|
proller joined #minetest-dev |
| 09:40 |
|
Fixer joined #minetest-dev |
| 10:30 |
|
Fixer_ joined #minetest-dev |
| 11:14 |
|
tech_exorcist joined #minetest-dev |
| 11:42 |
|
calcul0n__ joined #minetest-dev |
| 12:33 |
|
proller joined #minetest-dev |
| 13:32 |
|
specing_ joined #minetest-dev |
| 14:14 |
MTDiscord |
<appguru> Can we remove non-freetype support? |
| 14:17 |
sfan5 |
why |
| 14:17 |
sfan5 |
and yes |
| 14:30 |
|
don_flymoor joined #minetest-dev |
| 14:31 |
don_flymoor |
Hi! Does anyone know why I can see the inside of the player when using directx9? |
| 14:31 |
don_flymoor |
This only happens in 5.4.0 |
| 14:32 |
don_flymoor |
It completely blocks the screen. |
| 14:33 |
|
Fleckenstein joined #minetest-dev |
| 14:34 |
rubenwardy |
It adds more cases to support |
| 14:34 |
rubenwardy |
We have freetype and nonfreetype text boxes or something iirc |
| 14:35 |
don_flymoor |
I don't understand what you mean |
| 14:36 |
|
Kimapr joined #minetest-dev |
| 14:38 |
don_flymoor |
Does using directx9 disable backface culling? |
| 14:40 |
rubenwardy |
I'm not responding to yoy |
| 14:42 |
MTDiscord |
<appguru> sfan5: I was looking into font media, which I'd do using .ttf files, which requires freetype |
| 14:44 |
MTDiscord |
<IhrFussel> @don_flymoor there is already a github issue about your problem and I think the devs won't fix it as they don't offifially support directx |
| 14:45 |
don_flymoor |
Even if it's not officially supported, it glaring issues like this should be fixed, as directx is faster than opengl on windows. |
| 14:52 |
MTDiscord |
<Jordach> incorrect |
| 14:52 |
MTDiscord |
<Jordach> a real GPU or Intel iGPU are actually considerably better at OpenGL |
| 14:55 |
don_flymoor |
While true, Minetest is CPU bound, and at least on my pc, DirectX is faster because it uses less CPU than OpenGL. |
| 14:56 |
MTDiscord |
<Jordach> what |
| 14:56 |
MTDiscord |
<Jordach> if OpenGL had a bottleneck it wouldn't be used period |
| 14:56 |
don_flymoor |
Of course it has a bottleneck |
| 14:57 |
MTDiscord |
<Jordach> irrlicht's general implementation of the standard OGL library is a bit naff |
| 14:57 |
don_flymoor |
It seems to use draw calls more than DirectX |
| 14:57 |
don_flymoor |
I agree |
| 14:58 |
don_flymoor |
So: Why are we still using Irrlicht? |
| 14:58 |
MTDiscord |
<Jordach> i get zero GPU assistance as minetest does all mesh manipulation on CPU and is single threaded at that |
| 14:59 |
don_flymoor |
So why isn't Minetest multithreaded? That would make it a lot faster, and get rid of a lot of server lag. |
| 14:59 |
sfan5 |
"why isn't this glaring issue fixed?" "why are we still using irrlicht?" "why isn't minetest multithreaded?" |
| 14:59 |
MTDiscord |
<Jordach> it probably uses more draw calls as OpenGL has a much better depth buffer solution than DX that is also portable against macOS, Linux, BSD |
| 14:59 |
sfan5 |
who's gonna do it? |
| 15:00 |
MTDiscord |
<Jordach> also this |
| 15:01 |
sfan5 |
spending time to fix directx issues is also unwise as we're extremely likely to fully drop support in the upcoming 5.5.0 |
| 15:01 |
|
Fixer joined #minetest-dev |
| 15:02 |
don_flymoor |
Perhaps supporting Vulkan would be a good idea. Now that Minetest has their own version of Irrlicht, it would be more feasable. |
| 15:03 |
don_flymoor |
Of course, it's probably not going to happen |
| 15:03 |
MTDiscord |
<Jordach> are you suggesting us unpaid contributors are to implement a brand new rendering stage |
| 15:03 |
MTDiscord |
<Jordach> none of are named john carmack |
| 15:03 |
don_flymoor |
Yes |
| 15:03 |
sfan5 |
it's more realistic to fix up OpenGL usage to make it more performant |
| 15:04 |
rubenwardy |
don_flymoor: have you tried disabling shaders? |
| 15:04 |
don_flymoor |
Yes. No change in performance |
| 15:04 |
sfan5 |
our shaders don't work under directx anyway |
| 15:04 |
sfan5 |
oh this is in regard to performance |
| 15:04 |
sfan5 |
nvm then |
| 15:04 |
rubenwardy |
I meant on OpenGL, yeah |
| 15:06 |
don_flymoor |
The bottleneck seems to be meshmaking, so multithreading would theoretically improve performance more than anything else, |
| 15:06 |
sfan5 |
there is a thread dedicated to meshing |
| 15:07 |
sfan5 |
I think first someone knowlegeable should analyze rendering with one of those opengl profilers and see what's so inefficient |
| 15:07 |
Calinou |
RenderDoc time :) |
| 15:10 |
don_flymoor |
rendermap:drawmeshes(SOLID) and game:updateframe:drawscene are the slowest parts |
| 15:10 |
don_flymoor |
Yet my GPU is at 1/3 capacity |
| 15:11 |
don_flymoor |
And when I activate ReShade, the FPS stays the same. |
| 15:13 |
don_flymoor |
OpenGL and DirectX both suffer from this, but DirectX less so. |
| 15:16 |
don_flymoor |
How difficult would it be to port Minetest to a different rendering engine like Ogre? |
| 15:17 |
sfan5 |
very |
| 15:18 |
MTDiscord |
<Jonathon> there are some github issues where people suggested bgfx and in there are some of the issues |
| 15:19 |
don_flymoor |
I guess it isn't very feasible, without pretty much rewriting a lot of Minetest. |
| 15:32 |
|
don_flymoor joined #minetest-dev |
| 15:34 |
sfan5 |
>minetest_2021.03.29_15.32.35_frame3155.rdc loaded. Capture has 210 issues. 210 Unread. |
| 15:34 |
sfan5 |
I guess this is a good sign |
| 15:40 |
|
rubenwardy joined #minetest-dev |
| 15:41 |
|
tech_exorcist joined #minetest-dev |
| 15:44 |
sfan5 |
okay turns out the OpenGL Irrlicht uses is way too legacy so RenderDoc can't be of help |
| 15:44 |
don_flymoor |
Minetest tells me it's using OpenGL 4.6.0 |
| 15:45 |
sfan5 |
that's what the GL context says it supports |
| 15:48 |
don_flymoor |
I wonder if we could use https://github.com/Devsh-Graphics-Programming/Nabla as the render engine. It promises Vulkan support, and is build off Irrlicht. |
| 15:48 |
don_flymoor |
Nabla (previously called IrrlichtBaW ) is a new renovated version of older Irrlicht engine. The name change to Nabla allows for using Nabla side by side with the legacy Irrlicht and IrrlichtBaW engines. The project currently aims for a thread-able and Vulkan-centered API, but currently works on OpenGL only. |
| 15:51 |
don_flymoor |
It it is a modified version of Irrlicht, it may be very easy to use it in Minetest. It might also be better, or at least faster. |
| 16:02 |
|
appguru joined #minetest-dev |
| 16:05 |
|
ircSparky joined #minetest-dev |
| 16:05 |
|
ircSparky joined #minetest-dev |
| 16:30 |
|
specing joined #minetest-dev |
| 16:33 |
don_flymoor |
I'm going to try building IrrlichtBAW and see if Minetest works with it. |
| 16:53 |
rubenwardy |
The GUI will break, and the API will have differences |
| 16:59 |
don_flymoor |
But it won't be very difficult to fix... I hope |
| 17:02 |
sfan5 |
this has been brought up before, irrlichtbaw has dropped all GUI stuff which we do use |
| 17:03 |
don_flymoor |
Could we change our GUI? |
| 17:03 |
sfan5 |
change it to what? |
| 17:03 |
don_flymoor |
Whaterver BAW uses |
| 17:03 |
sfan5 |
nothing AFAIK |
| 17:04 |
don_flymoor |
Build A World has a GUI |
| 17:09 |
don_flymoor |
I believe remaking the GUI would be worth it to get the performance from IrrlichtBAW |
| 17:09 |
MTDiscord |
<Benrob0329> It'd require another library, such as Nuklear or Dear ImGUI |
| 17:11 |
don_flymoor |
As far as I can see, implementing another GUI wouldn't be very difficult |
| 17:11 |
MTDiscord |
<josiah_wi> Is there anything I can do to help get my build PR to the new Irrlicht fork merged? |
| 17:15 |
sfan5 |
I think it'd help to see how the changes that'd be made to the engine should looks like |
| 17:15 |
sfan5 |
and maybe another coredev has an opinion on that |
| 17:17 |
MTDiscord |
<josiah_wi> I could PR an update to the engine at the same time. |
| 17:18 |
MTDiscord |
<josiah_wi> That might be kind of weird though because the engine can't actually use the change until it's been made here. |
| 17:39 |
appguru |
#11130 needs some attention - Minetest is finally getting depth sorting! |
| 17:39 |
ShadowBot |
https://github.com/minetest/minetest/issues/11130 -- Fix rendering of allfaces nodes with transparent textures by x2048 |
| 17:44 |
sfan5 |
merging #11084, #11124, #11126, #11132 in 10m |
| 17:44 |
ShadowBot |
https://github.com/minetest/minetest/issues/11084 -- Replace fallback font nonsense with automatic per-glyph fallback by sfan5 |
| 17:44 |
ShadowBot |
https://github.com/minetest/minetest/issues/11124 -- Add missing languages to settingtypes.txt by Emojigit |
| 17:44 |
ShadowBot |
https://github.com/minetest/minetest/issues/11126 -- Clean up various misleading and/or confusing messages and texts related to priv changes by Wuzzy2 |
| 17:44 |
ShadowBot |
https://github.com/minetest/minetest/issues/11132 -- Update CONTRIBUTING info on translating builtin by Wuzzy2 |
| 17:44 |
pgimeno |
wow, does that mean that water won't disappear when watched through glass? |
| 17:45 |
MTDiscord |
<appguru> Yes. |
| 17:45 |
appguru |
11130 is really impressive. |
| 17:49 |
sfan5 |
coincidentally I just looked at renderdoc (this time with GLES, that works) and wondered why Minetest draws the furthest mapblocks first, wasting effort |
| 17:50 |
pgimeno |
farthest first is painter's algorithm, right? |
| 17:50 |
sfan5 |
yes |
| 17:51 |
pgimeno |
it makes sense for drawing half-transparent stuff |
| 17:51 |
pgimeno |
not for fully opaque or fully transparent blocks |
| 17:53 |
sfan5 |
drawing opaque stuff with z buffer should work regardless shouldn't it? wonder why that wasn't done |
| 17:56 |
pgimeno |
for opaque geometry, drawing near stuff earlier improves performance, because shaders don't need to process pixels that are farther once the ones in front are drawn |
| 17:57 |
pgimeno |
it works either way, it's just more performant to draw from front to back |
| 17:58 |
sfan5 |
I know, but why aren't we doing that for opaque stuff? it looks like such an obvious optimization |
| 17:58 |
pgimeno |
*shrug* |
| 18:00 |
|
Fixer_ joined #minetest-dev |
| 18:09 |
appguru |
Well |
| 18:09 |
appguru |
You could first render all opaque stuff closest first |
| 18:09 |
|
kilbith joined #minetest-dev |
| 18:10 |
kilbith |
the chat messages are UTF-8, correct? |
| 18:10 |
|
numzero joined #minetest-dev |
| 18:10 |
kilbith |
I'm wondering if we could extend it to UTF-32 to support emojis |
| 18:11 |
sfan5 |
chat messages are unicode, usually stored in std::wstring |
| 18:11 |
sfan5 |
whether that is 16-bit chars or 32-bit chars depends on OS |
| 18:11 |
sfan5 |
network transfer uses utf-16 but I made surrogate escapes work before 5.4.0 recently |
| 18:11 |
sfan5 |
or in short: the only thing preventing emojis on a platform with 32-bit wchar is the right font |
| 18:12 |
sfan5 |
(emojis should be able to work on 16-bit wchar platforms too I'm just not so sure about that) |
| 18:15 |
MTDiscord |
<appguru> Strings are rarely stored using UTF-32 as that wastes much memory. |
| 18:15 |
appguru |
Which encoding is used doesn't matter however. UTF-8 and 16 support emojis just as fine. |
| 18:16 |
appguru |
Sticking with UTF-8 is preferrable, as that is the encoding used by Lua. |
| 18:24 |
|
proller joined #minetest-dev |
| 18:30 |
pgimeno |
Yeah, emojis are a question of font support, not of encoding. And colour emojis are a different beast. |
| 18:37 |
sfan5 |
appguru: lua doesn't deal with anything more than ascii |
| 18:38 |
appguru |
sfan5: that's wrong |
| 18:39 |
appguru |
newer Lua versions even ship with UTF-8 utility functions |
| 18:41 |
sfan5 |
as long as string.sub() does not operate on utf-8 I consider "lua strings are utf-8" to be a false statement |
| 18:41 |
sfan5 |
this is the case even with 5.4 |
| 18:42 |
appguru |
in most languages the substring method operates "char"-wise and not "rune"-wise |
| 18:42 |
appguru |
examples: Go, Java |
| 18:42 |
appguru |
those are UTF-16 though |
| 18:44 |
sfan5 |
that's a different kind of broken |
| 18:49 |
sfan5 |
"lua strings are byte strings and builtin functions operate on ASCII" is what I consider correct to be clear |
| 18:53 |
MTDiscord |
<appguru> more like Latin-1 |
| 18:54 |
appguru |
I don't really see the point though |
| 18:55 |
appguru |
Chat messages have to be passed to Lua. It is most convenient to have everything UTF-8 in Lua. |
| 18:55 |
appguru |
Sure, most builtin functions operate on strings like on a byte array, which fair, they are. |
| 18:55 |
sfan5 |
of course, I didn't say anything unlike that |
| 18:57 |
MTDiscord |
<Warr1024> People seem to like to use UTF-16 because the assumption that each character could be represented by 2 bytes survived longer than the assumption that each could be represented by 1, i.e. a lot of supposedly-UTF-16 things are actually UCS-2 ones. |
| 18:58 |
MTDiscord |
<Warr1024> Just query the string length of most emoji and you'll often get 2 characters, meaning that the string length function is just dividing byte count by 2 instead of actually walking the UTF-16 data. |
| 19:09 |
celeron55 |
utf-16 is the worst, people think it works when it's actually broken |
| 19:09 |
|
Fleckenstein joined #minetest-dev |
| 19:09 |
Krock |
UTF-32 will solve the world problems |
| 19:10 |
MTDiscord |
<Warr1024> UTF-16 might be the worst right now, but give them time and they'll think of something worse. I mean after we've got the UUID data type, and time zones are still a thing. |
| 19:11 |
celeron55 |
Krock: except that it's a waste of space if your use case is common languages |
| 19:11 |
Krock |
to Chinese people, Chinese is common. |
| 19:11 |
MTDiscord |
<Warr1024> UTF-32 will solve all of the world's problems exactly the same way UTF-16 did. |
| 19:12 |
MTDiscord |
<Warr1024> And then UTF-64, UTF-128, etc will subsequently... |
| 19:12 |
celeron55 |
Krock: don't most chinese characters fit in 2 bytes in utf-16? |
| 19:13 |
sfan5 |
I think they do |
| 19:13 |
sfan5 |
but if you're going for space savings you should really just use utf-8 |
| 19:13 |
celeron55 |
what i'm reading now says utf-8 generally needs 3 bytes for chinese characters |
| 19:13 |
sfan5 |
and if you need quick iteration / random access or something else go for utf-32 |
| 19:14 |
sfan5 |
hm that's true |
| 19:14 |
celeron55 |
i suppose utf-32 compressed using some very lightweight algorithm would be most idiot programmer proof, which is sad but could be a nice life hack |
| 19:14 |
MTDiscord |
<Warr1024> UTF-32 would make the problem go away for now but you'd effectively be punting it down the line. |
| 19:15 |
MTDiscord |
<Warr1024> i.e. the reason why you'd use UTF-32 in the first place is if you could pretend that you don't need to actually parse it and can just multiply stuff by 4 to calculate offsets |
| 19:15 |
MTDiscord |
<Warr1024> which is true ... for now, just as it once was for UTF-16. |
| 19:15 |
sfan5 |
if we define more than 4 billion(?) characters we have other problems |
| 19:15 |
celeron55 |
utf-32 will suffice for our lifetime |
| 19:15 |
celeron55 |
definitely |
| 19:15 |
MTDiscord |
<Warr1024> We already have the other problems. 4B+ characters is just one of the few we haven't tried having yet. |
| 19:17 |
MTDiscord |
<Warr1024> If the alternative is just playing a game of kicking the can farther down the road, might as well just use one of the UTF's we already have now, like UTF-8 or something. |
| 19:17 |
celeron55 |
current computers could barely hold a font to display all of the utf-32 character space |
| 19:17 |
celeron55 |
if it was the only task to do |
| 19:19 |
celeron55 |
and it would take you years to read all the characters, assuming you knew them all already |
| 19:19 |
celeron55 |
as a human |
| 19:19 |
celeron55 |
if one of each was displayed |
| 19:21 |
|
kilbith joined #minetest-dev |
| 19:23 |
MTDiscord |
<Benrob0329> ah yes, making fonts is now a monumental task if you want to have a decent amount of Unicode support |
| 19:32 |
|
Fleckenstein joined #minetest-dev |
| 19:36 |
|
ircSparky joined #minetest-dev |
| 19:36 |
|
ircSparky joined #minetest-dev |
| 19:45 |
sfan5 |
cppreference.com replaced its search with duckduckgo and it's pretty awful |
| 19:56 |
|
Kimapr joined #minetest-dev |
| 19:58 |
|
kilbith joined #minetest-dev |
| 20:01 |
|
Fleckenstein joined #minetest-dev |
| 20:11 |
sfan5 |
wonder why nobody has fixed #8662 yet, the problematic is identified and everythin |
| 20:11 |
ShadowBot |
https://github.com/minetest/minetest/issues/8662 -- TextArea output color is ignored after first line of text. |
| 20:11 |
sfan5 |
+g |
| 20:12 |
sfan5 |
problematic code* |
| 20:18 |
numzero |
utf-32 is limited to well below 4B characters (“code points” in Unicode terms) |
| 20:19 |
numzero |
because every code point has to be encodable in UTF-16 as well |
| 20:19 |
numzero |
whose surrogate pair can encode 20 bits only |
| 20:19 |
numzero |
thus limiting Unicode to 1M characters |
| 20:20 |
|
hlqkj joined #minetest-dev |
| 20:21 |
celeron55 |
that is a bit of a bummer really |
| 20:21 |
numzero |
also regarding Chinese characters, read a bit about so-called Han unification |
| 20:22 |
numzero |
which was needed to force Chinese and other languages into 16-bit encoding |
| 20:22 |
|
hlqkj_ joined #minetest-dev |
| 20:22 |
numzero |
while Japan alone has about of 65k ideographs ATM AFAIK |
| 20:23 |
numzero |
(“ATM” is important here, that number grows with time) |
| 20:27 |
celeron55 |
1M is less than i thought, i suppose we need a new encoding in our lifetime after all |
| 20:28 |
celeron55 |
if i go looking for a more future proof character encoding than utf-32 i suppose everyone will tell me i'm completely crazy |
| 20:30 |
pmp-p |
not crazy and that would probably be abstract language indepedant lexeme encoding |
| 20:30 |
numzero |
something like older (first draft, before cloning Unicode) ISO-10646? |
| 20:30 |
MTDiscord |
<Warr1024> We're used to thinking of unicode as a technical project but really it's as poltical as anything else, which means they aren't really all that strictly bound by sense. |
| 20:30 |
sfan5 |
for some reason Irrlicht uses about 400 triangles to draw a 16x16 inventory image |
| 20:30 |
sfan5 |
under GLES at least |
| 20:30 |
appguru |
Extrusion mesh |
| 20:30 |
numzero |
also there is the TRON project, they have own character set too AFAIK |
| 20:31 |
celeron55 |
i guess it'll be utf-8 anyway, with some crazy wasteful extension scheme in which the wastefulness will not matter in the slightest due to insane far future storage space and network bandwidth increases |
| 20:31 |
numzero |
know little about these though |
| 20:31 |
sfan5 |
(well not really 16x16, it's scaled and not all of the triangles are the same size) |
| 20:31 |
sfan5 |
appguru: that'd be stupid |
| 20:31 |
appguru |
yeah |
| 20:31 |
MTDiscord |
<Warr1024> It is kinda stupid |
| 20:31 |
Krock |
UTF-32 helpfully has enough space to contain the vomiting cowboy emoji. https://imgs.xkcd.com/comics/vomiting_emoji.png |
| 20:31 |
appguru |
but Minetest has fancy spinning thingies support |
| 20:31 |
appguru |
so I assume when that was added, people just got rid of plain old inventory image drawing |
| 20:31 |
numzero |
sfan5, Warr1024: that only means that IS likely to happen |
| 20:32 |
Krock |
s/help/hope/ |
| 20:32 |
MTDiscord |
<Warr1024> That and the fact that the 2D image scaling formerly used on inventory images was controversial |
| 20:32 |
numzero |
oops |
| 20:32 |
appguru |
The vomiting statue of liberty is more important. |
| 20:32 |
numzero |
answering to wrong question |
| 20:32 |
MTDiscord |
<Warr1024> and also because rendering nodes to 2D textures for drawing in the inventory used to be a fuster |
| 20:32 |
|
calcul0n joined #minetest-dev |
| 20:32 |
appguru |
well, nodes usually only have 12 tris |
| 20:32 |
MTDiscord |
<Warr1024> I want a vomiting middle finger emoji |
| 20:33 |
appguru |
we should really optimize extrusion meshes |
| 20:33 |
appguru |
it's pretty simple in fact |
| 20:33 |
MTDiscord |
<Warr1024> really really |
| 20:33 |
celeron55 |
let's make a blockchain character set, anyone can add any characters and it'll just grow and grow indefinitely with some mining cost |
| 20:33 |
sfan5 |
appguru: https://0x0.st/-bBv.png |
| 20:33 |
numzero |
Warr1024: tell the Unicode consortium, it codifies emojis |
| 20:33 |
appguru |
but C++ makes it hard |
| 20:33 |
MTDiscord |
<Warr1024> I'm sure members of the Unicode Consortium read xkcd |
| 20:34 |
sfan5 |
maybe this is irrlicht poorly attempting to emulate nearest neighbor scaling |
| 20:34 |
sfan5 |
but why? |
| 20:34 |
MTDiscord |
<Warr1024> I think if we were to optimize extrude meshes for specific transparency masks, at least, then it would improve render performance for NodeCore, possibly significantly in some areas. |
| 20:34 |
celeron55 |
sfan5: nearest neighbor scaling isn't supported by the backend? |
| 20:34 |
celeron55 |
i can imagine that for gles1, maybe not for 2 |
| 20:34 |
appguru |
we've got drawImageFilteredScaled or what it's called |
| 20:35 |
appguru |
but this is probably not relevant here |
| 20:35 |
Krock |
extrusion mesh optimizations? slap one front face and back face to it, then add the vertices on transparent borders |
| 20:35 |
appguru |
that's the point |
| 20:35 |
MTDiscord |
<Warr1024> Probably the reason for extrude meshes in inventory is a combination of the rotation thing, and that mixing 2D images and 3D models in the HUD or formspecs is probably too much of a pain. |
| 20:35 |
sfan5 |
side fun fact: guiFormSpecMenu.cpp is 135 KB |
| 20:35 |
Krock |
and only borders, rather than front&back |
| 20:35 |
appguru |
currently there's unnecessarily many border vertices |
| 20:36 |
MTDiscord |
<Warr1024> Extrude mesh optimization is good for more than just HUDs or Formspecs, though, it'd be a big boon for ents. |
| 20:36 |
numzero |
remember #6803 |
| 20:36 |
ShadowBot |
https://github.com/minetest/minetest/issues/6803 -- Optimize wieldmesh by numberZero |
| 20:36 |
appguru |
well, complex generation of front and back would fix one of warr's bugs |
| 20:36 |
|
Fleckenstein joined #minetest-dev |
| 20:36 |
sfan5 |
celeron55: from a quick google gles2+ should definitely do GL_NEAREST |
| 20:37 |
MTDiscord |
<Warr1024> IIRC there have been attempts to use a single face for the front/back but it's caused problems with texture filtering before. |
| 20:37 |
appguru |
^ |
| 20:38 |
appguru |
numzero: #6803 looks fine - could you however cache the same normals, texcoords and vertices for all extrusion meshes of same size (say 16x16) and then just cache the different indices (omission of some border tris)? |
| 20:38 |
ShadowBot |
https://github.com/minetest/minetest/issues/6803 -- Optimize wieldmesh by numberZero |
| 20:38 |
sfan5 |
https://github.com/minetest/minetest/blob/master/src/client/hud.cpp#L949 |
| 20:38 |
sfan5 |
mystery solved |
| 20:38 |
sfan5 |
appguru was right, it uses the extrusion mesh |
| 20:38 |
sfan5 |
who writes all this stupid code and more importantly who reviews it.. |
| 20:39 |
MTDiscord |
<Warr1024> probably whoever added the rotation feature |
| 20:39 |
numzero |
appguru: um, well, I could |
| 20:39 |
numzero |
for everything not too large (128² at most probably) |
| 20:39 |
appguru |
Seeing as you already invested quite some work, albeit a few years back, could you basically redo that PR? |
| 20:39 |
rubenwardy |
It would have been RBA when spinning slots were added |
| 20:40 |
numzero |
make yet another PR that won’t ever be merged? |
| 20:41 |
MTDiscord |
<appguru> ¯_(ツ)_/¯ |
| 20:42 |
MTDiscord |
<Warr1024> HEh, yeah, LMD, I think maybe the torch has been passed to you now :-) |
| 20:42 |
celeron55 |
#6067 |
| 20:42 |
ShadowBot |
https://github.com/minetest/minetest/issues/6067 -- [CSM] Add basic HUD manipulation. by red-001 |
| 20:43 |
appguru |
Well, I don't really want it |
| 20:43 |
celeron55 |
sfan5: interesting, this was added as a PR |
| 20:43 |
appguru |
I'd be a lot less efficient than numzero |
| 20:44 |
sfan5 |
it doesn't matter if you inefficiently produce efficient code ;) |
| 20:44 |
celeron55 |
with simultaneous changes and a move of the hud.cpp file making the automatic github diff not really work |
| 20:44 |
celeron55 |
so probably nobody really even checked it |
| 20:45 |
celeron55 |
wait |
| 20:45 |
celeron55 |
this is just the move |
| 20:47 |
appguru |
Is there any way you can hit yourself with a regular Minetest client? |
| 20:47 |
appguru |
I'm considering making an anticheat PR for that |
| 20:47 |
appguru |
Because while it can be caught at mod level, it shouldn't have to be |
| 20:48 |
sfan5 |
that's more anti-things-that-shouldn't-happen and not anticheat, but good idea |
| 20:48 |
appguru |
Well, this is used as a cheat |
| 20:48 |
appguru |
For example medics in Capture The Flag healing themselves... |
| 20:49 |
MTDiscord |
<oneplustwo> relevant issue: https://github.com/MT-CTF/capturetheflag/issues/756 |
| 20:49 |
celeron55 |
6cd2b3b445bf558fda1e5a7908adef8e3a45449a |
| 20:49 |
sfan5 |
https://github.com/minetest/minetest/commit/6cd2b3b445bf558fda1e5a7908adef8e3a45449a |
| 20:49 |
celeron55 |
that's the RBA commit doing this |
| 20:50 |
sfan5 |
yea as suspected |
| 20:51 |
appguru |
Should I compare player and hitter by name? |
| 20:51 |
celeron55 |
https://irc.minetest.net/minetest-dev/2016-02-07#i_4526594 |
| 20:51 |
celeron55 |
https://github.com/minetest/minetest/pull/3610 |
| 20:52 |
celeron55 |
lol |
| 20:53 |
celeron55 |
even sfan5 said "Very nice", and paramat tested "no FPS drop" |
| 20:53 |
celeron55 |
so it was reviewed to today's standard |
| 20:53 |
celeron55 |
somehow it's still what it is |
| 20:53 |
appguru |
well of course no FPS drop with 16x16 textures |
| 20:53 |
appguru |
RIP 1024x1024 |
| 20:54 |
appguru |
That's more than two million tris |
| 20:54 |
appguru |
per item, that is |
| 20:54 |
|
calcul0n joined #minetest-dev |
| 20:54 |
MTDiscord |
<Benrob0329> At very high resolutions, is it cheaper to just layer planes on top of each other and fake the effect? |
| 20:54 |
appguru |
should not be done |
| 20:55 |
appguru |
well now that I think of it |
| 20:55 |
appguru |
well no |
| 20:55 |
appguru |
now that we got object shading, edges will look weird |
| 20:57 |
appguru |
can I rely on the fact that the pointers will be equal if puncher and hitter are equal? |
| 20:58 |
sfan5 |
of what object? |
| 20:58 |
sfan5 |
I can think of an easier way already: compare the ids of active objects |
| 21:04 |
|
T4im joined #minetest-dev |
| 21:07 |
appguru |
#11137 |
| 21:07 |
ShadowBot |
https://github.com/minetest/minetest/issues/11137 -- Detect interacting with yourself by appgurueu |
| 21:08 |
sfan5 |
https://0x0.st/-bBh.png now that's better |
| 21:15 |
Krock |
is that a security issue after all? |
| 21:15 |
|
T4im joined #minetest-dev |
| 21:15 |
Krock |
side-note: I observed this possibility in a 0.5.0-dev update where the GenericCAO message format changed. on failure, the entity would just follow the actual player |
| 21:15 |
Krock |
by a delay of one server tick |
| 21:16 |
Krock |
but well, that's an exotic case |
| 21:20 |
sfan5 |
hm does devtest have any colorized items for testing? probably |
| 21:23 |
appguru |
sfan5: fixed |
| 21:27 |
sfan5 |
devtest has exactly zero items that are colorized |
| 21:27 |
sfan5 |
(but a few nodes) |
| 21:28 |
sfan5 |
wait nvm |
| 21:30 |
sfan5 |
ah no it really has none |
| 21:40 |
|
T4im joined #minetest-dev |
| 21:46 |
|
Wuzzy joined #minetest-dev |
| 22:14 |
sfan5 |
merging #11067, #7840 in 10m |
| 22:14 |
ShadowBot |
https://github.com/minetest/minetest/issues/11067 -- Fix wield image of plantlike_rooted by Wuzzy2 |
| 22:14 |
ShadowBot |
https://github.com/minetest/minetest/issues/7840 -- Degrotate support for mesh nodes by numberZero |
| 22:16 |
|
proller joined #minetest-dev |
| 22:23 |
Pexin |
question about the new font fallback stuff: will fallback glyphs be guaranteed to have the same dimensions as the main chat output monospace font? ..or is that a dumb question? |
| 22:24 |
sfan5 |
the font engine will grab the fallback font at a matching size |
| 22:24 |
sfan5 |
but it will not be monospace or support bold/italic (this is not different than before) |
| 22:25 |
Pexin |
not be mono? |
| 22:25 |
Pexin |
i'm talking about the "t" and F10 console |
| 22:26 |
sfan5 |
yes |
| 22:26 |
sfan5 |
fallback glyphs there will not be monospaced |
| 22:26 |
Pexin |
maaan.. |
| 22:27 |
Pexin |
so that requires a total rewrite of the layout code |
| 22:27 |
sfan5 |
not at all, it should be easy to add this |
| 22:28 |
Pexin |
even though it currently uses the column number when constructing fragments? |
| 22:29 |
sfan5 |
I don't know the code of the chat console so I have no idea what you're referring to |
| 22:29 |
sfan5 |
since it already works for the non-fallback font now it logically can also work for the fallback font |
| 22:29 |
Pexin |
the T and F10 consoles rely on monospace font |
| 22:29 |
sfan5 |
(that difference is invisible to the chat console) |
| 22:30 |
sfan5 |
which usecase do you have anyway where fallback glyphs are used and monospace matters? (chinese characters are all the same width) |
| 22:30 |
Pexin |
romanic letters mixed with pictographs? |
| 22:31 |
Pexin |
the reason i'm curious is if the new font stuff makes #11092 obsolete |
| 22:31 |
ShadowBot |
https://github.com/minetest/minetest/issues/11092 -- Make chat web links clickable by pecksin |
| 22:32 |
sfan5 |
you mean for underlining and/or coloring links or something? |
| 22:32 |
Pexin |
but if that's the case, as i see it layout will need major restructure |
| 22:32 |
Pexin |
underlining is impossible currently |
| 22:33 |
Pexin |
but the mouse picking, and more importantly construction of text lines, does rely on monospace |
| 22:34 |
sfan5 |
you should use font->getDimension to determine the click targets for that |
| 22:39 |
Pexin |
that is already used to populate v2u32 GUIChatConsole.m_fontsize which is used to build the output |
| 22:40 |
sfan5 |
no I mean measure the size of the characters in the actual line with the link |
| 22:41 |
Pexin |
currently can't be done |
| 22:42 |
sfan5 |
then you do have a problem |
| 22:42 |
Pexin |
we all do ;) |
| 22:43 |
|
calcul0n_ joined #minetest-dev |
