v-rob's roadmap

For people working on the C++ code.
Post Reply
User avatar
v-rob
Developer
Posts: 970
Joined: Thu Mar 24, 2016 03:19
GitHub: v-rob
IRC: v-rob
Location: Right behind you.

v-rob's roadmap

by v-rob » Post

Well, I guess my old roadmap was 100% out of date in every respect, so time to rewrite it. It's all about the GUI, of course, but I've limited my scope to mostly medium-term goals right now.

Text

Minetest's Unicode support is none too good. Not horrible, but not good enough. Now, I'm a native English speaker, so this hasn't ever affected me much, but right-to-left languages like Hebrew are totally out of the question, and things like word wrapping, cursor movement, and whatever don't take Unicode into account at all. My first order of business is fixing this. I've done extensive (meaning months of research) research on this, and I've got a pretty good idea of all the things that go into proper Unicode support.

Still, it's hard. I've finally got libraries and their respective necessary APIs pinned down. All that's left is to design and write my code that integrates it all (which happens to be quite difficult--there's so much stuff to synthesize). It's getting there, though, and once it's done, we will have text rendering APIs ready for Minetest to use everywhere (although I'm not planning on updating all the formspec code to use it yet).

The final benefit is that we will no longer rely on Irrlicht at all in terms of text rendering. A "sometime in the future" API would also be server-sent fonts, but I don't plan on that until I actually get the cold, hard GUI code rolling.

Drawing

This one's pretty simple: wrap raw OpenGL calls in simple wrapper classes that do everything the most things in the GUI could ever want, while still leaving raw OpenGL available for more complicated things, like 3D rendering and shaders in the GUI. Since it uses raw OpenGL, there's no reliance on Irrlicht.

Events

Simple in concept. Finish replacing all of Irrlicht's events and windowing code for each specific platform with a single SDL2 API, and allow SDL2 to be used directly from Minetest while retaining Irrlicht wrappers. Some work has already been done on this. This allows us to incrementally move events and windowing away from Irrlicht, lessening our dependence on it, and allows the GUI to use SDL2's far, far, superior event system, and (for Unicode) full IME support on all platforms.

The actual GUI

This is the somewhat longer term goal. Once the above three are completed, the GUI has a solid foundation to rest on, and all that needs be done is make a GUI on top of it. (How hard could it be? :P) With proper low-level APIs, especially a powerful one for text rendering, no individual thing in the GUI will be overly complex to do. However, it's a lot of stuff put together.

However, by the time I get the basic GUI code done and a few elements, other people will be able to chip in as well, just in the same way that people can make new formspec elements right now. If that happens, it won't be nearly so much.

3D stuff

We'll need 3D stuff for the GUI, of course. There's the necessity of model[]-esque elements, of course, but I also think that 3D things are nifty, and we should allow more nifty 3D things in Minetest :) Shaders for e.g. blurring backgrounds of elements is another thing I think is a really good idea. However, my vision of APIs for these things is blurry at best right now, especially considering that my knowledge of OpenGL is minimal at best right now (although I will have to learn some of it sooner or later to get that drawing API hammered out).
Last edited by v-rob on Sat Feb 05, 2022 04:01, edited 4 times in total.
Core Developer | My Best Mods: Bridger - Slats - Stained Glass

User avatar
jp
Banned
Posts: 947
Joined: Wed Dec 18, 2013 09:03
GitHub: kilbith
Location: France

Re: v-rob's roadmap

by jp » Post

Here's my reply: all I have to say is that I can't wait to make a Quake clone in the GUI thanks to the new API.

User avatar
Linuxdirk
Member
Posts: 3218
Joined: Wed Sep 17, 2014 11:21
In-game: Linuxdirk
Location: Germany
Contact:

Re: v-rob's roadmap

by Linuxdirk » Post

v-rob wrote:
Thu Feb 25, 2021 21:03
SSCSM
I pretty much dislike the whole idea of giving the client MORE control when it should have LESS control. In the end the client should be nothing more than a stupid interface to what the server provides. Neither should it do own logic nor should it run own scripts.

You ideas sound awesome but ut was a massive mistake to release CSM in it's current form and without making 100 percent sure the client is as dumb as possible and is not being made smarter I really hope that SSCSM won't come at all.

Fortunately right now server owners can prevent most of CSM of an unmodified client, but when client-side modding (or client-side scripts) becomes mandatory for drawing formspecs then there will be massive issues.

User avatar
philipbenr
Member
Posts: 1897
Joined: Fri Jun 14, 2013 01:56
GitHub: philipbenr
IRC: philipbenr
In-game: robinspi
Location: United States

Re: v-rob's roadmap

by philipbenr » Post

I personally think a feature-rich but tightly-bound client side API would be great. I know that rule number 1 is never trust the user, but at some point you can't do all the work server side. Nor does it make sense to, especially for a game like Minetest, where customization for each person to their liking is the basis of the whole platform.

SSCSM will be a wild ride in terms of implementation, I wish you luck in getting the features you're aiming for while battening down the hatches...

User avatar
v-rob
Developer
Posts: 970
Joined: Thu Mar 24, 2016 03:19
GitHub: v-rob
IRC: v-rob
Location: Right behind you.

Re: v-rob's roadmap

by v-rob » Post

Linuxdirk wrote:
Fri Feb 26, 2021 09:07
I pretty much dislike the whole idea of giving the client MORE control when it should have LESS control. In the end the client should be nothing more than a stupid interface to what the server provides.
I agree with you in disliking CSM and want it removed, but I don't have the same opinion for SSCSM. A basic tenant of SSCSM is that it gives the client no more control, but gives the server a lot more control. In other words, SSCSM is server code, but it runs on the client because that's where it's needed. The user doesn't even get to touch, see, or modify SSCSM code themselves. The client has no more privilege than it did before.

I know that there's a worry that people can modify their clients to provide their own scripts into the SSCSM environment, but if they're modifying their clients, they can do anything SSCSM could do anyway. Therefore, even cheaters have no more control. My only concern myself in this line is security and making sure that malicious clients/servers can't do any real damage to the other.
Linuxdirk wrote:
Fri Feb 26, 2021 09:07
Fortunately right now server owners can prevent most of CSM of an unmodified client, but when client-side modding (or client-side scripts) becomes mandatory for drawing formspecs then there will be massive issues.
Actually incorrect. I understand the worry, but code already ran on the client before CSM existed: the main menu is entirely coded in Lua. The GUI will run under the same principle of being internal Lua separate from modded Lua. I mean, many web browsers implement their user interfaces in JavaScript, but JavaScript on webpages can still be disabled without it affecting the user interface. The same principle will apply with the GUI, meaning CSM can be enabled, disabled, removed, etc without touching the GUI at all.

Of course, it's a fancy of mine that there won't have to be a SSM API for GUIs, only a SSCSM one, but that's idle fancy; there's too many problems to make this an actual reality.
Core Developer | My Best Mods: Bridger - Slats - Stained Glass

User avatar
Linuxdirk
Member
Posts: 3218
Joined: Wed Sep 17, 2014 11:21
In-game: Linuxdirk
Location: Germany
Contact:

Re: v-rob's roadmap

by Linuxdirk » Post

v-rob wrote:
Sat Feb 27, 2021 20:54
I mean, many web browsers implement their user interfaces in JavaScript, but JavaScript on webpages can still be disabled without it affecting the user interface.
So we need SSCSM whitelists in our clients now like we have in our browsers? Otherwise servers can do whatever they want in the client using the local computer’s resources.

And because servers can lie about the mod’s name this whitelist needs to be function-wise and not basing on the reported name of the mod.

User avatar
rubenwardy
Moderator
Posts: 6972
Joined: Tue Jun 12, 2012 18:11
GitHub: rubenwardy
IRC: rubenwardy
In-game: rubenwardy
Location: Bristol, United Kingdom
Contact:

Re: v-rob's roadmap

by rubenwardy » Post

I disagree with making it client-side only, in the long run. I think that having an API to show GUIs from the server without sending Lua code is very useful. This can come later though, ofc
Linuxdirk wrote:
Sat Feb 27, 2021 22:23
So we need SSCSM whitelists in our clients now like we have in our browsers? Otherwise servers can do whatever they want in the client using the local computer’s resources.

And because servers can lie about the mod’s name this whitelist needs to be function-wise and not basing on the reported name of the mod.
We already have sandboxing on the server and the client. The client sandbox is much more strict - it doesn't do anything with mod names, and there's no trusted_mods setting.
Renewed Tab (my browser add-on) | Donate | Mods | Minetest Modding Book

Hello profile reader

User avatar
v-rob
Developer
Posts: 970
Joined: Thu Mar 24, 2016 03:19
GitHub: v-rob
IRC: v-rob
Location: Right behind you.

Re: v-rob's roadmap

by v-rob » Post

rubenwardy wrote:
Sat Feb 27, 2021 23:01
I disagree with making it client-side only, in the long run. I think that having an API to show GUIs from the server without sending Lua code is very useful.
I'm not planning on it. It would be nice since it would make my job easier without any loss in functionality, but that's not a good enough reason :) A server-side API has been on my list from the start.
Core Developer | My Best Mods: Bridger - Slats - Stained Glass

User avatar
rubenwardy
Moderator
Posts: 6972
Joined: Tue Jun 12, 2012 18:11
GitHub: rubenwardy
IRC: rubenwardy
In-game: rubenwardy
Location: Bristol, United Kingdom
Contact:

Re: v-rob's roadmap

by rubenwardy » Post

Ah I must have misread "entirely in client-side Lua", I thought you meant no server Lua API, but little client-side C++ makes more sense
Renewed Tab (my browser add-on) | Donate | Mods | Minetest Modding Book

Hello profile reader

User avatar
v-rob
Developer
Posts: 970
Joined: Thu Mar 24, 2016 03:19
GitHub: v-rob
IRC: v-rob
Location: Right behind you.

Re: v-rob's roadmap

by v-rob » Post

I've added three points to the second header: refactoring the sound system and supporting proper music; videos and streaming; and more font stuff.
Core Developer | My Best Mods: Bridger - Slats - Stained Glass

User avatar
v-rob
Developer
Posts: 970
Joined: Thu Mar 24, 2016 03:19
GitHub: v-rob
IRC: v-rob
Location: Right behind you.

Re: v-rob's roadmap

by v-rob » Post

OK, this was entirely out of date with my current plans, so I rewrote it. I expect it to be ignored by most people, which is really too bad because I don't like feeling like one of three or so people that actually seems to care about the state formspecs are in and what's trying to be done about it.

I feel like most people don't expect the GUI remake to be finished at all, which is really discouraging. I've been at it for years now, and I will absolutely not give it up at this point. I've sunk too much work, planning, effort, time, and expectations to give it up and leave everything to rot. I care about it, and wish more people seemed to care about it as well.
Core Developer | My Best Mods: Bridger - Slats - Stained Glass

User avatar
MisterE
Member
Posts: 693
Joined: Sun Feb 16, 2020 21:06
GitHub: MisterE123
IRC: MisterE
In-game: MisterE

Re: v-rob's roadmap

by MisterE » Post

id like to voice my support for this. while you may be one of three people who care about the gui *and* know how to do smth about it, I and others deinately can't wait or you to finish it so we can start making beautful and functional modern guis

User avatar
sorcerykid
Member
Posts: 1841
Joined: Fri Aug 26, 2016 15:36
GitHub: sorcerykid
In-game: Nemo
Location: Illinois, USA

Re: v-rob's roadmap

by sorcerykid » Post

I'm really happy to hear that one of your long term visions for the engine is adding support for streaming music and videos. Both of which would be a huge benefit for my virtual nightclub game.

Right now I've got the streaming music component working as a background process in conjunction with the WebAudio API which is synchronized via a keep-alive CGI process with the Minetest server for positional audio playback. It would certainly be nice though, to have this full integrated into the engine, so I don't have to rely on a Web browser running in the background :)

Also, I'm soon going to experiment with playback of music videos in-game, by hacking around with much improved dynamic media API. I'm thinking with suitable buffering, it might be possible to transmit live video feeds as low-resolution texture animations on upright sprites, so I can finally show music videos in my nightclub. Of course, a native solution would be much preferred.

Post Reply

Who is online

Users browsing this forum: No registered users and 4 guests