Anleitung zum Einbinden eigener DATEIEN

  • Ich habe mal an dem Programm zum Einbinden eigener Sounds, wie versprochen, etwas herumgewerkelt.
    Herausgekommen ist ein Programm, welches sich über eine ini-Datei auch vom TaschenPC aus konfigurieren lässt und welches es ermöglicht, so ziemlich jede Datei von einem anderen Ort zu beziehen, als standardmäßig vorgegeben. Nun gehts nicht mehr nur um eigene Sounds sondern auch um eigene Karten, eigene Configs, Geschwindigkeitsoptimierung etc. . Deshalb ein neuer Thread.


    Es wurden außerdem folgende Dinge verändert:
    - Alles ist nun threadsicher, d.h. auch in den ungünstigsten Situationen wird nichts mehr abstürzen.
    - Tritt ein Fehler beim Starten auf, kommt es nicht zu solchem Chaos wie bei der letzten Version. Die Fehler werden nun alle ordentlich abgefangen.
    - Das Programm ist bis zur Spitze hoch optimiert. Man kann von einem Performanceverlust von 0 ausgehen; oder anders: Durch das Dekomprimieren der SFS-Archive kann man nun nur noch Performance gewinnen.


    Deshalb würde ich allen, welche die alte ceSFS.dll bei sich installiert haben, empfehlen, unbedingt das Programm zu updaten. Geht nicht nur mehr rein sondern kommt auch noch mehr raus :)


    INSTALLATION der Schnittstelle:
    - Das diesem Posting angehängte ZIP-Archiv (s.u.) entpacken
    - Die Datei ceSFS.dll im MN4-Installationsordner auf dem Pocket-PC (standardmäßig \Programme\NAVIGON\MobileNavigator 4.0) mit Hilfe des Computers in _ceSFS.dll umbenennen
    - Die Datei ceSFS.dll aus dem Archiv in den selben MN4-Installationsordner auf dem Pocket-PC kopieren
    - Die sfs_config.txt aus dem Archiv ggf. editieren (das Format der Konfigurationsdateien wird unten beschrieben) und ebenfalls in den MN4-Ordner des Taschen-PCs kopieren.


    ...Fertig :)


    UPDATEN der Schnittstelle:
    - die ceSFS.dll im MN4-Installationsordner auf dem PocketPC überschreiben mit der DLL aus dem Archiv
    - ggf. die sfs_config.txt so umschreiben wie man es gerne haben will


    KONFIGURATION
    Das Programm bezieht die Informationen, wie es zu arbeiten hat, aus der Datei sfs_config.txt in eurem MN4-Verzeichnis. Diese Konfigurationsdatei ist wie eine ini-Datei, die für Windows typisch ist, aufgebaut und lässt sich daher sowohl vom Taschen-PC als auch mit dem Computer sehr komfortabel editieren.


    Kurze Erläuterung: In eckigen Klammern werden Sektionen definiert, innerhalb der Sektionen wird ein Wert dann immer einer Variablen zugeordnet. Beispiel:
    ---
    Globale_Variable=bla


    [Lebensgefährlicher_Abschnitt]
    Adrenalin=1
    RunAway=0
    ---
    Hier ist "Globale_Variable" eine Variable, die zu keiner Sektion gehört und den Wert "bla" hat. Dann wird eine Sektion "Lebensgefährlicher_Abschnitt" begonnen, zu welcher zwei Variablen "Adrenalin" und "RunAway" mit den Werten "1" und "0" gehören.
    Besonders gilt für diese inis: KEINE überflüssigen Leerzeichen (Whitespaces). Alles was man tippt, wird auch so aufgefasst.


    Dateien umzuleiten ist ganz einfach, wenn man es ein mal verstanden hat.


    Grundsätzlich funktioniert das Programm so: Man gibt eine Menge von Dateien an und sagt, in welchem Ordner die Dateien liegen. Das Programm versucht dann, die Datei von dort zu holen. Befindet sich die gesuchte Datei dort nicht, wird sie von dort geholt wo sie standardmäßig liegt.


    Das definiert man wie folgt:


    In den globalen Sektionen kann man sein(e) Profil(e) definieren, was in der Variable "Maps" (kommt von "Mappings") geschieht. Sie enthält einen oder mehrere durch ein Semikolon getrennte Namen von Profilen, die durchlaufen werden, wenn geschaut wird, ob eine Datei woanders gesucht werden soll als normal.
    Beispiel: Maps=SoundSchnell
    Das aktuelle ausgewählte Profil heißt "SoundSchnell".
    Beispiel: Maps=SoundLeise;kArte_langsam_3
    Zu erst wird geguckt, ob in dem Profil SoundLeise ein neuer Pfad für die aktuelle Datei angegeben werden kann; wenn nicht, dann wird kArte_langsam_3 durchlaufen usw., bis die Datei von irgend einem Ort erfolgreich geladen wurde.


    Die Profile definiert man in der Konfigurationsdatei wie "Sektionen".
    Beispiel: [SoundLeise]
    Alle folgenden Zuweisungen beziehen sich auf das Profil "SoundLeise".


    Diese Zuweisungen sind der Kern der ganzen Angelegenheit. Generell gilt: <maske>=<ziel>
    In <maske> definiert man, wie eine Datei aussehen muss und in <ziel> definiert man, in welchem Ordner diese Datei gesucht wird, wenn sie so aussieht wie in <maske> definiert.
    Auf beiden Seiten können die Pfadangaben entweder absolut oder relativ sein.
    Absolute Angaben beziehen sich immer auf die Wurzel des (teils ziemlich virtuellen ;) ) Dateisystems. Absolute Angaben sind z.B. "\Windows" oder "\Storage Card\Setup". Sie beginnen immer mit einem Backslash.
    Daneben gibt es relative Pfadangaben, die immer vom MN4-Installationsverzeichnis aus angeben, welcher Ort gemeint ist. Relativ ist z.B. "sound", denn im Ordner vom MN4 auf dem PPC befindet sich ein Ordner "sound". Ein anderes Beispiel ist "Skins\Green\". In jedem Falle darf kein Backslash am Anfang eines relativen Namens stehen. Im Gegensatz zu Shells oder anderer direkter semantischer Adressierung in Dateisystemen darf in der Konfigurationsdatei auch kein .\ am Anfang stehen (bzw. ginge das bei <ziel>, aber ich will hier niemanden verwirren ;) )!


    Das einfachste ist nun, einfach eine Datei aus einem anderen Ordner zu beziehen als eigentlich normal. Dafür gilt: <dateipfad>=<ordner>
    Beispiel: sound/Bitte.ogg=/Storage Card/
    Im Ordner /Storage Card/ muss nun die Datei Bitte.ogg sein, die dann abgespielt wird, wenn die freundliche Dame "Bitte" sagen will.


    Um eine Menge von Dateien umzuleiten, verwendet man einen Wildcard, in dem Falle ein *-Zeichen oder bzw. einen Stern. ;) Jede Maske kann nur genau einen Wildcard haben, was diese Suchstrings von denen in z.B. der Windows-Suchfunktion unterscheidet, wo Konstrukte wie *.* möglich sind.
    Am besten versteht man die Funktionsweise anhand von Beispielen:
    *.ogg=/Storage Card/neues_soundpaket/
    Bei allen Dateien mit der Endung ogg wird erst in dem Ordner gesucht.
    Ebenso möglich:
    sound/*.ogg=/Storage Card/neues_soundpaket/
    Bei allen Dateien, die relativ zum MN4-Verzeichnis im Ordner sound sind und als Endung ogg haben, wird in dem Ordner gesucht.
    Um Karten usw. umzuleiten, die sich ja normalerweise außerhalb des MN4-Verzeichnisses befinden, muss eine absolute Pfadangabe erfolgen:
    /Storage Card/Deutschland/*.map=karte
    Alle Dateien mit der Endung .map, die in dem Kartenverzeichnis liegen, werden im MN4-Verzeichnis im Ordner "karte" gesucht (Gedankenexperiment: Wichtige Kartendateien entpacken, ins MN4-Verzeichnis tun, dann die Umleitung machen und schauen was sich bei der MN4-Performance tut).


    Natürlich gibt es noch 1000 andere Kombinationen und man könnte es alles noch viel leistungsfähiger machen, aber nachdem ich selber mehrmals den Überblick verloren habe als ich das ganze noch höher und flexibler bauen wollte, denke ich, es ist das beste, sich auf diese wesentlichen Funktionen zu beschränken.


    Nun ist es ganz einfach, die Konfigurationsdatei anzugeben, die genau das tut, was die alte Version des Programms getan hat: Alle Sounds im Ordner X suchen (X kann z.B. \Storage Card\mn4sounds\ sein):
    ---
    Maps=EigeneSounds
    InitFailuresAreFatal=1


    [EigeneSounds]
    *.ogg=X
    ---


    Wenn mehrere Profile oder Einträge in den Profilen eingegeben werden, wird alles der Reihenfolge nach abgearbeitet (von links nach rechts, von oben nach unten). Da wo die Datei zum ersten mal erfolgreich geladen wird, wird abgebrochen. Wird sie nie erfolgreich geladen, wird die Datei so geladen, wie vom MN4 ursprünglich vorgegeben (erst wenn auch das nicht geht, habt ihr wirklich ein Problem ;) ).


    Übrigens:
    Im globalen Bereich kann man noch eine Variable "InitFailuresAreFatal" auf 1 oder 0 setzen (default: 1). Sie bewirkt, dass eine konsistente Konfigurationsdatei gefordert wird, damit MN4 anläuft. Sonst beendet sich das Programm bzw. MN4 bricht den Ladevorgang ab, nachdem der Fehler ausgegeben wurde. Das ist sehr sinnvoll, wenn man an der Konfigurationsdatei rumspielt. Dann muss man bei einem Fehler nicht immer so lange warten, bis MN4 gestartet hat. Den Wert auf 0 zu setzen ist nur für den sinnvoll, der sich seine Config zerschossen hat und trotzdem schnell den MN4 starten will.


    Update 20.10.
    - mit einem Eintrag $SKIPSFS kann man innerhalb einer Profil-Sektion (!) das Laden bestimmter SFS-Archive unterdrücken, so dass man das Archiv dann bedenkenlos von seinem Taschen-PC löschen kann. Natürlich sollten alle Dateien dann anders wo sein.
    Beispiel:


    [AllMySounds]
    $SKIPSFS=german_sound.SFS,english_sound.SFS
    *.ogg=/Storage Card/sounds


    EDIT by loew: Die angehängte Datei musste leider mit Blick auf bisher nicht geklärte Fragen des Copyrights entfernt werden.
    Deshalb sind die originalen Archiv-DLLs (ceSFS.dll u. SFS32.dll) nicht mehr mit bei mir im Archiv.


    DEINSTALLATION der Schnittstelle:
    - Mit dem Computer in das MN4-Verzeichnis auf dem Taschen-PC wechseln
    - die Datei ceSFS.dll löschen
    - die Datei sfs_config.txt löschen
    - die Datei _ceSFS.dll in ceSFS.dll umbenennen
    - Wenn irgend welche Dateien aus bestimmten Ordnern gezogen wurden, kann man diese Ordner nun selbstverständlich auch entfernen


    Die Dateien gibts mal wieder einsatzfertig im Ordner FS_Hook und als Quellcode in FS_Hook/src/. Wenn jemand etwas verändert, würde ich gerne nachwievor davon erfahren ;)
    Das Tool zum Entpacken, also sfs_unpack, liegt ebenso wieder bei (FS_Hook/sfs_unpack). Ohne dem hats ja keinen Zweck...


    Ansonsten möchte ich noch auf die Threads verweisen, die mit der ganzen Angelegenheit in Zusammenhang stehen:
    http://www.pocketnavigation.de…thread.php?threadid=34254 // Hier steht was zum Einbinden eigener Sounds
    http://www.pocketnavigation.de…thread.php?threadid=33985 // Hier gehts um das Tool, welches sfs-Dateien entpackt


    Also, nettes Experimentieren...
    - Johannes

  • Hallo 0815_Typ,


    angeregt durch Dein Posting habe ich mal von der 67 MB großen Karte "D-NORD" folgende *.SFS-Archive entpackt
    D_NORD\kwa\kwa.SFS
    D_NORD\maps\maps.SFS
    D_NORD\tmc\tmc.SFS.


    Dabei sind 33 Dateien mit insgesamt 189 MB entstanden:



    Diese Dateien habe ich auf eine CF-Card in das Verzeichnis
    \CF-Karte\Navigon\D_NORD\ENTP
    kopiert.
    Die Dateien kwa.SFS, maps.SFS und tmc.SFS habe ich umbenannt,
    damit diese Dateien mit Sicherheit nicht benutzt werden können.


    Die sfs_config.txt hat folgenden Inhalt.


    Maps=Default
    InitFailuresAreFatal=1


    [Default]
    *.dat=\CF-Karte\Navigon\D_NORD\ENTP
    *.dcr=\CF-Karte\Navigon\D_NORD\ENTP
    *.fsr=\CF-Karte\Navigon\D_NORD\ENTP
    *.map=\CF-Karte\Navigon\D_NORD\ENTP
    *.nam=\CF-Karte\Navigon\D_NORD\ENTP
    *.rid=\CF-Karte\Navigon\D_NORD\ENTP


    Das NM|4 läßt sich starten, die Karte wird aber nicht erkannt, sondern nach jedem Start kann ich nur die "Karte wählen", die Funktionen "Ein Ziel eingeben", "Mehrere Ziele eingeben" und "Karte anzeigen" sind nicht aktiv.


    Wo liegt mein Fehler?


    Viele Grüße
    Bernhard

    Es ist besser nichts zu tun als mit Mühsal nichts zu erreichen.

  • Hallo B.K.!


    Der Fehler liegt darin, dass man die originalen .SFS-Archive nicht umbenennen darf! Sie müssen weiterhin vorhanden sein, damit die Software zur Not noch auf die originalen Dateien zugreifen kann.


    Vielleicht kann ich aber auch gleich noch einen Automatismus einbauen, der unterbindet, dass die Originalarchive geladen werden, wenn alle darin befindlichen Dateien wo anders schon rumschwirren. Würde schließlich auch noch mal ne Menge Speicher und Laufzeit sparen.


    Bin mal gespannt, was Dein Test mit den Karten ergibt. Ich puzzle zur Zeit eher die Sounds zusammen ;)


    Bis denn,
    - Johannes

  • Zitat

    Vielleicht kann ich aber auch gleich noch einen Automatismus einbauen, der unterbindet, dass die Originalarchive geladen werden, wenn alle darin befindlichen Dateien wo anders schon rumschwirren. Würde schließlich auch noch mal ne Menge Speicher und Laufzeit sparen.

    Bittebittebittebittebitte! :D


    Muß ja kein Automatismus sein. Wozu ist die INI da. ;)
    Unter Global ein Value "LoadOriginalSFS"=0/1.

  • @DeJe:
    Reicht leider nicht... ;(


    Is aber schon implementiert, geht ja relativ fix.


    Aber ich muss es noch testen bevor ich es uploade, aber gleichzeitig 6:20 raus. Und RL ist wichtiger ;)


    - Johannes

  • Hallo Johannes,


    [edit] B.K. [d]vielleicht hinkt die Karte dann ja nicht mehr so sehr nach.[/d] [/edit]


    Habe jetzt einen ersten Test durchgeführt. Die Karte hinkt genausoweit nach.
    Ich habe zwar keine Messungen, denke jedoch die gesamte Systembelastung zum Einlesen der entpackten Daten (3 mal soviel Daten) ist höher, als die gesamte Systembelastung zum Einlesen und Entpacken der gepackten Daten. Nur mit sehr schnellen Erweiterungskarten ist evtl. ein kleiner zeitlicher Vorteil zu erreichen. Der max. Datendurchsatz von 6,5 MB/sec meiner TOSHIBA CF XTRA GREEN ist dafür wohl nicht ausreichend.


    Ich habe aber ein anderes Ziel.
    Wenn das alles so funktioniert wie ich es verstanden habe, dann kann man mit Deinem PGM die Installation von MN|4 endlich trennen.
    Software auf eine Erweiterungskarte, *.ini in den Speicher.
    Dafür müßte Dein Programm aber alle Dateien umleiten können und nicht nur die aus den Archiven.


    Viele Grüße
    Bernhard

    Es ist besser nichts zu tun als mit Mühsal nichts zu erreichen.

    Einmal editiert, zuletzt von rowdy ()

  • Ich habe heute auch mal ein wenig getestet.
    Alle sfs ausgepackt (Sounds, Karten, Maps...) und auf eine Speicherkarte gespielt.


    Leider Null-Performancegewinn mit der jetzigen Version (Abweichungen von ~1 Sekunde).


    mit/ohne neuer ceSFS.dll in Sekunden (Toshiba e800):
    MN starten: 24/24
    Route laden: 16.7/17.4
    Route berechnen: 33.9/34.7


    Für die Karten scheint es also nicht sinnvoll zu sein, da diese dann nur deutlich mehr Speicherplatz benötigen. Für die Sounds ist es natürlich nach wie vor interessant da a) Speicherplatz im RAM gespart werden kann und b) die Sounds auswechselbar werden.

    2 Mal editiert, zuletzt von DeJe ()

  • @DeJe,


    jetzt haben wir jedenfalls eine neue Erkenntnis:


    Das Nachhinken der Karte liegt nicht an der mit MN|4 eingeführten höheren Komprimierung.


    Viele Grüße
    Bernhard

    Es ist besser nichts zu tun als mit Mühsal nichts zu erreichen.

  • Hört sich ja nach einem klasse Tool an. Will mir das ganze auch mal ansehen. Warte aber noch auf Deine neue Version.

  • Zitat

    Original von B.K.
    jetzt haben wir jedenfalls eine neue Erkenntnis:


    Das Nachhinken der Karte liegt nicht an der mit MN|4 eingeführten höheren Komprimierung.


    Sooo neu ist die Erkenntnis nicht.


    Ich habe schon oft gesagt, dass Medion 3.1A mit gleicher Komprimierung nicht merklich hinkt - und dass es aus unbekannten Gründen den Prozessor weitaus weniger auslastet, was bisher die einzig plausible Erklärung für das Hinken in MN4.x ist.

    Einmal editiert, zuletzt von 944S2 ()

  • Meine Vermutung geht auch eher in Richtung neuer Grafik-Engine in MN|4. ;)

  • Zitat

    Original von 944S2


    Sooo neu ist die Erkenntnis nicht.


    Ich habe schon oft gesagt, dass Medion 3.1A mit gleicher Komprimierung nicht merklich hinkt - und dass es aus unbekannten Gründen den Prozessor weitaus weniger auslastet, was bisher die einzig plausible Erklärung für das Hinken in MN4.x ist.


    Hallo 944S2,


    ja stimmt, das hast Du schon oft schlüssig dargelegt aber jetzt ist aus der Annahme eine sichere Erkenntnis geworden.
    Vielleicht ist es ja sinnvoll, das Thema noch einmal in einem neuen Thread zu diskutieren.


    Viele Grüße
    Bernhard

    Es ist besser nichts zu tun als mit Mühsal nichts zu erreichen.

  • Zitat

    Original von B.K.
    Vielleicht ist es ja sinnvoll, das Thema noch einmal in einem neuen Thread zu diskutieren.


    Hmm, das Thema "CPU-Auslastung + Nachhinken"?


    Dazu gab es ja meinen alten Thread
    www.pocketnavigation.biz/board/thread.php?threadid=26472
    der nicht auf besonders viel Interesse gestoßen ist.


    Bei Bedarf kann man ja da weiter diskutieren, aber ich sehe wirklich nicht viel neues.


    Navigon muss das Thema kennen (Cityhunter hat damals mitdiskutiert), ist aber aus unverständlichen Gründen entweder nicht fähig oder nicht willens, etwas daran zu ändern.

  • Asche auf mein Haupt. ;)
    Ich muß mich ein einem Punkt korrigieren. Leider hatte ich einen kleinen Fehler in der sfs_config. Diesen behoben bringt bei der Berechnung der Route einen ca. 4 Sekunden Vorteil gegenüber der "gepackten" Variante.


    Allerdings ist das nicht so viel um ein ca. 2.5-fachen Speicherbedarf für die Karten zu rechtfertigen, denke ich.


    Außerdem gehe ich davon aus, das es nichts an der Erkenntnis ändert das das Hinterherhinken der Kartenanzeige nicht wesentlich davon beeinflußt wird.


    Zur Kartenanzeige kann man nur soviel sagen:
    Es ist (gerade bei transparenten Anzeigen) deutlich zu sehen wie jedes einzelne Fenster/Anzeige aktualisiert wird. Das zeugt irgendwie nicht davon das hier mit Double-Buffering für die Anzeige gearbeitet wird und die Aktualisierung mehr oder weniger direkt im Videospeicher abläuft. Dieser ist aber für aufwendige Pixeloperationen bei vielen Geräten extrem langsam. ;)
    Ich habe jetzt alle Anzeigen "nicht transparent" und bilde mir ein das der Kartenaufbau und die Anzeige-Aktualisierung merkbar schneller geht, auch beim Menüaufbau.

    Einmal editiert, zuletzt von DeJe ()

  • ...so interessant das Nachhinken ist:


    die Frage der Abspeicherung der *.ini's im RAM sollte nicht untergehen.


    Hat schon jemand Erfahrungen gemacht?