Auch wenns weder was mit OpenGL noch mit Delphi zu tun,dürfte es den ein oder anderen interessieren,das Activision vor Kurzem den kompletten Quellcode zu Civilization : Call to Power 2 veröffentlicht hat.Die Civilization-Reihe (erfunden von Sid Meier,den die "älteren" Jahrgänge hier sicherlich kennen) ist eine der erfolgreichsten Serien in der Computerspielgeschichte und sollte eigentlich jedem ein Begriff sein,weshalb ein Blick in den Quellcode durchaus interessant sein dürfte.
Allerdings musste man aus rechtlichen Gründen die Soundlibrary (Miles-Soundsystem) aus dem Quellcode entfernen,was dieser durchaus nachahmenswerten Aktion von Seiten Activisions jedoch keinen Abriss tut.

Mehr zum Release erfahrt ihr auf dieser Civilization-Fanseite (etwas weiter unten in den News - Direktlink zum Quellcode).Wie bei solchen Release immer der Fall,handelt es sich *nur* um den Quellcode,also ohne die immernoch mit einem Copyright behafteten Spielgrafiken und Sounds.

_________________
www.SaschaWillems.de | GitHub | Twitter | GPU Datenbanken (Vulkan, GL, GLES)

auch wenn es für mich direkt jetzt nicht wirklich nützlich ist, finde ich sowas eine gute Aktion vom Spielehersteller, weil manche dadurch sicherlich viel lernen können...
bei älteren Spielen, die eh nicht mehr verkauft werden ist das ja auch nicht mit Umsatzeinbußen verbunden...

Nützlich ist sowas meist wirklich nicht,aber ich finds recht interessant sich mal den Quellcode professioneller Spieletitel anzusehen,auch wenn bei diesem Quellcode hier leider alle Kommentare entfernt wurden.Allerdings sollten die Hersteller sowas in Zukunft öfter machen (der Homeworld-Quellcode wurde übrigens auch schon veröffentlicht),denn solche Aktionen stärken die Fanbasis und ermöglichen es Leuten wie uns solche Spiele auch auf andere Betriebssysteme oder Sprachen zu portieren,was bei CIV:CTP2 bereits in vollem Gange ist.

_________________
www.SaschaWillems.de | GitHub | Twitter | GPU Datenbanken (Vulkan, GL, GLES)

Ich hab mir die EXE(?) noch nicht gezogen. Wie läuft das ab? Is das direkt ein Installer der den quelltext installiert? oder wie läuft das?

Ansich find ich solche aktionen gut...Die Spielehersteller könnten ruhig mehr alte Spiele rausgramen und herzeigen...Die Fans und Privatprogger werdens ihnen danken.

_________________
Blog: kevin-fleischer.de und fbaingermany.com

Ja,das ist ein Installer der nix weiter macht als den Quellcode auf deiner Platte zu installieren.

_________________
www.SaschaWillems.de | GitHub | Twitter | GPU Datenbanken (Vulkan, GL, GLES)

Also, wenn ich mir den Source so anschau.... leuter kleine cpp Dateien...

Da Lob' ich mir doch Delphi's SmartLinking Technologie!

Aber prinzipiell doch interresant. Vor allem find' ich schön zu sehen, dass OOP in der Spiele-Branche doch auch benutzt wird (was ich als "OOP-Fan" recht nett finde). Macht ja aber auch bei so einem Spiel wirklich Sinn!

_________________
Und was würdest Du tun, wenn Du wüsstest, dass morgen Dein letzter Tag auf dieser Erde ist?

Also ich habe mir die Quellen zwar nicht angesehen. Aber ein ernst zu nehmenden Projekt (alles was mehr als 2 Monate Entwicklung benötigt) sollte irgendwo so etwas wie ein Objektmodel besitzen. Das nicht jede Anwendung ein komplexes Model besitzten kann ist auch klar. Aber ein zu komplexes Model macht das alles auch schon wieder unübersichtlich und manchmal wirkt sich das negativ auf die Performance und Flexibilität aus. Ein Objektmodel zeugt meistens auch davon, dass die jenigen die das entwickelt haben sich denn auch mal Gedanken darüber gemacht haben.

Ich behaupte auch mal das so gut wie alle kommerziellen Spiele inzwischen OOP nutzen,da bei dieser Programmiertechnik der Nutzen weitaus höher ist als der (geringe) Geschwindigkeitsverlust den das mitsich bringt.Spätestens wenn man den Code wiederverwerten will (was bei dem CIV:CTP2-Code der Fall war) oder ihn modular gestalten will (z.B. Unreal-Engine),muss man im Endeffekt ja auf OOP umsteigen.

_________________
www.SaschaWillems.de | GitHub | Twitter | GPU Datenbanken (Vulkan, GL, GLES)

Jau, seh' cih genau so. Meine Engine (ok, Engine ist etwas übertrieben, nennen wir es FrameWork für OpenGL-Apps ) ist auch komplett OOP wegen Modularität , Flexibilität und Erweiterbarkeit. Außerdem find' ich in Objekten des ganze etwas "aufgeräumter". Und wie man bei diesen Sources sieht, bind ich /sind wir nicht die einzigsten die das so machen bzw. so denken.

Ich konnte mir nur einen kleinen Seitenhieb nicht ersparen. Es gibt ja immer noch leute, die nach dem Motto leben "Carmack programmiert auch nicht OOP, und er wird seine Gründe haben. Deswegen ist OOP für Games schlecht". Nette Einstellung. Und damit machen sich die Leute IMO das Leben selber schwer...

_________________
Und was würdest Du tun, wenn Du wüsstest, dass morgen Dein letzter Tag auf dieser Erde ist?

Wie man auf den Bildern im Doom3 Legacy Video von der QuakeCon 2002 sehen konnte ist Doom3 auch OOP.

Wobei ich schon ganz froh bin, dass OpenGL nicht objektorientiert ist (zumindest die Schnittstelle nicht, wie es intern ausschaut kann dem Anwender ja egal sein). Wäre dies der Fall, könnte es viel schwerer auf unterschiedliche Plattformen und Programmiersprachen portiert werden, da diese dann auch das zugrundeliegende Objektmodell unterstützen müssten.

OOP muss nicht langsamer sein, als die herkömmliche imperative Programmierung, schließlich kann man mit jeder Sprache die zumindest Strukturen und Funktionszeiger unterstützt sein "eigenes" Objektmodell schaffen (z.B. Assembler) - wenn man die ganzen Laufzeitüberprüfungen (Typkontrolle) weglässt, ist dies auch nicht langsamer, als wenn man auf herkömmliche Weise mit Datenstrukturen operiert.

_________________
Viel Spaß beim Programmieren,
Mars
http://www.basegraph.com/

Das OpenGL nicht OOP ist, iss ja auch ganz ok. Ich rede ja auch von den eigenen Programmen die man schreib.

_________________
Und was würdest Du tun, wenn Du wüsstest, dass morgen Dein letzter Tag auf dieser Erde ist?

Schon klar. Wollte nur anmerken, dass es auch Fälle gibt, wo OOP sogar eher hinderlich sein kann. Meistens ist es schon praktisch, die grausigen Details vor den Augen des geplagten Anwenders hinter ein paar "privates" zu verstecken .

_________________
Viel Spaß beim Programmieren,
Mars
http://www.basegraph.com/

Da stimme ich zu. OOP hat nichts damit zu tun, daß unbedingt das Schlüsselwort class oder object im Program vorkommen muß. Allerdings ist es ganz praktisch, wenn man die Daten und die Methoden zu diesen Daten zusammen hat. Man kann aber auch mehr Fehler machen und durch schlecht durchdachte Klassen oder unnütze Vererbung sich das Leben schwer machen. Außerdem ist es gar nicht nötig alles vollständig ist Klassen zu packen, wie das bei Java der Fall ist, sonder nur was auch wirklich ein Objekt ist. Manchmal kann auch ein record praktischer sein.
Wenn man irgendwie die richtige Mischung findet und eine saubere Klassenhierachie hinbekommt, dann kommen meiner Meinung nach erst die ganzen Vorteile wie Vererbung und Polymorphie von OOP voll zur Geltung. Bestes Beispiel für eine gelungene Klassensammlung ist meiner Meinung nach die VCL. Dort wird auch immer gerade das benutzt, was am sinnvollsten ist.

Das finde ich auch. Die Klassen zu durchdenken ist das A und O eines guten Klassenmodels. Es macht zum Beispiel recht wenig (überhaupt keinen) Sinn für ein Model jeden Vertex als Klasse abzulegen. Ich habe so etwas ähnliches schon einmal feststellen dürfen. Und zwar handelte es sich dabei um glscene *duck*. Aus unwissenheit (Ich war Jung, Unschuldig und brauchte das Geld) habe ich für die 3D Darstellung, in unserer Software, GLScene verwendet. Soweit ging alles ganz gut. Aber ich habe dann eine Matrix mit 256x256 TCube(s) erstellen und wieder frei geben dürfen. Na ja. Das Erstellen geht schnell. Aber aufgrund der komplexibilitär der TCube Klasse. dauert das freigeben barbarisch viel Zeit.
An solchen Stellen ist es viel Speichereffizienter und vor allem auch scneller die gesamten Daten in einem Block zu haben und dann ala VertexArray zu rendern.

Und was will ich damit jetzt sagen? So gut wie OOP auch ist. Es kann einem tierisch schnell den Hals brechen. Und zwar genau dann wenn man zu Atomar und Universell aubaut.