Moderne Spiele in Assembler?

Andreas_1981

Neues Mitglied
Hallo Leute,

folgende Frage:
Ist es grundsätzlich möglich, moderne Triple A-Spiele in Assembler zu schreiben?


Folgender Hintergrund zu der Frage …
Ich habe meine IT-Ausbildung vor rund 25 Jahren gemacht und damals auch viel rumprobiert und gecodet. Weil es zu viele ITler gab hab ich die Branche gewechselt und seitdem nie wieder programmiert.
Daher korrigiert mich bitte, wenn die eine oder andere Aussage nicht mehr zeitgemäß ist.


Soweit ich mich noch düster an Assembler erinnere, war das verflixt schnell. Wir haben damals Lösungen für komplexe Berechnungen in Assembler und zum Vergleich in maschinenfernen Sprachen wie Visual Basic und quasi-nahen Sprachen wie C geschrieben.
Assembler war fix, aber eben aufwändig.


Würde sich nicht die GPU- und CPU-Last moderner Spiele ERHEBLICH verringern lassen, wenn sie in Assembler gecodet würden?

Das ist natürlich eine rein hypothetische Frage, denn ich vermute der Aufwand wäre enorm.
Assembler kann, soweit ich mich erinnere, nichts was in Richtung Objektorientierung geht (man korrigiere mich da gerne), d.h. ich stelle mir vor, man müsste quasi jede Textur einzeln coden. Wäre das so in etwa?

Wobei es ja mal so eine Basic-Sprache gab, mit der sich leicht 3D-Spiele erstellen ließen (Dark Basic hieß das) … eventuell ist das ja auch mit Assembler so „einfach“ möglich?


Wie gesagt … ist ein Gedankenspiel, aber wenn Assembler so fix ist, bräuchten wir dann ggf. nur ein Fünftel der Leistung aktueller CPUs und Grafikkarten?

Ließen sich nicht eventuell die Anweisungen für Grafikschnittstellen auch in Assembler schreiben?


Etwas hypothetisches Brainstorming, aber ich würde mich über eure Gedanken dazu freuen.
Da ich seit quasi einem viertel Jahrhundert nicht gecodet habe, bin ich grottenhaft daran verreckt mir die Frage selbst zu beantworten. Ich weiß irgendwie gar nichts mehr zu irgendeiner Programmiersprache, mit der ich damals gearbeitet habe = /.
 
Selbst wenn du ewig nicht mehr prorgrammiert hast, das logische Denken müsste noch in deinem Schädel stecken. Und auch die spezielle sprunghafte ASM-Denkweise ;) . Ich denke, du könntest dich schnell wieder einarbeiten. Kannst ja 'n bisschen online rumspielen und dann mit disassembly herumprobieren.

Das fixe ASM

Dass euer ASM schneller war als C kann ich mir nur so erklären, dass ihr mit ASM viel besser zurecht kamt als mit C, es nur Wunschdenken war (der Glaube daran, dass ASM einfach schnell ist), oder die Benchmarks in künstlichen Szenarien liefen (zB nur eine einzige Funktion getestet und kein großes Programm). ASM und Sprachen wie C/C++/Delphi sind gute Freunde und können gemischt geschrieben werden. Am Ende produzieren sie alle nur Maschinencode. Und in den meisten Fällen sind die builtin Funktionen der höheren Sprachen dann doch besser oder mindestens genau so gut wie das, was man in Assembler selber schreibt. Wenn bestimmte Abschnitte nicht so gut laufen, kannst du sie dekompilieren, den ASM Code kopieren und dann selbst direkt in ASM umschreiben.

Spieleentwicklung

Wenn ich das richtig verstehe, dann sind Grafikkarten auf die Schnittstellen zugeschnitten und die Schnittstellen gezielt auf Grafikkarten zugeschnitten. Da kannst du (realistisch gesehen) nicht mehr viel optimieren. Das heißt du müsstest beim Engine ansetzen und einen eigenen Engine schreiben. Triple A wird das auf jeden Fall (wenn A für "Agony" steht). Aber ich denke schon, dass ein auf ein einzelnes Spiel zugeschnittener Engine wesentlich schneller laufen würde, als zB Unreal oder Unity, die ja einfach viel Ballast mitbringen.

Wenn dich das Thema ASM und Spiele interessiert, kannst du dir mal anschauen, wie sie früher Spiele für Spielkonsolen geschrieben haben. Also Commodore, NES, SNES, GB, GBA, N64 und so weiter. 2D Grafiken kann ich eben gerade noch nachvollziehen. Wie man 3D in assembler machen würde, geht über mein Verständnis von Matrizen hinaus. :D

Vielleicht weiß das ja jemand.
 
Wie man 3D in assembler machen würde, geht über mein Verständnis von Matrizen hinaus. :D
Ich bin mir zu 80% sicher, dass grafische Berechnungen (Texturen und Objekte im Raum) für 3-dimensionale Räume von der Grafikkarte berechnet werden -> ergo Schnittstelle ansteuern. Aber wissen tu ich's auch nicht, weil ich noch nie ne eigene Engine geschrieben hab.
 
Es würde nicht funktionieren.

Zum einen - Assembler ist nicht per schneller. Insbesondere mit den heutigen Architekturen - insbesondere bei Spielen, die massiv die Graphikkarte mitnutzen kann keiner wirklich in Maschinensprache so programmieren, dass es wirklich effizient ist. An vielen Stellen sind Compiler & Co da deutlich besser.
Zudem kommen viele Performance Probleme daher, dass Optimierung nicht im Vordergrund steht bzw. zu wenig Zeit bleibt. Und die größten Performance Killer sind falsche Architekturentscheidungen, falsche Algorithmen etc. - nichts davon hängt an der Programmiersprache.

Zudem wäre ein Assembler Projekt um Längen aufwendiger, nicht wartbarer und hätte viel mehr Fehler, weil die einfach viel aufwendiger zu fixen sind und Seiteneffekte viel schwieriger zu kontrollieren sind. Sprich, das Projekt würde viel zu lange dauern, veraltet sein bevor es erscheint.
 
@Mat: naja speziell bei 25 Jahren Zit seitdem ist definitiv denkbar, dass die ASM-Implementierung schneller war, die Optimierungen der Compiler sind seitdem ganz erheblich bsser geworden, heute lassen Compiler sich eigentlich nur noch mit Kontextwissen schlagen wenn man von Hand optimiert, früher war das in einigen Punkten anders, besonders weil es noch keine ausgereiften, gebräuchlichen, Whole-Program-Optimizations oder Link-Time-Optimizations gab. Heute ist das natürlich anders, auch weil Prozessoren etc. seitdem weit komplexer geworden sind.

@TE: Es wäre natürlich möglich, Triple-A-Titel in ASM zu schreiben. Aber es wäre wohl kaum praktikabel und vermutlich wäre der Nutzen minimal bis nicht vorhanden. Das liegt daran, weil du als Mensch moderne Compiler nur noch mit erheblichem Kontextwissen und ganz erheblicher Arbeit schlagen kannst, und idR auch nur in hinreichend kleinen Fällen. Sobald dein Code so groß wird, dass du ihn wiederverwenden willst dürfte sich dieser Vorteil dadurch dass du checks einbauen musst etc. ziemlich schnell wegnivellieren. Und vor allem: wenn du da einmal als Mensch einen Fehler machst und einen Cache-Miss der nicht sein müsste rein baust hast du vermutlich den ganzen Vorteil schon wieder verloren. In meiner Erfahrung kannst du auch moderne CPUs und Compiler in ganz spezifischen Szenarien noch schlagen, in meiner Erfahrung auch in manchen Fällen noch um ~10% oder so, das ist aber so Hardwarespezifisch und so absurd viel Arbeit, dass sich das bestenfalls für innere Schleifen mit heftigem Number-Crunching noch lohnt(Hochdimensionale Numerik ist da so das letzte Beispiel, das mir noch in den Kopf kommt).


MfG, Lowl3v3l
 
Zurück
Oben Unten