Lovely work, it's always good to read about this kind of project!
Ich habe es ausprobiert und das Entpacken der Spieldateien funktioniert ganz problemlos!
It's always a great moment, defeating the compression of the data files and seeing it all open up before our eyes 
Duplode from the Stunts-Forum?
Duplode from the Stunts-Forum?
(Yup, it's me. Hello llm , nice to see you here! )
Hey Dragonsphere, wusstest Du, dass es eine Demo von HL 1914 gibt? Wenn Du Interesse hast, könntet ich die Dir zur Verfügung stellen. Es ist das erste Level, aber um diverse Einheiten ergänzt. Vielleicht kann Dir das irgendwie helfen? Schönen Gruß
Klingt auf jeden Fall interessant und gucke ich mir gerne mal an
Danke!
Wie macht Ihr das hier bzgl. Urheberrechte? Link zur Quelle, wo ich es her habe, oder soll ich es irgendwo hochladen? Sorry, bin noch neu
Wenn es eine Offizielle Demo war, wurde die doch auch so verteilt? Dann kannst du Sie hier gerne hochladen. Wenn dem nicht so ist, solltest du dich per persönlicher Nachricht mit moravec und Dragonsphere austauschen. Vielleicht finden sie es dann leichter 
Sie war als Diskette Beilage des Heftes PCGames 1/93, musste also käuflich erworben werden. Ok, dann schicke ich Euch das als Nachricht.
Sie war als Diskette Beilage des Heftes PCGames 1/93, musste also käuflich erworben werden. Ok, dann schicke ich Euch das als Nachricht.
Stimmt. Die Ausgabe hatte ich!
Ich hoffe das ist ok: auf archive.org gibt es die originale Floppy Images
ich nutze archive.org floppies immer gerne beim Reverse engineering um sicher zu sein das ich unmodifizierte Dateien anschaue
Gibt es einen Unterschied zwischen Kampagnen Karten und Multiplayer Maps? Als ich die mal aus Spaß gegen den Computer gespielt habe, ist mir aufgefallen, dass er eigentlich nie versucht hat, neutrale oder meine eigenen Depots zu besetzten 
Gibt es einen Unterschied zwischen Kampagnen Karten und Multiplayer Maps? Als ich die mal aus Spaß gegen den Computer gespielt habe, ist mir aufgefallen, dass er eigentlich nie versucht hat, neutrale oder meine eigenen Depots zu besetzten
Ich vermute, dass die eher für die Zwischensequenzen zu neu verfügbaren Einheiten und die Zeitungsmeldungen sind und weniger für Strategien des Computergegners. Wobei natürlich
Technisch gibt es den Unterschied, dass zu den Kampagnen-Karten immer noch eine COM-Datei gehört, die die Multiplayer-Maps nicht haben. Der Dateiname könnte natürlich darauf hindeuten, dass hier weitere Infos/Strategien für den Computergegner drin stehen, ausführbaren Code enthalten diese Com-Dateien nämlich nicht. Die könnten aber auch einfach für die Zwischensequenzen zu neu verfügbaren Einheiten und die Zeitungsmeldungen wichtig sein. Bei Gelegenheit teste ich mal, ob der Computer noch dämlicher wird, wenn man die Dateien verändert oder mit denen von einer anderen Karte austauscht.
Mir war mal auch schon mal aufgefallen, dass der Computer auf manchen Karten gar nicht versucht Gebäude zu erobern. Auf anderen dann aber wieder schon.
Der Computergegner ist ja leider wirklich die Schwachstelle dieses sonst tollen Spiels und macht generell einige sehr seltsame Dinge. Der benutzt auch keine Transportfahrzeuge, verwendet Einheiten mit großer Reichweite im Nahkampf, produziert neue Einheiten die für ihn strategisch keinen Sinn machen und benutzt Pioniere nie zum Ausheben von Schützengräben sondern als reines Kanonenfutter an vorderster Front. Ebenso Transportfahrzeuge und Depoteinheiten, die sind auch nur Kanonenfutter für ihn....
Mit eigenen Karten kann man dann ja auch noch mal sehr gut testen, wie sich der Computergegner in bestimmten Situationen verhält.
Es gibt ja die Möglichkeit, Savegames zu erstellen und zu laden. In diesen müsste doch dann auch die Anzahl einer Einheit und deren Erfahrung mit gespeichert werden. Meinst Du es wäre im Editor auch möglich, z. B. eine Einheit statt mit voller Gruppenstärke schon "dezimiert" zu platzieren oder vielleicht eine mit bereits voller Kampferfahrung?
Es gibt ja die Möglichkeit, Savegames zu erstellen und zu laden. In diesen müsste doch dann auch die Anzahl einer Einheit und deren Erfahrung mit gespeichert werden. Meinst Du es wäre im Editor auch möglich, z. B. eine Einheit statt mit voller Gruppenstärke schon "dezimiert" zu platzieren oder vielleicht eine mit bereits voller Kampferfahrung?
Ich fürchte, die Spieldateien geben das so nicht her. 
In den .fin Dateien gibt es ja keine Daten zu Gruppenstärke oder Erfahrung. Was mir auch fehlt, sind weitere Angaben zur Position der Einheiten. Im Spiel können die ja z.B. auch schräg stehen, aber in der .fin Datei gibt es keine Möglichkeit dafür und bei jeder Karte stehen alle Einheiten zu Beginn ja auch gerade, die deutschen weisen nach Süden und die französichen nach
Norden und alle mit voller Gruppenstärke und ohne Erfahrung.
Möglch wäre aber natürlich, ein Savgeames und nicht die Kartendateien selbst entsprechend zu editieren ((01.dat bis 09.dat im Hauptverzeichnis des Spiels sind die Savegames).
Da steht nämlich wirklich alles drin, denn um den Spielstand zu speichern werden vom Spiel einfach die Speicherbereiche mit den Daten/Variablen zum aktuellen Spielgeschehen komplett in eine Datei geschrieben.
Was ich schon gesehen habe ist, dass am Beginn einer Savegamedatei die Infos zum aktuellen Spielstand stehen, so wie sie auch im Spiel angezeigt werden, also welche Karte, welche Runde ob ein Zuglimit eingestellt ist, Rohsotffeinnahmen, Gebäude usw.
Etwas darunter kommen dann die Kartendaten mit der aktuellen Position der Einheiten im selben Format wie die .fin Dateien. Hier wird anscheinend immer der komplett mögliche Buffer für Kartendaten in die Datei geschrieben und bei kleineren Karten stehen dann da auch Speicherinhalte, die gar nichts mit dem Spiel zu tun haben. Bei mir stehen dann da z.B. unter den Kartendaten, plötzlich Meldungen vom Norton Commander im Savegame und daher bin ich mir sicher, dass ein Savegame einfach ein Speicherauszug ist 
Weiter unten in der Datei, kommen dann die Gebäude, deren Inhalt und aktueller Besitzer im selben Format wie die .shp Dateien. Irgendwo muss dazwischen auch die aktuelle Erfahrung der einzelnen Einheiten stehen und auch, wenn diese schräg stehen muss das ja irgendwo definiert sein. Kannst ja mal suchen und mit 'nem Hexeditor ausprobieren. Die letzten vier Byte in der Datei sind auf jeden Fall die aktuellen Rohstoffvorräte von Seite A und B.
Die Savegames sind auch nicht komprimiert, können also ohne Probleme editiert werden.
Die Grafiken bereiten mir übrigens noch immer Kopfzerbrechen:
Das Format der LIB-Dateien ist simpel und schnell nachzuvollziehen. Die bestehen aus zwei Abschnitten, der erste enthält hintereinender die Daten, also z.B. die einzelnen Grafiken, der zweite einen Index, mit einem 8-Stelligen ID String für die jeweilige Grafik und dem Startoffset. Die ersten vier Byte in der Datei enthalten den Startoffset des zweiten Abschnitts.
Aber die einzelnen Grafiken sind schwierig. Hier mal die erste in PARTS.LIB gespeicherte Grafik als Hex-View:
Es scheint einen Header zu geben, der Aufbau ist aber nicht der aus einer LBM/IFF Datei und entspricht auch nicht dem BMHD Chunk aus diesen Dateien.
Viele Bytes sind ja auf 0 gesetzt, nur die 20h und 55h an den Offsets 08h und 09h und 18h an Offset 0Eh und 10h scheinen Header Daten zu sein. Im LBM/IFF Format kommt hinter dem ID-String normalerweise die Größe des Chunks, hier scheinen aber weder die 20h noch die 55h zu passen, schon gar nicht als word. 21792 Byte hat die Datei nicht, 32 Byte oder 55 Byte sind dagegen zu wenig.
Also keine Ahnung wofür die stehen. 20h könnte auch noch als abschließendes Leerzeichen zum INFOILBM-String gehören. Die beiden 18h, also 24 dezimal, könnten gut die Größe des Bildes sein. 24x24 Pixel würde recht gut für ein Hexagon in HL passen.
Käme auch mit der Größe der Daten hin. 24x24 ergibt 576, 601 Byte hat die Grafik (danach folgt in der LIB der nächste INFOILBM String), blieben also 25 Byte für Header und den "INFOILBM" String.
Das würde aber bedeuten, dass es sich hier um die reinen, unkomprimieren Bilddaten handelt. Alle meine Versuche die Grafik am Bildschirm anzuzeigen, führten aber nur zu Grafiksalat.
Wenn wir uns im Vergleich die erste Grafik aus der UNIT.LIB anschauen, also die eine Einheit, wahrscheinlich den Spähpanzer, dann gibt es einige interessante Unterschiede:
Das Format scheint das gleiche zu sein, nur ist hier der ID-String nur "ILBM", die restlichen vier Byte sind auf 20h gesetzt. Dann kommen wieder zwei Byte, diesmal 09h un 50h und an den Offsets 0Eh und 10h wieder die 18h. Die stehen übrigens bei allen Grafiken an dieser Stelle, was ja Sinn macht, wenn wir von lauter 24x24 Pixel Bitmaps ausgehen.
Jetzt haben wir aber das Problem, dass diese Datei nur 306 Byte lang ist. Also doch eine Bildkomprimierung.
Die Bilddaten wie die in einer IFF/LBM Datei zu lesen, hat bisher nicht funktioniert. Hier fehlen ja auch Angaben zur Zahl der Bitplanes usw. Da werde ich noch mal weiter probieren, wenn ich etwas Zeit habe.
Vielleicht hat ja von euch auch noch jemand Lust, sich daran zu versuchen?
Ich hänge die beiden Grafiken als Testgrafiken aus PARTS.LIB und UNIT.LIB.zip mit an, dann müsst ihr zum Testen nicht mit den kompletten LIB-Dateien hantieren.
Ich finde das echt interessant und habe höchsten Respekt vor Euch Codern und Reverse Engineers Cool, dass Du Dir die Zeit nimmst.
ich hab ein wenig im IDA gestöbert und ein paar Routinen und Bezüge zu "TPMW", "PBM ", "ILBM", "BMHD", "CMAP", "BODY" gefunden
z.B. eine (bisher die einzige) Routine die nach den Grafik Tags/Ids? in einem Puffer sucht
; input ES:DI buffer
ILBM_USE1_sub_3AF32 proc far
mov cs:word_3B230, 0FFFFh
push di
; "PBM "
mov ax, 'BP'
mov bx, ' M'
push cs
call near ptr sub_3AFA2
pop di
jnb short loc_3AF5A
; "ILBM"
mov ax, 'LI'
mov bx, 'MB'
push cs
call near ptr sub_3AFA2
jb short loc_3AFA0
mov cs:word_3B230, 0
loc_3AF5A:
; "BMHD"
mov ax, 'MB'
mov bx, 'DH'
push cs
call near ptr sub_3AFA2
jb short loc_3AFA0
mov word ptr cs:dword_3B232, di
mov word ptr cs:dword_3B232+2, es
; "CMAP"
mov ax, 'MC'
mov bx, 'PA'
push cs
call near ptr sub_3AFA2
jb short loc_3AFA0
mov word ptr cs:dword_3B23A+2, es
mov word ptr cs:dword_3B23A, di
; "BODY"
mov ax, 'OB'
mov bx, 'YD'
mov di, 0
push cs
call near ptr sub_3AFA2
jb short loc_3AFA0
mov word ptr cs:dword_3B236+2, es
mov word ptr cs:dword_3B236, di
retf
loc_3AFA0:
stc ; nothing found?
retf
ILBM_USE1_sub_3AF32 endp
; in : AX, BX (AX='LI', BX='MB' ==> 'ILBM')
; out: ES:DI
sub_3AFA2 proc far
cld ; +1 direction
mov cx, 5000
loc_3AFA6:
repne scasw ; search for AX content (max 5000 words)
or cx, cx ; sets zero flag if cx = 0
jz short loc_3AFB6
cmp bx, es:[di] ; is BX content directly behind?
jnz short loc_3AFA6
sub di, 2 ; es:di ==> {ILBM....}
clc ; clear CF -> found
retf
loc_3AFB6:
stc ; set CF -> not found
retf
sub_3AFA2 endpfür anderen Spiele habe ich kleine Dosbox Staging Forks mit denen ich z.B. Datei-Operationen verfolgen kann - oder Testweise emulierten Code durch nativen Code ersetzen kann - um z.B. zu prüfen ob ein Algorithmus-Port richtig funktioniert - auch wenn nur mitten im Spiel genutzt, oder procs Hooken und schauen was da für Daten durchfließen usw. - ich denke für HL wäre so was auch ganz nett
jetzt könnte man im Dosbox Debugger einen Breakpoint auf die Routine setzen und mal schauen was da so für Daten durchgeschoben werden
sub_3AFA2 proc far
cld ; +1 direction
mov cx, 5000
loc_3AFA6:
repne scasw ; search for AX content (max 5000 words)
or cx, cx ; sets zero flag if cx = 0
jz short loc_3AFB6
cmp bx, es:[di] ; is BX content directly behind?
jnz short loc_3AFA6
sub di, 2 ; es:di ==> {ILBM....}
clc ; clear CF -> found
retf
loc_3AFB6:
stc ; set CF -> not found
retf
sub_3AFA2 endpdie ID-Suchroutine ist auch richtig schön "handgemalter" Assembler-Code, wenn der "cmp bx, es:[di]" vergleich in Zeile 9 fehlschlägt hüpft er einfach wieder in die Suchschleife mit repne scasw die dann sofort beendet wird (da cx schon 0 ist) und dann Sprung auf loc_3AFB6 - also sollte das Label in dem jnz unter cmp bx,es:[di] eigentlich direkt auf loc_3AFB6 gehen
und ich finde es komisch das die Routine nur Word-weise sucht d.h. die IDs/Tags müssen auf Word-Grenzen liegen sonst findet die Routine nix
ein Quick&Dirty Port davon sieht wohl so aus:
uint8_t* find_by_4byte_string(const std::string& id_, uint8_t* buffer_, size_t buffer_size_)
{
assert(id_.size() == 4);
uint32_t value = *reinterpret_cast<const uint32_t*>(id_.data());
uint32_t* dbuffer = reinterpret_cast<uint32_t*>(buffer_);
for (size_t i = 0; i < buffer_size_ / sizeof(uint32_t); ++i)
{
if (dbuffer[i] == value)
{
return reinterpret_cast<uint8_t*>(&dbuffer[i]);
}
}
return nullptr;
};
uint16_t word_3B230 = 0;
uint8_t* dword_3B232 = 0;
uint8_t* dword_3B236 = 0;
uint8_t* dword_3B23A = 0;
bool ILBM_USE1_sub_3AF32(uint8_t* buffer_, size_t buffer_size_)
{
word_3B230 = 0xFFFF;
uint8_t* curr = buffer_;
if (!find_by_4byte_string("PBM ", buffer_, buffer_size_))
{
curr = find_by_4byte_string("ILBM", buffer_, buffer_size_);
if (!curr) return false;
word_3B230 = 0;
}
curr = find_by_4byte_string("BMHD", curr, buffer_size_ - (curr - buffer_));
if (!curr) return false;
dword_3B232 = curr;
curr = find_by_4byte_string("CMAP", curr, buffer_size_ - (curr - buffer_));
if (!curr) return false;
dword_3B23A = curr;
// di = 0, es ist unklar ob das der buffer Anfang ist
curr = find_by_4byte_string("BODY", buffer, buffer_size_);
if (!curr) return false;
dword_3B236 = curr;
return true;
}und ich finde es komisch das die Routine nur Word-weise sucht d.h. die IDs/Tags müssen auf Word-Grenzen liegen sonst findet die Routine nix
Das Spiel wurde sicherlich zuerst auf dem Amiga entwickelt/programmiert (darum sicherlich auch das Grafikformat) und auf der Basis dann die PC -Version entwickelt, da würde das Sinn machen, mit den word-sized Routinen (16 Bit).
Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!