Jump to content

Instead of getting rid of HTML, make use of features in CoherentGT


Nayropux

Recommended Posts

I'm going to keep this short, since I haven't played in 3 months:

 

Removing HTML is overkill. The UI rendering solution you use in game already supports dynamically updating HTML without having to rewrite the entire content. See data binding in: https://coherent-labs.com/Documentation/cpp-gt/df/dfb/_h_t_m_l_data_binding.html

 

If you're worried about performance, this will be more efficient than your new Lua solution. You should make use of the technology you have already licensed and use instead of reinventing the wheel. More advanced UIs could be generated with the use of JS on top of this.

Link to comment
Share on other sites

Compared to LUA?

 

It is the inefficient lower level canvas operations used for UI and screen graphics that are killing performance, so whatever high level script language you use on top is irrelevant to the performance.

 

Link to comment
Share on other sites

At first glance, I'm not sure this solves the problem.  Sure, clients can databind to a state, but the clients still have to be sent the data.  It synchronizes the client's UI vs the client's game, but the client's game still has to get the HTML from the server, which is (supposedly) the problem

Link to comment
Share on other sites

8 minutes ago, Dimencia said:

At first glance, I'm not sure this solves the problem.  Sure, clients can databind to a state, but the clients still have to be sent the data.  It synchronizes the client's UI vs the client's game, but the client's game still has to get the HTML from the server, which is (supposedly) the problem

It only has to get the HTML from the server once, not once every frame. This is a huge difference.

Link to comment
Share on other sites

35 minutes ago, Nayropux said:

It only has to get the HTML from the server once, not once every frame. This is a huge difference.

that's what's up.... NQ using a violin to butter toast.


Take a look....
It's called Data Binding

C++ triggering JavaScript, Javascript triggered C++ (heehee)
https://coherent-labs.com/Documentation/cpp-gt/d9/d2b/binding__c_x_x.html

 

AAAAND databinding!
https://coherent-labs.com/Documentation/cpp-gt/df/dfb/_h_t_m_l_data_binding.html

 

So many options to improve performance by a lot... it is inconceivable that a game should refresh and send the whole DOM on every tick or frame... yet NQ did it. Every nail is stepped on.

Link to comment
Share on other sites

There seam to be a lot of misconceptions in some of your heads.

 

The lua problem.

 

Lua is slow, as any interpreted language is. But lua can be very fast if data treatment functions are implemented natively in C and exposed to Lua.

It would be great if lua could run in multiple threads, it cannot because variables have to be synced.

Some Lua commands will ask the server for info. Those can lag as the server lags to reply.

 

All this 3 problems are common on any "scripting" language. Any JS or phyton would have exactly the same issues.

 

The HTML problem.

 

The html is acquired only twice from the server

When the player enters the element rendering instance. 

When something changes HTML code.

 

There are 2 issues here.

One is HTML code being heavy on the embedded browser (like complex svg animations)

The other is having constant changing of code by the lua element.

 

I dont see how JS would improve this.

How would SVG animations would become lighter using JS or how a player would send the changed html to other players.

 

 

Suggestions

In my view NQ could do some stuff to help:

Lua: Add allot more C libraries to reduce lua processing.

Lua: Allow multi threaded lua to run (even in the same unit) if variables are not a dependency.

Lua: Create asynchronous server requests. Where we could ask for radar data and quit without waiting for a reply and execute a "filter" on radar when data arrives.

 

html: set max resources occupation and automatically lower html rendering rate on that specific screen if processing is too high and kill rendering if memory is too high.

html: allow partial html editing and re-rendering. We already have api functions that "only" edit divs inside the full html. The problem is that those api functions end up asking the engine for a full render even if only 1 word was edited....... 

html: make core rendering asynchronous from html rendering. HTML rendering should be written to a "texture" buffer 100% asynchronous from the general game rendering. Then game rendering would get the latest version of that screen's "texture" and splash it in place.

 

 

 

A final note: making our own C API will never happen in a MMO game. Most we can do is ask NQ to implement stuff.

Link to comment
Share on other sites

This is not about LUA vs JS. The resources needed to run those scripts are trivial regardless which one you use.

It is the underlying DOM operations rendering graphics and mixing it with the game that needs improvements, like making sure they don't do unnecessary updates etc.

Link to comment
Share on other sites

Give us option to disable foreign Lua scripts and screens on markets/everywhere. It will solve several things at once. 

- It will be much easier to implement for you

- Players don't need to change their scripts.

- less visual smog on markets.

- remove some market lagging

- ...

 

Link to comment
Share on other sites

On 4/8/2021 at 4:14 PM, joaocordeiro said:

All this 3 problems are common on any "scripting" language. Any JS or phyton would have exactly the same issues.

 

nope.... Lua is slow depending on what you're doing and how you're doing it (although it isn't exactly a language you want to compare to C for example )... Couple of examples: the json parser NQ is using is really slow, there are much better alternatives. While loops are generally slow in Lua, so everyone who is using while loops in, say, coroutines, will suffer performance loss. For loops that are ipairs or pairs are significantly slower than numeric loops, etc. Lua has some.. lets just say, holes, but if you know what you're doing it can be just as good as any other language for whatever you want to accomplish.

 

As far as JS, ow boy... JS can be fast... very very fast, especially when you consider it is non io-blocking and is event based, allowing for maximization of cpu and memory usage. It all depends on how and what you code. Ruby programmers should just switch professions.


As for your comments about HTML being heavy.... well... duh. They literally refresh the dom on every frame / tick.

Again, see here, they prob read the C triggered JS bits and forgot about databinding (you know, the super duper efficient and performant method as it only updates values that need to be updated, NOT the whole DOM... it's the same method I use for updating quadrillion table data rows in dom without crashing a browser.

 

C++ triggering JavaScript, Javascript triggered C++ (heehee)
https://coherent-labs.com/Documentation/cpp-gt/d9/d2b/binding__c_x_x.html

 

AAAAND databinding!
https://coherent-labs.com/Documentation/cpp-gt/df/dfb/_h_t_m_l_data_binding.html

 

Link to comment
Share on other sites

1 hour ago, IvanGrozniy said:

Couple of examples: the json parser NQ is using is really slow, there are much better alternatives.


Its slow because it is implemented in LUA. This should be implemented in C and exposed to LUA.

you guys fail to understand a basic thing here. If you add all the isolation and safety lua provides natively to JS you will end up with a slower JS than lua.

Link to comment
Share on other sites

4 hours ago, joaocordeiro said:

Its slow because it is implemented in LUA. This should be implemented in C and exposed to LUA.

in theory yes.

in practice you have to deal with teams, skill sets, build process, project management, etc

implementing in C is not always possible because the people who can do that have higher priorities, these are not usually the same that can do stuff in LUA.

Plus they're still iterating so no point implementing in C something that is not yet full designed and stable.

 

They have metrics we don't have and they're paying a lot of money to AWS (Amazon) for their servers & traffic. Every optimization on server side, storage size and traffic volume translate to real money savings. And may be some optimizations client side lead to less  load on servers even if the client itself runs slower.

 

I'm a seasoned dev (C/C++/C#/Go/JS/TS) but I can't judge if their proposed change is good or not because we don't have their metrics and context.

Link to comment
Share on other sites

32 minutes ago, Kirth Gersen said:

I'm a seasoned dev (C/C++/C#/Go/JS/TS) but I can't judge if their proposed change is good or not because we don't have their metrics and context.

 

We are talking about a json string parser. It is a 100% stand-alone thing. Has no connectivity with DU engine.

All the code has to do is get a string, and create a structure of classes compatible with lua.

Link to comment
Share on other sites

23 minutes ago, joaocordeiro said:

 

We are talking about a json string parser. It is a 100% stand-alone thing. Has no connectivity with DU engine.

All the code has to do is get a string, and create a structure of classes compatible with lua.


Here is an example in GPLv2 license

https://openwrt.github.io/luci/api/modules/luci.jsonc.html

URL    https://git.openwrt.org/project/luci.git
git://git.openwrt.org/project/luci.git

Link to comment
Share on other sites

I am agree with all the improvement about LUA and I have made a lot of suggestion to NQ in that way.

But, I must say that I am not against removing HTML. 
HTML is not made to create user interface. HTML is the standard markup language for documents designed to be displayed in a web browser.
https://www.w3.org/wiki/HTML/Training/What_is_HTML
https://en.wikipedia.org/wiki/HTML

Having a rendering API that allow us to create a real user interface would be much better, I know that many people will have to rewrite a part of the code.
But at the end, it will be an improvement.

Then about using JavaScript to replace LUA, I am against that.
Javascript is too limited when it comes to include C library, yes you can but it's not designed for that.
In contrario, LUA has been designed to do that. 

The fact that LUA is slow on DU is not a reason to change technology. LUA technology is robust and run very well in many environment.
https://www.lua.org/about.html

And for everyone that is against changement, don't forget the game is in "ALPHA" if we follow the normal "Software release life cycle".
A software in Beta, should have mainly bug correction and interface improvement, it's not really what we have in DU. We get a ton of new features all the time and the bugs are partially corrected.
https://en.wikipedia.org/wiki/Software_release_life_cycle

But I believe in NQ, they will do theyr best to fix the bugs and make a great game.

Link to comment
Share on other sites

From a badnwidth point of view, and as a programmer myself, I can see why removing HTML is a good choice. The advantage of using the LUA API can take care of a lot of back end that the end user doesn't need to worry about with lower bandwith. This should also fix the WHITE SCREEN issues that keep happening do to the transparency.

 

LUA scripts can get pretty large, but if you look at SVG combined with HTML, it's even larger. Bandwidth becomes the issue.

 

One scripted language is not that much slower if the proper setup of the end result is refreshed at a much lower framerate then the actual game. A script should be "compiled", and only that binary be transmitted between clients. This is how games like Second Life has done it for over a decade without problems. And everyone can see the end result without bandwith being an issue. HTML with SVGA is a bandwidth hog, no doubt about that.

 

So the only way that "LUA only" scripting would work though is if they add in the proper functions that everyone would need. Booleans, Arcs, Circles, Rectangles, Polygons, Beziers and Lines, filled and unfilled. These would be a must, otherwise it would take away the ability that SVG currently gives us.

Also, sending a texture of a screen that was drawn with LUA as a one time send, unless it's updated, is a lot less Bandwidth then sending HTML /  SVG constantly. And that one texture would just be rendered on the client side once it has been sent. And then any smaller portion of the screen that has been updated, only that section in compiled LUA binary form would be sent to the client, which could then render on their end. Then to sync player screens would only need some sort of verification between clients ( players ) and server.

EDIT : For those who claim JIT for LUA, you CAN have any scripted language compiled down to binary. Even the Unity Viewer does this now. ( It didn't always do this in the past. ) Game companies like Linden Labs has been using this technique for over a decade with much success.

EDIT 2 : By the way, for all of this to function smoothly and work correctly, it MUST be scalable. You can't send a 1080p texture to every person. It has to scale according to distance of the player.

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...