1.Wenn ich kein glClear() ausführe wird die Zeichenfläche ja nicht gelöscht. Wie kann ich diesen Teile der Zeichenfläche die nicht jedesmal neu gezeichnet werden(also das was sonst jedesmal gelöscht wird) bearbeiten?

2. Wie kann ich OpenGL als einfache 2D Zeichenfläche nutzen?
Kann ich dann direkt darauf zugreifen?(siehe 1.)

Pixelwerte aus dem Framepuffer auslesen : <a href='http://www.3dlabs.com/support/developer/GLmanpages/glreadpixels.htm' target='_blank'>glReadPixels</a>
Pixelwerte in den Framepuffer schreiben : <a href='http://www.3dlabs.com/support/developer/GLmanpages/glcopypixels.htm' target='_blank'>glCopyPixels</a>

Allerdings würde ich die nicht ihm großen Maßstab benutzen, da beide Funktionen je nach Grafikkarte sehr langsam sein können, denn sie stellen einen Eingriff in die Renderpipeline dar, welcher sehr aufwendig ist.

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

Also wenn du bei dem "onresize" - Ereigniss folgenden Code eintippst, dannbesfindeste dch in einem Reinen 2d-Modus... Bei diesem ist es dann auch so, dass die Weltkoordinate (0,0) genau in der ecke des Fensters liegt und dementsprechen die Weltkoordinate (width, height) entsprechend gegenüber... das heißt, dann man natürlich auch immer Weiß, wo alle Objekte auf dem Screen landen.... oder was meintest zu mit "zugreifen"?

_________________
Es sind immer die guten,
welche zu früh von uns gehen müssen...
Meine bislang 13 Open Gl - Tuts findet ihr auf www.dcw-group.net
Neu! Ein großer Teil der Demos nach Kylix übersetzt!

mit zugreifen meinte ich mehr ob ich dann direkte änderungen durchführen kann. Also das ganze z.B. so wie ne Canvas Zeichenfläche nutzen.
Ich werde keine Poylgone drauf Zeichnen sondern nur Pixel setzen...
halt OpenGL nur als schnelle Zeichenfläche.

Wie ich oben bereits erwähnt hab, stellen sowohl glReadPixels als auch glCopyPixels Eingriffe in die Renderpipeline dar, die je nach Grafikkartentreiber sehr aufwendig sein können.
Im Endeffekt ist es sogar möglich, das die Nutzung von OpenGL zum Verändern einiger Pixel langsamer als die Nutzung der GDI ist, weshalb ich dir von dieser Lösung abrate.Wenn du ne schnelle Zeichenfläche brauchst, dann *empfehle* ich dir DirectDraw oder eine DelphiLIB die darauf aufbaut wie z.B. PowerDraw.

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

Oder SDL!
OpenGL ist hauptsächlich durch seine 3D-Beschleunigung interessant, diese ist Vertex-orientiert und nicht pixel-orientiert. Aber mal Ernsthaft, wo verwendet man in der heutigen Zeit noch viele einzelne Pixel? In dem moment, wo Du größe Flächen mit ner Textur verwendest sieht das ganze schon wieder gänzlich anders aus...

_________________
"Light travels faster than sound. This is why some people appear bright, before you can hear them speak..."

Du wirst Lachen. An dem Produkt (DataMiningSoftware (DatenAnalyse)) an dem ich mit dran arbeite. Dort ist eine OpenGLAnsicht eingebaut die kann so ziemlich alles darstellen was du willst und vor allem frei dreh, zoombar, schnell und all die anderen Vorteile die man damit hat. Achja. Per Knopfdruck in 2D Wechselbar. Also alles in allem ziemlich geil und Totschick.

Aber frage nicht wie oft ich das schon gehört habe, dass unsere Kunden eine 2D Ansicht, ähnlich Excel, haben wollen. Was zum Teufel ist denn daran so besonders? Okay. Die Managementebene versteht keine komplizierten Grafiken. Und die Moral von der Geschichte ist nun, dass wir (ich) eine Ansicht einbauen werde die pur auf einer Canvas malt. Und vor allem in 16 Farben oder so. Ich fühle mich kastriert!!!

Nein aber mal Spaß bei Seite. Wenn du ein Produkt hast was auch für den Vorstand eines Unternehmens gedacht ist dann müssen solche Grafiken mit rein. Mit allem Anderen kommen die nicht klar. So traurig wie es nun mal klingt so ist es aber.

Aber auch DirectDraw ist nicht mehr so schnell, da es ab der Version 8 von DirectX mit Direct3D zusammengefasst wurde. Somit hat man bei DirectDraw eigentlich auch eine 3D-Zeichenfläche, die eben leicht optimiert ist und nur 2D-Funktionen anbietet (Sprite-Darstellungen usw.). Aber einzelne Pixel zu lesen und zu setzen ist nicht wirklich arg viel schneller. Vor allem bei hohen Auflösungen kann man das eigentlich vergessen. Denn ich nehme an, dass Du nicht 10-20 Pixel setzen willst, sondern mehrere.

Wenn es Darum geht einen Rahmen oder ein Paar Spieler-Infos ausgeben willst, empfiehlt sich wirklich der Ortho-Modus von OpenGL und dann ein Quad mit dem zu zeichnenden Bild (z.B. Rahmen oder so) als Textur. Alles andere ist nicht umbedingt Perfomant. Glaub mir, ich hab' schon diverse entäuschende Versuche hinter mir (so aus meiner Grafik-Anfangs-Zeit) und hatte damals nur eine Auflösung von 640x480. Bei 256 Farben mag das (bei dieser oder gerade mal der nächsten Auflösung) noch gehen, aber ab 16bit Farbtiefe oder gar 24/32 Bit und einer Auflösung von 1024x768 ist das ganze nicht wirklich so der Renner!

Was genau willst Du eigentlich im Endeffekt erreichen? Villeicht findet man ja einen anderen, besseren Lösungsweg!?!

_________________
Und was würdest Du tun, wenn Du wüsstest, dass morgen Dein letzter Tag auf dieser Erde ist?

hm, mir geht es halt einfach um ne wirklich schnelle Zeichenfläche. Wie halt zu Dos Zeiten wo man seinen Grafikmodus initialisiert hat und dann wie wild GetPixeln konnte

@Lossy: Ahem... Ahem... Du sagst mit deinem Post doch nicht wirklich, dass ihr Eure Ausgabe Pixel für Pixel setzt? Würde so einiges über den Haufen werfen, was ich bisher so denke O_o

@billy: Wie gesagt schau Dir sonst mal SDL an. Fand ich hervorragenden auch in Kombination mit OpenGL. Ist IMAO ne bessere Wahl als DirectX Falls Probleme damit haben solltest, schreib mich mal an, zumindest für die OpenGL Init kann ich glaube ich was geben, wobei die SDL SDK ne Menge klasse Beispiele hat

_________________
"Light travels faster than sound. This is why some people appear bright, before you can hear them speak..."

@Phobeus: Na ja nicht direkt. Ist noch in Arbeit. Da bin ich gerade bei.
Aber was meinst du wie das ist wenn man eigene Fensterelemente braucht? Da musst du auch alles per hand malen. Und wenn das ein wenig optimiert ist dann ist das auch nicht unbedingt super langsam. (sofern man nicht gerade Pixels verwendet)

@Billy: Ist evtl auch für dich interessant. Und es kommt immer darauf an was man aus den gegebenen Möglichkeiten herausholt.

Man mache sich ein Bild so groß wie die Zeichenfläche und dort zeichnest du rein. Wichtig ist, dass man das nicht direkt auf den Bildschirm macht. Weil 1. Langsam wie sau und 2. flackert das unnötig.

Also Bild am Anfang erstellen und erst am Ende wie frei geben (für Doublebuffering 2 Bilder). Das hat dann ein wenig ähnlichkeit wie der Rendercontext in OpenGL. Beim Zeichnen muss man dann darauf achten direkte Befehle wie LineTo der Canvas zu verwenden. Bzw. um Bilder zu zeichen Draw oder ähnliches. Aber wirklich so gut wie nie Pixels verwenden. Das ist das Langsamste wo gibt. Um zum Beispiel ein Hintergrund zu malen kann man auch Brusch.Bitmap verwenden. Auch sehr schnell. Scanlines bei einem Bitmap ist direkt in den Speicher des Bildes. Ist zwar ne wilde Pointerschieberei aber schneller gehts kaum noch.
Tja und wenn man fertig ist dann Zeichnet man das Bild mittels Draw auf das Fenster.

Ich muss aber zusagen, dass es bei unserem Produkt nicht darum geht super viel Frames zu schaffen. An der Stelle geht es eher darum ein recht unabhängiges System zwecks Datengröße zu schaffen. Es handelt sich hier hauptsachlich um solche Graphen Excel like.
In wie weit sich das geschwindigkeitstechnisch von DirektDraw unterscheidet kann ich nicht sagen. Aber wenn man sich an ein paar Dinge hält dann ist das durchaus auch brauchbar.

Bei Fensterelementen? Ja gerade da würde ich Quads nehmen und dann mit einer Textur (einer!! *g*) per UV-Mapping unterschiedliche Bereiche zuweisen. Praktisch ein HTML-gepuzzel auf OpenGL-Basis. Der Vorteil ist halt, dass man dann am ende sogar noch schön blenden kann, das wird bei Pixel schneller zur CPU-HärteProbe, oder nicht

_________________
"Light travels faster than sound. This is why some people appear bright, before you can hear them speak..."

Also ich meine da so etwas wie eine Tabelle oder eigene Buttons etc. Also Dinge die auf einem Fenster sitzen. So etwas muss man mit GDI machen. Allerdings muss man bei einem einfachen Button nicht mal puffern. Ich hatte schon mal einen Button nachgebaut. Der hatte sich auch ein Bild genommen und das zerlegt gezeichnet. Davon hatte ich dann mal ein Paar auf meinem Fenster. Und die Systemleistung lag bei ca. 0-1%. Sofern die gezeichnet wurden versteht sich.

Und jetzt Stelle dir mal vor wenn du dafür OpenGL verwendest. Erst einmal initialisieren und dann habe ich das Zeugs schon 10 Mal gezeichent.
Also wenn ich dich da richtig verstanden habe.

Und zum Thema Blending *g*
Schau dir mal das an. <a href='http://www.g32.org/graphics32/index.html' target='_blank'>http://www.g32.org/graphics32/index.html</a>
Alles Delphikomponenten und ziemlich geile Sache das. Schau dir mal die Examples an.
ch glaube das reicht als Beweis dafür, dass es auch schnelle nicht OpenGL Sachen gibt.

Achja Billi das wäre vielleicht was für dich. Ist mir erst jetzt wieder eingefallen. :rolleyes:

[Edit] Aber das Blending der Graka ist aber trotzdem schneller.

*gg* Ja, okay. In dem Fall aber auch die GDI, ich hatte das mit den Pixeln auf OpenGL bezogen und kann mir da eben denkbar besseres Vortstellen Auf der anderen Seite... Splash-Screen rein, hidden init und schon kann man die einzelnen Elemente blenden bis es dem Nutzer übel wird. B)

_________________
"Light travels faster than sound. This is why some people appear bright, before you can hear them speak..."

Ich habe mich jetzt erstmal einfach auf ne einfache Delphi Canvas beschränkt. Wenn man nur in ein Bitmap zeichnet und dieses Bitmap einfach jedesmal mittels canvas.draw auf die Zeichenfläche des Formulars packt dann hat man kein Flackern und eine absolut gute Geschwindigkeit. Mittels ScanLine kann man dann sogar noch extrem schnell das Bitmap Pixel für Pixel bearbeiten...