Implement nice GUI

[LaG1924]

Dear ImGui is good, but it is hard to tune it to Minecraft.

So, it should be replaced with own custom widget system.

[MrDullDev]

Why would we need to use custom widget system though? They are a few of open source embedable and modable widget systems , like MyGui(it is used by openmv and freeablo for example), nanogui(gpu accelerated gui framework, should be fairly customizable from what i seen) and rmlui(fork of now deprecated librocket, lacks solid userbase, but their github is pretty lively and they claim that they fixed most issues of librocket).

I mean developing widget system seams like a wasted effort, when the same thing can be done through modifying(aka adding new widgets/drawing custom themes) existing ones that were developed for such things. imgui is just not suited for visual customization since it is not targeted towards an end-user(which is actually stated in their readme on github), therefore lacks important eye-candy features.

[LaG1924]

Sorry for the late answer, I started doing research on this issue, but then got distracted and forgot about it.

One of the main principles of our UI System is that it should be easily customizable from lua scripts (other scripting frontends may be added later). I thought about a declarative model, but there may be others (for example, an API suspiciously similar to the one used in Forge and the ability to execute native mods through JNI can make this project very interesting).

NanoGUI cannot be embedded if I remember correctly. MyGUI has a slightly overcomplicated API, which may detract from its usability. To be honest, I've already looked into the available GUI systems (and chose Dear ImGui), but now I don't remember exactly what scared me off of MyGUI. RmlUI looks interesting enough, and even embedding shouldn't cause much trouble (they even have lua -api), but how appropriate is it to use HTML / CSS for something that should work fast on all platforms?

Dear Imgui was used as a quick-to-implement solution at a time when the lack of any gui was very difficult to use AC.

Also, I would like to mention that using a third party library (not header-only) will make dependency management even more difficult here, so solving #15 first would be a better solution.

[MrDullDev]

If perfomance is not one of our main concerns(i mean small gui overlay is not that resource demanding, so it wouldn't be unreasonable to be a little wasteful) we can use some of gui frameworks intended for embedded devices( aka microcontrollers, soc's, etc.). They are usually little to no dependencies in those frameworks and they usually require little to no effort to implement the renderer(like a few c functions to draw pixel, line and a triangle, or just straight up bitmap flush function). Though since they intended to be used on a low perfomance device they are usually lack some of hardware demanding eye candy like opacity or anti-alising, or sub-pixel rendering, also their rasterization algorithms are usually inferior and can be even defined in compile time(aka they will be able to run only in certain resolution). Also since renderer interfaces for them are that simple, they will perform much less efficiently compared to their desktop counter part(like imagine drawing something dot per dot). As for my recommendations in those type of libraries, i would choose either lvgl(https://lvgl.io/) or ugui(https://embeddedlightning.com/ugui/), since the first one is quite popular and big, while the second one is quite small, easy to use and friendly to port. I used both of them to some extent while messing around with a display on stm32 based project of mine.

About html concern, here's actually the paper that compares qml with html5 https://github.com/amirkogit/QtTestGround/blob/master/learn_qml/qmlhtml_whitepaper/WHITEPAPER_HTML5vQML.pdf , there author compares the perfomances using normal web engine for html, unlike librocket which uses more faster custom engine, which is not exactly html5 actually, but more limited(and therefore it is less bloated and faster)xhtml(like the one used in that jabber extension) with sprinkles on top. My point is that since they are not limited by bloated html5 standart(xhtml is quite compact actually) and using somewhat unsophisticated(compared to something like chrome's blink that is) custom engine for rendering i doubt we are gonna have severe problems with that(as i said earlier i doubt simple gui layout overhead is gonna make a difference) considering that even blink is not that severly outperformed by qt.

[uis246]

we can use some of gui frameworks intended for embedded devices( aka microcontrollers, soc's, etc.)

Framebuffer access cause syncronization in opengl

[uis246]

About html concern, here's actually the paper that compares qml with html5

Html. In game engine. Rly?

[LaG1924]

Performance is of course important. But, I'm sure that on a linear scale, performance <-> features (or rather embedded devices <-> modern web frontend) can find a more balanced solution. Considering that AC should work stably on fairly weak mobile devices, spending up to 40% of the frame budget on rendering a graphical user interface is stupid. As well as using something that does not support resolution scaling or 9-sliced ​​widget textures (similar to those used in the original MC and will probably be used in AC).

Okay, I'm almost convinced that using a limited subset of HTML is a good idea. But there is one more thing that worries me: as far as I know (I am not a front-end developer at all, so I could be wrong), so that it is possible to add or modify elements in the tree (I mean third-party mods that may want to add some buttons to the main menu or inventory window), they will not only have to learn a completely different API (XHTML instead of Forge-like), but also generate the entire markup document, which is quite problematic in terms of overhead and coding comfort.

[MrDullDev]

Well, regarding "in the middle solution" we can always succumb to the dark side and use qt quick. It is fairly bloated(binary size is humongous), but their promo advertises quite good perfomance even on very low-perfomance systems like mcu's while retaining the eye-candy. It is also usable in opengl and directX context. The problem is qt ecosystem, since they pretty much live in the world of their own, also it is somewhat of a pain if it is not the top dog of the main loop(though it doesn't mean it can't go without it https://doc.qt.io/qt-5/qquickrendercontrol.html). I also seen some article about embedding it in a game engine in my local language, so someone does use it that way.

Regarding the forge api compatibility, i doubt that designing our gui around it is a good idea, since it's gonna be harder to expand on it, it will also add quite heavy developer load from the get-go(since gui is quite basic feature for a visual game, we will need to implement the whole or majority of the forge api as a first matter lf buisness which is gonna be quite a hassle), also i heard forge api is quite convoluted in terms of api design anyway. Not to mention that the benefits of it are questionable, since writing forge compatability layer/bridge in java is gonna be a whole other project in itself and without it mod developers are gonna be forced to learn new tools anyway like lua or cpp, so i don't see how forge like api is gonna help them any.

The way i see it, it will be better to focus on gui without regards to forge api, the best we can do is implement gui in a way isomorphic to that of original mc, that's gonna reduce the overhead of compatability layer if we are gonna write one one day(which is a big if).

The overhead of the separate markup documents shouldn't be that big(size wise), i mean it's just a text file that is dynamically loaded after all. As for coding comfort, i think it is quite convenient to be able to be able to separate front-end and backend so cleanly, it also comes with a benefit of adding minute changes on the go. I am more worried about xml parsing, since it is hard to parse and it is quite hefty when it comes to big documents(memory print wise at the very least), so it can be potentially troublesome to make it run on machines with limited ram(like mobile devices)

[LaG1924]

It's not a good idea to use QtQuick ... Apart from the embedding problems you mentioned (their own main loop, excessive overloading with various unused dependencies, difficulties in embedding the render, not using the standard language library), I would also like to note the licensing problems.

Maybe you're right about the Forge API. In any case, we can do something similar to Forge after the introduction of the gui in the form of a high-level api. And using JNI to natively connect mods from the original MC: JE is something like a big bright happy, but distant dream.

Yes, I also meant DOM parsing. It is quite expensive in terms of CPU time and RAM (at least judging by what I see on desktop Chrome on fairly simple but large pages). Also, a GUI in XHTML will add overhead during development, that is, to add the same button, you will not only need to call one command to add a button, but get the current state of this page, add the desired element there, and then re-parse the new page and update render. But, I hope, there are simpler ways, I just don't know about them yet.

[MrDullDev]

Well regarding dependencies of qt-quick, it has much, much, much lesser dependencies than your usual qt framework(aka they tried to make it not to depend on their whole monstrosity of ecosystem). Regarding the licensing issue, I believe AC is compliant with LGPL which their software can be distributed under.

Like what i am saying is qt-quick CAN be used, but this monstrosity is potentially detrimental to the debugging and fixing issues, since it is build with qt framework philosophy in mind and has a number of redundant features that gonna not only make debugging a living hell, it will be devastating to work around it without utilising "qt-ways" of development. In other words, from my perspective adapting qt-quick is gonna require as much work as developing our own widget system, so i doubt it is worth it(power of dark force is tempting, but we must resist!).

Regarding the dom editing, you don't actually need to re-parse the whole thing, since you already have the structure in memory, you just need to rerender it after the changes, here's the diagram from their doc's https://mikke89.github.io/RmlUiDoc/pages/data_bindings/model-view-controller.svg it shows how interactions work in general. Here's the small snippet of their doc's where they elaborate a little on their approach https://mikke89.github.io/RmlUiDoc/pages/data_bindings.html

Also it might be still a good idea to look into mygui, even though their wiki is quite lacking(also there are no normal tutorials or guides on it that i could get my hands on), they seam like a mature framework, they don't require an entire zoo worth of dependencies(we pretty much need only font related dependence freetype which is reasonable), they have conveniently placed platform section in their project that potentially helps us in embedding it in our project(though since i didn't figure out how they work, i am not sure if it can be used outside main loop in already initialized opengl context, but i am somewhat sure that it can be done), they have an abundance of customizable widgets(from themes to functionality), they have plugin system, they are used by similar projects(there is gotta be a reason, right?)

On a side note, maybe it's good idea to integrate a internalization framework(like gettext) at this stage. I mean if gui is gonna be revised anyway, it's not that hard to deploy a function on every displayed string while we are at it.

[MrDullDev]

we can use some of gui frameworks intended for embedded devices( aka microcontrollers, soc's, etc.)

Framebuffer access cause syncronization in opengl

Not every embedded framework requires direct frame buffer access, they usually don't really care where their bitmap ends up, so for all i know, we can just render the output as a texture or smthg.

About html concern, here's actually the paper that compares qml with html5

Html. In game engine. Rly?

Don't see nothing wrong with that, xml been used for gui quite extensively, so why html, which has the same ancestors(aka sgml) woud be suprising? I do agree that current html standart is too much of a bloat for that purpose, but they use subset of xhtml and html4 as a base(aka not all tags from xhtml and html4 are there, syntax though is xml compliant), in fact here's the WHOLE list of built in elements of that markup language of theirs https://mikke89.github.io/RmlUiDoc/pages/rml/element_index.html . As you can see it is fairly compact and does not include overcomplicated notions. Also i updated my knowledge regarding xml parsing, so we actually can reduce memory foot print during parsing as long as we are willing to wait longer(considering that it takes a few seconds to parse even a few tens of megabytes worth of xml, i doubt we would suffer if we will sacrifice it a little of time during initialization on devices with small ram, also we can always just patch out the whole xml parsing stage and embed already initialized dom model directly into our code)

What i am trying to convey here is that rmlui is not some obscure webkit fork, but a a rather small dedicated gui solution that adopts xml based format for declaring the layout and style, that is parsed into a dom model and utilises tags/styles somewhat similar to that of html4+css2(or xhtml+css2 if we account for the fact that it is xml based), plus extends it with some interactive features of their own that are similar to those in html5. So the key word here is similiar.

[uis246]

we can just render the output as a texture or smthg.

Ok. Read after write dependency.

Also: https://github.com/uis246/AltCraft/blob/ui/src/GameUI.cpp https://github.com/uis246/AltCraft/blob/ui/src/RendererUI.hpp

[MrDullDev]

we can just render the output as a texture or smthg.

Ok. Read after write dependency.

I am not sure why would it trigger a race condition though, we don't really do anything to the displayed image after we already created the bitmap, we also don't need to redraw it every frame, for all we care we need to update that texture only when we interact with it and it changes it's appearance or in the case of resizing, in both cases previously drawn bitmap is irrelevant.

I am not sure what i am missing, can you elaborate a little?

[uis246]

https://github.com/MrGooogo/scanmem/commit/c64c6e0b49c0dccb5a5619e6ee193e7f34bdaba2#diff-92817e54c697fd6395db7e9eca8f2468538e83db228823136eaa96d834d74f76R112

Ясно

[LaG1924]

Ясно

You can't just accuse people of speaking Russian on the basis of one commit.

it might be still a good idea to look into mygui

I like RmlUI better. Are there any other reasons not to use it?

On a side note, maybe it's good idea to integrate a internalization framework(like gettext) at this stage. I mean if gui is gonna be revised anyway, it's not that hard to deploy a function on every displayed string while we are at it.

MC uses assets with localized text. Reading and extracting utf-8 from them won't be a problem. But I'm wondering if there is a better solution than one function to convert the id of a string to a localized string based on the global variable of the current language.

[MrDullDev]

I like RmlUI better. Are there any other reasons not to use it?

I do think that rmlui would be a better choice, but the fact that they are not that much dev's using it is kinda alarming(i am not the only one with concerns regarding this matter https://stackoverflow.com/questions/63838246/why-librocket-was-abandoned-and-why-librocket-rmlui-are-not-used-widely , though i do find this question strange, since not only rmlui is not unique, since there are the likes of scitter and webview, but also stackoverflow is not exactly the place for questions like that), also the fact that mygui has been there for much longer and have been used somewhat extensively by a few other projects of similar nature probably makes it a better choice if we want to encounter less bugs along the way(though the fact that community have somewhat died and the main traction force for it is their ogre3d platform makes it less than ideal choice for our uses).

To summarise:

rmlui

pros:

• separate user-friendly markup language
• decent documentation
• easy to embed(+there is a tutorial)
• easy to slightly change gui without recompilation
• quite active development(plus somewhat active community on gitter)

cons:

• small user base(aka potentially buggy and can become abandon ware sometime in the future just like original librocket)
• xml parsing during initialization

mygui

pros:

• Mature framework(been there long enough, got rich widget system, etc.)
• Used by other similar projects(freeablo in fact switched from librocket, aka predecessor of rmlui, to mygui in 2017 https://freeablo.org/2017/02/25/misc.html )
• Can be atleast partially defined by xml
• Throughout API documentation
• There at least was a thriving community based around this framework

cons:

• Shitty documentation on anything apart from api(though openmv dev says they are some good ones in russian, but i failed to find even them)
• Stagnant user base(i don't see anything new made with it, forum is quite inactive, etc.)

• Oriented towards complimenting other 3d-engine

  But I'm wondering if there is a better solution than one function to convert the id of a string to a localized string based on the global variable of the current language.

None that i am aware of(not that it means much, since i've seen only like 6 of them). The variants i've seen so far do exactly that, though the details differ(some support gendres, some store database in xml format like apple, some provide keys that are not displayed under all circumctances, etc.) Gettext is just most wide spread non-platform dependent framework that i know of(on a side note there is no "key" in gettext format per se, original phrase acts as a "key").

You can't just accuse people of speaking Russian on the basis of one commit.

It's not like being russian is a bad thing though, but i do find it strange to try to switch the language midconversation, it's kinda confusing.

[LaG1924]

I do think that rmlui would be a better choice

Even with all the shortcomings taken into account, RmlUi looks more interesting than MyGui. It's not very fair to judge that, but RmlUi (and especially libRocket) has more likes on the github than MyGui and the RmlUi development process on the github is also more active. However, I think that you can ask RmlUi if they have any problems (especially in the context of that article about freeablo) and if there is any large project that uses this library. Also I found a question on reddit of a person who wanted to select a gui library and chose rmlui, we can ask him about the pitfalls (https://www.reddit.com/r/gamedev/comments/gr64qt/looking_for_an_opensource_c_ui_library_for_games/).

on a side note there is no "key" in gettext format per se, original phrase acts as a "key"

Gettext does not have a "key" and this is the main difficulty in using it. The original MC: JE assets (which we mainly rely on) have extensive localization of everything, but keys are used there, so it will not be very easy to adapt GetText (and you will also need to generate some special files, if I understood the principle of using GetText from one random tutorial). However, if internationalization is almost always just one function for converting one string to another, then I think we can easily implement it ourselves.

It's not like being russian is a bad thing

It's just one fun fact that despite the use of English and the lack of publications about AltCraft in Russian, all three (I count myself, but I don't count you, because I'm still not sure) people contributed more than a couple of tickets in AC were from Russia. It is possible that these are some problems with SEO or simply Russia is a country of programmers who love Minecraft.