Diskussion:Low/High-Level: Unterschied zwischen den Versionen
| Zeile 2: | Zeile 2: | ||
Oder um es mal an einem Beispiel anzubringen. Im Vergleich glBitmap.pas und die Textures.pas. Die Textures ist eindeutig Lowlevel. Eine Methode zum Laden von Texturen. Die glBitmap ist dort eindeutig Highlevel. Die Textures mag an einigen Stellen schneller sein, dafür '''fehlt''' ihr aber Flexibilität. Speiziell beim Laden und der Handhabung der Texturen. Sie kann nur das was wofür sie geschrieben wurden. Datei rein und TExturid raus. Änderungen können recht leicht nachgepflegt werden. Das ist bei der glBitmap nicht ganz so einfach. Da muss man schon aufpassen, dass es in das System passt. Ich finde Lowlevel ist eher unflexibel, da es nur auf bestimmte Aufgabengebiete zugeschnitten wird wärend Highlevel nun mal viele Verwendungszwecke zur Verfügung stellt. Highlevel geht eher abstrakt an die Aufgaben herran. | Oder um es mal an einem Beispiel anzubringen. Im Vergleich glBitmap.pas und die Textures.pas. Die Textures ist eindeutig Lowlevel. Eine Methode zum Laden von Texturen. Die glBitmap ist dort eindeutig Highlevel. Die Textures mag an einigen Stellen schneller sein, dafür '''fehlt''' ihr aber Flexibilität. Speiziell beim Laden und der Handhabung der Texturen. Sie kann nur das was wofür sie geschrieben wurden. Datei rein und TExturid raus. Änderungen können recht leicht nachgepflegt werden. Das ist bei der glBitmap nicht ganz so einfach. Da muss man schon aufpassen, dass es in das System passt. Ich finde Lowlevel ist eher unflexibel, da es nur auf bestimmte Aufgabengebiete zugeschnitten wird wärend Highlevel nun mal viele Verwendungszwecke zur Verfügung stellt. Highlevel geht eher abstrakt an die Aufgaben herran. | ||
| + | |||
| + | Das Beispiel ist nicht von mir sondern von einen der Kernentwickler von der Vision Engine. | ||
| + | Ich war vor wenigen Tagen zu einem Vortrag in der Games Academy Berlin, wo einer der 5 Engineprogrammierer ein 2h Vortrag hielt und dieses Beispiel mit einbrachte. Darum habe ich das bedenkenlos übernommen gehabt und man sieht auch den unterschied das bei dem Hi-Level API Beispiel nur ein Licht aktiviert werden muss und Bumpmapping, Schatten und so weiter automatisch mit gehandelt werden. Im Low-Level API muss man sich um jedes einzeln kümmern, also Bumpmapping, Schatte, Lichtquelle und so weiter. | ||
| + | Ob die einzelnen Befehle wie glenable(GLLight0) und so weiter selber aufrufe oder ich es über Licht.enable:=... mache ändert nichts ander der Tatsache das ich für jede einzelne Lichtfunktion die OpenGL bietet immer noch eine in der Licht klasse habe. | ||
| + | --[[Benutzer:TAK2004|TAK2004]] 09:51, 8. Jul 2005 (CEST) | ||
Version vom 8. Juli 2005, 08:51 Uhr
Ich finde die Beispiele ein wenig unpassend. Laut der Definition wäre der Code für Highlevel eher für Lowlevel. Wobei ich persönlich beide Codes nach Highlevel einordnen würde, da beide Methoden nun mal Klassen benutzen. Bei dem "Highlevel" Beispiel befinden sich nur alle Parameter im Konstruktor und bei Lowlevel hat man sich sogar die Mühe gemacht properties dafür zu implementieren!?
Oder um es mal an einem Beispiel anzubringen. Im Vergleich glBitmap.pas und die Textures.pas. Die Textures ist eindeutig Lowlevel. Eine Methode zum Laden von Texturen. Die glBitmap ist dort eindeutig Highlevel. Die Textures mag an einigen Stellen schneller sein, dafür fehlt ihr aber Flexibilität. Speiziell beim Laden und der Handhabung der Texturen. Sie kann nur das was wofür sie geschrieben wurden. Datei rein und TExturid raus. Änderungen können recht leicht nachgepflegt werden. Das ist bei der glBitmap nicht ganz so einfach. Da muss man schon aufpassen, dass es in das System passt. Ich finde Lowlevel ist eher unflexibel, da es nur auf bestimmte Aufgabengebiete zugeschnitten wird wärend Highlevel nun mal viele Verwendungszwecke zur Verfügung stellt. Highlevel geht eher abstrakt an die Aufgaben herran.
Das Beispiel ist nicht von mir sondern von einen der Kernentwickler von der Vision Engine. Ich war vor wenigen Tagen zu einem Vortrag in der Games Academy Berlin, wo einer der 5 Engineprogrammierer ein 2h Vortrag hielt und dieses Beispiel mit einbrachte. Darum habe ich das bedenkenlos übernommen gehabt und man sieht auch den unterschied das bei dem Hi-Level API Beispiel nur ein Licht aktiviert werden muss und Bumpmapping, Schatten und so weiter automatisch mit gehandelt werden. Im Low-Level API muss man sich um jedes einzeln kümmern, also Bumpmapping, Schatte, Lichtquelle und so weiter. Ob die einzelnen Befehle wie glenable(GLLight0) und so weiter selber aufrufe oder ich es über Licht.enable:=... mache ändert nichts ander der Tatsache das ich für jede einzelne Lichtfunktion die OpenGL bietet immer noch eine in der Licht klasse habe. --TAK2004 09:51, 8. Jul 2005 (CEST)
