Time  Nick       Message
09:13 celeron55  you're thinking it in the wrong way
09:13 celeron55  when forking irrlicht, effectively MT isn't using an engine anymore
09:14 celeron55  the fork is part of MT
09:14 celeron55  thus there is no engine anymore
09:20 celeron55  Pexin's question is interesting though: what to use for a new project?
09:20 celeron55  it depends on whether you want to learn opengl or not
09:20 celeron55  if you do, then maybe pick up a large sample project using direct opengl and make your thing from it
09:21 celeron55  if not, then i think most engines have very different design criteria on what platforms they run on, what license they're under, how large they are, how they're packaged on linux distributions, how much they're developed, what the compatibility is between versions and so on
09:22 celeron55  what language you have to use, what kind of development environment there is
09:22 celeron55  it shouldn't be difficult to form an opinion about them without someone telling you to use one
09:23 celeron55  also what opengl versions they support. some don't run at all on low-end hardware, which also can be a problem
09:24 celeron55  most people don't have a gaming computer, so unless your target audience is "gamers", you might need to support some old opengl version
09:27 celeron55  oh, then there's the question of what to use for windowing and input with direct opengl, my answer would be sdl2
09:28 celeron55  what language to use then? there are lots of options and everyone has their favourite, maybe think about where you can get contributors to your project if you some day need them
09:30 celeron55  if you want contributors with gamedev experience, then you need to pick something simple and common in those circles
09:31 celeron55  if you like solo devving, just use your favourite or the language you'd like to have on your resume
11:27 rubenwardy My laptop doesn't like compiling for Android in a 26'c room
14:48 sfan5      someone approve #11350 plz
14:48 ShadowBot  https://github.com/minetest/minetest/issues/11350 -- Drop --videomodes, fullscreen_bpp and high_precision_fpu settings by sfan5
14:48 sfan5      then I can import/sync translations with weblate later
14:48 sfan5      (relevant because it removes some strings)
15:05 rubenwardy one sec, testing
15:14 rubenwardy done
15:35 sfan5      merging #11350 in 5m
15:35 ShadowBot  https://github.com/minetest/minetest/issues/11350 -- Drop --videomodes, fullscreen_bpp and high_precision_fpu settings by sfan5
15:58 rubenwardy There should probably be a fullscreen checkbox on the settings page
16:01 sfan5      only issue with that is irrlicht doesn't support changing fullscreen at runtime
16:01 sfan5      (not that it couldn't be done)
16:01 * sfan5    will look at weblate import now
16:02 rubenwardy can be     [ ] Fullscreen (restart needed)
17:23 sfan5      pushing weblate commits to master now
18:04 pgimeno    we're also forgetting that we're using the Irrlicht GUI, and as an engine it's pretty alone in providing one, so apart from another engine we'd need to choose a GUI library or develop one
18:04 pgimeno    that's also true if the "engine" is plain OpenGL, of course
18:06 v-rob      But the GUI rework will not use the Irrlicht GUI when its done, and neither will the compatibility code for formspecs either. It will all be Lua based with a C++ backend for drawing and events.
18:07 pgimeno    a GUI is a huge task, the multiline editor in particular is very involved
18:08 v-rob      I've expressed before that it's a task that I'm willing to take on. And I don't give up easily.
18:08 pgimeno    good
18:37 Krock      sfan5: would you please be so nice to explain why exactly offloading Settings parent management and is necessary? Why could it not be integrated into Settings directly?
18:38 sfan5      it's not
18:38 sfan5      what I'm saying is that it's a cleaner solution
18:41 Krock      exactly the offloading part and passing down the SettingsHierarchy reference to Settings again is why I have troubles seeing the advantage of it
18:42 Krock      MapSettingsManager already takes care of its Settings lifecycle anyway
18:43 Krock      well, I'm not a software engineer so *shrug*. I guess you're right then
18:43 sfan5      me neither
18:44 sfan5      as for why I think it's cleaner, that is because it's generic. you can change how a settings object retrieves its parent or where it registers just by passing a different class
18:45 sfan5      it is not the only solution but it's neat that this both 1) encapsulates the global layers from the rest of Settings and 2) allows MapSettingsManager to do what is needed to make it work
18:49 Krock      question then would be whether you'd ever need more than a single parent pointer. Settings outside the global layers do already now not perform any fallback checks (old Settings::getParent() code; because m_settingslayer == SL_TOTAL_COUNT)
18:50 Krock      the callbacks are a neat benefit though, and I think those make sense to ensure the parents are referencing to a proper location
18:52 sfan5      if you mean that every object keeps only a `Settings *m_parent`: that's annoying to work with since layers are created or destroyed at any time
18:53 Krock      right. without a Hierarchy class this would not be reliable
19:08 Krock      however `m_parent` could easily be overwritten using a 3-liner function in a callback, so that the fallback code has an unified structure. anyway. I'll best wait for other opinions on this topic
19:09 sfan5      how would Settings::createLayer look with m_parent? surely more than three lines
19:15 Krock      excuse me? m_parent is only necessary for non-global (s_layer) Settings, which are excluded from the regular fallback order. createLayer is only for s_layer settings
19:16 Krock      since the fallback order for glboal settings is clearly defined using the loop & nullptr checks
19:16 sfan5      when I said "every object keeps only a `Settings *m_parent`" earlier I meant removing m_settingslayer too
19:16 Krock      setting m_parent on global settings would be an invalid no-op, just like using `setDefault` on anything else than the global setings
19:17 Krock      oh
19:17 sfan5      (because I think it's useful having a single abstraction that both global layers and MapSettingsManager can use)
19:18 Krock      changing it into a single-linked list? I think I also considered that earlier, but dropped it due to overcomplicated dependency cleanups (i.e. parent references)
19:19 sfan5      yes that'd not be a good idea
20:56 Pexin      celeron55: thanks for engine choice insights. will keep list for later.
23:17 VanessaE   folks in here, please see my remarks and screenshots in #minetest