Hi,
ihr kennt doch sicherlich diese sorglos-glücklich-Pakete wie DelphiX oder Omega? Eben das genannte Omega hab ich in SpaceWars verwendet ( http://sw.philiplb.de, erreichbar, wenn Olympweb wieder erreichbar ist ). Nunja, aber die Abhängigkeit mag ich nicht. Das Spiel ist mit der alten Version von Omega alles andere als stabil. Auf meinem Notebook läuft es nicht, auf meinem Desktop auch nicht (mehr, der hat sowieso eine (Hardware-)Macke).
Da mir an SpaceWars viel liegt, will ich das in OpenGL noch einmal schreiben.

Nunja, damit will ich die nächste Zeit laaaangsam anfangen.
Jedoch tauchen da einige grundlegende Fragen auf. In einem 2d-Spiel dieser Art ist pixelgenaue Kollisionsabfrage ziemlich wichtig. Ich hab mir vorgestellt, die Sprites als Texturierte Quads im Ortho-Modus zu zeichnen. Jedoch hab ich keinen Ansatz, wie ich da die Kollisionsabfrage nach Pixeln (Die Sprites drehen sich auch) realisieren soll? Rein grundlegend, kein Code.

Da bleibt dir im Endeffekt nix anderes übrig als die pixelgenaue selbst zu erledigen, und zwar auf der CPU. Da solltest du dir vielleicht (wohl am besten aus dem Alphakanal der Textur heraus) die Pixelmaske nehmen und in nem zum Objekt gehörenden Array ablegen. Dann musste halt Pixel für Pixel testen ob an nem bestimmten Punkt ne Kollision stattfindet, wobei ich vorher trotzdem noch AABBs verwenden würde, um überhaupt zu testen ob Objekte kollidieren könnten, denn so sparst du dir erstmal sehr viele Pixeltests. Und das mit der Rotation deiner Objekte wirste dann auch selbst erledigen müssen, aber eine 2D-Rotation dürfte recht einfach zu machen sein (dank Sinus und Cosinus).

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

Wieso wusste ich, dass ich um genau das nicht rumkommen werde.

Es lohnt sich vielleicht auch die gedrehten Sprites im Speicher zu halten um die Kollision zu beschleunigen.

Moderne Grakas vorausgesetzt könnte man doch auch das erste Sprite in den ZBuffer (oder Stencil oder Alphabuffer) schreiben, die entsprechenden Tests aktivieren, das zweite Sprite zeichnen und Occlusion Queries verwenden - sollte eigentlich schneller sein, als selbst die Pixeldaten durchzugehen.

Wenn der Treiber Histogramme unterstützt kann man genau das selbe machen, die Maske des ersten Sprites rot, die des zweiten grün zeichen und dann das Histogramm des Bildes berechnen lassen.

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

Naja, also ich würde nicht behaupten, dass ich ne moderne Grafikkarte habe.

Eine sehr schnelle Pixelgenaue Kollision bekommst du auf jeden Fall, wenn du die Masken der Sprites als 1 Bit Bitmaps ablegst und diese AND verknüpfst. Die Bits die danach <> 0 sind "kollidieren" - wenn du dies machst, solltest du aber auf jeden Fall Lars Rat beherzigen und die Masken rotierter Sprites im Voraus berechnen (brauchen ja nur wenig Speicher) - nützlich in diesem Zhg könnte sich auch die Delphi TBits Klasse erweisen, die meines Wissens recht optimierten Code enthält (natürlich kannst du auch selbst Hand anlegen, wenn dir das lieber ist).

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

Das klingt garnicht so verkehrt, danke.