Minetest logo

IRC log for #minetest-dev, 2021-07-27

| Channels | #minetest-dev index | Today | | Google Search | Plaintext

All times shown according to UTC.

Time Nick Message
00:07 specing_ joined #minetest-dev
00:20 specing_ joined #minetest-dev
02:11 Extex joined #minetest-dev
02:27 celeron55 joined #minetest-dev
03:44 Kimapr joined #minetest-dev
04:41 AntumDeluge joined #minetest-dev
06:36 Kimapr joined #minetest-dev
07:05 nyje joined #minetest-dev
07:19 nrz joined #minetest-dev
07:19 nrz joined #minetest-dev
07:20 nrz joined #minetest-dev
07:21 nrz joined #minetest-dev
07:22 nrz joined #minetest-dev
07:23 nrz joined #minetest-dev
07:24 nrz joined #minetest-dev
07:26 nrz joined #minetest-dev
07:29 nrz joined #minetest-dev
07:34 nrz joined #minetest-dev
07:50 nrz joined #minetest-dev
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 ?
07:53 Kimapr5 joined #minetest-dev
07:56 calcul0n__ joined #minetest-dev
08:02 Kimapr joined #minetest-dev
08:05 nyje left #minetest-dev
08:10 tech_exorcist joined #minetest-dev
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:49 Kimapr joined #minetest-dev
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)
09:22 Fixer joined #minetest-dev
09:35 calcul0n_ joined #minetest-dev
09:59 Alias joined #minetest-dev
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:45 entuland joined #minetest-dev
10:55 specing MTG sucks as a showcase
10:58 longerstaff13 joined #minetest-dev
11:30 behalebabo joined #minetest-dev
12:19 specing_ joined #minetest-dev
13:03 x2048 joined #minetest-dev
13:19 x2048 left #minetest-dev
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:29 hecks joined #minetest-dev
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:38 Fixer joined #minetest-dev
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 Extex joined #minetest-dev
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 kilbith joined #minetest-dev
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:17 hecks joined #minetest-dev
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
18:41 x2048 joined #minetest-dev
18:43 x2048 joined #minetest-dev
19:32 v-rob joined #minetest-dev
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:22 Extex joined #minetest-dev
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 behalebabo joined #minetest-dev
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:35 kilbith joined #minetest-dev
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 joined #minetest-dev
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
22:29 Extex joined #minetest-dev
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...
23:49 AliasAlreadyTake joined #minetest-dev

| Channels | #minetest-dev index | Today | | Google Search | Plaintext