Time |
Nick |
Message |
00:14 |
|
AliasAlreadyTake joined #minetest-dev |
00:33 |
|
tekakutli joined #minetest-dev |
01:54 |
|
v-rob joined #minetest-dev |
01:54 |
|
olliy joined #minetest-dev |
02:26 |
|
v-rob joined #minetest-dev |
02:28 |
|
olliy joined #minetest-dev |
04:08 |
|
v-rob joined #minetest-dev |
05:00 |
|
MTDiscord joined #minetest-dev |
06:08 |
|
MTDiscord1 joined #minetest-dev |
06:18 |
|
Fleckenstein joined #minetest-dev |
06:42 |
|
v-rob joined #minetest-dev |
07:29 |
|
calcul0n joined #minetest-dev |
08:51 |
|
v-rob joined #minetest-dev |
09:05 |
|
queria joined #minetest-dev |
09:48 |
|
tekakutli joined #minetest-dev |
10:35 |
|
HuguesRoss joined #minetest-dev |
10:51 |
|
troller joined #minetest-dev |
12:33 |
|
proller joined #minetest-dev |
13:21 |
|
tekakutli joined #minetest-dev |
14:32 |
|
HuguesRoss joined #minetest-dev |
14:40 |
|
asdflkj_sh joined #minetest-dev |
15:28 |
|
Fixer joined #minetest-dev |
15:53 |
|
v-rob joined #minetest-dev |
15:56 |
|
tekakutli joined #minetest-dev |
16:13 |
|
v-rob joined #minetest-dev |
16:20 |
|
Taoki joined #minetest-dev |
17:12 |
|
v-rob joined #minetest-dev |
17:51 |
|
appguru joined #minetest-dev |
18:22 |
|
tekakutli joined #minetest-dev |
18:37 |
|
proller joined #minetest-dev |
18:52 |
|
v-rob joined #minetest-dev |
18:54 |
erlehmann |
i have just tried some irrlicht examples to figure some stuff out. can someone explain to me why irrlicht has particles and shadows that seem fast even on my thinkpad, yet minetest itself is a lagfest even with highly capable hardware? |
18:57 |
MTDiscord |
<Sublayer plank> minetest particles and shadows aren't using the irrlicht implementations, for better or for worse ¯_(ツ)_/¯ |
18:57 |
erlehmann |
for far worse, i'd say |
18:57 |
erlehmann |
class Particle : public scene::ISceneNode |
18:58 |
erlehmann |
oof |
19:01 |
erlehmann |
subplayer plank, i was a bit surprised that can get realtime shadows with openGL 1.4 on an old thinkpad. or tons of particles. but i guess computers are fast and minetest is doing something cursed. do you know whom i could ask about this? |
19:01 |
MTDiscord |
<fatalerror420> That feeling when you get better performance on black mesa on max settings |
19:02 |
sfan5 |
there is nothing cursed about it, stencil shadows are just out of fashion |
19:03 |
erlehmann |
nah but take the particles. each particle is a scene node? that seems a bit odd. |
19:05 |
erlehmann |
also … the minetest shadows look *really* bad in comparison to what irrlicht can do. i really wonder what i am missing. |
19:05 |
erlehmann |
like there must be a reason why it was not used if it is readily in the engine. |
19:05 |
erlehmann |
lying around |
19:06 |
MTDiscord |
<fatalerror420> That'd be a booold assumption |
19:07 |
erlehmann |
ok so my understanding right now is that particles in minetest are scene nodes, meaning if i see a lot of them ther are a lot of tiny drawcalls, slowing the thing down immensely. |
19:07 |
erlehmann |
but they can be batched. |
19:08 |
erlehmann |
i'll look in the forums |
19:11 |
|
proller joined #minetest-dev |
19:20 |
nrz |
Ayana joins |
19:45 |
Pexin |
erlehmann et al: concerning particles: I'm sure this is not news, but when our server does new years fireworks, it ends up lagging "something" so badly that chat messages take literally 20 minutes to show on the client |
19:46 |
erlehmann |
Pexin that should only happen if you manage to do a thing like simulate each particle separately, like mcl2 weather does |
19:47 |
erlehmann |
or, well, no idea what you do |
19:47 |
erlehmann |
i takeit back |
19:47 |
Pexin |
we think it has to do with network queueing |
19:48 |
erlehmann |
i can help you debug it, but not now. you can use this script on the client: https://git.minetest.land/Mineclonia/Mineclonia/src/branch/master/tools/analyze-packet-spam |
19:48 |
erlehmann |
regardless, what i'm saying is that particles being separate scene nodes seems to be like the absolute worst way to implement them |
19:48 |
erlehmann |
as if you have 10k particles, you have 10k scene nodes |
19:48 |
erlehmann |
they need to be batched |
19:57 |
|
tekakutli joined #minetest-dev |
20:20 |
rubenwardy |
erlehmann: Minetest uses a custom particle implementation where each particle is rendered individually |
20:20 |
rubenwardy |
this is a known issue |
20:27 |
erlehmann |
yeah but why |
20:28 |
erlehmann |
i see no advantage |
20:28 |
erlehmann |
are particles hard to batch? |
20:48 |
|
v-rob joined #minetest-dev |
20:57 |
rubenwardy |
erlehmann: it's just a dumb implementation |
20:57 |
rubenwardy |
it needs to be replaced |
21:00 |
erlehmann |
yeah, i literally could not find a slower way to do this haha |
21:09 |
|
appguru joined #minetest-dev |
21:35 |
|
v-rob joined #minetest-dev |
21:35 |
|
Calinou joined #minetest-dev |
21:46 |
HuguesRoss |
Merging #11969 in 15min |
21:46 |
ShadowBot |
https://github.com/minetest/minetest/issues/11969 -- Use absolute value for bouncy in collision by pecksin |
22:37 |
|
v-rob joined #minetest-dev |
22:46 |
v-rob |
Funny thing: You'd expect the hardest part about implementing Unicode would be figuring out how to use all the different parts. However, I've discovered that the hardest part is actually organizing all the individual parts so it works together in a clean manner without forcing the user of the code to jump through hoops. I've got to rethink part of my API yet again... |
22:46 |
v-rob |
I'm starting to think a clean organization is almost impossible. There's so much interdependency. |
22:47 |
erlehmann |
v-rob API, as in … what? |
22:48 |
erlehmann |
like what are ppl going to do |
22:48 |
erlehmann |
or want to do |
22:49 |
v-rob |
As in, the class that handles anything Unicode. The thing that allows you to iterate through language-specific characters and words, comparisons and searches, bidirectionality, shaping, etc. The whole lot. |
22:49 |
v-rob |
There's simply so much to integrate |
22:50 |
erlehmann |
well how much of that do people actually *need* though |
22:50 |
erlehmann |
i mean i guess, if you're doing it, better do all of it |
22:50 |
v-rob |
Everything I'm adding is basically necessary. You could probably do without comparisons and searching, but they're useful and not problematic. |
22:51 |
erlehmann |
i see |
22:51 |
v-rob |
There are lots of things I could add that aren't necessary, but I'm intentionally avoiding all of that. |
22:52 |
rubenwardy |
are you talking about C++ or Lua APIs? |
22:52 |
v-rob |
C++ |
22:52 |
rubenwardy |
thought so |
22:52 |
v-rob |
Lua would just be a reflection of C++ |
22:52 |
rubenwardy |
for Lua, it would be worth being API compatible with the unicode stuff in later Lua versions |
22:53 |
v-rob |
The UTF-8 code you mean? Probably |
22:53 |
rubenwardy |
Lua should also be UTF-8 only |
22:53 |
v-rob |
That's somewhat difficult. ICU cares very... strongly about using UTF-16 for most things. |
22:53 |
rubenwardy |
ICU? |
22:54 |
v-rob |
That's the library doing all the heavy Unicode work for me |
22:54 |
rubenwardy |
Ah. Well, you can convert from UTF-8 to UTF-16 in the Lua API |
22:54 |
v-rob |
No ICU = no full Unicode for Minetest :) |
22:55 |
v-rob |
Anyway, I'll worry about that after the C++ is done and works properly |
22:56 |
v-rob |
Some things are super annoying, though. Bidirectionality wants line breaking, line breaking requires shaping, and shaping requires bidirectionality to be applied first. Oof. I think Unicode is mainly a "best guess" really. |
22:56 |
erlehmann |
writing is messy |
22:57 |
v-rob |
I mean, if major web browsers differ in how weird Unicode situations are rendered, I think it can reasonably be said that much of it is up to interpretation. |
22:57 |
v-rob |
So Minetest will be "good enough" |
22:58 |
erlehmann |
i for one am looking forward to having dozens of combining characters in chat ^^ |
22:59 |
erlehmann |
v-rob do you think unifont should be included in minetest? (i do, but i am a bit biased) |
22:59 |
v-rob |
I'm glad I have someone who will break everything for me |
23:00 |
v-rob |
Unifont's pretty good looking, but I'm rooting for server-sent fonts so fonts can match the game. |
23:01 |
v-rob |
Certainly, it's viable now considering the font divisibility feature |
23:01 |
|
proller joined #minetest-dev |
23:01 |
erlehmann |
there needs to be a baseline |
23:01 |
v-rob |
Honestly, it might make more sense to make fonts server-sent, but also able to be part of texture packs. |
23:01 |
v-rob |
That would make them like all other types of media |
23:01 |
erlehmann |
there *still* needs to be a baseline, because fonts are HUGE |
23:02 |
rubenwardy |
that makes sense to me, especially when texture packs become media packs |
23:02 |
v-rob |
What do you mean by baseline? |
23:02 |
erlehmann |
well, having a font that works. |
23:02 |
erlehmann |
it can be overwritten by a game or sth |
23:02 |
rubenwardy |
by baseline, do you mean fallback? |
23:03 |
erlehmann |
but if i post STRAẞE, i do not want anyone to see STRA�E |
23:03 |
rubenwardy |
it makes sense for the engine to provide a fully capable fallback font |
23:03 |
v-rob |
As long as we have a fallback font always distributed with Minetest and proper font fallbacking when glyphs are missing from the preferred font, everything's good |
23:03 |
erlehmann |
yes fallback font |
23:03 |
erlehmann |
a surprising amount of computers have no current unicode fonts, but can do unicode |
23:04 |
v-rob |
I mean, if we wanted a "proper" fallback font, we'd use Noto Sans, which covers... everything. That's humongous, however. |
23:04 |
erlehmann |
i once installed unifont on an old nokia phone, instant emoji support hehe |
23:04 |
erlehmann |
uh no |
23:04 |
erlehmann |
it's giant |
23:04 |
erlehmann |
and ugly |
23:04 |
erlehmann |
and has wrong metrics |
23:05 |
erlehmann |
but yeah, it's humongous lol |
23:05 |
v-rob |
So we'd want something with full BMP support at least, though. I don't think our current fallback font covers that. |
23:06 |
erlehmann |
uh, astral plane is important |
23:08 |
v-rob |
The astral planes are literally everything else. |
23:48 |
|
v-rob joined #minetest-dev |
23:56 |
|
panwolfram joined #minetest-dev |