Archiv verlassen und diese Seite im Standarddesign anzeigen : assembler in einem 3d spiel?
amida maru
2007-04-24, 17:36:32
Brauch man Assembler für spieleprogrammierung oder ist es wichtig?
mfg
amidamaru
Assembler ist für Spieleprogrammierung unerläßlich, da das BASIC der modernen Heimcomputer zu langsam dafür ist. Ein guter Einsteig sollte sich hier (http://members.chello.at/wiener.freiheit/ass/ass.htm) finden lassen. Ist zwar schon etwas älter, gilt aber auch heute noch, wenn man für die Plattform Spiele programmieren will.
-huha
DocEW
2007-04-24, 17:59:01
Wieso C64?
HajottV
2007-04-24, 19:24:37
Brauch man Assembler für spieleprogrammierung oder ist es wichtig?
Nein, braucht man nicht für die Spieleentwicklung.
Natürlich ist Assembler wichtig.
Gruß
Jörg
Heutzutage gibt es gute C++ Compiler.
Brauch man Assembler für spieleprogrammierung oder ist es wichtig?
Kommt drauf an was du für ein Spiel entwickeltst und für welches System.
Auf dem PC ziemlich sicher nicht.
M@tes
2007-04-24, 20:25:11
Sagen wirs so: Wenn du die volle Rechenleistung nutzen willst, wirst an Assembler kaum drum rum kommen.
Mal eine andere Frage: Welche Sprache empfehlt ihr wenn um einfache animierte Simulationen geht. Als Beispiel eine Wasserwelle simulieren (fällt mir nix besseres ein)
ScottManDeath
2007-04-24, 20:45:05
CUDA =)
Demirug
2007-04-24, 21:06:33
CUDA =)
Gerne aber ich brauche eine Fall back für Systeme die nicht CUDA fähig sind.
micki
2007-04-24, 23:37:55
Gerne aber ich brauche eine Fall back für Systeme die nicht CUDA fähig sind.
nimm den cuda emulator
laeuft natuerlich nicht auf deinem taschenrechner ;)
@topic:
die meisten kommen ohne assembler aus. manche muessen assembler nutzen um ein kritischen stellen ordentlich was zu reissen. wenn man aber keine ahnung hat versaut man mehr als man gewinnt und verliert obendrein noch viel zeit.
Och ich finde es kann nicht schaden es mal gemacht zu haben...
Aber anwenden muss man es nur noch in Extremfällen. Andererseits ist es aber auch wirklich kein grißes Ding für einen erfahrenen Programmierer.
del_4901
2007-04-25, 01:12:50
der inline Assembler machts einem aber auch einfach, in solchen Dingen. Ist wirklich manchmal ganz hilfreich um "sicher" Compilergrenzen zu sprengen ^^
anorakker
2007-04-25, 02:26:51
um es vorweg zu sagen: ich bin weder programmierer, noch kenne ich mich grossartig in aktuellen prozessorarchitekturen aus, aber kürzlich sah ich ein video eines seminars von der breakpoint07, bei dem es um das thema "vom szeneprogger zum spielentwickler" ging.
(http://breakpoint.untergrund.net/torrents/BP07_Seminar_Chaos_FromDemocodingToConsoleGames_XVid.avi.torrent)
(ab 34:10min)
wenn ich mich recht entsinne, wurde dort diesselbe frage auch gestellt, es wurde zwar primär über konsolenentwicklung gesprochen, aber erstaunlicherweise wurde auch dort behauptet, das assembler überhaupt keine rolle mehr spielt. hauptgrund dürfte der extrem komplizierte und aufwändige umgang mit der masse an registern und die stackbehandlung sein, die compiler und diagnose tools (insbesondere hardwaremonitoring der busse und prozessoren) sind inzwischen so "mächtig" und gut, dass ein entwickeln auf der untersten hardwareebene - mit blick auf das ganze projekt - einfach nur ineffektiv wäre.
um es vorweg zu sagen: ich bin weder programmierer, noch kenne ich mich grossartig in aktuellen prozessorarchitekturen aus, aber kürzlich sah ich ein video eines seminars von der breakpoint07, bei dem es um das thema "vom szeneprogger zum spielentwickler" ging.
(http://breakpoint.untergrund.net/torrents/BP07_Seminar_Chaos_FromDemocodingToConsoleGames_XVid.avi.torrent)
(ab 34:10min)
wenn ich mich recht entsinne, wurde dort diesselbe frage auch gestellt, es wurde zwar primär über konsolenentwicklung gesprochen, aber erstaunlicherweise wurde auch dort behauptet, das assembler überhaupt keine rolle mehr spielt. hauptgrund dürfte der extrem komplizierte und aufwändige umgang mit der masse an registern und die stackbehandlung sein, die compiler und diagnose tools (insbesondere hardwaremonitoring der busse und prozessoren) sind inzwischen so "mächtig" und gut, dass ein entwickeln auf der untersten hardwareebene - mit blick auf das ganze projekt - einfach nur ineffektiv wäre.
Genau so ist es.
Allein schon durch die komplexe Art an Software und Design Hilfen bezügl. Software Engeneering/Technik spielt Assemblerprogrammierung bei Spielen (betrifft auch Konsolen) heutzutage keine Rolle mehr.
Die Spiele sind heutzutage so komplex und zeitintensiv, daß da gar keine Zeit mehr für Assemblerprogramikerung ist.
Auch wird aus Gründen der Überschaubarkeit, Wartbarkeit und Komplexität heutiger Spiele usw. darauf verzichtet.
Die Zeit, die die Programmierer haben, wird sinnvoller für andere Dinge verwendet.
Es gibt höchstens nur ganz selten Entwicklerstudios die noch ab und zu auf Assembler setzen und das sind in der Regel die, die die Engines entwickeln,
also Epci (Unreal) und Id Software (Doom Engine), die restlichen Spieleentwicklerfirmen die solche Engines meistens lizenzieren haben mit Assembler nichts mehr am Hut.
Und selbst die oben genannten Engine Entwickler nutzen Assembler nur noch an ganz ganz wenigen Stellen um hier und da ein Nadelöhr in einer OO Methode zu verbessern, aber außerhalb von Klassenmethoden ist Assemlber völlig uninteressant.
Monger
2007-04-25, 13:24:59
Ich hab darin ehrlich gesagt zu wenig Erfahrung, aber ich kann mir auch kaum vorstellen, welche Strukturen in Assembler sich denn NICHT effizient mit einer Hochsprache abbilden lassen - einen ordentlichen Compiler natürlich vorausgesetzt.
Assembler ist für Spieleprogrammierung unerläßlich, da das BASIC der modernen Heimcomputer zu langsam dafür ist. Ein guter Einsteig sollte sich hier (http://members.chello.at/wiener.freiheit/ass/ass.htm) finden lassen. Ist zwar schon etwas älter, gilt aber auch heute noch, wenn man für die Plattform Spiele programmieren will.
-huha
Hierauf gibt es "Two Thumbs Up!"
Nur schade, es versteht halt heutzutage nicht mehr jeder (sowohl das Thema, als auch Deine Ironie).
Was mir dabei so nebenbei auffällt: Wir werden schon ziemlich alt.
eXistence
2007-04-25, 14:12:19
Von id gibts nen Artikel, wie sie der Renderingpipeline mittels SSE optimiert haben:
http://www.intel.com/cd/ids/developer/asmo-na/eng/dc/games/293451.htm
Ich hab darin ehrlich gesagt zu wenig Erfahrung, aber ich kann mir auch kaum vorstellen, welche Strukturen in Assembler sich denn NICHT effizient mit einer Hochsprache abbilden lassen - einen ordentlichen Compiler natürlich vorausgesetzt.
SSE und selbstmodifizierender Code wären 2 Sachen.
Ein anderer Aspekt ist CPU spezifische Optimierung, man kann dabei im Gegensatz zum Compiler einer Hochsprache auch immer wieder in der Bedeutungsebene Umformungen vornehmen, um effizienteren Code schreiben zu können.
HajottV
2007-04-25, 17:21:23
Ich hab darin ehrlich gesagt zu wenig Erfahrung, aber ich kann mir auch kaum vorstellen, welche Strukturen in Assembler sich denn NICHT effizient mit einer Hochsprache abbilden lassen - einen ordentlichen Compiler natürlich vorausgesetzt.
Selbst ordentliche Compiler machen teilweise ganz komische ineffiziente Sachen. In 99.999% der Fälle ist das aber völlig akzeptabel. Bei den 0.001% kann es aber Sinn machen, selber Hand an zu legen und ein paar Zeilen Assembler zu programmieren. Ein typisches Beispiel sind Bildbearbeitungsfilter... da wird sehr oft noch Assembler benutzt.
Gruß
Jörg
Chris Lux
2007-04-28, 08:23:09
der inline Assembler machts einem aber auch einfach, in solchen Dingen. Ist wirklich manchmal ganz hilfreich um "sicher" Compilergrenzen zu sprengen ^^
naja da sehe ich das problem, wenn man für verschiedene plattformen entwickelt. beispielsweise funktioniert der inline assembler des gcc anders als der vom visual studio. bei letzterem ist es unmöglich den inline assembler zu nutzen, wenn man für das x64 target compilen will.
so bleibt leider, soweit ich das richtig überblicke, für plattformübergreifende programmierung mit assemblerteilen nur der weg über einen externen assembler...
micki
2007-04-28, 15:00:26
so bleibt leider, soweit ich das richtig überblicke, für plattformübergreifende programmierung mit assemblerteilen nur der weg über einen externen assembler...wie kann dir ein externer assembler bei der plattformuebergreifenden programmierung helfen gegenueber dem eingebauten?
soweit ich weiss ist der inlineassembler vom VS.Net der MASM, also integrierter externer assembler. aber wie das plattformuebergreifend wird entgeht mir.
normalerweise ist assembler nur eine optimierung, das heisst, dass man die langsame funktion schon hat und mittels eines #ifdef fuer alle anderen plattformen einschaltet.
Chris Lux
2007-04-28, 15:10:46
wie kann dir ein externer assembler bei der plattformuebergreifenden programmierung helfen gegenueber dem eingebauten?
soweit ich weiss ist der inlineassembler vom VS.Net der MASM, also integrierter externer assembler. aber wie das plattformuebergreifend wird entgeht mir.
normalerweise ist assembler nur eine optimierung, das heisst, dass man die langsame funktion schon hat und mittels eines #ifdef fuer alle anderen plattformen einschaltet.
wenn man bspw. NASM nutzt schreibt man den code einmal und nutzt dann immer den externen assembler (hier NASM) auf allen plattformen, einfach weil, wie gesagt, sonst unter x64 windows kein inline assembler mehr geht und der gcc da anderen syntax haben will. also ein assembler, der auf allen plattformen läuft.
ok, für 32 und 64bit muss man angepasste code versionen haben, aber sonst sollte es unter linux und windows nur eine code version geben, darauf wollte ich hinaus.
deekey777
2007-05-03, 23:41:42
CUDA =)
Wieso CUDA? Auch wenn CTM nicht in Konkurrenz zu CUDA steht, so wäre es fair auch CTM zu nennen, oder?
mickii
2007-05-04, 09:36:40
Wieso CUDA? Auch wenn CTM nicht in Konkurrenz zu CUDA steht, so wäre es fair auch CTM zu nennen, oder?
klar, verbietet dir doch niemand, nur zu, trau dich, wenn ein mod was gegen dich hat stehen wir dann geschlossen hinter deiner meinungsfreiheit ;)
ScottManDeath
2007-05-04, 22:29:00
Wieso CUDA? Auch wenn CTM nicht in Konkurrenz zu CUDA steht, so wäre es fair auch CTM zu nennen, oder?
Keine Angst, ich hab CTM in meinem Streaming-Clustering-Implemenations-Projekt-Report erwähnt, obwohl ich CUDA/G80 genommen habe =)
Especially recent developments in eassing access to GPUs for general purpouse computing, such as CUDA[NVI06], from NVDIA, and CTM[AMD06], from AMD, enable the use of the GPU as a data parallel device to run programs, without involving a conventional graphics API, such as OpenGL or Direct3D.
Klein Hannes
2007-05-09, 13:04:35
Hallo, die Programmiersprache ist weniger wichtig, vor 10 Jahren ganz wichtig, die Grafikkarte soll alles machen und der ist es egal mit welcher Programmiersprache die Funktion geschrieben wurde die ihr alles reinschiebt.
Man kann auch Assembler nehmen braucht aber Jahre was andere in ein paar Minuten machen. In Assembler wurden früher Funktionen geschrieben die immer wieder aufgerufen wurden, bis zu mehere tausendmal in der Sekunde, das machen heute alles die Grafikkarten, schneller und besser.
:cool:
Hallo, die Programmiersprache ist weniger wichtig, vor 10 Jahren ganz wichtig, die Grafikkarte soll alles machen ...:cool:
Die Grafikkarte macht aber nicht alles. Du klingst als hättest du alles nur aus einem Buch abgeschrieben.
Wie einige Vorredner geschrieben haben, wird man um Assembler nicht herumkommen, wenn man den SSE Befehlssatz nutzen möchte. Ansonsten kann man sich ruhig auf den Compiler verlassen.
das problem dürfte sein, daß die effizienz von assembler zu dos-zeiten, wo man sich den prozessor incl. stack und register exclusiv gekrallt hat, wesentlich größer war als heute, wo multicore und multitasking einen gehörigen teil dieser strategie quasi unmöglich machen. die andere sache, compilergrenzen erweitern, ist auch gefährlich, da viele dieser grenzen mit absicht gezogen wurden und man in vorhandene strukturen löcher reißt, die kein compiler abfangen kann.
ich denke, bis auf grakas (wo man wieder die pipeline quasi exclusiv beackert) dürfte sich das auf seeehr wenige spezialfälle beschränken.
ilPatrino@work
das problem dürfte sein...
Ist es nicht. Die Task-Switches kommen in CPU-Cycles gesehen so selten, dass das keinen Unterschied macht.
vBulletin®, Copyright ©2000-2024, Jelsoft Enterprises Ltd.