1. Foren
  2. Kommentare
  3. Games
  4. Alle Kommentare zum Artikel
  5. › Destiny: Der Always-Online-Sonnensystem…

In C++ implementiert?

Anzeige
  1. Thema

Neues Thema Ansicht wechseln


  1. In C++ implementiert?

    Autor PrometheusX 18.02.13 - 01:39

    Ich vermute mal dass die Engine in C++ implementiert ist. Wenn ich mich so umhöre, dann fällt bei'm Thema moderne Softwareentwicklung mit C++ immer häufiger ein Schlagwort, und zwar "veraltet". Aber wie kann es denn sein, dass, wenn selbst neue Softwareprojekte starten, die am Ende ein lauffähiges, hochauflösendes 3D-Computerspiel zum Ziel haben, immer wieder auf C(++) zurückgegriffen wird. Die populärsten Grafik-Engines kommen laut Wikipedia von id Software, Epic Games, Crytek und Valve. Und diese Engines haben mit Sprachen wie Java wohl am wenigsten zu tun. Wenn die Perfomancediskrepanzen zwischen VM-Sprachen und hardwarenahen Sprachen immer geringer werden und das auch propagiert wird, wo sind dann die entsprechenden Entwicklungen. Ich weiß dass es z.B. die JMonkeyEngine gibt, aber besonders beeindruckend (im Gegensatz zu den o.g.) ist diese nicht. Ich habe gelesen dass z.B. der Garbage Collector eine Rolle spielt. Niemand will dass die Frame-Rate einbricht, weil der GB seine Runde macht. Aber das muss doch in den Griff zu bekommen sein.

    Benutzer wird von Ihnen ignoriert. Anzeigen

  2. Re: In C++ implementiert?

    Autor PrometheusX 18.02.13 - 02:19

    PrometheusX schrieb:
    --------------------------------------------------------------------------------
    > .......... auf C(++) zurückgegriffen wird.
    > .......... entsprechenden Entwicklungen.
    SORRY!
    .......... auf C(++) zurückgegriffen wird?
    .......... entsprechenden Entwicklungen?

    Benutzer wird von Ihnen ignoriert. Anzeigen

  3. Re: In C++ implementiert?

    Autor doctorseus 18.02.13 - 03:10

    Kommt auf das Einsatzgebiet an. In der Gameindustrie ist C++ noch gang und gebe. Überall in allen großen Studios und Spielen. Liegt an der Hardwarenähe und daran das die Performance in diesem Bereich (Grafikdarstellung) immer noch wesentlich höher ist als bei VM basierende Sprachen. Vor allem kann man optimieren und vor allem bei Konsolenspielen ist das unumgänglich.
    Veraltet ist C++ womöglich schon, aber nicht überall, vor allem nicht bei Spielen.

    Plattformunabhängigkeit passt mit Grafikdarstellung einfach nicht zusammen. Die Spiele werden für die einzelnen Plattformen optimiert weil diese unterschiedlich viel hergeben.



    1 mal bearbeitet, zuletzt am 18.02.13 03:12 durch doctorseus.

    Benutzer wird von Ihnen ignoriert. Anzeigen

  4. Re: In C++ implementiert?

    Autor Sghirate 18.02.13 - 04:57

    Hi,

    Bei Engines gibt es eine Reihe (möglicher) Gründe [eine TL;DR-Version des folgenden Blocks ist nach dem Block zu finden]:
    Ein wichtiger Punkt sind Low-Level-Bibliotheken (DirectX und Betriebssystemsfunktionen), sowie Middleware. Low-Level Funktionen neigen dazu nativ zu sein und weisen nicht selten entweder unvollständige oder schlicht garkeine managed Version auf. Am Beispiel von DirectX: Man müsste entweder erst einmal einen eigenen Wrapper implementieren (und diesen pflegen), oder aber auf eine bestehende Implementierung zurückgreifen. Hier gibt es zum einen etwas kompletteres, wie XNA, dessen Zukunft jedoch eher düster aussieht und wo man sich nicht nur für eine Rendering-Bibliothek, sondern für eine [kleine] Engine [und dessen Nachteile] entscheidet. Als Alternative gäbe es Implementierungen, wie ManagedDX oder SlimDX, welche üblicherweise dem nativen DirectX um Monate (oder mehr) hinterherhinken und manche Funktionen garnicht implementieren. Bei Middleware ist es ähnlich, so wird diese häufig mit Blick auf die (nicht unbedingt ausschließtliche) Verwendung in C++-Projekten entwickelt - ich schaue hierbei in Richtung SpeedTree, Scaleform, RadGameToos, FMod und weitere. Wenn man also zum Beispiel eine C#-Engine entwickeln will muss man zusätzlichen Aufwand für die Implementierung (und das Testen und ähnliches) der Middleware-Wrapper einberechnen, oder aber man wählt aus dem (kleineren) Pool der Middleware, welche C#-Bindings anbietet.
    Als weiteren Punkt haben wir Code-Reuse. Auch wenn Studios (und vorallem Publisher) gerne die Verwendung der "vollkommen neuentwickelten Super-Engine-XY" verkünden handelt es sich dabei weder um komplett neu- noch komplett eigenentwickelte Frameworks. Sei es, dass man sich eine Engine von einem anderem Unternehmen einkauft und nach Anpassungen einen neuen Namen gibt, oder aber, dass man eine interne (alte) Engine nimmt und aufgrund dessen Code-Basis ein neues Inkrement schafft. Selbst bei "weitesgehend" neuen Engines, kann man sich sicher sein, dass einzelne Module oder Klassen aus alten Engines und Projekten "mitgenommen" wurden. (Beispiel: upload.wikimedia.org/wikipedia/commons/8/85/Quake_-_family_tree_2.svg )
    Noch ein Punkt sind die Leute, die damit arbeiten. Sprich, was für Entwickler in die Industrie eingestiegen sind, wie sich diese bewegt haben und welche Auswirkungen das auf Unternehmen und Technologien hatte. Frühere Projekte wurden in C/C++ implementiert - brauchte man neue Mitarbeiter, so sucht man Leute, die im bestehenden Team nützlich sind und auch mit vorhandener Infrastruktur arbeiten können; Will heißen: C/C++ ist ein eine Kernfähigkeit für Entwickler. Diese neuen Entwickler sammeln Erfahrung (arbeiten dabei tag-ein-tag-aus mit C/C++) verlassen unter Umständen das Unternehmen und gründen ein neues. Schauen dort natürlich, dass sie ihre Projekte möglichst effizient umsetzen, also in vertrauter/bewährter Umgebung. C/C++ => Der Kreislauf wiederholt sich.

    TL;DR:
    -Viele Bibliotheken, die in der Spieleentwicklung wichtig sind, sind für C/C++ entwickelt.
    -Engines werden häufig "aus alten Engines und Modulen" geboren, welche üblicherweise in C/C++ geschrieben sind.
    -Erfahrene Entwickler in der Spieleindustrie haben ihre Erfahrung nicht selten durch Arbeit mit C/C++-Code gesammelt
    -Bei großen, kommerziellen Projekten (wie Engines) macht es Sinn mit bewährten/vertrauten Umgebungen und Vorgehensweisen zu arbeiten (geringeres Risiko).
    -Im großen und ganzen das "Henne-Ei-Problem". (Veteran startet C/C++-Projekt; C/C++-affine Jünglinge werden als Unterstützung herangeholt; Jüngline sammeln weitere Erfahrung mit C/C++ und reifen zu Veteranen; das Ganze wiederholt sich)



    SO, nun aber Einwände:
    Das Ganze bezieht sich auf Engines. Diese bilden aber nur einen Teil eines Spiels. Es kann also sehr gut passieren, dass die Engine selbst in C/C++ implementiert wurde, während die Spiel-Logik in einer komplett anderen Sprache (sei es LUA, C#, Python, oder sogar etwas selbstgestricktes) implementiert wurde. Gerade weil hier die Performance-Unterschiede weniger drastisch sind, und die jeweiligen Vorteile der Sprache (in den Augen der Entwickler), mit Blick auf das Projekt überwiegen. Siene es der Wegfall der Speicherverwaltung, Änderungen zur Laufzeit, einfachere Lesbarkeit oder sonst etwas.
    Auch ist der Fokus hierbei auf der Engine als Bibliotheken-Sammlung statt Toolset. Mit Blick auf Stellenauschreibungen von (AAA-)Studios und einigen öffentlich verfügbaren Werkzeugen spielt hier C# zunehmend eine wichtige Rolle.
    Ebenso kann man die Aussage "C/C++ ist die Sprache der Spiele" nur mit Blick auf AAA Games (einigermaßen) Sinn macht. Sobald man den Blick auf Mobile-, Browser- oder Indie-Games richtet, sieht die Welt schon anders aus. So sind hier Sprachen wie Java, C# und JavaScript wohl eher dominierend.



    Als Fazit würde ich sagen, dass C++ als dominierende Sprache ein historisch gewachsenes Phänomen ist, welches dank Kosten-Nutzen-Rechnung diese Rolle in bestimmten Teilbereichen beibehalten wird. Das heißt jedoch nicht, dass andere Sprachen in der Spieleentwicklung keinen Platz haben, oder aber C++ nicht das Wasser reichen könnten. Alle Sprachen haben ihre Vor- und Nachteile, wodurch sie in bestimmten Fällen nunmal besser oder schlechter geeignet sind. Eine einzelne Sprache (/ein einzelnes Paradigma) als grundlegend perfekt, oder aber gänzlich nutzlos zu bezeichnen ist also vergleichsweise kurzsichtig.



    MfG Sghi'

    Benutzer wird von Ihnen ignoriert. Anzeigen

  5. Re: In C++ implementiert?

    Autor HerrMannelig 18.02.13 - 08:11

    bei den meisten modernen Games kommt es drauf an möglichst toll auszusehen. Das heißt, das Spiel muss bei gegebener Hardware auch möglichst performant laufen.

    Wenn du dich damit auseinandersetzt, wie Java oder teils auch C# funktionieren, dann findest du heraus, dass diese nicht annähernd so effizient _können_, wie bspw. c/c++.

    Da geschieht einfach noch viel zu viel im Hintergrund. In c++ muss der Programmierer jede Menge Dinge beachten, die bspw. in Java total egal sind, weil da die VM für einen drauf achtet und diese übernimmt. Dadurch entsteht in Java aber auch ein riiiesiger Overhead. Hier gehts nicht um einfache Berechnungen, sondern um die Verwaltung von Objekten / dynamische Speicherbelegung / Adressierung, usw.

    Außerdem kann man man c++ Dinge machen, die bei Java einfach fast ausgeschlossen sind. Spiele auf Konsolen sehen heute noch so relativ gut aus, weil dort einfach sehr Hardwarenah programmiert wird. Das kannst du mit Java einfach nicht in der Form.

    So, dann gibts noch die immer mehr werdenen Indiespiele. Die meisten sind auch hier mit C++ geschrieben. Da ist man einfach unabhängiger, als würde man C# verwenden. Will man plattformunabhängig Spiele anbieten, dann führ fast kein Weg an c++ vorbei. Java ist halt auch immer so ne Sache. Für einfachere 2D Spiele, ok. Aber für mehr... da wirds dann schnell unperformant. Außerdem gibts leider immer wieder Inkompatibilitäten zwischen den Plattformen. Bei Indiespielen wird dann halt gerne immer öfter auf Frameworks wie Unity oder XNA zurückgegriffen. Sowas in der Form ist mir für Java jedenfalls nicht bekannt.

    Benutzer wird von Ihnen ignoriert. Anzeigen

  6. Re: In C++ implementiert?

    Autor redmord 18.02.13 - 08:21

    Läuft nicht Mincecraft in Java? Auf meinem alten Q6600 mit Gf470 und 8GB DDR3 wollte das bei 2560*1440 mit max settings nicht annähernd flüssig laufen, während SC2 fast durchgehend zwischen 45 bis 60 FPS lieferte! :D

    Benutzer wird von Ihnen ignoriert. Anzeigen

  7. Re: In C++ implementiert?

    Autor JanZmus 18.02.13 - 08:32

    HerrMannelig schrieb:
    --------------------------------------------------------------------------------
    > bei den meisten modernen Games kommt es drauf an möglichst toll auszusehen.

    Das hat doch nix mit modern zu tun, das war doch schon IMMER so, seit es Games gibt.

    Benutzer wird von Ihnen ignoriert. Anzeigen

  8. Re: In C++ implementiert?

    Autor rommudoh 18.02.13 - 09:15

    redmord schrieb:
    --------------------------------------------------------------------------------
    > Läuft nicht Mincecraft in Java? Auf meinem alten Q6600 mit Gf470 und 8GB
    > DDR3 wollte das bei 2560*1440 mit max settings nicht annähernd flüssig
    > laufen, während SC2 fast durchgehend zwischen 45 bis 60 FPS lieferte! :D


    Das liegt aber nicht (nur) an der Programmiersprache Java, sondern auch an der relativ inperformanten Engine von Minecraft. Die wäre auch in C++ nicht sonderlich effektiv.

    Benutzer wird von Ihnen ignoriert. Anzeigen

  9. Re: In C++ implementiert?

    Autor tunnelblick 18.02.13 - 09:17

    quatsch - tetris in c++ auf dem gameboy? :)

    "we have computers, which can beat your computers"

    Benutzer wird von Ihnen ignoriert. Anzeigen

  10. Re: In C++ implementiert?

    Autor Endwickler 18.02.13 - 10:45

    PrometheusX schrieb:
    --------------------------------------------------------------------------------
    > Ich vermute mal dass die Engine in C++ implementiert ist. Wenn ich mich so
    > umhöre, dann fällt bei'm Thema moderne Softwareentwicklung mit C++ immer
    > häufiger ein Schlagwort, und zwar "veraltet". Aber wie kann es denn sein,
    > dass, wenn selbst neue Softwareprojekte starten, die am Ende ein
    > lauffähiges, hochauflösendes 3D-Computerspiel zum Ziel haben, immer wieder
    > auf C(++) zurückgegriffen wird. Die populärsten Grafik-Engines kommen laut
    > Wikipedia von id Software, Epic Games, Crytek und Valve. Und diese Engines
    > haben mit Sprachen wie Java wohl am wenigsten zu tun. Wenn die
    > Perfomancediskrepanzen zwischen VM-Sprachen und hardwarenahen Sprachen
    > immer geringer werden und das auch propagiert wird, wo sind dann die
    > entsprechenden Entwicklungen. Ich weiß dass es z.B. die JMonkeyEngine gibt,
    > aber besonders beeindruckend (im Gegensatz zu den o.g.) ist diese nicht.
    > Ich habe gelesen dass z.B. der Garbage Collector eine Rolle spielt. Niemand
    > will dass die Frame-Rate einbricht, weil der GB seine Runde macht. Aber das
    > muss doch in den Griff zu bekommen sein.

    C++ ist zwar alt, aber noch sehr lange Zeit nicht veraltet. es ist eine Sprache, die gut gepflegt wird. Das äußert sich auch darin, dass immer mal wieder auch neue Bibliotheken aufgenommen werden, die einem die Arbeit mit C++ erleichtern und so manche Aufgabe standardisieren sollen. Durch die Historie gesehen ist es so, dass C++ eine der mächtigsten Sprachen auf dem PC ist.

    Stünde vor so manchem Projekt, und hier schreibe ich nicht nur von Spielen, eine genaue Bedarfs-, Anforderungs- und Zielstellungsanalyse, käme so manches mal eine andere Sprache als C++ zum Einsatz. Ich persönlich halte zum Beispiel Lisp für eine sehr gute Alternativsprache, wenn man nichts hardwarenahes benötigt. Durch die zunehmende Geschwindigkeit in der Befehlsabarbeitung, wobei es da mal wieder echt Zeit für etwas neues nach der Parallelisierung und den Superpipelines wird, kommen auch langsam die Hochsprachen ohne maschinennahe Programmierelemente in den Fokus der Benutzbarkeit. Dazu wird es aber einen größeren Schnitt brauchen, da, wie schon geschrieben wurde, oft an dem, was man kennt, festgehalten wird. Wie so ein großer Schnitt aussehen kann, sprengte den Rahmen eines Forentextes.

    Zu Bungie und Destiny:
    Die Grafiken machen einen ordentlichen Eindruck und wenn sie in dem Spiel wirklich die Phantasie beflügeln und den Spaß am Spiel mit dem Universum vor das Töten anderer Spielfiguren stellen, könnte es ein neuer Meilenstein werden.



    1 mal bearbeitet, zuletzt am 18.02.13 10:51 durch Endwickler.

    Benutzer wird von Ihnen ignoriert. Anzeigen

  11. Re: In C++ implementiert?

    Autor JanZmus 18.02.13 - 15:17

    Verstehe den Zusammenhang zum Thema nicht.

    Benutzer wird von Ihnen ignoriert. Anzeigen

Neues Thema Ansicht wechseln


Entschuldigung, nur registrierte Benutzer dürfen in diesem Forum schreiben. Klicken Sie hier um sich einzuloggen


Anzeige

Haben wir etwas übersehen?

E-Mail an news@golem.de


3D-Druck ausprobiert: Internetausdrucker 4.0
3D-Druck ausprobiert
Internetausdrucker 4.0
  1. Niedriger Schmelzpunkt 3D-Drucken mit metallischer Tinte
  2. Deltadrucker Magna Japanisches Unternehmen zeigt Riesen-3D-Drucker
  3. 3D-Technologie US-Armee will Sprengköpfe drucken

iMac mit Retina 5K angeschaut: Eine Lupe könnte helfen
iMac mit Retina 5K angeschaut
Eine Lupe könnte helfen
  1. Apple Tonga-XT-Chip mit 3,5 TFLOPs für den iMac Retina
  2. iFixit iMac mit Retina-Display ist schwer zu reparieren
  3. Apple iMac Retina bringt mehr als 14 Megapixel auf das Display

Data Management: Wie Hauptspeicherdatenbanken arbeiten
Data Management
Wie Hauptspeicherdatenbanken arbeiten

  1. Hoverboard: Schweben wie Marty McFly
    Hoverboard
    Schweben wie Marty McFly

    Ein US-Unternehmen hat eine Magnetschwebetechnik entwickelt, die unter anderem den Bau eines Hoverboards ermöglicht. Damit das Board und noch andere Gegenstände schweben, suchen die Gründer Unterstützung per Crowdfunding.

  2. Nepton 120XL und 240M: Cooler Master macht Wasserkühlungen leiser
    Nepton 120XL und 240M
    Cooler Master macht Wasserkühlungen leiser

    Durch neue 120-Millimeter-Lüfter sollen die Wasserkühlungen der Serie Nepton von Cooler Master unter Last weniger Lärm verursachen. Die neu entwickelten Ventilatoren der Serie Silencio sollen später auch einzeln angeboten werden.

  3. Deutsche Telekom: Umstellung auf VoIP oder Kündigung erst ab 2017
    Deutsche Telekom
    Umstellung auf VoIP oder Kündigung erst ab 2017

    Die Telekom macht nach Berichten über Kündigungsdrohungen gegen PSTN/ISDN-Anschlussinhaber einen Rückzieher. Vor 2017 werde, "bis auf einige wenige Ausnahmen", nicht zu Kündigungen wegen VoIP-Verweigerung gegriffen.


  1. 19:40

  2. 18:48

  3. 17:48

  4. 17:35

  5. 17:26

  6. 17:02

  7. 16:56

  8. 16:45