Da mein Spiel ein Adventure wird, ist meine 'Zielgruppe' meistens nicht so gut bestückt wie die 3D-Shooter-Fraktion. Insofern kann ich nicht unbedingt mit einer GeForce- oder Radeon-Karte planen. Da ich mich bei schwächeren System auch mit 16bit zufrieden gebe, habe ich wieder Hoffnung. Unter Umständen muss ich eben wirklich eine Hardware-Anforderung aussprechen, ein 10fps-Spiel kommt nicht in Frage.

Ich habe jetzt auch ein paar Tests auf dem 800Mhz/Geforce256-System gemacht:
(VSync abgestellt)

Renderpass.exe:
32bit: ~125fps
16bit: ~250fps

GLTestApp.exe:
32bit: ~45fps
16bit: KEINE ANZEIGE, sehr ruckelig.
Hier das Log:


Mit diesen Framezahlen bin ich durchaus zufrieden. Kann man denn im Code das VSync ein/ausschalten?

So, ich werde also mal versuchen ein paar Stunden lang irgendein Template dahingehend zu verändern, dass es meiner Vorstellung entspricht. Irgendeine Empfehlung für eine 2D-Basis?

Vielen Dank schonmal im voraus!

für ein 2D-Spiel solltest du dir den Ortho-Modus (glOrtho)
mal genauer ansehen...

VSync kann man zwar per Software ausschalten, wobei es aber de facto nichts bringt, wenn man mehr FPS hat, als der Monitor anzeigen kann, weil man ja eigentlich doch nur die Monitor-Herzzahl Frames pro Sekunde sieht

(den Code dazu gabs irgendwann mal auf der PAge (DelphiGl.com), ich kann ihn aber leider grad nicht finden...

_________________
. . .

VSync ausschalten bringt unter Umständen schon etwas. Ich hatte bei einer Tutorialanwendung nach Ausschalten einen Sprung von 30 auf 60fps. Und das ist schon ein Unterschied. 30fps ist genau an der Schmerzgrenze. Wahrscheinlich lässt sich dieses Phänomen durch geschickteres Programmieren umgehen, oder doch nicht?

was hast du denn für einen Monitor??
wenn der bei dir bei eingeschaltetem VSync nur 30 FPS hat, dann ist entweder der Treiber kaputt, der Bildschirm gibt eine falsche HErzzahl zurück oder dein Bildschirm läuft wirklich unter 30Hz...
in diesem Fall, hat es aber wie eben schon beschrieben keinen Sinn das Programm unter 60FPS laufen zu lassen, weil es für den BEnutzer visuell NULL Unterschied ist, ob das Programm mit der Anzahl der Hz-Anzahl des Monitors läuft oder mit mehr FPS...
das Bildschirmergebnis wird eher noch schlechter.... :-/

_________________
. . .

Mit der Extension WGL_EXT_swap_control kannst du das einstellen. Aber ob es übernommen wird hängt vom Treiber ab. Wenn du dort eingestellt hast "Immer an" (oder aus) dann wird die Extension da auch nichts dran ändern.

Und zum Thema VSync. Es ist eine reine Geschmackssache. Wenn du es an hast dann werden die bilder nur dann gezeichnet wenn der Monitor gerade nicht zeichnet. Wenn du es ausmachst kann es sein, dass der Monitor das Bild zeichnet und mittendrin ihm das Bild ausgetauscht wird. Du hättest sozusagen 2 unterschiedliche Bilder zur Hälfte auf dem Monitor gezeichnet. Aber da das menschliche Auge eh ein wenig langsam ist fällt es nicht so stark auf. Unter idealen Bedingungen kann es aber schon auffalen. Das passiert aber eher selten.
Es hat beides Vor und Nachteile. Und im Endeffekt wählt der Benutzer schon die für ihn gewollte Einstellung. Oder der Treiber.

Zu deinen 30 FPS mit vysnc. Da wirst du beim Zeichnen ein ganz wenig über dem Sync gelegen haben. Und 30 sind nicht so schlecht. Ein Trickfilm hat nur 24 und er läuft flüssig.
Nebenbei kannst du bei den 30 fast das doppelte an Dingen rendern ohne das sich die FPS großartig verändern würde (theoretisch jedenfalls). Er hat ja momentan recht viel Zeit mit dem Warten verbracht und die würdest du so dann zum Rendern benutzen.

Fiji: Flachbildschirme laufen in der Regel nur mit 60 Hz. Die Flackern aber auch nicht.

Ja, stimmt normale Filme laufen mit 24/25fps. Und allgemein wird das als flüssig bezeichnet. Ich glaube aber, dass jeder hier eine höhere Framezahl als angenehmer bezeichnet. Ich wage zu behaupten, dass man optisch druchaus erkennen kann, ob 30,40 oder 50fps dargestellt werden. (Das wäre doch mal eine geile Idee für 'Wetten dass...' 8) )

Ich arbeite nur noch mit TFTs, die haben alle 60Hz.

Wahrscheinlich hast du auf der Geforce 256 im 16 Bit Modus kein passendes Pixelformat mit Stencilbuffer (wegen dem Schatten benötigt). Ab Geforce sind 32 Bit Modi ohnehin schneller.

Immerhin hast du in beiden Fällen (Vanta und Geforce 256) hardwarebeschleunigte Videomodi, wobei dein Treiber für Geforce 256 relativ alt ist, da sämtliche NVidia Treiber (ab TNT) schon relativ lange OpenGL 1.4 unterstützen.

Für deine Zwecke ist OpenGL bereits so wie es jetzt ist locker schnell genug: in GLTest werden die 3D Objekte in jedem Frame neu berechnet und in Bildschirm, Z-Buffer und Stencilbuffer gezeichnet.
Für deine Anwendung langen ein paar texturierte Quads mit Alphakanal aus (für die Sprites), den Hintergrund kannst du entweder als Textur realisieren oder mittels DrawPixels direkt zur Grafikkarte schaufeln. Du brauchst an sich weder Beleuchtung und Nebel.
Ich glaube dir versprechen zu können, dass das sogar auf einer normalen TNT in 800x600 mit weit über hundert FpS laufen wird - selbst wenn du größere Wasserflächen oder so animieren möchtest, wenn du nicht exzessiv Texturen schiebst, was jedoch, so wie es zur Zeit aussieht, leicht vermieden werden kann (du kannst z.B. alle für eine Szene benötigten Sprites und Animationssequenzen im Voraus als Texturobjekte definieren, dann kannst du damit sehr schnell arbeiten - du brauchst auch nicht mehrere skalierte Versionen eines Sprites, da du z.B. texturierte Quads in jeder beliebigen Größe zeichnen kannst).

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

Ja, bis jetzt sind erste Tests recht erfolgreich. Ich habe jetzt aber noch keine Ahnung wie ich die Vielzahl von Sprites/Animationen speichermässig verwalten soll. Zahlreiche Animationen (Laufen/Sprechen) brauche ich ständig und andere werden dynamisch dazu geladen. Ok, bei den Laufanimationen kann ich über Textur-Offsets gehen. Wie sieht's mit der Konvertierung System <-> Grafikkarte aus? Kümmert sich OpenGL darum, dass die gerade benötigten Texturen in den Grafikspeicher kommen, oder wie? Ich brauche schon einige MBs für die Animationen...

Der OpenGL Treiber verwaltet die Texturen automatisch. Wenn man mehr Texturen benutzt, als in den Grafikkartenspeicher passen, werden sie ausgelagert. Das Programm wird natürlich dadurch dann langsamer, aber mit 128 MB Standard braucht man sich da eigentlich keine Sorgen machen.
Wenn du allerdings ungefähr weißt, welche Texturen benötigt werden, dann ist es besser nicht immer alle zu laden, sondern da schon vorher eine Auswahl zu treffen.
Falls der Speicher insgesammt nicht ausreichen sollte:
Die Aktualisierung von Texturen über gltex[sub]image ist je nach Texture Größe von der Geschwindigkeit her noch akzeptabel. Demnächst gibt es noch eine neue Extension (arb_pbo) mit der man einen besseren Zugriff auf die Texturedaten hat und sogar Videos streamen kann.

Gut, gut, gut. OpenGL beginnt mir zu gefallen. Grosse Texturen sind auch kein Problem, aber müssen die Dinger wirklich 2^n und quadratisch sein? Wenn ich auf OpenGL umsteige, muss ich jetzt alle Grafik-Resourcen entsprechend anpassen? Was mache ich denn bei Grafiken mit den Ausmassen 1500*13? Für Animationen sind solche Dinger ganz praktisch. TexSubImages helfen mir glaub ich wenig weiter, denn ich brauch noch AlphaChannelMaps und das geht damit nicht (oder doch)?

(Sorry, wenn dieses Problem irgendwo schon breitgetreten wurde. Ich hab's nicht gefunden.)

TexSubImages unterstützen Alpha Channel

Es zwingt dich ohnehin niemand, gar alles mit Texturen zu realisieren (die übrigens nur Zweierpotenzen als Begrenzungen haben müssen, quadratisch müssen sie normalerweise nicht sein). Schau die doch mal die Dokumentation zu glDrawPixels und glCopyPixels an - für 2D Operationen können die auch praktisch sein.

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

ok, schau ich mal. Aber auf Pixel-Ebene wollte ich eigentlich nicht runter, kommt natürlich drauf an, ob ich AlphaChannels und eine vernünftige Geschwindigkeit dann noch habe. Mal sehen... thanks

Also eigentlich kann die die 2^n-Begrenzung recht egal sein, denn gluBuildMipMaps ver- bzw. entzerrt beim erstellen der MipMaps deine Texturen so, das sie genau in diese Begrenzungen passen. Wenn du diese Methode zur Übergabe deiner Texturdaten an OpenGL nutzt, dann können deine Texturen eigentlich jede von dir gewünschte Größe besitzen. Allerdings ists halt fraglich ob man für ein pures 2D-Spiel auch wirklich MipMaps braucht, da deine Objekte ja eigentlich immer auf der gleichen "Tiefe" liegen und so immernur eine MipMap-Stufe genutzt wird. Somit belagern die nichtgenutzten MipMap-Stufen also nur zusätzlichen Speicher im VRAM, aber wie gesagt hast du dann die Sache mit den 2^n-Texturdimensionen nicht mehr.

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