07. 05. 2007 - Mark Siblys Worklog
Auf
www.blitzbasic.com hat Mark neue Informationen über BlitzMax 3D veröffentlicht. Für User, die der englischen Sprache weniger mächtig sind, oder nur zu faul sind es zu übersetzen, hier eine (teilweise freie) Übersetzung des Beitrags:
Ok, es ist schon eine Weile her, seit ich hier das letzte mal schrieb, aber um ehrlich zu sein, war ich mir nicht hunderprozentig sicher, wie es weiter gehen wird.
Wie auch immer hier nun der Stand der Dinge, die sich heraus kristallisiert haben:
Max 3D
Nun Max3D ist noch in Entwicklung, doch es bewegt sich in eine etwas andere Richtung.
So wie es lief wäre Max3D nur "noch eine weitere 3D API" geworden, in der Richtung von B3D, Ogre, DB, etc. Dies ist nicht unbedingt schlecht, aber etwas, was nicht genug Interesse halten kann.
Die Sache ist, dass Blitz3D und seines Gleichen helfen nur ein Stücken der Spiele Entwicklung Problematik zu lösen und ich möchte wirklich etwas erreichen, was mehr als das kann, etwas auf einer deutlich höheren Ebene.
Ich mache mir viele Gedanken, wie dies zu erreichen ist, aber die Schlüssel dazu sind:
Gewöhnliche Tools und Editoren. Ich hab unzählige Male versucht übertragbare Informationen, wie Shader-Matrialeinstellungen und die Vorteile von Drittprogrammdateien wie 3DS etc. zu verwenden, doch das war nicht von Nutzen. Genug! Ich schreibe nun meine eigenen Editoren, die genau die Daten abgeben, die ich brauche. Dies bedeutet auch, dass so töfte Sachen, wie Soundeffekte zu Surfaces hinzu zufügen möglich sein wird. etc etc.
Außerdem wird es einen Game-Editor beinhalten, wie auch immer...
Es wird weiterhin mit dem grundlegenden Code laufen. Wenn du einen Mac besitzt und noch nicht mit dem "interface builder"(ein Programm zum Erstellen von GUIs) gespielt hast, empfehle ich es dir zu tun, dann weißt du was ich mein. Der "interface builder" macht durchaus radikal eine andere Annäherung zum "RAD design". Statt Code zu generieren verbinded er einfach bestehende Codes. Dies ermöglicht enorme Flexibilität alles erdenkliche einzustellen--ohne die Kopfschmerzen des andauerenden synchronisierens beim Code generieren.
Dies ist mit Sicherheit eine Abkehr vom ursprünglichen Weg, doch es ist etwas was ich schon immer entwickeln wollte. Wenn nicht jetzt, wann dann?
Mehr von allem, so wie es sich entwickelt.
gxLib
Direkt nach Weihnachten entschloss ich mich, die Entwicklung von Max3D kurz (!) zu unterbrechen um die IDE zu verbessern. Mein Hauptaugenmerk legte ich auf den langsamen Text-Editor, die unzuverlässige Hilfe und die extremen Linux Schwierigkeiten. Es wurde schnell klar, dass der Editor (insbesondere die Richedit Control) nicht für die Aufgabe geeignet ist.
So entschloss ich mich einen schnellen Blick auf wxWidgets (eine populäre "cross platform GUI") und wxScintilla (einen viel genutzter Text Editor) zu werfen. Der erste Eindruck war gut, doch wie immer sitzt der Teufel im Detail. Um es ausreichend zu BMX zu übertragen, würde es eine Ewigkeit brauchen. Es produziert riesige .exen (ja sogar, wenn die verschiedensten Untersysteme ausgeklammert wurden) und es leidet unter der eigenen Cross-Platform Fähigkeit.
Als dieser Punkt der Erbitterung einsetzte entschloss ich mich meine eigene "blutige" GUI zu entwickeln. Das war die Geburt von gxLib.
gxLib ist eine eigene GUI, die auf einem sehr niedrigen Level des Betriebsystems arbeitet und die gewöhnlichen OS-Fenster benutzt, aber eine eigenständige Gadgetverwaltung hat. Da es Skin basierend ist, lässt sich das Erscheinungsbild beträchtlich verändern.
Ja, es ist kein Standard und Mac-User werden die Menüs in den Fenstern verteufeln, aber "es läuft". Es läuft identisch auf allen Platformen, ist schnell, ich kann Fehler leichter entfernen und ich kann jede Art von sonderbaren und wunderbaren Gadgets erstellen, die ich möchte. Ich denke es war richtig dies an diesem Punkt so zu entscheiden.
Und es passt mit Sicherheit bestens in meinen Wunsch einen eigenen 3D Game-Editor zu schreiben.
Mein erstes Projekt ist eine neue IDE zu schreiben, die ich mit der Zeit in einen kompletten Game-Editor ausbauen möchte.
Hier eine erste frühe Version von gxLib, basierend auf dem Bmax Debugger:
Stimmt, der Step-Button ist an einem seltsamen Ort, aber ich habe noch keine Toolbar erstellt, aber ein Großteil des komplexen Krams ist schon aus dem Weg geräumt: Der Text-Editor ist zu 90% fertig und läuft gut und schnell. Das Hilfesystem (siehe unten) ist integriert und Tabviews, Splitviews und Treeviews etc. sind eingebaut.
Achtung: Dies wirkt sich nicht auf die BMax GUI Entwicklung aus. Die BMax GUI wird weiterhin verfügbar sein und unterstützt werden. Es wird vorerst auch kein öffentliches gxLib Modul geben, da es sich während der Max3D Entwicklung noch radikal verändern kann. Des weiteren bietet die BMax GUI 100% "look and feel" des jeweiligen Betriebsystems, was mit der gxLib nicht nachgeahmt werden kann.
BlitzMax Docs
Ich wollte es schon seit einiger Zeit aufräumen. Ehrlich!
Meiner Meinung nach, ist das derzeit größte Problem mit diesen Docs, ein organisatorisches. Ich bin beeindruckt von den IDE Lösung der Community hier (Category/Module anstatt eines Durcheinanders von Modulen) und die neue IDE wird diese Idee aufgreifen.
Ein weiterer strittiger Punkt in den Docs ist der HTML-Code in diesen. Zeitliche Einschränkungen, nicht zu erwähnen die Tatsache, dass wir zu der Zeit als sie erstellt worden sind nicht einmal eine IDE/GUI hatten, sind die Hauptschuldigen hier. Insbesondere die Language-Docs sind wegen der zahlreichen "<font class=...>" grausam zu bearbeiten. Das muss ich nun alles entfernen.
Die gxLib hat ihr eigenes Doc-System, dass auf einfachen Zeichen basiert, die nicht zu sehr aus dem Text heraus stechen. Es unterstützt 3 Ebenen: Fett, Links und Tabellen. Das ist wirklich schön. Alle Module-Docs sind schon konvertiert und die Language-Docs zur Hälfte.
Die neuen Docs sind auch in individuelle Seiten eingeteilt, die mit doppelter Verbindung vom Browser-Tree als auch von der Fußzeile jeder Parent-Seite verschiedene Wege zum erreichen zulassen. Das bedeutet auch, dass Type-Docs jetzt halbwegs gesund zu lesen sind. Die Docs sind vollständig durchsuchbar und kopierbar.
Alles in allem bevorzuge ich die neuen Docs und denke, dass es die Community auch tun wird, obwohl es schwer ist dies objektiv zu sagen.
BCC changes
Ich hab einige Veränderungen beim BCC vorgenommen. Ich werde sie wahrscheinlich bald releasen. Das wichtigste: Es ist möglich Arrays zu "verbinden". Beispiel:
Code: [AUSKLAPPEN] [EINKLAPPEN] Local x[10],y[20]
Local z[]=x[..5]+y[15..]
Das ist wirklich enorm nützlich.
Außerdem habe ich "Split" und "Join" Methods zu String hinzugefügt.
Bye!
Mark Sibly
Das Original gibts hier:
RELATED LINK http://www.blitzbasic.com/logs...p;log=1043
01.06.2007 - BattleSpace9142 ist Sieger der POTM-Wahl im Mai EDIT by Mr.Hyde am 01.06.07
Unterstützung einfacher Formen (Ovale, Quadrate usw.)