| Time |
Nick |
Message |
| 00:49 |
|
lhofhansl joined #minetest-dev |
| 06:52 |
|
mizux joined #minetest-dev |
| 08:00 |
|
ShadowNinja joined #minetest-dev |
| 08:45 |
|
calcul0n joined #minetest-dev |
| 10:12 |
|
Fixer joined #minetest-dev |
| 10:28 |
|
calcul0n_ joined #minetest-dev |
| 11:31 |
|
turtleman joined #minetest-dev |
| 11:45 |
Krock |
rubenwardy: do you have any test mod for #10173 ? |
| 11:45 |
ShadowBot |
https://github.com/minetest/minetest/issues/10173 -- Deprecate get_player_velocity and add_player_velocity by rubenwardy |
| 12:00 |
rubenwardy |
I'll post it when I'm on my laptop, later |
| 12:15 |
Krock |
nvm. wrote my own in the meantime |
| 12:42 |
|
absurb joined #minetest-dev |
| 13:25 |
|
Icedream joined #minetest-dev |
| 13:25 |
|
jas_ joined #minetest-dev |
| 14:42 |
Krock |
I'd like to hold a little meeting this evening, 18 GMT (or so). Who would be available? |
| 14:43 |
rubenwardy |
I will be |
| 14:43 |
rubenwardy |
also <rubenwardy> We should probably do meetings again - who's free this Saturday? |
| 14:43 |
rubenwardy |
sfan5 is available this evening, not sure about 18 GMT |
| 14:48 |
|
basxto joined #minetest-dev |
| 15:01 |
MTDiscord |
<Lone_Wolf> I request you consider giving out a Windows installer for the next release. I'll compile it myself if needed |
| 15:02 |
rubenwardy |
I would like that |
| 15:02 |
rubenwardy |
Ideally, Windows builds should be made in CI. We have MSVC builds in CI, just need to change the configs (ie: add LuaJIT) |
| 15:02 |
rubenwardy |
there's also a disabled Windows installer CI build |
| 15:38 |
sfan5 |
I don't know if the deps the msvc ci uses are built in the exact way we need them |
| 15:38 |
sfan5 |
e.g. gc64 mode for luajit |
| 15:38 |
sfan5 |
also does gettext work? |
| 16:23 |
rubenwardy |
Merging #9058, #7862, #8837, #9440 in 10 minutes |
| 16:23 |
ShadowBot |
https://github.com/minetest/minetest/issues/9058 -- Fix scrollbar overlapping text (again) by random-geek |
| 16:23 |
ShadowBot |
https://github.com/minetest/minetest/issues/7862 -- Lua API: Add register_on_chatcommand to SSM and CSM by octacian |
| 16:23 |
ShadowBot |
https://github.com/minetest/minetest/issues/8837 -- Reduce the FPS when the window is unfocused by HybridDog |
| 16:23 |
ShadowBot |
https://github.com/minetest/minetest/issues/9440 -- Chatcommands: Show the help message if func returns false without message by HybridDog |
| 16:27 |
Krock |
\o/ |
| 16:39 |
rubenwardy |
done |
| 16:47 |
MTDiscord |
<Lone_Wolf> I think there are a few other PRs with double approvals |
| 16:48 |
rubenwardy |
there are, I didn't approve them though |
| 16:49 |
rubenwardy |
one of them I did - I'm currently testing it more now |
| 16:49 |
rubenwardy |
large PRs probably shouldn't be merged as soon as they reach 2 approvals, but instead wait for a day ish |
| 16:49 |
rubenwardy |
well, they don't need to be |
| 16:49 |
MTDiscord |
<Lone_Wolf> Ah, makes sense I guess |
| 16:50 |
Krock |
will merge small #9792 and #9453 in 10 minutes |
| 16:50 |
ShadowBot |
https://github.com/minetest/minetest/issues/9792 -- Add note to docs on how to override privileges by LoneWolfHT |
| 16:50 |
ShadowBot |
https://github.com/minetest/minetest/issues/9453 -- Document builtin entities by Wuzzy2 |
| 16:59 |
Krock |
merging |
| 17:01 |
Krock |
done |
| 17:02 |
rubenwardy |
I've added a point to the meeting - to aid with prioritisation, people should think about what they think the focus should be on |
| 17:03 |
rubenwardy |
For example, UI improvements (ie: formspec rewrite) |
| 17:03 |
rubenwardy |
!dev Meeting |
| 17:03 |
ShadowBot |
rubenwardy: Error: That URL raised <HTTP Error 404: Not Found> |
| 17:03 |
rubenwardy |
!dev Meetings |
| 17:03 |
ShadowBot |
Meetings - Minetest Developer Wiki -- http://dev.minetest.net/Meetings |
| 17:15 |
|
MTDiscord3 joined #minetest-dev |
| 17:24 |
rubenwardy |
#10460 |
| 17:24 |
ShadowBot |
https://github.com/minetest/minetest/issues/10460 -- Prevent games from setting secure settings by rubenwardy |
| 17:41 |
Krock |
readConfigFile is cumulative |
| 17:42 |
Krock |
luckily it's run on a temporary settings object |
| 17:44 |
rubenwardy |
Yeah |
| 17:44 |
rubenwardy |
I commented this |
| 17:44 |
rubenwardy |
Wait |
| 17:44 |
rubenwardy |
I didn't click submit |
| 17:44 |
Krock |
new TODO entry: move readConfigFile/parseCommandLine to the Settings constructor to avoid such mess |
| 17:44 |
Krock |
(note to myself) |
| 17:45 |
Krock |
nore, sfan5: meeting in 15 minutes - would you be available then, or would you prefer to join at another time? |
| 17:45 |
sfan5 |
sure |
| 17:46 |
|
DS-minetest joined #minetest-dev |
| 18:00 |
Krock |
okay. let's go. Meeting notes: https://dev.minetest.net/Meetings#2020-10-03 |
| 18:01 |
Krock |
> 5.4.0 release plan -> December? |
| 18:01 |
Krock |
I just wondered whether that's just a random date or whether it was discussed previously |
| 18:01 |
rubenwardy |
it's 6 months after the last release |
| 18:01 |
rubenwardy |
the date itself is random |
| 18:02 |
rubenwardy |
I don't believe it was discussed, I just set it as 6 months after |
| 18:02 |
Krock |
fair enough. we rarely release on that date, so it might make sense moving it a few weeks forward already :3 |
| 18:02 |
Krock |
s/forward/earlier/ |
| 18:03 |
rubenwardy |
true, moved it two weeks earlier |
| 18:03 |
Krock |
whatever. it's not important. next topic. |
| 18:03 |
rubenwardy |
yeha |
| 18:03 |
Krock |
thanks |
| 18:03 |
Krock |
> Roadmap - everyone list 3 goals for development (ie: Improve UI), this can then be condensed into a roadmap of goals. |
| 18:04 |
Krock |
So you'd like us to write a personal TODO list or so? |
| 18:04 |
rubenwardy |
Essentially, but higher level goals rather than individual features. It's helpful in communicating to contributors that certain things are more likely to be accepted, as they're wanted soon |
| 18:05 |
rubenwardy |
I don't think it matters too much how strictly you do it, tbh |
| 18:05 |
Krock |
currently it's like "oh, that's a nice PR. I'll review that now" |
| 18:07 |
Krock |
where would you like to write that down? tbh I don't have any features in mind, but cleaning up the internal structure for now |
| 18:07 |
Krock |
ping sfan5 btw |
| 18:07 |
rubenwardy |
that's a valid goal - and was on my list |
| 18:08 |
Krock |
the list on the forums? |
| 18:08 |
rubenwardy |
#10461 |
| 18:08 |
ShadowBot |
https://github.com/minetest/minetest/issues/10461 -- Roadmap Idea Board |
| 18:08 |
Krock |
ah |
| 18:08 |
rubenwardy |
well, an issue or the forums |
| 18:09 |
rubenwardy |
or GitHub teams, it doesn't matter too much |
| 18:09 |
Krock |
GH teams isn't visible to outsiders, which would kinda miss the point |
| 18:09 |
sfan5 |
I doubt this is very useful but my three immediate goals are solving #10342, implementing an alternative solution to #9978 and optimizing rendering of nodeboxes |
| 18:09 |
ShadowBot |
https://github.com/minetest/minetest/issues/10342 -- Rethink use_texture_alpha changes |
| 18:09 |
ShadowBot |
https://github.com/minetest/minetest/issues/9978 -- Add new_pos to moveresult output by oilboi |
| 18:09 |
sfan5 |
doubt I can bring myself to do the last one before 5.4 |
| 18:09 |
Krock |
it's long-term goals after all |
| 18:13 |
rubenwardy |
I can think of either 4 or 2 things, but 3 is hard |
| 18:14 |
Krock |
ok done |
| 18:15 |
Krock |
moving on to next topic in a minute |
| 18:15 |
sfan5 |
so where do I write that down? |
| 18:16 |
Krock |
https://github.com/minetest/minetest/issues/10461 |
| 18:16 |
sfan5 |
ah |
| 18:16 |
Krock |
apparently that's the new place - a cut-down version of the forum post (if you wrote one previously) |
| 18:17 |
rubenwardy |
not many have made the forum posts |
| 18:18 |
Krock |
> Decide on a "use_texture_alpha" solution (issue 10342) |
| 18:18 |
sfan5 |
well there's no decision to be made really |
| 18:18 |
sfan5 |
if for whatever reason this is unsolved before 5.4 revert the changes so far |
| 18:18 |
sfan5 |
if not, someone (me) will PR the changes proposed in point 2 |
| 18:18 |
Krock |
okay, so we'll leave that task to you - since it's on the roadmap |
| 18:18 |
rubenwardy |
#10342 |
| 18:18 |
ShadowBot |
https://github.com/minetest/minetest/issues/10342 -- Rethink use_texture_alpha changes |
| 18:19 |
Krock |
uh-oh new meeting points were added in the meantime |
| 18:19 |
rubenwardy |
a user PM'd me |
| 18:19 |
Krock |
> Add trusted contributors as issue triagers |
| 18:20 |
Krock |
I've also read a bit of this conversation and it's apparently to spread the load a bit |
| 18:21 |
Krock |
reasonable people could take over that job for sure, but I'm afraid that most of the cases need troubleshooting by an active developer |
| 18:22 |
Krock |
already now it's possible for them to highlight duplicates - after that it's one click to close it (if it's really a dupe) |
| 18:23 |
Krock |
generally no objections from my side. rubenwardy: is this a special set of rights that can be given to team members or so? |
| 18:23 |
rubenwardy |
yes, GitHub supports giving triage permissions without write |
| 18:23 |
rubenwardy |
I'm probably thinking about this the wrong way around, it's worth seeing if anyone actually wants to do this |
| 18:24 |
Krock |
let's try this when someone would like to be a volunteer |
| 18:25 |
rubenwardy |
Core developer is currently all or nothing, I think there's value in delegating certain things like organisation, documentation, and design - given that they're different skills |
| 18:25 |
rubenwardy |
but yeah, certainly |
| 18:25 |
rubenwardy |
This has largely spun off of organisation discussions from the forums, and reading how other projects manage this |
| 18:26 |
Krock |
how would this opportunity be communicated? |
| 18:26 |
rubenwardy |
I have a few people in mind, I can see what they think |
| 18:26 |
Krock |
a forum post would be an objectively sane decision, but might attract the wrong kind |
| 18:27 |
|
homthack joined #minetest-dev |
| 18:27 |
Krock |
alright |
| 18:28 |
Krock |
and based on this "test run", there will be rules in the wiki to ensure everying's will go well |
| 18:28 |
Krock |
which will hopefully satisfy paramat a bit |
| 18:29 |
Krock |
if there are no objections so far, I'll write this down in the wiki before new points are added |
| 18:29 |
rubenwardy |
sire |
| 18:29 |
rubenwardy |
*sure |
| 18:29 |
Krock |
sfan5: any particular opinion on this topic? neutral? |
| 18:30 |
sfan5 |
sounds useful to me if the people doing it do it correctly |
| 18:32 |
Krock |
> Require debug priv to view gameplay-relevant debug info (2nd try), add wireframe priv |
| 18:32 |
Krock |
#9315 |
| 18:32 |
ShadowBot |
https://github.com/minetest/minetest/issues/9315 -- Require debug priv to view gameplay-relevant debug info (2nd try), add wireframe priv by Wuzzy2 |
| 18:33 |
Krock |
uhm |
| 18:33 |
sfan5 |
I haven't looked at this PR specifically but |
| 18:33 |
sfan5 |
wasn't the consensus last time that it can't be a privilege? |
| 18:33 |
Krock |
I avoided this PR because I personally don't agree with the design choices |
| 18:33 |
rubenwardy |
@GreenXenith requested that this be discussed now |
| 18:33 |
rubenwardy |
not sure if they had a specific comment about it, or just wanted it merged :D |
| 18:34 |
MTDiscord |
<GreenXenith> I just want to control debug info, man :] |
| 18:34 |
rubenwardy |
:D |
| 18:34 |
sfan5 |
IMO there can be a default on player property (we really need to stop putting everything into properties) that can be turned off to disable viewing the player position and maybe a few other things |
| 18:35 |
sfan5 |
(re properties: everytime you toggle the zoom fov every other player is informed of it, stupid design) |
| 18:35 |
MTDiscord |
<GreenXenith> The second row of debug is really the only one the server should have control over (pos, pointed, dir, seed) |
| 18:35 |
MTDiscord |
<GreenXenith> If the priv method is definitely not going to be merged, then that should be mentioned on the issue thread (and possibly closed?) |
| 18:36 |
MTDiscord |
<GreenXenith> With suggested alternatives, of course |
| 18:36 |
sfan5 |
that's just my opinion, I literally haven't opened that issue in a few months (or ever?) |
| 18:36 |
rubenwardy |
I find it interesting that no one put SSCSM or CSM in their roadmap lists ? |
| 18:36 |
sfan5 |
too much work |
| 18:36 |
Krock |
CSM were a thing in 2017/18 and generally neglected now |
| 18:37 |
Krock |
not surprising IMO |
| 18:37 |
rubenwardy |
they were heralded as the solution for all problems from 2012-2017 |
| 18:37 |
MTDiscord |
<GreenXenith> The benefits of SSCSMs currently arent outweighing the implementation drawbacks (half of which are politics) so no one can be bothered |
| 18:38 |
sfan5 |
rubenwardy: here's what I think needs to be done https://i.imgur.com/hLsByXU.png |
| 18:38 |
sfan5 |
it's annoying work and also requires some coordination (in parts), you can't just decide that one day you want to start doing it |
| 18:38 |
rubenwardy |
I agree with that |
| 18:40 |
sfan5 |
(specifically point 2 and 3 require a decision and potentially need the current CSM implementation to be changed significantly) |
| 18:40 |
MTDiscord |
<GreenXenith> I'd have to agree that a player property may be better for debug, since I hold the philosohpy that games should have full control over everything. However, something is better than nothing. |
| 18:41 |
Krock |
and by the way splitting visual/non-visual player property packets |
| 18:42 |
sfan5 |
maybe us coredevs can decide that a property is the way to go and then someone can make a PR that has good acceptance chances |
| 18:42 |
Krock |
a property format string would probably work best |
| 18:43 |
Krock |
like done in the chat command template |
| 18:43 |
MTDiscord |
<GreenXenith> Whatever is decided, it should probably be noted on the current PR thread |
| 18:43 |
Krock |
s/command/message/ |
| 18:43 |
Krock |
wiki edit done. meeting moved to "Past Meetings". |
| 18:45 |
Krock |
though I must admit that it'll be a pain to debug on multiplayer servers when F5 is restricted |
| 18:45 |
rubenwardy |
hacked clients for everyone! |
| 18:45 |
Krock |
but modifying the client shouldn't be a big deal |
| 18:45 |
rubenwardy |
tbh, you could ignore the flag when building in debug mode |
| 18:46 |
rubenwardy |
I see it more as hiding temptions rather than cheating |
| 18:46 |
Krock |
debug builds are slow anyway, so people would probably not want to use those to play seriously |
| 18:46 |
MTDiscord |
<GreenXenith> The property string could have a set of replacement patterns, such as %pos %pointed %yaw %pitch etc. and the property defines the order or existence of each specific portion. So the game could make it whatever it wants, and include the origin stuff if it so chooses. |
| 18:47 |
Krock |
https://github.com/minetest/minetest/blob/master/minetest.conf.example#L1362 <-- already existing format |
| 18:47 |
MTDiscord |
<GreenXenith> Ah, cool |
| 18:47 |
Krock |
and in addition to that, the replacement functions are safe now |
| 18:51 |
rubenwardy |
shame v-rob and pyrollo missed it. Perhaps they don't check IRC |
| 18:51 |
DS-minetest |
debug info doesn't only show the info text at the top of the screen, but also eg. object selection boxes. the format string could not restrict such |
| 18:51 |
MTDiscord |
<GreenXenith> Not true per se |
| 18:51 |
MTDiscord |
<GreenXenith> format string values can be used as flags |
| 18:52 |
DS-minetest |
then it's a flag string |
| 18:52 |
MTDiscord |
<GreenXenith> It would be both |
| 18:52 |
Krock |
ah right. upcoming meetings should be announced in the minetest team |
| 18:54 |
MTDiscord |
<GreenXenith> If you used "@position @seed @selectionbox" for instance, the debug info would dipslay "(42, 1337, 69) 1234567890" and would enable the entity selectionbox. |
| 18:55 |
DS-minetest |
you forgot the trailing space |
| 18:55 |
MTDiscord |
<GreenXenith> or perhaps it should be a debug table, with a property for infotext instead alongside other flags |
| 18:56 |
MTDiscord |
<GreenXenith> the formatter would probably ignore the first space before a flag string, but yes |
| 18:56 |
Krock |
the entity selection box is another topic. I don't think that should be controlled with the debug text |
| 18:56 |
rubenwardy |
isn't there a per-object prop for that? |
| 18:56 |
MTDiscord |
<GreenXenith> Using a format string for flags is a hack anyway |
| 18:57 |
MTDiscord |
<josiah_wi> Now that the meeting is over, I want to let the devs know that I'm trying to compile with warning flags, and I have a couple questions about stuff I broke. |
| 18:57 |
Krock |
GreenXenith: a hack? I though you'd like to format the F5 infotext only, which would work perfectly fine with formatter strings |
| 18:58 |
Krock |
josiah_wi: as long it's warnings you could try to run MInetest anyway to check whether it still works. errors are worse. |
| 18:58 |
MTDiscord |
<GreenXenith> I was referring to using something like @selectionbox in the format string as a non-replacement but a flag to toggle the entity debug selection |
| 18:59 |
MTDiscord |
<josiah_wi> I caused errors by satisfying the warnings. I'm trying to make the codebase more solid. |
| 18:59 |
Krock |
josiah_wi: perhaps there's already an open issue about your initial warnings |
| 19:00 |
Krock |
including potential solutions |
| 19:01 |
MTDiscord |
<josiah_wi> Good idea, perhaps I should look. We're talking hundreds of warnings though. |
| 19:01 |
MTDiscord |
<GreenXenith> a cleaner method would be a debug player property with an infostring key for the format string, a bool entity key for toggling entity debug (extra infotext, maybe selection), and a bool wireframe key (self-explanitory). |
| 19:01 |
rubenwardy |
josiah_wi: is this regarding #10346 ? |
| 19:01 |
ShadowBot |
https://github.com/minetest/minetest/issues/10346 -- Enable warnings and fix them |
| 19:02 |
rubenwardy |
A draft PR could be a good idea to receive help |
| 19:02 |
MTDiscord |
<josiah_wi> I felt that the best way to fix them was to start, because if I take too much time thinking about how crazy it is it'll slow me down. |
| 19:02 |
MTDiscord |
<GreenXenith> (oh, implying the debug property is a table) |
| 19:02 |
rubenwardy |
yeah, exactly |
| 19:02 |
MTDiscord |
<josiah_wi> Awesome thanks, I'll take a look. |
| 19:03 |
rubenwardy |
I'd enable warnings, fix some in certain classes/files, remove the warnings, make PR |
| 19:03 |
rubenwardy |
oh, and read up on the warnings to check they make sesne |
| 19:03 |
rubenwardy |
you can learn a lot by working out what the warning is telling you |
| 19:04 |
Krock |
FYI: Minetest already disables a few warnings where the code is wanted exactly as-is |
| 19:04 |
MTDiscord |
<josiah_wi> Hmm ok. I'm not using all the same warnings you are, but some are the same. |
| 19:04 |
MTDiscord |
<josiah_wi> I understand the warnings, I understand a fair bit of C++. |
| 19:06 |
MTDiscord |
<josiah_wi> I see you disabled warnings on jsoncpp. I should probably make a PR to the CMake script because I already fixed the bad practice that causes flags set Minetest to be extended to libraries. |
| 19:06 |
MTDiscord |
<josiah_wi> Technically I'm not done fixing it but it'll be quick to finish. |
| 19:07 |
|
fluxflux joined #minetest-dev |
| 19:08 |
MTDiscord |
<josiah_wi> I am not intentionally enabling warnings that were explicitly disabled anywhere. I set warning flags on the minetest project from CMake. |
| 19:26 |
pgimeno |
sfan5: re https://i.imgur.com/hLsByXU.png for clarity, "disable JIT" is not what is proposed in 7043, but "reject LuaJIT bytecode" (i.e. block loading of bytecode in require, dofile, loadstring etc) |
| 19:27 |
rubenwardy |
LuaJIT bytecode is already blocked |
| 19:27 |
rubenwardy |
all bytecode is blocked |
| 19:27 |
rubenwardy |
wait actually, it could have a different signature |
| 19:27 |
sfan5 |
nah it's the same |
| 19:28 |
sfan5 |
pgimeno: the only comment referencing JIT in that issue is from May but I'm pretty sure disabling jit was proposed previously |
| 19:29 |
sfan5 |
#5987 |
| 19:29 |
ShadowBot |
https://github.com/minetest/minetest/issues/5987 -- (Security) Should JIT be disabled in server-provided client mods? |
| 19:29 |
rubenwardy |
loool, helpful reply by me |
| 19:29 |
pgimeno |
ah ok, just reacting to what I read in the image :) |
| 19:31 |
pgimeno |
I guess JIT opens up the possibility for Spectre-type exploits |
| 19:32 |
pgimeno |
(just like JavaScript did) |
| 19:33 |
rubenwardy |
is it less suspectible if you turn of JIT? |
| 19:33 |
rubenwardy |
as in, jit.off() |
| 19:33 |
|
Fixer_ joined #minetest-dev |
| 19:33 |
pgimeno |
I believe so |
| 19:34 |
pgimeno |
the timings dilute among many more instructions |
| 19:34 |
rubenwardy |
that could be a solution if you want a build with LuaJIT, but not client-side |
| 19:34 |
rubenwardy |
at CERN, Jeija was discussing using a complicated runtime linking method to link with either Lua or LuaJIT depending on client-side or server-side |
| 19:34 |
rubenwardy |
I think that was Jeija |
| 19:34 |
rubenwardy |
perhaps lets not do that |
| 19:35 |
pgimeno |
I don't think disabling LuaJIT compilation is necessary; LuaJIT is an interpreter just like Lua is. If LuaJIT is insecure then Lua is too. |
| 19:36 |
pgimeno |
So, I think jit.off() is enough. |
| 19:56 |
|
v-rob joined #minetest-dev |
| 20:07 |
v-rob |
Hmm, sorry I missed the meeting. I don't check IRC enough; if it's announced on GitHub or something, I'll get email notifications which I will see. |
| 20:16 |
rubenwardy |
sorry for not posting on Github |
| 20:16 |
pgimeno |
[1003 20:52:48] <Krock> ah right. upcoming meetings should be announced in the minetest team |
| 20:16 |
pgimeno |
they realized too late :) |
| 20:16 |
rubenwardy |
do you have any thing to add about the discussed points? |
| 20:16 |
v-rob |
I'm looking over it now |
| 20:20 |
v-rob |
Nothing really to add, no. I guess I'll write something for the roadmap brainstorm |
| 20:20 |
v-rob |
I do support issue triaging |
| 20:31 |
|
pmp-p joined #minetest-dev |
| 20:35 |
v-rob |
About my experiments with Lua drawing: I don't know much about the speed of Lua, but it seems to me that the batch call should be faster than the individual function calls |
| 20:35 |
v-rob |
Profiling happens to be very difficult for me, so I can't get good benchmarks |
| 20:37 |
|
pmp-p joined #minetest-dev |
| 20:37 |
v-rob |
Making it string-based would probably be faster, but I don't want to replace formspecs with more string formats :) |
| 20:38 |
|
Jordach joined #minetest-dev |
| 20:38 |
DS-minetest |
drawing in lua would require sscsm first, right? |
| 20:39 |
rubenwardy |
you could have a JSON representation for server->client |
| 20:39 |
rubenwardy |
and not require SSCSM |
| 20:40 |
v-rob |
What ruben said. SSCSM can come later, and everything will already be ready for it |
| 20:40 |
DS-minetest |
so, draw it in a server mod and send the stuff? |
| 20:41 |
rubenwardy |
compose it in a server mod, send the tree using JSON, draw in client Lua |
| 20:41 |
rubenwardy |
well, it's more like client Lua architects the renderer than it actually drawing |
| 20:42 |
v-rob |
I looked at Love2d like sorcerykid suggested, but it looks like it just uses consecutive functions calls like my first attempt |
| 20:43 |
rubenwardy |
batching can be invisible |
| 20:43 |
rubenwardy |
like, the consecutive functions could just add to a table |
| 20:43 |
rubenwardy |
which is then flushed |
| 20:43 |
rubenwardy |
that's nice from an API point of view, but it won't be that different from a performance point of view |
| 20:44 |
v-rob |
I don't see a good way to speed up what I have without losing functionality |
| 20:45 |
DS-minetest |
just store the calls in a table and add a final flush function |
| 20:45 |
rubenwardy |
do you have a branch? |
| 20:46 |
v-rob |
https://github.com/v-rob/minetest/tree/gui First commit is separate functions, second commit is batch call |
| 20:47 |
|
kilbith joined #minetest-dev |
| 20:47 |
v-rob |
I would prefer separate functions because something like drawer:get_font_dimensions(text) can't really be batched, it's needed immediately |
| 20:48 |
v-rob |
So a Lua-side hypertext would be very slow if there's no way to speed up the individual calls |
| 20:49 |
kilbith |
v-rob: hello, are you all focused on your refactor or the other PRs do matter? |
| 20:49 |
kilbith |
because so far you didn't give any +1 since your core-dev, I'm kinda disapointed |
| 20:49 |
v-rob |
Oh, shoot. I forgot about reviewing model[] again |
| 20:49 |
v-rob |
I'll do that right now |
| 20:50 |
kilbith |
yes, rubenwardy asked few days ago |
| 20:51 |
DS-minetest |
I think, I didn't really understand correctly what you want to archieve with the lua drawing. is it for individual custom elements or for changing what is drawn in the current formspec? |
| 20:51 |
|
pmp-p joined #minetest-dev |
| 20:52 |
v-rob |
My plan is to make GUIs entirely Lua-side. Scrap formspecs altogether except for a compatibility layer. |
| 20:52 |
MTDiscord |
<Jordach> don't get everyones hopes up |
| 20:52 |
v-rob |
Faster to develop, extensible with CSM/SSCSM, and JSON SSM API to replace formspec strings. |
| 20:53 |
v-rob |
If I can get drawing to have good performance, then it's very likely to be implemented |
| 20:53 |
DS-minetest |
ah, I see |
| 20:53 |
rubenwardy |
The disadvantage is having almost all new code |
| 20:54 |
rubenwardy |
unless there's some Love2d lib that can be adapted |
| 20:54 |
v-rob |
True, but no Irrlicht. Irrlicht's IGUIElements are pretty buggy |
| 20:54 |
pgimeno |
Luigi is a good candidate |
| 20:54 |
v-rob |
Could also potentially replace the HUD as well; unified API |
| 20:55 |
pgimeno |
https://github.com/airstruck/luigi |
| 20:55 |
pgimeno |
I talked about that with c55, he had that idea of drawing the gui on the Lua side too |
| 20:56 |
DS-minetest |
if we also draw nodes and objects in lua, it will be super customizable |
| 20:57 |
v-rob |
Sure, lets just reimplement the entire engine in Lua :P |
| 20:59 |
pgimeno |
http://irc.minetest.net/minetest-dev/2018-02-05#i_5223722 |
| 21:00 |
pgimeno |
and well, there's this: https://github.com/groverburger/lovecraft :) |
| 21:01 |
MTDiscord |
<GreenXenith> Haha, im not the only one that's done it I guess :D except they did it in a much more sane language |
| 21:04 |
pgimeno |
what language did you use @GreenXenith? |
| 21:04 |
MTDiscord |
<GreenXenith> Arguably the worst one: Python (with PyGame) |
| 21:04 |
v-rob |
The problem with Love2d is that Lua has the control whereas in Minetest C++ has the control |
| 21:05 |
* DS-minetest |
expected br***fuck |
| 21:05 |
MTDiscord |
<GreenXenith> Anyone that can make a 3d renderer in bf must be a god |
| 21:05 |
MTDiscord |
<GreenXenith> (without transpiling) |
| 21:05 |
v-rob |
Any computer that can handle it at a sane speed would have to be pretty incredible |
| 21:07 |
pgimeno |
v-rob: yeah but isn't that the point of drawing the GUI in Lua? |
| 21:07 |
v-rob |
Well, Love2d has it's own mainloop in Lua, we have our mainloop in C++ |
| 21:08 |
DS-minetest |
are you sure? the programms written in löve use a draw callback |
| 21:08 |
pgimeno |
but drawing must be done in a single frame anyway |
| 21:09 |
pgimeno |
the screen is cleared every frame |
| 21:10 |
v-rob |
I looked at Love2d's code a few days ago; the draw callback is called from a Lua while loop that manually caps the framerate itself. |
| 21:10 |
pgimeno |
DS-minetest: yes the main loop is in Lua, but I think that's not important |
| 21:10 |
DS-minetest |
ah, ok |
| 21:11 |
pgimeno |
yes, in minetest that should be a per-frame callback |
| 21:11 |
pgimeno |
similar to the current step() |
| 21:11 |
pgimeno |
(which is the same as in Love, really) |
| 21:11 |
v-rob |
See, I just don't see how Love2d can be faster than what I've already done |
| 21:12 |
v-rob |
And speed is the most important thing right now |
| 21:13 |
pgimeno |
sorry, I'm not up to date with what you've done, I'm just saying that it's not off the table to draw the GUI in Lua as long as it's client-side |
| 21:14 |
v-rob |
You can see the discussion here: https://github.com/minetest/minetest/issues/6527#issuecomment-698646731 |
| 21:15 |
pgimeno |
I was commenting in relation to this: <v-rob> My plan is to make GUIs entirely Lua-side. Scrap formspecs altogether except for a compatibility layer. |
| 21:15 |
pgimeno |
reading now |
| 21:18 |
pgimeno |
hmm, don't underestimate Love's autobatching |
| 21:18 |
pgimeno |
nice job by the way |
| 21:19 |
pgimeno |
autobatching consists of holding the draw call, and instead sending the geometry to a buffer to be drawn later |
| 21:20 |
pgimeno |
that way it draws more geometry with one single draw call |
| 21:21 |
pgimeno |
that's done under the hood, you still call draw() |
| 21:27 |
pgimeno |
the drawing functions could be implemented as FFI calls to not interrupt traces, if JIT is enabled (but if it's for CSM then JIT would probably be disabled) |
| 21:35 |
|
pmp-p joined #minetest-dev |
| 21:37 |
v-rob |
Are you saying Love batches the function calls somehow or just what to draw is batched? |
| 21:38 |
pgimeno |
it batches drawn stuff when repeatedly using the same texture; if you change the texture, it draws the previous batch and starts a new one |
| 21:39 |
pgimeno |
in OpenGL it's a lot faster to draw many polygons at once, than to draw them with separate draw calls |
| 21:39 |
v-rob |
Ah |
| 21:40 |
pgimeno |
that may have been a bottleneck in your tests |
| 21:41 |
DS-minetest |
but current gui doesn't do this either, does it? |
| 21:41 |
DS-minetest |
in C++ |
| 21:41 |
v-rob |
No, it doesn't batch either, but performs extremely better than my Lua drawing |
| 21:41 |
pmp-p |
to draw fast, use virtual dom patching and a C++ renderer |
| 21:42 |
pgimeno |
I don't know if it uses scene nodes for the GUI, if it does then there's a chance that it batches the calls |
| 21:42 |
pgimeno |
(I haven't looked into the formspec code) |
| 21:43 |
v-rob |
Tested my Lua drawing again. Images are definitely the bottleneck; rectangles alone barely dent the framerate |
| 21:44 |
v-rob |
Maybe I should experiment with driver->draw2DImageBatch |
| 21:44 |
pgimeno |
anyway, interrupting a trace is probably a bottleneck in Lua, because then it needs to keep interpreted mode |
| 21:45 |
pgimeno |
and calls to C++ interrupt traces |
| 21:46 |
pgimeno |
by the way, it would be nice to look into converting some core functions to FFI for that reason |
| 21:46 |
v-rob |
The second implementation only uses one single draw call with table definitions. Does pushing/popping to the Lua stack interrupt traces? |
| 21:47 |
pgimeno |
the Lua stack? not sure what you mean, if you mean in the Lua side then no |
| 21:47 |
v-rob |
The Lua stack where parameters to function calls are accessed in C++ |
| 21:48 |
pgimeno |
in the C++ side there's no tracing, all tracing occurs in the Lua side |
| 21:48 |
pgimeno |
when the C++ function gets called, that interrupts the trace |
| 21:48 |
pgimeno |
(unless it's an FFI function) |
| 21:49 |
v-rob |
Well, my second implementation (did you read past the first post in the link I gave?) only has one function call per frame |
| 21:49 |
v-rob |
But is just as slow |
| 21:50 |
pgimeno |
no I didn't read past that, sorry |
| 21:52 |
pgimeno |
you may be hitting other trace breakers, there are quite some of these, see wiki.luajit.org/NYI |
| 21:53 |
DS-minetest |
image[ uses driver->draw2DImage for drawing btw. https://github.com/zaki/irrlicht/blob/c7a766c2909f601e81bc44d28ecc12c738d7a0f7/source/Irrlicht/CGUIImage.cpp#L71 |
| 21:53 |
pgimeno |
anything in that page that says not compiled, interrupts a trace |
| 21:55 |
pgimeno |
interestingly, I've just noticed that function calls are compiled in 2.1 stitch (whatever that is - a branch?) |
| 21:58 |
DS-minetest |
:O I've actually experienced CALLT being slower than normal CALL (I had to introduce a local variable: https://github.com/Desour/minetest/blob/595eeab282b0dffbffb2c98a9d333866dd43a407/builtin/common/vector.lua#L32) might that be bacause of the >CALLT partial Tailcall. Some tailcalls to frames lower than the starting frame of the trace are not compiled. ? |
| 21:59 |
|
Andrey01 joined #minetest-dev |
| 21:59 |
pgimeno |
could be that, yes |
| 22:01 |
v-rob |
Images have twice the amount of parameters that rectangles do... This might be something. |
| 22:01 |
v-rob |
I think I'll try making both have the same number of args; see if the speed is still different |
| 22:02 |
pgimeno |
if the images had to be rendered with alpha, that's a huge performance penalty |
| 22:03 |
v-rob |
The thing is, I'm doing the same drawing as image[] and box[]. I doubt it's the drawing. |
| 22:03 |
v-rob |
button[] does way more drawing, but isn't slow |
| 22:06 |
DS-minetest |
your code on github draws with alpha |
| 22:08 |
Andrey01 |
#10363 is ready for merging I think |
| 22:08 |
ShadowBot |
https://github.com/minetest/minetest/issues/10363 -- [MainMenu] Add clear button and icon for search one. by Andrey2470T |
| 22:09 |
|
Fixer joined #minetest-dev |
| 22:10 |
Andrey01 |
#10423 is still in working out process, #10450 is ready, but not ready for merging since it depends from first one |
| 22:10 |
ShadowBot |
https://github.com/minetest/minetest/issues/10423 -- Add `table.find` and `table.find_if` methods. by Andrey2470T |
| 22:10 |
ShadowBot |
https://github.com/minetest/minetest/issues/10450 -- Add GUI for '/help mods' command. by Andrey2470T |
| 22:12 |
Andrey01 |
anyway, #10450 can be reviewed now |
| 22:12 |
ShadowBot |
https://github.com/minetest/minetest/issues/10450 -- Add GUI for '/help mods' command. by Andrey2470T |
| 22:14 |
|
Fixer_ joined #minetest-dev |
| 22:15 |
v-rob |
Oof, never mind. button[] has terrible performance |
| 22:17 |
* DS-minetest |
doesn't think he ever saw a gui with >100000 buttons being drawn at once |
| 22:18 |
v-rob |
I did earlier tests, and I thought I tested button[]... |
| 22:18 |
v-rob |
And this was only 1000 |
| 22:21 |
v-rob |
Well I'm a fool |
| 22:21 |
v-rob |
I did some more comprehensive testing, and the batch drawing is barely worse than the formspec |
| 22:21 |
rubenwardy |
lol, sounds like programming to me |
| 22:22 |
v-rob |
Oooooooook, I guess Lua-side drawing is feasible after all. |
| 22:23 |
v-rob |
I guess I'll see if the multiple function call version performs as well |
| 22:27 |
DS-minetest |
btw. not that I knew anything about it, but would it make sense to compile csm lua to webasm first? I've heard that webasm is fast and secure |
| 22:40 |
v-rob |
Multiple function calls do appear to be slower than the batch |
| 22:40 |
v-rob |
Anyway, I have to be going |
| 22:40 |
|
Taoki joined #minetest-dev |
| 22:42 |
MTDiscord |
<Jonathon> i recall seeing something here earlier I thought but can't find it now, / doesn't open chat anymore? |
| 22:43 |
DS-minetest |
Jonathon: there's an issue: #10440 |
| 22:43 |
ShadowBot |
https://github.com/minetest/minetest/issues/10440 -- Regression: "/" not toggling chat anymore |
| 22:44 |
MTDiscord |
<Jonathon> ah ok, ty |
| 22:47 |
pgimeno |
~tell v-rob Please test the drawing code with JIT off too |
| 22:47 |
ShadowBot |
pgimeno: O.K. |
| 22:49 |
pgimeno |
are dead keys fixed with any of the recent keyboard fixes, by the way? |
| 23:22 |
rubenwardy |
Merging #10173 in 10 |
| 23:22 |
ShadowBot |
https://github.com/minetest/minetest/issues/10173 -- Deprecate get_player_velocity and add_player_velocity by rubenwardy |
| 23:32 |
|
homthack joined #minetest-dev |
