Lars, du scheinst ja schon eine ganz konkrete vorstellung zu haben. Eventuell könntest du ja mal hier ein kleines Beispiel posten, und die anderen Formatdesigner sagen was sie anders machen würden, und warum.

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

Auf Seite 4 hatte ich ein Bsp. geschrieben. Das einzige was ich da noch ändern würde wäre die Typen nicht am Anfang sondern immer bei ihrer ersten Verwendung (wie die Namen) zu deklarieren. Das ganze hat nur eine konstante zusätzliche Größe gegenüber keinen TypeInformationen und Text oder Binärformat sind faktisch gleich.

Wäre das nicht recht komplex, wenn du Typen erst bei verwendung deklarierst? Hier wäre ich für die Pascal-Methode. Das würde wohl die lesbarkeit steigern. Außerdem könnte der Loader erst die ganzen Typinfos abarbeiten und dann zum eigentlichen Laden übergehen. Wenn die Typinfos selbst eine Versionsangabe haben, dann können unnötige Typen immer noch übersprungen werden.

Über diese "Versionsangabe" ließen sich auch andere schöne Sachen realisieren. Z.B. könnte man aus einem File was allen schnickschnak wie Bones und animationen enthält per gezielter Versionsangabe nur das nackte Modell, oder nur das Texturierte Modell auslesen, oder halt das Modell mit allen Schikanen. Das scheint mir schon recht zukunftsträchtig. Man könnte dahingehend auch noch eine "DefaultVersion" angeben (als erstes) die angibt welche Daten überhaupt maximal verfügbar sind. Wenn man dann im Programm "LoadMesh(DEFAULT_VERSION)" ausführt , lädt der Loader selbstständig das was er maximal noch versteht bzw. was im File gespeichert steht. Das is dann schon ziemlich Flexibel.

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

Ich versteh nicht was daran unflexible sein soll, dass musst du mir mal erklären ?

Denn durch versionsnummer und size wird es ja gerade flexible da man mit ein älteren loader die datein trotzdem ohne probleme lesen kann.
Übrigens was für ein Speziellen Tag ? Es ist ne normale anzahl an tags und anhand der versionsnummer wird festgestellt ob der tag bekannt ist oder nicht und anhand size kann ein unbekanter tag übersprungen werden. Um zu erfahren welcher tag nun kommt hat man typ anstatt den tagnamen wie im Textformat.
also eine convertierung von binär in text ist dann folgendes.

version=versionstring
size=sizestring
typ=<tagname>

Noch dazu stehem im Header in der Textvariante diese Daten sowieso, um klar zu machen auf welche Version die File ausgelegt ist.
Also sind die Daten sowieso schon alle da nur in binary und text an unterschiedlichen stellen.

Hier mal ein richtiges Beispiel wie ich mir eine Textfile noch denken könnte.



Bei <type> werden alle benötigten typen festgelegt, wenn ein typ vorhanden ist dann wird dieser automatisch ersetzt.
Wenn im datateil dieser Typ auftaucht wird dann mit hilfe der Typendefenierung die daten gelesen.
Der Loader selber unterstützt nur die Grundtypen wie z.B. Byte, Char, Float, Array, Integer,... .

Die Binäre Variante würde dann so aussehen(nutzte einfach mal hexwerte, bits sind zu stressig)



Noch ein paar worte dazu, ein tag ist ein cardinal und von [00 00 00 00] bis [00 ff ff ff] ist der private bereich für vorgegebene tags wie <header> und den grundlegenden Variablentypen wie Byte oder Float. Die darauf folgenden werte sind für den öffentlichen gebrauch wie für neue bezeicher.
Um nicht unnötig viele Loadersource zu fabrizieren hab ich anfang und ende eines tags mit der gleichen Nummer belegt.
Wenn noch nachträglich änderungen an dem loader statt fanden bezüglich neuer tags, vartypen oder änderungen von alten sollte man anhand der Versionsnummer im header und der versionsnummer in den klassen des loaders die passende version des typen laden können. So ist die abwärtskompatibilität gewährleistet.
Allerding bleibt das problem mit der aufwärtskompatibilität des Loaders, denn wenn ich ne file nutze die ein Vartyp nutzt der erst mit dem Loader 1.1 hinzukam und man noch den Loader 1.0 hat dann würde da ein Problem geben. Wobei ich denke das man erwarten kann das jemand den neusten loadersource lädt.
Noch dazu glaube ich auch nicht das man da überhaupt ne änderung erwarten brauch wenn die betaphase gut genug war.

_________________
"Wer die Freiheit aufgibt um Sicherheit zu gewinnen, der wird am Ende beides verlieren"
Benjamin Franklin

Projekte: https://github.com/tak2004

Ich würde sagen die Versionsnummer sollte eher nebensächlich sein. im Text kann man diese sehr einfach ändern und wenn man ihr zu viel beachtung schenkt, dann geht das schnell nach hinten los. Entweder kennt der Loader die enthaltenen Tags oder nicht. Eine neue Version sollte nur dann erscheinen, wenn sich grundlegendes am Aufbau geändert hat. Also dann wenn die Formate bewusst inkompatibel gemacht werden müssen. Was natürlich nicht passieren sollte. Aber das weiß man vorher nie so genau. Es sollte nur beachtet werden. Also sollte die Hauptversion immer 1 bleiben und sollte dort man eine 2 stehen dann ist Ende im Gelände! Es spielt auch keine Rollen wenn die Version 1.20023 ist. Die 1 muss bleiben um kompatibel zu bleiben.

Das Überspringen der Tags könnte man im Text durch hirarische "Tag Anfang" und "Tag Ende" Texte realisieren. Also Runde Klammer auf nach dem Tagtypen und und Klammer zu auf einer einzellnen Zeile oder so etwas. Im Binären kann man leider nicht so ohne weiteres hirarisch vorgehen, da die Werte nun mal auch bei den Daten vorkommen könnten. Da wäre die Größe eines Tags (Blockes) bestimmt das Sinnvollste. Damit sollte es dann möglich sein einen unbekannten Tag überspringen zu können.

Bevor Stimmen aufkommen, dass das nicht kompatibel sei. Auf den Ersten blick mag das durchaus stimmen. Wenn man die Leseklasse aber so aufbaut, dass sie den Block überspringen kann, dann ist alles im grünen Bereich. Also eine Klasse die die Daten ließt. Und sie lädt im versteckten die Größe oder die hirarischen Infos. Je nachdem ob Text oder Binär. Wenn die Datenhalterklasse mit dem Tag nichts anfangen kann oder will, dann sagt sie "Skiptag" und die Leseklasse springt automatisch auf das nächste Tag. Woher sie die Informationen bekommt ist der Datenklasse egal.

Versionen@Tak: An und für sich klingt das ja schon nicht schlecht. Aber was ist binären Anwenungen die nicht mehr gewartet werden oder nicht ständig auf dem neusten Stand gehalten werden können. Die sollten auch mit einer neueren Datei zurecht kommen. Und man muss halt immer dafür sorgend, dass sich daran nichts mehr ändert. Was innerhalb der Tags abgeht ist deren Sache nur der Aufbau der Tags (oder auch Kontainer genannt) müsste auch mit 0.1 des Formats schon stehen. Ich sage mal nur Office man kann Problemlos mit XP abgespeicherte Datein in 2000 wieder öffnen.

PS: Die Größe (2 Bytes oder 4 Bytes) eines Tags geht meiner Meinung nach derzeit viel zu weit ins Detail und stifftet nur Verwirrung!

Meinst du mich? Hab ich das irgendwo geschrieben?

Also ich wollte in meinem Posting darauf hinaus, dass man mit den Versionsangaben mehr machen kann als nur Versionen zu unterscheiden. Man könnte den Loader nämlich dazu bringen, aus ein und dem selben File verschiedene Meshversionen zu laden. Das fände ich schon recht interessant.



Also wenn ich das gerade richtig verstanden habe dann ist man sich momentan Einig in folgenden Punkten:

-Duales Fileformat (Binary- und Textversion, User entscheidet was er will)
-Aufwärtskompatibilität durch Versionsangaben im File
-Speicherung von Typinformationen im File
-Überspringen von Daten möglich
-Bei Tags existiert Anfangs und Endtags

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

Naja wenn man es genau nimmt ist es in beide richtungen kompatibel solange nicht neue grundtypen hinzukommen die vom exporter verwendet werden. Z.B. in version 1.0 gabs keine Kommazahl und in version 1.1 ist sie aufeinmal drin und wird vom exporter verwendet, dann würde es ein problem geben aber wenn man vorsorglich in version 1.0 die grundtypen wie zahl, char, kommazahl und array festlegt ist es kein problem mehr. Die struktur für ein Tag bleibt ja von version zu version gleich, neue und somit unbekannte Tags werden einfach übersprungen und wenn man sich eine eigene neue Struktur in der file selber bekannt macht muss sie nur auf den Basistypen aufbauen und um sowas kümmert sich ja das exporterscript.

So ist es ja auch in allen programmiersprachen man, man baut typen auf grundtypen die vorgegeben sind auf.
Im Prinzip reicht es Byte, Char, Single, Pointer zu setzten und aus diesen kann man alles typen machen die man will.
Das hat den vorteil das es immer kompatibel ist aber den geringen nachteil das jeder typ in der file deklariert wird.

_________________
"Wer die Freiheit aufgibt um Sicherheit zu gewinnen, der wird am Ende beides verlieren"
Benjamin Franklin

Projekte: https://github.com/tak2004

Also als erstes würde ich vorschlagen in einer Typdeklaration zu schreiben, wie groß ein Typ ist, oder ob er eine variable Größe hat.(Hat er eine Variable größe so wird auch noch Angegeben in welchen Typ die größe gespeichert wird. z.b. ein ShortString hätte ein Byte zur Speicherung der Größe)

Grob unterteilung in:
* Kommentar
* Zahlen
* Delphi ähnlichen record
* Array
* String
* Einem Block der folgendes haben kann: Namen, Eigenschaften, untergeordnete Blöcke.

Danach würde ich entweder die Zahlen so:
(Vorschlag A)
** Integer
*** Wieviel Bits?
** Integer ohne Vorzeichen
*** Wieviel Bits? (oder sollen wir Bytes hernehmen)
** Gleitkommazahlen
*** Wieviel Bits speichern die Zahl und wieviel die Komma position?
** Festkommazahlen
*** Wieviel Bits für Vor und wieviel Bits für Nachkomma stellen?

oder (Vorschlag B) mit der gleichen Bezeichnung wie einer Programmiersprache genauer benennen.(z.B. Pascal: ShortInt, Byte, Word, LongWord, Int64, Single, Double, Real)

Das Problem das man am Anfang nicht weis welche Typs verwendet werden könnte man so lösen:
1.) Alle für das Datei format üblichen Typs abspeichern(so viele dürften das nicht sein)
2.) Am Anfang prüfen für welche Kateogorien Daten da sind und dem entsprechend Typinformationen abspeichern.(z.b. hat das Modell, Bones, Texturen, Animationsdaten?)
3.) Die Typinformationen an einem Stück am Schluss hinschreiben und im Header vermerken wo die Typinformationen sind.

Ich persönlich wäre für Lösung 2 da es beim Exportieren für gewöhnlich nicht auf die paar Millisekunden mehr oder weniger drauf ankommt.

MfG
Flo

_________________
Danke an alle, die mir (und anderen) geholfen haben.
So weit... ...so gut

Moment mal!

Soweit wie ich das verstanden habe möchtet ihr eine Zweigleisige Strecke fahren, einmal Text und einmal Binär. Zudem wollt ihr neue Sachen die der User hinzufügt per Extension reinbringen.

Ich frage mich ehrlich warum ihr das nicht anderst macht. Ihr nehmt z.b. mein Format, schreibt alles in reiner Textform rein. Zudem plant ihr es so weit vorraus, das keine Extensions nötig sind( Versionskontrolle ist natürlich auch drinnen )!
Wenn ihr jetzt das ganze als schnelle Version braucht, jagt ihr es durch eine Art Compiler, der euch das ganze als wunderschönes Binärformat ausgibt( Kann z.b. auch beim laden einer Karte passieren ).

Dann haben die einen ihr lesbares Textformat, und die anderen haben ihr Binäres Format zu Streamen.

_________________
Shareholder und Leitender Entwickler bei Pipedream-Games.

Zitat: Siehst du diesen Park da unten? Jeden Tag lernen sich darin Menschen kennen und verlassen einander. Und du hast dein ganzes Leben Zeit darin zu gehen.

Das binäre Fomat ist erstens leicher zu lesen und zu schreiben als das binäre Format(von einen Program). Zweitens kann das binären Format leichter in das Text-Format übergeführt werden als andersrum.

MfG
Flo

_________________
Danke an alle, die mir (und anderen) geholfen haben.
So weit... ...so gut

Ich denke wir kommen gut vorran.

Übersicht:
-Grunddatentypen sind Zeichen,Zahl,Gleitkomma Zahl,Zeiger und Zustand(0 oder 1)
z.B. Char(1zeichen),Byte(1byte zahl),smalfloat(1byte kommazahl),Pointer,Boolean(1bit zustand),String(1byte zahl+chars)

-datentypen bauen auf den Grunddatentypen auf
z.B.
tag_für_datendeklarierung_start
datentypname datentyp
...
tag_für_datendeklarierung_ende

-datentypen für daten werden über den tag bekannt gemacht
-tags und datentypen werden zu begin der file bekannt gemacht
-tags bestehen aus 1 oder meheren datentypen
z.B.
tag_für_datendeklarierung_start
tagname_anfang
zugrifsname datentyp
....
tagname_ende
...
tag_für_datendeklarierung_ende

-daten werden zwischen ein taganfang und ein tagende abgelegt
tagname
werte
...
tagende

-ein tag wird in textform über den namen erkannt
-ein tag wird in binärform über eine zahl erkannt

Ich hab extra keine <, [, { oder ähnliches verwendet da ich denke das steht noch zur diskussion und hab einfach nur symbolische namen genutzt.

_________________
"Wer die Freiheit aufgibt um Sicherheit zu gewinnen, der wird am Ende beides verlieren"
Benjamin Franklin

Projekte: https://github.com/tak2004

Da ich weiter an meiner Idee arbeite( Allerdings werde ich .NET benutzen, dort geht das schneller mit dem zerlegen ), bitte ich euch doch mal hier sämtliche Stichwörter hinzuschreiben die euch zum Thema Texturen( sprich, normalmap,textur, displacementmap, specularmap,... ) hinzuschreiben, und auch zu anderen Dingen. Hier mal ein paar Stichwörter die mir einfielen:

- Normalmap
- Textur ( Mit Alphawerten )
- Displacementmap
- Specularmap

- Shader
- Alpha ( Generell )


thx an euch!

_________________
Shareholder und Leitender Entwickler bei Pipedream-Games.

Zitat: Siehst du diesen Park da unten? Jeden Tag lernen sich darin Menschen kennen und verlassen einander. Und du hast dein ganzes Leben Zeit darin zu gehen.

Hi,

kann sein, dass ich etwas zu spät dran bin, aber ich möchte euch das trotzdem nicht vorenthalten. Es geht um eine Unit, die Binärdaten in einer Baumstruktur ablegen und auslesen kann. Abwärts- und Aufwärtskompatibilität ist gewährleistet und die Unit kann auch mit sehr fehlerhaften Daten umgehen, da dann einfach Standardwerte für die fehlerhaften Stellen im Stream hergenommen werden. Vielleicht kennt ja jemand die Klasse hier bereits, sie nennt sich TRAKBinaryStreamData und ist verdammt nützlich. Sie kann auch in XML exportieren und importieren, und ein kleines Tool ist dabei, welches das direkte Editieren der Dateien ermöglicht, die damit erstellt wurden.

Es ist also so eine Art Zwischenformat. Es werden alle gängigen Typen von Delphi unterstützt; mit der Unit kann man auch prime Texturen mit reinspeichern...

Ein Tutorial, wie man das benutzt, findet sich hier: http://www.dsdt.info/tutorials/bindatei/

Die Units selbst gibt's auf der Homepage von Richard Kaspar: http://www.kasparsoft.de/RakBinaryStreamData/Download.htm

Ich selbst benutze dieses Zwischenformat nun seit geraumer Zeit und bin recht glücklich damit. Damit lässt sich auch nachträglich das Dateiformat problemlos erweitern, ohne dass es zu Schwierigkeiten kommt.

Wer seine Zweifel daran hat, ob das auch für Meshs geeignet ist, es funktioniert tadellos. Meine gesamte Engine baut darauf auf Und die lädt eigentlich recht flott. Die Unit arbeitet mit den Delphi-Streams, somit lassen sich Daten, die damit erstellt wurden auch problemlos über das Netzwerk streamen etc...

Gruß,
Philipp

P.S.: So wie es aussieht, dürften die von euch angestrebten Features eines DGL-Fileformats damit leicht verwirklicht werden können.

_________________
"Für kein Tier wird so viel gearbeitet wie für die Katz'."

Wo du es gerade erwähnst. Ich habe dazu ne Anmerkung. Also zum Thema Fremdbibliotheken.

Ich mag Units nicht die zum Kompilieren eine Reihe von Fremdbibliotheken benötigen. Und um so größer die Frembibliothek umso ärgerlicher finde ich das Ganze. Speziell wenn es zum Beispiel in diesem Fall im übertragenen Sinn lediglich um eine Kappselung von TStream geht. Versteh mich da bitte nicht falsch. Ich kenne die Bibliothek nicht, kann also nicht sagen ob sie schlecht oder Endsgeil ist. Aber der Entwickler der unser Format dann benutzen will der muss sich dann erst einmal aus dem Netz verschieden Quellen zusammensuchen. Das erhöht lediglich den Frustfaktor, welcher nicht förderlich für die Verbreitung des Formats sein dürfte. Ich wäre da eher immer für ein "Rundumsorglospaket". Auch wenn es bedeuten würde, dass man für verschiedene Dinge selber ein wenig mehr programmieren müsste. Wenn der Vorteil der Bibliothek den "zusätzlichen Quellen Manko" ausgleicht dann spricht natürlich nichts dagegen.

Da stimme ich Lossy zu. Nicht nur das zusammensuchen von Paketen sondern unter umständen auch verschiedene Lizensen machen das Leben nicht egrade leichter.

Ich bin da für ein DGL-Paket was enthält:

- Blenderscript Textformat
- Blenderscript Binaryformat
- Loaderklasse in den Sprachen Delphi und C++ (C++ sorgt für eine wachsende Verbreitung)

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