Performanceverlust: RPG-Maker XP

Guten Abend, ich habe heute ein kniffliges Problem.

Mein Problem dreht sich um eine eigene Implementierung einer Tilemap (weshalb ich es benötige eine eigene Tilemap zu erstellen ist eine andere Geschichte) und ich hatte bisher die Strategie verfolgt für jedes Tile mehrere Sprites zu erstellen.
Dies lief solange gut, solange die Karten relativ klein waren.
Bei 20x20 Tiles, wobei jedes Tile aus 3 separaten Sprites bestand, (macht 1200 Sprites) lief alles noch sehr flüssig, die FPS lagen bei guten 38-40.
Bei 40x40 Tiles (4800 Sprites) beliefen sich die FPS immernoch, unverändert, bei 38-40.
Hatte ich auf 60x60 erhöht (10800 Sprites) fielen die FPS jedoch einschlägig auf ein Rekordtief von 6 herab.

Ich habe mithilfe mehrerer Resourcen-Überwachungsprogramme die Werte nachgeprüft, das Spiel verbrauchte (nur) 25mb RAM und die CPU war gerade einmal bei 15-20% Auslastung.
Weitere Tests hatten jedoch ergeben, dass diese Werte für RAM und CPU-Auslastung bei 20x20 und 40x40 Tiles nicht sonderlich abwichen.

Ich frage mich also ob wirklich der Computer mit den Tilemengen überfordert war oder ob es sogar der RGSS-Player sein könnte? Kann ein hoher Performanceverlust auftreten wenn die Anzahl der Sprites die 10000 Grenze überschreitet?

Zur Information: Parallel liefen kaum Update-Methoden ab, nur eine einfach möglichkeit über die Karte zu scrollen, diese Aufgabe sollte jedoch bei steigender Kartengröße nicht mehr Performance verbrauchen also sind irgendwelche parallelen Prozesse an dem Verlust der Framerate nicht (oder wohl kaum) schuld.

Weis jemand etwas von derartigen Problemen?
Würde es helfen all diese Sprites gegen einen einzigen aus zu tauschen und ein gigantisches Bitmap anstatt zu erstellen und die entsprechenden Bildabschnitte per Blocktransfer aus den Tiles zu kopieren?

also bei mir laggt es auch, wenn ich 10.000 sprites anzeigen lasse. die grafikkarte ist bei Graphics.update einfach überlastet, weil sie zu viele sprites auf einmal rendern muss. (denke das liegt an der schlechten programmierung von seiten enterbrains. es handelt sich schließlich nur um 2d grafiken. wieso sollte die da sonst so einbrechen? >>)

wenn ich allerdings das attribut visible auf false setze springt die fps von 0 auf 30. vermutlich wird das sprite dann beim rendern übersprungen.
-> immer visible = false setzen, wenn das sprite nicht sichtbar sein kann (außerhalb des sichtbaren bereiches oder verdeckt) ;)
auch das verwenden von viewports verbessert die performance enorm, denn wenn sprites außerhalb liegen, müssen sie nicht komplett gerendert werden.
wenn das sprite komplett außerhalb des viewports liegt, sollte trotzdem visible = false verwendet werden. das ist nämlich noch immer schneller.
-> also unbedingt viewports benutzen!

das verwenden von blocktransfers anstelle von vielen sprites kann (!) eine lösung sein.
allerdings verlagerst du die rechenleistung dadurch nur von der grafikkarte zur cpu.
ein vorteil davon wäre jedoch, dass dieser transfer vermutlich nur einmal durchgeführt werden muss, während die grafikkarte bei jedem Graphic.update alles rendern muss.
also die gesammte map in ein bitmap zu kopieren wäre möglich aber würde sehr auf den arbeitsspeicher gehen.
(btw die original bitmap handelt alles in 21x16x3 = ca 1.000 sprites. wenn du die auflösung des fensters veränderst und den zur tilemap gehörigen viewport vertgrößerst, kannst du das sehr gut sehen.)

10.000 sprites sind bei weitem nicht nötig um eine tilemap zu erstellen. selbst komplexere tilemaps wie z.b mode7 oder ähnliches kommen mit unter 2000 zurecht. (zumindest benötigt mein 3d script ca 1.800 sprites)

bei diesen mengen ist jedoch nicht die anzahl der sprites das problem sondern eher, wie man mit ihnen umgeht.
in jedem update den z wert von allen sprites zu setzen ist natürlich sehr rechenlastig. man sollte diesen nur setzen wenn er wirklich verändert werden muss (z.b in dem moment, wo das sprite eine neue grafik anzeigen muss/einem neuen tile zugewiesen wird).

Du updatest über 10.000 24Bit-Sprites in einem Softwarerenderer und fragst dich warum es langsam wird?

Fang damit an nur die Tiles zu rendern, die man sieht.

Die Sprites wurden in keinem update Vorgang überhaupt verwendet und ein Viewport war natürlich auch verwendet worden.

Ich habe nun testweise einen einzigen Sprite erstellt und diesem dann ein gigantisches Bitmap zugewiesen, per Blocktransfer habe ich die gesamte Tilemap nun auf das Bitmap zeichnen lassen.
Die Performance ist stabil, selbst bei riesigen Karten. Eine spürbare Zeitspanne zum zeichnen der Karte gibt es auch nicht. Diese Lösung bietet sich also sehr gut an in dem Fall, dass die Tiles nicht animiert sind.

Es liegt also tatsächlich an der bloßen Anzahl an Sprites? Ich wusste nicht, dass Sprites derart viel Performance schlucken, bisher dachte ich immer man könnte recht großzügig mit der Verwendung umgehen. Danke für die Information.

Wieso aber ist die Performance so miserabel obwohl CPU-Auslastung und verbrauchter RAM sich in einem passablen Umfang bewegen?

Zitat:

---

Wieso aber ist die Performance so miserabel obwohl CPU-Auslastung und verbrauchter RAM sich in einem passablen Umfang bewegen?

---

Du meinst verglichen mit dem was man erwartet wenn man sich die Grafik und Performance kommerzieller Spiele ansieht?

Lies dir das hier mal durch:
http://de.wikipedia.org/wiki/Grafikpipeline

Softwarerendering wo bei jedem Update die Einzelsprites in einen Buffer gemalt werden kommt da natürlich nicht mit. Deine Hardware wird nicht ausgelastet, weil sie nicht entsprechend benutzt wird, ist ein völlig normaler Effekt, du kannst die dicksten Wievielkernrechner durch ein "paar" Sprites zum einbrechen bringen. Die Grafikausgabe von Java ist so ein Fall. Praktisch zu verwenden, schaut ganz passabel aus, aber sobald 24Bit Grafiken mit Alphamap animiert werden sollen ist Ende.

Es gibt fürn XP wenn ich mich recht erinnere ein paar Scripte, die an der Performance rumschrauben, solltest mal danach suchen.

Vielen Dank für die Informationen, gibt es einen Tipp den du zu meiner derzeitigen Methode abgeben könntest? Bisher versuche ich nun die gesamte Karte auf einen einzelsprite zu reduzieren.
Das Bitmap des Sprites wird beim laden der Karte per Blocktransfer aus dem Tileset gezeichnet. Das Scrolling wird über den Viewport handgehabt; sollte ich es besser mit der src_rect des Sprites machen?

Soweit reicht mein Fachwissen in Sachen RMXP leider nicht, sry.

Ich finde src_rect sauberer, aber obs eine Verbesserung der Performance bringt kann ich nicht sagen. Für die Performance ist auch die Größe entscheidend. Viele kleine Sprites lassen sich performanter rendern als ein großes. Nichtsdestotrotz sind 10k Sprites ganz schön viel. Bei mir kommt der Maker schon bei wenigen hundert Sprites ins Schwitzen ^^°
Wenn du so viele Sonderwünsche (eigene Grafikklassen, bessere Performance, Netzwerkzugriff...) hast, solltest du dir evtl. überlegen die Engine zu wechseln. Es gibt für Ruby noch andere Engines für 2D-Spieleentwicklung die mit hardwarebeschleunigung arbeiten und so auch wesentlich bessere Performance erzielen, beispielsweise Gosu. Die rxdata Dateien des Makers könntest du ja weiterhin nutzen, du müsstest nur die Grafikklassen und Datenstrukturen (Rect, Color, etc.), die die RGSS verwendet, nochmal neu schreiben.

Ich weis, es wäre wahrscheinlich das allerbeste auf eine andere Plattform zu wechseln. Aber ich habe derzeit eine keine Zeit mich in alles hinein zu lesen. Etwas zu suchen was mir gefällt, zu lernen was ich brauche und was ich vielleicht ändern sollte. Definitiv nicht in den nächsten Monaten.

Netzwerkzugriff habe ich allerdings derzeit noch nur bedingt mit dem RMXP, die Scripte welche ich bisher in diesem Gebiet versucht habe sind noch ein bisschen dürftig, da ich damit keinerlei Erfahrung habe.

Was du zu den Sprites sagst, sollte ich die Karte dann doch eher in (wenige) Teile teilen? Zum Beispiel 9 Sprites welche den entsprechenden Abschnitt als Bitmap speichern?