Time  Nick             Message
07:52 nrz              hello everyone ? i'm glad to see improvements on the irrlicht side. I think we have more to do, i really want to move generic MT things inside it ?
08:19 rubenwardy       We should be removing from it, not adding to it
08:19 rubenwardy       Pure irrlicht stuff may make sense, but not generic Mt stuff
08:20 nrz              remove what from irrlicht ? irrlicht rendering itself ?
08:20 nrz              you clear irrlicht to absorb it in MT codebase ?
08:20 nrz              (that can be a solution)
08:21 nrz              moving stuff to irrlicht properly has an advantage, it may show us a pattern which may permit to remove our crap client irrlicht stuff and have generics to replace it with other engine if needed (but i think it's not required as now we have our fork)
08:50 sfan5            reminder #11287
08:50 ShadowBot        https://github.com/minetest/minetest/issues/11287 -- Take advantage of IrrlichtMt target by JosiahWI
08:55 celeron55        it works, right?
08:57 celeron55        i did look at the code at some point and it was fine, if you're looking for a merge go-ahead i can give it
08:57 nrz              sfan5: german commit in the PR :p
08:58 nrz              approved
08:59 celeron55        this could have a bit more guidance for installing irrlichtmt in the error messages
09:00 sfan5            it works yes
09:00 sfan5            I just don't want anyone surprised/unaware that they can't use point to irrmt via IRRLICHT_INCLUDE_DIR + IRRLICHT_LIBRARY anymore
09:00 sfan5            s/use point/point/
09:01 celeron55        the test would be, pull minetest into somewhere, try to build it, it should tell you you can just pull irrlichtmt into lib/ and try building again
09:01 celeron55        and you shouldn't have to go look for a guide to do that
09:01 sfan5            that or the README should have a very prominent section (we can expect users to read that right?)
09:01 celeron55        i think we can't
09:02 celeron55        well
09:02 celeron55        it could tell the user to go look in README
09:04 celeron55        there's no reason to not make the build process as self-explanatory as possible
09:04 sfan5            true
09:04 celeron55        of course this can be a separate pull request but i'm not the one who made me look at the cmake error messages 8)
10:27 freshreplicant[m <MTDiscord "<Warr1024> I think MTG would not"> Bit late to this, but this idea makes a lot of sense. As much as a subset of creators are ready to see MTG go the way of the dodo, most players don't seem to be interested in that and aren't heeding it. If MTG must exist as a non-default option, then why not a maintained, more coherent one? Alternatively, if you can somehow bring the modders of the MTG ecosystem along with you, maybe
10:27 freshreplicant[m it's time to give MTG the Caesar treatment ("Et tu, El Ceejo?") and invest in some semi-official capacity into another project that can act as a showcase for the engine.
10:55 specing          MTG sucks as a showcase
14:25 freshreplicant[m It certainly does in its present form. Which is why I agreed with Warr's suggestion of creating an overhauled version (not necessarily as a showcase, but at least so MTG isn't a detriment to MT) or axing it and going for something that is actually a good showcase.
14:31 hecks            nrz: the plan is to absorb what remains of irrlicht after deleting enough
14:32 hecks            almost nothing in irrlicht is well designed, it's a liability
14:32 hecks            in the long run even the ISceneNode system may end up being removed
14:36 hecks            rather than abstract things away to make an engine switch easier, we should not be using an engine, we are making one
14:42 specing          Maybe you should
14:42 specing          switch to a better engine
14:44 MTDiscord        <Sublayer plank> in that case, what would that engine be?
14:52 hecks            the minetest engine, of course =]]
15:01 specing          hecks: nah, I was told that Torque3D is the best, but has two problems: (1) can't run on potato (2) upstream has gone a bit proprietary
15:01 hecks            torque is garbage :o
15:02 specing          hecks: there's still other maintained ones to look at, like unvanquished's engine?
15:02 hecks            what do we need an engine for
15:02 specing          But I must admin that I'm not a first person game dev, so idk about these engines
15:02 hecks            here's the deal
15:02 specing          hecks: sharing of development burden
15:02 hecks            we already implement a lot of the things an engine usually does
15:03 hecks            we don't use irrlicht for most things
15:03 hecks            hence i was able to delete half of that thing without losing any features
15:03 hecks            we use irrlicht for: rendering, gui, i/o
15:04 hecks            and a lot of the problems that irrlicht has been causing us were in part due to the fact that it targets so many platforms
15:04 hecks            minetest's client environment is special in a lot of ways, we have a lot of domain specific knowledge that we can use to optimize things
15:04 MTDiscord        <Sublayer plank> doesn't minetest already target all the platforms irrlicht targets? windows, macos, linux, freebsd, android...
15:04 hecks            that a general purpose game engine can not do
15:05 hecks            I'm not talking about that
15:05 MTDiscord        <Sublayer plank> oh
15:05 hecks            I'm talking about irrlicht having a goddamn software renderer, D3D path, etc... not being GL only was tying our hands a lot
15:05 hecks            and a lot of the stupid things irrlicht does are a consequence of this too
15:06 hecks            minetest is an engine, it does not make sense to overlay it on top of another engine
15:07 hecks            c55 was just messing around in irrlicht one day and made it, and that's fine
15:08 hecks            it's an acceptable concession if you're working mostly alone
15:08 hecks            and don't know opengl
15:10 hecks            but minetest has grown into this monster of a platform since and there's now enough hands on the deck to do it right
15:10 hecks            meaning using sdl, opengl and various other libs rather than a general purpose game engine
15:11 hecks            among other things, mobile performance is crap because irrlicht is trying to use gles2 as if it were a software renderer
15:13 celeron55        why is this still argued about
15:13 hecks            :o what?
15:13 celeron55        hecks should be writing code, not responding to the same question over and over again
15:13 hecks            :DDDDD
15:13 hecks            right
15:13 hecks            back to butchering ivideodriver it is
15:14 hecks            celeron55 take a look at #11490
15:14 ShadowBot        https://github.com/minetest/minetest/issues/11490 -- Add engine design guidelines by hecktest
15:14 celeron55        the only reason irrlicht wasn't gotten rid of is there wasn't enough expertise and time to do it
15:14 celeron55        hecks seems to have both, and it would be a total waste not to use it
15:15 hecks            my time isn't infinite but i straight up need to do this
15:16 celeron55        even if hecks disappeared after this, MT still would be in a better position: we'd have outdated opengl code, but unlike now it would be minimized inside the project, not maximized inside irrlicht, i.e. there would be a chance someone else could update it
15:17 celeron55        irrlicht is dead, there's no question about that
15:17 celeron55        and almost all 3d engine projects die at some point
15:17 hecks            if i disappeared *after* this you'd at least have: a smaller binary, and a somewhat good gl2 base
15:19 hecks            i'm not going to willingly disappear though because this is the upstream for my crappy MMO and i'm stuck with it
15:21 hecks            i give myself time until about october to have the new renderer up and running
15:22 sfan5            I wonder if we want to delay 5.5 until it's done or hotfix (or disable) the shadow stuff so we can safely put out what is currently in master
15:24 hecks            i'm basically stuck in engine work so i'm a little indifferent, mibi is not live yet
15:24 hecks            but i'll be rebasing shadows on top of the new renderer at one point so maybe knowing that can help
15:40 specing          hecks | torque is garbage :o
15:40 specing          hecks: why?
15:42 celeron55        why wouldn't it be, most of them are
15:42 celeron55        because someone told you so?
15:42 celeron55        that's the thickest nonsense i've heard today
15:45 celeron55        it might be good for *something*, but being good for minetest is an impossible goal for a generic 3d engine
15:46 celeron55        if i was working for microsoft with the task of slowing down MT development, i would do something like try to get MT to try to switch to another 3d engine
15:50 specing          right
15:50 specing          Duion of Uebergame told me that's its the best
15:52 hecks            i'll admit i straight up don't remember why i hate torque but i did install it once and hated it, even more so than irrlicht
15:52 hecks            this was quite a long time ago
15:53 MTDiscord        <Warr1024> If feels weird hearing people say that an engine should switch to a different engine
15:53 hecks            but basically none of these ancient engines are good, people have learned how to design engines since
15:53 hecks            and yes
15:54 hecks            the best engines are either proprietary sadly, or in-house things you've never heard of
15:54 hecks            my work on minetest will basically be a port of the latter
15:56 MTDiscord        <Benrob0329> Torque always looked interesting but like it needed a bit more work to modernize
15:56 MTDiscord        <Benrob0329> also, custom scripting language
15:57 hecks            i wrote a 3d engine as a backup plan in case minetest ends up being unsalvageable, a friend was writing his in the meantime and we ended up sharing notes a lot
16:05 hecks            anyway what i can tell you is that most available game engines are lagging behind in good practices and features, and the free software ones even more so
16:17 hecks            it would also be immensely stupid for a game engine to use an engine =]
16:19 MTDiscord        <Warr1024> I think Unity should consider switching to the Minetest engine XD
16:23 MTDiscord        <Sublayer plank> yeah! why shouldn't they?
16:58 sfan5            merging #11128, #10876, #11287, #11478 in 10m
16:58 ShadowBot        https://github.com/minetest/minetest/issues/11128 -- Improve documentation of tools by Wuzzy2
16:58 ShadowBot        https://github.com/minetest/minetest/issues/10876 -- ContentDB: Add reason to downloads by rubenwardy
16:58 ShadowBot        https://github.com/minetest/minetest/issues/11287 -- Take advantage of IrrlichtMt target by JosiahWI
16:58 ShadowBot        https://github.com/minetest/minetest/issues/11478 -- Add bold, italic and monospace font styling for HUD text elements by sfan5
17:08 Krock            ⏰
17:09 kilbith          sfan5: https://irc.minetest.net/minetest-dev/2021-07-26#i_5851738
17:10 sfan5            yes I know, will fix eventually
17:10 Krock            there's more somewhere in the sha code
17:10 sfan5            yea I was planning to fix all warnings we currently have at once someday
17:41 sfan5            hmm I think the buildbot no longer installs irrlicht dlls this way
18:39 sfan5            pushing http://sprunge.us/PuhN2v?diff in a few min
19:32 v-rob            Hey, can I have an opinion? On the C++ side, how should the new GUI store styling information? StyleSpec stores it as strings and then parses the string in a context-dependent way. However, the new GUI isn't string-based, but styling still could be context-dependent (especially if custom Lua elements ever were to exist)
19:36 v-rob            I can't just store JSON from the server verbatim if a real (SS)CSM Lua API is to exist for the GUI later on
19:36 sfan5            what does "context-dependent" mean? just different enums?
19:38 v-rob            That is, it's pretty hard to know for certain what datatype a certain styling property is without limitations (especially custom Lua elements might interpret things however they like)
19:38 v-rob            Future-proofing is hard
19:38 sfan5            don't elements have a persistent state they can use to store the style in parsed form?
19:39 sfan5            then you'd keep the raw data around but only for purposes of element creation
19:44 v-rob            I can. It does kind of dash my hopes of keeping formspec element compatibility from contaminating the new elements without having to inherit a formspec element class from each new element class.
19:51 v-rob            Honestly, I want the new GUI to drop all formspec default styling (like the gradiented button panes) and give a blank slate that can be styled as wanted without having to unstyle everything first.
19:55 celeron55        i think strings are a perfectly valid in-memory format for values, as long as the enclosing data structure is parsed into a proper container
19:55 celeron55        if the string can contain a large parseable data structure, then it becomes a bit iffy
19:56 celeron55        actually, then storing the parsed state of a json parser could make sense
19:56 celeron55        if the required format for the data isn't known before use
19:59 v-rob            Then again, there's always performance to worry about, seeing as this would be read every frame
19:59 v-rob            I don't know if JSON state would be slow
20:00 celeron55        depends on the json parser
20:00 celeron55        the one we link to probably isn't the best
20:00 celeron55        it just has the sexiest name
20:01 celeron55        but anyway, if it's possible with reasonable effort, of course parse as much as possible into a fast data structure
20:02 celeron55        can you think of an example where a simple one-level key-value store won't work for styling?
20:05 celeron55        if i was implementing this i'd just do std::unordered_map<std::string, std::string> and hope for the best, but i'm lazy
20:06 celeron55        especially if "custom lua elements" are going to be a thing
20:06 v-rob            I'm probably looking from this from the wrong angle. Perhaps a better angle than "how to store style info" is really "how to have formspec compat code without it making its way into the new elements without a whole new set of elements dedicated to formspecs" since that's how I got into thinking about styling.
20:07 v-rob            It's a problem I've never resolved from the start, and I suspect it's contaminated a lot of my designing
20:07 celeron55        i guess you'll just have to have a bunch of compatibility code that convers the old stuff into new stuff
20:07 celeron55        and have the new elements able to act like old ones given the right styles and parameters
20:07 celeron55        that the compat code will apply to them
20:08 celeron55        converts*
20:08 v-rob            I was hoping for a solution that keeps the formspec code entirely separate. But I guess that might not be very possible.
20:09 celeron55        well that keeps it separate
20:09 celeron55        it can literally be a conversion function that takes in a formspec element and puts out the new kind of element
20:09 celeron55        in a different file, if you get anxiety otherwise
20:10 celeron55        as long as the new elements can act like old ones given they are supplied certain parameters
20:10 celeron55        and i don't mean a parameter like "old_style=true"
20:11 celeron55        i mean a parameter like color=blue, if the old default was blue
20:12 celeron55        this surely makes sense to at least someone here?
20:13 v-rob            No, I fully understand you, but I just didn't want things like "gradients=true" having to sit in the new elements for all time because of formspecs. Oh well, I guess there's not much for it.
20:14 celeron55        well
20:14 celeron55        the way around that is to change the default style and not support the old default style
20:14 celeron55        i certainly am open to that
20:14 v-rob            Hmm
20:15 v-rob            I don't think anyone would miss the dark gray gradients :P
20:15 celeron55        as long as the default style is consistent and somewhat similar to before it won't matter a lot what it is
20:15 celeron55        pretty much any light on dark style could work
20:16 celeron55        i'm sure even hecks would be fine with that
20:16 hecks            what's up
20:16 celeron55        :D
20:16 celeron55        there he is *points*
20:17 hecks            v-rob wants to break my forms? :DDD
20:17 v-rob            Yes, it's my secret plan
20:17 hecks            how about we don't overhaul gui without sscsm...
20:17 hecks            but ok, what were you guys talking about
20:19 v-rob            It was just a discussion on whether default formspec styling could be changed somewhat so as to not have to support the old styling in new GUI code. Like, getting rid of gradients on buttons.
20:20 v-rob            And, if you're fine with that, probably everybody would be
20:20 hecks            *default* does not concern me
20:20 hecks            however you might be approaching formspec emulation from the wrong angle
20:21 v-rob            What angle would you approach it from?
20:21 hecks            reimplemented as user elements entirely
20:22 v-rob            As in, inheriting a new class for each formspec element?
20:22 hecks            yup
20:22 hecks            of course entirely in lua
20:23 v-rob            Why in Lua specifically?
20:24 hecks            is it not the whole point of the new system?
20:25 v-rob            Well, I'd love absolutely everything to be in Lua, but it's not possible without security issues. So, most of the GUI has to be in C++, but with as many openings for Lua as possible
20:26 hecks            pardon me that i'm not actually that certain what the problems with our gui are
20:27 hecks            besides hud and forms not using the same api
20:27 hecks            as long as we do not have server sent code, we'll run into the same problems
20:28 hecks            people seem to go on a lot about how formspecs suck (i'm in the minority that doesn't mind them much)
20:28 hecks            but has anyone actually written down a list of why they suck?
20:28 sfan5            1. awful text format
20:28 v-rob            2. awful event system
20:29 v-rob            3. non-dynamic in the least
20:29 specing          > hecks | pardon me that i'm not actually that certain what the problems with our gui ara
20:29 specing          It sucks
20:29 v-rob            4. inconsistent in absolutely everything except in being horrible
20:29 specing          Check out SpringRTS's lua GUI
20:29 hecks            well the low dynamicity of forms is a limitation of not being able to execute server sent code
20:29 sfan5            hey at least the coordinates are no longer inconsistent ;)
20:29 specing          in SpringRTS, the entire goddamn GUI is in lua
20:30 v-rob            5. the backend is Irrlicht. Need more be said?
20:30 hecks            =]
20:30 hecks            oh right, you'd do me a big favor by using low level rendering to do your gui as opposed to irr gui features
20:31 hecks            text format: at least it's compact, it works as a transmission format
20:31 v-rob            JSON's much better, however, as an almost 1:1 translation can be done from Lua tables
20:31 hecks            awful event system: i'll agree this was a little wonky to wrap but it ended up working
20:32 hecks            actually why would we ever use json if we have a perfectly good lua parser and vm...
20:32 v-rob            Because no one's making SSCSM.
20:32 specing          I wish that whatever the new GUI system becomes, that it stays interactable in CSMs. Right now it is pretty simple to interact with CSMs
20:32 specing          v-rob: wrong
20:32 specing          luk3yx has a few
20:32 hecks            i mean, as a transmission format lua works even without sscsm, making a barebones sandbox is not that hard
20:33 hecks            sscsm is hard because of the apis you have to expose
20:33 v-rob            I mean, no one's implementing SSCSM in the engine
20:33 hecks            as a serialization format, it doesn't really matter, although
20:33 hecks            ideally forms should not be transmitted as text in the first place
20:33 hecks            same with texture modifiers
20:34 hecks            anyway a lot of the problems with forms seem more like api problems than a problem with the concept itself
20:34 v-rob            Yeah, mostly the new GUI is a) replacing Irrlicht's GUI and b) replacing the API, which amounts to basically everything
20:35 hecks            i wrapped them in an object oriented toolkit, i can even make my own elements from what's available and have clients sharing a form
20:35 celeron55        the thing about SSCSM lua gui is, it doesn't need any security sensitive apis to be exposed from the engine
20:35 sfan5            hecks: it's a bit annoying to have a serialization format that can trivially enter an infinite loop
20:35 celeron55        literally a 2d drawing api and an input api
20:35 hecks            =] disallow loops
20:35 sfan5            how?
20:36 hecks            yeah i get it
20:36 celeron55        i think it's doable, even right now, if someone wants to
20:36 v-rob            Sure, a drawing and events API is possible. I've already done it
20:36 v-rob            (closed for a few reasons, however)
20:37 hecks            anyway for forms it would be smart to deconstruct what they are
20:37 v-rob            The security issues really lie in things like a SSCSM being able to overwrite the pause menu or something
20:37 hecks            forms consist of a gui markup language and response events
20:37 hecks            as long as there is no server sent code being executed, i fail to see issues with the concept by itself
20:38 hecks            other than it requiring programming skill to work with because it's pretty low level
20:38 celeron55        v-rob: is overwriting the pause menu actually a security issue?
20:38 hecks            not if there's a panic button to disconnect from the server
20:38 v-rob            Some users don't know what alt-f4 is
20:39 celeron55        well, i can think of some server literally displaying the main menu, and a user typing the password of another server there
20:39 celeron55        a bit iffy
20:39 hecks            now we're talking...
20:39 hecks            how about a formspec mimicking the phone's interface... okay i'll stop
20:39 celeron55        but i'm sure web browsers have lots of experience on something like this
20:40 hecks            this was an attack i heard of recently, with a fake address bar
20:40 celeron55        well actually, i think displaying the main menu is ALREADY possible
20:40 v-rob            The new web browser: Minetest Explorer
20:40 celeron55        and displaying a pause menu also is
20:40 v-rob            Well, not with clouds in the background
20:40 celeron55        sure is
20:40 hecks            well, shit
20:40 celeron55        just point the player to clouds
20:40 hecks            not a lot of people would notice
20:41 celeron55        so, we already have this security issue
20:41 celeron55        it's not a new issue for sscsm gui
20:41 hecks            time to redact the logs :DD
20:41 celeron55        :D
20:42 celeron55        fug :DDDD as we say in finland
20:42 hecks            ebin
20:42 hecks            well with sscsm you basically don't have to care what the communication format and api are
20:43 hecks            it's best realized in a low level way
20:43 v-rob            Games can't bind the Esc key (yet), so that exploit isn't perfect
20:43 celeron55        well all this can be solved by including something in the engine pause and main menus that games can't easily mimick
20:44 hecks            well this esc thing was actually an annoyance for me... but i found a way to deal with it
20:45 hecks            the problem was "what if the player just closes this form" https://a.uguu.se/4kNAx2Ndorsp_close.png
20:46 v-rob            Just bind the "exit" event and reshow it
20:46 hecks            the solution ended up being that you can close it and look around and use the esc menu; it'll just be reopened when you press any button
20:46 hecks            that was a bit annoying because you couldn't leave the server if i did that
20:46 rubenwardy       [20:36] <+sfan5> what does "context-dependent" mean? just different enums?
20:46 hecks            well you could
20:46 hecks            you'd just have to spam esc until you managed to get the pause menu open, and that just didn't feel right
20:46 v-rob            True dat
20:46 rubenwardy       It's like settings - the key is parsed by the code in different ways
20:46 hecks            oh but thanks, i just realized a bug
20:46 hecks            i need to disable chat in this mode...
20:47 hecks            not like anyone can *hear* your yet-nameless character talking in their instance in the corner of the map, but still
20:48 rubenwardy       Honestly, formspec compatibility should just be done by keeping the old formspec code
20:48 v-rob            But then we're stuck with Irrlicht's GUI forever
20:49 hecks            why can't forms be rebased on top of the new gui?
20:49 hecks            at least rendering wise
20:49 hecks            it's not like we're allowed to lose any functionality
20:50 v-rob            Full circle: because I don't want current formspec styling to invade the new code
20:50 v-rob            I don't want a "gradient=true" styling option, for instance
20:50 hecks            so yeah, at the very least, do that subclass thing except forget the lua bit
20:50 hecks            it seems solvable with basic OOP
20:51 hecks            FormElement : public MtGuiElement
20:51 hecks            FormButton : public FormElement
20:51 hecks            etc
20:51 rubenwardy       Or you can translate formspecs to the new GUI
20:51 rubenwardy       So parse them and emit new GUI elements
20:52 hecks            that's basically the same thing
20:52 rubenwardy       You don't need to support border (=gradient) and such
20:52 celeron55        i think v-rob should forget compatibility at this point and just design a good extendable system
20:52 v-rob            Sounds like a plan
20:53 celeron55        then it should naturally be extendable to support the old stuff
20:53 hecks            the emulator can be figured out later
20:53 celeron55        if it's extendable enough
20:53 rubenwardy       However, bear in mind that it will be hard to completely and reliably reproduce formspecs if rewriting the code
20:53 celeron55        it doesn't matter, we're known to break stuff randomly
20:53 v-rob            Who said formspecs were reliable in the first place?
20:53 hecks            the code doesn't need to know anything about form specific options, it just needs to pass the duck test
20:53 hecks            even if you have to emulate one element using many
20:53 celeron55        ...i mean, it's going to be close enough
20:53 hecks            perhaps that's the missing hint
20:53 rubenwardy       So I'd suggest keeping the old code whilst deprecating formspecs, and then using a transpiler that isn't likely to give the exact same results
20:54 v-rob            Well, the old code won't go anywhere for a long time
20:54 hecks            sure, just prepare for a thousand edge cases from me
20:54 v-rob            You forget -- it's my secret plan to break your formspecs. Bwa ha ha!
20:55 v-rob            And, of everyone here, I think I know the formspec code the best
20:55 hecks            it's not like my gui system is very aware of forms, it's an implementation detail
20:55 hecks            i'll just hawk you for features until i can port everything
20:56 v-rob            I've sifted through nearly every line of the 4771-line guiFormSpecMenu.cpp
20:56 hecks            4771...
20:56 v-rob            It's waaaaaaay too big
20:56 hecks            still smaller than irrlicht's GL drivers
20:56 v-rob            We have a 1000 line max, but no one's gonna split up GUIFormSpecMenu
20:57 hecks            did you know that irrlicht just carries an enum and a string list of all the extensions in existence for no apparent reason...
20:57 hecks            including SUN extensions
20:57 v-rob            Sun, of all thing? Wow
20:57 hecks            SUN_multi_draw_elements or something like that
20:57 hecks            plus NV and ATI versions of everything side by side with the ARB version
20:58 hecks            but the real question is
20:58 hecks            who queries GL extension presence so often that they need enum performance?
20:58 v-rob            Once the new GUI is complete, I reserve the right to tear out GUIFormSpecMenu and all of its friends mercilessly. I think that's my privilege
20:58 v-rob            :D
20:58 hecks            what you're basically not allowed to do is change the coordinate system
20:59 hecks            though it would be best if the user could actually specify the units (wow!)
21:00 hecks            whether they want to treat the screen as an arrangement of tiles or a reference resolution of some sort
21:00 v-rob            I've already changed the entire coordinate system and kept backwards compatibility. It's the very first thing I ever did for MT. I don't think you have to worry about that
21:00 hecks            :o ok
21:00 hecks            basically uh
21:00 v-rob            (Trivia: It's the first time I ever did C++ either)
21:00 hecks            anybody with a brain already wraps formspecs in something
21:00 hecks            so it would be good if at least they could keep their layouts
21:01 hecks            and only change the implementation
21:02 v-rob            There may be a sizer for absolute layouts for easy formspec transitioning. However, it will be highly discouraged for any new GUIs
21:02 v-rob            Other sizers will be highly recommended.
21:03 hecks            as long as i don't have to crop elements or reserve empty space ever
21:03 hecks            those are no-go
21:03 hecks            autogenerated scrollbars are also considered harmful
21:04 v-rob            BTW: as an exercise, I made a basic mock-up of how one could design your GUI with sizers: <https://user-images.githubusercontent.com/31123645/126883250-67414ef6-5fbc-445e-8b90-fdf26c338d06.png>
21:05 hecks            have you considered that the right window must be 4 inventory cells wide
21:06 hecks            and that the compactness is intentional and desirable?
21:06 hecks            the only thing i would do if i could is
21:06 hecks            shift the left and right windows around depending on the screen aspect ratio
21:06 hecks            but never enough that they start eating the middle section's space
21:06 hecks            at that point i'd rather just scale everything
21:07 hecks            still, the creator form is low hanging fruit
21:07 hecks            https://a.uguu.se/U4XTKOjWAB5W_inv.png the inventory has zero dead space reserved
21:07 v-rob            Sizers don't make it difficult to not be compact. Just make the outermost sizer's dimensions maximums, or remove them altogether
21:07 hecks            but
21:08 hecks            you can't make that window wider than 4 cells because there would be ugly gaps around the inventory
21:08 hecks            you cannot make it more narrow because it would no longer fit
21:08 hecks            game GUIs generally don't stretch as much as HTML
21:08 hecks            i think you just don't play a lot of games
21:09 v-rob            Not everything in Minetest is a game GUI like yours. And some people like to translate
21:09 v-rob            Without scrollbars, like you
21:10 hecks            i just want the option to fix everything and scale uniformly
21:10 hecks            or fix entire chunks at least
21:10 hecks            but that's basically just for aspect ratio support (which is becoming less important as 4:3 screens are rare)
21:10 nrz              hecks, wrong, many AAA games are using cef3 which is chromium like rendering in games ?
21:11 hecks            i'd voice my opinion on libcef but this is a mostly SFW channel
21:11 hecks            they also used to literally use flash in the form of Scaleform
21:12 hecks            first, it doesn't matter what they use because they often fix the GUI layout a lot anyway
21:13 v-rob            How would your fixed layouts work for a HUD anyway?
21:13 hecks            anchors
21:13 hecks            groups would be fixed relative to one another but still be able to move with the screen corners
21:14 hecks            i think this is already possible in the hud system
21:14 v-rob            The HUD system uses percentages
21:14 hecks            since the position of an element is normalized device coordinates
21:14 hecks            and offsets can be expressed in pixels
21:14 hecks            then i can use the former to anchor to a corner and then use pixel offsets
21:15 hecks            and the DPI setting will scale it all correctly and it'll work in every aspect ratio =]
21:15 hecks            which is kind of how it works in unity and, well, it works
21:15 hecks            and this is how most game guis work
21:16 hecks            even the games that use floating windows a lot like various MMOs, they rarely flex anything inside the windows
21:16 hecks            basically for aesthetic reasons
21:17 rubenwardy       The point of sizers/layouters is to make it easier to make GUIs - you don't need to manually specify positions and sizes, you instead use elements to place children one on top of another, for example
21:17 rubenwardy       Responsiveness can also be supported by this, but only one benefit
21:17 hecks            i'm not opposed to anchors and hierarchy
21:18 rubenwardy       Layouters include linear (side by side), grid, and absolute (like formspecs)
21:18 rubenwardy       Also constraing
21:18 rubenwardy       Although that's not really needed
21:18 hecks            well then I'd end up using enough constraints that it would be indistinguishable from a fixed layout
21:18 v-rob            I want opinions: sfan5, celeron55, Krock: who prefers absolute fixed-size layouts over sizer-based layouts?
21:19 hecks            all i care about is relative fixing
21:19 hecks            that's a strawman too
21:19 rubenwardy       You could just use absolute layouters if that matches your workflow
21:19 sfan5            'prefer to work with' or 'consider the superior solution'?
21:19 v-rob            Both
21:20 sfan5            guess we need both fixed-size and sizer-based then
21:20 hecks            would diablo be that memorable without its cell inventory and basically pixel-perfect GUIs?
21:20 nrz              i agree
21:21 rubenwardy       I think sizer based is superior, but supporting absolute would be fine
21:22 hecks            as i've said i'm fine with aspect ratio correction, supporting a range from 4:3 to 16:9 by moving whole groups around
21:22 hecks            but as soon as either ratio is hit i want my gui to just shrink beyond that point
21:22 hecks            instead of cutting text off with ellipses or spawning scrollbars for it
21:23 hecks            and likewise i want perfect control over which part gets stretched out between the aspect ratios, instead of everything stretching sort of uniformly
21:23 hecks            because it's a game inventory screen, not a website
21:23 v-rob            Stretching some things but not others sounds like sizers...
21:24 sfan5            sizers between fixed-size containers that is
21:24 hecks            yup
21:24 hecks            it could also be expressed as anchors
21:26 hecks            like here's one of my planned guis https://a.uguu.se/uFgYNb4uw6f3_skilltree.png
21:27 hecks            there's not a whole lot of opportunity to flexibly scale things in it
21:27 hecks            especially if i want to style it with artwork in this way
21:36 v-rob            Well then, you can have your fixed layouts. I implement them under protest, however
21:37 sfan5            people with existing layouts would have lots of issues if new formspecs don't support fixed sizes
21:37 sfan5            weren't you planning for this?
21:37 hecks            I don't understand what's so evil about it...
21:41 rubenwardy       Not evil, just painful to calculate all the coordinates and write reusable components
21:44 v-rob            I don't want to provide pure fixed layouts because, since they are easier, people will use them, and then their stuff breaks easily because they can't support anything like translations or different user preferences.
21:44 v-rob            Changing a font should never be a breaking change, and yet fixed layouts make it so. That's ludicrous.
21:44 rubenwardy       I'm not sure they're necessarily easier though
21:45 v-rob            Easier to get started with and easier to understand
21:45 rubenwardy       They shouldn't be easier, our API would be bad in that case
21:45 v-rob            Not easier in the long run
21:47 v-rob            That is, it's easy to understand "put this element at (X, Y)" than "put this element in some flexible container", so people gravitate towards it. I used to do it myself a long time ago with desktop toolkits.
21:47 hecks            the mistake is letting the user decide the font instead of letting the server send it
21:48 rubenwardy       Accessibility
21:48 hecks            unity used to have a desktop-like GUI system, everyone thought it was shit and they switched to an anchor based one
21:50 hecks            they thought they were being clever with skins and styling and sizing and layout groups...
21:57 Calinou          in an era of hiDPI and ultrawide monitors, we should definitely design something scalable
21:57 Calinou          especially if you want to improve the Android situation :)
22:07 hecks            if you want to improve the android situation, fix their controls
22:07 hecks            and we have a DPI setting already
22:07 hecks            in fact it's the best way to scale anything and works with even my "evil" fixed GUIs
22:08 hecks            https://user-images.githubusercontent.com/42101236/126729643-8362bdc2-20ba-481d-8ba5-75a1e5fedcfb.png
22:09 hecks            so saying my forms don't scale is a strawman unfortunately
22:09 hecks            what they can't do is fit all aspect ratios, but letterboxing 4:3 is fine really
22:11 sfan5            <hecks> and we have a DPI setting already < it's almost always ignored
22:11 sfan5            because it's only a fallback when MT doesn't know how to retrieve the dpi
22:11 sfan5            which is approximately never
22:21 MTDiscord        <Jordach> btw
22:21 MTDiscord        <Jordach> DPI is wrong on macOS and is actually 96 on any standard VESA compliant display
22:21 MTDiscord        <Jordach> like windows it was never 72
23:11 hecks            the default should probably just be 96, that's what screens actually use don't they
23:12 hecks            sfan5: we need a percentage DPI scale setting on top of it
23:13 hecks            because changing the DPI OS wide to make things bigger when you want to is a bit of a hassle
23:16 MTDiscord        <Jordach> can we like just move to 96 dpi globally and use npow2 scaling
23:18 hecks            yes
23:18 hecks            96 is actually the setting where a 16px font is 16 pixels (wow!)
23:19 hecks            and uhh
23:19 hecks            not npow2 scaling, integer scaling
23:19 hecks            x3 is fine
23:19 hecks            if the idea is to avoid misscaling sprites
23:19 MTDiscord        <Jordach> you knew what i meant
23:19 hecks            sure
23:19 MTDiscord        <Jordach> scaling that doesn't introduce the heinous irrlicht scaling
23:20 hecks            it's not irrlicht's fault, it's an inherent problem with scaling sprites
23:20 MTDiscord        <Jordach> inventory slots are known to smush textures
23:20 hecks            but
23:20 hecks            inventory slots are another problem
23:20 hecks            and i'd like to see it resolved one day
23:20 hecks            this is the one place i haven't been able to eliminate shitty scaling from
23:21 hecks            i ended up sizing my item sprites 24x24 because that looks good in the hotbar
23:21 hecks            but
23:21 hecks            they are actually slightly off in the inventory
23:21 hecks            https://a.uguu.se/oHCfxCfitcgp_compare.jpg just barely
23:22 MTDiscord        <Jordach> use the tried and tested ellen ripley method: nuke it from orbit
23:22 hecks            i mean it looks like we ought to scale it down a little in the inventory
23:22 hecks            bring it down a size
23:22 hecks            a few pixels whatever
23:22 hecks            but
23:22 hecks            i sure hope doing that wouldn't break some weird default that minetest_game happens to work on or something...
23:23 MTDiscord        <Jordach> what
23:24 MTDiscord        <Jordach> 's minetest game
23:24 hecks            :DDD
23:24 hecks            i would go and test it at 72 dpi but i literally can't set it
23:24 hecks            on windows
23:24 hecks            like maybe it works at 72 with 16x16 sprites on both? is somebody who actually coded this in the room?
23:25 MTDiscord        <Jordach> and right now i need to swap KVM to give the author of 11287 a very good ribbing
23:27 hecks            oh uhhh i don't know about any of this build stuff =]
23:27 hecks            i just run whatever sfan spoonfeeds me
23:38 hecks            the hotbar graphic is also messed up now that i look at it
23:42 hecks            oh this is also kinda ridiculous
23:42 hecks            https://a.uguu.se/qPEJAhIlkjrS_wat.gif
23:42 hecks            so this is the power of sizers...