kannst du das nicht ohne PixelAbfrage machen?
Oder nur bei dem großen raumschiff?
denn erstens Mehr FPS und 2ten trifft doch munition doch eh bei den kleinen schiffen wenn das rechteck das schiff berührt oder? :-/

_________________
www.audi32.de

Durch eine Typisierung der Sprites konnte ich die Frameraten bei langsamen Systemen um den Faktor 2 erhöhen, bei schnellen hat es kaum etwas gebracht. Die pixelgenenaue Prüfung wird nur bei wenigen Objekten gemacht und geht mittlerweile nur noch mit ca. 4-5% in die Renderzeit ein. Optimierungsbedarf in der Routine gibt es noch. Den größten Verbrauch, mit ca. 13%, hat zur Zeit der Aufruf der Methode Items bei TObjectList.

Einen seltsamen Effekt habe ich gefunden. Ich zeichne die Sprites mit folgender Routine auf dem Schirm:


Durch eine Debug - Unit für OpenGL, welche ich mir für bestimmte OpenGL - Funktionen, erstellt habe, wird in ein Protokoll die Funktion, Unit und Zeile eines OpenGL - Fehlers geschrieben. In dem Protokoll steht folgende Zeile: uGame(Line: 893): GL_INVALID_OPERATION(glEnd). Ich habe keine Ahnung, warum dieser Fehler auftaucht. Zudem verbraucht diese Zeile ca. 12% der Renderzeit, was für mich auch nicht verständlich ist. Weder beim glBegin oder bei den Befehlen dazwischen wird ein Fehler aufgezeichnet. Hat jemand einen Tip für mich, was die eventuelle Ursache des Fehler sein könnte. Die Anzeige erfolgt korrekt.

Gruß
KidPaddle

_________________
http://www.seban.de

Also laut Wiki müsste alles Funktionieren. GL_INVALID_OPERATION gibts zwar im zusammenhang mit glEnd aber nichts was es auslöst, kann ich hier sehn.

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

Dass der Code viel Zeit beansprucht ist klar - Fehlerbehandlung benötigt viel Zeit, außerdem treten Fehler in glBegin glEnd Blöcken meist erst bei glEnd auf, da meist erst mit diesem Kommando OpenGL anfängt überhaupt etwas zu tun.

Mögliche Fehler sind:
* Du hast irgendwo vorher noch ein glBegin stehen, das nie mit einem glEnd abgeschlossen wurde (auch überprüfen ob du irgendwo zu einem Zeitpunkt aus einem try Block rausfliegst, wo es nicht sein sollte)
* Die übergebenen Koordinaten sind irgendwelche "Unzahlen" (NAN, INF, -INF, auch wenn der OpenGL Treiber an sich damit fertig werden sollte)

Dein geposteter Code schaut jedenfalls korrekt aus, allerdings verhalten sich ältere Delphi Kompiler (<6) bei Fließkommaoperationen unter OpenGL etwas seltsam, wenn das Kommando Set8087CW($133F); nicht irgendwo beim Programmstart aufgerufen wird (sollte an sich die OpenGL Bibliothek machen).

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

Nach mehren Stunden habe ich den Fehler gefunden. Wer lesen kann ist klar im Vorteil. Steht doch im Wiki, dass ein Aufruf von glGetError zwischen glBegin und glEnd nicht erlaubt ist. Da ich in der Debug - Unit nach jedem Befehl auf Fehler geprüft habe, habe ich somit auch den Fehler dort produziert. Nun habe ich einen Zähler eingebaut, der bei glBegin erhöht und bei glEnd erniedrigt wird. Vorteil dabei ist, das ich nun auch fehlerhafte Aufrufe von glBegin und glEnd mitprotokolieren kann.

Die Debug - Unit wird nur einmail eingebunden und nach einem ActiveRenderContext initialisiert. Ab diesem Punkt biege ich die Zeiger auf die OpenGL - Funktionen auf eigene Funktionen um und kann somit jeden Aufruf, der vorher über die Unit dglopenGl ging, egal wo er stattfindet, protokolieren. Es werden zur Zeit die Fehler und der Aufruf von Funktionen mitprotokoliert. Heraus kommt dies:

oder


Dank der JCL sieht man sogar Unit und Zeile, wo der Fehler aufgetreten ist. Zur Zeit werden nur wenige Funktionen,

unterstützt. Falls interesse besteht, werde ich die Unit weiter ausbauen und hier zu Verfügung stellen. Diese Unit sollte auch unter Linux laufen, da ich mich an den Still von dglOpenGL.pas gehalten habe, was die Auffrufkonventionen angeht.

Eine neue Version werde ich hoffentlich bis morgen veröffentlichen.

Gruß
KidPaddle

_________________
http://www.seban.de

Auf alle Fälle sicherlich nützlich und hilfreich beimdebuggen.

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

So, nach einigen Tagen arbeitend für die Firma, konnte ich weiter an dem 2D Spiel arbeiten. Unter http://www.seban.de/download/sf.zip (1.7MB) steht die neue Version bereit. Die Kollisionsabfrage wurde weiter optimiert und auf einer Matrox Millenium G400 komme ich nun nicht unter 150 FPS. Lauf einem Profiler wird ca. 70% der Zeit für das senden der OpenGL - Befehle verbraucht, so daß die Ausgabe nun hauptsächler an der Graka hängt. Auf einer Radeon 9800pro liege ich zwischen 400 und 600 FPS jenach Anzahl der zu zeichnenden Objekte.

Leider scheint es ein Problem mit SiS Onboard - Grafikkarten geben und zwar mit den Texturen. Das Spiel läuft und man kan durch pressen von der Taste 2 sehen, das die Texturen gezeichnet aber nicht dargestellt werden. Die Texture - ID sind gültig und bei der Erzeugung der Texturen scheint kein Fehler aufzutreten. Hat jemand eine Idee, woran das liegen kann?

Gruß
KidPaddle

_________________
http://www.seban.de

Also ich habe auch schon ein paar lustige Dinger in der OpenGL Implementation von SiS und Intel festgestellt. Kannst du davon evtl mal ein Bild machen? Da ich nicht so ganz verstehe was du damit meinst, dass sie zwar da sind aber irgendwie doch nicht. Woran hast du denn mitbekommen, dass sie da sein müssen.

Evtl lohnt es sich auch ein extra Programm (Ein Quad mit einer einfachen Textur) zu machen um zu sehen ob das überhaupt sinnvoll funktioniert und ob du den Fehler so ein bisschen einschränken kannst.

Ich zeichne um jede Texture 4 Linien, wenn die Taste 2 gedrückt wurde. Man sieht so, daß der Aufruf des Zeichnens erfolgt. Die Texture ID war gültig und glGetError brachte beim Binden keine Fehler. Auf einem Rechner waren vereinzelte Pixel zu sehen, die sich auch bewegt haben, jedoch ist meistens nur der Hintergrund zu sehen.

Gruß
KidPaddle

_________________
http://www.seban.de

Du solltest überprüfen
* ob die Ausdehnungen der Texturen tatsächlich Zweierpotenzen sind
* ob die Texturen kleiner sind, als die maximale Texturgröße der OpenGL Implementation
* ob du auch keine Kommandos verwendest, die eine "größere" OpenGL Implementation voraussetzen, als der Treiber zur Verfügung stellt (du kannst das Programm zur Sicherheit mal mit Microsofts/SGIs Softwareimplementation testen (OpenGL 1.1) - dazu musst du nur ein Pixelformat mit gesetztem "generic" Flag wählen)

Wenn der Bug tatsächlich im Treiber liegt, hast du ein Problem:
in diesem Fall ist es möglich, dass der Treiber einige Texturformate (vom mir aus GL_LUMINANCE) nicht korrekt darstellt, oder sogar ein Problem mit Texturobjekten hat. Wenn es unbedingt auch auf der ältesten OpenGL Implementation (1.0), bzw. dieser speziellen Karte laufen muss, kannst du daher versuchen, keine Texturobjekte zu verwenden, sondern einfach mittels glTexImage2D das entsprechende Bitmap vor der Verwendung als Textur hochzuladen (sollte immer noch schnell genug für ein 2D-Spiel sein).

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

Hallo Mars,

die Texuren sind entweder 32x32, 64x64 oder 128x128. Es wird keine der Texturen angezeigt. Das erstellen des Pixelformates mit dwFlags = PFD_GENERIC_FORMAT anstelle von PFD_SUPPORT_OPENGL hat keiner Änderung gebracht. Seltsamerweise auch keine Änderung in der Gschwindigkeit, wahrscheinlich weil auf der Matrox schon die Software - Implementierung von OpenGL läuft.

Zum laden der Texturen verwende ich glBitmap von Lossy Ex, zum zeichnen der Texture folgenden Code:


Das sind alles Standardbefehle.

Gruß
KidPaddle

_________________
http://www.seban.de

Ich hatte vor Jahren auch schonmal die "Ehre" OpenGL auf ner Matrox-Karte zu programmieren, damals war Matrox aber selbst im Gamer-Bereich noch anerkannt (war zu Zeiten der G400). Und selbst damals war deren OpenGL-Implementation total katastrophal, woran sich bis heute wohl kaum etwas geändert hat. Von daher dürfte dein Problem wohl definitiv von den Treibern her kommen. Einzige "Alternative" : Es gibt Wrapper, die OpenGL-Befehle nach D3D übersetzen, und sowas ist dann auf Matrox-Karten mit Sicherheit besser als deren grauenvolle OpenGL-Implementation.

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

Mal ne ganz doofe Frage. Benutzt du Backfaceculling? Denke ich mal ja. Hast du das schon mal ausgestellt? Nicht, dass deren Treiber von Natur aus in die andere Richtung arbeitet.

Die Matrox G400 arbeitet einwandfrei, das zweite Bild ist von dieser Graka, jedoch sind es SiS Onboard Graka, z. B. die vom ASUS Pundit, die mir Probleme bereitet. Wenn ich den Alphakanal ausschalte, dann wird wenigsten ein Viereck angezeigt.

Gruß
KidPaddle

@Lossey Ex
Ja, benutze ich. Habe ich gerade mal kurz deaktivert, jedoch kein Unterschied wie zuvor.

_________________
http://www.seban.de

SiS und OpenGL kann man sowieso vergessen. Daher würde ich mir da gar keine Gedanken machen, oder direkt GDI+ anstelle von OpenGL benutzen. Da kann auch Überblendungen (Startmenü) und verschiedene 2D Effekte verwenden.