NQ-Deckard Posted April 8, 2021 Share Posted April 8, 2021 Hello Noveans! Currently, screen unit content is an HTML page. We synchronize screen unit content between players by sending the whole HTML; however, screen unit HTML content can be pretty big and uses a lot of bandwidth and frame time to render when updated every frame by a programming board or control unit. This has a significant impact on client performance for players, especially when a lot of screen units are in the same area. Performance improvement is of paramount importance to us and an ongoing request we get from players. Consequently, it is something we will continually work to achieve. To address this, we are bringing a possible solution to PTS so that players can try it out. This prototype involves using a new API to draw screen units with a dedicated Lua script. This will use simple drawing commands like drawRectangle(a,b,c,d) drawText(“Hello DU”) Simple actions like setTextContent will not be affected. In addition to performance improvements, this new tech also allows for some unprecedented possibilities to create even better screen displays than before. Check out this video to get a taste of what it can do! We realize that this change will mean that players won’t be able to use SVGs on screens anymore, and that SVGs are easier and more flexible than uploading static images. It’s important to note that the new Lua system will still allow you to draw complex images. You don't really need any Lua knowledge, and it’s easier than the DPU system. Additionally, we added an option to deactivate HTML screen units for players who experience the worse framerate. We expect this to bring significant performance improvements in markets and parking areas. Once the change is fine-tuned, thanks to your feedback after trying it on the PTS, we will announce a transition period to allow players time to switch over to the new API before we disable support for HTML-based screen units. We will continue to support both techs during this transition period. We strongly encourage everyone to check out this change when it’s available on PTS and share your constructive feedback with us on the forum. SyZoILLz, Makashima, Scott1sh and 17 others 20 Link to comment Share on other sites More sharing options...
NQ-Deckard Posted April 8, 2021 Author Share Posted April 8, 2021 Hello again Noveans! We have heard your initial feedback on the screens and we want to elaborate on some of your major concerns. Will this affect both screens and content written to the players screen (HUDs)? No, this technological change will affect only screen units at this time. Will all player created work on screens suddenly become non-functional? No, this technology will be available side-by-side with the current technology, both first on the PTS in a prototype state, and eventually also on the Live server. We strongly recommend everyone does test and experiment the new tech on the PTS, as your feedback and testing will help shape this feature. How will this make a difference on performance? The main reason being that the current implementation does not allow for much control over the performance impact of screen renderings. Complex 3D transformations using a combination of HTML, SVG and CSS has a significant impact on render times in the client. Adding to the fact that screens are often condensed with multiples of them in close proximity to each other, there is an increasing drop in performance on the client with more screens using the current technology. The new system allows for more precise control over rendering time allowed across screens and allows us to safeguard the level of performance impact the screens have on the client. So you will be removing HTML support entirely? Not necessarily, the two techs will run side by side for an as of yet undefined period of time. Eventually we may introduce a phase where we make the rendering of HTML on screens an option for players along with a warning that it can significantly degrade client performance. Players with that option disabled will simply not see any HTML content and not suffer performance degradation because of it. Why not improve the current HTML implementation instead of the new technology? This is a complex topic, HTML/CSS/Javascript is a group that forms a UI technology. For reasons beyond the scope of this topic we do not allow the use of Javascript inside the screen units. When you remove Javascript, the group effectively becomes a not so efficient vector image drawing technology which we have very little control over in terms of rendering. We have previously implemented a lot of small limitations here and there to reduce the impact of the screens, but there are (and likely always will be) edge cases which will eventually crop up using that technology. As such, the new technology has built-in limitations on how taxing a screen unit can be, and if a screen unit goes over the limit it will simply stop drawing. This is why we ask you all to go and test this, and help us find caveats and where you run into things you can and can’t do. What about bandwidth? Are you doing this to reduce data transfer for screens? The current implementation does not address this, the current implementation is a way for us to collect your feedback on this concept. Eventually we may change the way data transfer for screens is handled, where we may increase the size of the defined “template” inside a screen unit itself. Followed by a lower limit on the amount of data transferred to the screen from external sources. Allowing the screen element to do the rendering and drawing work, using parameters fed to it by a control unit. For example: You would draw the design of a fancy instrument panel using the screen element, and a programming board or control unit just sends the values for all the instruments to the screen. This is currently not in the current implementation however, but may give you a better idea of why this technology has a lot of potential for more intricate and powerful designs. What about artists who draw using external programs and import their SVG’s into the game? One of our hopes is to provide a good enough set of commands in the screens API so that our system can express most SVG graphics converted to these commands through for example a small conversion tool. It is unlikely that we will develop and maintain a conversion tool for this, but this is also why we want your feedback on this new API for you to let us know what commands you really want to see included to make this process easier. We sincerely hope that this answers many of your initial questions and concerns. I personally can’t wait to see what you will all come up with in your designs! Kronius, DropNod, admsve and 18 others 21 Link to comment Share on other sites More sharing options...
NQ-Deckard Posted April 16, 2021 Author Share Posted April 16, 2021 Lua Screen Units API Many of you have asked us to release more information about the workings of the Lua Screen Units. As such, you can now read the initial API information in the PTS Feedback forum in this post. Please bare in mind that this is a technical prototype, and many things such as UI, feedback, polish and features are not present at this time. Link to comment Share on other sites More sharing options...
Recommended Posts