1. Foren
  2. Kommentare
  3. Applikationen
  4. Alle Kommentare zum Artikel
  5. › Browser-Games: Unreal Engine 4…

Performance ist mies

  1. Thema

Neues Thema Ansicht wechseln


  1. Performance ist mies

    Autor: Sammie 27.05.17 - 15:34

    Das blöde an den Implementierungen dieser Engines ist, dass sie eigentlich schneller und CPU-schonender sein sollen als reines Javascript, im realen Benchmark aber langsamer, aufgeblähter und deutlich speicherhungriger sind, als von hand geschriebener WebGL-Code im einfachen Javascript. Daher kann man die EmScripten/WebAssembly-Implementierungen von Unreal (genauso wie bei Unity) bisher nur als sperriges Alpha-Feature betrachten. Da herrscht noch jede Menge Verbesserungspotential. Dabei hat WebAssembly im Prinzip viele Vorteile, die aber bei diesen Implementierungen kaum wirklich ausgereizt werden.

    PlayCanvas hat letzten Sommer ja auch mal einfache Demos nachgebaut und massive Unterschiede in Größe, Framerate und Speicherverbrauch festgestellt. Die Unreal/Unity-Portierungen schneiden da mehr als mies ab.
    https://blog.playcanvas.com/playcanvas-versus-unity-webgl/
    https://blog.playcanvas.com/playcanvas-versus-unreal-webgl/

    Das blöde ist bei Unreal/Unity halt immer, dass man jede Menge unnötigen Ballast, eben die komplette Engine mit lädt, selbst wenn das jeweilige Projekt nur 5-10% der Features überhaupt benötigt. Das ist bei den speicherbegrenzten Browser-Tabs mehr als kontraproduktiv. Da werden aus einfachen Games, die mit nem halben Megabyte Javascript auskommen könnten, 36MB große Applikationen, nur weil massiv unnötiger Code mitgeschleift wird, der dann auch noch 10-15 Sekunden zum Laden braucht, während die Plain-Javascript-Variante in einer Sekunde startbereit ist. Da kann nie was Performantes dabei rauskommen.

    Chrome gibt sowieso maximal nur Zugriff auf 768 MB pro Tab - egal wieviel RAM in der eigenen Kiste steckt - und davon muss man schön sämtliche downloadbaren GameAssets abziehen, inkl der Engine und allem was an dynamischen Variablen noch erzeugt wird und im Speicher hängt. Geht der Speicherverbrauch drüber, verabschiedet sich der Tab mit einer Crash-Message. Unreal & Unity-Foren sind voll von derartigen Topics. Da ist es ja gerade wichtig, dass der eigentliche GameCode so klein wie möglich bleibt und das ist bei diesen Engine-Portierungen eben nie der Fall. Und dass wirklich alles läuft, garantiert ja auch keiner.

    Aber sagt Unreal ja selbst auch.. "The HTML5 pipeline is currently experimental. Some projects may not run properly when built for the HTML5 platform. Expect some rough edges." - https://docs.unrealengine.com/latest/INT/Platforms/HTML5/GettingStarted/index.html

    Man kann halt C++ Code nicht 1:1 auf Javascript übertragen und dann beste Ergebnisse erwarten. Javascript hat nun mal seine Eigenheiten und Beschränkungen und vieles könnte man selbstgeschriebenen Code deutlich performanter laufen als diese aufgeblähten automatischen Portierungen, die darauf nur bedingt Rücksicht nehmen. Ja, es ist dann deutlich aufwändiger und man muss auch programmieren können, statt sich in den Engines alles nur im Baukastenprinzip zusammenzuklicken, der dann einen fertigen Code ausspuckt - aber man könnte seine Projekte locker 50% kleiner und performanter kriegen, als es die Exporter von Unreal und Unity derzeit schaffen.

    Und ob dieser ganze 3D-Kram im Browser überhaupt Sinn macht, darüber kann man eh streiten. Wenn man allein die Ladezeiten dieser winzigen WebGL 2.0-Demo betrachtet, ist das für den Einsatz für Browsergames nach wie vor alles viel zu lahm. Kein Spieler wartet für spontane Gaming-Sessions minutenlang aufs Laden winziger Level. Und in diesen bisher gezeigten Demos passiert ja praktisch Null, während man in einem realen Browsergame ja relativ viel Bewegung, Animation und Interaktion mit anderen Spielern erwartet, die zusätzlich die CPU für die nötigen Berechnungen belasten.

    Ich kenn bis heut noch keinen Publisher, der in den letzten 5-6 Jahren auch nur ein namhaftes bekanntes Game auf WebGL-Basis released hat. Mehr als kleine TechDemos seitens Mozilla und Unreal, sowie einige schrottige Baukasten-Unity-Games hat bis heut noch kein Mensch gesehen. Und ob sich das jemals ändert, ist fraglich solang jeder Browserhersteller seine eigene JS-Engine, eigene Compiler und Optimizer hat, die sich alle unterschiedlich verhalten und ihre Vor- und Nachteile mit sich bringen. Was in dem einen Browser gut läuft, kann in einem anderen schon wieder laggen und umgekehrt. Und da ständig dran geschraubt wird, gibts auch keine Garantie, dass sich eigene Optimierungen am Code 1-2 Browserversionen später nicht wieder völlig gegenteilig verhalten.

    Spieleentwickler brauchen vorallem eine verlässliche Basis, und die ist dadurch eben nie gegeben, was auch ein Hauptgrund dafür ist, dass sich WebGL bis heute nicht gegen Flash bei Browsergames durchgesetzt hat. Technisch ist HTML5/WebGL gegenüber Flash nach wie vor 4-5 Jahre hinterher, was den Feature-Umfang angeht. In HTML5 fehlt noch so einiges. So gern man Flash auch loswerden würde, machts halt keinen Sinn, solang die angepriesene Alternative nicht den gleichen Feature-Umfang und eine stabile Basis mit sich bringt, die in allen Browser absolut identisch ist.

    Der Schritt zu WebGL2.0 für OpenGL 3.0 Shadern war schon seit Jahren überfällig (kann Flash schon seit 2015). Aber es fehlen eben auch noch "unbegrenzte" Speichermöglichkeiten der GameAssests - weil keiner bei jedem Spielstart erneut über 100 MB Daten laden will. Chrome/Firefox haben das ja inzwischen eingesehen, und vor kurzem ein dymanisches Limit eingeführt (abhängig vom verfügbaren Festplattenplatz) - Edge hingegen klammert sich seit Jahren nach wie vor an ein relativ witzloses 10 MB-Limit.. kein gottverdammtes Browser-Game kommt mit 10 MB Grafiken aus... Selbst uralte HTML-Browsergames haben Minimum 50MB+ an GrafikAssets - im 3D Bereich braucht man locker das doppelte. Und die hochgelobten WebAssemblys sind im Grunde fast das gleiche wie Crossbridge/Alchemy für Flash (http://adobe-flash.github.io/crossbridge / https://www.golem.de/0811/63650.html) - das gabs in Flash schon anno 2008. ^^

    Wünschenswert wären auch richtige raw TCP-Sockets, statt diese lahmen WebSockets mit ihrem unnötigen Overhead. Die sind sogar geplant (https://www.w3.org/TR/raw-sockets/) - aber wann sie genau kommen und crossbrowserfähig nutzbar sind, steht in den Sternen. Chrome hat sie bisher nur experimentell und auch nur für Extensions - ob man sie später auch mal für normale Browsergames nutzen kann, weiß keiner. Flash bietet performante TCP-Sockets schon seit Anfang an.

    Was HTML5 auch mal bräuchte sind direkte Bitmap-Funktionen abseits der Canvas. Simple Sachen wie zB das einfache Extrahieren oder Überschreiben eines Alpha-Channels oder generell eben Channel-Kopierfunktionen von Bitmap A nach B, statt dass man Pixel für Pixel selbst auslesen muss, was unheimlich langsam ist. Und die Liste der "Missing Features" könnte man noch ewig fortsetzen. Javascript mangelts da an jeder Menge performanter nativer Funktionen. Solang vieles nur durch eigene langsame Workarounds ergänzt werden kann, wird HTML5 nie ein vollwertiger Flash-Ersatz werden und von Games-Entwicklern weiterhin unbeachtet bleiben.

    Und das ist eben auch der Kernunterschied - während Flash bzgl Funktionsumfang gezielt auf Games hin optimiert ist, bleibt in der HTML5-Welt nur das allgemeine Javascript, was nur spärlich nach und nach über die Jahre hinweg die nötigen Funktionen ergänzt. Laut W3C ist alles in Planung was man bräuchte.. aber eben nur In Planung.. seit Jahren. Nur ab und zu schafft es mal das ein oder andere Feature aus der Planung oder einem experimentellen Status heraus - dieser "Fortschritt" ist einfach viel zu langsam. Bei dem Tempo bräuchte es noch gut 6-8 Jahre, bis man Flash wirklich bedingungslos ersetzen könnte.

  2. Danke...

    Autor: Hello_World 28.05.17 - 00:40

    ... für diese detaillierten Erläuterungen. Bist Du selbst in dem Bereich tätig oder wie kommt es, dass Du dich da so gut auskennst?

  3. Re: Performance ist mies

    Autor: Haxx 28.05.17 - 10:37

    So würde ich das nicht sagen, es ist doch eher so das diese monolithisch ich-kann-alles Engines nicht so gut fürs Web geeignet sind. Eine kleine spezialierte c++ Engine wäre von der Größe vergleichbar mit three js

  4. Re: Performance ist mies

    Autor: Proctrap 28.05.17 - 11:37

    Ist die Frage dann nicht eher ob wir wirklich Games & so viel 3D im Browser benötigen ?
    Flash mag ja alle diese Features besitzen, hat dafür eine Hardwarebeschleunigung von 0% und bringt ganze Systeme zum hängen (mit Videos auf 100%!).
    Weil für Mobil gibts Apps, da kann ich sogar C++ verwenden / Crosscompiling ist da ja nicht mehr so schlecht. Auf Desktop-PC's kann ich diese Basis dann verwenden um dort richtige was ab zu liefern. Und selbst dort gibt es ja jetzt auch schon "Apps". Daher frage ich mich eher ob es denn wirklich 3D in dem Umfang im Browser benötigt.
    [Auch wird mit all den Features wieder einiges an Löchern (allein Tracking schon) in die Browser kommen, nur weil hier APIs eingebaut werden, welche für 99% des täglichen Browsens wirklich niemand braucht. Und so wirklich gut für die eigentlichen Benutzer dieser APIs scheinen sie aber ja auch nicht zu sein > gleich weg lassen.]
    Und dann kommen hoffentlich auch wieder Leute von der Idee weg ganze Applikationen nur mit JS, Html5 und einer fetten Chrome-Engine zu entwickelt..

    ausgeloggt kein JS für golem = keine Seitenhüpfer

  5. Re: Performance ist mies

    Autor: TimeX 28.05.17 - 15:05

    Ich habe mich vor 5 Jahren auch mit WebGL beschäftigt und habe damals threejs.org benutzt. Ich fand die Performance nicht mies, allerdings hatte man Probleme die man nur mit Tricks lösen musste (Zu viele Objekte, Assetsverwaltung etc.). Die Ergebnisse waren eigentlich recht gut wenn auch sehr Aufwendig. Ich habe mich mit dem Thema nicht mehr weiter beschäftigt, aber es ist schon komisch, dass in diesem Bereich nicht viel passiert ist. Okay, jetzt kommt der WebGL 2.0 Standard, aber meiner Meinung nach hätte hier viel mehr passieren können und auch müssen.

    Ich hab mich auch gefragt warum sich hier nicht mehr getan hat. IMHO ist der Grund einfach. Die großen Player am Markt wollen dies nicht. Denn was bedeutet es, wenn alle Games auf einmal im Browser spielbar sind? Es schadet schlicht der App Store Infrastruktur, hier könnte auf einmal kein Geld mehr verdient werden. Warum kommt hier keine Konkurrenz? Ich glaube es ist einfach zu Aufwendig von null auf eine JS Game Engine zu entwickeln, wobei ThreeJS zu mindest am Anfang einen guten Weg gegangen ist.

  6. Re: Performance ist mies

    Autor: windbeutel 28.05.17 - 18:34

    Sammie schrieb:
    --------------------------------------------------------------------------------
    > Das blöde an den Implementierungen dieser Engines ist, dass sie eigentlich
    > schneller und CPU-schonender sein sollen als reines Javascript, im realen
    > Benchmark aber langsamer, aufgeblähter und deutlich speicherhungriger sind,
    > als von hand geschriebener WebGL-Code im einfachen Javascript.
    [...]
    > Bei dem Tempo bräuchte es noch gut 6-8 Jahre, bis man Flash
    > wirklich bedingungslos ersetzen könnte.

    Hast Du die letzten 10 Jahre unter einem Stein gelebt? Flash ist (gottseidank) mausetot.

  7. Re: Performance ist mies

    Autor: Sammie 13.07.17 - 17:29

    windbeutel schrieb:
    --------------------------------------------------------------------------------
    > Hast Du die letzten 10 Jahre unter einem Stein gelebt? Flash ist
    > (gottseidank) mausetot.

    Unsinn. Nach wie vor produzieren alle BrowserGames-Hersteller nur in Flash, sei es BigPoint, Ubisoft, GoodGame oder was auch immer am Markt einen Namen hat. Kein namhafter Hersteller macht bisher irgendwas in HTML, geschweigedenn in WebGL - gab zwar zögerliche Versuche - aber das hat man alles schon in der Entwicklungsphase wieder in die Ecke gekickt und dann das verwendet, was überall funktioniert: Flash.

    Sogar für Tablets und Mobile wird die gleiche Programmiersprache (Actionscript3) verwendet, um für die Geräte App-Portierungen herzustellen. Das ist ja auch ein entscheidender Vorteil. Du kannst mir dem gleichen Source für das Flash-Browser-Plugin, für mobile Apps (Blackberry, Android, iOS) oder auch Standalone-Desktop-Applikationen kompilieren, die auch auf Smart-TVs usw laufen.

    Wahrscheinlich hat jeder von euch schon Apps auf dem Smartphone gehabt, die eigentlich nur selbststartende Flash-Programme sind. Sieht man denen ja nicht an, welche Programmiersprache dahinter steckt.

    Nur weil es kein Flash-Plugin auf mobilen Geräten gibt, ist die Technik noch lang nicht tot - sie heißt da nur anders - nämlich Adobe AIR - ist aber zu 99% der gleiche Source wie bei Flash. => http://www.adobe.com/de/products/air.html - aber Hauptsache mal schön getrollt... ;P

  1. Thema

Neues Thema Ansicht wechseln


Um zu kommentieren, loggen Sie sich bitte ein oder registrieren Sie sich. Zum Login

Stellenmarkt
  1. Bayerische Versorgungskammer, München
  2. Advantest Europe GmbH, Böblingen
  3. ServiceXpert Gesellschaft für Service-Informationssysteme mbH, München
  4. medneo GmbH, Berlin

Golem pur
  • Golem.de ohne Werbung nutzen

Anzeige
Spiele-Angebote
  1. 3,58€
  2. (-75%) 4,99€
  3. (-40%) 32,99€
  4. (-35%) 25,99€


Haben wir etwas übersehen?

E-Mail an news@golem.de


Kaufberatung (2020): Die richtige CPU und Grafikkarte
Kaufberatung (2020)
Die richtige CPU und Grafikkarte

Grafikkarten und Prozessoren wurden 2019 deutlich besser, denn AMD ist komplett auf 7-nm-Technik umgestiegen. Intel hat zwar 10-nm-Chips marktreif, die Leistung stagniert aber und auch Nvidia verkauft nur 12-nm-Designs. Wir beraten bei Komponenten und geben einen Ausblick.
Von Marc Sauter

  1. SSDs Intel arbeitet an 144-Schicht-Speicher und 5-Bit-Zellen
  2. Schnittstelle PCIe Gen6 verdoppelt erneut Datenrate

Kailh-Box-Switches im Test: Besser und lauter geht ein klickender Switch kaum
Kailh-Box-Switches im Test
Besser und lauter geht ein klickender Switch kaum

Wer klickende Tastatur-Switches mag, wird die dunkelblauen Kailh-Box-Schalter lieben: Eine eingebaute Stahlfeder sorgt für zwei satte Klicks pro Anschlag. Im Test merken unsere Finger aber schnell den hohen taktilen Widerstand.
Ein Test von Tobias Költzsch

  1. Keychron K6 Kompakte drahtlose Tastatur mit austauschbaren Switches
  2. Charachorder Schneller tippen als die Tastatur erlaubt
  3. Brydge+ iPad-Tastatur mit Multi-Touch-Trackpad

Schräges von der CES 2020: Die Connected-Kartoffel
Schräges von der CES 2020
Die Connected-Kartoffel

CES 2020 Wer geglaubt hat, er hätte schon alles gesehen, musste sich auch dieses Jahr auf der CES eines Besseren belehren lassen. Wir haben uns die Zukunft der Kartoffel angesehen: Sie ist smart.
Ein Bericht von Martin Wolf

  1. Smart Lock Netatmo und Yale zeigen smarte Türschlösser
  2. Eracing Simulator im Hands on Razers Renn-Simulator bringt uns zum Schwitzen
  3. Zu lange Ladezeiten Ford setzt auf Hybridantrieb bei autonomen Taxis

  1. Kickstarter: Gebundener Mars-Atlas zeigt Karten des Roten Planeten
    Kickstarter
    Gebundener Mars-Atlas zeigt Karten des Roten Planeten

    The Mars-Atlas ist ein interessantes Buch: Es zeigt detaillierte Karten vom Mars statt der Erde. Mehr als 2.000 Standorte sind darauf zu sehen. Auch eine digitale Applikation wird angeboten, auf der Hobbyforscher ein 3D-Modell des Mars erkunden können - ähnlich wie bei Google Mars.

  2. 5G: Österreich sieht sich beim Mobilfunk klar vor Deutschland
    5G
    Österreich sieht sich beim Mobilfunk klar vor Deutschland

    Das schlechteste Mobilfunknetz in Österreich sei immer noch besser als das beste Netz in Deutschland, hat Wirtschaftsministerin Margarete Schramböck behauptet. Auch Messungen bestätigen das.

  3. TLS: Netgear verteilt private Schlüssel in Firmware
    TLS
    Netgear verteilt private Schlüssel in Firmware

    Sicherheitsforscher haben private Schlüssel für TLS-Zertifikate veröffentlicht, die Netgear mit seiner Router-Firmware verteilt. Der Hersteller hatte nur wenige Tage Reaktionszeit. Die Forscher lehnen die Praktiken von Netgear prinzipiell ab, was zur Veröffentlichung geführt hat.


  1. 17:20

  2. 17:07

  3. 16:45

  4. 15:59

  5. 15:21

  6. 13:38

  7. 13:21

  8. 12:30