| Time |
Nick |
Message |
| 00:05 |
|
Eragon joined #minetest-dev |
| 01:13 |
|
YuGiOhJCJ joined #minetest-dev |
| 04:26 |
|
hwpplayer1 joined #minetest-dev |
| 05:00 |
|
MTDiscord joined #minetest-dev |
| 06:48 |
|
MTDiscord joined #minetest-dev |
| 07:32 |
|
SFENCE joined #minetest-dev |
| 07:46 |
|
SFENCE joined #minetest-dev |
| 09:04 |
Krock |
y5nw: "would need to be considered different keys even if they get the same keycode" << this is already the case now. The key processing priorities are specified by `KeyCache::populate`. |
| 09:06 |
Krock |
event.KeyInput.Char is the printable character and event.KeyInput.Key is not dependent on modifiers from what I can see. |
| 09:09 |
[MatrxMT] |
<y5nw> Krock: I know. My point is that you would need to support a new case in addition to the existing one. |
| 09:13 |
|
SFENCE joined #minetest-dev |
| 09:13 |
Krock |
y5nw: sorry, I do not understand what you mean by "a new case". In either way, it seems the only way to skip SDL_IME_ProcessKeyEvent would be to patch the program memory, which is beyond sanity. |
| 09:14 |
Krock |
so going with scancodes is probably - after all - the best solution. |
| 09:17 |
[MatrxMT] |
<y5nw> Krock: if we have / on shift-7 we would need to consider differentiating the "/"/Shift-7 key event from the event where you only press the "7" key (they would have different keychars but the same EKEY_CODE) |
| 09:19 |
[MatrxMT] |
<y5nw> It's largely a secondary consideration though since it would be very hacky to work around IMEs already. |
| 09:44 |
|
SFENCE joined #minetest-dev |
| 09:58 |
|
SFENCE joined #minetest-dev |
| 10:11 |
|
SFENCE_ joined #minetest-dev |
| 11:04 |
|
SFENCE joined #minetest-dev |
| 11:38 |
|
SFENCE joined #minetest-dev |
| 11:52 |
|
SFENCE joined #minetest-dev |
| 12:02 |
|
SFENCE joined #minetest-dev |
| 13:17 |
|
SFENCE joined #minetest-dev |
| 13:23 |
|
whosit joined #minetest-dev |
| 13:46 |
|
SFENCE joined #minetest-dev |
| 13:52 |
|
SFENCE joined #minetest-dev |
| 14:23 |
|
SFENCE joined #minetest-dev |
| 14:42 |
|
SFENCE joined #minetest-dev |
| 15:56 |
|
SFENCE joined #minetest-dev |
| 16:02 |
|
SFENCE joined #minetest-dev |
| 16:35 |
|
SFENCE joined #minetest-dev |
| 17:19 |
|
SFENCE joined #minetest-dev |
| 17:22 |
sfan5 |
particle collision detection seems to be weirdly inefficient |
| 17:23 |
sfan5 |
(8% of the client run loop) |
| 17:28 |
|
Desour joined #minetest-dev |
| 17:29 |
|
Farooq joined #minetest-dev |
| 17:32 |
|
Farooq joined #minetest-dev |
| 17:39 |
|
Farooq joined #minetest-dev |
| 17:40 |
sfan5 |
add_area_node_boxes should really run block-wise |
| 17:40 |
|
hwpplayer1 joined #minetest-dev |
| 17:44 |
|
SFENCE joined #minetest-dev |
| 17:45 |
|
SFENCE_ joined #minetest-dev |
| 17:53 |
sfan5 |
might be costing 5-10fps |
| 17:55 |
sfan5 |
(this is a scene with rain particles and it doesn't reach full fps even without, so any extra work is noticeable) |
| 18:02 |
|
SFENCE joined #minetest-dev |
| 18:04 |
|
SFENCE joined #minetest-dev |
| 18:12 |
MTDiscord |
<josiah_wi> Particle collision detection could possibly be related to the incorrectly large particle bounding box, maybe? |
| 18:16 |
sfan5 |
good idea, but it doesn't use that box |
| 18:23 |
MTDiscord |
<luatic> doesn't particle collision detection have the same performance problems as entity collision detection |
| 18:24 |
sfan5 |
yes |
| 18:24 |
MTDiscord |
<luatic> okay, then it boils down to the fact that we're using an unnecessarily large bounding box rather than a ray with some margin and no spatial indexing for entities |
| 18:25 |
MTDiscord |
<luatic> the former we have PRs for, implementing the latter could potentially reuse selectionbox raycast code |
| 18:25 |
sfan5 |
the box is the particle size |
| 18:26 |
sfan5 |
if it's small enough sure we can use a ray |
| 18:26 |
Desour |
collision adds 1 node length in each direction |
| 18:26 |
MTDiscord |
<luatic> hence why i'm saying "ray with margin" |
| 18:26 |
Desour |
which is especially bad for small boxes, like particles |
| 18:26 |
Desour |
(see `collisionMoveSimple`) |
| 18:26 |
MTDiscord |
<luatic> we have to add this margin because we allow large collision boxes |
| 18:27 |
MTDiscord |
<luatic> we could try to optimize for the common case of small boxes however |
| 18:27 |
MTDiscord |
<luatic> similar to what was attempted for raycasts |
| 18:27 |
MTDiscord |
<luatic> (but had to be reverted) |
| 18:29 |
MTDiscord |
<josiah_wi> How come one of the glTF tests failed on MacOS for #15408? |
| 18:29 |
ShadowBot |
https://github.com/minetest/minetest/issues/15408 -- Collision: more accurate computation with acceleration and long dtime by kno10 |
| 18:29 |
MTDiscord |
<luatic> are you sure it's a gltf test that's failing? |
| 18:29 |
Krock |
@josiah_wi It's probably again the biome test |
| 18:30 |
MTDiscord |
<luatic> yeah, most likely #15598 |
| 18:30 |
ShadowBot |
https://github.com/minetest/minetest/issues/15598 -- Random ARM macOS CI failures |
| 18:30 |
Krock |
> Test assertion failed: biome->name == expected.name |
| 18:30 |
Krock |
the glTF errors are intentional and good |
| 18:30 |
MTDiscord |
<josiah_wi> Yep, it's the biome test. |
| 18:43 |
|
Farooq joined #minetest-dev |
| 18:50 |
|
vorgzander joined #minetest-dev |
| 18:50 |
|
Guest26 joined #minetest-dev |
| 18:52 |
|
Farooq joined #minetest-dev |
| 19:51 |
|
Farooq joined #minetest-dev |
| 19:55 |
sfan5 |
there are definitely a bunch of mods misusing use_texture_alpha |
| 19:56 |
sfan5 |
if you bind skipping the transparent ClientMap render pass to quicktune you can see some perfectly opaque rails, door disappearing. also some untinted glass panes |
| 21:04 |
sfan5 |
there are like two or three nested maps inside ItemStackMetadata, man |
| 21:06 |
MTDiscord |
<wsor4035> name and shame? if there mt-mods ones, can have those fixed pretty quickly |
| 21:08 |
|
Sharpman joined #minetest-dev |
| 21:11 |
sfan5 |
advtrains, homedecor, ilights, pkarcs_doors3 |
| 21:14 |
|
SFENCE joined #minetest-dev |
| 21:14 |
MTDiscord |
<wsor4035> ilights uses clip, should it not? as for homedecor its used across 22 files, would have to go through all of those i guess |
| 21:16 |
sfan5 |
server mods may be outdated, idk. |
| 21:17 |
sfan5 |
ilights:lights_on is in the transparent render pass. for no reason. |
| 21:31 |
|
YuGiOhJCJ joined #minetest-dev |
| 21:42 |
|
SFENCE joined #minetest-dev |
| 23:34 |
|
panwolfram joined #minetest-dev |
