OOP oder Prozedural?
-
Hallo
Ich lese gerade ein Buch über Spieleprogrammierung mit DirectX.
Darin wird eine eigene Libary entwickelt, die die DirectX-Funktionen umgibt. Dabei wird darauf hingewiesen, dass die Geschwindigkeit sehr wichtig für ein Spiel ist.
Die Libary wird deshalb größtenteils in C geschrieben und ist prozedural aufgebaut.
Jetzt frage ich mich, ob man diesen Ansatz beibehalten sollte und wenn man dann ein eigenes Spiel entwickeln will, diese Libary verwenden sollte, oder ob man parallel zu der Entwicklung im Buch eine eigene Libary schreiben sollte, die ein OOP Konzept verfolgt und auch sonst z.B. Streams verwendet statt der alten C-Funktionen.
Im Endeffekt stellt sich mir also die Frage: ein komplexes Klassensystem aufbauen, welches dann zu Lasten der Geschwindigkeit geht, oder kurze schnelle Funktionen in einer Libary nutzen und diese erst bei der Spielgestaltung in Klassen verpacken?
Was würdet ihr mir empfehlen und macht ein Klassenkonzept von anfang an einen großen Geschwindigkeitsunterschied aus (damit mein ich z.B. ein Singleton für DirectDraw etc.)?
-
Dieses "hardcore optimieren wo nur geht" gehört der Vergangenheit an. Bei heutigen Spielen wird häufig Objektorientierte Programmierung verwendet, einige Beispiele? Doom3, Farcry, Unreal Tournament, ...
Und ja, da werden z.T. auch Streams verwendet.
-
wie schnell es laeuft haengt bei c/c++ von den faehigkeiten des programmieres ab.
btw. wenn jemand streams oder fopen benutzt, hat er eh nicht mit geschwindigkeit am hut.
-
Die grosse Optimierungs-Arbeit fällt heute mehr bei der Grafik an, also Sichtbarkeitstest, optimale Nutzung von Hardware-Features usw. Früher wurden die Engines so zusammengepackt das sie gerade so eben "3D Grafik" darstellen konnten, in dem Umfang das eine 486er CPU ohne Hardware-Beschleunigung das auf die Reihe kriegt (Siehe die ersten 3D Engines, auch "2.5D" Engines genannt - Doom1+2, Build Engine usw). Da durfte natürlich keine Leistung verschenkt werden, damit dieses Konstrukt auf den altertümlichen Dingern auch flüssig lief. Aber heute... Lass doch mal einen Profiler laufen und guck dir an, welche Rechenzeit das Zeug frisst, was nichts mit Grafik am Hut hat
-
die meisten spiele sind heutzutage doch immer noch cpu limitiert, was soll da der unterschied zu frueher sein, als 95% der rechenzeit der cpu fuer graphik draufging
-
Welches Spiel soll denn heute CPU limitiert sein?
Speicher ja, aber CPU? Naja ich weiss nich...
-
Cpp_Junky schrieb:
Welches Spiel soll denn heute CPU limitiert sein?
so ziemlich jedes gut optimierte spiel ist cpu limitiert. deswegen kann man die meisten auch auf 1600*1200 mit 4AA (oder mehr) und 8AF spielen.
hier z.b. shooter benchmarks (und das sind die graphiklastigsten spiele) http://www.hartware.de/review_680_14.html wie du dort sehen kannst bewegt sich die framerate nicht bei moderaten aufloesungen ueberhaupt nicht, und ein AMD64 4000+ ist weit mehr als bei den meisten spielen als optimal angegeben wird.
-
Hm überzeugt mich nicht, ich will einen Test sehen auf dem die Framerate mit einer schnelleren CPU signifikant höher ist.
-
http://www.xbitlabs.com/articles/cpu/display/29cpu-hl2_3.html
Es gibt solche und solche.
Die meisten Spiele-Benchmarks findet man bei den Indoor FPShootern, die noch dazu den Schwerpunkt auf Multiplayer haben, also kaum AI berechnen müssen.Bei Spielen wie Rome-TotalWar, ArmedAssault oder FlightSimX sähe das vermutlich anders aus, hier sind organisierte Benchmarks aber schwer zu finden.
-
Cpp_Junky schrieb:
Hm überzeugt mich nicht, ich will einen Test sehen auf dem die Framerate mit einer schnelleren CPU signifikant höher ist.
Was hat die Framerate mit der CPU zu tun?
-
SeppSchrot schrieb:
http://www.xbitlabs.com/articles/cpu/display/29cpu-hl2_3.html
Es gibt solche und solche.
Die meisten Spiele-Benchmarks findet man bei den Indoor FPShootern, die noch dazu den Schwerpunkt auf Multiplayer haben, also kaum AI berechnen müssen.Bei Spielen wie Rome-TotalWar, ArmedAssault oder FlightSimX sähe das vermutlich anders aus, hier sind organisierte Benchmarks aber schwer zu finden.
Jo da kann man schön sehen, bei welchen Einstellungen was zum Flaschenhals wird. Auf 1024x768 ohne alles ist es klar, das die CPU limitiert. Da schläft die Grafikkarte ja dabei ein. Auf Qualitäts-Einstellungen (1280x1024, 4x FSAA, 16x AF) bewegt sich der Unterschied dann lediglich noch im Bereich von 4 Frames.
lolz schrieb:
Cpp_Junky schrieb:
Hm überzeugt mich nicht, ich will einen Test sehen auf dem die Framerate mit einer schnelleren CPU signifikant höher ist.
Was hat die Framerate mit der CPU zu tun?
Hast du den Thread überhaupt gelesen?
-
Cpp_Junky schrieb:
lolz schrieb:
Cpp_Junky schrieb:
Hm überzeugt mich nicht, ich will einen Test sehen auf dem die Framerate mit einer schnelleren CPU signifikant höher ist.
Was hat die Framerate mit der CPU zu tun?
Hast du den Thread überhaupt gelesen?
Ja hab ich, aber ich hab gepennt (noch zu früh am Morgen :D).
-
Cpp_Junky schrieb:
Jo da kann man schön sehen, bei welchen Einstellungen was zum Flaschenhals wird. Auf 1024x768 ohne alles ist es klar, das die CPU limitiert. Da schläft die Grafikkarte ja dabei ein. Auf Qualitäts-Einstellungen (1280x1024, 4x FSAA, 16x AF) bewegt sich der Unterschied dann lediglich noch im Bereich von 4 Frames.
meistens weil die benchmarks lediglich graphik testen, z.b. die timedemos. sobald logik, physic,sound etc. voll laeuft, bist du in den meisten spielen cpu limitiert.
-
Ja, sowas hab ich mir auch mal gedacht. Also ich hab ein Spiel (Oblivion). Stelle ich bei mir die grafischen Einstellungen auf fast voll, läuft es ganz flüssig. Dann wollte ich mal mehr rausholen, indem ich einige Features runtergeschraubt hab --> kein signifikanter Unterschied.
Das lustigste war sowieso, dass ich manchmal im Spiel heftige Ruckler bei vielen Tieren auf einmal hatte, zig Menschen haben nicht geschadet. Dann entdeckte ich das Problem, der Flaschenhals war meine (Onboard-)Soundkarte. Oblivion erzeugt bei _jedem_ Auftreten von nicht menschlichen Füßen einen realistischen 3D-Sound. Ein Rudel Wölfe hat meine Soundkarte in die Knie gezwungen.
Gruß
Don06
-
"Auf CPU limitiert" bedeutet, "die ganze Arbeit hat die CPU" oder was hat man darunter zu verstehen oO?
-
CPU-limitiert heißt, dass die Grafikkarte sehrwohl noch genügend Power hätte um mehr FPS darzustellen es aber an CPU-Leistung dafür fehlt.
MfG SideWinder
-
hach, da macht es richtig spaß, eines der jüngeren schlagwörter in den raum zu werfen GPGPU.
Bis jetz liegen ja fast alle logischen vorgänge (auch die für tausende instanzen) bei der cpu, die gpu macht grafik. saubere trennung (sollt ich auch ma mit dem müll so halten oO). Eig wäre eine gpu für diese aufgaben aber besser geeignet, aufgrund der konstruktion.
-
piXelshooter schrieb:
Bis jetz liegen ja fast alle logischen vorgänge (auch die für tausende instanzen) bei der cpu, die gpu macht grafik. saubere trennung (sollt ich auch ma mit dem müll so halten oO). Eig wäre eine gpu für diese aufgaben aber besser geeignet, aufgrund der konstruktion.
nein, ueberhaupt nicht.
-
piXelshooter schrieb:
hach, da macht es richtig spaß, eines der jüngeren schlagwörter in den raum zu werfen GPGPU.
Bis jetz liegen ja fast alle logischen vorgänge (auch die für tausende instanzen) bei der cpu, die gpu macht grafik. saubere trennung (sollt ich auch ma mit dem müll so halten oO). Eig wäre eine gpu für diese aufgaben aber besser geeignet, aufgrund der konstruktion.die gpu ist für grafische berechnungen designed, und nicht für logische vorgänge. diese technik nutzt man nur, weil die graka in der logischen rechenphase des programms relativ wenig zu tun hat, und man diese Rechenpower nicht verschwenden will. Und natürlich, weil die gpus enorm viele berechnungen parallel vornehmen können.
Was wir bräuchten, wär eine art LPU
-
Hallo
hab mich jetzt dafür entschieden ein Klassendesign zu verwenden um auf die DirectX Funktionen etc. zuzugreifen.
Jetzt stehe ich aber vor dem Problem der Performance.
Wie hier schon gesagt wurde, scheint der Performanceunterschied zwischen prozeduraler und objektorientierter Programmierung heutzutage nicht mehr all zu groß zu sein.
Jetzt überlege ich aber, ob ich die Mittel der STL, besonders vectoren, verwenden soll oder lieber auf C Arrays zurückgreifen soll. Wie groß schätzt ihr die Geschwindigkeitsunterschiede hierbei ein?
Bin nämlich momentan dabei, eine Klasse für die Palette zu schreiben und benötige dazu entweder ein Array für die einzelnen Einträge oder einen vector.
Oder gibt es anstelle eines vectors noch einen anderen Container, der schneller ist also eher an ein normales Array ankommt?
PS: Wie ich in einem anderen Forum zum Thema Doom3 SDK gelesen habe, wurden dabei anscheinend auch C Arrays und andere C Methoden genauso wie Klassen verwandt (also "C+").