| Time |
Nick |
Message |
| 01:16 |
|
calcul0n_ joined #minetest-dev |
| 02:10 |
|
v-rob joined #minetest-dev |
| 03:13 |
|
pmp-p joined #minetest-dev |
| 04:03 |
|
v-rob joined #minetest-dev |
| 05:10 |
|
CeeGee joined #minetest-dev |
| 05:28 |
|
\c joined #minetest-dev |
| 05:35 |
|
v-rob joined #minetest-dev |
| 06:24 |
|
v-rob joined #minetest-dev |
| 07:00 |
|
\c joined #minetest-dev |
| 08:01 |
|
specing_ joined #minetest-dev |
| 09:01 |
|
T4im joined #minetest-dev |
| 09:13 |
celeron55 |
you're thinking it in the wrong way |
| 09:13 |
|
Fixer joined #minetest-dev |
| 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:18 |
|
tech_exorcist joined #minetest-dev |
| 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 |
| 09:34 |
|
freshreplicant[m joined #minetest-dev |
| 09:41 |
|
wsor4035 joined #minetest-dev |
| 10:04 |
|
T4im joined #minetest-dev |
| 11:11 |
|
olliy1or joined #minetest-dev |
| 11:11 |
|
hlqkj joined #minetest-dev |
| 11:27 |
rubenwardy |
My laptop doesn't like compiling for Android in a 26'c room |
| 12:03 |
|
T4im joined #minetest-dev |
| 12:43 |
|
entuland joined #minetest-dev |
| 12:47 |
|
hlqkj_ joined #minetest-dev |
| 12:49 |
|
olliy joined #minetest-dev |
| 13:47 |
|
T4im joined #minetest-dev |
| 14:06 |
|
appguru joined #minetest-dev |
| 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:00 |
|
T4im joined #minetest-dev |
| 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:39 |
|
Extex joined #minetest-dev |
| 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 |
| 17:47 |
|
CeeGee joined #minetest-dev |
| 18:02 |
|
v-rob joined #minetest-dev |
| 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:10 |
|
Fixer_ joined #minetest-dev |
| 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 |
| 19:57 |
|
Fixer joined #minetest-dev |
| 19:59 |
|
Fixer_ joined #minetest-dev |
| 20:01 |
|
specing_ joined #minetest-dev |
| 20:29 |
|
Fixer joined #minetest-dev |
| 20:40 |
|
Fixer_ joined #minetest-dev |
| 20:56 |
Pexin |
celeron55: thanks for engine choice insights. will keep list for later. |
| 22:14 |
|
Extex joined #minetest-dev |
| 22:34 |
|
Lone_Wolf joined #minetest-dev |
| 22:39 |
|
pmp-p joined #minetest-dev |
| 22:46 |
|
pmp-p joined #minetest-dev |
| 22:53 |
|
Extex joined #minetest-dev |
| 23:17 |
VanessaE |
folks in here, please see my remarks and screenshots in #minetest |
| 23:18 |
|
Alias2 joined #minetest-dev |
| 23:39 |
|
v-rob joined #minetest-dev |
