Hallo miteinander.
Ich habe im Anhang eine Datei hochgeladen welche etwa 133 verschiedene
8-Bit BMP Dateien enthalten müsste. Diese Datein sind alle Grayscale.
Nun habe ich versucht jede Datein über den Hex Editor herauszukopieren.
Leider sind die Dateien danach von keinem Bildprogramm mehr lesbar. Habt
ihr evtl eine Theorie wo der Fehler liegen könnte? Im Hex-Code finde ich
den Header "424D" mehrfach vor. Keiner der Dateien sollte größer als
20~40KB sein.
Leider kann ich aus diesen Header-Informationen keine für mich
verwertbaren Informationen herausziehen:
424D7F8BCCCC7F8B7F8B33537F8B7F8B1111B29F7F8B11127F8B7F8BCCCC7F8BBB7C8B44
0C4812997C8B729E11122788443989A40C9444A21F08000A9F11122227444778AB22AFA9
02133011079E20101111772224A30CCAAAA7994442B3FF11117210412343717AA70B059D
110301777987
Ich hoffe ihr habt davon mehr Ahnung als ich :)
Hmmm ... die Signatur ist "BM", dezimal 19778, hex 4D 42 ... ist da bei
dir evtl. ein Little-Endian-Problem (LoByte/HiByte vertauscht)?
http://de.wikipedia.org/wiki/Windows_Bitmap
Hallo und danke für deine Antwort. Leider kann ich nicht zu 100%
auschließen das sich die Datei unkomprimiert in der Datei befinden. Ein
Datei-Signatur-Scan hatte mich auch nicht weiter gebracht, daher habe
ich mir einfach eine 8-Bit BMP erstellt und mit dem HEX-Editor den
Header kopiert. Gibt es da mittel und Wege um genauere Informationen aus
der Datei zu bekommen?
Plastefuchs schrieb:> Gibt es da mittel und Wege um genauere Informationen aus> der Datei zu bekommen?
du must doch am besten wissen, was für Daten du erwartest?
wo kommen sie her, welche Auflösung, welche farbauflösung
aber unkomprimierte Bilddaten scheint das nicht zu enthalten.
Wenn man im Gimp mit Rohdaten öffnen spielt, könnte man sonst wenigstens
ansatzweise irgendwo struktur erkennen, wenn man ein wenig mit dem
Breitenregler spielt-
Also die Situation ist folgende: Die Daten enthalten 8-Bit Bilder in
Graustufen. Diese entstammen einem 12 Jahre altem Spiel. Die
Entwicklerfirma existiert schon lange nichtmehr daher habe ich mich mit
verschiedenen Herstellern in Verbindung gesetzt weil ich den Quellcode
kaufen wollte. Den richtigen Ansprechpartner habe ich zwar ausfindig
gemacht, aber leider war der originale Quellcode nichtmehr auffindbar.
Man hat mir allerdings gestattet mir die Ressourcen aus dem
Originalspiel zu verwenden.
Das ist alles was mir über diese Datei bekannt ist.
Kann es sein, dass die Datei eine einzige Bitmap, mit mehreren Kacheln,
enthält?
Dann würde sich nur ein Header in der Datei befinden. Dies wiederum
würde das "manuelle" Kopieren verhindern.
Such dazu einfach nach der Sequenz: 42 4D. Aber Vorsicht, die Byte-folge
kann aber auch regulär innerhalb eines Bildes vorkommen.
Plastefuchs schrieb:> Die Daten enthalten 8-Bit Bilder in> Graustufen. Diese entstammen einem 12 Jahre altem Spiel.
Name des Spiels, Größe der Grafiken, Farbauflösung (4, 8, 16,...
Graustufen in einem Bild), Screenshot?
Hallo,
@ Vlad Tepesch
Das Spiel nennt sich "KKnD: Krossfire". Die Farbauflösung liegt bei 256
Farben, diese werden aber nicht in der Bitmap selbst gespeichert sondern
über eine Farbpalette direkt vom Spiel in die korrekte Farbe gezeichnet.
Wie groß die Grafiken sind ist schwer zu sagen die einen sind etwas
kleiner andere etwas größer, alle aber kleiner als 50x50 denke ich.
@amateur
Es ist gut möglich das die Datein in einer großen Datei zusammengefasst
wurden sind. Den Bitmap Header konnte ich allerdings an mehreren Stellen
der Datei ausfindig machen, daher ging ich davon aus das es sich hierbei
um einzelne Bilder handelt.
Probiers mal damit ist ein altes DOS-Tool, also ohne Gewähr. Das
Programm erwartet vermutlich als Übergabeparameter den Namen der zu
durchsuchenden Datei.
gk
Die genaue Beschreibung der Bitmapheader gibt's bei KleinWeich.
Früher enthielt denen C-Compiler auch eine passende Strukturdefinition,
zusammen mit einer Beschreibung der Datentypen.
Da drinnen steht auch ob 1,4,8 u.s.w. Bit pro Pixel verwendet werden und
wie groß die Farbtabelle ist.
Um grob festzustellen, ob jedes Bild einen eigenen Header hat, wüste ich
nur die Suchfunktion. Die Anfangskombination müsste mindestens 133-mal
vorkommen. Sollte sie als Grau-Wert innerhalb eines Bildes auftauchen,
so ist es oft so, dass mehrere Signaturen in sehr geringem Abstand
auftauchen.
kknd sagt mir was, ich glaub das hab ich auch mal gespielt.
wo hast du denn den dump her?
kann man nicht vielleicht direkt in den Spieldateien nach den
Grafikdaten suchen?
um welche Grafiken geht es dir denn?
notfalls halt per screen shot
der dump enthält auf jeden fall keine gültigen BMP-Header.
und wie gesagt, er enthält höchstwahrscheinlich auch keine
unkomprimierten grafikdaten.
zu not könnte man noch versuchen, ob man zur Programmlaufzeit an die
Daten kommt. da werden sie höchstwahrscheinlich irgendwo im Ram liegen
oder ist deine datei ein ram dump?
amateur schrieb:> Früher enthielt denen C-Compiler auch eine passende Strukturdefinition,> zusammen mit einer Beschreibung der Datentypen.
Das tut der jetzt natürlich auch noch.
Hallo,
Den Dump hat ich aus ner Memory Dump rausgeschnitten weil ich gehofft
habe das die Datein dort ggf. unverschlüsselt drin liegen könnten. Die
Originaldatei ist bei /levels/german/gamesprt.lpk zu finden. Ich wollte
es vermeiden jede einzelne Einheit von Hand aus der Datei zu rippen da
auch viele Animationen vorhanden sind und das einfach sehr lange dauern
würde dies für jede Farbe seperat zu tun. Ich möchte nach möglichkeit
alle Grafiken haben die zu finden sind. Da der Quellcode nichtmehr
auffindbar ist und der Assemblercode mehr als aufwendig
umzuprogrammieren ist, wollen wir die moderne Technik nutzen wie z.b.
die XNA Umgebung von Mikrosoft und das Spiel nachprogrammieren. Das
dürfte mit den heutigen Mitteln nicht mehr ganz so komplex sein.
Plastefuchs schrieb:> Ich habe im Anhang eine Datei hochgeladen welche etwa 133 verschiedene> 8-Bit BMP Dateien enthalten müsste. Diese Datein sind alle Grayscale.
Meine erste Vermutung: Die Anzahl der Bytes im dump (6142650) ist durch
150 teilbar.
6142650 / 150 = 40951
Meine Anfangsvermutung: Es handelt sich um einzelne 150 Bilddateien mit
identischer Größe von je 40951 Bytes.
Also würde ich den dump erstmal in 150 einzelne Dateien splitten und
dann nachsehen, was man da herausholen kann.
Und ich würde mich von der Vorstellung freimachen, dass mit BMP
zwangsläufig eine "Windows BMP" Datei gemeint sein muß. Das Kürzel BMP
kann durchaus einfach für "Bitmap" stehen, also irgendein Format bei dem
jeweils dieselbe Anzahl von Bits für je einen Bildpunkt stehen.
Wie oft kommt denn die "BM"-Zeichenfolge im dump vor, die auf ein
Windows-BMP Format hindeuten würde? Ist diese magische "BM" Folge
jeweils am Anfang der Datei zu finden, wenn man den dump in 150
gleichgroße Dateien aufteilt?
Plastefuchs schrieb:> Ich wollte es vermeiden jede einzelne Einheit von Hand> aus der Datei zu rippen
Und deshalb "rippst" du lieber ein Memory-Dump?? Wenn man einmal das
Format raus hat kann man sich doch ein kleines Programm schreiben
welches die Daten konvertiert, Programmerfahrung sollte ja wohl
hoffentlich vorhanden sein wenn du das nach programmieren willst.
Was mir gerade noch einfällt:
Ist das vielleicht aus einem Windows-Programm?
Vielleicht sogar aus einem Windows-Programm, das mit einem
Microsoft-Compiler entsprechend der Microsoft-Programmierrichtlinien
programmiert wurde?
Wenn die Entwickler beim fertigen Programm keine speziellen
Kompimierungs- oder Verschlüsselungsmaßnahmen vorgesehen haben, dann ist
es unter Umständen möglich, direkt aus der .EXE oder .DLL Datei die
Bilder wieder herauszubekommen.
Poste bitte mal statt des dumps lieber diejenige EXE oder DLL Datei oder
sende mir mal einen Link zum Downloaden, in der die Bilder enthalten
sind, dann versuche ich mal was.
Plastefuchs schrieb:> Die> Originaldatei ist bei /levels/german/gamesprt.lpk
das:
Jürgen S. schrieb:> Poste bitte mal statt des dumps lieber diejenige EXE oder DLL Datei oder> sende mir mal einen Link zum Downloaden, in der die Bilder enthalten> sind, dann versuche ich mal was.
ist also nicht notwendig
wobei mird er Ort levels komisch vorkommt und ich eher vermuten würde,
dass dort missionsgedöhns drinsteckt. Sprites werden schließlich selten
lokalisiert und levelabhängig werden die Sprites auch nicht sein.
Ich würde versuchen bei den Spieledateien anzusetzen.
Zur Not versuchen mit einem Debugger/Dissassembler (zB ollydbg)
herauszubekommen, was mit den Dateien gemacht wird.
Hallo nochmal,
Ich arbeite mit Assembler momentan an der Originalen exe-Datei. Ich
selber kann zwar nur sehr wenig Assembler Programmieren, jedoch kann ich
diesen einigermaßen gut lesen. Die Sprites für das Spiel sind ohne jeden
Zweifel in dieser Datei enthalten. In einer anderen Routine werden die
Sprites zur Laufzeit über 3x *.pal Dateien eingefärbt. Dies ist zu 95%
sicher. Leider kann ich aus der Debugger-Routine nicht zu 100% schließen
wie genau die Dateien nun eigentlich entpackt werden. Sicher ist nur das
diese nicht im Arbeitsspeicher oder auf der Festplatte
zwischengespeichert werden.
Ich habe im Anhang die von mir manipulierte exe hochgeladen. Die
Änderungen sind unter anderem:
- Verschlüsselung der exe entfernt
- NoCD Patch
- Videos / Hintergrundmusik wird absofort nichtmehr von CD geladen
sondern Lokal
- Auflösung auf Widescreen angepasst (fehlerhaft)
- IsDebuggerPresent gepatcht
- CreateFileA gepatcht
- Checksumming gepatcht
Der Code ist durch diese Maßnahmen von jedem beliebigen Debugger lesbar.
Ich nochmal, ich habe euch für Testzwecke auf die schnelle eine
lauffähige "minimal" version gebastelt. Ich habe alle Videos, alle
Musikdaten, SP und MP-Missionen entfernt. Daraus ergibt sich die
Dateigröße von 10MB. Wenn man im Singleplayer eine beliebige Mission
startet, sieht man eindeutig wie er die Sprites aus der gamesprt.lpk
extrahiert. Vielen Dank nochmal.
Ein Copyright verstoß besteht im übrigen nicht, da ich eine Erlaubnis
habe :)
Plastefuchs schrieb:> Ich arbeite mit Assembler momentan an der Originalen exe-Datei.
Aus der EXE-Datei kann ich nur drei winzig kleine 32x32 Bitmaps
rausziehen, die entweder als Icons oder als Mauscursor verwendet werden
können, darunter das unter Windows angezeigte Programm-Icon der Datei.
Weitere Bilder sind da erstmal so direkt ersichtlich nicht enthalten.
Weiter oben schriebst Du etwas von der Datei "gamesprt.lpk", in der die
Bilder enthalten sein sollen. Der von Dir angegebene Speicherort
existiert natürlich nur in einer vollständigen Installation des Spiels
auf der Festplatte, die ich nicht habe. Diese Datei gamesprt.lpk könnte
eine umbenannte DLL-Datei sein. In dem Fall würde irgendwo kurz nach dem
Anfang der Datei einmal die Zeichenfolge "PE" als PE-Header auftauchen.
Wenn das der Fall ist und die Datei genau so wenig verschlüsselt und
komprimiert ist wie die EXE-Datei, und dort die Bilder entsprechend den
üblichen Microsoft-Standards enthalten sind, kann man sie dort eventuell
auch herausziehen. Die im letzten Posting gepostete EXE-Datei enthält
jedenfalls keine für mich dort ersichtlichen BMPs, nur drei kleine
Icons.
Jedenfalls könnte man die Bilder nur aus derjenigen Datei rausziehen, in
der sie tatsächlich enthalten sind. Und die EXE-Datei ist es nicht.
Hallo,
In der von mir oben angehängten Datei befindet sich sehr wohl die
gamesprt.lpk. Wenn die rar-Datei geöffnet (www.winrar.de) wurde, findest
du den Ordner "LEVELS" vor. Wenn du dann in den Ordner "german"
navigierst findest du die Datei. Es handelt sich hierbei nicht um eine
PE Datei :)
Plastefuchs schrieb:> Wenn man im Singleplayer eine beliebige Mission startet, sieht man> eindeutig wie er die Sprites aus der gamesprt.lpk extrahiert.
Tja, leider hat die gamesprt.lpk Datei keinen PE-Header und es handelt
sich nicht einfach um eine umbenannte DLL-Datei.
Oben schriebst Du was von "Verschlüsselung der exe entfernt".
Könnte es vielleicht sein, dass die "gamesprt.lpk" eine auf dieselbe
Weise verschlüsselte Datei ist?
Also dass man ggf. mit demselben Entschlüsselungstool, das zum
Entschlüsseln der EXE verwendet wurde, ggf. eine unverschlüsselte
gamesprt.lpk erhalten kann, ggf. nachdem gamesprt.lpk nach gamesprt.dll
oder gamesprt.exe umbenannt wurde?
Andere Idee: Ob es wohl herauszubekommen ist, mit welchem Toolkit die
.lpk Datei erstellt wurde, wenn sie nicht mit einem Microsoft-Compiler
kompiliert wurde? Vielleicht mit einem Game-Construction-Kit oder einen
bestimmten Grafik-Tool?
Hallo,
Ich glaub ich muss das nochmal klarstellen mit den Dateien, da gab es
scheinbar ein missverständnis.
Die exe wurde durch PE-Verschiebung manuell verschlüsselt. Da die Datei
allerdings schon >14 Jahre alt ist, war es mit heutigen Mitteln
nichtmehr so schwer diese zu "korrigieren". Der Rest war dann nurnoch
Assembler-Code.
Bei der "gamesprt.lpk" handelt es sich nach wie vor um Bilddatein. Es
handelt sich hierbei weder um eine DLL noch um ene EXE. Die exe liest
während des Ladevorganges eines Levels die Sprites aus der Datei aus.
Dabei sind 133 Lesevorgänge laut Procmon festzustellen. Jede Datei ist
20-40KB groß. Sämtliche Bilddatein die darin enthalten sind, wurden in
Grayscale - also Graustufen gespeichert. Die Datein enthalten demnach
keine Farben. Die Farben werden zur laufzeit über die .pal-Files
eingfärbt. Der Hex-Editor an mehreren Stellen eine Bitmap Signatur
sichtbar. Das Spiel läuft auf 256 Farben.
Plastefuchs schrieb:> Der Hex-Editor an mehreren Stellen eine Bitmap Signatur sichtbar.
Zwar taucht die Kennung "BM" auf, aber im BMP-Dateiformat folgt nach der
"BM" Signatur ein 4-Byte Wert im Little Endian Format, der die
Dateigröße der BMP-Datei vorgibt.
Falls die Bilddateien nicht größer als 64 KB sind, müßten das dritte und
vierte Byte hinter BM immer 0 und 0 sein.
Dezimal:
B M . . 0 0
Hexadezimal
42 4D .. .. 00 00
Und das kommt bei der Datei nicht hin, weil das dritte und vierte Byte
nach "BM" eben nicht "0" und "0" sind. Da stellt sich dann für mich
schon die Frage, was es sein kann und wie das ggf. ein ein
Greyscale-Bitmap zu konvertieren ist, wenn es keine hintereinander in
eine Datei kopierte Windows-Bitmaps sind.
Ggf. sind die Bytes im ein paar Stellen verschoben und im
Arbeitsspeicher werden sie zurück verschoben? Irgentwo in dem ASM Code
muss ja der Code drinstehen. :)
in dem File sind definitiv keine Bitmap header, das schrieb ich weiter
oben schon.
die kennung BM ist da zufällig drin.
die datei ist 6MB groß,
Bei angenommener Gleichverteilung aller Zeichen würde man ~90 vorkommen
von BM vermuten.
Es sind zwar mit 144 ein paar mehr, aber das ist wohl im Rahmen der
Schätzung. Auf jeden Fall müssten es deutlich mehr sein, wenn da auch
noch 130 BMP-Header drin sein sollten.
Ich hab grad mal versucht das Programm mit einem Debugger auszuführen
und mir die stelle anzuschauen, wo er den "gamesprt"-String
referenziert.
Ein paar Befehle drunter ist eine string-Referenz auf eine
Fehlermeldung, dass das Laden fehlgeschlagen ist.
Meine Hoffnung ist, dass man dort, wo er es einliest heruasfinden kann
(zum beispiel an Parameter von Funktionsaufrufen in bekannte APIs), was
für ein Format das zeug hat.
Die Idee hatte ich auch schon aber leider bin ich bisher gescheitert.
Wenn du allerdings etwas herausfinden solltest würde ich mich sehr
freuen wenn du es mir mitteilst :)
Danke schonmal
Darf man fragen wozu Du die Bitmaps verwenden willst?
Ich hab übrigens auch mal ein paar RAW-Experimente mit den Files gemacht
und konnte keine Strukturen erkennen - Bist Du sicher das es
unkomprimierte Bitmaps sind?
Plastefuchs schrieb:> Da der Quellcode nichtmehr> auffindbar ist und der Assemblercode mehr als aufwendig> umzuprogrammieren ist, wollen wir die moderne Technik nutzen wie z.b.> die XNA Umgebung von Mikrosoft und das Spiel nachprogrammieren. Das> dürfte mit den heutigen Mitteln nicht mehr ganz so komplex sein.
Ich bin leider nicht zu 100% sicher ob die komprimiert sind. Aber
nachdem was ich bisher gehört habe gehe ich davon aus das dies der Fall
ist.
Dis Struktur der Datei wird etwas klarer, wenn man sich die Lesezugriffe
anschaut.
zuerst wird ein Header gelesen.
in den letzten 4 Byte steht die größe des nächsten Blocks.
Der nächste Lesezugriff beträgt Größe plus zusätzliche 8 Byte, in deren
letzten 4 Byte wieder die Größe des nächsten blockes steht.
Ich möchte wetten, dass das jeweils ein Objekt ist.
Da die Blöcke alle unterschiedlich groß sind, obwohl man annehmen
sollte, dass zumindest wenigstens einige Bilder ein gleiches Format
haben, liegt die Vermutung nahe, dass sie komprimiert sind.
Die Kompression ist auf jeden fall nicht sehr fortgeschritten, da die
Bytewerte nicht allzugut verteilt sind.
auffällig ist, dass alle Dateien ziemlich am Ende einen leeren Block
haben.
Der letzte Block wird auch immer genau mit der definierten Größe
eingelesen.
falls es irgendwie hilft: hier der Code zum splitten der großen Datei in
Eintelteile.
Ich komm nich weiter. Da du geschrieben hast, dass du Asm sehr gut lesen
kannst, könntest du versuchen festzustellen, wo die Bilddaten am ende
landen.
Meine Vermutung war, dass irgendwo eine WinApi oder DirectX-Funktion
gerufen wird, der die Daten übergeben werden.
An der stelle hätte man gewonnen, da dieser Funktion ja irgendwie das
Format bekannt sein muss.
Leider konnte ich in den importierten Funktionen nix finden, was mit
grafiken zu tun haben könnte. Vielleicht ist die Liste der Importierten
Routinen aber auch irgendwelchen Verschlüsselungs- oder
Obfuscating-Aktionen zum Opfer gefallen.
Vielleicht kennt jemand ein Tool, mit dem man sämtliche Calls zu
externen Modulen mitloggen kann?
Processmonitor überwacht scheinbar nur eine Auswahl an IO-Operationen
kannst du vielleicht mal noch so viel dateien posten, dass man das spiel
auf einer kleinen einfachen Karte richtig starten kann, um sich mal den
kompletten Ram anzuschauen?
Ansonsten hab ich auch keine Ideen mehr, außer dem quasi hoffnungslosen
Durchprobieren von Dekompressionsmethoden auf den Daten. Da es aber
sicher zig simple Bildkompressionen gibt (alleine RLE gibts mehrere
Varianten) und dann unklar ist, ob in den einzelnen Blöcken der Anfang
ein Header ist, den man auslassen muss, scheint mir das unmöglich.
Vlad Tepesch schrieb:> Vielleicht kennt jemand ein Tool, mit dem man sämtliche Calls zu> externen Modulen mitloggen kann?> Processmonitor überwacht scheinbar nur eine Auswahl an IO-Operationen
API Monitor (http://www.rohitab.com/apimonitor) scheint das zu können.
aber auch hierfür wäre es wichtig mal das Spiel im laufenden Zustand zu
monitoren
Hallo
Zuerst vielen Dank für deine bisherige Hilfe!
Dieser De-Compiler sieht ja sehr interessant aus. Darf man fragen mit
welchem Programm der erstellt wurde? Ich hatte in der vergangenheit
schonmal nach etwas ähnlichem gesucht aber leider ohne Erfolg.
Ich habe dir im Anhang 3 Multiplayer-Karten hochgeladen. Diese müssten
in das Verzeichnis \KKND Krossfire\LEVELS\Multi\
Im Spiel kannst du sie dann Laden indem du auf "Multiplayer"-"keine
Mitspieler" gehst. Einen CPU Gegner fügst du hinzu indem du auf eins der
schwwarzen Kästchen der Spieler-Liste klickst.
Ich habe die Multiplayer-Karte aus dem Grund hochgeladen, da im
Singleplayer-Modus noch ein Anti-Crack-Schutz greift, der prüft ob die
CD-Check Variante geändert wurde. Dies führt dazu das im Singleplayer
alle Einheiten Selbstmord begehen. Ich habe noch nicht herausgefunden
woran das liegt.
In den LPM-Datein sind die Tiles sowie die Attribute, die MIN-Datei
enthält nur die Minimap.
Plastefuchs schrieb:> Zuerst vielen Dank für deine bisherige Hilfe!
Spieltrieb und sportlicher Ehrgeiz
wie es ausschaut, werden die lpm files nach dem gleichen Muster
eingelesen, wie die lpk files. villeicht gibt es einen Maperditor oder
ein grafik converterprogramm was bmp->kknd-map grafiken umwandelt.
zumindest gibt es ja leute die eigene tilesets erstellt haben.
kannst du die multiplayerkarten in einem Mapeditor öffnen?
Am vielversprechendsten scheinen mir die MinMaps zu sein.
Da passieren 3 4-Bytelesezugriffe und dann ein Block.
Meine Vermutung ist, dass die 2. und 3. Lesezugriff die Größe sind.
kennst du die Größe der Karten?
hier die werte aus den dateien:
1: 212x212
2: 192x192
3: 246x244
und:
http://www.youtube.com/watch?v=s0QOAFTwxQ4
Ach so:
Plastefuchs schrieb:> Dieser De-Compiler sieht ja sehr interessant aus
das ist kein decompiler, das tool logt nur alle aufrrufe in externe
moodule mit.
did mim dateien scheinen ausnahmsweise unkomprimierte rohdaten zu sein.
bei Breite 212 oder noch eher bei 424 lässt sich eine Karte erahnen
allerdings gehören scheinbar immer 2 Byte zu einem Pixel RGB565 ist es
aber auch nicht.
(im anhang mal 3 fach vergrößert)
ich konnte auf der Spielerstllungsseite aber irgendwie nicht die Karte
aktivieren um es zu vergleichen.
Nach ein paar schritten stürzt das spiel bei mir aber auch ab.
Das hatte ich vergessen dir zu sagen, ich hatte die Auflösung auf
1920x1080 gepatcht, das Spiel verkraftet das nicht so gut. Immer wenn
man die Maus ausserhalb des 4:3 Fensters bewegt gibts einen Crash. Du
musst einfach die options.cfg mit Notepad öffnen und den Screenmode von
2 auf 0 ändern. Dann läuft es wieder 1024x768.
Die MIM Datein liegen unkomprimiert vor. Ein "Minimap Viewer" wird sogar
auf der Seite angeboten. Wie dieser Karteneditor den du dort beschreibst
entstanden ist, ist mir wohl bekannt. Diverse Mapper haben Wochenlang
die einzelnen Tilesets aus dem Spiel herausgerippt. Die "Tiles" befinden
sich für gewöhnlich in den den Desert.kp-Datein. Dort sind diese in
16x16 Blöcken unverschlüsselt. In den Map Files müssten sie allerdings
Verschlüsselt sein.
Die Entwickler sprechen leider nur Chinesisch und Google Englisch. Aber
wie bereits erwähnt sind die Tiles unkomprimiert, während die Sprites
verschlüsselt sind.
