| Time |
Nick |
Message |
| 00:46 |
[MTMatrix] |
<Zughy> still not sure what to do with #14103. Is it supported somehow or...? |
| 00:46 |
ShadowBot |
https://github.com/minetest/minetest/issues/14103 -- Add drawtype sunken and covered by sfence |
| 00:47 |
[MTMatrix] |
<Zughy> It feels rude closing it whilst there is a discussion in progress, but nobody is really supporting it (meaning assigning themselves) |
| 00:55 |
|
y5nw joined #minetest-dev |
| 00:57 |
Mantar |
shame, that's a cool feature |
| 01:08 |
|
v-rob joined #minetest-dev |
| 01:46 |
|
MTDiscord joined #minetest-dev |
| 01:47 |
MTDiscord |
<herowl> Zughy, isn't that feature in roadmap anyway? |
| 01:47 |
MTDiscord |
<herowl> Graphical improvements, API improvements... |
| 02:11 |
MTDiscord |
<mistere_123> Don't let it get closed. Some dev assign yourself, please! Missing Sunken drawtypes is one of the graphical issues with minetest that really should have been fixed long ago. |
| 02:13 |
MTDiscord |
<warr1024> Having the ability to mark a node as "don't draw the outside boundary of neighboring nodes, act as if they connect with this node" in general would be really nice. I've got some game types where the level design is fixed, and thus geometry should be optimizable ... and the fact that the game has prepared polygons for faces that can never be seen because of where the player is trapped, and has to cull them from every frame ... just |
| 02:13 |
MTDiscord |
feels wrong 😄 |
| 02:14 |
MTDiscord |
<mistere_123> Also, yeah, sfence's pr seems pretty roadmappy |
| 02:18 |
MTDiscord |
<herowl> cx384 was casually paramatting that PR :hyperXD: |
| 02:20 |
MTDiscord |
<herowl> funny how the related issue was approved by paramat |
| 02:21 |
MTDiscord |
<herowl> although, I guess one could say that sfan5 was the one approving the concept |
| 02:46 |
MTDiscord |
<paradust> pgimeno: Indeed, you can convert a quaternion to a matrix, and expect that p * q * v == p.mat() * q.mat() * v, as long as conventions were chosen to be consistent. But it looks like matrix multiplication is also somewhat different than math conventions |
| 03:21 |
|
v-rob joined #minetest-dev |
| 04:00 |
|
MTDiscord joined #minetest-dev |
| 04:09 |
|
v-rob joined #minetest-dev |
| 04:20 |
|
proller joined #minetest-dev |
| 05:12 |
|
imi joined #minetest-dev |
| 06:22 |
|
v-rob joined #minetest-dev |
| 06:58 |
|
appguru joined #minetest-dev |
| 08:11 |
nore |
btw, does anyone know how the CI works? I don't understand why the last commit of #13687 makes the CI fail on something that looks completely unrelated |
| 08:11 |
ShadowBot |
https://github.com/minetest/minetest/issues/13687 -- Client-side translations: gettext and plural support by Ekdohibs |
| 08:57 |
sfan5 |
is your branch rebased on latest master? |
| 09:19 |
nore |
I rebased it less than a week ago, since I saw you had merged a commit related to it, but it didn't seem to fix it |
| 09:26 |
sfan5 |
strange |
| 10:34 |
pgimeno |
@paradust oh well, starting with the axis convention choice, little is standard in Irrlicht or MT |
| 10:37 |
|
grorp joined #minetest-dev |
| 11:46 |
|
Lupercus joined #minetest-dev |
| 12:37 |
|
proller joined #minetest-dev |
| 12:44 |
|
appguru joined #minetest-dev |
| 14:49 |
|
Desour joined #minetest-dev |
| 14:52 |
|
Noisytoot joined #minetest-dev |
| 16:08 |
|
fluxionary joined #minetest-dev |
| 17:20 |
|
Desour joined #minetest-dev |
| 17:26 |
sfan5 |
should I merge irr#295? |
| 17:26 |
ShadowBot |
https://github.com/minetest/irrlicht/issues/295 -- [no sq] Reformat the code (adopted) by Desour |
| 17:29 |
Desour |
:+1: |
| 17:29 |
|
v-rob joined #minetest-dev |
| 17:37 |
|
pmp-p joined #minetest-dev |
| 17:42 |
Desour |
how do we actually do #13642 in a way that people don't get weird side issues? |
| 17:42 |
ShadowBot |
https://github.com/minetest/minetest/issues/13642 -- Import Irrlicht by numberZero |
| 17:43 |
Desour |
we have to delete the .git folder in irrlichtmt, as git will otherwise treat it as submodule |
| 17:45 |
Desour |
but if you switch from master to the irrlicht import branch, and presumably also when you pull, the .git is there again (but somehow doesn't show up in git status), as well as other files that differ from the imported irrlichtmt |
| 17:47 |
Desour |
should we maybe move the imported irrlicht to another directory, and keep the old irrlichtmt repo ignored? |
| 18:23 |
MTDiscord |
<andrey2470t> Rebased #14427 |
| 18:24 |
ShadowBot |
https://github.com/minetest/minetest/issues/14427 -- Dual wielding (revival) by Andrey2470T |
| 18:26 |
Desour |
I haven't found a better way. so I think we should import irrlicht to a lib/irrlichtmt_imported/, and let cmake use that one. |
| 18:27 |
Desour |
this way, the old repo will not be magically deleted or anything |
| 18:27 |
Desour |
it'll also makes bisecting easier if you can still have the old irrlichtmt there, and have just the old minetest use it |
| 18:30 |
sfan5 |
or maybe even under <root>/irr? |
| 18:31 |
sfan5 |
that way the paths aren't so long e.g. /irr/src/CIrrDeviceSDL.cpp |
| 18:31 |
Desour |
sounds good |
| 18:31 |
Desour |
could also be src/irr |
| 18:31 |
Desour |
or lib/irr |
| 18:34 |
MTDiscord |
<josiah_wi> Isn't consistent project structure more important than path length? |
| 18:35 |
MTDiscord |
<josiah_wi> Could this be a reasonable time to re-organize the directory structure a little if necessary? |
| 18:36 |
Desour |
do you have suggestions? |
| 18:37 |
MTDiscord |
<josiah_wi> I think your lib/irr suggestion makes sense because Irrlicht still has an upstream project. But if we're going to treat it as part of our Minetest codebase, I would suggest maybe putting it under src/irrlicht and moving its includes to include/irrlicht or something. |
| 18:38 |
MTDiscord |
<josiah_wi> Thoughts on that? |
| 18:38 |
MTDiscord |
<josiah_wi> Oh, you suggested src/irr as well. Looks like we're pretty much thinking the exact same thing. |
| 18:39 |
Desour |
for now we want to build irrlicht separately though (see https://github.com/minetest/minetest/pull/13642#issuecomment-1902678237 ), because of which it's probably better to not put it into src/ |
| 18:41 |
MTDiscord |
<josiah_wi> It can be built as its own component even if it's in the src/ directory. We already do something like that in our existing code with the headless server vs the client. They share the same source tree but they're two different executables. |
| 18:42 |
MTDiscord |
<josiah_wi> It's also easy to ask CMake to build a single target from the command line without any additional configuration. A simple script could be used to build and package it as a standalone library. |
| 18:44 |
Desour |
to keep the import PR simple, it's imo better to not merge the irrlicht cmake project into the minetest cmake project |
| 18:45 |
Desour |
(not in the import PR) |
| 18:46 |
rubenwardy |
An includes dir only makes sense if you're making a library, I'd prefer to merge the trees into one |
| 18:46 |
MTDiscord |
<josiah_wi> Agreed. Although I don't really have any say in this, I'm not even a core dev. 😄 |
| 18:46 |
MTDiscord |
<josiah_wi> (agreeing with Desour) |
| 18:47 |
Desour |
contributor feedback is valuable though :) |
| 18:47 |
rubenwardy |
especially good not to merge the irrlicht cmake project in if it's super painful cmake code as well |
| 18:48 |
MTDiscord |
<josiah_wi> I was in the process of cleaning it up a lot after the move to CMake 3.12, but I haven't landed it yet. |
| 18:48 |
Desour |
we can (and imo should at some point) still move irrlicht around the minetest repo later |
| 18:50 |
Desour |
if we first want to merge the irrlicht cmake project into the minetest one, before mergeing into src/, it might be best to put it to <root>/irr, like sfan5 suggested |
| 18:50 |
MTDiscord |
<josiah_wi> I don't think anything has to be done CMake-project-wise at this point, because both are already designed to work correctly in their own project context. |
| 18:50 |
Desour |
(because all other libs in lib/ have their own cmake project, afaik) |
| 18:51 |
MTDiscord |
<josiah_wi> What's the benefit of combining it into one project()? |
| 18:51 |
MTDiscord |
<josiah_wi> Versioning, maybe? |
| 18:52 |
Desour |
not sure. but there's no real reason to have a separate project, I think |
| 18:52 |
MTDiscord |
<josiah_wi> I think it boils down to whether you want to version it separately or not. |
| 18:53 |
MTDiscord |
<josiah_wi> Or perhaps in a broader sense, whether you want to package them separetely. |
| 18:54 |
Desour |
we dont |
| 18:55 |
MTDiscord |
<josiah_wi> Probably a good idea to combine it into one project then like you said. Only thing to be aware of might be that per-project configuration will be shared, so all Minetest's configuration will apply to the Irrlicht code. I expect that to mostly work out of the box but it'd be good to pay attention to that when the merge happens. |
| 18:56 |
Desour |
right |
| 18:57 |
Desour |
this might also be a thing we want. it's weird if we're using -ffast-math for example in irrlicht only |
| 18:57 |
MTDiscord |
<josiah_wi> It will also make sense to remove all the target export code from the Irrlicht CMake lists, to make things a lot simpler, and some dependency management that is done separately for the two projects can be combined. |
| 18:59 |
MTDiscord |
<josiah_wi> The one annoyance there is that Minetest does much of its dependency management in <root>/src/CMakeLists.txt, so <root>/irr/ won't be able to pick that up. |
| 19:00 |
MTDiscord |
<josiah_wi> I think if you add the subdirectories in the right order it would work, although I'd have to review whether you can link to the irrlicht target before it's been created. |
| 19:09 |
|
pmp-p joined #minetest-dev |
| 19:15 |
|
pmp-p joined #minetest-dev |
| 19:22 |
|
pmp-p joined #minetest-dev |
| 19:32 |
|
pmp-p joined #minetest-dev |
| 19:48 |
|
pmp-p joined #minetest-dev |
| 19:55 |
|
book` joined #minetest-dev |
| 19:58 |
Desour |
#14483 |
| 19:58 |
ShadowBot |
https://github.com/minetest/minetest/issues/14483 -- [no squash] Irrlicht import by Desour |
| 20:08 |
celeron55_ |
interesting to see the irrlichtmt line count. that's about a sixth of the upstream irrlicht 1.8.whatever line count as far as i can tell |
| 20:48 |
|
appguru joined #minetest-dev |
| 21:01 |
sfan5 |
Desour: i can the fix android the mingw build |
| 21:02 |
Desour |
ah nice |
| 21:02 |
Desour |
feel free to push to the branch |
| 21:22 |
|
Lupercus joined #minetest-dev |
| 21:35 |
|
v-rob joined #minetest-dev |
| 21:54 |
sfan5 |
Desour: probably everything should work now |
| 21:57 |
Desour |
thanks! |
| 21:59 |
sfan5 |
apparently we're crashing clang++-10 in one CI job |
| 21:59 |
sfan5 |
can't hold on to old software forever 🤷 |
| 22:16 |
sfan5 |
Desour: fyi i pushed a change to the irrlicht mt repo, might wanna include that in the commit |
| 22:18 |
Desour |
the irr/.github workflows are currently not run btw. |
| 22:18 |
Desour |
I guess we should maybe move them to root .github at some point |
| 22:22 |
sfan5 |
dunno. I'm not sure what the goal should be regarding integration into our cmake/test suite/logging or keeping it separate |
| 22:43 |
|
proller joined #minetest-dev |
| 23:33 |
|
panwolfram joined #minetest-dev |
