Ich hätte mein Changelog weiterführen sollen, jetzt ist es ungemein schwierig zu dokumentieren was neu dazu gekommen ist und was sich geändert hat. Nunja, es ist wie es ist und das Changelog wird dann halt mit ganz vielen "added" neu begonnen.

Wie versprochen habe ich heute den "Direct-Wrapper" weiter erweitert und das Example sieht derzeit so aus:

BlitzMax: [AUSKLAPPEN] [EINKLAPPEN]

SuperStrict

Framework sedm.bo3d

Local r:Root = Root.Create()

If r.showConfigDialog()
	Local win:RenderWindow			= r.initialise(True, "BlitzOgre3D")
	Local scene:SceneManager		= r.createSceneManager()
	Local res:ResourceGroupManager	= New ResourceGroupManager
	Local cam:Camera				= scene.createCamera()
	Local vport:Viewport			= win.addViewPort(cam)
	
	Local inp:OIS					= OIS.Init(win)
		
	vport.setBackgroundColour(0.3, 0.5, 0.9)
	vport.setCamera(cam)
	
	Local w:Int = vport.getActualWidth()
	Local h:Int = vport.getActualHeight()
	
	cam.setAspectRatio(w / h)
	cam.SetPosition(0.0, 0.0, 5.0)
	
	res.addResourceLocation("media", "FileSystem", "myFiles")
	res.initialiseResourceGroup("myFiles")
	
	Local box:Entity				= scene.createEntity("", "box.mesh", "myFiles")
	Local rsn:SceneNode			= scene.getRootSceneNode()
	Local cs:SceneNode				= rsn.createChildSceneNode()
		
	cs.attachObject(box)
	
	Repeat
		r.messagePump()
		
		inp.captureKeyboard()
		inp.captureMouse()
		
		If inp.isKeyDown(KC_ESCAPE) Then Exit
		If inp.isMouseDown(MB_LEFT) Then Exit
		
		r.renderOneFrame()
	Forever
	
	r.Shutdown()
End If

End

Ja, das ist ne Menge Holz ... aber das soll ja nicht so bleiben. Wie man schon an der Initialisierung des InputManagers sieht läuft nicht alles exakt so wie in C/C++. Während man "drüben" den Mouse- und KeyboardHandler einzeln initialisiert und dann auch noch EventListener erstellt, mache ich das in BlitzMax in einem Rutsch im Objekt "OIS". OIS muss ich verwenden weil ich keine Möglichkeit gefunden habe PolledInput oder BMax Events auf das Ogre3d Fenster zu "biegen". Aber hin Hinblick auf die Blitz3D/BlitzPlus Version ist das auch nicht so schlimm, denn dort stünde ich vor demselben Problem.

Ich denke dass ich noch etwa zwei Tage benötigen werde um auf den Stand der 0.49.6 zu kommen und werde dann damit beginnen das "Highlevel API" zu definieren so dass dann irgendwann das Example wieder so aussieht wie ihr es kennt.

Nee, nicht wirklich ne Pause ... es geht im Stechschritt voran. Was sich gerade ändert ist die Art und Weise wie ich das Ganze wrappe. Während ich bis neulich noch kreativ in C/C++ herum gebastelt und mich dabei immer mehr in Sachen verzettelt habe die erreichen sollten dass soviel von Ogre3D wie möglich nutzbar wird, gehe ich nun einen anderen Weg:
Ich wrappe die Methoden der Ogre-Klassen direkt und bastele das HighLevel Interface in BlitzMax/Blitz3D dann selbst zusammen. So kann man direkt auf die Methoden der Ogre3D Engine zugreifen, kann auch mal in die API Docs schauen wenn etwas unklar ist oder sich einfach mit dem begnügen was die HighLevel API so hergibt.

Ich habe mal die HotDocs generierten Docs hochgeladen. Dort kann man (bitte die Funktionen mit dem Präfix "o_" ignorieren, die sind und werden nicht dokumentiert) schauen wie das Ganze mal aussehen soll.

Alle Klassen die Ogre3D besitzt werden in gleichnamige BlitzMax Types übersetzt. Die meisten Methoden dieser Klassen haben senselben Namen wie ihr Ogre3D Gegenstück. "Die meisten" deshalb weil BlitzMax viele Namen für sich in Besitz hält und diese ums verrecken nicht hergeben will. Aber das betrifft nur einige wenige Namen (NameSpaces würden BlitzMax ganz gut stehen).

Das Example (das mangels OIS derzeit exakt eine Sekunde läuft) sieht im Source derzeit so aus:
Code: [AUSKLAPPEN] [EINKLAPPEN]
Wie man sieht ist "Graphics3D" komplett entblättert und das ist gut so, denn Graphics3D soll direkt in BlitzMax/Blitz3D implementiert sein und nicht wie bisher in C. Das was man da oben sieht kann man auch aus normalen Ogre3D Tutorials ziehen, d.h. dass man auch die normalen Ogre3D Docs lesen kann um mit diesem Mod klarzukommen (wenn man denn auf diesem LowLevel Niveau arbeiten will).

Desweiteren bin ich von "GetProcAddress()" auf einen banalen "Extern" Block umgestiegen, das vereinfacht es später die Sache auf Linux und MacOS zu portieren.

Einige Dinge sind aber auch ganz anders als in Ogre3D. So erwartet die Methode Ogre::Root::createRenderWindow() eine Map mit diversen Optionen. Diese Map liesse sich zwar in BMax durch TMap simulieren aber nicht an eine C-Funktion übertragen. Deshalb habe ich entschieden dass BMax einen Pipe-separierten String schickt und C sich das dann selbst wieder auseinander pflückt.

Für alle die nicht wissen was ein(e) "Pipe" ist:
Code: [AUSKLAPPEN] [EINKLAPPEN]

Noch ein Vorteil dieser Vorgehensweise (was das LowLevel API betrifft): Ich kann die vorhandene Dokumentation fast 1:1 übernehmen wie man hier ganz gut sehen kann.

Jetzt geht es darum die API auf den Stand von 0.49.6 zu bringen und dann die Funktionen zu implementieren die auch wieder ein Graphics3D() etc. möglich machen.

stay tuned ...

Da sich mit dieser Version hauptsächlich Bugfixes einschleichen habe ich nur auf 0.49.5 erhöht. Die Klasse TOverlayImage habe ich wieder rausgeschmissen und stattdessen der Klasse TPanel ein paar neue Methoden beschert. So muss man zwar drei Schritte statt einem durchführen um ein Image als Overlay zu bekommen, aber so ist das Ganze ein wenig konsistenter geworden. Vielleicht bastle ich ja noch eine Methode die das wieder auf einen Methoden-Aufruf eindampft.
Die Overlay-Images müssen in der Reigenfolge erzeugt werden in der sie angezeigt werden sollen. Soll also der Mauszeiger über allem schweben muss er zuletzt erstellt werden, soll er aber hinter dem Logo erscheinen muss das Logo nach dem Mauszeiger erzeugt werden etc.

Eventuell habe ich auch den Bug behoben dass einigen ein MAV um die Ohren geflogen ist. Ich habe einfach mal geraten dass es an Texturen lag die nicht den Konventionen entsprechen.

Changelog:
Code: [AUSKLAPPEN] [EINKLAPPEN]

Um den Vorteil der neuen Vorgehensweise zu zeigen habe ich einen Mauszeiger eingebaut der eigentlich nur ein Panel ist:

Code: [AUSKLAPPEN] [EINKLAPPEN]



>> Download BlitzOgre3D Demo v0.49.5 (ca. 235kb) <<

Beachte: um die Demo in diesem Archiv zu starten musst Du zuerst 0.48 herunterladen, diese mit 0.49 überschreiben und dann 0.49.5 drüber bügeln! Wer mir bis hierher gefolgt ist und schon 0.49 auf der Platte hat, der muss natürlich nur 0.49.5 drüber kopieren.

have fun!

EDIT
Ich habe mal das Modul hochgeladen.
>> Download sedm.mod\blitzogre3d.mod (ca. 870kb) <<
/EDIT

Die hier propagierte Version 0.49 bietet nur marginale Veränderungen die mich dennoch einige Stunden gekostet haben



Zunächst mal das Changelog:
Code: [AUSKLAPPEN] [EINKLAPPEN]

Da ich hier im Büro nicht in der Lage bin die beschriebenen Fehler zu reproduzieren und Madame zuhause auf ihrem Rechner nichts installiert hat was mich befähigen würde Fehler auszumerzen, habe ich folgendes getan: Das Executable im nachfolgenden Päckchen öffnet nach dem Start eine Konsole und schreibt da ziemlich viel Krimskram rein, fast alles was auch die bo3d.log beinhaltet. Diejenigen bei denen es nicht funktioniert möchte ich bitten mir den Inhalt der Konsole in die Comments zu posten, so kommen wir dem Fehler schneller auf die Spur.

>> Download BlitzOgre3D Demo v0.49 (ca. 220kb) <<

Beachte: Dieses Archiv beinhaltet nur die Änderungen gegenüber der v0.48. Das heißt dass der Inhalt des Archives über den der Version 0.48 kopiert werden muss!

Nebenbei habe ich noch den Bug beseitigt dass das Logo nicht bei jedem an der selbem Stelle saß ... mit v0.49 sollte es bei jedem, egal in welcher Auflösung, rechts unten hocken.

BlitzOgre3D v0.48



Wie man sehen kann habe ich auf die Husche noch Schatten eingebaut (leider funktionieren derzeit nur die Stencilbuffer Types, warum das so ist muss ich noch ergründen) und man kann deutlich erkennen dass ich Kisten mag

Das Overlay-Image wird aus einer Kombination von Overlay- und Material-Script geladen. Im Folgenden mal die beiden Scripts die erforderlich sind um das Image zu definieren:

Das Overlay-Script:
Code: [AUSKLAPPEN] [EINKLAPPEN]

Das Material-Script:
Code: [AUSKLAPPEN] [EINKLAPPEN]

Der Aufruf in BlitzMax:
Code: [AUSKLAPPEN] [EINKLAPPEN]

Danach muss man sich nicht mehr um das Image kümmern, Ogre3D weiß allein dass man es permanent auf dem Screen haben will. Logischerweise ist das noch extrem ausbaufähig, gerade in Hinblick auf die Möglichkeit diese Dinge auch ohne Script "hard-zu-coden".

Noch das Changelog:
Code: [AUSKLAPPEN] [EINKLAPPEN]
Das komplette Changelog liegt dem nachfolgenden Päckchen bei.

>> Download BlitzOgre3D 0.48 Demo (ca. 5,4MB) <<

In diesem Paket befindet sich diesmal kein Source und kein Modul, das gibt es wieder wenn Blitz3D auf demselben Stand wie die BlitzMax Version ist. Ich habe auch ein wenig im DLL-Dschungel aufgeräumt. Wenn bei jemandem angesagt wird dass die cg.dll fehlt kann er sich diese hier herunterladen.

So ... dann baue ich mal weiter, liegen ja noch ein paar Mannjahre Arbeit vor mir

Ich konnte heute erfolgreich den OgreHead, dank Bullet, auf eine ziemlich hässliche Plane fallen lassen ... sobald TMesh.Copy() funktioniert gibbet eine neue Demo ... ich denke das wird morgen sein.

Changelog:
Code: [AUSKLAPPEN] [EINKLAPPEN]

Nur damit niemand denkt hier passiert nix mehr, poste ich mal eben das Changelog.

Code: [AUSKLAPPEN] [EINKLAPPEN]

Morgen habe ich Bullet soweit durchgeschliffen dass man Objekte rumschubsen kann ... stay tuned.

Heute habe ich an zwei Fronten gekämpft. Die eine befand sich auf der Texturseite und die andere auf dem Gebiet der sogenannten Compositoren. Letztere sind einfache Scripts die es einem Ogre3D Jünger gestatten den PostProcess Bereich relativ frei zu gestalten. Ich gedenke diverse Compositor-Scripts mit BlitzOgre3D direkt zu definieren so dass man diese Effekte mit einem einfachen Aufruf nutzen kann (bspw. "Depth of Field", "Bloom", "Motion Blur" etc.)

Mit der Einbindung von Compositors und den Texture-Befehlen gehe ich auch einen Schritt davon weg jede Blitz3D Funktion direkt in C++ zu wrappen. Stattdessen schleife ich die benötigten Ogre3D Methoden durch und klebe das dann in BMax und Blitz3D zusammen.

Texturen sind in ihrem Ogre3D Format etwas komplizierter zu erstellen als man das in Blitz3D mit seinem banalen "CreateTexture()" gewohnt ist, aber man hat auch wesentlich mehr Möglichkeiten. Nutzt man CreateTexture() nur mit den erforderlichen Parametern "width" und "height" bekommt man halt eine 32 Bit Textur mit den Eigenschaften RGB und Alpha. MIt Blick auf die Portierung des Wrappers auf Mac und Linux (BMax) habe ich aber auch alle anderen Formate durchgeschliffen. Diese kann man sich in der Datei "include/bo_texture_pixelformats.bmx" genauer ansehen. In dieser Datei sind auch noch diverse Möglichkeiten definiert die Textur des Vertrauens zu nutzen (bspw. als RenderTarget) sowie den Typ der Textur zu bestimmen, was für Shader nicht unbedingt uninteressant ist (1D, 2D, 3D, CubeMap Texure).

Compositors sind Ogre3D Scripts die ein klein wenig den GLSL oder HLSL Scripts vorgreifen und PostProcess Effekte ermöglichen. In BlitzOgre3D schleife ich alle Methoden durch die man benötigt um direkt die Dokumentation und/oder die Tutorials nachvollziehen zu können, fasse aber die wichtigsten Effekte in eigenen Methoden/Funktionen zusammen. Beispielsweise erledigt ein "SceneDOF(camera, near, far)" den kompletten Ablauf eines Depth of Field, wer möchte darf das dann aber direkt wie in Ogre3D selbst tun.

Mit dem nächsten Release (0.48) wird das dann möglich sein.

Es war ein Heidenaufwand so einfache (aber wichtige) Sachen wie EntityParent() zu realisieren. Das funktioniert jetzt und das ist gut so.

Derweil habe ich das gesamte BMax Konstrukt umgeschrieben da es dort einige Fallstricke gab die ich bei meinem ersten drauf los rennen garnicht bedacht hatte.
Alle Objekte stammen nun von TOgreObject ab und implementieren die meisten Funktionen selbst. In der letzten Version erbte noch jede Klasse von TEntity, was aber einige Fehler mit sich brachte die in C++ so nicht aufgetreten wären weil man dort eine Funktion komplett überschreiben kann, während BlitzMax da noch einige Anforderungen hat (bspw. die Anzahl der Parameter).

Eine weitere Änderung ist dass man den InputHandler nicht mehr selbst erstellen muss, dies passiert bereits beim Initialisieren der Engine. Ein Handle auf den InputHandler bekommt man per TOgre::getInputHandler().

Eine weitere Änderung ist dass viele Translations-Funktionen nun den zusätzlichen Parameter "relativeTo" besitzen mittels dem man definieren kann in welcher Relation die Translation passieren soll: Lokal, relativ zum Parent oder relativ zu den Weltkoordinaten (TS_LOCAL, TS_PARENT, TS_WORLD).

Als letztes ein, wie ich finde sehr wichtiges, Feature sei genannt dass die Engine nun auf StdOut Exceptions der Ogre3D Engine meldet. Noch nicht auf alle Funktionen aber ich bin bemüht in jede Funktion ein "try...catch()" einzubauen. Leider gibt es in Blitz3D keine Möglichkeit diese wichtigen Ausgaben abzufangen, vielleicht baue ich da noch was ein dass der Krimskram in eine Datei ausgegeben wird.

Das war es erstmal, ohne Release, für diesen Status-Bericht. Ansonsten will ich nur noch verkünden: Wenn die "Bird Demo" aus dem Blitz3D Paket ohne großartige Änderungen übersetzt werden kann, ist Ogre3D für Blitz3D in der Beta ... die BlitzMax Version ist dann ebensoweit, aber das Birdie-Demo wird nicht laufen

Wieder hat sich an der Oberfläche nur wenig verändert, das Meiste ist intern passiert. Das Blöde an Ogre3D ist, dass es so inkonsistent ist. Während ich für den einen Objekttyp direkt auf Methoden wie Pitch(), Yaw(), Roll() etc. zurück greifen kann, ist es bei anderen Objekten wesentlich komplizierter sie zu drehen obwohl alle betroffenen Typen von ein und derselben Klasse abstammen. Dazu kommt noch dass ich nicht bei jeder Methode die ein Objekt dreht definieren kann ob die Drehung im lokalen Raum, im globalen Raum oder relativ zum Parent passiert.

In 0.45 ist das positionieren und drehen von Pivots eingebaut was aber noch einige Bugs enthält die teilweise mit EntityParent() zusammen hängen. Im Example ist eine einfache FPS Camera eingebaut die leider auch noch nicht so arbeitet wie ich das gern hätte ... aber oberflächlich funktioniert es schonmal.

Weiterhin hinzugekommen ist für beide Versionen die Funktion/Methode "SetLogLevel()". Über diese kann bestimmt werden wie umfangreich die Log-Messages der Engine sind. Mögliche Werte für den Parameter sind LL_LOW, LL_NORMAL, LL_HIGH. Voreingestellt ist LL_LOW. SetLogLevel() muss vor Graphics3D aufgerufen werden wenn man es nutzen möchte.

Das Changelog für 0.45 BlitzMax
Code: [AUSKLAPPEN] [EINKLAPPEN]

Das Changelog für 0.45 Blitz3D/BlitzPlus
Code: [AUSKLAPPEN] [EINKLAPPEN]




>> Download BlitzOgre3D v0.45 für Blitz3D/BlitzPlus (ca. 690kb) <<

>> Download BlitzOgre3D v0.45 für BlitzMax (ca. 196kb) <<

Wichtig!
Dies ist ein Update für die Version 0.44. Das heißt dass zuerst 0.44 installiert und dann 0.45 darüber kopiert werden muss.