Files |  Tutorials |  Articles |  Links |  Home |  Team |  Forum |  Wiki

Aktuelle Zeit: So Apr 20, 2014 10:00

Foren-Übersicht » Programmierung » Allgemein
Unbeantwortete Themen | Aktive Themen



Ein neues Thema erstellen Auf das Thema antworten  [ 18 Beiträge ]  Gehe zu Seite 1, 2  Nächste
Autor Nachricht
 Betreff des Beitrags: EBML… oder was?
BeitragVerfasst: Fr Feb 08, 2013 12:12 
Offline
DGL Member
Benutzeravatar

Registriert: Do Sep 02, 2004 19:42
Beiträge: 3874
Wohnort: 2a01:4f8:d16:1305::/64
Programmiersprache: FreePascal, C++
Guten Tag,

Ich überlege gerade, wie ich das Levelformat von ManiacLab aufbaue. Es soll schon was binäres sein, denke ich. Textformate für Levels erschien mir schon immer komisch, obwohl sie ihre vorteile haben. Frase hatte uns ja schon beim berüchtigten Dänemarktreffen auf EBML aufmerksam gemacht, was an sich recht cool ist. Mir gefallen bloß zwei dinge nicht: (a) es gibt nur einen pseudo-RFC (b) die Referenzimplementation ist relativ undokumentiert. Das führt schon praktisch dazu, dass ich ne eigene Implementation schreiben müsste. Gut, damit kann ich leben.

Aber vorher will ich wissen, ob das Format an sich überhaupt eine gute Wahl wäre oder ob es etwas besseres gibt? Ein full-blown binary XML will ich nicht, mir gehts nur darum, grundlegende erweiterbarkeit des Formats zu haben, um nicht bei jedem Upgrade spielstände zu b0rken. Das Format sollte bindings oder noch besser eine Implementation in C++ haben und im optimalfall supereinfach zu benutzen sein. Shared Pointer sind gerne gesehen, es muss nicht schnell sein, nur einfach.

Meine Anforderungen zusammengefasst:
  • Binärformat
  • Einfach versionierbar oder noch besser, laufend erweiterbar
  • Einfache Verwendung im Programm
  • C++11-fähig

grüße

_________________
If you find any deadlinks, please send me a notification – Wenn du tote Links findest, sende mir eine Benachrichtigung.
current projects: ManiacLab; Pythonic Universe; eXtensible Web Framework in Python
zombofant networkmy photostream
„Writing code is like writing poetry“ - source unknown

OTR: zion=3BA7F5A6 868DC61E 6412ACD1 71157B5F 849D62B0 | voyager=4661E31D 3F9543A4 79C22BBC C5A7C016 B1C7DD49

„Give a man a fish, and you feed him for a day. Teach a man to fish and you feed him for a lifetime. “ ~ A Chinese Proverb


Nach oben
 Profil  
 
 Betreff des Beitrags: Re: EBML… oder was?
BeitragVerfasst: Fr Feb 08, 2013 14:29 
Offline
DGL Member
Benutzeravatar

Registriert: Do Dez 29, 2005 12:28
Beiträge: 2246
Wohnort: Düsseldorf
Programmiersprache: C++, C#, Java
BSON (Binary JSON)?
http://bsonspec.org/

Selbst benutzt habe ich es aber noch nicht :)

_________________
Watch Star Citizen Trailer at Youtube!


Nach oben
 Profil  
 
 Betreff des Beitrags: Re: EBML… oder was?
BeitragVerfasst: Fr Feb 08, 2013 15:07 
Offline
DGL Member
Benutzeravatar

Registriert: Do Sep 02, 2004 19:42
Beiträge: 3874
Wohnort: 2a01:4f8:d16:1305::/64
Programmiersprache: FreePascal, C++
Mmmhm. Das ist schon cooler als EBML, allein weil sie little endian benutzen ;). Aber ich frage mich, wie speichere ich da unsigned ints? Dafür gibts keinen definierten Typ…

grüße

_________________
If you find any deadlinks, please send me a notification – Wenn du tote Links findest, sende mir eine Benachrichtigung.
current projects: ManiacLab; Pythonic Universe; eXtensible Web Framework in Python
zombofant networkmy photostream
„Writing code is like writing poetry“ - source unknown

OTR: zion=3BA7F5A6 868DC61E 6412ACD1 71157B5F 849D62B0 | voyager=4661E31D 3F9543A4 79C22BBC C5A7C016 B1C7DD49

„Give a man a fish, and you feed him for a day. Teach a man to fish and you feed him for a lifetime. “ ~ A Chinese Proverb


Nach oben
 Profil  
 
 Betreff des Beitrags: Re: EBML… oder was?
BeitragVerfasst: Fr Feb 08, 2013 15:16 
Offline
DGL Member
Benutzeravatar

Registriert: Do Dez 29, 2005 12:28
Beiträge: 2246
Wohnort: Düsseldorf
Programmiersprache: C++, C#, Java
Nun, du könntest dir eigene Element-Keys definieren dafür und eine bestehende OpenSource-Implementierung entsprechend umbauen. Stört ja keinen sofern du das Format nur selbst benutzt. Am besten solltest du das Format in deiner Doku dann aber nicht mehr BSON nenen sondern HORAZIMTSON oder sowas, damit jeder das sieht sofort weiß das es was selbst gefrickeltes ist was mit nichts kompatibel ist.

_________________
Watch Star Citizen Trailer at Youtube!


Nach oben
 Profil  
 
 Betreff des Beitrags: Re: EBML… oder was?
BeitragVerfasst: Fr Feb 08, 2013 16:52 
Offline
DGL Member

Registriert: So Aug 08, 2010 08:37
Beiträge: 322
Programmiersprache: Pascal (FPC/Delphi)
Zitat:
Binärformat
Einfach versionierbar oder noch besser, laufend erweiterbar


schließt sich das nicht gegenseitig aus?

(habe ich so gelernt oO...)

_________________
Never run a changing system! (oder so)


Nach oben
 Profil  
 
 Betreff des Beitrags: Re: EBML… oder was?
BeitragVerfasst: Fr Feb 08, 2013 18:20 
Offline
DGL Member
Benutzeravatar

Registriert: Do Dez 29, 2005 12:28
Beiträge: 2246
Wohnort: Düsseldorf
Programmiersprache: C++, C#, Java
Zitat:
schließt sich das nicht gegenseitig aus?

Ich wüsste jetzt nicht warum sich das ausschließen sollte. BSON und JSON sind gleich mächtig, sie drücken die gleichen Dinge aus. Gleiches gilt für BinaryXML und XML. Die binäre Variante lässt sich jeweils nur schwieriger von Hand lesen/schreiben, dafür kann sie der Rechner schneller lesen. Gerne wird so verfahren, dass man während der Entwicklung die lesbare Variante benutzt (wenn es noch keinen Editor gibt, etc.) und später für den Release dann auf binär umgestellt wird.

_________________
Watch Star Citizen Trailer at Youtube!


Nach oben
 Profil  
 
 Betreff des Beitrags: Re: EBML… oder was?
BeitragVerfasst: Fr Feb 08, 2013 18:57 
Offline
DGL Member
Benutzeravatar

Registriert: Do Sep 02, 2004 19:42
Beiträge: 3874
Wohnort: 2a01:4f8:d16:1305::/64
Programmiersprache: FreePascal, C++
Ich glaube ich nehme EBML. Beide sehen zwar für den allgemeinen gebrauch etwas unreif aus, aber mit EBML denke ich, werde ich weniger probleme haben. Schon die tatsache, dass ich das Format patchen müsste, um unsigned integer zu repräsentieren, schreckt mich von BSON ab ;).

grüße

_________________
If you find any deadlinks, please send me a notification – Wenn du tote Links findest, sende mir eine Benachrichtigung.
current projects: ManiacLab; Pythonic Universe; eXtensible Web Framework in Python
zombofant networkmy photostream
„Writing code is like writing poetry“ - source unknown

OTR: zion=3BA7F5A6 868DC61E 6412ACD1 71157B5F 849D62B0 | voyager=4661E31D 3F9543A4 79C22BBC C5A7C016 B1C7DD49

„Give a man a fish, and you feed him for a day. Teach a man to fish and you feed him for a lifetime. “ ~ A Chinese Proverb


Nach oben
 Profil  
 
 Betreff des Beitrags: Re: EBML… oder was?
BeitragVerfasst: Mo Feb 11, 2013 11:06 
Offline
DGL Member
Benutzeravatar

Registriert: Di Mai 18, 2004 16:45
Beiträge: 2113
Wohnort: Hamburg
Programmiersprache: C/C++, C#
Weder EBML noch BSON sind gute Native Formate.
Solche Container Formate sind für Platformunabhängige Daten, wo der Inhalt variieren kann.
Bei deinem Levelformat ist dies nicht notwendig.
Arbeite lieber mit structs und array's.
Der Vorteil ist, dass du dir das Strukturelle prüfen einer Datei sparen kannst, sofern der FOURCC stimmt, das Laden mit einem read und mehreren Pointer operationen getan ist.
Damit es git, svn und co besser diffen können, sollte das binary möglichst einer Struktur folgen.
Hast du ein Tile basiertes Game, dann speicher die Tiles in festen Rastern, dann werden nur Tiles verändert und wenn es wenn es 3D Mesh ist, dann speicher es Octree Node weise oder welches Visual Partition System du auch immer verwendest.

Schnelles und effizientes Laden erreichst du über Facade Pattern, also binary Daten Laden, in das Facade packen und vieleicht noch ein bisschen Pointer magic.

Kleines Beispiel.
Code:
  1. struct myChessBoardTile{
  2.   int figureId;
  3.   bool isWhiteField;
  4.   char reserved[3];// 4byte alignment
  5. };
  6.  
  7. struct figure{
  8.   int id;
  9.   FigureType type;
  10. };
  11.  
  12. struct player{
  13.   char name[32];
  14. };
  15.  
  16. struct mapData{
  17.   myChessBoardTile tiles[64];
  18.   figure figures[32];
  19.   player players[2];
  20.   // wenn vorhanden, kommt nun hier dynamischer kram hin
  21.   int listSize;
  22. };
  23.  
  24. class MyChessGame
  25. {
  26.   public:
  27.     // hier kommen nun die logischen funktionen, um die daten zu verändern und zu zugreifen
  28.     void Load(mapData* data){
  29.        this->data=data;
  30.        if (this->data->listSize>0)
  31.          irgendWasDynamisches=this->data+1;
  32.     }
  33.     Entry* GetEntry(unsigned int Index){
  34.       if (Index<this->data->listSize)
  35.         return irgendWasDynamisches[Index];
  36.       else
  37.         return 0;
  38.     }
  39.   private:
  40.     mapData* data;
  41.     Entry* irgendWasDynamisches;
  42. }


Was du nun machen kannst ist die größe der Datei fest stellen, Speicher alloziieren, lesen und dann den Buffer zu mapData Typecasten und an die MyChessGame instanz übergeben.
Fallen noch dynamische Daten an, dann kannst du dir hilfspointer anlegen, die auf die dynamischen Daten zeigen, um nicht immer wieder zu prüfen ob alles korrekt ist.

Die meisten Formate lesen Chunkweise, machen logische prüfungen auf die Daten und lesen dann wieder weiter und man braucht kein Doktor Titel um zu merken, dass dies ineffizient ist.
Das gerade gezeigte Verfahren wird oft flat loading genannt und hat im Idealfall nur ein einzigen Festplatten zugriff, Speicheralloziirung und wenn überhaupt nur ne hand voll If's und pointerarithmetik.

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

Projekt: http://www.part-time-scientists.com
http://www.radonframework.org


Nach oben
 Profil  
 
 Betreff des Beitrags: Re: EBML… oder was?
BeitragVerfasst: Mo Feb 11, 2013 16:50 
Offline
DGL Member
Benutzeravatar

Registriert: Do Sep 02, 2004 19:42
Beiträge: 3874
Wohnort: 2a01:4f8:d16:1305::/64
Programmiersprache: FreePascal, C++
Ich denke eben nicht, dass das sinnvoll ist. Ich plane, das System durchaus erweiterbar zu halten um neue Objekttypen und eventuell auch Skripte später mal einfügen zu können. Dementsprechend ists eben nicht einfach nur Structs und Arrays einlesen. Ich halte eine Erweiterbarkeit des Formats für sehr wichtig.

EBML geht mir teilweise ziemlich auf den Keks. Die spec sieht wie eine Abstraktion des Matroska-Formates aus, welche aber falsch durchgeführt wurde. Allein, wie die Regeln, wo eine Node auftauchen darf, definiert sind, macht das schreiben eines allgemeinen Parsers sehr unangenehm. Ich überlege, einen Flavour „Restricted EBML“ (rebml) zu bauen, der einiges davon nicht unterstützt, anderes dafür abstrahiert. Das sollte viele Probleme lösen und das Format zugleich übersichtlicher machen. Im Optimalfall kann ich dann immer noch Matroska parsen ;).

grüße

_________________
If you find any deadlinks, please send me a notification – Wenn du tote Links findest, sende mir eine Benachrichtigung.
current projects: ManiacLab; Pythonic Universe; eXtensible Web Framework in Python
zombofant networkmy photostream
„Writing code is like writing poetry“ - source unknown

OTR: zion=3BA7F5A6 868DC61E 6412ACD1 71157B5F 849D62B0 | voyager=4661E31D 3F9543A4 79C22BBC C5A7C016 B1C7DD49

„Give a man a fish, and you feed him for a day. Teach a man to fish and you feed him for a lifetime. “ ~ A Chinese Proverb


Nach oben
 Profil  
 
 Betreff des Beitrags: Re: EBML… oder was?
BeitragVerfasst: Mo Feb 11, 2013 20:18 
Offline
DGL Member
Benutzeravatar

Registriert: Di Mai 18, 2004 16:45
Beiträge: 2113
Wohnort: Hamburg
Programmiersprache: C/C++, C#
Zum ersten, das ist irrglaube, denn diese Art von Format ist sehr wohl flexibel, denn es hat nix mit erweiterbarkeit zu tun.
Blender macht dies z.B. auch und hat an erster stelle eine chunkId, welche zur versionierung von solchen structs verwendet wird.
So kann man vom gleichen Struct mehrere varianten haben und das format bricht nicht mit älteren versionen.

Zum zweiten EBML ist aus Matroska entstanden.

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

Projekt: http://www.part-time-scientists.com
http://www.radonframework.org


Nach oben
 Profil  
 
 Betreff des Beitrags: Re: EBML… oder was?
BeitragVerfasst: Mo Feb 11, 2013 20:26 
Offline
DGL Member
Benutzeravatar

Registriert: Do Sep 02, 2004 19:42
Beiträge: 3874
Wohnort: 2a01:4f8:d16:1305::/64
Programmiersprache: FreePascal, C++
Die Grundprinzipien eines solchen Formates sind mir durchaus bekannt. Dann muss man aber auch bedenken, dass Level zwischen mehreren Minors oder Major-Versionen, wo vielleicht nen optionales Feld an jedes Tile drangehangen wurde getauscht können werden sollen. Ich kann natürlich für jede alte Version eine eigene Leseroutine schreiben, aber das ist nicht sehr hilfreich. Die Blender-Leute haben für ihre Structs nen recht komplexes System entwickelt, was sich darum kümmert.

So fertige Containerformate hätten halt den vorteil, dass ich für Flags in den neueren Versionen einfach defaultwerte nehmen kann, wenn sie nicht in der Datei sind. Das ist schon eine bestechende Einfachheit.

Natürlich wird das ein bisschen davon aufgefressen, dass ich hier gerade damit liebäugle, ne eigene Implementation von so einem Containerformat zu bauen *hust*. Dieser EBML-Kram ist aber schon extrem nervig. Wie die das Streambar gemacht haben, ist mir unklar. Vielleicht grabe ich demnächst mal tiefer in den Source der Referenzimplementation. Ich meine, man kann doch in EBML z.B. die Parent-Zugehörigkeit eines SHA1 [ SHA1Container [ Void … ] Checksum ] konstruktes nicht eindeutig bestimmen, bis man mehr als das Void-Element gelesen hat. Wie man für sowas einen streamenden Parser schreiben kann, ist mir ein großes Rätsel.

BSON ist bestechend einfach und ich fürchte fast, dass ich da landen werde, selbst wenn mir das Format bei weitem nicht so elegant vorkommt wie EBML. Vielleicht implementiere ich auch einen einfachen mix aus BSON und EBML, mal sehen ;).

grüße

ps.: Mir ist klar, dass EBML von den Matroska-Leuten kommt – deshalb habe ich das ja erwähnt ;) bzw. sonst würde ich das Matroska-Format nicht kennen.

_________________
If you find any deadlinks, please send me a notification – Wenn du tote Links findest, sende mir eine Benachrichtigung.
current projects: ManiacLab; Pythonic Universe; eXtensible Web Framework in Python
zombofant networkmy photostream
„Writing code is like writing poetry“ - source unknown

OTR: zion=3BA7F5A6 868DC61E 6412ACD1 71157B5F 849D62B0 | voyager=4661E31D 3F9543A4 79C22BBC C5A7C016 B1C7DD49

„Give a man a fish, and you feed him for a day. Teach a man to fish and you feed him for a lifetime. “ ~ A Chinese Proverb


Nach oben
 Profil  
 
 Betreff des Beitrags: Re: EBML… oder was?
BeitragVerfasst: Di Feb 12, 2013 00:22 
Offline
DGL Member
Benutzeravatar

Registriert: Di Mai 18, 2004 16:45
Beiträge: 2113
Wohnort: Hamburg
Programmiersprache: C/C++, C#
http://bitsquid.blogspot.de/ <- Da solltest du mal rein gucken.

Die Entwickler nutzten Data driven design und nutzten verschiedenste Arten von Formaten.
Zum einem nutzen sie json für Konfigurationsdaten, welche zu bson ähnliche notation konvertiert werden kann und für größere Daten gibt es mehrere Formate, ein intermediate format und ein dazu gehöriges natives Format.

Als intermediate könnte z.B. ein json, mit binary Daten, in base85 kodiert oder ähnlich verwendet werden und als natives dann flat format wie vorher beschrieben.

Es gibt halt viele Möglichkeiten.

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

Projekt: http://www.part-time-scientists.com
http://www.radonframework.org


Nach oben
 Profil  
 
 Betreff des Beitrags: Re: EBML… oder was?
BeitragVerfasst: Di Feb 12, 2013 18:59 
Offline
DGL Member
Benutzeravatar

Registriert: Mo Nov 08, 2010 18:41
Beiträge: 426
Programmiersprache: Gestern
Machs doch einfach wie so ziehmlich jeder in letzten 20 Jahren.

structs = geometrie und bäume
entities = gameplay objekte

Für die Entities kannst du entweder wie Q3 einfach nen script nehmen oder auf eines dieser lustigen Formate setzen. Oder du machst sowas wie property - value matching.... alles Wurst wie Käse da sehr simpel
Wenn du es ganz extrem haben willst kannst du wie Doom auch zeiger von Geometrie auf Entities machen (oder wars umgekehrt :twisted: ).... brauchst du allerdings bloß für heftige Animation wie dort.

_________________
Meine Homepage
-general obj-c lib (0.4)(cross-platform)


Nach oben
 Profil  
 
 Betreff des Beitrags: Re: EBML… oder was?
BeitragVerfasst: Mi Feb 13, 2013 10:21 
Offline
DGL Member
Benutzeravatar

Registriert: Di Mai 18, 2004 16:45
Beiträge: 2113
Wohnort: Hamburg
Programmiersprache: C/C++, C#
Egal wie du weiter arbeitest, kannst du hier schreiben, wie du dich entschieden hast und wie das aussehen wird ?
Mich würde interessieren, wie du dann letzlich dein Format nutzt und für folgende Entwickler, die sich damit rum Plagen müssen kann es inspirierend sein. Man könnte also dann darauf verlinken.

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

Projekt: http://www.part-time-scientists.com
http://www.radonframework.org


Nach oben
 Profil  
 
 Betreff des Beitrags: Re: EBML… oder was?
BeitragVerfasst: Do Feb 14, 2013 20:11 
Offline
DGL Member
Benutzeravatar

Registriert: Do Sep 02, 2004 19:42
Beiträge: 3874
Wohnort: 2a01:4f8:d16:1305::/64
Programmiersprache: FreePascal, C++
TAK2004 hat geschrieben:
Egal wie du weiter arbeitest, kannst du hier schreiben, wie du dich entschieden hast und wie das aussehen wird ?
Na klar doch, Tak. Siehe meinen Post in meinem Projektthread.

grüße,
Horazont

_________________
If you find any deadlinks, please send me a notification – Wenn du tote Links findest, sende mir eine Benachrichtigung.
current projects: ManiacLab; Pythonic Universe; eXtensible Web Framework in Python
zombofant networkmy photostream
„Writing code is like writing poetry“ - source unknown

OTR: zion=3BA7F5A6 868DC61E 6412ACD1 71157B5F 849D62B0 | voyager=4661E31D 3F9543A4 79C22BBC C5A7C016 B1C7DD49

„Give a man a fish, and you feed him for a day. Teach a man to fish and you feed him for a lifetime. “ ~ A Chinese Proverb


Nach oben
 Profil  
 
Beiträge der letzten Zeit anzeigen:  Sortiere nach  
Ein neues Thema erstellen Auf das Thema antworten  [ 18 Beiträge ]  Gehe zu Seite 1, 2  Nächste
Foren-Übersicht » Programmierung » Allgemein


Wer ist online?

Mitglieder in diesem Forum: 0 Mitglieder und 0 Gäste


Du darfst keine neuen Themen in diesem Forum erstellen.
Du darfst keine Antworten zu Themen in diesem Forum erstellen.
Du darfst deine Beiträge in diesem Forum nicht ändern.
Du darfst deine Beiträge in diesem Forum nicht löschen.
Du darfst keine Dateianhänge in diesem Forum erstellen.

Suche nach:
Gehe zu:  
  Powered by phpBB® Forum Software © phpBB Group
Deutsche Übersetzung durch phpBB.de