| Time |
Nick |
Message |
| 00:09 |
|
Alias2 joined #minetest-dev |
| 00:22 |
erlehmann |
celeron55 why would it be slow to have a rendered image? i mean, you only have to render it *once*. prerendering all nodes sounds dumb though. |
| 00:23 |
erlehmann |
unless it is done in development. |
| 00:23 |
erlehmann |
but i don't get why an inventory scene should have to render more than one frame |
| 00:23 |
erlehmann |
it's not like there are any lighting changes for the nodes in inventory |
| 00:26 |
erlehmann |
the most cursed thing i have seen in that respect was imgui, some ghetto UI library where the author was proud of rerendering everything in every frame instead of, uh, tracking dirty rectangles or so. |
| 00:27 |
erlehmann |
regarding the inventory, so far i can place all of those nodes in the world and get barely any slowdown, but no idea really what it is. i'll try to bisect it i guess. with all the pain that entails. |
| 00:38 |
erlehmann |
has sprinting been removed from minetest? |
| 00:39 |
erlehmann |
btw who decided i can't go left or right while autoforwarding? it's really bad :( |
| 00:40 |
rubenwardy |
erlehmann: you then need to keep the image in memory |
| 00:40 |
rubenwardy |
GPUs work with meshes |
| 00:40 |
rubenwardy |
To render an image, they need to render a mesh with 4 vertices with a texture mapped onto it |
| 00:41 |
erlehmann |
so? |
| 00:41 |
erlehmann |
i mean it's certainly not too wasteful for the texture size of one inventory page |
| 00:42 |
rubenwardy |
Minetest originally rendered to texture and then to screen |
| 00:43 |
rubenwardy |
RBA changed it to just render the nodes, as he claimed it was faster |
| 00:43 |
rubenwardy |
In practice, ? |
| 00:44 |
erlehmann |
can you point me to a commit or PR? |
| 00:44 |
erlehmann |
because if that's the culprit, it would be ridiculous (i can see hundreds of nodes, and have 30fps, but an inventory page …) |
| 00:50 |
erlehmann |
btw, the x2048/alpha_blend_indexed branch has not lead to much slowdown so far. 20 to 30 fps in the woods. computer gets really hot though, no idea why. |
| 00:50 |
erlehmann |
oh and sprint works, my mistake. |
| 00:50 |
erlehmann |
but left/right was really disabled :( |
| 00:51 |
erlehmann |
(during autoforward) |
| 00:51 |
erlehmann |
makes boats kinda bad |
| 00:57 |
MTDiscord |
<Jonathon> https://github.com/minetest/minetest/issues/12048 already known |
| 00:59 |
erlehmann |
oh, i thought it was *on purpose* |
| 00:59 |
erlehmann |
sorry |
| 00:59 |
erlehmann |
thx |
| 01:59 |
|
v-rob joined #minetest-dev |
| 03:27 |
|
v-rob joined #minetest-dev |
| 05:00 |
|
MTDiscord joined #minetest-dev |
| 06:55 |
|
v-rob joined #minetest-dev |
| 07:12 |
|
calcul0n joined #minetest-dev |
| 08:10 |
sfan5 |
<erlehmann> twrightsman[m] given the unwillingness of mt devs to even upstream patches to irrlicht [...] |
| 08:10 |
sfan5 |
can you please stop pulling things out of your ass |
| 08:12 |
sfan5 |
Irrlicht has been unmoving since 5 or more years, various users have tried to upstream fixes with mixed success |
| 08:16 |
sfan5 |
besides: making the irrlicht devs aware of some of our fixes that are upstreamable is on my TODO list |
| 10:44 |
|
appguru joined #minetest-dev |
| 10:59 |
erlehmann |
sfan5 “unmoving” as in no new technical development? cutealien commits stuff from time to time, but releases seem super rare … |
| 11:00 |
erlehmann |
sfan5 i'll retract my assertions and want to apologize |
| 11:00 |
erlehmann |
sfan5 i had just looked at recent irrlicht history and that you had fixed some stuff that then never appeared in irrlicht proper |
| 11:22 |
|
calcul0n joined #minetest-dev |
| 11:23 |
|
proller joined #minetest-dev |
| 11:31 |
|
appguru joined #minetest-dev |
| 11:33 |
erlehmann |
twrightsman[m] regarding the upstream comment by sfan5, take note pls |
| 11:37 |
|
appguru1 joined #minetest-dev |
| 11:56 |
MTDiscord |
<Benrob0329> aren't we going to be absorbing Irrlicht at some point? |
| 11:58 |
proller |
why not urho3d or something alive? |
| 12:00 |
MTDiscord |
<Sublayer plank> urho3d looks to be way too much for minetest |
| 12:03 |
rubenwardy |
Hugues Ross: it's mildly confusing that you use "give it a pass" to mean give it a pass / look over, when it can be interpretted as pass on it |
| 12:13 |
|
HuguesRoss joined #minetest-dev |
| 12:15 |
erlehmann |
Benrob0329 fixes to irrlicht can and should still be upstreamed, regardless of roadmap. |
| 12:15 |
|
HuguesRoss joined #minetest-dev |
| 12:52 |
|
olliy joined #minetest-dev |
| 13:10 |
sfan5 |
well as soon as Irrlicht is absorbed many fixes stop being directly applicable |
| 13:12 |
erlehmann |
well, if you give me a list of commits that are, i can offer to travel to the wasteland that is sourceforge and leave the package on the ground in front of the appropriate mudhole |
| 13:13 |
erlehmann |
i mean existing ones, from the past. i wish i knew a better solution for the image loader fixes btw. |
| 13:13 |
erlehmann |
(where you limited the dimension) |
| 13:14 |
erlehmann |
btw, any idea why only the 0.4 gamma PNG texture seems so messed up? |
| 13:14 |
erlehmann |
gimp also has gamma bugs (or so it seems), but there every gradient looks different |
| 13:14 |
erlehmann |
with the lower values having darker gradients overall |
| 13:15 |
erlehmann |
(which is consistent with not just doing gamma i guess) |
| 13:32 |
|
appguru joined #minetest-dev |
| 14:08 |
MTDiscord |
<luatic> erlehmann: can you upgrade libpng? I sometimes get PNG warnings which seem to stem from using an outdated libpng version |
| 14:14 |
erlehmann |
luatic what kind of warnings are these? |
| 14:16 |
erlehmann |
luatic if it is “iCCP: known incorrect sRGB profile” then the thing is that *newer* libpng is stricter about checking this |
| 14:16 |
erlehmann |
and you need to fix the texture |
| 14:16 |
erlehmann |
and by “newer” i mean, like, this warning goes years back |
| 14:57 |
|
ronoaldo joined #minetest-dev |
| 14:57 |
ronoaldo |
Hi! I have a crash at my server that is hard to debug... something happened with either the map/mod/modstorage after a recent update of my mods. |
| 14:57 |
ronoaldo |
Server is crashing and producing a core dump file, which after a gdb bt shows this info: https://paste.debian.net/1231735/ |
| 14:59 |
ronoaldo |
Logs on verbose don't show exactly what is causing the crash, and don't show full warnings either. Logs on action shows these warnings: https://paste.debian.net/1231737/ (when I join, with the account ronoaldo,) |
| 15:00 |
ronoaldo |
it is happening only when I'm at a specific position... if I teleport to spawn and join the server, no crashes. If any player goes to a specific position, after a few seconds it crashes (perhaps when loading a problematic block from database?) |
| 15:00 |
ronoaldo |
any tips on debugging the issue to understand how to fix it would be apreciated. |
| 15:01 |
ronoaldo |
Error happens on both 5.4.1 and 5.5.0 |
| 15:05 |
|
tekakutli joined #minetest-dev |
| 15:06 |
|
proller joined #minetest-dev |
| 15:23 |
|
Fixer joined #minetest-dev |
| 15:55 |
|
v-rob joined #minetest-dev |
| 16:10 |
|
v-rob joined #minetest-dev |
| 16:36 |
sfan5 |
what's the abort message? neither the gdb backtrace nor the log files show it |
| 16:37 |
erlehmann |
sometimes minetest just gives up though, so maybe there is none? |
| 16:37 |
sfan5 |
it gets printed to stderr on crash so it might get lost if you don't have logging set up for that |
| 16:38 |
ronoaldo |
sfan5: it looks like an issue with Draconis mod update from 1.1 to 1.2; reverting that one fixed the crash. I'm probably not having the stderr output logged then! It does not go to debug.txt right? |
| 16:39 |
sfan5 |
correct |
| 16:39 |
ronoaldo |
perfect, this is useful to know, going to setup for the server! thank you! |
| 16:40 |
sfan5 |
if it's just for testing you can also start the server in a screen/tmux |
| 16:42 |
ronoaldo |
good point! |
| 17:11 |
|
v-rob joined #minetest-dev |
| 18:07 |
|
tekakutli joined #minetest-dev |
| 18:23 |
|
appguru joined #minetest-dev |
| 18:38 |
MTDiscord |
<luatic> @Based and Tax Fraud-pilled draconis has a bug |
| 18:39 |
rubenwardy |
...wrong channel |
| 18:47 |
MTDiscord |
<Jonathon> technically correct as it refers to above chat |
| 18:47 |
MTDiscord |
<Jonathon> *correct channel |
| 18:56 |
|
proller joined #minetest-dev |
| 19:10 |
|
proller joined #minetest-dev |
| 19:24 |
|
v-rob joined #minetest-dev |
| 19:28 |
|
v-rob joined #minetest-dev |
| 19:31 |
|
ROllerozxa joined #minetest-dev |
| 20:16 |
|
v-rob joined #minetest-dev |
| 20:44 |
|
olliy1or joined #minetest-dev |
| 21:13 |
|
tekakutli joined #minetest-dev |
| 21:31 |
|
v-rob joined #minetest-dev |
| 22:13 |
|
proller joined #minetest-dev |
| 22:28 |
MTDiscord |
<MisterE> I thought he was muted semipermanently |
| 22:28 |
MTDiscord |
<MisterE> So wouldn't be able to respond |
| 22:28 |
rubenwardy |
run-vcpkg is such a dumb plugin |
| 22:29 |
rubenwardy |
relying on these plugins for CI is a lock-in |
| 22:29 |
rubenwardy |
on GitLab, you can freely specify cache directories. So you'd make vcpkg a cache dir, and then call vcpkg directly |
| 22:31 |
|
proller joined #minetest-dev |
| 22:32 |
|
proller joined #minetest-dev |
| 22:32 |
MTDiscord |
<MisterE> Hey, devs, is there any plans for a ver. 3 of dynamic media that allows you to send temporary media that does not fill up the cache because it can be forgotten? So you could do things like live television (showing the viewpoint of a server-controlled playerbot or smth) |
| 22:32 |
MTDiscord |
<MisterE> That might be a bad ex |
| 22:32 |
MTDiscord |
<MisterE> Anyhow media that you want to send often and then forget it. |
| 22:33 |
sfan5 |
rubenwardy: you can do that with github actions (only builtin tools) too |
| 22:33 |
MTDiscord |
<MisterE> Live livesteam music maybe |
| 22:33 |
sfan5 |
that's also a bad example |
| 22:33 |
rubenwardy |
does it support cache dirs? |
| 22:34 |
sfan5 |
a list of dirs that you tell it to cache and it automatically restores? |
| 22:34 |
rubenwardy |
there's actions/cache |
| 22:35 |
sfan5 |
yes |
| 22:35 |
sfan5 |
but I still don't know what "cache dirs" means to you |
| 22:35 |
rubenwardy |
"This action allows caching dependencies and build outputs to improve workflow execution time." |
| 22:36 |
rubenwardy |
exactly this |
| 22:38 |
rubenwardy |
would you object to just using the old version of run-vcpkg that works |
| 22:39 |
sfan5 |
the new one doesn't? but I don't mind either way |
| 22:39 |
erlehmann |
MisterE i do not know how often you want to update your live television, but given that you can lag out players with hud updates, i think you should *probably* figure out if you really want that. |
| 22:39 |
rubenwardy |
in order to use vcpkg triplets, the new version requires changing cmake and running vcpkg from cmake |
| 22:40 |
MTDiscord |
<MisterE> every 1/4 sec would be nice |
| 22:40 |
erlehmann |
MisterE if you doubt my assertion about hud updates, go on a mineclone2 0.71 server and stand in a fire until your connection is saturated. |
| 22:41 |
sfan5 |
?!?!?!?!?!?! |
| 22:41 |
sfan5 |
who comes up with that |
| 22:41 |
erlehmann |
the implementation is cursed in exactly the way live television would. we fixed it in mineclonia. |
| 22:41 |
rubenwardy |
replying to me or MisterE/erleh |
| 22:41 |
sfan5 |
you |
| 22:41 |
rubenwardy |
erlehmann, MisterE: #minetest please |
| 22:41 |
erlehmann |
ok! |
| 22:42 |
rubenwardy |
yeah it's odd. I'm not a huge fan of putting even more stuff into cmake |
| 22:42 |
rubenwardy |
oh, there's an env variable that might be able to be used instead |
| 22:43 |
rubenwardy |
still, it seems to be ignoring the path I give to the vcpkg.json file |
| 22:45 |
|
v-rob joined #minetest-dev |
| 22:46 |
MTDiscord |
<luatic> @MisterE, Modder of Sortz no, there is currently no way to make clients forget sent files during the session; ephemeral media is however forgotten after the session (and not cached on disk) at least. |
| 22:55 |
MTDiscord |
<MisterE> Yes, it would be very useful to be able to forget a media that was no longer needed. This would provide a few advantages: in my music mod, there can be so many tracks that it is unlikely the same one will be used twice. It would be nice to be able to forget tracks after they are played so the cache isn't filled. Also, a blocker to having different textures of the same name being sent to different players (to make an object invisible to |
| 22:55 |
MTDiscord |
some players and not to others ) is that once you send a texture, that namespace is used up. A workaround is possible, but with enough changes of the texture you will fill up the cache. Better to be able to send a new texture of the same name and then forget the old one |
| 22:58 |
erlehmann |
i think you are doing something incredibly cursed and i am not sure if i would try the same approach |
| 23:00 |
erlehmann |
misterE if i send different textures with the same name to different people i can give an object a different appearance, is that correct? |
| 23:02 |
sfan5 |
that is correct |
| 23:19 |
|
tekakutli joined #minetest-dev |
| 23:22 |
|
erle joined #minetest-dev |
| 23:29 |
MTDiscord |
<MisterE> I just said can have that many tracks, it doesn't have to |
| 23:30 |
MTDiscord |
<MisterE> ok, here is a good example. Procedurally generated music |
| 23:30 |
MTDiscord |
<MisterE> no its not, that would have to be a csm |
| 23:40 |
|
SOMBRIO joined #minetest-dev |
| 23:46 |
erlehmann |
mister E for music just a way to give an ogg stream would be enough |
| 23:47 |
erlehmann |
can be generated on server |
| 23:47 |
erlehmann |
put in streaming file |
| 23:47 |
erlehmann |
done |
| 23:49 |
MTDiscord |
<MisterE> True |
| 23:55 |
|
SOMBRIO joined #minetest-dev |
