JLI Spieleprogrammierung

[Zyrian]

Hi zusammen

ich habe in meinem Game eine Framerate von ca 29 fps ohne Framebremse. Lediglich auf einem Aldi-Rechner können Framerates von ~70fps erreicht werden.
Folglich kann man sagen, ich hab bei der Performance ziemlich ins Klo gegriffen ^^

Ich vermute einfach mal, dass es an den Vektoren liegt, die bei jeder Bewegung durchlaufen werden, und so ca. 800 einzelne Tiles + zusätzliche Sprites um die jeweilige Koordinatenänderung in andere Richtungen bewegen.

Mit Tiles hab ich mich diesmal das erste Mal auseinandergesetzt. Aus einer Datei lade ich das Aussehen der Landschaft und setze es in Sprites um.
Das sieht momentan so aus:

[Beni5]

Also bei mir geht das toll. Ich habe auch Tiles, und momentan 2 Layer aus sprites und surfaces. Bist du sicher das du die files nur 1 mal lädst? Das war bei mir auch mal der Fehler.

[Christian Rousselle]

Das ist alles etwas schwer zu sagen, ohne den kompletten Code zu kennen. Beschreib doch erstmal, was dein Programm machen soll, dann kann man auch besser sagen, ob das mit mehr als 29 FPS geht. Ansonsten, wie Beni5 schon sagt:

1. Sicherstellen, dass alles nur 1x geladen wird, nicht in jedem Frame.
2. vecSurfacesToDraw.push_back(SurfaceToDraw); sieht so aus, als wenn du das Object und nicht nur einen Zeiger/Adresse in den Vektor kopierst, kann man aber ohne die Definition von vecSurfacesToDraw zu sehen auch nicht sagen.
3. Was ist der Unterschied zwischen AddTexture und SetTexture, versteht man nicht.

Christian

[Zyrian]

Also, geladen wird alles nur 1mal, so wie ich das hier sehen kann. Dafür hab ich ja 2 Funktionen, wobei die eine die "Bodensprites" ausliest und die andre die anderen, zu interagierenden Sprites. Diese Funktionen werden in der WinMain Methode aufgerufen, und zwar vor der Nachrichtenschleife.

Dies hier ist meine Renderroutine:

[xardias]

Also generell kann man so noch optimieren:
Nach Texturen sortieren. d.h. alle Stein texturen zeichnen, dann alle holz usw. also so, dass man nur selten die textur wechseln muss, das verbraucht nämlich gut performance.
Ansonsten, speicher Sparen (4 statt 16 statt 32).

Wenns imemr noch langsam ist, würde ich mich mal nach nem profiler umschaun um den flaschenhals in deinem Spiel zu finden.

Happy Codin'
Xardias

[Zyrian]

Hm, wie kann ich denn nach Texturen sortieren? Gibts dafür einen Algorithmus?

[Christian Rousselle]

[Zyrian]

Jo klasse! Danke dafür! (:
Hab jetzt ~60 FPS, is zwar net viel, aber auch n guter Wert für ne Framebremse.

Thx 4 help!

MFG
#C
_________________
Schau mir in die Augen, Kleines.

[xardias]

Zum texturen sortieren gibt es leider keinen festen algoritmus.
Es komtm halt drauf an, wie du deine objekte verwaltest.

du verwendest ja für deine objekte den std::vector soweit ich mit bekommen habe. Dann könntest du zum Beispiel nen Functor benutzen um deine objekte zu sortieren. oder du machst das gleich per hand, es gibt ja eine menge sortier algoritmen. du musst nur deinen vector durchgehen und den so anordnen, dass die sprites mit den gleichen texturen direkt hintereinander liegen.

Das mti den Texturen mein ich ganz einfach nur so, dass du zum Beipsiel für s/w Bilder keine 32 Bit textur nehmen soltest. da reichen auch 4 bit (weiß nur nicht, welche parameter DX dafür braucht). Und für Bilder, die kein Alpha channel brauchen reicht meist auch 16 bit.

[Hazel]

Wenn du einen Vector benutzt, würd ich das mit dem sortieren sein lassen, weil es dort sehr zeitaufwendig ist. Da Spielobjekte sowieso andauernd kommen und gehen würde ich dir empfehlen auf std::list umzusteigen.
_________________
*click* Dabuu!?
Twitter: http://twitter.com/Ollie_R

[Christian Rousselle]

Wobei ich nicht sehe, was dass für ein Nachteil haben soll, da ja nur Zeiger in dem vector sind.

Bei der Sortierung der Texturen bin ich mir auch nicht sicher....ich habe da noch nie einen Performance Vergleich geshen, noch habe ich das selbst gesehen, aber schon 1000x gehört. Was Sinn machen wird, ist die Texturen zu sortieren, damit sie nicht aus dem Videospeicher rausfliegen, wenn sie einmal drin sind und immer wieder geladen/rausgeschmissen werden usw. aber wenn man sowieso weniger braucht, als die Grafikkarte RAM hat, sehe ich den immer erwähnten Performancevorteil nicht. Die paar SetTexture-Calls können es jawohl nicht ausmachen und sind am Ende normalerweise schneller als das Sortieren. Kann mich jemand aufklären?

C.

[Hazel]

Stimmt mein Fehler... hab nicht dran gedacht dass es nur Zeiger sind. :)
_________________
*click* Dabuu!?
Twitter: http://twitter.com/Ollie_R

[Zyrian]

na gut, dann würde das mit dem sortieren schon mal rausfallen.

hab grad bemerkt, dass ich leider nur auf gute fps komme, wenn meine einzelnen tiles nicht kleiner als 128x128 sind. eigentlich schade, aber was kann man schon von einem duron 1200 erwarten ... ?

noch mal zum sortieren. die sprites müssten ja eigentlich sowieso sortiert werden, und zwar danach, wo sie gezeichnet werden sollen. soll heissen, die sprites ganz oben müssten als erstes gezeichnet werden, dann die nächsten usw.
welchen suchalgorithmus sollte ich dazu am besten verwenden? im c++ primer sind eine ganze reihe aufgelistet, aber nur der sort algorithmus ist erklärt. die restlichen erläuterungen finde ich nicht, oder sie sind nicht vorhanden.

MFG
#C
_________________
Schau mir in die Augen, Kleines.

[Zyrian]

Mal so eine generelle Frage:

Ist es performancemäßig besser, wenn man mit wenigen großen, oder mit vielen kleinen Texturen arbeitet?

MFG
Chris
_________________
Schau mir in die Augen, Kleines.

[Sören]

Stellst du denn sicher dass du auch nur die Tiles renderst die auch auf dem Bildschirm zu sehen sind? Wenn von 800 Tiles nur 40 pro Frame zusehen sind, aber 800 gerendert werden isses klar dass da was abgebremst wird.

(Hab jetzt nicht den ganzen Thread komplett gelesen, also sry wenn ich was übersehen hab...)