Objektorientiert oder nicht ?

[Beruga]

Hallo Leute ...

ich hab vor kurzem angefangen an einem Game (Jump'n'Run) zu arbeiten und bin mittlerweile fast mit der Architektur fertig, dabei versuchte so Objektorientiert zu arbeiten wie es geht (in Delphi) .... nun bin ich mir jetzt gar nicht mehr sicher ob die Idee ein Spiel objektorientiert zu entwickeln so sinnvoll war, einmal weil es sicherlich auf einer anderen Weise nicht so komplex währe und vielleicht auch schneller

also es ist mein erstes Piel und es währe sehr nett wenn ein kundiger mal hier weiter helfen könnte .....

danke schon mal im voraus

 

[Uranus]

Nun ja allgemein soll OOP ja eher der Strukturierung eines Projektes und der Modularisierung dienen als der Geschwindigkeit. Um trotzdem eine hohe Geschwindigkeit zu erreichen wird im Allgemeinen dann mit Zeigern bzw. Referenzen gearbeitet (dadurch muss weniger im Hauptspeicher umkopiert werden). Auch wird sehr darauf wert gelegt die Daten sinnvoll im Hauptspeicher anzuordnen (wenn du z.B. zum Rendern immer alle Punkte eines Objekts erst aus verschieden Speicherbreichen herkopieren musst ist das langsamer als wenn du sie per sturem memorycopy Blockweise transportieren kannst).

Hättest C++ verwendet könnte ich dich beruhigen. Die Compiler erzeugen Code an den man selbst mit Assembler nur schwer ran kommt.

An Stellen die sehr oft gebraucht werden kann man in C++ Inline Funktionen verwenden (ka ob man das bei Delphi kann)

Im groben und ganzen kann man eigentlich sagen wenn man sich die Struktur gut überlegt muss man fast keine Geschwindigkeitseinbusen hinnehmen.

 

[Beruga]

hmmm ... stimmt daran hab ich garnicht gedacht ... danke !

 

[squeaker]

Original geschrieben von Uranus

Hättest C++ verwendet könnte ich dich beruhigen. Die Compiler erzeugen Code an den man selbst mit Assembler nur schwer ran kommt.

An Stellen die sehr oft gebraucht werden kann man in C++ Inline Funktionen verwenden (ka ob man das bei Delphi kann)

Im groben und ganzen kann man eigentlich sagen wenn man sich die Struktur gut überlegt muss man fast keine Geschwindigkeitseinbusen hinnehmen.

das fürchte ich, kann ich so nicht unterschreiben. Ein sehr guter Assemblerprogrammierer kann jeden C/C++ Compiler schlagen - die Frage ist ob es das Wert ist (Wartbarkeit, Zeitaufwand).
Die Struktur eines Programmes hat sehr viel mit der Geschwindigkeit zu tun. Gute und schnelle Datenstrukturen an den Schlüsselpunkten sind ein guter Ansatz für Geschwindigkeit. Wenn sie dann nicht reicht, kann man Anfangen über ASM nachzudenken.

 

[Uranus]

Naja bei reinen Adressoperationen bist wirklich mit Assembler besser dran weil der Compiler da irgendwie generelle Probleme hat den optimalen Weg zu finden. Deshalb is memcpy z.B. auch ein Assembler Programm.

Aber was den Rest betrifft hat man es wirklich enorm schwer weil C/C++ Compiler
derart stark optimieren das es eigentlich quatsch is da zu versuchen mit Assembler noch was raus zu holen was man wirklich merkt. Die Compiler achten darauf wie viele Takte der einzelne Befehl brauchen wird und solche Dinge.
Wenn man sich das ganze mal in Assembler ausgeben lässt was der Compiler erzeugt und sich die Mühe macht nachzurechnen wirst feststellen das da wenn überhaupt nur wenig Raum für Optimierung ist. Das durfte ich mal machen

 

[chibisuke]

Nun also die Frage OOP oder nich....

Das hängt droßteils von den Augen des Betrachters ab, was besser geeignet ist, jedoch empfielt sich vor allem bei größeren Projekten die verwendung von OOP, da es die übersichtlichkeit wesentlich erhöhrt. Auch kann man wenn man OOP programmiert relativ einfach mit großen mengen an daten sauber umgehen, is ja alles in den objekten versteckt.

Die Geschwindigkeit von OOP is nahezu gleich der von konventionellem prozeduralem programmieren, sofern der Compiler anständig arbeitet, aber schwarze schaafe gibts ja überall.

 

[Beruga]

also ich hab mir das jetzt alles durchgelesen ... und ich denke mal dass ich auch bei OOP bleiben werde ... da man fast nur mit Referenzen arbeitet und dadurch auch keine Geschwindigkeitsveruste gibt (hoffe ich zu mindest)

 

[squeaker]

Original geschrieben von Uranus

Aber was den Rest betrifft hat man es wirklich enorm schwer weil C/C++ Compiler
derart stark optimieren das es eigentlich quatsch is da zu versuchen mit Assembler noch was raus zu holen was man wirklich merkt. Die Compiler achten darauf wie viele Takte der einzelne Befehl brauchen wird und solche Dinge.
Wenn man sich das ganze mal in Assembler ausgeben lässt was der Compiler erzeugt und sich die Mühe macht nachzurechnen wirst feststellen das da wenn überhaupt nur wenig Raum für Optimierung ist. Das durfte ich mal machen

ich habe nirgendwo gesagt, dass es einfach sei. Ich lese auch noch das masmforum und da gibt es max. eine Hand voll Leute die das könnten. Aber wenn du dir einfach überlegst, wie gross die Unterschiede in der Laufzeit zwischen C/C++ Compilern (Intel, Borland, VC, GCC) bei dem "optimierten" Code ist, dann wirst du feststellen, dass da immer noch Raum bleibt. Ausserdem hat ein Compiler NIE Verständnis für den Algorithmus - er kann nur lokal optimieren.

Beispiel aus dem Masmforum:

Orginalalgorithmus: ~8000 cycles
Optimiertes C: ~700 cycles
Optimiertes Assembler: ~300 cycles
(allerdings werden da dann die Optimierungen schon Prozessorabhängig).

Ich sag mal - Faktor 2-3 geht sicher noch - aber einfach ist es nicht.