Gedankenspiel ~ Andere Libery verwenden = Mehr Leistung?

    • Neu

    So ich hab mal wieder einen wirren Gedanken den ich mit euch Teilen möchte bzw gerne darüber diskutieren möchte ^^ :P


    Erstmal das Grundsätzliche - Der Maker MV/MZ verwendet als Libery Pixi und als Framework NWJS (Hoffe ich verdrehe jetzt nicht Bezeichnungen :huh: )
    Naja zu meinen Gedankenspiel:

    Würde es mehr mögliche Performance erzeugen wenn man Pixi mit z.B. Tree auswechselt oder NWJS mit Electron?


    Mein bisheriger Gedanke dazu:

    Pixi ist spezialisiert auf 2D Anwendungen wobei Tree für 3D Anwendungen spezialisiert ist. Nachdem 3D Anwendungen mehr Leistung ziehen müsste es mehr Luft nach oben sein, wenn man darin eine 2D Architektur einbaut. Dazu, NWJS erstellt vereinfacht gesagt einen Server Innerhalb einer Anwendung, somit ist es dort immer noch eine Browserumgebung. Aber mit Electron, der es als "richtige" Anwendung erstellt müsste es ebenfalls mehr Luft erzeugen.


    Dazu habe ich aber 0 Erfahrungswerte daher kann ich es nur schwierig beurteilen :D Wie ist denn eure Meinung dazu bzw. eure Ideen und eventuell Erfahrungen mit sowas?

    • Neu
    Zitat von Zion

    Wie würdest du das denn umsetzen wollen? Muss man dafür nicht den Maker neu programmieren?

    Nachdem es nur Theoretisch ist kann ich nur sagen, dass es nicht mal unbedingt der Fall sein müsste. Das hat einen einfachen Grund: Vererbung
    Das heißt, dass wenn man die "Base" Sachen bearbeitet (z.B. Scene_Base) wirkt es sich automatisch auf alle weiteren Kinder aus (bei Scene_Base wäre es zum Beispiel Scene_item, Scene_Equip usw)

    • Neu

    Ich glaube das PixiJs und ThreeJS beide über WebGL ihrer Sache erledigen. Also im Kern gibt es da kein "Besser".

    Darüber hinaus würdest du mit ThreeJS wohl eher das Gegenteil erzeugen. Die Performance würde darunter leiden, da es mehr Overhead erzeugen würde, da es hier deutlich mehr Sachen im Hintergrund macht. Pixi ist ja für 2D Spiele ausgelegt, kann also sein, dass hier viele Sachen wegfallen, wie viele Transformationsberechnungen. Rotationen funktionieren in 2D anders (einfacher) als in 3D, da hier mehr Achsen ins Spiel kommen. Aber für Maker Games sollte es keinen unterschied machen.


    Wenn du das Tauschen willst, müssest du die Core.js komplett überarbeiten, da diese hier als Schnittstelle fungiert. Wird aber einiges an Arbeit kosten, da man das ganze auch testen muss. Aber kannst du gerne mal versuchen, wäre interessant zu wissen.


    Ich kenne mich weder mit PIXIJS oder ThreeJS im Detail aus, aber ich schätze, dass das so ist, wie ich beschrieben habe.


    Ich kenne Electron nicht, daher kann ich dazu nichts sagen. Aber danke, dass du es erwähnt hast, ich schaue es mir mal :thumbup:


    EDIT:
    Was mir dazu noch einfällt:

    Externer Inhalt www.youtube.com
    Inhalte von externen Seiten werden ohne Ihre Zustimmung nicht automatisch geladen und angezeigt.
    Durch die Aktivierung der externen Inhalte erklären Sie sich damit einverstanden, dass personenbezogene Daten an Drittplattformen übermittelt werden. Mehr Informationen dazu haben wir in unserer Datenschutzerklärung zur Verfügung gestellt.


    Falls das kein Fake sein sollte, hat der type im Video das wohl so gemacht. Wobei das mMn. eher als eine Spielerei zu sehen ist, sowas mit dem Maker zu machen, da es hierfür einfach bessere alternativen gibt im Webbereich.

    • Neu

    Ich halte mich kurz - weil ich gerade auf Arbeit bin bzw Rauch Pause mache:

    Das Video kenn ich und ich schätze es so ein, dass es dort 2 Kniffe gab: 1x wurde das bekannte 3d plugin verwendet (Player Control) und der Hafen der zu sehen ist, vermute ich ist ein Video Parralax :P

    • Neu

    Hallo, ich entwickle selbst eine Engine die sowohl 2D als auch 3D beherrscht. Das Wichtigste hat Canti schon gesagt, aber ich kann noch etwas "aus der tieferen technischen Ebene" anmerken.


    Bei mir läuft beides über WebGL (2D auch via Canvas, aber das mehr aus Bequemlichkeit als Performance) und die für mich relevanten Flaschenhälse sind der Speichertransfer zur GPU, die Renderleistung der GPU und als drittes die Leistung der CPU. Ob man die bestmögliche Leistung erreichen kann, ist dabei stets eine Frage der Optimierung. Im 2D-Bereich gibt es z.B. die Möglichkeit, mehrere Sprites auf eine Textur zu packen (denn jeder Texturwechsel kostet Zeit). Um Daten zu sparen, transferiert man dann lediglich die Positionen und Indizes zur Grafikkarte und lässt einen Shader von der entsprechenden Textur rendern. Mit dieser Method kann man auch auf einem betagten Notebook mehrere tausend (!) Sprites flüssig darstellen. Mein Fazit ist daher, dass nicht die darunterliegende Engine die Grafik ausbremst, sondern die darüberliegende Software.


    Sorry für das technische Kauderwelsch.

    • Neu
    Zitat von Yhoko

    Hallo, ich entwickle selbst eine Engine die sowohl 2D als auch 3D beherrscht. Das Wichtigste hat Canti schon gesagt, aber ich kann noch etwas "aus der tieferen technischen Ebene" anmerken.


    Bei mir läuft beides über WebGL (2D auch via Canvas, aber das mehr aus Bequemlichkeit als Performance) und die für mich relevanten Flaschenhälse sind der Speichertransfer zur GPU, die Renderleistung der GPU und als drittes die Leistung der CPU. Ob man die bestmögliche Leistung erreichen kann, ist dabei stets eine Frage der Optimierung. Im 2D-Bereich gibt es z.B. die Möglichkeit, mehrere Sprites auf eine Textur zu packen (denn jeder Texturwechsel kostet Zeit). Um Daten zu sparen, transferiert man dann lediglich die Positionen und Indizes zur Grafikkarte und lässt einen Shader von der entsprechenden Textur rendern. Mit dieser Method kann man auch auf einem betagten Notebook mehrere tausend (!) Sprites flüssig darstellen. Mein Fazit ist daher, dass nicht die darunterliegende Engine die Grafik ausbremst, sondern die darüberliegende Software.


    Sorry für das technische Kauderwelsch.

    Das Thema Flaschenhälse trifft es wirklich sehr gut - Ich sehe beim Maker der größte Flaschenhals, dass lediglich 300MB Ram zur Verfügung gestellt wird. Vieles geht zwar mit dieser Limitierung aber sobald komplexere Grafische Berechnungen kommen, wie zum Beispiel Licht wird es schwierig noch darin zu bleiben. Ebenfalls sind große Maps ebenfalls ein Problem, wenn sie per Parallax erstellt wurden. Weil die Cache bekannterweise dann voll läuft. (Im alten Forum gabs mal deswegen ne größere Diskussion)

    Naja, daher auch dieses Gedankenspiel - wie kann man diesen Flaschenhals beseitigen und an den nächsten stoßen? Was könnte helfen was würde nicht helfen^^


    Außerdem finde ich es sehr cool zu lesen das du eine eigene Engine bastelst, darauf habe ich selbst Bock nur kann keine der C-Sprachen und wüsste auch nicht was für ein Framework sich dafür anbieten würde. ^^

    • Neu

    Uff, 300 MB klingt wirklich mickrig. Da zeigt sich aber auch, dass es quasi unmöglich ist, ein System perfekt zu optimieren (ausser für Konsolen, wo die Specs genau bekannt sind). Auf heutigen Rechnern wäre es wohl performanter, weniger vorzurendern bzw. zu cachen, und mehr "live" an die GPU zu senden und die mehr rendern zu lassen.

    Ich hatte selbst schon die Situation, dass ich das Rendering auf einem System beschleunigen konnte, dieselbe Idee aber auf einem anderen Rechner die FPS gesenkt hat - weil das Verhältnis von CPU zu GPU Leistung bei den Systemen unterschiedlich war. Oh, und ich entwickle in JavaScript bzw. einem eigenen Dialekt "Ynet" (daher auch WebGL). Für einen Einsteiger würde ich in dem Bereich Three.js empfehlen.

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!

Benutzerkonto erstellen Anmelden