Hallo,

in eurer FAQ schreibt ihr, dass ihr aus Bequemlichkeitsgründen die Landschaft mit OpenGL "live" rendert.
Ein kurzer Blick in den Quellcode offenbahrt, dass ihr tatsächlich den kompletten sichtbaren Ausschnitt mit OpenGL rendert. Ich möchte folgenden Vorschlag machen, der die Performance verbessern kann, und wahrscheinlich relativ leicht umzusetzen ist:

1. Die komplette Karte einmal in ein Puffer rendern, z.B. mit OpenGL und der Erweiterung Framebuffer Object. (Für Anwender ohne Grafiktreiber mit der Erweiterung gibt es sicher Alternativen, z.B. libmesa)
Dieses riesige Bild würde ich dann in kleine (z.B. dreieckige oder quadratische) Ausschnitte einteilen.

2. Wenn ich es richtig sehe, ist außer der Landschaft und den Straßen alles in Wirklichkeit zweidimensional. Also genügt es, falls die Landschaft durch einen Planierer oder durch Straßenbau verändert wird, den kleinen Ausschnitt, der die Änderung enthält, einmal neu zu rendern und den Pufferspeicher an der entsprechenden Stelle zu überschreiben. Man muss nicht den gesamten sichtbaren Bereich neu rendern.

3. Die restlichen Objekte können zweidimensional einfach an die richtige Stelle "kopiert" werden. Unbewegliche Objekte könnten sogar in o.g. Pufferspeicher geschrieben werden.

---

Ich sehe da 3 Probleme:

1. Grafik im Grafikspeicher:
Das ganze hätte aber auch Nachteile und zwar das das ganze Bild im Grafikspeicher rumliegen muss und das sind bei großen Karten (256x256) ~100MB. Das heißt eine Grafikkarte mit 64MB Speicher kann man dann garnicht mehr verwenden und die zusätzlich benötigten Texturen brauchen auch noch mal was, da könnte es selbst für Grafikkarten mit 128MB Speicher noch knapp werden.

2. Bild im Ram
Lagert man das Bild im Ram aus ist die Zugriffsgeschwindigkeit deutlich niedriger und es werden statt derzeit ca 150 MB Ram 250 MB Benutzt.

3. Das Bild muss immernoch Berechnett werden
also verwendet man weiterhin OpenGl was insgesamt gein großen Performance gewinn bringt

Fazit:
Da die Rechenleistung selbst bei einfachen Grafikkarten eigentlich ausreicht und bei dieser Variante andere Probleme auftreten die auch gelößt werden müssen, halte ich das für keine gute Lösung.

Ps:
mein AMILO Pi 1536 (1,6 GHz DualCore, ATI X1400) schafft locker 130 Bilder/Sec

---

Dass die Größe der Datei für kleinere Rechner ein Problem sein könnte, sehe ich ein.

Dass die Rechenleistung selbst bei einfachen Grafikkarten ausreicht, kann ich aber nicht bestätigen. Auf meinem Netbook läuft es kaum und ich erreiche hier mit 2 x 3,0 Ghz u. einer ATI Radeon 4850 mit 512 MB bei 1680x1050 magere 60-70 fps bei einer großen Karte. Wenn man überlegt, dass das originale Siedler II mit derselben Funktionalität auf einem 486 DX mit 66 MHz flüssig läuft, sehe ich hier Handlungsbedarf, aber natürlich nicht mit höchster Priorität.

Um die Größe der Datei zu reduzieren, könnte man einmal nur den aktuellen Bildausschnitt in den Speicher rendern lassen und das Terrain des Ausschnitts etc. im Speicher belassen, bis weiter gescrollt wird, statt es bei jedem Frame neu zu berechnen. Die ganze Karte zu berechnen ist wahrscheinlich kein guter Kompromiss zwischen Rechenzeit und Speicherbedarf.

Natürlich muss das Bild berechnet werden. Die Frage ist nur, ob man das 130 mal pro Sekunde machen will oder eben möglichst selten.

---

Hallo,
wenn du Ahnung und Lust hast, bist du herzlich eingeladen mitzuhelfen :)

Ansonsten werkelt fbd gerade ein bisschen an der Optimierung, vielleicht kannst du dich mit dem mal kurzschließen (Er ist öfter im IRC-Channel #siedler2.5 auf irc.freenode.net anzutreffen oder auch über "Chat" oben auf der Seite).

Grüße,
jh

---

Ich hatte schon ein zwei Mal einen Grafik-Rewrite vorgeschlagen. Dabei ist das Rendern der Map gar nicht das Problem, sondern das viele Umschalten zwischen den Textures, die nacheinander gezeichnet werden. Ich selbst hab einen Laptop mit Intel GMA "Grafikkarte" und bekomme erst Probleme, wenn im fortgeschrittenen Spiel viele Häuser und Leute gezeichnet werden. Mit 15fps macht das Spielen da keinen Spaß mehr; eine unbebaute Karte kann ich aber auch mit 1920x1280 Pixeln anschauen. Zumal das Spiel auf Rechnern von vor 10 (!) Jahren flüssig lief!

Mein Vorschlag wäre, die Grafik in reinem SDL nochmal neu zu verfassen. Ich kenne mich nicht aus, aber vermute mal, dass das Binden von Textures in OpenGL ist deswegen so aufwändig ist, weil man sie auf Polygone im dreidimensionalen Raum projezieren kann. Dann muss letzterer noch gerendert werden. Das ist natürlich für alle 2D völliger Overkill, wir brauchen ja nicht einmal irgendwas vergrößern/verkleinern, sondern nur 1:1 die Pixel zeichnen.
Natürlich müsste dann jemand für die Landschaft einen Software-Renderer schreiben. Davon hab ich zwar auch keine Ahnung, aber ich kann als Physik-Student mit Vektoren rechnen und könnte mich einlesen, falls sonst keiner Lust hat ;) .

SDL kann nur noch blitten, aber mehr brauchen wir ja nicht. Außerdem unterstützt es nativ offscreen-Surfaces, auch hardwarebeschleunigt. Man könnte also unabhängig von der Grafikkarte mehrere Layer haben für mehr oder weniger statischen Inhalt.

Ein anderer Punkt ist, im GUI möglichst nur noch zu zeichnen, was sich verändert. Habt ihr schon mal die FPS beobachtet, wenn man im Spiel ein paar Fenster öffnet? Mit OpenGL kann man ohne Framebuffer-Extension Statisches nirgendwo zwischenspeichern. Mit SDL könnte man z.B. für jedes Fenster ein Hardware-Surface erstellen, in das nach dem ersten Zeichnen nur noch die Änderungen kommen. Das lässt sich dann ohne CPU und mit Warteschlange (SDL_ASYNCBLIT) auf den Bildschirm bringen, während man weiterrechnet.

Falls jemand der Meinung ist, SDL sei zu langsam, dann frage ich mich warum OpenTTD bei mir flüssig läuft.

Eine native-SDL-Grafik ließe sich zunächst auch parallel zur OpenGL-Grafik entwickeln, ohne off-display-Surface/Framebuffer - Unterstützung. Ich selbst hätte Spaß daran.

Falls ich Unsinn geschrieben habe, widerlegt mich bitte :) . Mein Wissen ist auch nur mit Google zusammengesucht.

Gruß,
Divan

---

Hallo
SDL 1.2 macht unter Linux auch alle Blits per Software, nutzt also gar keine Hardware-Beschleunigung (Selbst wenn man SDL_HWSURFACE angibt). Unter Windows verwendet es glaube ich DirectDraw, was aber unter (halbwegs) neueren Windows-Versionen (und Hardware) auch wesentlich langsamer ist, als Direct3D oder OpenGL zu verwenden.
Ab SDL 1.3 wird deshalb zum Blitten auf OpenGL aufgesetzt. Von daher sollte sich nicht viel an der Performance ändern, wenn man von OpenGL auf SDL (1.3) umsteigt.

Ich glaube, dass es mehr Sinn macht, ein Profiling durchzuführen um genau rauszukriegen, was für die niedrige FPS-Rate auf älteren Rechnern sorgt. Das dürfte weniger Aufwand kosten und wesentlich mehr bringen, als alles komplett umzukrempeln.

Ich kenne den Quellcode von Siedler 2.5 nicht aber ich denke es sollte für eine Grafikkarte (weniger als 10 Jahre alt) kein Problem sein 500 Objekte pro Frame zu zeichnen. Teurer dürfte in der Tat nur das Kopieren von Texturen vom RAM in den Grafikspeicher sein. Da kann man also vielleicht viel sparen, falls das z.B. bei der GUI noch gemacht wird.

Andererseits löst sich das Problem von selbst, da die Grafikhardware immer schneller wird (auch in Netbooks und Handys). Erstmal sollte das Spiel von der Funktionalität her fertig werden und dann kann man sich um Optimierungen für Geräte mit wenig Leistung kümmern.

Alles nur meine persönliche Meinung. Letztendlich ist das Spiel Open-Source und von daher hängt es nur von den Entwicklern selbst ab, für was sie Zeit investieren woilen. Derjenige der Zeit investiert, entscheidet was gemacht wird.
Ich beobachte das Projekt schon länger und freue mich über die Fortschritte die es gemacht hat (und das es nun Open Source ist). Großen Dank an die Entwickler.

---

Zitat:

richtig. das ist auch das hauptproblem momentan, daran arbeitet fbd ja im moment z.b

Erstens diverse Texturen zu einer zusammenzufassen (dann entfällt schon mal öfter das wechseln), auch wenn wegen texturgrößenbegrenzungen natürlich nicht einfach alles in eine textur "geklatscht" werden kann.

Weiterhin müsste die Reihenfolge des Zeichnens sohingehend verändert werden, das auch die verbleibenden (unnötigen) texturwechsel entfallen, bzw das OpenGL die Texturen auch wirklich in den Grafikram läd und nicht im Systemram behält und nur auf "Anfrage" diese auf die Grafikkarte speichert. Da besteht eben noch einiges an Optimierungsbedarf und dies darf jeder gerne beisteuern (gut gemachte Patches sind da gerne willkommen)

---
mfg
Flo

---

Das Profiling gestaltet sich leider nicht so einfach. Das Problem ist nämlich, dass die meiste Rechenzeit im Grafikkartentreiber verloren geht - und mit einem normalen Profiler wie AMD CodeAnalyst kann man da nicht "reinschaun". Es gibt allerdings auch Profiler von nvidia und ati speziell für Grafikkarten und einen (nicht kostenfreien) Opengl Profiler. Der Profiler von nvidia läuft bei mir unter Win7 leider nicht - deswegen konnte ich mir das noch nicht genau anschaun.

Soweit ich es bisjetzt überblicken kann würde eine konsequente Optimierung der Performance vom Umfang her aber wohl einen Versionssprung rechtfertigen. Man müsste Objekte in texturspezifische Klassen packen (bzw. erstmal eine Menge einzelner Animationstexturen in einer Textur zusammenfassen) und den z-buffer wieder einführen. Bei der ganzen Geschichte wäre eine klare Trennung zwischen Grafikengine und den anderen Berechnungen nötig - und das ist etwas was ich im Moment einfach nicht erkennen kann. Das Spiel ist aktuell darauf angewiesen dass alles in einer bestimmten Reihenfolge gezeichnet wird,was Optimierungen außerordentlich schwierig macht und das hat meist nur unnötig komplizierte (von der Überschaubarkeit her - nicht unbedingt was die Rechnenzeit angeht) Lösungen zur Folge.

Den Weg von Opengl weg zu evtl. reinen 2Dlibs halte ich übrigens für den falschen Weg. Opengl beschleunigt wenn man es richtig angeht auch reine 2D Anwendungen.

Die Arbeit sich in den Quellcode einzulesen, dann nur halbherzige Lösungen programmieren zu können (wo man selbst weiß dass sie nicht optimal sind aber es einfach nicht anders geht ohne das halbe Spiel umzukrempeln) nur damit das dann (berechtigterweise) eh nicht umgesetzt wird ist btw ziemlich demotivierend. Das ist auch der Grund weshalb ich die letzten 1,5 Wochen keine große Lust mehr hatte was zu machen.

Insofern müssten sich Flosoft und Oli irgendwann mal hinsetzen und die Optimierungen vielleicht für den Versionssprung von 0.7 auf 0.8 planen. Dass bis dahin natürlich wieder schnellere Rechner auf dem Markt sind ist klar und ob die Performance dann noch n echtes Problem ist fraglich .. Mal abgesehen davon dass jeder auch noch n Leben neben S25 hat auf das er Rücksicht nehmen muss ..

---