hallo Leute! Ich progge grad an nem Shoot em Up und habs jetzt geschafft schon einige Funktionen in meine C++ / SDL / OpenGL Engine einzubauen. Nun bin ich seit kurzem dabei nen Level-Loader hinzuzufügen inkl. Darstellung (scrollender Hintergrund). Bisher war ich mit der Geschw. ja ganz zufrieden , hatte für mein Menü ca. 400 windowed und im Fullscreen 450 FPS. Mein ganzes Game hat 800x600 als Auflösung. Jetzt hab ich aber eben das Level zuig hinzugefügt und sobald das alles gezeichnet wird sinkt die FPS auf 80 - 100 obwohl alles in einer OpenGL-List gezeichnet wird, sind diese Werte normal?

Das Level wird nur gezeichnet, wenn es innerhalb der Window-Koordinaten ist und setzt sich aus 32x32 BMP's zusammen.

---
Mir ist grad aufgefallen, dass ich GL_LINEAR aktiviert hatte, habs auf GL_NEAREST umgeschrieben. Komm jetzt also auf ca. 140 - 160 FPS, das gefällt mir schon viel besser. Würd grad gern nochmal hören, dass das ein akzeptabler Wert ist. Smile

Etwas von deinem Code zu sehen wäre nicht schlecht, man könnte möglicherweise etwas genauer dazu sagen .

_________________
"Meine Mutter sagt : 'Dumm ist der, der Dummes tut'." - Forrest Gump

Ist schon recht komplex und lang, ich wollt nur mal wissen ob das halbwegs normale Werte sind, hatte nämlich schon mehr FPS erwartet.

Hier die Passage zum Level zeichnen (werde while noch in for umwandeln):


Und hier meine GL_List (für den Test hab ich jetzt nur die eine Textur)


DrawMap wird so oft aufgerufen wie möglich, UpdateMap wo dann alles um 1 pixel nach links verschoben wird max. 60 mal / s (auch hier wird die while durch for ersetzt werden)



Das wären ein paar Auszüge

Mir ist grad aufgefallen, dass ich GL_LINEAR aktiviert hatte, habs auf GL_NEAREST umgeschrieben. Komm jetzt also auf ca. 140 - 160 FPS, das gefällt mir schon viel besser. Würd grad gern nochmal hören, dass das ein akzeptabler Wert ist.

Alles was über 30 Frames ist gilt als flüssig. Wenn du mehr als 60 hast wird keiner einen Unterschied zu 300 Frames feststellen können.

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

Du verwendest hier sehr häufig LoadIdentity, in der DisplayList am Ende und in der Routine zum zeichnen vor dem Aufruf der DisplayList, eines von beiden ist überflüssig. Das dürfte zwar kaum was ausmachen.

Du bindest in der DisplayListe ständig eine Textur. Es ist besser, vor dem Zeichen nach den Texturen zu sortieren und dann entsprechend vor der ersten Verwendung einer neuen Texture zu binden und dann die DisplayListen aufzurufen. Du könntest in Level[i][j] zusätzlich die Textur speichern, in einer ersten Schleife alle zu zeichnenden Tiles bestimmen, diese in einem zweiten Array speichern und dieses Array nach den Texturen sortieren. Damit würdest Du nur noch eine einzige DisplayList brauchen und nicht für jede Textur eine.

Gruß
Thomas

_________________
http://www.seban.de

Danke, das dürfte was bringen!

Das ist sowieso ein Fehler. In einer DL kann man lediglich nur die Texturkoordinaten speichern.

_________________
"Meine Mutter sagt : 'Dumm ist der, der Dummes tut'." - Forrest Gump

Sicher sniper? Wäre mir neu, dass man in einer Displaylist keine Texturen binden dürfte. Bei VBOs stimmt's. Mag sein, dass das bei Displaylists auch so ist, aber ich wäre überrascht, sollte es so sein

_________________
"Für kein Tier wird so viel gearbeitet wie für die Katz'."

Also funktionieren tut es auch in ner Display List ob man es "darf" ist ne andere Frage

No Texturen sind OK. Siehe glNewList

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

Mir ist grad aufgefallen, dass du wohl anscheinend kein Timebased Movement verwendest. Solltest du schleunigst nachholen

_________________
"Für kein Tier wird so viel gearbeitet wie für die Katz'."

Jop, hab bisher in Updates / Sekunde (~60) und die Zeichenroutinen unterteilt. d.h. Update nur zu gefixten Zeiten und Zeichnen sooft wie möglich, funtzt allerdings noch nicht ganz perfekt. Werd mir mal den Artikel durchlesen und ausprobieren was besser funtzt!

Das kann ich dir jetzt schon sagen Timebased Movement ist immer vorzuziehen, wenn es nicht um Energieschonende Anwendungen geht. Solltest du planen, das Ganze auf einem Notebook einzusetzen, ist einem reinen Timebased Movement ein Timebased Movement kombiniert mit sleep vorzuziehen Dein Akku wird es dir danken

Aber ansonsten ganz klar: Timebased Movement.

Ok, es gibt noch eine weitere Ausnahme. In dem Fall, dass deine Anwendung so konzipiert ist, dass sie neben anderen OpenGL-Progs laufen soll, wäre es evtl. besser, auf eine OnPaint-Methode zurückzugreifen. Dass du also nur dann zeichnest, wenn es sein muss. Das ist die Akkuschonendste und netteste Variante. Nett hier im Sinne von Ressourcenschonend, so dass für andere Anwendungen noch Zeit übrig bleibt.

_________________
"Für kein Tier wird so viel gearbeitet wie für die Katz'."

Also bin jetzt beim implementieren, soweit ich das jetzt verstanden habe geht das so (die Kommentare im Wiki sind nicht ganz verständlich an welcher Position der Code in nem App hingehört, deswegen hab ich mich eher der Theorie (im Bomberman Tut) als dem Code gewidmet):

1. Zeit vor Rendern nehmen
2. Zeit nach Rendern nehmen
3. Daraus Zeitfaktor berechnen
und mit diesem alle Bewegungen multiplizieren

(Game-Schleife) {

Swap Buffers }
und wieder loopen

Wäre das jetzt korrekt (hab derzeit keine anderen Rechner zum testen)?

EDIT: Hab das prob dass bei Frameraten über 200 bei Zeitfaktor 0 herauskommt und alles stehenbleibt ..