[*]Profan

RGH

Hallo Pascal,

da es schon spät ist und die nächste Subscriptionslieferung diese nacht noch noch raus soll, heute nur ganz kurz:

Die XProfan-oGL-Funktionen haben nicht die Absicht, die oGl-API 1:1umzusetzen, d.h. hinter fast jeder oGL-Funktion verbergen sich mehrere API-Aufrufe. Hinter Clear verbirgt sich also deutlich mehr als das glClear. Es wird zum Beispiel ein Default-Viewport eingestellt, etc. Wer ein Beispioel aus der Literatur umsetzen möchte, kann ja auf die vollintegriete OpenGL-API zurückgreifen.
Ziel der oGL-Funktionen ist es, mit möglichst wenigen XProfan-Zeilen (auch wegen des Tempos!) möglichst gute Resultate zu erzielen. Außerdem soll die Anzahl der oGL-Funktionen überschaubar bleiben, damit auch der Einsteiger schnell zum Ziel kommt.

Was den Ursprung der Objekte betrifft, habe ich lange mit mir gerungen. Ich bin davon ausgegangen, daß OpenGL in erster Linie für Spiele eingesetzt werden wird und da liegen die Objekte nun mal alle auf dem Erdboden (der Nulllinie) und ragen nicht zur Hälfte in diesen hinein. Wenn ich einen Cuboid für ein Haus oder eine Mauer baue, müßte ich ansonsten so tricksen, wie Du jetzt bei den Asteroiden (oder ich beim Planeten-Demo). Um mit einem meiner früheren Chefs zu sprechen: Einen Tod müssen wir sterben.

Wieso brauchst Du bei Listen und Texturen unbedingt Arrays? Du kannst doch Listen- oder Texturnummer jeder beliebigen Integervariablen zuweisen. Auch hier werden mehrere OpenGL-API-Aufrufe zu einer XProfan-Funktion zusammengefaßt. Was das Löschen einer Liste betrifft hast Du natürlich recht. Das sollte ich noch einbauen.

Daß man Texturen auch aus Bitmaphandles und aus TGA-Dateien erzeugen kann, ist geplant. Ob es aber schon in XProfan 10 realisiert wird, weiß ich noch nicht.

Ok, das soll für heute reichen.

Gruß
Roland

Intel Duo E8400 3,0 GHz / 4 GB RAM / 1000 GB HDD - ATI Radeon HD 4770 512 MB - Windows 7 Home Premium 32Bit - XProfan X4

03.05.2006 ▲

Frank
Abbing

[quote:35b41f96d0]Was das Löschen einer Liste betrifft hast Du natürlich recht. Das sollte ich noch einbauen.[/quote:35b41f96d0]
Halte ich ebenfalls für wichtig. Der API-Aufruf ist zwar auch kurz, aber zumindest fehlt hierzu die Beschreibung.

ogl(glDeleteLists,liste&,1)

[quote:35b41f96d0]Daß man Texturen auch aus Bitmaphandles und aus TGA-Dateien erzeugen kann, ist geplant. Ob es aber schon in XProfan 10 realisiert wird, weiß ich noch nicht.[/quote:35b41f96d0]
Ich plädiere stark dafür

Da die 10er Version erst für Ende Herbst angekündigt ist, hättest du noch viel Zeit, das unterzubringen.

RGH

[quote:c80f356165=Frank Abbing][quote:c80f356165]Was das Löschen einer Liste betrifft hast Du natürlich recht. Das sollte ich noch einbauen.[/quote:c80f356165]
Halte ich ebenfalls für wichtig. Der API-Aufruf ist zwar auch kurz, aber zumindest fehlt hierzu die Beschreibung.
[/quote:c80f356165]
Es sollte schon möglich sein, OpenGL ohne API zu programmieren. Daher muß oGL(DeleteList, N%) noch eingebaut werden. Diese Listen verbrauchen Einiges an Grafikspeicher.

Gruß
Roland

Intel Duo E8400 3,0 GHz / 4 GB RAM / 1000 GB HDD - ATI Radeon HD 4770 512 MB - Windows 7 Home Premium 32Bit - XProfan X4

Ähem, den glDeleteLists hatte ich bereits in Okrea erfolgreich angewandt - viel wichtiger ist aber das ich es nicht-erfolgreich versuchte auch Texturen wieder freizugeben!

War ich nur zu unbededarft oder gibts da etwas das ich nicht wissen kann?

RGH

Jetzt zu einigen Punkten etwas ausführlicher:

[quote:51dbce937f=Uwe Pascal Niemeier]ogl(CLEAR) Entspricht nicht der ogl-API glClear; zusätzlich zum Löschen der Grafik wird auch das Koordinatensystem zurückgesetzt[/quote:51dbce937f]
Es geschieht, wie gesagt, noch einiges mehr, teilweise abhängig davon, ob ich mich im Testmode befinde oder nicht. Es wird in der fertigen Hilfe darauf hinzuweisen sein, daß hier nicht nur glClear aufgerufen wird! Die Namensähnlichkeit mag etwas unglücklich sein, mir ist aber noch kein besserer Name eingefallen.

[quote:51dbce937f]Ausserdem fehlt noch eine Kapselung von glDeleteList.[/quote:51dbce937f]
Ist in der nächsten (8.) Subscriptionsversion mit drin.

[quote:51dbce937f]ogl(2D,...) Sehe ich das richtig, dass hier zum 1. Mal die Rückgabewerte einer Funktion direkt in vorgegebene Zielvariablen geschrieben werden?? Sehr gewöhnungsbedürftig!
BTW: Die entsprechende Umkehrfunktion wäre auch sehr nützlich![/quote:51dbce937f]
Mir fiel keine für den Anwender einfachere Möglichkeit ein, zwei Parameter zurückzugeben. (Die Implementierung war nicht ohne, zumal ich natürlich abtesten wollte, daß da wirklich passende Variablen stehen.) Die andere Möglichkeit wäre gewesen, zwei neu zu schaffende Systemvariablen zu füllen. (So wie %bmpX und %bmpY nach Befehlen, die eine Bitmap laden.) Was ist besser?

Das mit der Umkehrfunktion ist auch nicht so ohne: Bei der Wandlung von 2D nach 3D brauche ich ja einen dritten Parameter (etwa die Entfernung vom Betrachter), da ich ansonsten einen Vektor zurückbekomme: Ein Punkt auf dem Bildschirm entspricht ja einer ganzen Linie von Punkte im dahinter liegenden 3D-Raum. Ich denke, wer es wirklich benötigt, ist so tief in der Materie drin, daß er auch die dazugehörige API, wo es die Umkehrfunktion natürlich gibt, bemühen kann. (Für diesen Fall liefert oGL(2D,...) schon jetzt den benötigten dritten Parameter z& zurück.)

[quote:51dbce937f]ogl(TESTMOUSE,...) & ogl(TESTXY,...) Wenn man bei letzterem die Mausposition übergibt, kann man sich ersteres sparen...[/quote:51dbce937f]
Da hast Du natürlich recht. oGL(TestMouse, x&, y&) ist identisch mit oGL(TestXY, x&, y&, %MouseX, %MouseY). Daß es beide gibt, liegt halt daran, daß TestMouse zuerst da war. Ich habe es dann dabei gelassen, da Testmouse wegen der geringeren Parameterzahl einen Tick schneller ist als TestXY. Ich könnte natürlich TestMouse ganz weglassen oder etwa bei TestXY die letzten beiden Parameter optional machen. Fehlen Sie, wird die aktuelle Mausposition genommen. Was meinen diejenigen Subscriptionskunden dazu, die diese Funktion(en) schon einsetzen?

[quote:51dbce937f]ogl(STARTTEST,...) & ogl(ENDTEST) Praktischer wäre, wenn man hier ein Rechteck vorgeben könnte wie in der Original-API. [/quote:51dbce937f]
Ja, auch hier muß ich Dir recht geben, zumal ich letztlich sogar dafür Verwendung gehabt hätte. oGL(StartTest,...) hat nun ein (ab der nächsten Lieferung) optionales Parameterpaar dx&, dy&, das wie in der OpenGL-API die Größe des Rechteckes um den Punkt sx&, sy& bestimmt. Werden diese Paramter weggelassen, werden diese Werte wie bisher mit 1 angenommen.

Gruß
Roland

Intel Duo E8400 3,0 GHz / 4 GB RAM / 1000 GB HDD - ATI Radeon HD 4770 512 MB - Windows 7 Home Premium 32Bit - XProfan X4

RGH

[quote:a2f1dbe078=iF]Ähem, den glDeleteLists hatte ich bereits in Okrea erfolgreich angewandt - viel wichtiger ist aber das ich es nicht-erfolgreich versuchte auch Texturen wieder freizugeben!

War ich nur zu unbededarft oder gibts da etwas das ich nicht wissen kann?[/quote:a2f1dbe078]
So ist die API definiert:
glDeleteTextures( GLsizei n, const GLuint *textures);
n ist die anzahl der zu löschenden Texturen und *textures ein Zeiger auf ein Integer-Array mit den Texturnummern. (Wird nur eine Textur gelöscht, darf es auch ein Zeiger auf ein einzelnes Integer sein.)

(Es ist schon eine gewisse Gemeinheit von OpenGL, daß hier die Parameter genau andersherum sind, wie bei DeleteLists und als zusätzliche Erschwernis noch ein Zeiger auf eine Liste der zu löschenden Texturen erwartet wird und nicht wie bei DeleteLists das erste zu löschende Element.)

So müßte es also gehen:

oGL(glDeleteTextures, 1, Addr(t&))
t& ist hier die Texturnummer.

Und ja, auch diese Funktion sollte ich noch als oGL-Funktion einbauen, da es bei größeren OpenGL-Anwendungen (etwa, wenn jedes Level eines Spieles eigene Texturen verwendet) unumgänglich ist, mit dem Grafikkartenspeicher zu haushalten.

Gruß
Roland

Intel Duo E8400 3,0 GHz / 4 GB RAM / 1000 GB HDD - ATI Radeon HD 4770 512 MB - Windows 7 Home Premium 32Bit - XProfan X4

[quote:8de59f2438]Sie, wird die aktuelle Mausposition genommen. Was meinen diejenigen Subscriptionskunden dazu, die diese Funktion(en) schon einsetzen?[/quote:8de59f2438]Ich bin der Meinung das die Subscriptionphase dafür da ist mögliche Ungereimtheiten zu erkennen. Roland sollte also während der Subscriptionphase keine Bedenken haben Funktionen umzubauen, zu ersetzen oder gar zu entfernen. ogl.testmouse würde ich nur dann für gelungen halten, wenn ogl.testmouse auch tut was es verspricht - was IMHO momentan nicht so ist: ogl.init erlaubt das Angeben eines Parenthandles für den ogloverlay. Wenn dieser nicht %hwnd ist so scheiterte ogl.testmouse in meinen Tests - da wohl %mousex/y relativ vom hwnd genommen wird. Wenn dem nicht mehr so ist dann ist alles in Butter.

RGH

[quote:3d74d3090a]iF: Roland sollte also während der Subscriptionphase keine Bedenken haben Funktionen umzubauen, zu ersetzen oder gar zu entfernen.[/quote:3d74d3090a]
Keine Bange, die habe ich nicht!

[quote:3d74d3090a]ogl.testmouse würde ich nur dann für gelungen halten, wenn ogl.testmouse auch tut was es verspricht - was IMHO momentan nicht so ist: ogl.init erlaubt das Angeben eines Parenthandles für den ogloverlay. Wenn dieser nicht %hwnd ist so scheiterte ogl.testmouse in meinen Tests - da wohl %mousex/y relativ vom hwnd genommen wird. Wenn dem nicht mehr so ist dann ist alles in Butter.

[/quote:3d74d3090a]
Ich werde das mal überprüfen.
Bei mit Create(Window,...) und Create(Dialog,...) erzeugten Fenstern löst ein Mausklick zwar kein Verlassen des WaitInput aus. (Daher sind diese Fenster für bestimmte OpenGL-Anwendungen mit WaitInput eher ungeeignet.) Aber davon abgesehen haben %MouseX und %MouseY (und damit auch oGL(TestMouse,...) ) selbstverständlich die korrekten zum erzeugtenFenster bezogenen Werte ... zumindest ab der nächsten Subscriptionsversion

.

Gruß
Roland

Intel Duo E8400 3,0 GHz / 4 GB RAM / 1000 GB HDD - ATI Radeon HD 4770 512 MB - Windows 7 Home Premium 32Bit - XProfan X4

Frank
Abbing

[quote:f7f18350e4]Mir fiel keine für den Anwender einfachere Möglichkeit ein, zwei Parameter zurückzugeben. (Die Implementierung war nicht ohne, zumal ich natürlich abtesten wollte, daß da wirklich passende Variablen stehen.) Die andere Möglichkeit wäre gewesen, zwei neu zu schaffende Systemvariablen zu füllen. (So wie %bmpX und %bmpY nach Befehlen, die eine Bitmap laden.) Was ist besser?[/quote:f7f18350e4]
So wie es ist, ist es gut.
Ich schliesse mich aber auch der Meinung an, das in der Testphase eingeführte Funktionen noch verbessert werden sollten, wenn das ihr Handling vereinfacht.

Uwe
''Pascal''
Niemeier

Hallo Leute, hallo Roland!

Klar kann man nicht alle Möglichkeiten berücksichtigen. Sonst könnte man ja gleich bei der nativen API bleiben. Und es wird immer mal jemand dies oder jenes Extra brauchen, das nicht implementiert ist.
Das ist auch ganz gut so, sonst gäbe es für Bastler wie mich ja nichts mehr zu tun

[quote:032606ccb6]Was den Ursprung der Objekte betrifft, habe ich lange mit mir gerungen.
Ich bin davon ausgegangen, daß OpenGL in erster Linie für Spiele eingesetzt werden wird und da liegen die Objekte nun mal alle auf dem Erdboden (der Nulllinie) und ragen nicht zur Hälfte in diesen hinein.[/quote:032606ccb6]
Stimmt, so hab ich das garnicht gesehen; das macht Sinn !

[quote:032606ccb6]Daß man Texturen auch aus Bitmaphandles und aus TGA-Dateien erzeugen kann, ist geplant. [/quote:032606ccb6]
Wenn man ein Handle verwenden kann, braucht man eigendlich keine direkte Dateiunterstützung mehr. Man kann doch bereits (fast) jeden beliebigen Bildtyp laden. Und notfalls gibts ja die GDIPlus.dll und iFs PCU.

[quote:032606ccb6]Wieso brauchst Du bei Listen und Texturen unbedingt Arrays?
Du kannst doch Listen- oder Texturnummer jeder beliebigen Integervariablen zuweisen.[/quote:032606ccb6]
Aber wenn man mehrere Objekte in einer Schleife erzeugen, positionieren, abfragen usw. möchte? Das ginge dann doch nicht ohne Arrays. Da wäre zB. ein Zähler als Vorgabe für den Namen sinnvoll.
Nicht zu vergessen die Möglichkeit, eine Liste gezielt durch Überschreiben zu ersetzen.

[quote:032606ccb6]...ogl(2D,...)
Mir fiel keine für den Anwender einfachere Möglichkeit ein, zwei Parameter zurückzugeben.[/quote:032606ccb6]
Eine Möglichkeit wäre, das der Anwender einen Bereich vorgeben muss, den die Funktion dann füllt. Korrektes Auslesen läge dann beim Anwender.

Was IMHO noch mit rein sollte: Eine Skalierfunktion und Nutzung/Manipulation der Lichter.
Dafür wird bestimmt Bedarf bestehen.

Und natürlich eine Funktion, die den letzten ogl-Fehler als String ausgibt
(oder eine entsprechende Systemvariable und eine Liste zum Nachschlagen)

SeeYou
Pascal

RGH

[quote:2773ab08cb=Frank Abbing]
[quote:2773ab08cb]Daß man Texturen auch aus Bitmaphandles und aus TGA-Dateien erzeugen kann, ist geplant. Ob es aber schon in XProfan 10 realisiert wird, weiß ich noch nicht.[/quote:2773ab08cb]
Ich plädiere stark dafür

Da die 10er Version erst für Ende Herbst angekündigt ist, hättest du noch viel Zeit, das unterzubringen.

[/quote:2773ab08cb]
Ab der nächsten Subscriptionsversion gibt es die Funktion:
n& = oGL(GetTextureBMP, hBild&, Filter%)
hBild& ist das Handle einer Bitmap.

Gruß
Roland

Intel Duo E8400 3,0 GHz / 4 GB RAM / 1000 GB HDD - ATI Radeon HD 4770 512 MB - Windows 7 Home Premium 32Bit - XProfan X4