Frage: Gibt es eine Möglichkeit, die Sprite Funktion von OpenGL zu nutzen, aber nicht alles zu rendern, sondern nur das Sprite? Also nicht den ganzen Hintergrund als BMP zu nehmen, sondern nur dort wo auch das Sprizte sich befindet?

Hintergrund: Mir reicht eigentlich für das was ich darstellen möchte die 2D Funktion von OpenGL mittels Sprite völlig. Möchte aber gleichzeitig die normale Draw Funktion auf die Windows Grafik Objecte nutzen (weil es eben sehr einfach ist). Dehen und verschieben ist mit OGL Sprites sehr einfach. Da liegt es doch nahe beides zu verbinden, oder?

Kann mir jemand einen Tip geben oder gibt es irgend wo eine Demo? (Das 2D Tutorial kopiert auch den gesamten Hintergrund und verwaltet diesen. Wenn eine Änderung eintritt sieht man diese nicht).

Das was du da vor hast ist leider ein bisschen gegen die Natur von OpenGL. Denn OpenGL arbeitet mit einem Framebuffer der beim Zeichnen immer komplett gezeichnet wird. Entsprechend wird auch immer der gesammte Bereich übermalt. Aber es ist auch nicht ratsam die GDI und OpenGL zu mixen, denn beide Techniken arbeiten intern zu unterschiedlich als das man dabei wirklich Vorteile bekommt. Auch wenn beide "nur" etwas auf ein Fenster zeichnen intern sind sie zu verschieden.

Je nachdem was du vor hast gäbe es vielleicht unter Umständen eine halbwegs gangbare Möglichkeit. Allerdings tritt da wieder das Obere in Kraft. Nach Möglichkeit sollte man es nicht mischen. Evtl wäre es da besser, wenn du uns genau erklärst was du vor hast.

Hallo, vielen Dank fürs Antworten, auch wenn es noch nicht die Lösung ist. Will mal versuchen das ganze zu beschreiben. Vielleicht kommt dann eine Variante heraus, die eine gute Lösung für das Problem darstellt:

Was mache ich bis jetzt:
Derzeit stelle ich eine Anlage in 2D Seitenansicht dar. Diese Anlage hat Fahrstrecken, Tauchbecken und andere Anlagenteile. Es fährt nun ein Carrier der eine Autokarosse trägt die Anlage ab und dreht sich im bereich der Tauchbecken, um die Karosse zu tauchen. Der Hintergrund und die Anlage wird ganz normal auf dem Object TGraphicControl gezeichnet. Ist auch ziemlich statisch, so das nicht all zu viele Paint Vorgänge anfallen. Allerdings wird die Anlage genau im Maßstab gezeichnet, der auch gezoomt werden kann! Es ist also etwas Präzision gefragt. Der Carrier ist zur Zeit auch nur ein Dreieck, auf dem, wenn eine Autokarosse vorhanden ist, diese mit ca. 40 Linien gezeichnet wird. Wie schon gesagt, der Carrier kann sich um 360° drehen. Das mache ich indem ich die Zeichenfläche sperre (canvas.Lock), die Linen mit Pen.Mode pmNOT zeichne und die Zeichenfläche wieder entsperre. Beim nächsten mal werden die Linen 2 mal gezeichnet, erst die alte gelöscht und dann die neue gezeichnet. Das funktioniert ziemlich gut und ist wahnsinnig schnell. Die CPU Belastung ist auch bei 40 Carrier (kann maximal vorkommen) kaum spürbar. Allerdings ist es sehr primitiv und macht auch nicht viel her, aber funktioniert.
Nun würde ich das ganze gerne aufpeppen. 3D wäre toll, allerdings fehlt mir absolut die Erfahrung um das vorhandene in der Genauigkeit und in der vorgegebenen Zeit umzusetzen. Also hatte ich die Idee es mittels sich drehender Bitmap (also Sprites) umzusetzen, was am Hintergrund zu scheitern droht. Direkt mit Bitmaps zu arbeiten habe ich bereits versucht, ist aber entschieden zu langsam, auch wenn ich mit Clipping arbeite, da das Sprite durch die Zoom Möglichkeit groß werden kann. Also was tun ...???

Hat vielleicht jemand eine geniale Idee?

Hinweis: Da sie Darstellung auch in Echtzeit läuft, kann es vorkommen, dass eine Bitmap (Sprite) in 10 sec. über 1000 Pixel verschoben wird.

Würde mich freuen, wenn ich einige Meinungen von den altgedienten erfahrenen Forummitgliedern hätte.

MASU

OpenGl hat in dem Sinne keine Sprite Funktion, sondern etwas, was in der Wikipedia "Shape" genannt wird. Realisieren kann man das auf vielfältige Art und Weise (alte Displaylisten, alte Vertexarrays, neuere VertexBuffer Objects). Deine Bemerkung, dass auch eine größere Anzahl von Carriern möglicherweise gezeichnet werden muss, gibt eigentlich einen Hinweis darauf, dass Du etwas Schnelleres brauchst als nur das normale GDI. Mit GDI Plus kenne ich micht nicht aus. Aber in OpenGL sollte das nur von der Hardware abhängig sein. Auf genügend schneller Hardware kann die entsprechende Software das sicherlich realisieren.

Von 3D rate ich Dir definitiv ab, außer Du hast mindestens ein Jahr Zeit (Full Time, versteht sich). Das soll jetzt keine Abschreckung sein, 3D zu lernen. Aber für ein Projekt mit einem Fertigstellungstermin wird das extrem hart werden. 2D sollte man dagegen in einer vertretbaren Zeit lernen können.
Viele Grüße
Traude

Hach. Jetzt fängst du aber an zu schleimen.

Wie du im 2D Tutorial ja gesehen hast kann man die Ansicht von OpenGL so anpassen, dass sie sich wie ein normales TCanvas verhält. Also Pixelgenau arbeitet. Dazu musst du bei glOrtho die genaue Größe deiner Zeichenfläche eingestellen. Und wenn das stimmt dann funktioniert es auch. In dieser Ansicht kannst du natürlich auch kleine 3D Objekte benutzen. Allerdings fehlt dann die typische perspektivische Verzerrung des Raumes die in echten 3D "Welten" so existiert. Allerdings mit dieser Perspektive wird es natürlich extrem schwer wirklich genau den Inhalt an das Fenster anzupassen. Innerhalb der Welt kannst aber genau so genau kontrollieren wie weit sich etwas bewegen soll.

Für dein Problem sehe ich jetzt so 2 mögliche Lösungen.

Die erste Methode wäre alles in OpenGL zu zeichnen. Dann wären Zooms, Verschiebungen, Skalierungen etc alles in Echtzeit möglich. Aber das erfordert natürlich eine Menge Aufwand. Da du mehr oder weniger alles was mit Zeichnen zu tun hat nachprogrammieren müsstest. Das wäre dann allerdings die beste Lösung im Zusammenhang mit OpenGL. Aber da wird vermutlich die Zeit der entscheidende Faktor sein.

Die andere Möglichkeit wäre vom Aufwand und vom Zusammenspiel sogar noch halbwegs verkraftbar. Da du bereits sowieso alles auf ein TGraphicControl (genau genommen dessen TCanvas) zeichnest, könntest du die Zeichenoperationen auf ein TCanvas eines TBitmaps umleiten. Dieses Bitmap könntest du dann als Textur benutzen. Jedes Mal, wenn du Zoomst etc aktualisierst du das Bitmap und erstellst daraus eine Textur. Diese Textur kannst du dann in OpenGL ganz normal als Hintergrund zeichnen. Deine Sprites würdest du dann über den Hintergrund zeichnen und das wars.

Zur Lösung mit den Bitmaps. Das Bitmap sollte als Größe eine Potenz von 2 haben. Also 1, 2, 4, 8, 16, ... 256, 512, 1024. Sollte deine Zeichenfläche größer als 1024x1024 werden können, so solltest du das Bitmap wohl in mehrere Teile zerschneiden. Pixelformat ist pf24 Bit. Zum Erstellen einer Textur kann ich die die [urlhttp://wiki.delphigl.com/index.php/Glbitmap_loader]glBitmap[/url] anbieten. Der Artikel ist leider nicht ganz aktuell. Du musst die glBitmap konfigurieren. In deinem Falle brauchst du wohl nur das define GLB_DELPHI aktivieren. Dann bietet die Klasse TglBitmap2D eine Methode AssignFromBitmap. Damit wird das übergeben Bitmap in den Internen Speicher der Instanz geladen und nach dem Aufruf der Methode GenTexture wird die Textur erstellt. Evtl existierende ältere Textur wird vorher gelöscht. Zeichnen kannst du diese Textur dann ganz normal. Im dem Paket auf meiner Webseite ist auch ein Beispiel enthalten wo ich eine Textur 1:1 darstelle.

Bei der Texturinstanz die dein Hintergrund ist solltest du evtl noch folgende Parameter setzen. Damit deaktivierst du mipmaps und deaktiviert die Texturfilterung. Da du es sowieso 1:1 darstellst ist vollkommen egal.

Wenn deine Sprites irgendwann Texturen sind, dann solltest du da aber die Filterung aktivieren. Den Grund dafür kannst du im 2D Tutorial (das Flugzeug) erkennen.

Sollte das jetzt zu schnell gegangen sein (was ich verstehen könnte), dann scheue dich nicht und frage nach. Eine Sache solltest du aber noch bedenken. Die Rechner auf denen deine Anwendung laufen soll brauchen aber eine Hardwarebeschleunigte Grafikkarte. Wenn es halbwegs aktuelle Systeme sind ist das eigentlich kein Thema. Aber wenn sie es nicht sind, dann springt mitunter Windows ein und berechnet alles auf der CPU. Was durchaus etwas langsam werden könnte.