c++ vs delphi

[TheAn00bis]

Ist denn von der Perfomance kein Unterschied zu finden?

Es wäre also möglich ein modernes Spiel auch in Delphi zu schreiben? Oder nicht?

[NicoDE]

Zitat von TheAn00bis:

Es wäre also möglich ein modernes Spiel auch in Delphi zu schreiben? Oder nicht?

Eher nicht. 90% der Software die man einkauft (Physik-, Animatons-, Sound-, Musik-, ...System) um überhaupt mit dem Spiel anzufangen, bieten nur ein C/C++-Interface.

[mael]

Zitat von NicoDE:

Zitat von TheAn00bis:

Es wäre also möglich ein modernes Spiel auch in Delphi zu schreiben? Oder nicht?

Eher nicht. 90% der Software die man einkauft (Physik-, Animatons-, Sound-, Musik-, ...System) um überhaupt mit dem Spiel anzufangen, bieten nur ein C/C++-Interface.

Es gibt sogar Leute die jetzt mit C# Spiele entwickelnhttp://gameports.net/gp/offlineseite/artikel_1598.html (Google Cache weil die original Seite offline ist)

Von der Performance selber gesprochen:
Delphi hat Probleme was die Geschwindigkeit bei Gleitkommaberechnungen angeht, da optimiert der Kompiler leider so gut wie gar nicht. Ich kenne bis jetzt auch keinen Delphi/Pascal Kompiler der die "neuen" Prozessorfeatures wie MMX oder SSE direkt zur Codeoptimierung nutzt.
Für Graphik alleine ist das nicht so schlimm, das Problem ist erst bei komplexen (sprich realistischen) Physikengines oder der KI von Gegnern.

Wer einen echten Vorsprung gegenüber der Konkurrenz haben will der wird mit vielen Einkäufen nicht so weit kommen, denn er muß sich abheben. Graphik und Effekte zählen heute leider mehr als die Spielidee.

[tommie-lie]

Zitat von mael:

Zitat von NicoDE:

Zitat von TheAn00bis:

Es wäre also möglich ein modernes Spiel auch in Delphi zu schreiben? Oder nicht?

Eher nicht. 90% der Software die man einkauft (Physik-, Animatons-, Sound-, Musik-, ...System) um überhaupt mit dem Spiel anzufangen, bieten nur ein C/C++-Interface.

Es gibt sogar Leute die jetzt mit C# Spiele entwickeln

Lies richtig, Nico sagte, daß die Bibliotheken, die man einkauft, nur C(++)-Interfaces haben. Wenn du sie dir selbst schreibst, hast du dieses Problem nicht, aber oft genug kauft man fremde Engines und entwickelt das eigene Spiel darauf aufbauend.

[mael]

Zitat von tommie-lie:

Zitat von mael:

Zitat von NicoDE:

Zitat von TheAn00bis:

Es wäre also möglich ein modernes Spiel auch in Delphi zu schreiben? Oder nicht?

Eher nicht. 90% der Software die man einkauft (Physik-, Animatons-, Sound-, Musik-, ...System) um überhaupt mit dem Spiel anzufangen, bieten nur ein C/C++-Interface.

Es gibt sogar Leute die jetzt mit C# Spiele entwickeln

Lies richtig, Nico sagte, daß die Bibliotheken, die man einkauft, nur C(++)-Interfaces haben. Wenn du sie dir selbst schreibst, hast du dieses Problem nicht, aber oft genug kauft man fremde Engines und entwickelt das eigene Spiel darauf aufbauend.

Lies Du richtig und komplett :

Zitat:

Wer einen echten Vorsprung gegenüber der Konkurrenz haben will der wird mit vielen Einkäufen nicht so weit kommen, denn er muß sich abheben. Graphik und Effekte zählen heute leider mehr als die Spielidee.

[NicoDE]

Zitat von mael:

Wer einen echten Vorsprung gegenüber der Konkurrenz haben will der wird mit vielen Einkäufen nicht so weit kommen, denn er muß sich abheben.

Meiner bescheidenen Meinung nach sind 95% aller Titel im Budget-Bereich - da reichen 'kleine' Effekte für's 'kleine' Geld
Ich nehme an, dass Du die 'großen' Titel meinst... auch die kaufen Subsysteme (die halt aufgebohrt werden), da niemand mehr die Zeit hat, sich 5 Jahre hinzusetzen um eine Engine und ein Spiel zu entwickeln. Zudem wird es zunehmends schwieriger in Deutschland Experten in den betreffenden Bereichen (z.B. Animation) zu finden.

Zitat von mael:

Graphik und Effekte zählen heute leider mehr als die Spielidee.

Angebot und Nachfrage. Leider.
Noch jemand Lust auf den Fußball-Manager 2006
(es geht auch anders, auf Siebenwind wird immer noch Rollenspiel mit OU-Engine gespielt )

topic: man kann mit Delphi gute, moderne Spiele entwickeln - ist nur eine Frage der Anforderungen und der Zeit.

[tommie-lie]

Zitat von mael:

Lies Du richtig und komplett :

Zitat:

Wer einen echten Vorsprung gegenüber der Konkurrenz haben will der wird mit vielen Einkäufen nicht so weit kommen, denn er muß sich abheben. Graphik und Effekte zählen heute leider mehr als die Spielidee.

Das ändert nichts an dem, was Nico gesagt hat. Und es werden in der Realität oft viele Dinge dazugekauft, weil die Entwicklungskosten für komplette Eigenentwicklungen zu groß sind. Auch an Graphik und Effekten kann man Dinge kaufen und sie besser machen als andere, das fängt nämlich schon bei liebevolleren Texturen und Modellen an. Man kommt auch mit Einkäufen weit.

[TheAn00bis]

Bleibt mal locker

Ja, mir war klar, dass es so gut wie keine Grafikengine für Delphi zu kaufen gibt. Mir ging es mehr um das theoretische, ob Delphi sonst irgendwelche Nachteile mit sich bring.

Was bedeutet denn Codeoptimierung eigentlich? Natürlich kann ich mir was darunter vorstellen, dass der compilierte Assemblercode so effektiv wie möglich gestalltet ist. Aber macht das so viel aus?

[NicoDE]

Zitat von TheAn00bis:

Natürlich kann ich mir was darunter vorstellen, dass der compilierte Assemblercode so effektiv wie möglich gestalltet ist. Aber macht das so viel aus?

Wenn man sehr häufig verwendete Klassen optimiert (zB Matrizen), dann kann das sehr viel bringen. Aber selbst dafür finden sich Lösungen für Delphi (optimierte C++Builder-Klassen einlinken). Ansonsten ist es einfach mehr Arbeit mit Delphi Language Performanceprobleme zu vermeiden - aber grundsätzlich geht es. Den größten Performancegewinn bringen, aus Erfahrungswerten, immer noch die Optimierung der Algorithmen und Datenstrukturen...

[mael]

Zitat von TheAn00bis:

Was bedeutet denn Codeoptimierung eigentlich? Natürlich kann ich mir was darunter vorstellen, dass der compilierte Assemblercode so effektiv wie möglich gestalltet ist. Aber macht das so viel aus?

NicoDE hat Recht, daß es wesentlich auf den richtigen Algorithmus ankommt.

Berechnungen mit Multimedia Daten lassen sich typischer Weise aber nicht durch einen klugen Algorithmus beschleunigen.
Häufig muß man den kompletten Datenstrom betrachten: Filtereffekte, Überblenden, Tonverzerrung, OGG-Vorbis-Decodierung und Ähnliches können nicht einfach einen Teil der Daten ignorieren.
Häufig wird ist das bei schnellen Algorithmen der Fall: z.B. Clipping: spart Zeichenoperationen, Stringsuche: die Länge des Such-Strings kann verwendet werden um Bytes zu überspringen.

Trotzdem schafft man mit SSE häufig 2-4 fache Beschleunigung (für Multimedia-Daten), weil dort mehrere Datenpakete der gleichen Größe auf einmal verarbeitet werden können.

Was Gleitkommaoperationen angeht: Delphi streut zuviele fwaits in seinen Kode ein, solche Funktionen wie Sin werden als Funktionsaufruf implementiert obwohl der Prozessor direkt dafür einen Opcode anbietet. Da wäre Compilermagic sinnvoller. Dann werden oft Sachen hin und herkopiert auch wenn es unnötig ist.
Es gibt noch anderes... Vor längerer Zeit habe ich mal einen Funktionsparser geschrieben, der den Term dann in Assemblerkode umgewandelt hat. Das war jetzt nicht wirklich optimiert, aber trotzdem immer ungefähr doppelt so schnell wie der von Delphi kompilierte Kode.
C++ Kompilat war meistens noch schneller.

Allgemein, ist Delphi gegenüber klassischen C++ Compilern nicht so schlecht, ausgenommen Intel's C++ Compiler, aber der optimiert ja auch auf die neusten CPUs.