| |
| |
|
| - Seite 1 - |
|
Uwe
''Pascal''
Niemeier | Hallo Leute!
Ich hatte endlich Gelegenheit, die OpenGL-Funktionen zu testen und will mal ein paar Kommentare dazu absondern.
Es sind auch ein paar Vorschläge und etwas Kritik dabei. Ich hoffe, vor allem letzteres wird mit Wohlwollen aufgenommen 
Allgemein:
Mir ist aufgefallen,dass einige profan-eigene ogl-Funktionen nicht ganz mit den
gleichnamigen Original-APIs identisch sind. Das macht es schwer für Leute, die irgendwelche Demos übersetzen wollen oder in anderen Programmiersprachen schon mit oGL gearbeitet haben. Vielleicht lässt sich da noch was nachbessern, oder es muss in der späteren Hilfe entsprechend nachdrücklich auf solche Abweichungen hingewiesen werden.
Hier ein paar Details:
ogl(Irgendein Objekt,...)
Bei Übersetzung meiner Ballerspiel-Demos habe ich 1 Stunde gegrübelt, warum meine Asteroiden so komisch durch die Gegend eiern, bis ich die Fussnote in der OpenGL.txt gefunden habe: Bei Erzeugung eines Objektes per glu-API liegt der Körpermittelpunkt im Nullpunkt des Koordinatensystems, bei RGH der unterste Punkt des Körpers
Will man z.B. eine Kugel um ihren Mittelpunkt rotieren lassen, muss man sie also erst um ihren Radius nach unten verschieben. Ziemlich lästig...
ogl(CLEAR)
Entspricht nicht der ogl-API glClear; zusätzlich zum Löschen der Grafik wird auch das
Koordinatensystem zurückgesetzt (Ist da noch ein glLoadIdentity eingebaut?)
Die Folge ist, dass in einer Schleife mit CLEAR keine relativen Transformationen möglich
sind, nur absolute.
Beispiel RGH-ogl:
[box:03f4aca031]window 50,50-500,500
ogl(Init,%hwnd,0,0,0,1)
declare R%
while 1
case R%=360:R%=0
inc R%
ogl(clear)
ogl(move,0,0,-3)
ogl(rotate,0,R%,0)
ogL(sphere,0.5,4,2)
ogl(show)
endwhile[/box:03f4aca031]
Beispiel Standart-ogl:
[box:03f4aca031]window 50,50-500,500
oGL(Init,%hwnd,0,0,0,1)
ogl(move,0,0,-3)
while 1
ogl(glClear,~GL_COLOR_BUFFER_BIT | ~GL_DEPTH_BUFFER_BIT)
ogl(rotate,0,1,0)
ogL(sphere,0.5,4,2)
ogl(show)
endwhile[/box:03f4aca031]
Im 2. Beispiel wird der ogl-Bildschirm zwar gelöscht, die Matrix aber nicht zurückgesetzt, sodass ROTATE bei jedem Durchlauf auf die bereits gedrehte Szene angewendet wird.
Vorschlag: CLEAR sollte sich nur auf das Löschen des Bildes beschränken, dafür könnte man glLoadIdentity kapseln, z.B. als ogl(RESETCOORD) oder so.
ogl(ORIGIN,...)
Besteht anscheinend aus glLoadIdentity + glTranslate (MOVE), setzt also die Koordinaten auf absolute Werte. Könnte entfallen, wenn es ogl(RESETCOORD) gäbe.
ogl(STARTLIST)
Gibt einen Integer-Namen für die DisplayList zurück. Das bedeutet aber, dass man bei mehreren DLs die jeweiligen Namen z.B. in einem Array ablegen muss, um volle Kontrolle zu haben.
Besser wäre, den Namen selbst vorzugeben, so wie in der Original-API. So wüsste man immer, wie welche DL anzusprechen wäre, ausserdem könnte man eine bereits angelegt DL überschreiben.
Wie wäre ein optionaler Parameter iName% ?
Ausserdem fehlt noch eine Kapselung von glDeleteList.
oGL(LOADTEXTUREBMP,...)
Hier gilt das Gleiche wie für STARTLIST; der IntegerName wird von Profan vorgegeben, könnte aber auch vom User zugeteilt werden. Arrays könnten entfallen. Texturen könnten z.B. in einer Schleife angelegt werden und wären dann über ihre Nummerierung zu erreichen.
BTW: Eine Alternative, um bmp-Handles zu verarbeiten, wäre auch nicht schlecht 
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!
ogl(TESTMOUSE,...) & ogl(TESTXY,...)
Wenn man bei letzterem die Mausposition übergibt, kann man sich ersteres sparen...
ogl(STARTTEST,...) & ogl(ENDTEST)
Praktischer wäre, wenn man hier ein Rechteck vorgeben könnte wie in der Original-API. Dann entspräche das Ganze praktisch der alten @Mouse-Funktion. Wer einen Punkt testen will, kann ja Start- und Endpunkte des Rechtecks übereinanderlegen.
Soviel fürs erste.
Bin auf Kommentare gespannt (vor allem von Roland)
PS: Werde demnächst noch ein paar angepasste Demos posten.
SeeYou
Pascal |
|
| |
| |
| |
|
| |
| |
| - Seite 2 - |
|
|
Uwe
''Pascal''
Niemeier | Hallo Leute!
Ich habe da etwas gefunden, was möglicherweise ein Bug sein könnte:
KompilierenMarkierenSeparieren!
window 50,50-500,500
ogl("init",%hwnd,0,0,0,1)
while 1
sleep 50
ogl("clear")
ogl("push")
ogl("move",2,1,-7)
ogl("sphere",1,10,10)
ogl("pop")
ogl("show")
endwhile
Hier wird ein Ogl-Fenster mit einem Ball drin erzeugt. Wenn ich dieses Fenster in den Hintergrund schicke (z.B. indem ich ins dahinterstehende Editorfenster klicke), bekomme ich eine heftige Fehlermeldung.
OK, der Code als solcher ist zwar ziemlich sinnlos, aber deshalb gleich ein Gleitkomma-Fehler?
Oder habe ich was übersehen?
SeeYou
Pascal |
|
| |
| |
| |
|
|
 | | Läuft bei Dir das mitgelieferte Demo lesson13a.prf ohne Absturz? |
|
| |
| |
| |
|
|
Frank
Abbing | | Pascal, setze das -7 mal in Klammern, dann müsste es gehen. Habe bei meinen Tests noch einige dieser Stolperstellen entdeckt und Roland auch gemeldet. Bin sicher, dass er sie bald korrigiert hat. |
|
| |
| |
| |
|
|
RGH | [quote:60ba900c81=Uwe Pascal Niemeier]
ogl(STARTLIST)
Gibt einen Integer-Namen für die DisplayList zurück. Das bedeutet aber, dass man bei mehreren DLs die jeweiligen Namen z.B. in einem Array ablegen muss, um volle Kontrolle zu haben.
Besser wäre, den Namen selbst vorzugeben, so wie in der Original-API. So wüsste man immer, wie welche DL anzusprechen wäre, ausserdem könnte man eine bereits angelegt DL überschreiben.
Wie wäre ein optionaler Parameter iName% ?[/quote:60ba900c81]
Dein Spieledemo mit den Asteroiden hat mich überzeugt, daß das doch sinnvoll ist. Ab der nächsten Subscriptionsversion (der 11.) gibt es diesem optionalen Parameter. Ohne diesen Parameter wird mit glGenList die nächste freie Listennummer ermittelt, mit Parameter wird eben diese Nummer benutzt.
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 | 22.05.2006 ▲ |
|
| |
|
|
RGH | [quote:47f614c4dd=Uwe Pascal Niemeier]Wenn ich dieses Fenster in den Hintergrund schicke (z.B. indem ich ins dahinterstehende Editorfenster klicke), bekomme ich eine heftige Fehlermeldung.
OK, der Code als solcher ist zwar ziemlich sinnlos, aber deshalb gleich ein Gleitkomma-Fehler?
Oder habe ich was übersehen?[/quote:47f614c4dd]
Hm, bei mir läuft es völlig problemlos.
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 | 22.05.2006 ▲ |
|
| |
|
|
RGH | [quote:b4209c4237=Uwe Pascal Niemeier][quote:b4209c4237]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:b4209c4237]
Stimmt, so hab ich das garnicht gesehen; das macht Sinn !
Was IMHO noch mit rein sollte: Eine Skalierfunktion[/quote:b4209c4237]
Nach längerem Hin und Her habe ich mich jetzt entschieden beides zu ermöglichen. Mit oGL(PosMode, N%) kann man den Modus einstellen. Im Defaultmodus 0 ist der Ursprung der Objekte bodenständig ausgerichtet und im Modus 1 ist es der Mittelpunkt des Objektes.
Und die Funktion oGL(Scale, N!) zum Verkleinern und Vergrößern von Objekten wird es auch geben.
Ich denke mal, in der nächsten oder übernächsten Subscriptionsversion wird es soweit sein.
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 | 23.05.2006 ▲ |
|
| |
|
|
RGH | [quote:b46363596f=Uwe Pascal Niemeier]Und natürlich eine Funktion, die den letzten ogl-Fehler als String ausgibt
(oder eine entsprechende Systemvariable und eine Liste zum Nachschlagen)[/quote:b46363596f]
Aber nicht doch!  Händisches Nachschlagen im 21. Jahrhundert? 
Es gibt kein spezielles Fehlerhandling für in der OpenGL-API auftretende Fehler, sondern Windows nutzt hier das Windowseigene Fehlerhandling. Den letzten aufgetretenen Fehler ermittelt die API-Funktion GetLastError() und über FormatMessage(...) kann man den passenden Fehlertext ermitteln. Diese beiden Funktionalitäten habe ich nun als Systemvariablen in XProfan integriert:
%LastError  : Der letzte aufgetretene Windowsfehler. 0 = Kein Fehler. Der Wert der Systemvariablen ändert sich nur, wenn ein weiterer Fehler auftritt. Wichtiger Hinweis: Ein aufgetretener Windowsfehler sagt nicht zwingend aus, daß ein XProfan-Fehler aufgetreten ist. Es gibt durchaus auch Windowsfehler, die XProfan bewußt ignoriert.
$LastError : Der letzte aufgetretene Windowsfehler in Textform.
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 | 23.05.2006 ▲ |
|
| |
|
|
Uwe
''Pascal''
Niemeier | Hallo Roland!
[quote:a770c6eb53]Es gibt kein spezielles Fehlerhandling für in der OpenGL-API auftretende Fehler, sondern Windows nutzt hier das Windowseigene Fehlerhandling. [/quote:a770c6eb53]
Bist du da sicher??
KompilierenMarkierenSeparieren!
window 10,10-700,500
proc glError?--------------------------------
parameters a$
declare a&,b&
a&=ogl("glGetError")
b&=ogl("gluErrorString",a&)
messagebox(str$(a&)+": "+string$(b&,0),a$,0)
endproc--------------------------------------
ogl("init",%hwnd,0,0,0,1)
ogl("glClear",0)
glError? "Test 1"
ogl("glClear",-1)
glError? "Test 2"
SeeYou
Pascal |
|
| |
| |
| |
|
|
Uwe
''Pascal''
Niemeier | Hallo Leute!
[quote:ed5606461a]Uwe Pascal Niemeier: Wenn ich dieses Fenster in den Hintergrund schicke (z.B. indem ich ins dahinterstehende Editorfenster klicke), bekomme ich eine heftige Fehlermeldung.[/quote:ed5606461a]
Es scheint wohl vom OS bzw. von der Version der oGL-dlls abhängig zu sein...
Der Fehler tritt bei mir auf, wenn sich die Szene nach Anwendung von Push/Pop auf der Z-Achse am Nullpunkt befindet und dann angezeigt werden soll:
KompilierenMarkierenSeparieren!
window 50,50-500,500
ogl("init",%hwnd,0,0,0,1)
while 1
sleep 50
ogl("clear")
ogl("origin",0,0,0)--------Fehler!
ogl("origin",0,0,0.0001)--Klappt!
ogl("push")
ogl("move",2,1,-5)
ogl("sphere",1,5,5)
ogl("pop")
ogl("move",0,0,0.0001)--Klappt auch!
ogl("show")
endwhile
Ein einfacher Workaround wäre also, irgendwo ausserhalb von Push/Pop z.B. ein ogl(move,0,0,0.0001) einzufügen.
Meine dlls:
opengl32.dll: Version 5.1.2600.2180 vom 10.08.2004 ; 697 KB
glu32.dll : Version 5.1.2600.2180 vom 10.08.2004 ; 120 KB
BTW: Auch einige meiner oGL-Api-Demos machen unter XP nicht das, was sie sollten 
SeeYou
Pascal |
|
| |
| |
| |
|
|
RGH | [quote:2aa2723ce6=Uwe Pascal Niemeier]Hallo Roland!
[quote:2aa2723ce6]Es gibt kein spezielles Fehlerhandling für in der OpenGL-API auftretende Fehler, sondern Windows nutzt hier das Windowseigene Fehlerhandling. [/quote:2aa2723ce6]
Bist du da sicher??[/quote:2aa2723ce6]
 Da hatte ich offensichtlich was übersehen. Aber getLastError() klappt auch bei bei oGL-Fehlern. Offensichtlich nutzt OpenGL auch das windowseigene Fehlerhandling. Aber umso besser, dann gibt es nun eine weitere Systemvariable und eine neue oGL-Funktion:
e% = %oGLError und e$ = oGL(ErrorString, e%)
(Die Sache mit %LastError und $LastError kann ich dann wieder einmotten.)
Danke!
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 | 24.05.2006 ▲ |
|
| |
|
|
Michael
Wodrich | Einmotten???
Wenn man so einfach in Profan einen Windowsfehler serviert bekommt, dann wird es vielleicht auch häufiger benutzt.
Ich würde diese LastError-Geschichte drin lassen. Gehört ja zur Allgemeinen Fehlerbehandlung in Windows.
Und es wird ja immer jemanden geben, der nicht über Profan sondern direkt über die Windows-API am System dreht - da braucht man die Fehlerabfrage ja.
Schöne Grüße
Michael Wodrich |
|
| |
| Programmieren, das spannendste Detektivspiel der Welt. | 24.05.2006 ▲ |
|
| |
|
|
Frank
Abbing | | Sehe ich ähnlich. Ich würds drinlassen... |
|
| |
| |
| |
|
(766)
Deutsch
English
Français
Español
Italia