Tja der titel sagts eigentlich schon. Gibs für OGL auch ne Header für die (unglaublich unbekannte und schrecklich begrenzte) Sprache Oberon?

Da stellt sich die Frage welchen Oberon Compiler du benutzt und auf welchem system. Auf native Oberon wirds wohl nix werden, weil das System IMHO bloß 2D Grafikkarten kennt und alle anderen auch nur so angesprochen werden. Bei anderen Systemen kanns das durchaus geben. Ich vermute allerdings, daß du dann nicht umhin kommen wirst, dir deine Header selber zu schreiben (keine Angst das ist nicht allzu kompliziert und das meiste lässt sich leihct automatisieren).
Warum sollte Oberon eigentlich beschränkt sein? Es kann eigentlich sogar ziemlich viel und deutlich mehr als Ur-Pascal. Und unbekannt ist sie auch nicht, allerdings handelt es sich halt auch nicht um eine 0815 überall eingesetzt sprache - ist eine sprache für die man prima compiler selbst schreiben kann und die im Uni-Dienst durchaus an der ein oder anderen Stelle ihre dienste verrichtet... Naja, aber das ist schon etwas offtopic, aber du hast es ja in deinem eigenen thread angesprochen.

Naja wenn ich mir den Delphi OGLHeader ansehe, muss ich doch sagen, dass es die Arbeit, die ich in meine Infoprojektarbeit investieren wollen würde, doch etwas übersteigen würde. An sich würde 2D auch reichen, wenn 3D wirklich nicht geht.
Als Compiler für Oberon verwende ich POW.

Tja ich habe gerade mal selbst etwas gegoogled zu dem Thema und fand viiiiele Sachen, die mir mein (nun muss ich die Objekte tauschen) beschränkter Infolehrer bisher verschwiegen hat.
Ich haette schon damals skeptisch werden sollen, als er, um einen Mouseklick abzufangen, es nicht gebacken bekommen hat, die Procedure GetMouse in eine Whileschleife zu packen... (hach ich werd OT)

Naja er jedenfalls meinte immer, in Oberon würde OOP nicht gehen, einige Implementationen anderer Sprachen oder SPeicherformate ala XML etc. würden auch nicht gehen usw...
Zumindest weiss ich nun, dass Oberon OOP kann. Und da er mir verboten hat, meine Arbeit in Delphi zu schreiben, wenn gleich die Syntax beinahe völlig identisch ist (Ausnahmen zb: uses <> import; Array[..,..] <> Array(..,..) usw), werde ich nun zwar Oberon nehmen, aber alles OOP machen, denn das kann der gute nicht... und sowas nennt sich Infolehrer... Naja steht immernoch die Frage, ob man einen Header für Oberon bekommt. Wenn ein Header wirklich wenig arbeit ist, denn es ist wie gesagt nur eine Projektarbeit, für die andere auch ein nichtgrafisches Wer-wird-Millionär? mit statischer Fragenreihenfolge abgeben und 15 Punkte bekommen...

Naja schon im Vorraus mal danke

Versuch mal diese Suche. Scheint schon was zu geben.
http://www.google.de/search?hl=de&q=%22OpenGL+Binding%22+Oberon&btnG=Suche&meta=

_________________
Blog: kevin-fleischer.de und fbaingermany.com

Also wenn dich interessiert, was dir dein info lehrer sonst noch alles verheimlicht hat:
ftp://ftp.inf.ethz.ch/pub/software/Ober ... nEBNF.Text
Der schöne Text beschreibt wunderbar wie oberon definiert ist - besonders stutzig sollte einen das

machen... Records abgeleitet von BaseType sind schon was interessentes Wie man da genau mit programmiert weis ich allerdings nichtmehr. Irgendwie ist der richtige Einsatz von sternchen wichtig und die richtige implementation an der richtigen stelle. Aber meine Oberonerfahrungen sind schon recht alt - ungefähr aus der Zeit wo POW noch recht neu war und Windows 3.11 noch nicht obsolet. Wie gesehen wird POW auch schon länger nicht mehr weiterentwickelt - das trifft dummerweise auch auf den zugehörigen Compiler zu. Also ich denke mit dem ein oder anderen Problem beim EInsatz von OpenGL ist wohl zu rechnen... Hachja das waren Zeiten wo man zum ersten mal mit Garbage Collection gearbeitet hat und dann jahre lang nicht mehr... Hach ja
Also wenn 3D nicht wirklich notwenig ist würde ich mir diesen Stress an deiner Stelle nicht geben und mich hier auf das nötige beschränken - ist ja nur für die schule Notfalls ist auch 2D Liniengrafik in 3D ausreichend - sind dazu nicht sogar einfache Beispiele dabei gewesen? Ich kann mich noch an sich drehende boxen aus den Beispielen erinnern. Evtl. kann man dort etwas Mathematik klauen und sich das leben leichter machen? Es selbst zu schreiben ist zwar auch nicht schwer aber in der Schule kennt man dazu meist die Hilfsmittel noch nicht. Apropos: XML.. Geht sicher auch wunderbar man muss ich nur einen passenden Parser dazu schreiben. Ist nicht wirklich schwer, zumal du ja jetzt weist, daß du dazu Objekte anlegen kannst. Aber bei einfachen Projekten langen meist auch einfach strukturierte Textdateien - ist vielleicht der geringere Aufwandt?

ja wie ich per linedraw und sonne faxen male, weiss ich schon, aber zb texturen etc gehen mit oberon nicht, deswegen wollt ich wissen ob ogl geht. naja muss ich mir eben irgendwas einfaches einfallen lassen... ka habe ja nochn halbes jahr zeit

Gar nicht mal schlecht das Oberon. Gibt's auch für .Net habe ich gesehen. Was mich allerdings stört ist, dass man den Funktionsnamen nochmal nach dem end der Funktion schreiben muss.

Das mit den Funktionsnamen ist eigentlich gar nicht so dumm - Oberon ist immerhin schon so alt, daß es aus einer Zeit stammt, wo man rein mit Texteditoren gearbeitet hat, die üblicherweise kein Automatisches einrücken beherrschten und wenn man sich mal tiefer eingeschachtelt hat und eine ganze Reihe Ends am Stück auftauchen - was ja gelegentlich passiert - und dann eines Fehlt oder zuviel ist, dann hat man häufig das Problem, daß der Compiler an einer Stelle schreit, die nicht unbedingt mit dem zusammenpasst, wo der Fehler tatsächlich ist und dann oft auch mit sehr seltsamen Fehlermeldungen - stolpert er aber vorher über eine Funktionsend ist ganz klar, daß irgendwo ein entsprechendes End fehlt und die Fehlermeldung ist auch nicht weit entfernt vom tatsächlichen Fehler. Also ich finde diese Einrichtung gar nicht so schlecht und man hat sich das sehr schnell angewöhnt: Ich glaube nicht, daß das ein Grund wäre dieses Sprache abzulehnen, sorgt es doch dafür daß selbst völlig unbelehrbare nicht Einrücker gezwungen sind gelegentlich anzumerken wo denn eine Funktion zu Ende ist und wirklich aufhalten tut eines das nicht - zumal ich das in meinen Pascal Zeiten ja acuh häufig am Ende von Funktionen imemr als Kommentar angemerkt habe. Also ich würde diese Eigenschaft als Pro statt als Con ansehen.